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

npomarede at corp.free.fr npomarede at corp.free.fr
Wed Feb 3 22:27:48 CET 2010


On Wed, 3 Feb 2010, Eero Tamminen wrote:

>> 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?

Hello,

I really don't have any clue on how the falcon memory is working. Sure 
that in ST/STE mode, we can use the same routs are those for plain STE in 
video.c/screen.c but for the problem reported by laurent, I think it's 
falcon specific.

On STE low res, using hscroll requires 8 more bytes per line (due to 
prefetching), but I don't know if similar adjustements are needed on 
falcon.


>
>
>> 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.

Yes, maybe some "shortcuts" could be used to call STE screen functions, 
but does someone know how to determine when videl is in such mode ?

Nicolas




More information about the hatari-devel mailing list