05350: Systems using M6809 with M6809_HOLD_LINE: CWAI doesn't acknowledge interrupts while polling for them

ID	Category [?]	Severity [?]	Reproducibility	Date Submitted	Last Update
05350	Core	Critical (emulation)	Always	Nov 2, 2013, 00:32	Aug 11, 2014, 22:10

Tester	Saurus	View Status	Public	Platform	MAME (Self-compiled)
Assigned To	hap	Resolution	Fixed	OS	Linux
Status [?]	Resolved			Driver
Version	0.150	Fixed in Version	0.155	Build	Normal
		Fixed in Git Commit		Github Pull Request #

Summary	05350: Systems using M6809 with M6809_HOLD_LINE: CWAI doesn't acknowledge interrupts while polling for them
Description	The CWAI implementation in base6x09.ops calls get_pending_interrupts() to poll for new interrupts. Instead, check_pending_interrupts() should be used afaik. Using get_pending_interrupts() misses to acknowledge the interrupt request and re-starts the IRQ routine immediately after RTI (where IRQ is finally acknowledged). Furthermore, I'd propose to "@eat(7)" cycles in INTERRUPT_VECTOR to account for all overhead cycles when an interrupt is triggered and new vector is fetched on this CPU.
Steps To Reproduce	I noticed the issue on rocnrope where the gameplay demo in attract sequence is too short: The player dies on the lower right platform, whereas he's supposed to die on the fourth platform. This was fine with older mame versions prior to 0148u2 when the m6809 code was rewritten. With the two modifications described above, rocnrope attract mode is back to the old behavior and also matches my rocnrope hardware again.
Additional Information	The current strategy of acknowledging interrupts for m6x09 is not exactly in line with the real hardware. The comment for check_pending_interrupt() in m6809inl.h nails it down pretty well: // check_pending_interrupt() will also invoke the IRQ // callback for FIRQ and IRQ interrupts // // I'm not sure why this is necessary; neither the 6809, 6309 // nor (presumably) Konami had any interrupt acknowledge lines so // it isn't clear what this is reflecting On rocnrope for example, the software acknowledges the IRQ by writing 0 to $8087. This is currently not modeled in rocnrope.c driver (and probably in other drivers using M6809). My conclusion is that all such drivers would need an update to clear the interrupt line on board level when the software acks the IRQ (typically on Konami games like rocnrope, gyruss). Once this is in place, the whole quirky check_pending_interrupt() story in the M6809 CPU would finally become obsolete.
Github Commit

Flags	Verified with Original, Verified with Code
Regression Version
Affected Sets / Systems	Systems using M6809 with M6809_HOLD_LINE

Attached Files

No.09962 Bletch Developer Nov 9, 2013, 15:58	This is an issue caused by incorrect usage of the m6809 core in rocnrope and other drivers. The M6809 had no notion of interrupt acknowledgement. However, rocnrope and other drivers incorrectly use HOLD_LINE because in practice the 6809 core implemented interrupt acknowledgement (as per your comment). The proper fix would be for all drivers using HOLD_LINE on a 6x09 to be changed to use SET_LINE and CLEAR_LINE when appropriate. When all drivers are transitioned, we could eliminate interrupt acknowledgement in the 6x09 core.

No.09962

Bletch

Developer

Nov 9, 2013, 15:58

This is an issue caused by incorrect usage of the m6809 core in rocnrope and other drivers.

The M6809 had no notion of interrupt acknowledgement. However, rocnrope and other drivers incorrectly use HOLD_LINE because in practice the 6809 core implemented interrupt acknowledgement (as per your comment). The proper fix would be for all drivers using HOLD_LINE on a 6x09 to be changed to use SET_LINE and CLEAR_LINE when appropriate. When all drivers are transitioned, we could eliminate interrupt acknowledgement in the 6x09 core.