Out of curiosity I checked handshake time on kickstarts (rough values because only by vertical beam position between write, but enough for an estimation).
KS1.x - 480us
KS3.x - 400us
Of course you should check the code to have the actual values and not influenced by the multitasking system or the processor speed (bare 68k used).
Surprisingly (KS3.1 code):
Code:
00FBA7B4 0039 0040 00bf ee01 OR.B #$40,$00bfee01
00FBA7BC 41ee 0114 LEA.L (A6,$0114) == $00008868,A0
00FBA7C0 2f0e MOVE.L A6,-(A7) [00008754]
00FBA7C2 2c6e 0108 MOVEA.L (A6,$0108) == $0000885c [000081f4],A6
00FBA7C6 4eae ffc4 JSR (A6,-$003c) == $00008718
00FBA7CA 2c5f MOVEA.L (A7)+ [00fba7ea],A6
00FBA7CC 7036 MOVEQ #$36,D0 <----------
00FBA7CE d1ae 0118 ADD.L D0,(A6,$0118) == $0000886c [001e6fc7]
00FBA7D2 6404 BCC.B #$04 == $00fba7d8 (T)
00FBA7D4 52ae 0114 ADDQ.L #$01,(A6,$0114) == $00008868 [00000000]
00FBA7D8 4e75 RTS
This basically setup a 'delayed check' (so fortunately it is not a pointless wait) based on E clock ticks, and the value used is #$36! -> 1/709309*54=76us! (with PAL crystal, ~75 on NTSC)
Even if the OS coders intended to use a shorter handshake, the management routine is so slow that in any case even Cherry keyboards have never had functional problems just for that reason
.
This mean that:
- on VERY fast processor you can have a handshake of ~76us (on KS3.x, I've not checked the code on previous versions)
- on A2000 with Cherry keyboard everything works without problems because the processor is slow