Hatari speed accuracy

[Orion_]

I'm using Hatari 2.4.1 under linux (compiled from hrdb repo)
I'm using the STe mode, and using some blitter in my program.
I use the good old VBL color bar to time my code, and for some reason it doesn't shows up on Hatari.
as if Hatari was executing the code or the blitter at light speed.
the same program on a real STe or on Steem produce the correct behavior and I can see how much VBL time my code takes by changing the color 0 of the palette, but on Hatari, it stays black.
I have activated the options: prefetch emulation and cycle-exact with cache emulation
but it change nothing.
is there any way to get accurate cycle emulation under hatari ?

[Orion_]

I think I found a bug.
When I start hatari with the my default configuration for Falcon, then I load a new config file for a STe setup, I reset the machine -> cycle exact doesn't work
I go into the CPU menu, I change nothing, I reset the machine -> cycle exact work

[Eero Tamminen]

Can you reproduce that issue also with normal Hatari release, and not just with the hrd fork?

[Orion_]

I compiled the lastest 2.5.0 version without hrdb, and it works, so maybe an old bug

[tat]

The latest version of hrdb (0.009) uses the Hatari 2.5.0 codebase, so it might be worth updating to that.

https://github.com/tattlemuss/hatari/re ... rdb-v0.009

[Orion_]

well, I just got the bug on the 2.5.0 version, so I guess it's just randomly happening, I can't reproduce it for sure.
What I do is, I start Hatari with my default hatari.cfg: https://pastebin.com/17bQizRB
Then I press F12, I load this config: hatari_st.cfg https://pastebin.com/wE7sFSKi
Reset the machine, start a program with VBL color 0 timing my code and it doesn't show up.
I reset the machine again, I start the same program again and it show up.

[tat]

Thanks Orion. I managed to reproduce this using your .cfg files.

I can reproduce in the hrdb branch using 2.5.0 Hatari, and in the current Hatari master branch ("v2.6.0-devel")

It seems more obvious when I wait until the GEM desktop has appeared in Falcon mode before hitting F12 and loading the second config. Once booted in STE mode, the ST screen borders look incorrect, despite having "Show Borders" checked in the Atari Screen menu (see screenshot -- there's no side borders for example), and the immediate colour update doesn't occur like you mention -- this PRG is changing the background colour to red to show the CPU usage off a timer C interrupt.

[tat]

I did some debugging on this. I really don't know this area of the Hatari code though.

The non-updating palette seems to be related to the function Spec512_StoreCyclePalette(). When this function writes the "LineCycles" value into the palette timing table, the cycle value is not a multiple of 4 (e.g. it can be something like 435, and in the failure cases I see, always an odd number). This number seems to be derived from the call to Cycles_GetCounterOnWriteAccess() and is already an odd number when coming out of that function.

The spec512 palette update function Spec512_UpdatePaletteSpan() only increments ScanLineCycleCount by 4 each time, so the comparison function in there to say "are we on the correct cycle to change the palette now" never matches the odd values we have stored in the pCyclePalette block. So the code never changes the palette during a scanline.

So my (completely uneducated) guess is that the Falcon->ST switch might be upsetting the internal video clock counters somehow. In this failure state, the nCyclesCounter[CYCLES_COUNTER_VIDEO] value always seems to be an odd number.

I don't know if there is something particular in those .cfg files that triggers this case, because I don't recall ever seeing it happen when I have done the same Falcon->ST switch with my own config files.

But, as I say, I'm not familiar with this code. So I might be talking nonsense.

Steve

[npomarede]

Hi
your analysis is correct, at one point cycles are odd under Falcon (which is possible), but when switching to STF/STE mode the counter remains odd instead of being rounded to 4 again on the next bus access.

The problem is with an old part of video.c which still uses the counter CYCLES_COUNTER_VIDEO instead of using the global monotonic counter CyclesGlobalClockCounter. If CyclesGlobalClockCounter is sync'ed again to even cycles this resync doesn't "propagate" to CYCLES_COUNTER_VIDEO.
(see the TODO I added near Video_GetPosition_CE() some times ago but that I never did so far).

At the moment I'm working on a different part that also needs to be rewritten to better handle wait state during bus access, I will try to remove CYCLES_COUNTER_VIDEO in all remaining parts at the same time ; this will require a lot of testing, but hopefully I won't break anything in the end and old code can be cleaned.

Nicolas

[npomarede]

Hi
this "odd cycle" issue should now be fixed in current devel version of Hatari. The correct number of wait states should now be correctly added to ensure RAM accesses or colors accesses are on a 4 cycles boundary on the next access after being odd.
Orion or Tat , can you build this latest version and see if the problem is gone ?

Nicolas

[tat]

Thanks for the update, Nicolas

Sorry for the delay. I did try to update to the latest Hatari devel code. I didn't see any fix to the "immediate colour-change" problem once I had recreated the test environment, but I think the border issue might have changed. However, I had to do it in a rush, so I'd like to do some more checking to make sure my environment is correct.

Steve

[npomarede]

Hi
thanks for your tests, I think this should also "resync" on the next color change in this scenario of switching from 68030 to 68000 (at least I saw it in my tests when enabling traces, but maybe I didn't reproduce the same case as Orion and you). Let me know later if you still see an issue where colors would not be correct because accesses remains on odd values.