[hatari-devel] spec512 using blitter on STE

npomarede at corp.free.fr npomarede at corp.free.fr
Sun Jan 10 00:28:44 CET 2010


On Sat, 9 Jan 2010, npomarede at corp.free.fr wrote:

> On Sat, 9 Jan 2010, Jean-Baptiste Berlioz wrote:
>
>> Yes i'm still around, and ready to fix blitter timings.
>> 16 cycles, that's huge, i'd like to see the source code, just before the
>> blitter was started.
>
> Maybe those 16 cycles are the results of 4 * 4 cycles ? I don't see any
> io accesses with wait state. Or maybe Hatari is synchronising with ff8209
> 16 cycles too late (but this would be a rare case).
>
> I will try to compare with Steem's timing to see at which point we don't
> get the same result, to be sure the problem is really blitter's related.

Well, it turns out that the problem was not related to blitter's timing, 
but to a wrong calculation of $ff8209 (used to synchronise with the 
shifter) when STE's left border is extended by 16 pixels.

This is now fixed (see 'intro' and 'direct color zoomer' in Atari STe 20 
year megademo)


Thomas wrote :

> Could that be related to the problem in the EPSS demo? That demo fails
> to open the right border because there is also a blitter access between
> the left and right border. The offset between wrong and right access
> also seems to be 16 cycles if I got that right...

Not directly, because they don't use the same 16 pixels trick (the screen 
is 160 bytes per line), but by comparing with Steem I can see that 
Video_CalculateAddress doesn't seem to be correct and return a value that 
is 8 bytes too low (which gives a 16 cycles shift).
I will try to look at this too, as this doesn't seem to be a blitter 
problem in fact.


Nicolas



More information about the hatari-devel mailing list