GTS3: rewrite DMD PWM integration

[vbousquet]

• get the same luminance levels between games,
• fix some residual flickering,
• simplify code,

but at the price of a little performance impact

more details in gts3dmd.c code comment on the motivation behind this proposed change.

Note that this PR needs an update of #303 (I will do it if this PR is merged)

[toxieainc]

Nice! I fear something similar could also be needed for some early WPC DMD games like T2 or HS2 as these seem to feature some flicker 'effects' that exceed the usual 4 brightness levels. So if you're interested.. .. .. :)

[toxieainc]

..oh, and what about AlvinG.? I guess that should be similar to GTS3?

[toxieainc]

one more: GTS3_VBLANKFREQ is insanely high, and i don't think this is useful anymore nowadays? (unless i miss something)

[toxieainc]

And yet one more: if you enter the display test on e.g. SMB (press '0' multiple times) and then flip through the brightness levels, then one can see slight variations, and if all 5 levels are displayed some slight flickering, now.
But fixing that i would consider just a bonus.

[vbousquet]

Just had a look to all these points:

• the remaining flickering in SMB (and others) was a precision issue. I fixed it and merged the change. I also updated the filter since before finding this stupid precision issue (the final multiplication by 15 when computing shades...), I thought it was the filter, so I did a clean FIR design in Octave and validated a new (and better) filter.
• GTS3_VBLANKFREQ is 60Hz, so it looks 'normal' to me (as long as normal means something here since there is no hardware vblank: this is a generic timer to perform legacy PWM smoothing and fast flips. another name for this could be less misleading).
• Regarding WPC and AlvinG, they should be somewhat the same (they all uses this type of PWM, but the hardware for the DMD rasterization varies). I will have a look when validating luminance for them for VPX's new DMD renderer (that's how I stumbled upon the GTS3 issues, for the time being, I have Stern and GTS3 looking right, and still have to validate the others)

[vbousquet]

Just realized that GTS3_VBLANKFREQ is in fact 60x60Hz. I agree this is way too high.

As I wrote above, I think that this VBlank implementation is somewhat hacky. To me, I would prefer core_updateSw to be directly handled by the core, then have drivers implement their legacy solenoid/lamp smoothing as they want. This would imply the following:

• let drivers expose gameOn state to core (add a method for this, and call it on state change)
• move core_updateSw to the core interrupt handler, select a frequency for it (something like 4x60Hz should be enough)
• adjust drivers handling of legacy sol/lamp smoothing (not doing it at all when using physic output)

For the time being, for GTS3, I would say that using 4 for the 60Hz multiplier to trigger core switch handling should be good.

[vbousquet]

Little update here:

• WPC is done and it needed timing (and other tings) adjustment. I think it is now good but needs wider testing,
• I cleaned up GTS3 and finally went up for a 60HZ interface update frequency as most drivers are like this (also renamed to interface update)
• I had a quick look to Alvin G and think it needs a deeper look since, as the code says, the FIRQ is 'a wild guess' so the timing are likely 'good enough' but not the real one. Since Alvin G uses discrete IC (not a FPGA), I think ths can be done like for others but needs more time & work

[toxieainc]

For AlG i have a measured one, never commited as it didn't improve things so far: 73.41

[vbousquet]

On which table was this measured ?

It looks like AL's Garage band and Mystery Castle do not have the same timing (Mystery Castle has a /4 clock divider and it toggles VClock with the SELSYNC signal while Mystery Castle don't have these IC)

[toxieainc]

Unfortunately i don't know. @lucky01 gave me the measurement some years ago (thanks!).

[toxieainc]

Minor nitpicking again, sorry ;)
Now for GTS3, the 4 shades 'variants' flicker in the display test menu (e.g. stargate).
(it can also be seen during gameplay in some of waterworlds animations/displays)

(the rest of the changes look pretty good so far, thanks!!)

[vbousquet]

