I have an 83+SE, a 128k 84+ and a TI-82stats.fr (TI 83 rom on 83+BE hw) that I can test for you.

I'll post my program tomorow, but i'm not sure your TI-82stats.fr will like it
Anyway, i just tested the keys of my 83+be.
The shortest delay is 0.
The longest is 6.
The concerned keys are not the same as on my 84+se.
It seems keyboards may differ...

Your delay figures don't count the amount of cycles spent in the out/in instructions, do they? I believe that could account for the discrepancy you're seeing. It may not add exactly 11 cycles of delay though, as a physical port write might not happen after the same amount of time/cycles relative to the start of the instruction as a physical port read.

All my tests were made using OUT (1),A and IN A,(1), without including any cycles spended by the instructions themselves.
Mainly because i think it's easier for the programmer to just know how much delay he has to put between the two lines.
From what i've tested, the delays are about the same when using the C register (delay-1 or so...).

#####

I was thinking of something.
What happens when you write to the port in the middle of a disabling job ?
I mean, is the second OUT failing, or does the port stops what he was doing and follow the new instructions ?
Some interesting questions...

Interesting...
It seems that each key on the keyboard needs a specific time to be disabled.

old group map > new group map   group,key=delay6mhz/delay15mhz
00000000>00000001   0,0=4/21 0,3=4/20
11111110>11111111   0,0=4/21 0,3=4/20
00000000>00010000   4,0=6/29 4,7=4/20
11101111>11111111   4,0=6/29 4,7=4/20
00000000>01000000   6,0=5/26 6,7=4/18
10111111>11111111   6,0=5/26 6,7=4/18
00000000>11111111   0,0=4/21 0,3=4/20 4,0=6/29 4,7=4/20 6,0=5/26 6,7=4/18

Such results prove that i was wrong about 2 things :
1) Key bits are NOT processed in a linear order during the disabling process (bit0, bit1, ..., bit7). Instead, it seems it is hardware specific (probably depends on the electric scheme).
2) Writing 1 over 1 does NOT take time.
(post#1 updated)

It's getting clearer & clearer.
Now, i'm curious to find which key needs the longest time to be disabled =P

EDIT :

Tested all keys.
It's official, the key that takes the longest time to be disabled is [5] : 7 cycles at 6 Mhz & 31 cycles at 15 Mhz.
That's very funny, cause that totally explains why that was the only key that could break my loop (see one of my previous posts) =]
The fastest is [ALPHA], with 4 cycles at 6 Mhz and 16 cycles at 15 Mhz.
So, i think it's safe enough to use 8 cycles at 6 Mhz, and 32 at 15 Mhz.
But again, such delays are only safe when checking one key at once !

Whoa, that I did not expect. I'll definitely want to play with that myself on hardware. Maybe that could explain the rare occurrences I still hear about of mis-registered keypresses in Axe, as the getKey(0) command reads from all groups to check if any key is pressed and might be causing issues for any subsequent single key read attempt.

Neither did i =]
I re-checked it, and it appears all keys corresponding to key bit 2 at once could break the loop, but after a few loop iterations.
So, i had to let the loop run with a heavy thing on all keys for long enough, overlol.
New world record : 123 cycles (tested with cpu speeds 1,2,3).

At first, i was kinda curious to know why sending $FF would remove the necessity to wait for a delay between writing & reading.
I couldn't believe that sending that was processed somehow differently than sending anything else.
After many boring tests, here is what i discovered :

> About sending $FF :

Sending that to port 1 was called a "reset" by some.
It is true in the fact that it disables the scanning of all groups.
But, i can confirm that it doesn't have any additional effects.
I mean, sending $FF has the exact same effect as sending $7F (the unused group).
It just disables all groups, and is interpreted by port 1 like any other sending.

> About the (famous) needed delay :

Whenever you need to check specific keys (IN), you sometimes have to send one or more group map(s) first (OUT), to be sure that the key presses will be detected.
Sometimes, a delay is needed between OUT & IN, sometimes not.
First, you have to understand that the port always remember the last group map you have sent to him.
We'll call it the current group map.
If you really want to optimize your code, you'd better know what the current group map is, each time you intend to update it.
In other words, each time you use an OUT, it's better to know what you last sended to the port with the previous OUT.
When you update the current group map, here is how it works :

