Re: [hatari-devel] Hatari & physbase/$ff820x (Videl)

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On tiistai 21 tammikuu 2014, Nicolas Pomarède wrote:
> Le 21/01/2014 18:41, Douglas Little a écrit :
> ...
> 
> > I suppose this is useful in a way, because it exaggerates tearing that
> > would exist on real HW, but be either invisible or much less visible,
> > so more likely to get noticed and fixed. But OTOH, if this is used to
> > optimize away dead time in a game loop, it requires special handling
> > by the programmer to treat Hatari differently.
> > 
> > If anyone is able to correct or confirm the above, I would appreciate
> > the input.
> 
> Hello
> 
> I haven't look at the videl code, but I guess it the same as the STF/STE
> code.
>
> In that case, destination (emulated) screen is built one raster at a
> time ; on every HBL, we convert 1 line pointed by the video address to
> the internal bitmap image used by SDL.

No, the conversion is done in single step in Videl emulation, that's
why rasters don't work with it.

I don't know whether that happens before or after VBL interrupt
handler, but I would assume the screen blit to happen at same point
it happens on ST side...?

Videl (C++) code was ported from Aranym to Hatari by Thomas with minor
fixes by me and later improvements by Laurent.


	- Eero

> As you say, depending on where the cpu is currently writing in the
> "video ram" allocated to the screen, tearing may or may not happen, with
> possibly different result than on real HW (especially if the cpu if
> writing in RAM ahead of the video beam or not).
> 
> It's kinda hard to fix for now, ideal solution would be to check on
> every write to RAM if the RAM location overlaps with the current beam
> position, to simulate a screen that is rendered pixels by pixels, as if
> an electron beam was also doing it in Hatari (when current write
> location doesn't overlap with the screen memory, you can speed up things
> by rendering a whole line at once).
> 
> Some STF demos (GEN4 Demo by ULM for example) show a tearing in the
> middle of the screen because of this, as it uses a single video buffer
> and write in it at the same time that the shifter is reading it.
> 
> Nicolas