Re: [hatari-devel] PSG_WaitState() inaccuracy

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 09/07/2022 à 13:08, Christian Zietz a écrit :
> Christian Zietz schrieb:
>
> > But this is not a difference in *memory* timing but an inaccurate
> > emulation of the *PSG* access timing. It just becomes more easily
> > observable if code is run from outside of ST RAM.
>
> To underpin this point consider the attached program that can be run
> from ST-RAM in a stock ST (or STE) and will still show the inaccuracy:
> Hatari 680 ticks, real hardware 554 ticks.
>
> The sequence "CLR.L Dx; MOVE.B Dx,(A1)" where A1 is 0xFFFF8800 takes 16
> cycles on real hardware: 6 for the CLR.L, 10 for the MOVE: 8 + 1
> waitstate during PSG access + 1 waitstate for re-synchronization of the
> next (prefetch) access to ST-RAM.

Hi

yes, it is known that the waitstates when accessing the YM2149 are not 
correct for all cases yet.

If you look at the start of psg.c you will see several examples that I 
used over the time to ensure timings were correct in CE mode.

At that time, I came to the conclusion that adding 1 cycle for each 
access was the correct solution, but later I changed it by adding 4 
cycles and also checking if the same instruction is doing several access 
or not (because the way Hatari counted cycles then was not really suited 
to add 1 cycle at a time, which is not the case anymore)

I know memory access is not rounded to 4 from alt ram / cartridge, but I 
never tested access to YM from cartridge to see how it behaves (no HW 
for that on my side)

I already planned to go back to the "1 cycle waitstate" method, because 
it's how HW works, so with your test program I will also be able to 
check timings are correct from alt-ram / cartridge, which is a very good 
thing :)

Nicolas