05721: sms, smspal: Failed on "SMS VDP Test"

ID	Category [?]	Severity [?]	Reproducibility	Date Submitted	Last Update
05721	Misc.	Minor	Always	Oct 12, 2014, 17:34	Apr 8, 2015, 03:04

Tester	demotester	View Status	Public	Platform	MESS (Official Binary)
Assigned To	Justin Kerk	Resolution	Fixed	OS	Windows XP
Status [?]	Resolved			Driver	sega/sms.cpp
Version	0.154	Fixed in Version	0.161	Build	Normal
		Fixed in Git Commit		Github Pull Request #

Summary	05721: sms, smspal: Failed on "SMS VDP Test"
Description	SMSVDPTest-SMS-1.31 -> http://www.smspower.org/Homebrew/SMSVDPTest-SMS SMS VDP Test (tested on sms system) ----------------------------------------------------- SMS VDP data test (page 1) ..... Passed all tests SMS VDP misc test (page 2) .... Failed 2 tests (HCounter correct, VINT flag HCount) SMS VDP sprite test (page 3) ... Failed 1 test (Spr ovr correct HC) Note: On smspal system all same except: SMS VDP sprite test (page 3) ... Failed 2 tests (Spr col correct HC, Spr ovr correct HC)
Steps To Reproduce
Additional Information	JFI ... condition for the above test is: ZEXALL test passed (see below): ZEXALL-SMS-0.15 ...... http://www.smspower.org/Homebrew/ZEXALL-SMS ...... Passed all (tested in MESS sms system) So that the condition is satisfied for above SMS VDP Test ! (AFAIK, the emu that is very close to pass all SMS VDP tests is Regen v0.97 ... it failed only one test on SMS VDP misc test (page 2) .... Line IRQ HCount !)
Github Commit

Flags
Regression Version
Affected Sets / Systems	sms, smspal

Attached Files

No.11168 enik Tester Oct 23, 2014, 01:33	The VDP emulation relies on screen timing. Drivers set in src/mess/drivers/sms.c file use the MCFG_SCREEN_RAW_PARAMS() macro to configure the screen. The macro relies on the pixel clock, passed as the first parameter, to calculate the pixel time (time taken for each single pixel). Each SMS driver configuration divides the master clock by 15 to set the CPU clock and by 10 to set the pixel clock. By consequence, the ratio between CPU clock and pixel clock is 2/3, what means that, for each 2 cycles, the CPU expects the VDP drew 3 pixels on screen. The emulation core schedules the execution of each execution device, like CPUs, using time slices. The operation that reads VDP status is executed in the CPU time slice. Both NTSC and PAL master clocks are multiple of 15, but unfortunately aren't multiple of 10, then the integer pixel clock used by MCFG_SCREEN_RAW_PARAMS() ends up losing 0.5Hz. By consequence, the ratio between a CPU clock time and a pixel time isn't exact 2/3 anymore. The difference may seem insignificant, but depending on the amount of clocks ran in a CPU time slice, the sum of their times divided by the bigger pixel time produced by that rounding issue may result in a count with a missing pixel when the CPU reads the VDP status. The VDPTest ROM requires exact results. Due to the issue I described, sometimes the results are successful, sometimes not. The behavior is better demonstrated by running the X-Scroll test for some time. I submitted a patch in the past that added a big comment to explain the issue and offered a workaround, that sets a more exact pixel time by reseting the refresh rate using MCFG_SCREEN_REFRESH_RATE(): http://git.redump.net/mame/tree/src/mess/drivers/sms.c#n507 A changed SMS driver configuration, that adds the proper MCFG_SCREEN_REFRESH_RATE() line provided by the comment, pass all tests of the VDPTest 1.31.
No.11586 Justin Kerk Developer Apr 8, 2015, 03:02	After seeing some discussion of this on the shoutbox a while ago I have gone ahead and applied this workaround for now as it seems fine to me and nobody is jumping up to fix the core issue. Can revisit later.

No.11168

enik

Tester

Oct 23, 2014, 01:33

The VDP emulation relies on screen timing. Drivers set in src/mess/drivers/sms.c file use the MCFG_SCREEN_RAW_PARAMS() macro to configure the screen. The macro relies on the pixel clock, passed as the first parameter, to calculate the pixel time (time taken for each single pixel). Each SMS driver configuration divides the master clock by 15 to set the CPU clock and by 10 to set the pixel clock. By consequence, the ratio between CPU clock and pixel clock is 2/3, what means that, for each 2 cycles, the CPU expects the VDP drew 3 pixels on screen. The emulation core schedules the execution of each execution device, like CPUs, using time slices. The operation that reads VDP status is executed in the CPU time slice.

Both NTSC and PAL master clocks are multiple of 15, but unfortunately aren't multiple of 10, then the integer pixel clock used by MCFG_SCREEN_RAW_PARAMS() ends up losing 0.5Hz. By consequence, the ratio between a CPU clock time and a pixel time isn't exact 2/3 anymore. The difference may seem insignificant, but depending on the amount of clocks ran in a CPU time slice, the sum of their times divided by the bigger pixel time produced by that rounding issue may result in a count with a missing pixel when the CPU reads the VDP status.

The VDPTest ROM requires exact results. Due to the issue I described, sometimes the results are successful, sometimes not. The behavior is better demonstrated by running the X-Scroll test for some time. I submitted a patch in the past that added a big comment to explain the issue and offered a workaround, that sets a more exact pixel time by reseting the refresh rate using MCFG_SCREEN_REFRESH_RATE():

http://git.redump.net/mame/tree/src/mess/drivers/sms.c#n507

A changed SMS driver configuration, that adds the proper MCFG_SCREEN_REFRESH_RATE() line provided by the comment, pass all tests of the VDPTest 1.31.

No.11586

Justin Kerk

Developer

Apr 8, 2015, 03:02

After seeing some discussion of this on the shoutbox a while ago I have gone ahead and applied this workaround for now as it seems fine to me and nobody is jumping up to fix the core issue. Can revisit later.