- --
Viewing Issue Advanced Details
ID | Category [?] | Severity [?] | Reproducibility | Date Submitted | Last Update |
---|---|---|---|---|---|
05915 | Graphics | Major | Always | Apr 8, 2015, 03:17 | Apr 24, 2018, 13:13 |
Tester | trebor | View Status | Public | Platform | |
Assigned To | Resolution | Fixed | OS | Windows Vista/7/8 (64-bit) | |
Status [?] | Resolved | Driver | |||
Version | 0.160 | Fixed in Version | Build | 64-bit | |
Fixed in Git Commit | Github Pull Request # | ||||
Summary | 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. | ||||
Github Commit | |||||
Flags | |||||
Regression Version | |||||
Affected Sets / Systems | a7800 [ddragon], [ikari], [kungfum], [bonq], clones and Frogger | ||||
Attached Files
|
MESS0160-KUNGFUMASTER.png (281,857 bytes) Apr 8, 2015, 03:17 Uploaded by trebor
| ||||
MESS0160-IKARIWARRIORS.png (584,732 bytes) Apr 8, 2015, 03:18 Uploaded by trebor Ikari Warriors - Colors are inverted in several places
| |||||
MESS0160-DOUBLEDRAGON.png (224,948 bytes) Apr 8, 2015, 03:19 Uploaded by trebor Double Dragon - Line Graphic Corruption between the status and playfield.
| |||||
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.
| |||||
MESS0160-FROGGIE.png (436,524 bytes) Apr 8, 2015, 03:22 Uploaded by trebor Froggie - Line graphic corruptions in the status area.
| |||||
Relationships
Notes
8
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. |
---|---|
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. |
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. |
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. |
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. |
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. |
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. |
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? |