I think most of the flickering is due to precision issue since we are reducing the values to 16 shades while the pattern lead to 32 and 96 value so a little ripple causes a visible gap. Rendering with 255 shades (like in VPX) would hide most of it. I will have a look to better fit the FIR filter or add a small offset to hide the 0/1 ripples.

I just pushed another update for other system and better code. This 'little' clean up/improvment is starting to get somewhat big. On the news side:

• regarding Alvin.G I think the new code correspond better to the hardware but I still have doubts on the main timing (informations are scarce for this hardware, made everything from bad scans of schematics, so...).
• regarding Data East, I was fairly surprised to see that one of the 2 frame pattern was over weighted (not 1/1 but 2/1). I fixed it but this would break colorizations (raw frames were not exposed, so they use preshaded ones). I will have to add a way to toggle between backward compatibility for colorization or fixed luminance.

[toxieainc]

Great, thanks a lot for diving into this.

[toxieainc]

Next bugreport, sorry ;)
Data East games, e.g. LW3 on TriBall ready and also during TriBall now sometimes shows the display version screen for a while.

[vbousquet]

I have Data East & Whitestar wrong, sorry for that. I now have access to the full digital recordings so I will try to fix these asap.

On the bright side, I think I finally have fixed the Alvin G timing (by reading again and simulating part of the schematics). The surprising part was that Al's Garage Band ends up with a fairly high refresh rate of 900+ Hz. Still have to check a few things for it, but it's getting closer.

[toxieainc]

In general a lot of stuff is improved already now, e.g. the fading of GTS3/AlG, the timing of some DE/Sega games (e.g. videomodes), so this is pretty awesome.

[lucky01]

From my recordings I see that pistol poker has 74,5 Hz refresh

[vbousquet]

@lucky01 this match the revised AlvinG driver (I simulated the rasterizer in logisim-evolution and it nearly matched). Do you have timings for Al's Garage Band ? This would be great as it would save quite some work.

I have pushed cleaned up version of AlvinG, and DE/Whitestar. I'm still somewhat unsatisfied for DE/Whitestar since I had to put back the hack to get around SW/LW3/... bugs but it leads to wrong timings and DMD animation speed on these games (like before). If someone has insight on these (digital recordings, frequency measures, any hint,...), this would be greatly appreciated

[lucky01]

Do you have timings for Al's Garage Band ? This would be great as it would save quite some work.

Sorry no !

If someone has insight on these (digital recordings, frequency measures, any hint,...), this would be greatly appreciated

LW3 has a refresh of 78,07Hz (RowData Pin) if that helps

Any chance you can have a look at the last missing pinball emulation Sleic ? From what Gerrit told me the incomplete I80188-CPU emulation is the problem.

As far as I understand Mame has a working emulation which needs to be ported to pinmame. We found a good starting point for pinmame which should be this commit in mame
mamedev/mame@89e14c6#diff-15ad9f77e2909023d8a085db8b004280

only 6 commits in between
https://github.com/mamedev/mame/commits/2fa7094eab8797f2cc50406a67d03cdbbfc0e3ac/src/emu/cpu/i86/i86.h

[vbousquet]

Any chance you can have a look at the last missing pinball emulation Sleic ?

Sadly, for the time being, I have far too much things ongoing to go on another side project. But one day, who knows ?

Regarding the DMD emulation, some new progress, this time for Data East 128x16. It used to have a few hacks (CPU cmd being processed twice, some command being eaten, slightly off timing) which should be fixed now. Also the low pass filter gives better result than the previous 2 frame integration, but it may also breaks colorization since raw frames were not sent.

The overall progress so far:

