Waiting 300 microseconds on a shift/load change or button shift on a CD32 gamepad?

[ross]

Originally Posted by saimo

It must be a language thing. So, you mean: "minimum" = "at least". I had interpreted that as "as small as".

This

Originally Posted by modrobert

Yes, my mistake, starting to remember now, so the Amiga activates pin 5 to get the data from CD32 controller shifted out on pin 9, right?

Right, pin 6 as the 'clock' for the serial data.

[saimo]

I had the CIA tests run on a friend's Amiga CD32 equipped with a TF328. The results (attached) are: all the instructions (clr, move, st, tst) execute in 1 E clock cycle, no matter the combination. I guess this is due to CIAs and Gayle being integrated into Akiko.
The sad news is that this proves that the CIA speed access cannot be relied upon for precise timing, unless one writes self-adapting/parametric code that executes according to a previous assessment of the speed.

EDIT
Correction to myself: the expansion board used was a TF330, not a TF328.

[ross]

Originally Posted by saimo

The results (attached) are: all the instructions (clr, move, st, tst) execute in 1 E clock cycle, no matter the combination.

These are the results I would expect from any AGA machine, executing code from icache, in the internal bus
(and basically are the results that WinUAE provides).

I'd like to see results from other revisions of the A1200 or A4000..

[saimo]

Originally Posted by ross

These are the results I would expect from any AGA machine, executing code from icache, in the internal bus
(and basically are the results that WinUAE provides).

Yep, and we're back to my very first post here I had always assumed that it was like that, until recently my A1200 pointed out I was wrong!

I'd like to see results from other revisions of the A1200 or A4000..

Me too. I asked another friend who has a variety of machines to make other tests, but unfortunately he won't be able to run them for a few weeks. This evening I should get the results from another Amiga CD32, though.
Of course, if anyone else is able and willing to run tests, that's very welcome! They are attached to this post.

[saimo]

I finally received the log from another test, performed on yet another Amiga CD32 equipped with a TF328. Surprise: the results are different from the previous ones (see post 42)! While the previous results were perfect (1 CIA cycle per access), these ones show an odd behaviour:
* the combinations clr+tst and st+tst require 3 CIA cycles (instead of the perfect 2);
* the combinations clr+tst+st+tst and st+tst+clr+tst require 5 CIA cycles (instead of the perfect 4 and also instead of 6, as one would expect from the previous point).

Bottom line: even when the machines are supposedly the same, the timings may vary, so CIA accesses cannot be used for precise timing.

EDIT
Correction to myself: the results in post #42 have been made on an Amiga CD32 equipped with a TF330 (not a TF328), so the surprise isn't as big as I wrote above It's still true, however, that trusting the CIA access speed for exact timing isn't wise.

[BeamCoder]

Originally Posted by saimo

I finally received the log from another test, performed on yet another Amiga CD32 equipped with a TF328. Surprise: the results are different from the previous ones (see post 42)! While the previous results were perfect (1 CIA cycle per access), these ones show an odd behaviour:
* the combinations clr+tst and st+tst require 3 CIA cycles (instead of the perfect 2);
* the combinations clr+tst+st+tst and st+tst+clr+tst require 5 CIA cycles (instead of the perfect 4 and also instead of 6, as one would expect from the previous point).

Bottom line: even when the machines are supposedly the same, the timings may vary, so CIA accesses cannot be used for precise timing.

Maybe this could be post on Undocumented Amiga Hardware thread for archive? This information could be important to someone

[saimo]

Originally Posted by BeamCoder

Maybe this could be post on Undocumented Amiga Hardware thread for archive? This information could be important to someone

Hmmm... given what he says in post 17, it sounds that all of this was nothing new to Toni Wilen - maybe it was common knowledge already?


(By the way, I'm going to make a correction to my previous post right after submitting this.)

[Toni Wilen]

This kind of behavior is typical for async CPU clock (CPU clock is not integer multiple of main board clock), some memory access cycles are always missed. I wasn't sure if it affects CIA (that badly).

EDIT: 68020+ due to caches and internal pipelines, can have different delays between memory access and start of next memory access, even if instructions are exact same and clock is sync.

Undocumented thread is mostly about chipset features, not fast CPUs/accelerator boards.

[saimo]

Originally Posted by Toni Wilen

This kind of behavior is typical for async CPU clock (CPU clock is not integer multiple of main board clock), some memory access cycles are always missed. I wasn't sure if it affects CIA (that badly).

It sounds like I had made the same or a similar assumption: I thought that the access speed was 1 CIA cycle and that, however, the CPU might lose some CPU cycles due to clocks not perfectly synchronized. I certainly didn't expect the loss to be multiples of CIA clocks halves and to be so apparently random.