[hatari-devel] spec512 using blitter on STE

Eero Tamminen eerot at users.berlios.de
Fri Jan 29 22:13:40 CET 2010


Hi,

On Sunday 10 January 2010, npomarede at corp.free.fr 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.
>
> The problem is now fixed ; it was due to reading $ff8209 while $ff8265 >
> 0, which scrolls the screen with prefetching. In that case, the shifter
> starts reading data 16 pixels earlier in the left border than the usual
> position, which means we should add 8 bytes to the content of $ff8209 to
> get the same result (it is considered to be a bad practice to read
> $ff8209 on STe while scrolling is used to get in synch with the shifter,
> but as it was used by this demo, we have to support it)

There's something strange with the demo.  At the bottom of the normal
screen (not on borders), there's an area of screen where the scrolltext
never shows, it disappears while it's on that part of screen.

Sometimes the scrolltext on the border seems to lose sync for a while
and the text looks like two display frames were overlapping.

See the attached screenshot.


> BTW Anders, this demo seems to use the same left/right border removal
> (224 bytes) as the one you used in the dhs demos : hi/lo is at cycle
> 504/4 and there's no stabilizer.

All screens in "More or Less Zero" and "Cernit Trandafir" seem now to
be offset to the right.


	- Eero
-------------- next part --------------
A non-text attachment was scrubbed...
Name: epss.png
Type: image/png
Size: 5488 bytes
Desc: not available
URL: <https://lists.berlios.de/pipermail/hatari-devel/attachments/20100129/acece4cf/attachment.png>


More information about the hatari-devel mailing list