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

Laurent Sallafranque laurent.sallafranque at free.fr
Thu Feb 4 22:18:05 CET 2010


This little patch seems to correct the display problem.
I'm not sure at all if this is correct in every case or only a bad hack 
for Killing impact.

I would need to find some more programs with $ff8265 different of 0.

diff -r e38d8fda585c src/falcon/videl.c
--- a/src/falcon/videl.c        Wed Feb 03 23:39:39 2010 +0200
+++ b/src/falcon/videl.c        Thu Feb 04 22:14:31 2010 +0100
@@ -440,6 +441,7 @@
        if (hscrolloffset) {
                /* Yes, so we need to adjust offset to next line: */
                nextline += vbpp;
+               fvram += 10;            /* is this correct ? fix killing 
impact */
        }

        /* Center screen */
@@ -699,6 +701,7 @@
        if (hscrolloffset) {
                /* Yes, so we need to adjust offset to next line: */
                nextline += vbpp;
+               fvram += 10;            /* is this correct ? fix killing 
impact */
        }

        /* Integer zoom coef ? */




Does anybody knows if address $ff8264 is also used on falcon for 
hardware scroll as it is on STE ?

Regards,

Laurent



npomarede at corp.free.fr a écrit :
> On Wed, 3 Feb 2010, Laurent Sallafranque wrote:
>
>> I think more and more about rewriting the VIDEL code.
>> I thought about doing it the other way.
>> I would prefer to isolate all the video functions in Videl.c and link
>> them via iomemtabFalcon.c.
>>
>> I'd have to rewrite some ST video code, but video.c and videl.c would be
>> totally separated.
>> (I did this for crossbar code, I've rewritten every address, also the ST
>> addresses are remapped in crossbar.c).
>>
>> Like this, it would be easier to debug and maintain videl specific code
>> and there's no risk to use some "ST code" and add in it : "if (machine
>> == FALCON)" tests.
>>
>>
>> Do you agree with this ?
>
> Yes, I also think that as videl is really different from the ST/STE 
> shifter, it deserves to have its own source file.
>
> STF/STE video emulation is rather stable, and nearly as complete as it 
> could be (some small issues reamin). Having a separate file for videl 
> would prevent regressions in STF/STE mode.
>
> As this requires a lot of work to make a working videl model, adding 
> some code to video.c to create the necessary videl binding and then 
> putting all videl code in a dedicated file would be better (as a first 
> step, I think we could even duplicate some code from video.c in 
> videl.c if this helps ; once all issues are fixed, it will be time to 
> merge again some common concepts/routines if needed)
>
>
> Nicolas
>
>
>
>




More information about the hatari-devel mailing list