|Re: [hatari-devel] Spec512 screens with higher CPU frequencies|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
Le 02/03/2019 à 18:15, Thomas Huth a écrit :
Initially, both players start in the same room, and thus both parts of
the screen use the same palette. You've got to move one of the players
to a different room to see the problem: When you move one of the two
players into another room that uses a different palette, each part of
the screen should get a different palette. However, in 32 MHz, the
second part of the screen always has the same (or most of the same)
colors as the first part.
I think the problem might rather be the "CycleEnd >>= nCpuFreqShift" in
Spec512_EndScanLine() ... that looks like it is causing the update to
stop too soon. When I comment it out, the split screen in AlphaWaves
also looks fine again...
I can see the issue after going to another room ; but for me it's more
an unstable timerb interrupt (due to 32 Mhz) than spec512.c itself, as
the game in fact only changes the palette at mid-screen
There were some issues at some point when converting the cycle position
into the current frame into an X/Y position when not using 8 MHz.
I fixed most of them, but that's might be a remaining case, I will look
into this in more detail (probably the X position is odd instead of even
and the code in spec512.c doesn't store the color change)
In all case, that's definitely sthg that should work at any cpu freq,
fixing it in spec512.c might not be the correct fix though, it might be
in video.c when timerb is handled.