1) You write a 0 to a group bit.
Technically, it can be :
- sending a 0 over a 0 : It has no effect on the concerned group. > No delay is required before reading keys in that group.
- sending a 0 over a 1 : You actually ask the port to enable a group. Fortunately, it is done almost instantly. > No delay is required before reading keys in that group.
In other words, if you don't disable any group(s), you're free to use a IN right after a OUT without fear, even at 15Mhz.

2) You write a 1 to a group bit.
Technically, it can be :
- sending a 1 over a 1 : It has no effect on the concerned group. > No delay is required cause all the keys in that group should already be disabled.
- sending a 1 over a 0 : You actually ask the port to disable a group. > A variable delay is required before all the keys in that group are disabled.
Disabling a group actually means that you don't need to check keys in it anymore.
However, if some of those keys are pressed when you read the port, and are not disabled yet, they will return a zero bit if pressed, even if you think you are reading another (enabled) group.
So, basically, if you don't care if the keys in a disabled group are pressed or not, you don't need to wait.
But, if you want to be 100% sure that all the keys in that group have been disabled, continue reading.
When you disable a group, the keys in it are not disabled simultaneously.
Actually, some take more time than others.
Here is what i gathered :
- Disabling only one group :
Strangely, the more keys are being pressed during the disabling process, the faster it is.
The slowest scenario is when only one key is pressed.
The highest needed delays measured were 7 cycles at 6 Mhz, and 31 at 15 Mhz (Using 8 & 32 would be safe enough.).
- Disabling multiple groups :
The delay can go pretty high.
The slowest scenario is when you disable the entire keyboard (changing the group map from %00000000 to %11111111).
In that case, The delays measured were 46 cycles at 6 Mhz, and 125 at 15 Mhz (Using 48 & 128 would be safe enough.).
According to several tests, what makes that delay so high is that many keys of the same key bit are being pressed at the same time (The keyboard needs a huge time to disable those.).

> Note :

The way i made my tests, all delays refer to the needed cycles between a OUT (1),A line and a IN A,(1) line.
Those values were all obtained by checking pressed keys.
Due to how the keyboard works, the real time it needs to enable|disable unpressed key(s) remains unknown...

Still about the keyboard :

I finally found a little something.
The challenge was to find a way to know if the current group has been updated (similar to reading bit 7 of port $10 for the LCD).
It seems impossible, since reading port 1 doesn't actually give any infos about that.
But, fortunately, there is a way to know if : the group has been updated AND a key is being pressed on that group.
I believe it is compatible with all possible hardware types, for all CPU speeds.
There you go :

LD A,$FF
OUT (1),A
LD BC,$??01 < ?? = group to be checked
LOOP
OUT (C),B < using C to make the loop faster
IN A,(1)
INC A
JR Z,LOOP < JP maybe better, not sure...
< group updated & key(s) pressed
DEC A
< A holds the key map for the desired group, safe to check it.

Of course, that is the safe way, not necessarily the fastest.

/e : just corrected it

/e2 : realised that it only allows to test one group at once =/

Allright, since i was curious about it, i did some tests, but this time, resetting the port first.
When you do that, i can confirm that no delay is needed bewteen sending the group and reading the key.
However, a delay is now needed between resetting the port and sending the group.

A bit more visual explanation :
LD A,$FF
OUT (1),A < resetting the port
... < that is where i mesured how many cycles are needed before writing to the port again (likely to include an instruction to actually load the group to be monitored in A)
OUT (1),A < sending the group
(no delay needed here)
IN (1),A < reading the keys

I only tested my 84+se for now, but it is a good reference (had the longest possible delays in my previous tests).
That is what i got :
cpu speed 0 > 4 cycles needed (maybe less, but that is the minimum cycles you need to load your group in A anyway)
cpu speed 1,2,3 > 17 cycles needed

That is interesting, cause it could imply that writing to port 1 is faster than reading from it.

When i have time, i'll check if the delays are similar when using the C register for input/output...

EDIT :

When using the C register for input/output (as expected) :
cpu speed 0 > 4 cycles
cpu speed 1,2,3 > 16 cycles (one less than on the previous test, but that is probably because in/out operations take 1 more cycle)

Hmm... there's something i don't get, then.
If left is pressed, (1) will return $FD.
$FD and $FD = $FD, right ?
So, why checking if if the result is zero before calling ?
Can somebody tell me where i missunderstand it ?

And about the CSE delays, yes, i remember you were surprised when my code returned those results.
Maybe i f***ed up somewhere in it...