Author Topic: Rollover, where keyboard data might go, and ramble  (Read 12181 times)

0 Members and 1 Guest are viewing this topic.

Offline dw_junon

  • Thread Starter
  • Posts: 96
    • http://www.9999hp.net/
Rollover, where keyboard data might go, and ramble
« on: Sun, 27 January 2008, 13:11:42 »
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


I'll be doing some path tracing so I can update this page with a solution.

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:
  • 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.
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...
ARC/Chicony KB-5181 XT/AT blue ALPS? 101 US FCC ID E8H51KKB-5181 • AST ASTKB102 AT capacitive rubber dome 102 UK ISO
Cherry G80-2100 AT black Cherry 126 key German ISO unique • Compaq Enhanced III PS/2 unknown rubber dome 102 UK ISO
Datacomp DFK102ARA03 AT 102 blue ALPS? US/Arabic FCC ID blank, S/N 37880001 • Dell AT102W PS/2 Black ALPS 105 UK ISO x2
Fujitsu KFB4725-102 AT membrane rubber dome with spring 105 UK ISO • Hewlett Packard C1405A AT rubber dome 102 UK ISO
IBM 0989705 XT/AT no LEDs Model M 102 US/Arabic  • IBM 1388076 Industrial AT Model M 102 UK ISO
IBM 1389260 3179/3180 Display Station Model M 122 US 3270 x2 • IBM 1391406 PS/2 Model M 102 UK ISO x2
IBM 1397003 PS/2 Model M "Host Connect" emulator 122 German ISO • IBM 71G4643 PS/2 Model M Quiet Touch "Ouch!    Rubber spring" 102 UK ISO x2
IBM 5640987 3178 Display Station Model C2 capacitive buckling spring 87 key US 3270 • IBM 556-712-01 RT PC rubber dome [same as 2nd PCjr kbd?] 101 US
IBM 6450225 PC/AT capacitive buckling spring 84 key UK PC/AT • Lexmark 8125460 Model M2 102 UK ISO
NMB RT-102 117456-002 AT Hi-Tek black, clicky 102 UK ISO • Olivetti ANK 2462 M24 Personal Computer keyboard 2 clicky Olivetti spring module 102 UK unique
Ortek MCK-142Pro AT white ALPS 142 key UK • Sun 540-1006-03 Type unknown linear(?) keyswitch 2 87 key SunType2
Wang 724 725-3771-UK salmon ALPS 110 key UK Wang724 • Making this list hasn\'t half scared me...
[/I]

Offline dw_junon

  • Thread Starter
  • Posts: 96
    • http://www.9999hp.net/
Rollover, where keyboard data might go, and ramble
« Reply #1 on: Sun, 27 January 2008, 13:12:45 »
"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.
ARC/Chicony KB-5181 XT/AT blue ALPS? 101 US FCC ID E8H51KKB-5181 • AST ASTKB102 AT capacitive rubber dome 102 UK ISO
Cherry G80-2100 AT black Cherry 126 key German ISO unique • Compaq Enhanced III PS/2 unknown rubber dome 102 UK ISO
Datacomp DFK102ARA03 AT 102 blue ALPS? US/Arabic FCC ID blank, S/N 37880001 • Dell AT102W PS/2 Black ALPS 105 UK ISO x2
Fujitsu KFB4725-102 AT membrane rubber dome with spring 105 UK ISO • Hewlett Packard C1405A AT rubber dome 102 UK ISO
IBM 0989705 XT/AT no LEDs Model M 102 US/Arabic  • IBM 1388076 Industrial AT Model M 102 UK ISO
IBM 1389260 3179/3180 Display Station Model M 122 US 3270 x2 • IBM 1391406 PS/2 Model M 102 UK ISO x2
IBM 1397003 PS/2 Model M "Host Connect" emulator 122 German ISO • IBM 71G4643 PS/2 Model M Quiet Touch "Ouch!    Rubber spring" 102 UK ISO x2
IBM 5640987 3178 Display Station Model C2 capacitive buckling spring 87 key US 3270 • IBM 556-712-01 RT PC rubber dome [same as 2nd PCjr kbd?] 101 US
IBM 6450225 PC/AT capacitive buckling spring 84 key UK PC/AT • Lexmark 8125460 Model M2 102 UK ISO
NMB RT-102 117456-002 AT Hi-Tek black, clicky 102 UK ISO • Olivetti ANK 2462 M24 Personal Computer keyboard 2 clicky Olivetti spring module 102 UK unique
Ortek MCK-142Pro AT white ALPS 142 key UK • Sun 540-1006-03 Type unknown linear(?) keyswitch 2 87 key SunType2
Wang 724 725-3771-UK salmon ALPS 110 key UK Wang724 • Making this list hasn\'t half scared me...
[/I]

