Sega Model2 Emulation Thread - 09/21: Discussing M2 Emu Colors

In a somewhat shocking turn of events, the EEPROM I dumped is now emulated inside of MAME! I had no idea until I was compiling my own version of MAME and saw Sonic the Fighters now required an extra file! This is absolutely amazing!

 

Thanks for that! Though I'm not sure that adding that file as a mandatory requirement to all the romsets that support it is the way to go but hey, it's amazing nonetheless!

 

Some interesting discussion on reddit has occurred regarding ElSemi's emulator vs MAME:

 

Because I'd like to keep things interesting, I'd like to share a discovery I made in a difference found between ElSemi's emulator, sometimes mistaken as "Nebula2", and MAME.

Since it's release, it's directx api and assembly optimization have made ElSemi's emulator the king in the Model2 area. So much so MAME devs lost drive to even pursue it further in their own software. However, many recent additions to the Model2 code in the last year have vastly improved playability for Model2 emulation in MAME.

Exhibit A in "ElSemi never had this to implement":

This is a window of debug mode in Sonic the Fighters called "EN COMMAND". The code, theoretically, shows many "simplified" debug functions with English labeling. While 90% of the Debug functions in StF work in ElSemi's emulator (some may be broken at the code level), this menu does not.

Exhibit B, the MAME "EN COMMAND" menu:

Here is the same menu, activated at the same time as ElSemi's emulator, but we can see the menu produces different results. I haven't fully investigated why that is, but I have a sneaking suspicion it has to do with specific opcodes which tell the code to pull menu items from a list. While MAME also can not produce the menu, it's unclear if it's a bug in emulation or program code. In either case, we have two seperate results under emulation, and are likely to have a 3rd result of real hardware soon once a mode to inject debug mode into a retail cabinet is produced.

I just thought the difference was interesting and worth sharing to show that the MAME team is advancing in their Model2 emulation, and this, while glitchy, may be more correct emulation that we previously had.

 

It's been well over a year since I last posted in this thread, but today I thought I would post something involving a change in how MAME handles the audio CPU of the Model2 series. This change happened in MAME 0.209 and the bug is still current today.

Here is the mametesters thread.

tl;dr, strange attract mode issues in "USA" and "JAPAN" regions but not "EXPORT".

 

Alright so me and my crew have been discussing this before. Ultimately, arcade games use potentiometers to adjust color settings. The Model2 is no exception, with the pots being somewhere in-between the arcade board and the monitor (the monitor itself may have some too).

The EMULATOR.INI offers the following settings:

Ultimately you can adjust those to your liking.

This is what my VF2 screen looks like on default settings. Note that setting in game assignments will be "PROJECTOR"



This is what the setting looks like on CRT:


So there is your answer as to why it looks like that. Settings when taking screenshots should always be initialized first.

There has been some recent discussion with my own M2 circle regarding colors and what we've decided ultimately is that we need to create some sort of benchmark. To do this, we plan to extract the graphics from the Display Test of Sonic the Fighters, both the graphic and cg data, and attempt to color match those to that of a real Model2 board captured via HDMI. Ultimately, that may calibrate Sonic the Fighters, but it is unknown how that will look for games such as Virtua Fighter 2 or Daytona.

For now, the only official Model2 emulation that should be considered the most "color accurate" are the PSN and X360 releases. I would screenshot from those for now until this benchmark of ours is set up. + - I also can't believe you wouldn't ping me for this... smh  

As for MAME, it can run M2 games, but it is absolutely inaccurate in colors/lighting/graphics.

EDIT: Can a mod review if this thread should be merged into this one? I'd like to consolidate this if possible.

 

Here are some side by sides with default values:
VF2 and FV


VF2 and STF


Both VF2 and FV are identical. A gif of the two as a comparison:




VF2 and StF are clearly different:


Now here is VF2 and StF with StF's values changed to the same numbers as VF2/FV:


And now a gif of that compared to VF2:


