Re: [hatari-devel] "Infinite Live of the Blitter" STE demo doesn't work anymore

[ Thread Index | Date Index | More Archives ]

Le 21/01/2015 20:21, Eero Tamminen a écrit :

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

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).


thanks for pointing this ; this is indeed an important part of the mfp emulation, this 4 cycles delay is involved in some rather tricky code. I need to check, but I think here the irq happens during a rather long blitter operation, which means it should not be delayed by 1 instruction but considered effective as soon as the blitter finishes.

I need to do precise traces of this before, as it could break some currently working programs that were fixed by changeset #4358


Mail converted by MHonArc 2.6.19+