geekhack Community > Keyboards

Rollover, where keyboard data might go, and ramble

(1/3) > >>

dw_junon:
Hi all,

Lurked for a bit now and haven't really known where to begin.  I was going to reply to the stickied topic but maybe fuelling the sorta-OT isn't such a great idea.  particularly since this is more of an exploratory ramble than I expected - ed. by dw


--- Quote from: pex's IBM Model M keyboard dissection/repair page ---
I'll be doing some path tracing so I can update this page with a solution.
--- End quote ---

Interesting.  I haven't seen anyone else try this, and have yet to find any IBM documentation on the matrices, probably not something for the Customer Engineer to play with.  This would be very useful with respect to determining the fundamental switching capability, never mind any issues introduced from there on.

That said, Dave Dribin's diode suggestion on the aforementioned Keyboard Matrix Help page seems logical, and so in the absence of diodes (unless they are somehow concealed in there...), I'd suggest that n-key is unlikely.  Not that this diminishes the usefulness of tracing the matrices though, this will still give a good idea of what can be achieved.

Then again, how standard are matrices in 101 "Model M"s?  I don't know that anyone knows...

At least looking at keyboard controllers in IBM Enhanced 'boards, there has been some deviation over the years, as documented by Louis Ohland on his IBM PS/2 resource "Ardent Tool of Capitalism"'s Model M page and by Sandy on the Model M (and F) Trivia page of the fascinating and wide-ranging "A Little Bit of Keyboards".

While I certainly don't know what may or may not have changed in the controllers, I do have some potentially significant information from an early reference (which I might go on about in another topic in a bit):
From "IBM 7531/2 Industrial Computer Technical Reference System Unit" [IBM part number 6523261, First Edition (July 1985)]
Chapter 4, [Keyboard] - page 4-3

Keyboard Buffer

A 16-byte first-in-first-out (FIFO) buffer in the keyboard stores the scan codes until the system is ready to receive them.

A buffer-overrun condition occurs when more than 16 bytes are placed in the keyboard buffer.  An overrun code replaces byte 17.  If more keys are pressed before the system allows keyboard output, the additional data is lost.

When the keyboard is allowed to send data, the bytes in the buffer will be sent as in normal operation, and new data entered is detected and sent.  Response codes do not occupy a buffer position.

If keystrokes generate a multiple-byte sequence, the entire sequence must fit into the available buffer space or the keystroke is discarded and a buffer-overrun condition occurs.

Keys

With the exception of the Pause key and the Num Lock key, all keys are make/break.  The make scan code of a key is sent to the keyboard controller when the key is pressed.  When the key is released it break scan code is sent.

Additionally, except for the Pause key and the Num Lock key, all keys are typematic.  When a key is pressed and held down, the keyboard sends the make code for that key, delays 500 milliseconds ± 20%, and begins sending a make code for that key at a rate of 10.9 characters per second ± 20%.  Some systems allow the typematic rate and delay to be modified (see "Set Typematic Rate/Delay (Hex F3)" on page 4-9).

If two or more keys are held down, only the last key pressed repeats at the typematic rate.  Typematic operation stops when the last key pressed is released, even if other keys are still held down.  If a key is pressed and held down while keyboard transmission is inhibited, only the first make code is stored in the buffer.  This prevents buffer overflow as a result of typematic action.

Of some significance, then:
[*]The keyboard has a 16-byte buffer.

In all three scan code sets, most make codes are 1 byte, and for sets 2 and 3 break codes are produced by prepending the make byte with F0, so 2 bytes.  Modifying keys such as Ctrl act on their own and do not add further bytes to other keys.

So the maximum possible number of individual key presses that may be held by the keyboard's buffer is 16.  Note that this only applies when the host [computer] is not ready to receive data, so is not a definitive limit, but is a worst-case-scenario for what the maximum the keyboard controller is able to cope with.
[/LIST][*]Typematic operation.

From the first sentence of the last paragraph, "If two or more keys are held down, only the last key pressed repeats...".  This behaviour could lead to misinterpretation of casual rollover testing.
[/LIST]

At this point curiosity got the better of me, and I wanted to see exactly where the keyboard data went, and what further obstacles to n-key rollover in hardware there might be.