Offline pex

  • Posts: 145
Rollover, where keyboard data might go, and ramble
« Reply #2 on: Sun, 27 January 2008, 17:04:36 »
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.)
Ж®Cherry G80-8113 (someday I hope to have one that reads magstripes, rfid cards, and smartcards), broken \'98 42H1292 Model M, some other Model M from a decade before that, 30 more keyboards in a box, 4 more lying here or there
Destroying Sanctity: my Model M project. Status: Dead.

Offline dw_junon

  • Thread Starter
  • Posts: 96
    • http://www.9999hp.net/
Rollover, where keyboard data might go, and ramble
« Reply #3 on: Tue, 29 January 2008, 17:45:36 »
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...
ARC/Chicony KB-5181 XT/AT blue ALPS? 101 US FCC ID E8H51KKB-5181 • AST ASTKB102 AT capacitive rubber dome 102 UK ISO
Cherry G80-2100 AT black Cherry 126 key German ISO unique • Compaq Enhanced III PS/2 unknown rubber dome 102 UK ISO
Datacomp DFK102ARA03 AT 102 blue ALPS? US/Arabic FCC ID blank, S/N 37880001 • Dell AT102W PS/2 Black ALPS 105 UK ISO x2
Fujitsu KFB4725-102 AT membrane rubber dome with spring 105 UK ISO • Hewlett Packard C1405A AT rubber dome 102 UK ISO
IBM 0989705 XT/AT no LEDs Model M 102 US/Arabic  • IBM 1388076 Industrial AT Model M 102 UK ISO
IBM 1389260 3179/3180 Display Station Model M 122 US 3270 x2 • IBM 1391406 PS/2 Model M 102 UK ISO x2
IBM 1397003 PS/2 Model M "Host Connect" emulator 122 German ISO • IBM 71G4643 PS/2 Model M Quiet Touch "Ouch!    Rubber spring" 102 UK ISO x2
IBM 5640987 3178 Display Station Model C2 capacitive buckling spring 87 key US 3270 • IBM 556-712-01 RT PC rubber dome [same as 2nd PCjr kbd?] 101 US
IBM 6450225 PC/AT capacitive buckling spring 84 key UK PC/AT • Lexmark 8125460 Model M2 102 UK ISO
NMB RT-102 117456-002 AT Hi-Tek black, clicky 102 UK ISO • Olivetti ANK 2462 M24 Personal Computer keyboard 2 clicky Olivetti spring module 102 UK unique
Ortek MCK-142Pro AT white ALPS 142 key UK • Sun 540-1006-03 Type unknown linear(?) keyswitch 2 87 key SunType2
Wang 724 725-3771-UK salmon ALPS 110 key UK Wang724 • Making this list hasn\'t half scared me...
[/I]

Offline pex

  • Posts: 145
Rollover, where keyboard data might go, and ramble
« Reply #4 on: Wed, 30 January 2008, 10:40:12 »
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.
Ж®Cherry G80-8113 (someday I hope to have one that reads magstripes, rfid cards, and smartcards), broken \'98 42H1292 Model M, some other Model M from a decade before that, 30 more keyboards in a box, 4 more lying here or there
Destroying Sanctity: my Model M project. Status: Dead.

Offline Nonmouse

  • Posts: 298
Rollover, where keyboard data might go, and ramble
« Reply #5 on: Wed, 30 January 2008, 13:16:17 »
Quote from: pex;2684
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.


Well, after taking a gander at the diodes in my Cherry G80-8113 board and wandering around the interwebs, I came up with either 1N914 or 1N4148 fast switching diodes.  I then went and looked at the Keyboard Matrix Help page, and the author (Dave Dribin) has a section—"9. What Diode Parts to Use"— where he recommends either 1N4001 or 1N4148 diodes, with the 1N4148 having a much faster switching time (probably overkill fast).  

I also found a place that has 1N4148 diodes at $1.00/100 pcs.  Shipping's $7, but they've got all kinds of other cool junk (full-on geek candy store) that you could toss in to make the shipping worth it.

As far as fitting them in, they're a bit smaller than a grain of rice, with~ 1 cm leads (of course, you can clip them shorter), so fitting them in shouldn't be any problem at all. The easiest thing to do would probably be to solder them to the pins on the bottom of the circuit board, then scrape across the original circuit path with an exacto blade (if you don't break the old circuit, it'll just bypass the diode)

