[hatari-devel] Hatari patches for bitplane conversion
Eero Tamminen
eerot at users.berlios.de
Wed Jul 22 21:43:11 CEST 2009
Hi,
On Wednesday 22 July 2009, Kåre Andersen wrote:
> nFrameSkips is somehow never initialised, add a =0 and everything is
> fine... How can this be different on different platforms?
>
> Mini-patch:
>
> --- hatari-hg-072209/src/video.c 2009-07-22 10:17:27.000000000
> +0200 +++ hatari/src/video.c 2009-07-22 11:47:56.000000000 +0200
> @@ -293,7 +293,7 @@
>
> int STRes = ST_LOW_RES; /* current ST resolution
> */ int TTRes; /* TT shifter
> resolution mode */
> -int nFrameSkips; /* speed up by
> skipping video frames */
> +int nFrameSkips=0; /* speed up by
> skipping video frames */
It's possible that because you explicitly set the variable, it goes to a
different section in the binary (.data instead of .bss)[1], but that should
not have any effect on it's value as globals are automatically zeroed.
(Apple documentation I referred in my earlier mail already stated that
.bss should be zeroed.)
Could you compile video.c with and without this change, diff the resulting
assembly code (with GCC you'd get that with the -S option) and mail
the changes?
In my case the change is following:
----------------
@@ -4253,6 +4253,12 @@
.size STRes, 4
STRes:
.zero 4
+.globl nFrameSkips
+ .align 4
+ .type nFrameSkips, @object
+ .size nFrameSkips, 4
+nFrameSkips:
+ .zero 4
.globl nScreenRefreshRate
.data
.align 4
@@ -4436,7 +4442,6 @@
.local bTTColorsSTSync
.comm bTTColorsSTSync,1,1
.comm TTRes,4,4
- .comm nFrameSkips,4,4
.comm bUseSTShifter,1,1
.comm bUseHighRes,1,1
.comm nVBLs,4,4
-----------------
Once we know where your compiler puts the nFrameSkips variable in BSS,
I could check whether e.g. any of the variables before or after it could be
written in a way that overwrites/corrupts nFrameSkips.
- Eero
More information about the hatari-devel
mailing list