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

[BeamCoder]

Is 300 microseconds wait not needed when changing shift/load or when reading buttons on a CD32 gamepad? Like in this code I got from this thread http://eab.abime.net/showthread.php?t=101516

   lea    (_ciaa),a4
    lea    (_custom),a5
; port 1
    moveq    #CIAB_GAMEPORT1,d3    ; 1rst button (red)
    moveq    #14,d4            ; 2nd button (blue)
    move.w    #$6F00,d5

    btst    d3,(a4)
    bne.b    .no_red_button
    bset    #JPB_BUTTON_RED,d0    ; fire/lmb
.no_red_button

    ; this is the joypad specific part
    ; we set bits from 16 to 0, retrieving the data from serially sent info
    bset    d3,(ciaddra,a4)
    bclr    d3,(a4)
    move.w    d5,(potgo,a5)        ; a5=$DFF034
    moveq    #10-1,d1    ; was done 24 times, not needed

    bra.b    .lbC000746    ; removed: shaving timer issue too close
                        ; 2017: reinstated (identical as Wepl timing fix)

.button_loop
    tst.b    (a4)
    tst.b    (a4)
.lbC000746
    tst.b    (a4)
    tst.b    (a4)
    tst.b    (a4)
    tst.b    (a4)
    tst.b    (a4)
    tst.b    (a4)
    move.w    (potinp,a5),d2        ; a5=$DFF016
    bset    d3,(a4)
    bclr    d3,(a4)
    btst    d4,d2
    bne.b    .lbC00077C
    bset    d1,d6
.lbC00077C
    dbra    d1,.button_loop
    ; all buttons have been read, reset data direction register

    bclr    d3,(ciaddra,a4)

    ; acknowledge port input


    move.w    #$FF00,(potgo,a5)    ; a5=$DFF034    ; correct value according to robinsonb5@eab

        
    move.b  d6,d3
    and.w   #$3,d3

In reading the manual it states that it takes 300 microseconds to change state on the lines which are used by CD32 however this code doesn't look like it waits that long. There are also code from other threads which doesn't look like it waits that long.

Anyone could explain to me why CD32 gamepad reading is an exception to this case?

[Photon]

I have no way of developing for my CD32, but I can read the code.

