Viewing Issue Advanced Details
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 sms.cpp
Version 0.154 Fixed in Version 0.161 Build Normal
Summary MESS-specific 05721: sms, smspal: Failed on "SMS VDP Test"
Description SMSVDPTest-SMS-1.31 ->

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 ...... ...... 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 !)
Regression Version
Affected Sets / Systems sms, smspal
Attached Files
There are no relationsihp linked to this issue.
User avatar
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():

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.
User avatar
Justin Kerk
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.