### Author Topic: port 1 stuff  (Read 5462 times)

0 Members and 1 Guest are viewing this topic.

• LV6 Super Member (Next: 500)
• Posts: 302
• Rating: +45/-0
##### port 1 stuff
« on: May 15, 2014, 04:34:23 am »
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...
« Last Edit: May 21, 2014, 03:47:42 pm by the_mad_joob »
"No human is trustworthy, not even me..." - the_mad_joob

#### Streetwalrus

• LV12 Extreme Poster (Next: 5000)
• Posts: 3820
• Rating: +80/-8
##### Re: port 1 stuff
« Reply #1 on: May 15, 2014, 05:02:41 am »
Wow pretty impressive research job, I'm sure this will be useful !
send it

• LV6 Super Member (Next: 500)
• Posts: 302
• Rating: +45/-0
##### Re: port 1 stuff
« Reply #2 on: May 15, 2014, 05:18:46 am »
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) :
Code: [Select]
    xor aloop    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.
« Last Edit: May 15, 2014, 11:30:00 am by the_mad_joob »
"No human is trustworthy, not even me..." - the_mad_joob

#### Runer112

• Moderator
• LV11 Super Veteran (Next: 3000)
• Posts: 2289
• Rating: +639/-31
##### Re: port 1 stuff
« Reply #3 on: May 15, 2014, 08:52:06 am »
All set bits will disable the corresponding groups, but it will take some time (the famous delay).
Note that when you ask the keyboard to disable a group that is already disabled, it will do nothing (no delay).
So, basically, the keyboard only needs a delay when changing a group bit from 0 to 1.

That's been my suspicion for years, but I don't have any knowledge of how the hardware actually works so could never definitively say so. Good to hear that my suspicion can now be upgraded to a probable truth.

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's about 16 cycles per group, which 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.
« Last Edit: May 15, 2014, 08:55:27 am by Runer112 »

• LV6 Super Member (Next: 500)
• Posts: 302
• Rating: +45/-0
##### Re: port 1 stuff
« Reply #4 on: May 15, 2014, 09:05:29 am »
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).
« Last Edit: May 15, 2014, 11:31:12 am by the_mad_joob »
"No human is trustworthy, not even me..." - the_mad_joob

#### Matrefeytontias

• Axe roxxor (kinda)
• LV10 31337 u53r (Next: 2000)
• Posts: 1982
• Rating: +310/-12
• Axe roxxor
##### Re: port 1 stuff
« Reply #5 on: May 15, 2014, 12:38:59 pm »
That's some useful information do you mind if I detail that on WikiTI with your name in the credits as the finder of these info ?

• LV6 Super Member (Next: 500)
• Posts: 302
• Rating: +45/-0
##### Re: port 1 stuff
« Reply #6 on: May 15, 2014, 01:27:48 pm »
@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... « Last Edit: May 15, 2014, 04:21:53 pm by the_mad_joob » "No human is trustworthy, not even me..." - the_mad_joob #### the_mad_joob • LV6 Super Member (Next: 500) • Posts: 302 • Rating: +45/-0 ##### Re: port 1 stuff « Reply #7 on: May 16, 2014, 07:06:17 am » 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 ! « Last Edit: May 16, 2014, 10:00:56 am by the_mad_joob » "No human is trustworthy, not even me..." - the_mad_joob #### Streetwalrus • LV12 Extreme Poster (Next: 5000) • Posts: 3820 • Rating: +80/-8 ##### Re: port 1 stuff « Reply #8 on: May 16, 2014, 10:24:50 am » 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. send it #### the_mad_joob • LV6 Super Member (Next: 500) • Posts: 302 • Rating: +45/-0 ##### Re: port 1 stuff « Reply #9 on: May 16, 2014, 11:50:12 am » 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. Yeah, i really never figured out why myself... Next steps : > check the maximum possible delay at 6 Mhz > code a decent prog & find someone to test on another 84+se (to know if the fastest/slowest keys are the same, me curious) > find a trick to know when the keyboard has finished the enabling/disabling job, to avoid having to use a predefined delay > reformating post#1 into something more understandable "No human is trustworthy, not even me..." - the_mad_joob #### Streetwalrus • LV12 Extreme Poster (Next: 5000) • Posts: 3820 • Rating: +80/-8 ##### Re: port 1 stuff « Reply #10 on: May 16, 2014, 01:09:13 pm » 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. send it #### Runer112 • Moderator • LV11 Super Veteran (Next: 3000) • Posts: 2289 • Rating: +639/-31 ##### Re: port 1 stuff « Reply #11 on: May 16, 2014, 01:10:17 pm » 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. Yeah, i really never figured out why myself... 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. #### the_mad_joob • LV6 Super Member (Next: 500) • Posts: 302 • Rating: +45/-0 ##### Re: port 1 stuff « Reply #12 on: May 16, 2014, 06:24:32 pm » 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...
« Last Edit: May 16, 2014, 06:38:13 pm by the_mad_joob »
"No human is trustworthy, not even me..." - the_mad_joob

#### Runer112

• Moderator
• LV11 Super Veteran (Next: 3000)
• Posts: 2289
• Rating: +639/-31
##### Re: port 1 stuff
« Reply #13 on: May 16, 2014, 08:17:06 pm »
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 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.