[hatari-devel] Killing impact screen problem : I've found the problem
Laurent Sallafranque
laurent.sallafranque at free.fr
Thu Feb 4 22:25:02 CET 2010
Forget it.
It's totally wrong ;)
I've tested with "willi's adventure"
I continue to search and try to understand.
Regards,
Laurent
Laurent Sallafranque a écrit :
> 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
>>
>>
>>
>>
>>
>
> _______________________________________________
> hatari-devel mailing list
> hatari-devel at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/hatari-devel
>
>
>
More information about the hatari-devel
mailing list