|システムコア||重要 (ゲーム)||解決済み||修正済み||2013-11-02 09:32||2014-08-12 07:10|
|セット||Systems using M6809 with M6809_HOLD_LINE|
|詳 細||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.
|再現手順||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.