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)|
|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|
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.
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|
|Affected Sets / Systems||Systems using M6809 with M6809_HOLD_LINE|
|There are no relationship linked to this issue.|
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.