06281: astrocde [280zzap]: 280Zzzap/Dodgem Cartridge Resets

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
		Fixed in Git Commit		Github Pull Request #

Summary	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] EXX ... 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 L24AB: LD A,B OUT (INFBK),A ; &(13)=regB for INterrupt FeedBacK LD A,C OUT (INLIN),A ; &(15)=regC for write INterrupt LINe POP IX EXX EX AF,AF' EI RET 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
Github Commit

Flags
Regression Version	0.124
Affected Sets / Systems	astrocde [280zzap]

Attached Files

No.12914 AJR Developer 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.
No.12947 Duke Developer 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.
No.12949 AJR Developer Jul 16, 2016, 18:56	The committed fix also works for Gorf, a well-known edge case.
No.13025 ballyalley Tester 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?
No.13032 Duke Developer 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.