Oops.  I just went and found a picture of the guts of a Model M board—the contacts are actually on a flexible sheet (looks like mylar) with the circuit runs printed on it.  I'm sure there's got to be a way to insert diodes in the circuits.  Anyone know anything about soldering leads to a mylar sheet, lol?  Mebbe use conductive epoxy?  I suppose if worse comes to worst, you could etch an actual circuit board for the bottom contact sheet, and solder the diodes to that.  Hmmm... I've got a bunch of circuit board blanks kicking around, and some crappy membrane keyboards that could be donated for research.  Maybe I'll put that on the list of hack projects.  Would anyone be interested in an n-key rollover Model M?  :D

Offline Mikecase00

  • Posts: 74
    • http://www.mikecase.net
Rollover, where keyboard data might go, and ramble
« Reply #6 on: Wed, 30 January 2008, 14:22:31 »
Quote from: Nonmouse;2687
Would anyone be interested in an n-key rollover Model M?  :D


What is the appeal of n-key rollover?  In what scenario would you need to reliably press more than 8 keys at a time (which seems possible for my 1391401 through a PS/2 interface)?  Eventually you start to run out of fingers to actuate keys with.  Assuming you have an 84 key board triggering 8-key combinations, you have thousands of unique potential key combinations, certainly far more than would be practical to remember.
IBM Model M 1391401 (dyed black) w/ keys from M-13
IBM M-13 Trackpoint (naturally black)
IBM Model M 1392934 SpaceSaver
Several plain IBM 1391401 Ms
Epson Equity Q203A
http://www.mikecase.net

Offline Nonmouse

  • Posts: 298
Rollover, where keyboard data might go, and ramble
« Reply #7 on: Wed, 30 January 2008, 15:02:25 »
Quote from: Mikecase00;2689
What is the appeal of n-key rollover?  In what scenario would you need to reliably press more than 8 keys at a time (which seems possible for my 1391401 through a PS/2 interface)?  Eventually you start to run out of fingers to actuate keys with.  Assuming you have an 84 key board triggering 8-key combinations, you have thousands of unique potential key combinations, certainly far more than would be practical to remember.


The biggest utility is for gamers.  I'm not a huge gamer, but one of the games I do play, I have trouble with rollover on my notebook keyboard- I think the combination is qwa (I just checked with the rollover test page; this is the combination that doesn't work).  A lot of games use closely clustered groups of keys for movement or firing or special actions for ease of play, but hitting several keys in the same row or column is the most likely scenario for dropping key presses.  On my notebook keyboard, for instance, most combinations of three or  keys in the same 2x2 block will only register 2, 1 or even 0 keys.  

The n-key rollover is more about ensuring that no combinations of keys will ghost or mask than about making sure you can press 84 keys at once.  (And, of course, there's the e-penis factor, too.)

Offline xsphat

  • Posts: 2371
  • Location: 'Sconi FTW
  • Enlightened
    • Dan Newman, Writer
Rollover, where keyboard data might go, and ramble
« Reply #8 on: Wed, 30 January 2008, 15:36:27 »
Quote from: Nonmouse;2690
(And, of course, there's the e-penis factor, too.)


:)


I hate the minimum post length. I wish iMav would change it.

Offline Mikecase00

  • Posts: 74
    • http://www.mikecase.net
Rollover, where keyboard data might go, and ramble
« Reply #9 on: Wed, 30 January 2008, 17:12:59 »
Quote from: Nonmouse;2690
The biggest utility is for gamers.  I'm not a huge gamer, but one of the games I do play, I have trouble with rollover on my notebook keyboard- I think the combination is qwa (I just checked with the rollover test page; this is the combination that doesn't work).  A lot of games use closely clustered groups of keys for movement or firing or special actions for ease of play, but hitting several keys in the same row or column is the most likely scenario for dropping key presses.  On my notebook keyboard, for instance, most combinations of three or  keys in the same 2x2 block will only register 2, 1 or even 0 keys.  