On the computer end, data is sent by the keyboard over a serial link to the host.  Each transmission is effectively a single raw scan code byte with some "formatting".  The eight scan code bits are ultimately transferred to an eight bit buffer from which they may be sent to the data bus.  This is verified in the 7531/7532 Tech Ref (I really must get it to a decent scanner).  According to it the 8042 controller has 128 bytes of RAM, though there is no obvious indication that it is used for any further buffering.

Therefore it seems reasonable to conclude that the host controller itself is incapable of holding any more than two scan codes instantaneously [one sitting in the output buffer, one incoming from the keyboard].  This itself may not be possible dependent on implementation, and besides only the scan code in the output buffer may read by the computer, so ultimately the computer can only possibly be aware of one scan code at any instant.  This seems quite logical, given the nature of the keyboard/host communication…

Looking at the schematic logic diagrams for the IBM 7531 computer [which I now need to point out is essentially an IBM 5170 AT in a "fancy" case], the output buffer of the 8042 is connected via 74ALS245 bus transceivers (which presumably and hopefully will not modify the data) to the 80286 processor (and 80287 co-pro).  This suggests that in this system there is no prominent facility for the processing or buffering of multiple scan codes, at least before reaching the processor…


Anyhow, obviously this bears limited relation to your shiny Apple products, but does show the possibility for system architecture to impact keystroke handling, perhaps particularly with that concept that traditionally [for an IBM AT with the Enchanted keyboard at least], any buffering of keystrokes in done in the keyboard itself.

The transmission protocol between keyboard and host however should be relatively constant for PCs though (otherwise you wouldn't be able to plug any old keyboard in, yes, even considering the adapters), so sending multiple keystrokes instantaneously is probably not going to be possible without something special.

Consequently then, an now-obvious way to help increase the amount of keystrokes that appear on your screen seemingly in one go is to have a keyboard controller with a large buffer, thus retaining the data regardless of the computer's capabilities.  Furthermore, the effect will be good for any computer you attach it to.  The matrix design, and the keyboard controller's ability to interpret data from it, however, is crucial.  Again, I suggest that the Matrix Help page has it right.


I did not discuss the reading of the matrix in the 7531's keyboard as neither the reading, the interpretation, conversion to scan codes, or the layout of the matrix itself, is discussed in the Tech Ref, only the sending and receiving of data.  To my surprise though I have just discovered a schematic for the entire keyboard controller:

http://www.9999hp.net/7531-2_TechRef_4-41_Keyboard_Logic_Diagram.jpg - a little bit too big to put in-line after all.

The only relevant specifications given are the power requirements [+ .5 Vdc ± 10% [sic!, surely this should be +5V], Current cannot exceed 275mA].  No values are given for components, and there's no sign of a breakdown of what the 6805 actually does, alas.  I do have the appropriate keyboard [it's in the avatar], but none of my 7/32"/5.5mm socket bits have a narrow-enough to fit into the recesses, so I'm afraid can't open any Enhanced "Model M"s to get any info that way.

What can be seen from the diagram are the eight "sense" lines and the sixteen "drive" lines.  So by the looks of it, when a key is pressed, the corresponding "drive" lines will go high.  The presence of the resistors on the "sense" lines also suggests that the appropriate "sense" level on the microprocessor will go low.  If so, the exact purpose is unclear but could be to offer improved reliability as a limited verification of what was pressed.  A matrix with 16 "drive" lines allows for over 32 thousand unique combinations, so that should not be an issue.

There is a secondary IC, U1, but it looks like no more than a load of inverters which is probably not significant.

Now, if we can just find data on everything else...

dw_junon:
"1.  The text that you have entered is too long (10006 characters). Please shorten it to 10000 characters long."

I guess that says a lot, too.

pex:
Well, I'm of course going to be agitated when I spent all this time and someone produces a matrices representation picture and schematics of my controller.

:rolleyes:

Thanks for providing the info.  Someday I will have an n-key rollover keyboard so I can supplement stuff like technical manuals with empiric experience (ex: all this talk about host controllers and small buffers is saddening, but we know there ARE keyboards out there that are punching out insane numbers of keys at a time, if not all 104 at once.)

dw_junon:
Bear in mind that all that refers to mostly to a reference from July 1985.  The controller from your 42H1292 [ref] has far fewer external components than on that logic diagram.  Obviously stuff has changed a bit...


One thing I failed to discuss is the timing of the communication protocol (see computer-engineering.org).  Never mind what goes on inside your keyboard, if it can't talk to the computer properly you're stuffed.  So everyone had better get it right (and do it the same way...).

