Viewing Issue Advanced Details Jump to Notes ]
ID Category [?] Severity [?] Reproducibility Date Submitted Last Update
06281 Crash/Freeze Critical (emulation) Always Jul 5, 2016, 23:18 Aug 4, 2016, 09:42
Tester ballyalley View Status Public Platform
Assigned To Duke Resolution Fixed OS Windows Vista/7/8 (64-bit)
Status [?] Resolved   Driver
Version 0.175 Fixed in Version 0.176 Build 64-bit
Summary MESS-specific 06281: astrocde [280zzap]: 280Zzzap/Dodgem Cartridge Resets
Description This is my first MAME bug report. I hope I have provided enough information to fix the issue.

The 2K "280 ZZZap / Dodgem" cartridge (file 280zzap) for the Bally Arcade/Astrocade no longer works in MAME. I just tested it with mame0175b_64bit using Windows 7. This cartridge doesn't act correctly-- but it USED to work fine in early versions of MESS. I can start "280 ZZZap" from the Astrocade menu as normal, and as before, it still works; I can play the game. I pressed reset (F3) and was returned to the main menu (as expected). Then I chose "Dodgem" and I selected my "Race Time" as normal. The game's start screen is quickly drawn, and then the emulator resets to the cartridge's main menu.

The last time that Dodgem worked was in MESS 0.123. An update to the astrocade driver was made for the next release of MESS 0.124 (March 2008). The update to the Astrocade driver is described as:

- [ASTROCDE] Removed the MESS specific implementation of the video hardware
  in favor of the more accurate MAME version. Also fixed the I/O ports
  defintion which improves the sound a lot. [Dirk Best]

I posted about this issue on the Bally Alley Yahoo groups in September 2013. A member of the group (Richard Degler) sent me a private email with an explanation of what is happening in the emulator what the Astrocade driver fails to work correctly.

Hopefully, Richard's information will help someone figure-out what is causing the issue. Here is what I received from Richard:

If you're serious about getting MESS fixed for Dodgem, here's where it goes wrong

        LD A,$23 ; set Interrupt register for L23xx
        LD I,A

Setting up this here...
; Interrupt Vectors table
L2330: DW L2334 ; for DODGEM only
L2332: DW L24EA ; for 280 ZZZAP
; DODGEM Interrupt handler
L2334: EX AF,AF' ; [aka DB $08,$D9]
Then later, with Game ID either 0 for 280ZZZap or 1 for Dodgem...
; Jump over ?? entry point
L2493: LD HL,L4FC3 ; "custom time base" byte
        LD BC,$0601 ; reset to 6 and mask CT0 on
        CALL CTIMER ; do a System CALL
        CALL STIMER ; do another System CALL
        LD BC,$3246
        LD A,(L4F5C) ; read Game ID
        AND A
        JR Z,L24AB ; (+$03) skip if 280 ZZZAP
        LD BC,$30A0 ; on DODGEM only
        OUT (INFBK),A ; &(13)=regB for INterrupt FeedBacK
        LD A,C
        OUT (INLIN),A ; &(15)=regC for write INterrupt LINe
        POP IX
        EX AF,AF'
If you set a "bp 24ab" and "F12" to Run and select 1 for 280ZZZAP then "Run to Next Interrupt - F7" you can see that the interrupt goes to 24EA as it should, but select 2 for DODGEM instead then "F7" it goes off to D908 which, if you do the math, means it used L2334: as a vector NOT the targeted routine.
The WZ "register" in the left column not only shows this final Interrupt Routine address, but if you step thorough using F10 rather than F7 you can see it shows the last byte OUTput (x 256) and the Port Number PLUS one, which seems like a bug in the display rather than the actual Port it wrote to.

That is the full explanation that Richard sent to me.
Steps To Reproduce
Additional Information
Regression Version 0.124
Affected Sets / Systems astrocde [280zzap]
Attached Files

-  Notes
User avatar
Jul 8, 2016, 16:53
MAME's implementation of Astrocade scanline interrupts appears to be at fault. At the point where $30 is written to INFBK in the above excerpt, a scanline interrupt has already been triggered with $34 as the stored vector. The very first scanline interrupt after system reset also gets triggered before INFBK is even written, which once again makes the Z80 jump into unmapped memory.
User avatar
Jul 16, 2016, 18:01
The two issues have the following causes:

1. The initial interrupt happens because the interrupt line register is initialized with 0x00, this means it triggers as soon interrupts are enabled at line 0. Initializing this to 0xff fixes that.

2. Dodgem rewrites the interrupt line register from c8 (200) to a0 (160). This means that an interrupt happens while the previous interrupt is still active, because interrupts are only cleared after VBLANK. The old MESS implementation cleared interrupts after each line, which means the issue didn't occur there. I've fixed it by clearing the interrupt once the interrupt related registers are written. However, I don't know if this is how it works on real hardware. More tests would be needed there.
User avatar
Jul 16, 2016, 18:56
The committed fix also works for Gorf, a well-known edge case.
User avatar
Aug 1, 2016, 20:32
In MAME 0.176, Dirk Best wrote about this fix: "Initialize interrupt line register with 0xff (prevents initial bogus interrupts) and clear active interrupts when an interrupt related register is written (tests would be good to confirm how this works on real hardware)."

I'd be willing to confirm how this works on real Bally Arcade/Astrocade hardware if someone can explain how to proceed with the test. Would it require special hardware testing equipment?
User avatar
Aug 4, 2016, 09:42
You need the ability to run your own software on the Astrocade and then write a test which tests the interrupt behaviour.