The n-key rollover is more about ensuring that no combinations of keys will ghost or mask than about making sure you can press 84 keys at once.  (And, of course, there's the e-penis factor, too.)


I'm not an avid gamer anymore, and I can't speak to your laptop or any other keyboard, but I've got to think that a PS/2 connected model M (with its 16 char buffer) would be more than sufficient.  Plus, can't you re-map keys to work around the 2x2 block issue?

I think I read once that USB spec for keyboards is somehow more limited than PS/2 in the number of keys they can support pressed all at once.  If that's the case, USB keyboards (of which most are these days) are poor choices for gaming because it's the interface that's the limiting factor.  Upgrading the board with additional electronics isn't going to make the USB pipe any better.  If your only connection option for a Model M is USB you'd be out of luck as well.

To have full n-key rollover support you need several things.  Starting with the keyboard, it needs to register multiple key presses independently, not as blocks with other keys.  The board needs an on-board char buffer to temporarily hold key press data until the computer is ready to receive it, not just dump the key presses to the interface as they come in.  The keyboard to computer interface needs to accept and support transmit of multiple key presses simultaneously, and finally the OS software needs to be able to support n-key rollover.  

Before I got out my soldering iron I'd adding things to the keyboard, I'd want to make sure everything downstream of my board can accept the additional key press data.  Otherwise you'll end up with a kick-ass keyboard that performs exactly like the $5 Officemax special.
IBM Model M 1391401 (dyed black) w/ keys from M-13
IBM M-13 Trackpoint (naturally black)
IBM Model M 1392934 SpaceSaver
Several plain IBM 1391401 Ms
Epson Equity Q203A
http://www.mikecase.net

Offline pex

  • Posts: 145
Rollover, where keyboard data might go, and ramble
« Reply #10 on: Wed, 30 January 2008, 20:50:53 »
I'll be a closet n-key rollover guy, no one needs to know.  I just need to know I can PWN!

The (mostly likely) reason to want n-key rollover is not so you can press 20 keys at once but that you can be sure you can press any keys at once with no question to that ability.  Any section of the keyboard is different than any other section in physical layout (on a standard 102/3/4 ibm keyboard), so you really want that option, especially for games, to choose which section of the keyboard you're using.

I'm not a WASD guy (regarding FPS)...never was.  I think I started with arrows in Doom 2, although I'm not sure.  At some point (no recollection of when or why), I picked up a hands-crossed-over setup where I use the full numpad (must have done this playing Ice & Fire) and now to this day, Counter-Strike: Source.

I've got a picture of the crossover if you can't imagine why or how someone would do that; it'll go up my solutions page probably with a short blurb about n-key rollover.

You need to understand that a grain of rice is very important to how the keyboard will respond.  On top of the metal plate is the bottom membrane, with the connection circles and paths.  it is separated by a sheet of similar thickness of the membranes, with holes for the contacts, and a top layer.  They lay flat on top of one another.  On top of them is the black sheet, and then the plastic keyboard shell which houses the springs/pedals and on top, the keys.

I guess I did forget that there is some room under the plastic key-holding shell; however, 100 grains of rice in between the membranes will have what I'm guess will be a serious effect on typing feel and possibly performance.  With a bunch of rerouting I'm sure it's very doable.  It's just then going to take a lot of engineering time.  I'd prefer flatter diodes. :p

I wish Dave Dribin would have been clearer on why it is switching diodes (or these! switching diodes) we want.  I guess it sounds 'okay' enough from a limited technical perspective, but did he measure up voltages (will I have the appropriate amount to beat clamping voltage)?  Does the Radio Shack clerk mod keyboards?  If i could slip this stuff in/out without a lot of planning, a few bucks for diodes may not be a big deal.  However...reality...

Cost VS Invasiveness VS Time

I suppose as a test it is really only important I fix up one set of keys that interferes (after proving I can predict what keys interfere).
Ж®Cherry G80-8113 (someday I hope to have one that reads magstripes, rfid cards, and smartcards), broken \'98 42H1292 Model M, some other Model M from a decade before that, 30 more keyboards in a box, 4 more lying here or there
Destroying Sanctity: my Model M project. Status: Dead.

Offline Nonmouse

  • Posts: 298
Rollover, where keyboard data might go, and ramble
« Reply #11 on: Wed, 30 January 2008, 20:59:55 »
Quote from: Mikecase00;2692
I'm not an avid gamer anymore, and I can't speak to your laptop or any other keyboard, but I've got to think that a PS/2 connected model M (with its 16 char buffer) would be more than sufficient.  Plus, can't you re-map keys to work around the 2x2 block issue?

I think I read once that USB spec for keyboards is somehow more limited than PS/2 in the number of keys they can support pressed all at once.  If that's the case, USB keyboards (of which most are these days) are poor choices for gaming because it's the interface that's the limiting factor.  Upgrading the board with additional electronics isn't going to make the USB pipe any better.  If your only connection option for a Model M is USB you'd be out of luck as well.

To have full n-key rollover support you need several things.  Starting with the keyboard, it needs to register multiple key presses independently, not as blocks with other keys.  The board needs an on-board char buffer to temporarily hold key press data until the computer is ready to receive it, not just dump the key presses to the interface as they come in.  The keyboard to computer interface needs to accept and support transmit of multiple key presses simultaneously, and finally the OS software needs to be able to support n-key rollover.  

Before I got out my soldering iron I'd adding things to the keyboard, I'd want to make sure everything downstream of my board can accept the additional key press data.  Otherwise you'll end up with a kick-ass keyboard that performs exactly like the $5 Officemax special.


Well, yeah, you can re-map controls, but it can start getting to be a pain in the ass- especially if you're trying to do two directionally-dependent actions (the qwa combination happens when moving forward, firing to the left and steering to the left).  The masking is pretty clearly happening because of the overlay of the matrix mapping, which diodes would eliminate.  (Not that I'm planning on trying anything like this on my notebook- at least not until I've got a really good handle on it)

Yeah, as I understand it, the USB protocol only supports 6 characters at a time- I guess the protocol committee members weren't gamers.

The Model M 16 character buffer is a great thing, and one of the reasons I think that it'd be worth popping diodes in the matrix.  I haven't got a Model M yet, but from what I understand, it does exhibit ghosting and masking of keys in certain combinations- which is exactly what diodes would fix.  Frankly, etching a circuit board wouldn't be all that big a deal- scan the contact sheet from the keyboard, invert the image, print it out on a laser printer, iron the the toner onto the board, dip it in etchant, wash it and buff it, drill the holes.  A few hours work at most.  The only possible problems I see are fitting it in the case, which I don't think should be too hard- at worst, you could pull the metal plate out- and whether the carbon would make a decent contact with copper.  Even if it didn't, drops of conductive ink over each spot should fix that.  Besides, hacks don't need to to make sense- they're done for the fun and the cool factor.  The more obscure and arduous the process required to come up with a slightly improved product the better, at least for the bragging rights . :D

Offline pex

  • Posts: 145
Rollover, where keyboard data might go, and ramble
« Reply #12 on: Thu, 31 January 2008, 03:03:10 »
Selling "xRAREx IBM Skeletor(tm) Model M xRAREx"!



Working keyboard, numlock is on :)