Name	Raster. FPS / Disp. FPS	PWM pattern	Changes	Remaining	Comments
Alvin G. 1	1194.4 / 298.6	4	Improved timing & shading	Validate timing	The rasterization frequency seems too high
Alvin G. 2	298.6 / 74.6	4	Fixed timing & shading	-
Capcom	508.6 / ?		TODO	TODO
Data East 128x16	177.5 / 59.2	2u	Timing cleanup, CPU-DMD fixes, better shading	-	Colorization backward compatibility option to add
Data East 128x32	234.21 / 78.07	2u	Fixed timing & slightly better shading	SW/LW3/R&B may have glitches (can't reproduce anymore)	Colorization backward compatibility option to add
Data East 192x64	? / 74.72	4	TODO	TODO
Gottlieb GTS3	375.9 / 125.3 - 37.6	3 / 6 / 8 / 10	Fixed timing & shading	Residual flicker (precision issue ?)
Inder	134.8 / ?		TODO	TODO
Whitestar	233.31 / 77.77	2u	(Slightly) better shading	-	Colorization backward compatibility option to add
Sleic			TODO	TODO
Spinball	132.9 / ?		TODO	TODO
Stern SAM	? / 62.6	4u	TODO	TODO
WPC	122.1 / 40.7 - 20.3	3 (/ 6 ?)	Fix T2 (and others ?), better shades	-	T2 real pinball has glitches in the target anim too.

[toxieainc]

Great analysis and execution!

[toxieainc]

Just small testing report: TAF(G) has a flickering 'title screen' now. Thanks!

[toxieainc]

..seems to be a more general WPC 'problem', e.g. T2 and TOM also feature it now

[vbousquet]

Some more progress. There should not remain any flicker, Data East should be finally fixed, WPC's Phantom Haus too, SAM has perhaps better shades (but this needs more reverse engineering).

Name	Raw FPS Disp.FPS	PWM pattern	Changes	Remaining	Comments
Alvin G. 1	1194.4 298.6	4 row	Improved timing & shading	Validate timing (likely wrong ?)	The rasterization frequency seems too high (only used by Al's Garage Band)
Alvin G. 2	298.6 74.6	4 row	Fixed timing & shading	-
Data East 128x16	177.5 59.2	2u row	Timing cleanup, CPU-DMD fixes, better shading	-	Shading improvments by considering 30Hz data smoothing
Data East 128x32	234.2 78.1	2u row	Fixed timing, slightly better shading, fix SW/LW3/R&B incorrect timings and bugs	-
Sega 192x64	224.2 74.73	2u row	Timing cleanup, slightlys better shading	-
Gottlieb GTS3	375.9 125.3 - 37.6	3 / 6 / 8 / 10 frames	Fixed timing & shading	-
Sega/Stern Whitestar	233.3 77.8	2u row	Slightly better shading	-
WPC	122.1 40.7	3 frames	Fix T2 (and others ?), better shades	-
WPC Phantom Haus	61.05 30.1	2 frames	Fixed timing, full panel rendering	-
Capcom	508.6 127.2 ?	4 ?	TODO	TODO
Inder	134.8 ?	?	TODO	TODO
Sleic	? ?	?	TODO	TODO
Spinball	132.9 ?	?	TODO	TODO
Stern SAM	751.2 62.6	4u row	Improved shades (to be better validated ?)	Implement interframe emulation, validate shades, fix back/front mix

• 'u' stands for 'unbalanced' : each frame has a different display length.
• PWM can be performed per row or per frame (raw FPS is computed considering equivalent per frame PWM).
• The flicker/fusion limit for plasma DMD is guessed around 25Hz from WPC/GTS3 which have patterns as low as 30.1Hz without real flicker but use one less frame in PWM pattern to keep above 20Hz in WPC Phantom Haus.
• The flicker/fusion limit for LED DMD is unknown, perhaps higher (less bright device which impacts Ferry/Porter law, and faster display reaction).

[toxieainc]

More testing: Batman Forever sometimes shows the display version screen at Ball1 launch and/or after game end/match sequence.

[toxieainc]

Values of the transmitted (to VPX) DMD data seem to be smaller/darker now.

Congo DMD now has a slight flicker in the williams logo during attract mode (but has an awesome fading now of the Congo logo!).