Hi,
On tiistai 20 tammikuu 2015, Nicolas Pomarède wrote:
I found the problem, there's a bug in the demo, some MFP registers are
not correctly saved at the start of the demo, and when they're restored
at the end of the dot tunnel, this causes the last call to timer A to
jump at a non existing address.
From what I see, there's a race condition that might explain it doesn't
happen on real STE, but I haven't seen yet where's the difference is
between STE and latest Hatari (haven't tried Hatari 1.7, maybe it still
worked)
Just in case you have time, could you try "hg bisect" to see which
commit triggered this ?
changeset: 4358:aed047c66614
user: Nicolas Pomarede
date: Sun Mar 03 23:03:28 2013 +0100
summary: When an MFP interrupt happens, a delay of 4 cycles is needed
before the CPU receives it
Your comments in mfp.c say following of the change:
------------------------
2013/03/01 [NP]
When MFP_IRQ goes from 0 to 1, the resulting signal is visible
to the CPU only 4 cycles later (fix Audio Artistic Demo by
Big Alec and the games Super Hang On, Super Monaco GP, Bolo).
...
Important timing note : when the MFP's IRQ signal is set, it's visible
to the CPU only 4 cycles later.
Instead of using CycInt_AddRelativeInterrupt to simulate this 4 cycles
delay, we use MFP_DelayIRQ to delay the exception processing after
the next instruction instead of the current one (as an instruction
takes at least 4 cycles, we get the expected result without using
an additional internal timer).
------------------------