[hatari-devel] PSG_WaitState() inaccuracy

[Christian Zietz <czietz@xxxxxxx>]

Hello,

please excuse if this is a known inaccuracy / limitation in Hatari.

Consider the attached cartridge which times accesses to the PSG (writes
to address 0xffff8800). It prints the number of 200 Hz ticks for
30000x64 accesses. In Hatari [1] in ST mode with cycle exact 68000
emulation the code takes 624 ticks. On a real ST, the code takes 477
ticks, ca. 75% of the Hatari value.

Note that this inaccuracy is not limited to cartridges. It occurs with
code running from TOS ROMs or Alt-RAM, as well -- anything that is *not*
running from ST RAM. A cartridge was just the easiest way to test on
Hatari and real HW.

This 25% difference results from the PSG_WaitState() implementation [2],
which assigns four waitstates to every new instruction accessing the
PSG. Whereas in reality, only one waitstate is incurred for a PSG
access. However, the next bus-cycle accessing *ST-RAM* gets waitstates
until everything is realigned on a multiple of four. But this also
means: If you do not access ST-RAM, you don't see four waitstates.
Hence, "move.b  d1,(a1)" takes 9 instead of 12 cycles.

Note this isn't a regression in Hatari 2.4. Also, fixing it might be
difficult because you need to track when the next ST-RAM access occurs.

Regards
Christian

[1] Please note when testing: Hatari can only emulate a user-defined
cartridge when GEMDOS-drive emulation (among other things) is disabled.
EmuTOS does not support the virtual "c:" (lower case "c") drive for
cartridges on the desktop; thus, please test with Atari TOS.

[2] https://git.tuxfamily.org/hatari/hatari.git/tree/src/psg.c#n458
--
Christian Zietz  -  CHZ-Soft  -  czietz@xxxxxxx
WWW: https://www.chzsoft.de/
PGP/GnuPG-Key-ID: 0x52CB97F66DA025CA / 0x6DA025CA

Attachment: psgcart.zip
Description: Zip compressed data