It's a ***** to try to get those membrane leads to connect together and get the controller board to mate at the same time.  I used 4 magnets and hoped I lined everything up.  Hopefully I don't accidentally zap anything when the leads get knocked out of alignment!

I don't know if etchant is also a surfactant or something horrible...maybe instead of this PCB bollocks (which seems to me still requires the membrane to be altered or a new one created), why don't I print toner on a transparency sheet (17x11) and etch from there, and then just work with a component test board?  Someone forgot how pcb etching works.  :rolleyes:

I'm not really a believer in death and destruction for the sake of discovery unless the achievement can be proven great and unattainably only with said death and destruction.  I know my Model M is broken, but I am SIMULTANEOUSLY! trying to fix it and learn from it.  :D
Ж®Cherry G80-8113 (someday I hope to have one that reads magstripes, rfid cards, and smartcards), broken \'98 42H1292 Model M, some other Model M from a decade before that, 30 more keyboards in a box, 4 more lying here or there
Destroying Sanctity: my Model M project. Status: Dead.

Offline grantb3

  • Posts: 8
Rollover, where keyboard data might go, and ramble
« Reply #13 on: Thu, 07 February 2008, 11:12:21 »
Quote from: Nonmouse;2696
Yeah, as I understand it, the USB protocol only supports 6 characters at a time- I guess the protocol committee members weren't gamers.

The 1N4148 diodes are very typical for this application.  The '914 is also acceptable.

There are some keyboards that use their own driver, and hence overcome the 6-key limitation of USB.  You also need to consider that low-speed USB has a report rate of only once every 10ms, whereas a full-speed USB keyboard could be as fast as 1ms (you need to look at the USB descriptors to know).  Sorry I don't know which keyboards fit this bill, but I'm sure those that do advertise it because it's very important -- just like the rollover issue.

You might also want to consider a programmable add-on keypad.  Genovation.com makes some.  The ControlPad 683 (and similar) are low speed USB, but you can stack up keys in macro format (if that helps) or map the keys how you like.  In themselves the 683's don't have n-key rollover, but with the macro capability you might not need it.  The MiniTerm family (900 series) is full speed and I think they have a 2ms report rate.  Again they don't support n-key rollover but they have an HID mode that supports limited macros.  Anyway, an add-on keypad from wherever might solve some of your gaming issues.

Offline iMav

  • geekhack creator/founder
  • Location: Valley City, ND
  • "Τα εργαλεία σας είναι σημαντικά."
Rollover, where keyboard data might go, and ramble
« Reply #14 on: Thu, 07 February 2008, 14:12:43 »
Thanks for the info grantb3.

And welcome to geekhack!  ;)