Viewing Issue Advanced Details
ID Category [?] Severity [?] Reproducibility Date Submitted Last Update
05915 Graphics Major Always Apr 8, 2015, 03:17 31 days ago
Tester trebor View Status Public Platform
Assigned To Resolution Fixed OS Windows Vista/7/8 (64-bit)
Status [?] Resolved Driver a7800.cpp
Version 0.160 Fixed in Version Build 64-bit
Summary MESS-specific 05915: a7800 [ddragon], [ikari], [kungfum], [bonq], clones and Frogger : Major graphic corruption in several games
Description Several games, including: Double Dragon, Ikari Warriors, Kung-Fu Master, BonQ, Froggie, have graphic corruptions under 0.160 that are not present with 0.159; all games display perfectly with the 0.159 release.

Please note, this is NOT due to r36463 [http://mame.dorando.at/svn/?rev=36463]. If you take the a7800.c source file from 0.159, and drop it into the 0.160 sources, the same exact issues occur.

It is not Windows specific as the same results are experienced on an upgraded Linux Mint install. It is not specific to NTSC either, as the same corresponding PAL games encounter the same problems.
Steps To Reproduce Load and run any of the aforementioned games:

-Double Dragon - Line Graphic Corruption between the status and playfield.
-Ikari Warriors - Colors are inverted in several places.
-Kung-Fu Master - Major graphic corruptions in many places.
-BonQ - Anytime the number "5" appears in the player's score, there is a graphic artifact above it.
-Froggie - Line graphic corruptions in the status area.
Additional Information Again, bugs occur under 0.160 with either the a7800.c driver file from 0.160 source, or even if you drop in the a7800.c driver file from 0.159 source into 0.160.
Flags
Regression Version
Affected Sets / Systems a7800 [ddragon], [ikari], [kungfum], [bonq], clones and Frogger
Attached Files
png file icon MESS0160-KUNGFUMASTER.png (281,857 bytes) Apr 8, 2015, 03:17 Uploaded by trebor
trebor
png file icon MESS0160-IKARIWARRIORS.png (584,732 bytes) Apr 8, 2015, 03:18 Uploaded by trebor
Ikari Warriors - Colors are inverted in several places
trebor
png file icon MESS0160-DOUBLEDRAGON.png (224,948 bytes) Apr 8, 2015, 03:19 Uploaded by trebor
Double Dragon - Line Graphic Corruption between the status and playfield.
trebor
png file icon MESS0160-BONQ.png (152,397 bytes) Apr 8, 2015, 03:21 Uploaded by trebor
BonQ - Anytime the number "5" appears in the player's score, there is a graphic artifact above it.
trebor
png file icon MESS0160-FROGGIE.png (436,524 bytes) Apr 8, 2015, 03:22 Uploaded by trebor
Froggie - Line graphic corruptions in the status area.
trebor
Relationships
related to 05918Resolved Games using at least "Exidy SFX+PSG" device: Most of the games in the driver the sound is corrupt. 
Notes
8
User avatar
No.11587
trebor
Tester
Apr 8, 2015, 10:27
Found the source of the regression -

r36233 - m6502: Fix icounting [Peter Ferrie]

http://mame.dorando.at/svn/?rev=36233

Reverting that change fixes all regressions.

Please let me know if this is something that I must submit to have reverted, or will be handled otherwise.
User avatar
No.11592
AWJ
Developer
Apr 8, 2015, 16:43
"Find the commit where the regression happened and revert it" is not how we fix bugs in MAME.
User avatar
No.11593
trebor
Tester
Apr 8, 2015, 17:03
Thank you for the follow-up. I was offering up exactly where the problem occurred and volunteered to submit the change (Which I did via email to MAME Code), if that was seen as the way to handle this specific bug and modification.

Obviously, all regressions/bugs are not handled that way, but certainly there is and has been precedent where that has transpired. It did not mean to imply that's how all bugs are fixed in MAME(MESS). This issue, evidently, is falling under the, "handled otherwise" statement.
User avatar
No.11613
trebor
Tester
Apr 17, 2015, 02:26
A "brute force fix for m6502-related regressions" was applied... http://mame.dorando.at/svn/?rev=37151 ...fixing issues with the Exidy driver... http://mametesters.org/view.php?id=5918 ...that is(was) also having problems with the aforementioned m6502 icounting fix.

Not sure how much (if anything) can be gleaned from it, in light of the problems being experience with the a7800 driver; but thought it was worth a mention in case there is any applicable material for any curious or/and able to address the matter.
User avatar
No.11614
Tafoid
Administrator
Apr 17, 2015, 13:02
From what I know of the situation, the model of 6502 was not a standard bog 6502, so this would require either driver level adjustment to correct issues or a specific CPU case added. Just a matter of time for it to happen.
User avatar
No.11615
trebor
Tester
Apr 17, 2015, 23:57
edited on: Apr 18, 2015, 00:00
The difference between the 6502c (also used in later versions of the Atari 8-bit line) and the 6502 was only an external /HALT line, which MARIA does indeed use to stop the 6502c cold, and the new icount code should allow for this.

Additionally, looking through the m6502.txt under the 'docs', it seems that "wait states" is a TO DO feature (Section 11). Evidently, the a7800 driver is broken due to an incomplete implementation.

User avatar
No.11616
AWJ
Developer
Apr 18, 2015, 09:43
The problem is that all that tweaking and adjusting of MARIA DMA timings that you contributed a while back was done based on a bugged 6502 that wasn't actually running cycle-by-cycle, and now that the 6502 is fixed you're going to have to do it all over again.
User avatar
No.11641
trebor
Tester
May 3, 2015, 14:45
edited on: May 3, 2015, 15:20
The exidy and victory drivers still have issues despite the "brute force fix" applied. This includes not only the sound being off for those drivers...
http://mametesters.org/view.php?id=5918

...but also at least one game still completely freezing:
http://mametesters.org/view.php?id=5930

The implementation of values worked excellently with the previous 6502 setting before the "r36233 - m6502: Fix icounting [Peter Ferrie]" update. Those values were not hand tweak/guesses, rather measured directly from hardware:
http://atariage.com/forums/topic/224025-7800-hardware-facts/?p=2983361

Not stating something else may not be amiss here outside of the 6502; however, is there absolute certainty of the "cycle-by-cycle" accuracy of the current configuration/tweak to the 6502?