| ID | Category [?] | Severity [?] | Reproducibility | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 07016 | Crash/Freeze | Critical (emulation) | Always | Jun 12, 2018, 16:06 | 25 days ago |
| Tester | Kale | View Status | Public | Platform | MAME (Self-compiled) |
| Assigned To | AJR | Resolution | Fixed | OS | Windows Vista/7/8 (64-bit) |
| Status [?] | Resolved | Driver | |||
| Version | 0.198 | Fixed in Version | 0.273GIT | Build | 64-bit |
| Fixed in Git Commit | ca1c02d | Github Pull Request # | |||
| Summary | 07016: astrowar: game resets at start of stage 5 | ||||
| Description | Astro Wars resets itself at start of stage 5, right after drawing the background vertical lines and before showing the boss. | ||||
| Steps To Reproduce |
Reach stage 5 or load attached save state (need to kill stage 4 last enemy). Preferably load it after the POST, save states aren't offcially supported by the game. |
||||
| Additional Information |
Culprit seems to be this snippet:1:09F9: loda,0 $35ad ;reads s2636 portCould be either s2650 or s2636 core bug. Seldomly this doesn't occur, by hitting the last enemy in specific spots? Seems to happen up to version 0.169 |
||||
| Github Commit | |||||
| Flags | |||||
| Regression Version | |||||
| Affected Sets / Systems | astrowar | ||||
|
Attached Files
|
 r.zip (1,191 bytes) Jun 12, 2018, 16:06 Uploaded by Kale | ||||
 0017.png (1,978 bytes) Jun 12, 2018, 16:08 Uploaded by KaleSnapshot of the game prior to reset.
| |||||
 No.15169
kazblox Tester
Jun 12, 2018, 20:22
|
This driver is poor already (among the many things is that video needs a total rewrite to support the actual RAW_PARAMS configuration which is similar to Lazarian), but this does look like a core bug at a glance. Nice catch. |
|---|---|
|
No.15179
AJR Developer
Jun 15, 2018, 15:46
|
I suspect that this might actually be a bad dump. In context, it seems as if the BDRR,3 opcode (FB) ought to be COMR,3 (EB) instead. |
|
No.15337
AJR Developer
Aug 21, 2018, 18:55
|
I've decided to mark one ROM as a bad dump for now, in the hope that it can be redumped and verified. There isn't another dumped set for code comparison purposes, the code performs no self-test (contrary to the "POST" mention in the report), and, given how stupidly difficult the game is to play, I fear it might have actually shipped with this bug. |
|
No.15338
Osso Moderator
Aug 22, 2018, 05:56
|
FWIW I've asked an Italian owner for a redump, he agreed but it won't be in the near future, as he doesn't have access to his games right now. |
 No.22510
hap Developer
26 days ago
edited on: 26 days ago
|
I received another ROM dump, but it looks very suspicious to me, I think it was modified by a previous pcb owner when reprogramming 1980 EPROMs that had gone bad. Suspicious in the sense that only the bad opcode was changed, and changed so much that it can't be flipped bits. It was changed to E4 40. (...) 1:09F3: 06 27 lodi,2 $27 1:09F5: 07 10 lodi,3 $10 1:09F7: BB 86 zbsr *$0006 ; did not appear to change R3 when i checked live disasm 1:09F9: 0C 15 AD loda,0 $35ad ; random number? 1:09FC: E4 80 comi,0 $80 ; compare rand with $80 1:09FE: 19 14 bctr,p $2a14 1:0A00: EB F8 comr,3 *$29fa ; EB F8 MAME + AJR bitflip, *$29fa = $35ad, so it compares R3($10) with rand 1:0A00: E4 40 comi,0 $40 ; E4 40 hack? 1:0A02: 19 08 bctr,p $2a0c 1:0A04: 04 7B lodi,0 $7b 1:0A06: 05 1A lodi,1 $1a 1:0A08: 06 47 lodi,2 $47 1:0A0A: 1B 1A bctr,a $2a26 1:0A0C: 04 A3 lodi,0 $a3 1:0A0E: 05 1A lodi,1 $1a 1:0A10: 06 E7 lodi,2 $e7 1:0A12: 1B 12 bctr,a $2a26 1:0A14: E4 C0 comi,0 $c0 ; compare rand with $c0 1:0A16: 19 08 bctr,p $2a20 1:0A18: 04 53 lodi,0 $53 1:0A1A: 05 19 lodi,1 $19 1:0A1C: 06 A7 lodi,2 $a7 1:0A1E: 1B 06 bctr,a $2a26 1:0A20: 04 3B lodi,0 $3b 1:0A22: 05 19 lodi,1 $19 1:0A24: 06 47 lodi,2 $47 1:0A26: 07 34 lodi,3 $34 So, at the start of the bossfight, it sets up R0,R1,R2 with 4 possible sets of values, based on a random number. current MAME: 50% chance it will crash AJR's bitflip: 25% 25% [43.75% 6.25%](depends on R3) hack ver: 25% 25% 25% 25% |