12 August 2021, 00:18 | #1 |
Registered User
Join Date: Dec 2020
Location: Philippines
Posts: 45
|
Waiting 300 microseconds on a shift/load change or button shift on a CD32 gamepad?
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
Code:
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 Anyone could explain to me why CD32 gamepad reading is an exception to this case? |
12 August 2021, 15:34 | #2 |
Moderator
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,657
|
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. |
12 August 2021, 17:28 | #3 | |
Registered User
Join Date: Dec 2020
Location: Philippines
Posts: 45
|
Quote:
"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. |
|
13 August 2021, 17:42 | #4 | |
Registered User
Join Date: Dec 2020
Location: Philippines
Posts: 45
|
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 Quote:
|
|
13 August 2021, 18:14 | #5 |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,491
|
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. |
13 August 2021, 18:49 | #6 | ||
Registered User
Join Date: Dec 2020
Location: Philippines
Posts: 45
|
Quote:
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: Quote:
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. |
||
13 August 2021, 19:27 | #7 |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,491
|
The following line, executed at the end of the routine, should potentially set the right value for the next reading:
Code:
move.w #$FF00,(potgo,a5) ; a5=$DFF034 ; correct value according to robinsonb5@eab 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 Last edited by ross; 13 August 2021 at 20:32. |
13 August 2021, 21:51 | #8 | |
Registered User
Join Date: Aug 2010
Location: Italy
Posts: 854
|
Quote:
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. |
|
13 August 2021, 22:16 | #9 | |
Registered User
Join Date: Aug 2010
Location: Italy
Posts: 854
|
Quote:
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. |
|
13 August 2021, 22:54 | #10 | |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,491
|
Quote:
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 |
|
14 August 2021, 10:30 | #11 | |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,491
|
Quote:
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 |
|
14 August 2021, 10:58 | #12 |
This cat is no more
Join Date: Dec 2004
Location: FRANCE
Age: 52
Posts: 8,369
|
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. |
14 August 2021, 12:34 | #13 | |
Registered User
Join Date: Dec 2020
Location: Philippines
Posts: 45
|
Quote:
Last edited by BeamCoder; 14 August 2021 at 12:49. |
|
14 August 2021, 13:16 | #14 | |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,491
|
Quote:
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. |
|
14 August 2021, 14:13 | #15 | ||
Registered User
Join Date: Aug 2010
Location: Italy
Posts: 854
|
Quote:
Your test program provides a nice confirmation: Code:
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 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: 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 Code:
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 ------------------------------------------------------------ EDIT: attachment removed; for a complete suite of tests, check out post #28. Last edited by saimo; 16 August 2021 at 13:28. |
||
14 August 2021, 14:29 | #16 |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,491
|
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. |
14 August 2021, 14:43 | #17 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,570
|
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. |
14 August 2021, 14:47 | #18 | |
Registered User
Join Date: Aug 2010
Location: Italy
Posts: 854
|
Quote:
EDIT: whoops, forgot to mention... I ran your test program after booting without startup sequence. |
|
14 August 2021, 14:54 | #19 | |
Registered User
Join Date: Aug 2010
Location: Italy
Posts: 854
|
Quote:
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? |
|
14 August 2021, 14:59 | #20 | |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,491
|
Quote:
(2 hres bpls are practically harmless for CPU accesses to internal bus and IRQs are turned off) |
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Shift + F3 not working in ProTracker? | h0ffman | support.WinUAE | 4 | 06 February 2014 14:21 |
shift pattern | AGS | Coders. Asm / Hardware | 16 | 16 December 2013 21:27 |
Dead shift keys... | clownstyle | support.Hardware | 21 | 13 October 2013 22:30 |
Right Shift+Right Amiga works, but not Left shift+Left Amiga | Photon | support.WinUAE | 13 | 22 November 2010 21:43 |
Sound shift | mcferson | support.WinUAE | 26 | 15 October 2008 13:03 |
|
|