Re: [hatari-devel] The DSP and wait states

[laurent.sallafranque@xxxxxxx]

Hi Roger

I'm not sure to understand well, but I've spent à lot of time with the DSP cycles. From what I remember, I add 2 cycles for all instructions and then, I add the extra cycles on each nstruction that need some (for instructions that take 4 cycles for example). For memory acces, I take into account access to inner or outer memory. And for outer memory, I simplified the problem by considering a zéro waitstate memory access in all cases (I considerated that non falcon developer would add extra cycles for pleasure, but this can be improved by taking into account the bcr if someone cares but I didn't feel useful to do it by the time). Loosing up to 15 cycles for extra external access seems unuseful to me 😜. Hope this helps

Le 28 oct. 2020 02:54, Roger Burrows <anodyne@xxxxxxxxxxxx> a écrit :

Hi all,
As a result of Eero's questions on emutos-devel, I've decided to come up with
my own questions on hatari-devel :-).

I was curious about how the DSP emulation was integrated into Hatari, so I
looked at the code a little bit.  One thing that I was a bit puzzled about was
the addition of extra cycles for access to external memory.  The code always
seems to add 2 cycles for access to external memory, which is NOT how the real
DSP runs.

The real DSP inserts wait states according to values in the BCR.  A reset sets
the BCR to 0xffff (15 wait states for access to all external memory), but about
the first thing any DSP program running on the Atari does is to set the BCR to
0x0000 to indicate 0 wait states for access to all external memory.  Of course
I certainly don't understand Hatari very well, so perhaps I've misinterpreted
the code somehow.  But I've done a grep for DSP_BCR, and it is only referenced
in DSP initialisation, when setting its value to 0xffff.

Roger