[hatari-devel] MFP problem with Bolo
npomarede at corp.free.fr
npomarede at corp.free.fr
Sat Feb 13 20:06:51 CET 2010
On Sun, 7 Feb 2010, Thomas Huth wrote:
>
> Hi Nicolas!
>
> I wanted to play the breakout game "Bolo" today (one of the games that
> I owned when I was a child...), but there seems to be a problem with
> the MFP emulation... Right before the first level starts, it hangs
> forever in this loop here:
>
> 0002b15e: 13c1 ffff fa23 1039 ffff MOVE.B D1,$fffffa23
> 0002b164: 1039 ffff fa23 b001 66f0 MOVE.B $fffffa23,D0
> 0002b16a: b001 66f0 4e75 41f9 0002 CMP.B D1,D0
> 0002b16c: 66f0 4e75 41f9 0002 b060 BNE.B #$fffffff0 == 0002b15e (TRUE)
>
> D1 contains the value 0xff. Seems like the Timer C counter never
> reaches the value 0xff, it seems to be reloaded with the value 0xfe
> instead once it has expired...
> The game works fine when I manually break this loop, so this seems to
> be the only problem. Could you maybe have a look when you've got some
> spare time?
>
> Regards,
> Thomas
>
[cc'ing this to devel list, to keep track of the issue]
Hello,
I remember this game too, one of the very first one for monochrome screen,
very fine gfx at this time.
I gave this one a (deep) look, and this is a very vicious problem.
In fact it seems that when TCDR is at 01 and is decremented (which will
triger the interrupt) then TCDR is reloaded with $ff *before* the
interrupt in $114 is called by the cpu (else, the routine in $114 takes
approx 800 cycles, which is superior to the 652 cycles to decrement TCDR
so it's impossible to read $ff after the RTE).
So, the only explanation is that fffa23 is read with $ff just before the
68000 interrupt.
This goes in the same category as audio art by big alec and super hang on :
the mfp is running asynchronously to the 68000 and there seems to be a
delay when mfp data reg goes to 0 before the int request is sent to the
68000 (in Hatari this is immediate, hence the problem). During this delay,
the cpu has the time to run one instruction, which will allow to read
$fffa23 with $ff.
One solution would be to delay all mfp ints to the next cpu instruction,
but this might broke some demos that rely on very precise timings (but if
it's how it works on real hardware, then it's the way to go anyway).
Marked on my todo list, I will try to write some code to measure this
precisely on a real ST.
Regards
Nicolas
More information about the hatari-devel
mailing list