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

[Laurent Sallafranque <laurent.sallafranque@xxxxxxx>]

Hi,


Yes Doug, there's still some work to do into hatari ;)

The videl is rendered in one time, every VBL.

The code would need a lot a rewrite, but I haven't changed anything 
because of the big speed difference between Hatari and real Falcon.
I still think there's the general timing of the CPU to solve first (and 
maybe the Videl cycles to access the RAM are are not taken into account 
for now (I think))

Another example of problem is with pinball dream (the upper HUD is in a 
memory area whereas the game is in another area).
The game jumps the hardware register at HBL 80 (or something like that).
But Hatari is not precise enough for this.

I've got a hacked version of hatari for this special case, but it's not 
the way it should be sold.

Maybe one day, we could work together on Hatari and solve all these 
problems to have a good emulator ?

Regards
Laurent


Le 21/01/2014 18:54, Nicolas Pomarède a écrit :
> 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.
>
> 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