Again, the developers of the software have hard-coded these values into ROM which get sent to the graphics processor for rendering. Each game is going to have it's own graphics rendering code, these three games happen to share that code so they can produce identical color results.

The reason these adjustments are even available for these titles is so arcade operators could calibrate their CRTs for their cabinets like Blast City cabs and not have to hardware adjust the monitors to get a good picture. This allowed operators to change colors at the software level and the games would remember those levels on every boot. A game could be swapped back into the Blast City and the monitor would not need color recalibration.

EDIT: Looking at the disassembly for STF, the routine that initializes colors is at offset 0x3634:

Code (Text):

1. ROM:00003634 loc_3634:                               # CODE XREF: ROM:00003A24↓j
2. ROM:00003634                                         # ROM:00006970↓p
3. ROM:00003634                 mov     22, r15
4. ROM:00003638                 stib    r15, TST_RED_ADD
5. ROM:00003640                 mov     22, r15
6. ROM:00003644                 stib    r15, TST_GRN_ADD
7. ROM:0000364C                 mov     22, r15
8. ROM:00003650                 stib    r15, TST_BLUE_ADD
9. ROM:00003658                 addo    0x1F, 0x17, r15 # r15 = 0x36 (54)
10. ROM:0000365C                 stib    r15, TST_RED_MUL
11. ROM:00003664                 addo    0x1F, 0x17, r15 # r15 = 0x36 (54)
12. ROM:00003668                 stib    r15, TST_GRN_MUL
13. ROM:00003670                 addo    0x1F, 0x17, r15 # r15 = 0x36 (54)
14. ROM:00003674                 stib    r15, TST_BLUE_MUL
15. ROM:0000367C                 mov     0x1F, r15       # r15 = 0x36 (54)
16. ROM:00003680                 stib    r15, TST_B_BRIGHT
17. ROM:00003688                 call    write_colors_to_ram

We can see that our RED, GREEN, and BLUE color values get assigned a value of 22, and our GAIN values get assigned a value of 54. This happens every boot of the game before the values are read from the saved backup ram and get potentially overwritten. These default values are the hardcoded values intended for this game. I imagine all Model2 titles have their own implementations of this. So to say a title looks better on a crt in an arcade where the monitor has been calibrated to the environment and the arcade operator's preferences is just that, a preference. I would imagine the developers intended these values during development and shipped them in the final game.

EDIT: I will go one step further here. This video of Virtua Fighter 2 is taken from arcade hardware and is being passed through the same video processing unit I will be using (although they are using an upscaler and I won't)

If we take a screenshot of the character select and compare it to the model2 emulator screenshots, we can compare results for at leas an initial benchmark:

Hardware vs m2emu projector setting:


Hardware vs m2emu crt setting:


Neither are accurate to hardware, but I guess the point I am trying to make here is that the settings within the service menu shouldn't be the settings we adjust, but rather the m2emulator's virtual potentiometers should be adjusted to balance the colors for all games across the board for the original factory shipped settings.

EDIT: I got slightly more accurate settings for when VF2 is set to CRT display type:


Change your EMULATOR.INI settings to this:

Code (Text):

1. GammaR=0.67            ;Per Component Gamma correction (1.0 = no correction). Red
2. GammaG=0.67            ;Green
3. GammaB=0.67            ;Blue

I don't think the correction variable goes to more than two decimal points, which is a shame...

EDIT: Just to make sure I wasn't going completely crazy, here is the CRT TEST with both the adjusted (values above) and not adjusted (values at 1.0) comparison:

 

The manual also says "Normally, there is no need to make adjustments."

I will keep playing with settings and maybe try to disassemble the the m2emulator to see how many decimal places the emulator uses for those variables.

EDIT: Well wouldn't you know it. My hacked ROM of StF to load the service menu in the PS3 version, 16 graduations...



EDIT2: Unexpectedly, MAME shows the 16 as well, though it's emulation isn't reliable enough for screencapping gameplay.

 

It appears that on 4/27, the domain that ElSemi's emulation page was hosted, emulatronia.com, has been taken down.