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...

Wow pretty impressive research job, I'm sure this will be useful !

Thx =]
Well, the discovery could be at least useful in some unusual circumstances.
Like, for example, if you need to add some new group(s) in your scan, without disabling the previous ones, you don't need a delay.
Also, we now know that when you send 0 to port 1 (code checking for any key pressed, etc)., you can read directly without waiting =]
Here is the piece of code i'm testing (interrupts disabled ofc) :
    xor a
loop
    out (1),a ; all groups enabled
    dec a
    out (1),a ; asking to disable all groups
; delay needed here
    in a,(1)
    inc a
    jr z,loopAs you can see, i ask the port to disable all groups, to see the maximum needed delay.
It seems that 29 cycles isn't enough (tested @ 15Mhz).
Even more fun, only the [5] key can exit that loop, don't ask me why
EDIT 1 : I suspect it's because the group including [5] is in the middle of the disabling process, when the IN instruction occurs.
EDIT 2 :
@ 30 cycles, no single key can exit the loop.
However, 2 keys from different groups can
Seems like the only way to know the real maximum delay is to hold absolutely all keys at once.
Checking that right away...
EDIT 3 :
@ 66 cycles, 4 keys from different groups can exit the loop...
@ 88 cycles, 5 keys...
@ 96 cycles : 6...
LAST EDIT FOR THAT POST :
It appears that when you enable all groups, and then ask the port to disable them, my calc needs exactly 121 cycles to perform a full disabling, in cpu speed 1.
In other words, that's the time the keyboard needs to switch all 8 groups from 0 to 1.
That is huge.
Anyway, my second theory was right : the more groups the port has to disable, the longer it takes.

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).

@Matrefeytontias : You should wait a little, cause some values would need to be more accurate.

#####

Some new discoveries =]
> My intuition was right, it seems the time the port needs to do a disabling is not the same for each group (looks like bits are processed in a a linear way).
Group bit 0 is the fastest to set, whereas group bit 7 is the longest.
Example :
00000010 > 00000011 : 23 cycles needed
00000010 > 01000010 : 27 cycles needed
> I was wrong when i said that writing a 1 over a 1 is instantaneous.
Looks like it takes around 1/4 cycles per group at 15 Mhz.
> I updated post 1 with all that juicy stuff =]
> I'm trying to think of a way to know when the group map has been totally updated...

Whoa nice. Only weird thing is that it looks like it takes 4 times more cycles for 15-16MHz but it's not even 3 times the speed.

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 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...

I understand that you don't count the cycles spent in the in/out instructions for simplicity purposes. I just wanted to clarify why the 6MHz and 15MHz delays you recorded are not in a ratio of 6:15.

I understood the clarification, but i wasn't sure about the "do they?".
Thx =]