Keyboards and computers communicate using two lines in binary states, Data (for... data) and Clock (for timing), each being high or low.
Normally (i.e. when transmission is possible), both Data and Clock are high.
When the keyboard starts talking, the Clock line is pulsed, it goes low then high then low then high etc.
The Data line is read by the computer each time the Clock goes low.
Each scan code (eight bits) is sent with a parity [error checking] bit, and surrounded with bits to mark the start and stop of transmission, so with eleven bits total this happens eleven times.
When the Clock is no longer required to be low, it goes high again to its normal state.

From the above-mentioned page: "The clock frequency must be in the range 10 - 16.7 kHz.  This means clock must be high for 30 - 50 microseconds and low for 30 - 50 microseconds."
So, starting high, the Clock goes low 11 times and goes high 10 times during transmission.  Therefore, the actual communication of a scan code to a computer must take max. 21 x 50µs = 0.00105 seconds.  If you had it show up in blinkenlights, that'd probably be quite easy to miss...

However, there has to be some time between transmissions to keep them apart.  Again, from the page: "The Clock line must be continuously high for at least 50 microseconds before the device can begin to transmit its data.".  The delay must be at least 50µs, then.

So how long would it take to transmit, say, 50 keys mashed all at once read by an optimal matrix, scanned, buffered, translated and read at the other end by optimal controllers?

If we use the minimum possible time between transmissions, it would be 50 keys (21 x 50µs + (1 x 50µs)) = 55000µs = 0.055 seconds.  This is unrealistic because:

Contact bounce in mechanical switches may necessitate some delay to ensure accurate detection
Either identifying or calculating the scan code takes time
Writing and reading the buffer takes time
Calculating and appending the parity bit takes time
Prepending and appending the start and stop bits takes time
And how much of the above four can be done in parallel?  Are there any delays required as a result?

That said, with memory access times of nanoseconds rather than microseconds, and microcontrollers capable of multiple MIPS I fail to see any good reason for much electronic delay at all nowadays.  Electromechanical delay seems far too complicated for me to bother considering right now and is surely also nominal anyway.

But, getting back to trying get a time for the 50 keystrokes, what would be a realistic interval between scan code data transmissions?

A very realistic interval would be a real one; get an oscilloscope on a "live" Data line and press two keys (or as many as you can get away with) as synchronously as possible.  Unfortunately I don't have access to a 'scope.  Any help there?

I had a look around the 'net for such information, but everyone just documents the protocol, shows how one scan code is sent and leaves it.  The 7531 manual does the same, but also documents the host commands [stuff the computer can tell the keyboard do], included among which is the Typematic [repeat] Rate/Delay command (I actually already included a reference to this in the extensive manual quote above).

Trying not to go into too much detail (har), the Typematic Rate (which is the rate at which a keystroke is repeated following the first repetition (the delay before being the Typematic Delay)) is determined by the setting of five bits.  The calculation given for this is:

Rate = (8 + A) x (2 ^ B) x 0.00417 seconds, where A and B are binary values of multiple bits (if you really care, I'll tell you what goes where).

To save any actual calculating, a table shows that setting all the bits low produces a Rate of 30.0 ± 20% make codes (effectively keystrokes for one byte [most] keys) per second, or approx. 3.336 (again, probably ± 20%) milliseconds per keystroke.

Furthermore, doing the typematic stuff likely "wastes" some of that time.  As it's eight data bits you have send for that Typematic Rate/Delay command, I have to wonder if the 8 and the "A" bits in the calculation are related to each bit of make code, possibly making the 0.00417 the per-bit execution time (of course, no explanation is given...).


So.

Proof that the protocol can deal with sending at least 30 characters per second, and so could early controllers (albeit with the same key.  They are still scanning for other keys in Typematic mode: Hold down a key, then hold down another key, then another...).  Just how much quicker could modern controllers be?  How much quicker might they have been even then (see above at "oscilloscope")?

If we can get the matrix right, n-key rollover within regular numbers of human digits is quite possible...

pex:
Well I'm just going to scrape up my membrane sheet and add diodes everywhere I can.

Unfortunately I know neither which type of diode (there are so many!) that I need nor do I know how (yet) I will be able to fit them in the little space provided by IBM/Lexmark.

Navigation

[0] Message Index

[#] Next page