Viewing Issue Advanced Details
ID Category [?] Severity [?] Reproducibility Date Submitted Last Update
03712 Graphics Minor Always Feb 5, 2010, 12:47 Dec 18, 2018, 02:34
Tester M.A.S.H. View Status Public Platform MAME (Self-compiled)
Assigned To Resolution Open OS
Status [?] Confirmed Driver cischeat.cpp
Version 0.136u2 Fixed in Version Build
Summary 03712: f1gpstr2: Garbled graphics in attract mode
Description There is garbled graphics on the right side in the attract mode
since MAME 0.125u3. See animated GIF!
Steps To Reproduce
Additional Information
Flags Verified with Original
Regression Version 0.125u3
Affected Sets / Systems f1gpstr2
Attached Files
gif file icon f1gpstr2.gif (309,773 bytes) Feb 5, 2010, 12:47
zip file icon (124,534 bytes) Feb 5, 2010, 19:40
There are no relationship linked to this issue.
User avatar
Senior Tester
Feb 5, 2010, 13:38
The whole driver needs a rewrite really.

It runs at 30fps, it should probably be 60 with different interrupt generation.

There are more unknown / unused ROMs on most games than used ones.

There are heavy graphic / priority glitches in many games (big run has severe priority issues, wild pilots has bad flickering etc.)
User avatar
Feb 5, 2010, 16:28
edited on: Feb 5, 2010, 16:28
The procedure for game with games which are flagged (not 100% graphics emulation) is to have a source or video from the original game or pcb. But, given this is an obvious regression from a previous mame version, I'll confirm and allow the report.
User avatar
Senior Tester
Feb 5, 2010, 19:41
I have fix the gfx problem. It was the changes in src\emu\cpuexec.c. Please download
the attached file "" here. It has the fix in it and
a compare tool for the file src\emu\cpuexec.c from MAME 0.125u2 and u3.
User avatar
Senior Tester
Feb 5, 2010, 19:51
edited on: Feb 5, 2010, 19:54
uh I don't think you should be changing core cpuexec functions unless you know what you're doing or why it was changed in the first place.
User avatar
Senior Tester
Feb 5, 2010, 20:46
I don't know the reasons of the changes in cpuexec.c at the time but looking at the fix it looks like it's a problem of interrupts per frame. If I'm not wrong sprites are updated on every vblank so with a correct implementation of interrupts the problem could go away. Surely(?) the bug was already lying in the driver and changes in core made it appear.
User avatar
Senior Tester
Feb 5, 2010, 21:18
that would be more logical. the iloops stuff is deprecated anyway afaik.and hacking the core to fix a driver problem is not a fix at all.
User avatar
Senior Tester
Dec 10, 2018, 15:42
edited on: Dec 10, 2018, 15:46
Recorded from pcb. This is how it should look like:

This is how it looks in mame (tested in current version, 0.204):