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

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

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


	- Eero