[hatari-devel] Killing impact screen problem : I've found the problem

Eero Tamminen eerot at users.berlios.de
Wed Feb 3 21:31:01 CET 2010


Hi,

On Wednesday 03 February 2010, Laurent Sallafranque wrote:
> I've found the problem about Killing impact screen.
> It displays garbage.
>
> The problem is linked to address $ff8265 (Horizontal scroll register)
> which is not 0.
>
> In this case, the bitplanes are not correct.
>
> I've tried to modify the value of " fvram_column " in the
> Videl_bitplaneToChunky call.
> I've added 2.
>
> + Videl_bitplaneToChunky( fvram_column +2, vbpp, color );
>
> With this, hatari displays wrong (of course) because the 4 bitplanes are
> shifted.
> But in killing impact (in the game), the 4 bitplanes display correctly
> (horizontal scroll register is not 0).
> The main menu picture displays wrong (scroll register =0) which is OK.
>
> fvram_column comes from     "Uint16 *fvram = (Uint16 *)
> Atari2HostAddr(atariVideoRAM);"
>
> #define Atari2HostAddr(a) (&STRam[a])
>
>
> I don't think that adding something like the following patch is a good
> idea:
>
> if (hscrolloffset !=0)
>    fvram +=2;
>
> Perhaps "atariVideoRAM" is the problem too ?

You can look into Video_CopyScreenLineColor() in video.c how it does STE HW
scrolling.  Maybe Videl code isn't taking into account everything doe in 
there?

(I guess in the Videl case you can ignore the border handling code)

Nicolas?


> Any idea of how to correct this correctly.

I also wonder whether we really need always to use Videl drawing routines:
       /* Now draw the screen! */
        if (ConfigureParams.System.nMachineType == MACHINE_FALCON 
&& !bUseVDIRes)
        {
                bScreenChanged = VIDEL_renderScreen();
        }

Couldn't we on Falcon & TT use the ST/STE screen rendering when
using ST/STE screen mode on them?  Those drawing routines handle
scrolling etc fine.


	- Eero



More information about the hatari-devel mailing list