[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