Viewing Issue Advanced Details
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
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.
Flags Verified with Original, Verified with Code
Regression Version
Affected Sets / Systems Systems using M6809 with M6809_HOLD_LINE
Attached Files
There are no relationsihp linked to this issue.
User avatar
Nathan Woods
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.