03674: tgm2, tgm2p: MAME boots the game faster than the PCB.

ID	Category [?]	Severity [?]	Reproducibility	Date Submitted	Last Update
03674	Misc.	Minor	Always	Jan 18, 2010, 07:59	Mar 14, 2010, 11:15

Tester	colour_thief	View Status	Public	Platform	MAME (Official Binary)
Assigned To		Resolution	Open	OS	Windows Vista/7 (64-bit)
Status [?]	Confirmed			Driver	psikyo/psikyosh.cpp
Version	0.136u1	Fixed in Version		Build	Normal
		Fixed in Git Commit		Github Pull Request #

Summary	03674: tgm2, tgm2p: MAME boots the game faster than the PCB.
Description	After the rom check screen, MAME and the PCB appear equal in speed. However for the brief bootup period before the rom check screen, MAME is faster than the real hardware by about 50%. The following counts show the delay between the service menu and the rom check screen. MAME, via -writeavi 77 frames PCB, via direct video capture* 113 frames (trial 1) 115 frames (trial 2) PCB, via Zi6 video camera in 60fps mode 114 frames (trial 1) 115 frames (trial 2) 111 frames (trial 3) *My video capture device is designed for NTSC signals and has been known to occasionally skip some frames recording arcade games.
Steps To Reproduce	Go to the service menu and select reset. Start counting frames after the service menu text disappears. Stop counting the frame before the rom test text appears.
Additional Information	I realize there could probably be a bug report like this for half the games in MAME, but I went through the trouble of documenting what the hardware was like so I thought I'd throw it up anyways.
Github Commit

Flags	Verified with Original
Regression Version
Affected Sets / Systems	tgm2, tgm2p

Attached Files	fastboot.mp4 (274,186 bytes) Jan 18, 2010, 07:59

No.05532 Haze Senior Tester Jan 18, 2010, 14:18	It probably comes down to wait states, cache speed, and other more complex CPU related issues. For newer CPUs 100% accurate timing isn't really a realistic prospect as they're several magnitudes more complex in their internal operation than 'simple' CPUs like the z80. It's a bug, and it's worth documenting, but the chances of it being fixed properly are minimal at best sadly.
No.05535 Tafoid Administrator Jan 18, 2010, 14:38	Auuugh, forgot about wait states..
No.05539 colour_thief Tester Jan 18, 2010, 16:04	Yep, I figured there would be something like wait states and whatnot, and is unlikely to be fixed in the short term. Probaly useful to have a reference case if ever MAME gets that ambitious though. Incidentally, the power on pattern in MAME (black and white gradients before the rom check) looks very orderly and differs from the PCB. Is that significant? The PCB doesn't look exactly the same every time, but it is approximately the same every time. You can see it in the attached video.
No.05879 Haze Senior Tester Mar 14, 2010, 11:15 edited on: Mar 14, 2010, 16:36	No, it shouldn't. It is a bug, even if it won't be fixed. To expand on the issue, timing DO matter, even on modern systems, even if they're nearly impossible to get right. It would be very easy to write a routine which fails completely on MAME because the timings are wrong, but works just fine on real hardware. Just look at the recent work being done on the SNES, you need things to be accurate within the region of a few cycles for some game to work, there is no room for error in the timings at all! Anything that sets a timer for an interrupt could potentially break if the game ends up executing too much code before it happens, but the developers didn't check for that because it always works on real hardware. There are many reasons why accurate timing is important, and while it might not break any of the Psikyo games in a significant way, and is likely to be nearly impossible to get right for complex systems it's definitely NOT an issue that can just be ignored if you want to claim that MAME strives to be an accurate emulator. Slight timing bugs are the reason things like the Mode Select screen in Assault Plus are broken too. It becomes a far more significant issue with multi-cpu systems. So.. there is nothing 'stupid' about this report, it's an accurate report with real hardware reference. Please just get on with what you're good at doing instead.