It reads 10 bits serially to d6 (and then keeps only 2). Each inner loop wait (the tst.b's) would take ~8 usecs on 7MHz 68000 if DMA doesn't slow it down, less on a higher-MHz EC020.

[BeamCoder]

Originally Posted by Photon

I have no way of developing for my CD32, but I can read the code.

It reads 10 bits serially to d6 (and then keeps only 2). Each inner loop wait (the tst.b's) would take ~8 usecs on 7MHz 68000 if DMA doesn't slow it down, less on a higher-MHz EC020.

Yes it seems like only ~8 usecs is needed but the reason I'm confused is that in the Amiga Hardware Manual at p.240 it states:
"If you set the output enable for any pin to a 1, the Amiga disconnects the potentiometer control
circuitry from the port, and configures the pin for output. The state of the data bit controls the
logic level on the output pin. This register must be written to at the POTGO address, and read
from the POTINP address. There are large capacitors on these lines, and it can take up to 300
microseconds for the line to change state."

So this is why I thought maybe 300us should be used as the wait time for compatibility reasons. Looking at the code again though it seems that Bit15 of POTGO is not set to 1 but Bit13 is set to 1. So maybe that's why for waiting of the 7 button states + 2, 300us is not needed however I think maybe the changing from load-to-shift or shift-to-load a 300us might still be needed since the output enable bit for that is set to 1.

[BeamCoder]

Searching at other threads related to my question, I stumbled upon this post by Toni Wilen:
http://eab.abime.net/showpost.php?p=974152&postcount=12

Setting POTGO first, then reading POTGOR should work (You probably need delay between writing to POTGO and reading POTGOR to allow pot capacitor charge or discharge depending on button state, without delay you may get incorrect button state. I think I timed this sometime ago and delay needed was very short, less than 1 scanline)

Normally your VBL routine (if it is added using exec routines) has lower priority than OS routine that sets POTGO "incorrectly". You can also try using very high priority for your VBL routine.

I assume now that as long as the user's machine has good capacitors(most likely a current amiga user has his/her replaced), waiting for 300us according to the hardware manual is too much and only a wait time of less than a scanline is needed like the cd32 joypad routine in my first post.

[ross]

I think you are confusing things.
Those delays for the CD32 pad are made for exchanging digital signals.
The 300us delay refers to POTGO analog signals.

[BeamCoder]

Originally Posted by ross

I think you are confusing things.
Those delays for the CD32 pad are made for exchanging digital signals.
The 300us delay refers to POTGO analog signals.

I'm definitely confused about this.

The 300us delay is from the Digital I/O on the Controller Port section of the hardware manual and code I found on other threads that deals with 2nd/3rd button of mouse waits for ~300us like in this thread:
http://eab.abime.net/showpost.php?p=1327320&postcount=3.

In this same thread, Toni Wilen said:

2nd/3rd button handling is always tricky because as long as POT capacitor is charged, button press can work once even if POTGO is "incorrectly" configured.

The 2nd/3rd mouse buttons have the same pins as Shift/Load and Button State of CD32 Pad.

So at this point I think it's really how good the capacitors are. And even for mouse button handling no need for a too long wait time of 300us.

[ross]

The following line, executed at the end of the routine, should potentially set the right value for the next reading:

move.w    #$FF00,(potgo,a5)    ; a5=$DFF034    ; correct value according to robinsonb5@eab

(and set the pad to non-serialized mode).

I am not even sure if a re-initialization is needed, maybe one-time initialization suffice, normally with the 'usual' second buttons it is enough, but you never know..
But you need more experienced people than me on the matter, I'm certainly not for the CD32 joypad.

EDIT: reading what Toni wrote it seems to understand that only in the case of a reset or an 'inappropriate' modification of POTGO you have to wait 300us to read POTGOR, but they are never messages that refer directly to the CD32 joypad

[saimo]

Originally Posted by Photon

Each inner loop wait (the tst.b's) would take ~8 usecs on 7MHz 68000 if DMA doesn't slow it down, less on a higher-MHz EC020.

Just for everybody's information...

Recently, for other reasons, I measured the time it takes to perform exactly that operation, i.e. tst.b (ax) on a CIA PRA register. I had always given for granted that the speed was about 1.4 microseconds as a consequence of the E-Clock frequency (1,000,000/709,379), but that was wrong: the correct time is twice as that, i.e. about 2.8 microseconds (or 10 color clocks, to look at it in another way). I made multiple tests on a stock a A1200 and on an A1200 with a 68030 at 50 MHz, getting identical results. Since I don't own another Amiga, I can't say for sure that the same happens on all the other Amiga models - but why shouldn't it, anyway?
Therefore, the delay of the inner loop is around 17 microseconds.

[saimo]

Originally Posted by ross

The following line, executed at the end of the routine, should potentially set the right value for the next reading:

move.w    #$FF00,(potgo,a5)    ; a5=$DFF034    ; correct value according to robinsonb5@eab

(and set the pad to non-serialized mode).

I am not even sure if a re-initialization is needed, maybe one-time initialization suffice, normally with the 'usual' second buttons it is enough, but you never know..
But you need more experienced people than me on the matter, I'm certainly not for the CD32 joypad.

EDIT: reading what Toni wrote it seems to understand that only in the case of a reset or an 'inappropriate' modification of POTGO you have to wait 300us to read POTGOR, but they are never messages that refer directly to the CD32 joypad

Some months ago, one of my betatesters showed me a video of a game of mine running on his machine: the menu was totally unusable because as soon as he chose an option to enter a submenu, the main menu was automatically brought back. Given that I had assigned button 2 of the joystick the "back" function, my first guess was that I should write POTGO after reading it, once per frame. Indeed, that fixed the issue. However, I was never convinced: the AHRM doesn't mention nor imply that. After some more thinking, it dawned on me: my betatester machine is stuffed with add-ons, so I thought that, maybe, something was messing up with POTGO - or better, I was messing up with POTGO while something else was using it, as I had not gotten access to it properly. The cure was simple: allocate the required bits through the potgo.resource and then write to the register. Doing that got the menu working on my friend's machine also with POTGO written to once only. Of course, if one takes over the system, the call to potgo.resource is not even needed (but, if/when disowning the system, it's recommendable to do a WritePotgo(0, 0) to have the previous value restored).
That game has been around for a while now, and also other two games for which I use the same method, and I haven't received any bug report yet.

In short: from my experience, a single move.w #$ff00,$dff034 at initialization only is perfectly sufficient to read the digital buttons 2 and 3 from both ports.

[ross]

Originally Posted by saimo

Some months ago, one of my betatesters showed me a video of a game of mine running on his machine: the menu was totally unusable because as soon as he chose an option to enter a submenu, the main menu was automatically brought back. Given that I had assigned button 2 of the joystick the "back" function, my first guess was that I should write POTGO after reading it, once per frame. Indeed, that fixed the issue. However, I was never convinced: the AHRM doesn't mention nor imply that. After some more thinking, it dawned on me: my betatester machine is stuffed with add-ons, so I thought that, maybe, something was messing up with POTGO - or better, I was messing up with POTGO while something else was using it, as I had not gotten access to it properly. The cure was simple: allocate the required bits through the potgo.resource and then write to the register. Doing that got the menu working on my friend's machine also with POTGO written to once only. Of course, if one takes over the system, the call to potgo.resource is not even needed (but, if/when disowning the system, it's recommendable to do a WritePotgo(0, 0) to have the previous value restored).
That game has been around for a while now, and also other two games for which I use the same method, and I haven't received any bug report yet.

In short: from my experience, a single move.w #$ff00,$dff034 at initialization only is perfectly sufficient to read the digital buttons 2 and 3 from both ports.

Yep, this is what I usually do, see for example this code that support also non-standard second button: http://eab.abime.net/showpost.php?p=...postcount=1520

The problem is that it is not always clear if it is enough or not, in some cases I have read that one POTGO write per frame after reading is necessary..
But this is a theme that every few months comes out again, so I probably always end up forgetting the correct answer

Probably jotd who has dealt with gazillion of various real cases would be able to tell us something more

[ross]

Originally Posted by saimo

Just for everybody's information...

Recently, for other reasons, I measured the time it takes to perform exactly that operation, i.e. tst.b (ax) on a CIA PRA register. I had always given for granted that the speed was about 1.4 microseconds as a consequence of the E-Clock frequency (1,000,000/709,379), but that was wrong: the correct time is twice as that, i.e. about 2.8 microseconds (or 10 color clocks, to look at it in another way). I made multiple tests on a stock a A1200 and on an A1200 with a 68030 at 50 MHz, getting identical results. Since I don't own another Amiga, I can't say for sure that the same happens on all the other Amiga models - but why shouldn't it, anyway?
Therefore, the delay of the inner loop is around 17 microseconds.

Could you test the attached binary?
It's my speed test code (you can find the sources somewhere here on EAB) applied to a unrolled loop of 100 CIA accesses repeated 10000 times.

WinUAE results give ~353KB/s for a bare 7MHz 68k, ~703KB/s for a 14MHz 68k and real fast-RAM, ~710KB/s for a bare A1200 (where code fit interely in icache).
So all results are congruent with a 5CCK access time.

I think for such basic machines the WinUAE results are quite accurate.
But real tests are definitely what matters

[jotd]

from my experience (which is mostly empiric)

- reading buttons during vblank interrupt (and only there) is the best method
- if you hook on a copper interrupt, you may miss readings
- if you loop indefinitely to read the values out of vblank interrupt you may get bogus readings

Then the tst bfe001 has a fixed timing, no matter the CPU (at least it's roughly the same timing). waiting 5/7 times (or 6/8 times I don't remember) between each button read works.

One last annoyance: when adapting to some games, I found out that it could introduce too much delay and trigger gfx glitches when the CPU cycles are very tight within the game. This has occurred with Switchblade 2 (I think I could fix it with some optim) and with Shadow Of the Beast 3 (I could not fix it)

Just reading the second (and third/middle mouse) button takes virtually no time, on the other hand.

[BeamCoder]

Originally Posted by ross

Could you test the attached binary?
It's my speed test code (you can find the sources somewhere here on EAB) applied to a unrolled loop of 100 CIA accesses repeated 10000 times.

WinUAE results give ~353KB/s for a bare 7MHz 68k, ~703KB/s for a 14MHz 68k and real fast-RAM, ~710KB/s for a bare A1200 (where code fit interely in icache).
So all results are congruent with a 5CCK access time.

I think for such basic machines the WinUAE results are quite accurate.
But real tests are definitely what matters

Interesting, so CIA operation like tst (ax) is not actually fixed to ~1.4us and it actually depends on what CPU&RAM is used for the machine?

[ross]

Originally Posted by BeamCoder

Interesting, so CIA operation like tst (ax) is not actually fixed to ~1.4us and it actually depends on what CPU&RAM is used for the machine?

Yes, it's something like this.
The test simply highlights that max speed can be achieved by processors with >=(CCK*4)MHz and code in fast memory (or from a processor with that speed but with cache memory).
Slower processor or without cache or with code in 'slow' RAM require more than one E-clock cycle regardless.
I have no idea of the processors that are not on the 'internal bus', such as accelerator cards, which very often are also very slow to access the normal chip-ram.

[saimo]

Originally Posted by ross

Yes, it's something like this.
The test simply highlights that max speed can be achieved by processors with >=(CCK*4)MHz and code in fast memory (or from a processor with that speed but with cache memory).
Slower processor or without cache or with code in 'slow' RAM require more than one E-clock cycle regardless.
I have no idea of the processors that are not on the 'internal bus', such as accelerator cards, which very often are also very slow to access the normal chip-ram.

As I mentioned earlier, I don't think it's possible to go below 2.8 µs, no matter the CPU.

Your test program provides a nice confirmation:

 S) Elapsed: 5614 ms, data: 1000000 bytes, speed: 178,12 KB/s
 B) Elapsed: 2819 ms, data: 1000000 bytes, speed: 354,73 KB/s

 S) stock PAL A1200
 B) same A1200, but with Blizzard 1230 IV (68030 at 50 MHz and 60 ns RAM) on

It's worth noting that 354.73 k = 354730, which is almost equal to 709379/2 = 354689.5 (the difference can be easily explained with the inevitable code overhead and timing precision limitations).

As counter-test, attached here is my own test, which simply tests the PRA register 354689 times: it takes almost precisely 1 second.

This is the test code:

   lea.l  $bfe001,a0   ;(not included in the time measurement)
   move.l #709379/2,d0 ;(not included in the time measurement)
.w tst    (a0)
   dbra   d0,.w
   clr.w  d0
   subq.l #1,d0
   bpl.b  .w

And these are the results on the same machines mentioned above:

stock A1200
------------------------------------------------------------
                         d0: $ffffffff
                         a0: $00bfe001
number of registers changed: 2
               color clocks: 3552856
                rasterlines: 15626.217
                     frames: 50.084
                         µs: 1001680.624
  free RAM before execution: 556144
   free RAM after execution: 556144
------------------------------------------------------------

A1200 + Blizzard
------------------------------------------------------------
                         d0: $ffffffff
                         a0: $00bfe001
number of registers changed: 2
               color clocks: 3552603
                rasterlines: 15625.105
                     frames: 50.080
                         µs: 1001609.294
  free RAM before execution: 29386480
   free RAM after execution: 29386480
------------------------------------------------------------

P.S. For precise timing, never rely on UAE.

EDIT: attachment removed; for a complete suite of tests, check out post #28.

[ross]

These data are very interesting!
Anyway I suppose you got them under the same conditions as me, that is the default WB / CLI at 2 bitplanes, am I right?

I hope Toni reads the thread
And also for other users to try the test program on their machines.

[Toni Wilen]

Usual answer is: if it depends on CPU speed and CPU is 68020+: it won't be accurate.

This is also sort of undefined behavior because it can also depend on accelerator board hardware (not just CPU) how it handles CIA accesses.

[saimo]

Originally Posted by ross

These data are very interesting!
Anyway I suppose you got them under the same conditions as me, that is the default WB / CLI at 2 bitplanes, am I right?

Nope, my test program takes the system over and turns off DMA, all CIA timers and all interrupts.

EDIT: whoops, forgot to mention...
I ran your test program after booting without startup sequence.

[saimo]

Originally Posted by Toni Wilen

This is also sort of undefined behavior because it can also depend on accelerator board hardware (not just CPU) how it handles CIA accesses.

OK, then I had made a wrong assumption: given that CIAs use the E-clock for timing and given that the Blizzard 1230 IV is known to connect to the machine efficiently, I had taken for granted that 2 cycles was the limit.
Unfortunately, I have only the aforementioned Blizzard card: do you have some other card(s) and would you feel like giving the test program I attached in the previous post a go?

[ross]

Originally Posted by saimo

Nope, my test program takes the system over and turns off DMA, all CIA timers and all interrupts.

EDIT: whoops, forgot to mention...
I ran your test program after booting without startup sequence.

Well, it's basically the same as my test program
(2 hres bpls are practically harmless for CPU accesses to internal bus and IRQs are turned off)