Making a cheap Model M USB controller

[Mnemonix]

[SIZE=+1]How to build a USB controller for your keyboard.[/SIZE]

Some time ago I've noticed that my IBM Personal System/2 Space Saving Keyboard (or just my "Mini") had a little problem: the controller would heat up during operation, and I feared it could fail some time. So I replaced the original controller with a homebrew USB controller running my custom Keyboard Upgrade firmware. I've done this before for another M, but this time I took some pictures of the progress and documented how I have built the controller.

Even though I only needed the controller for a Model M Mini (i.e., no LEDs), I thought it would be a good idea to build one that could also be used in a full-size 1391401, and hence make these instructions more useful for more people. I tested the controller in a 1391403 (which is a 1391401 with the annoying German layout) to make sure it would really fit in there and work as it should--which it does.

Since I didn't want to handle chemicals and also wasn't ready to spend serious money on a professionally etched PCB, I used stripboard for making the controller. Unfortunately, stripboards are a mess, so most of this post describes how I treated a stripboard to recreate the design found on this page. Scroll all way down to the end of this post for some notes on "real", etched PCBs.

Meanwhile, my industrial gray Model M Mini has arrived, which I am using now instead of my other Mini. I moved the USB controller over to the gray Mini, and this is what it looks like:





Must be the most modern industrial Mini in the world! :D


[SIZE=+1]Materials and tools[/SIZE]

Materials used:

[*]One "standard" piece of stripboard (100 x 160 mm, 2.54 mm pitch). These are available in various qualities. I opted for a higher quality fiberglass board because the cheaper phenolic boards tend to smell quite a bit. The smell can be very annoying as I have learned by using such a board in my IBM M4-1.
[*]One AVR ATMega16 or ATMega32 in DIL-40 package. The bigger ATMega32 is slightly more expensive, but also has more EEPROM capacity, allowing you to store more key maps on your controller. I'll recommend the ATmega32 unless you are extra cheap or have an ATMega16 lying around anyway.
[*]DIL-40 IC socket
[*]6-pin single row jumper header, 2.54 mm pitch
[*]6-pin dual row jumper header, 2.54 mm pitch
[*]resistors: 2 x 68 Ohm, 3 x 470 Ohm, 1 x 2.2 kOhm, 1 x 4.7 kOhm, 1 x 10 kOhm
[*]capacitors: 2 x 22 pF, 1 x 100 nF
[*]2 x 3.6 V Z-diodes
[*]12 MHz crystal oscillator
[*]USB type B receptacle connector, right angle, solder type
[*]3 x FFC connector (flat flexible cable connectors), 2.54 mm pitch, vertical PCB mount type. You'll need one with 8 and one with 16 terminals for connecting the keyboard matrix, and another one with 4 terminals for the LEDs. It might be hard to obtain these--in worst case you could sacrifice your original IBM controller and desolder its connectors.
[*]loads of wires
[*]thick wire and a ring terminal for grounding
[/LIST]

Tools used:

[*]soldering iron, solder, etc.
[*]diagonal pliers
[*]wire stripping pliers
[*]cutter knife
[*]file
[*]multimeter (to check for shorts)
[*]Dremel rotary tool (optional)
[*]3.5 mm and 2 mm drill bits, and a drill
[*]5.5 mm socket wrench to open the keyboard (check out this thread if you don't have one already)
[/LIST]

(And yes, I am ignoring medieval ways for specifying lengths. This world is metric. Get used to it. ;) )


[SIZE=+1]Build![/SIZE]

So, here are the instructions for building a cheap IBM Model M USB controller... Please read the instructions in full length before attempting to build your own.
The resolution of some of the pictures below may not be high enough to show all the necessary details. Therefore, I have attached larger versions here and here.

First, cut the stripboard into pieces as illustrated on the following picture using a Dremel or a cutter knife (which is harder). It is OK for the bigger pieces to be a tad larger than shown on the picture since the size of the USB board is not as critical. The main board should not be smaller than shown on the picture. If done correctly, you'll end up with four pieces that could actually be used to make two controllers: two bigger pieces with 39x20 holes, and two smaller 19x20 ones.



File down one of the long sides of the main board until it fits easily into the tray where the old controller was (don't force it in!), right next to the two poles that hold the controller in its place.
Drill the USB board as shown on the next picture. The smaller holes will pick up the USB connector. The bigger holes should fit over the two poles at the gap for the SDL connector so that the board is held in its place just like the old controller was (later, we will attach the USB board to the main board so that they appear as a single board). Make sure to remove enough copper surrounding the big holes so that it cannot eat into or otherwise damage the plastic poles. Again: don't force anything here and make use of your tools!

Now as the boards are correctly sized and drilled, cut the copper strips in the red-marked areas as shown below. I used a Dremel for the coarse cuts, and a cutter knife to rework some improperly cut strips. Double-check for shorts with a multimeter.





We'll be running wires from underneath the IC socket, so you'll need to make sure that there is enough room to route some wires below the short sides of the socket. (Scroll down a bit and look at one of the pictures with the IC socket soldered in to see what I mean.) My socket had some ridges on both sides standing in the way which I had to remove with a cutter knife like this:



That's it for the mechanical work, you may stow away your Dremel now. Heat up your soldering iron and start soldering some wires onto the stripboard as shown on the next two pictures. There are direct connections between neighboring copper strips in the two green marked areas; these are intended and no mistakes.





What follows is a list of the wire connections seen on the pictures.
Holes are identified using the coordinate system displayed on the pictures; e.g., coordinate 4/9 means row 4, column (or copper strip) 9.

Code: [Select]

Blue               White             Red            Direct
 4/ 9 -  5/12       5/20 -  5/27     17/12 - 17/24   6/28 -  6/29
 4/10 -  5/13       6/24 -  6/28     18/10 - 18/23   6/29 -  6/30
 4/11 -  5/14       9/15 -  9/29                    17/11 - 17/12
 4/12 -  5/15       9/17 -  9/30                    (9/27 -  9/28)
 4/13 -  5/16       9/27 -  9/28 [2]
 4/14 -  5/17      13/23 - 13/37
 4/15 -  5/18      14/ 2 - 14/13 [3]
 4/16 -  5/19      14/ 4 - 14/12 [3]
10/18 - 10/39 [1]
10/19 - 11/38 [1]
10/20 - 11/36 [1]

[1] End points are not connected in these pictures yet. See below.
[2] Can be replaced by a "green" direct connection, but I didn't think of this at the time...
[3] Bend wires, do not make a straight connection. See below.

I kept the three long blue wires rather long and loose on one end because I didn't know how long they should really be at that point. You may just take a look at one of the later pictures to get their lengths right in the first place. :)
The two white wires 14/2-14/13 and 14/4-14/12 need to run around the programming connector that is soldered in later. Hold the 6-pin jumper header at 14/6-14/11 and route the wires around it to get them right; also check out the pictures below. I didn't solder the header in at that point, however, because it would have stood in the way all the time.

Next come 8 wires that you'll need to make long enough to "flow around" the IC socket (look at one of the next pictures to get an idea). Hold the socket into its later place--rows 6 and 12 and starting in column 1--to get the lengths right (I didn't really measure their lengths). I've actually made the four "inner" wires a bit too short for this controller, which is why they are sitting rather tight around the socket...



Connections:

Code: [Select]

10/1 - 4/23  10/5 - 4/27
10/2 - 4/24  10/6 - 4/28
10/3 - 4/25  10/7 - 4/29
10/4 - 4/26  10/8 - 4/30

This is how your controller should look like after putting in the IC socket, dual row jumper header, and soldering the three loose ends mentioned before:



This is a good time to double-check all connections. Are there any shorts? Do the connections work? Any weak solder joints? This is really important--do yourself a favor and don't skip this step.

We'll carry on by soldering in the components. I've added the 8 resistors and 3 capacitors for the next picture. No new wires here.



Components:

Code: [Select]

Resistors                 Capacitors
 4/36 -  9/36 (470 Ohm)   13/11 - 13/12 (22 pF)
 4/38 -  9/38 (470 Ohm)   16/10 - 16/11 (100 nF)
 4/39 -  9/39 (470 Ohm)   16/12 - 16/13 (22 pF)
10/22 - 10/24 (4.7 kOhm)
11/22 - 11/23 (2.2 kOhm)
13/14 - 13/22 (68 Ohm)
14/16 - 14/21 (68 Ohm)
16/ 9 - 16/23 (10 kOhm)

Then, add the 2 Z-diodes, crystal oscillator, programming header, and the FFC connctors for the keyboard matrix. My version of this controller lacks the connector for the LEDs because I didn't have a spare one, so instead I've marked the place in the picture where the 4-pin connector should go. It should face in the same direction as the neighboring 8-pin connector, with the four legs soldered in the green marked area (row 3). Pay attention to the correct orientation of the FFC connectors (all of them!).



Components:

Code: [Select]

Z-diodes       Crystal
12/21 - 12/24  16/2 - 16/4
15/22 - 14/24

16-pin connector   :  2/ 1 -  2/16
8-pin connector    :  3/23 -  3/30
4-pin connector    :  3/36 -  3/39
6-pin jumper header: 14/ 6 - 14/11

The diodes are the only components in this circuit where polarity matters, so take care to solder them in in the correct orientation. The black rings mark the cathodes and go to holes 12/21 and 15/22, respectively.

Note that the 6-pin header for hooking up the AVR programmer is not exactly "the standard way to do it"; commonly, 6- or 10-pin IDC sockets are used for this. The six pins on this design, however, connect straight to pins 6 through 11 on the AVR, which is much more convinient on stripboard. Another reason to go with this solution is space: there is not enough room for an IDC socket in this location when putting the controller into a Mini.

If you are planning to use your controller in a Space Saving keyboard, then you still must cut the header pins to a shorter length so that they don't make contact with the metal plate of the keyboard assembly! There is really much less vertical space in a Mini than in a full-size Model M. Your best bet is to put the board into the keyboard case and take a good look if the pins are touching the plate when putting in the assembly; cut the pins accordingly while keeping them long enough to make contact with a programming connector. Make sure that the keyboard assembly is really in its place when doing this, i.e., it must be fully inserted and held in its place by the rectangular plastic poles at its top, and not "hang" or be otherwise misaligned.

So, most of your controller is ready by now. Solder the USB connector to the USB board, and add four long wires to the copper strips that run to the pins on the connector. The wires will provide the electrical connection between the smaller USB board and the larger main board. Their names are "GND", "+5V", "D-", and "D+", corresponding to the pins on the USB connector. Again, I didn't really measure the lengths of the wires...
Also add the thick grounding wire now that will go to the keyboard assembly--I forgot it at first, but added it later. Depending on the type of cable that you are using for this, you may need to drill the hole for the grounding wire a bit larger.





Connections:

Code: [Select]

Blue        Red         White       Direct
16/10 (D+)  16/8 (+5V)  16/7 (GND)  3/7 - 3/ 8
16/ 9 (D-)                          3/9 - 3/10

Grounding wire: 10/7

USB connector: pins at 4/8, 4/9, 5/8, and 5/9

We are still missing the mechanical connection between the two boards in order to get "one" controller board. As seen already on the previous picture, I used some junk wire that I've cut off from the resistors to tie them together (do not forget to remove the copper from the area around the holes when using wire!). The connection is flexible and not overly stable, a bit like a hinge, but that's more than we need. Here is a close-up of the two "wire hinges" marked by green circles:



Alright, here is the last step: connect the four wires to the main board. This picture also shows the grounding wire that I have added a bit too late (at hole 10/7):





Connections:

Code: [Select]

Blue        Red          White
19/21 (D+)  19/10 (+5V)  19/11 (GND)
19/22 (D-)

Check again all solder joints, at least visually. Take good care that there are no connections between neighboring copper traces where there should be none. Sometimes these accidental connections are hard to spot, so take a good final look.


Well done!

The hardware is ready to be programmed now.




Here is the pinout of the programming header on the controller. Your AVR programmer will likely have a 6-pin or a 10-pin IDC socket, or both. Build an adapter cable according to one of the following pinouts in order to program the AVR on the controller. Do not plug the controller into your computer's USB plug when attaching the programmer to the programming header!

Code: [Select]

6-pin at   | header pin on    10-pin at  | header pin on
 programmer | controller       programmer | controller
------------+---------------  ------------+---------------
 1 (MISO)   | 2                1 (MOSI)   | 1
 2 (+5V)    | 5                2 (+5V)    | 5
 3 (SCK)    | 3                3 (NC)     | -
 4 (MOSI)   | 1                4 (GND)    | 6
 5 (nRESET) | 4                5 (nRESET) | 4
 6 (GND)    | 6                6 (GND)    | 6
                               7 (SCK)    | 3
                               8 (GND)    | 6
                               9 (MISO)   | 2
                              10 (GND)    | 6





This is my cable:



A bit rough--I know you can make a nicer one! :)

If you don't want to make an adapter cable, see here for a "quick how-to guide on making ultra-simple development boards for programming AVR microcontrollers". Really simple, and saves you from building a custom cable.
Note: you should probably add a 12 MHz crystal oscillator and two 22 pF capacitors to the board (in the same places as on the keyboard controller) so that the AVR would still work after programming its fuses to actually make use of an external crystal oscillator...


[SIZE=+1]Jumpers[/SIZE]

There are three jumpers on the controller, in columns 28, 29, and 30. For normal operation, all of these should be left open.



Only one of the jumpers is used by the firmware at the moment, called KM0 (for Key Map 0), located in column 28. Closing KM0 forces the controller to use its built-in QWERTY key map. Use this in case you have activated a broken key map and cannot switch back to a good one anymore.


[SIZE=+1]Programming the boot loader and firmware[/SIZE]

The AVR needs, to the very least, a boot loader so that the main firmware can be programmed from your computer via USB. Firmware and boot loader images can be downloaded from http://sourceforge.net/projects/kbupgrade/files/Firmware, sorted by keyboard model and AVR type. Choose the 1391401 version for a 1391401, and the 1392934 version for the Mini; the latter simply lacks LED and numpad support.

There is a file called file_id.diz in the zip archives that documents which values your AVR's fuses must be programmed to for the particular firmware. After programming the low and high fuses, write the boot.hex image to your AVR. You need to do this only once and not again for later updates. Then, program the main.hex image to the AVR, and lock the boot loader by programming the lock fuse to the value given in the file_id.diz file.

Note that for updating the firmware or uploading alternative key maps via USB you'll still need to build the corresponding tools from the sources for now. I do not have pre-compiled binaries of the required tools right now (too much extra work to keep them up-to-date for multiple operating systems and package management systems). Maybe I can build them for you on demand.

If you prefer to build the firmware (and tools) from scratch, you can download source tarballs from http://sourceforge.net/projects/kbupgrade/files/Source or pull the latest sources from GitHub at http://github.com/rhomann/kbupgrade. Follow the instructions given in the INSTALL file.

That's all. Put your new controller into your keyboard and stow away or sell the original controller. :)
Plug in, and it should be recognized as a generic USB keyboard. For more documentation, read the INSTALL file from the firmware sources (yes, the docs should be split somehow).

Have fun!


[SIZE=+1]But wait! Look at all those wires! I don't wanna mess with stripboards![/SIZE]

If you prefer an etched PCB and are able to produce one by yourself, you may want to take a look at either Dulcimer or RUMP. The relevant files are also found in my source tree.

Both of the designs are compatible with my firmware, but only the Dulcimer design incorporates a connector for the LEDs.

Note that both designs were made with a full-size 1391401 Model M in mind, which has significantly more spare space than a Mini, especially in vertical direction. If you are planning to build a controller for your Mini using one of these designs, then double-check that it will fit into the keyboard and that no component will touch the metal plate!

Programming works just like with the stripboard version, of course.

[itlnstln]

Strong work.  That's pretty sweet. Congrats.

[msiegel]

beautiful

[keyb_gr]

:Cry:


EDIT: Stylish to the rescue - here's a hotfix for overly wide images in the Wiki. Scrolling over them is painfully sluggish but at least I can read the text now. Grmbl.

Code: [Select]

@-moz-document url-prefix("http://geekhack.org/showwiki.php?") {
  img {
    max-width: 1160px;
    }
}
EDIT^2: Nice tutorial, well done!

[itlnstln]

I wonder why the Wikis don't resize pics/wrap text as well as the rest of the forum.  The dark theme isn't quite as bad, though.  At least it's readable.

[Mnemonix]

:Cry:

Hm... I thought the forum's automatic image resizer would take care of the wide pictures, but apparently it does not in this case. ;(

I could reduce the image sizes, but I'm afraid that some important details will become invisible then. Suggestions?

[Specter_57]

Yesss....

very nice project.

Well done!

Spec57

[kishy]

This looks fantastic...I wonder how adaptable this would be to 122-key terminal keyboards?

Would just need to compensate for the larger and different matrix (easier said than done I'm sure).

[keyb_gr]

Hm... I thought the forum's automatic image resizer would take care of the wide pictures, but apparently it does not in this case. ;(

This has been on the "things to bug iMav with" list for a while...

I could reduce the image sizes, but I'm afraid that some important details will become invisible then. Suggestions?

Here's the worst offender in terms of width, brought to half size in XnView with the tried and true Lanczos algorithm:

Anything missing?

Leave it the way it is.  Bigger pics are more important that minor scrolling issues.  There is a light background option too at Geekhack.  Of course if his monitor was CALIBRATED it wouldn't even have that issue.

Content is King.

:mmph:

If it takes enhanced geek wizardry to REDUCE the original problem of 1/3 unreadable text to a minor scrolling issue mainly noticeable on slower machines like mine, I would consider it anything but negligible. That, and I don't see why I would have to apologize for using a "mere" SXGA monitor. Ridiculous. And of course I'm using the light theme, but that one still has a dark border.

Sometimes I enjoy smartass comments as much as the plague.

[itlnstln]

You're swine, ripster.

[itlnstln]

I wonder if you could use this to build controllers for other keyboards, say, f*cked up Fukkas.

[msiegel]

How come Stupid Americans haven't built this before???

i believe that's the non-usb version, suitable for PS/2. and you'd also need to build or buy a programmer...

[roadblock2thesun]

Excellent post... I had been reading through the other thread ripster mentioned and thinking "I wish someone would post a tutorial."

Thank you again

[Mnemonix]

Anything missing?

It really sucks reading this on my tiny 1024x768 laptop screen. I've down-scaled all pictures to a width of 800 pixels, and attached two zip files containing the full-size versions of the pictures. The page is more readable now, and if someone needs the bigger pictures they are still there.

How come Stupid Americans haven't built this before???

The American version is called RUMP, linked from the article. The hardware is very similar to Dulcimer.

I wonder if you could use this to build controllers for other keyboards, say, f*cked up Fukkas.

Well, the software is designed to be easily adaptable for other keyboards, but it is not fully generic as AIKON. Each keyboard model needs a specific firmware that has the keyboard matrix hard-coded, but most of this code is generated from a matrix definition file. The software is really the most complicated thing in this project.

The hardware described in the article is specific to the Model M: the board size and placement and types of the connectors are made so that the controller can be used as a drop-in replacement for the original controller. Other than that, it could also be used for other keyboards. It's just a matter of adapting the software.

[kishy]

How about my programming the controller question.  Do you need special HW or can this be done somehow with a simple USB to PC connecton to load the bootloader?

This. Want know.

Brain shutting down. Ebay seller responses killing cells. Self protection time.

[Mnemonix]

How about my programming the controller question.  Do you need special HW or can this be done somehow with a simple USB to PC connecton to load the bootloader?

Ah, you'll need a programmer for AVR microcontrollers. There are lots of different models available, you can even build them yourself. I've bought a kit for ~15 Euros off from EBay: PCB, components, and pre-programmed microcontroller for this.

Hm, maybe I can write more about this tomorrow, no time left now.

[msiegel]

this is why i got a teensy... it has usb, and can program *itself*. uses the arduino software.

at $20, this was easier on my simple-minded brain  the $24 one has way more i/o pins if needed.

otherwise... AVR programmers @ adafruit

[Mnemonix]

Would this work?

Both would work, I think, even if the descriptions do not list the MCU types they can program.
That assembly kit is really cheap and should be good enough. My kit looked similar and took maybe an hour to make.

This and this should be OK, too. The USBtinyISP at adafruit is also fine and comes with a case.

The question is which software you will be using to speak with the programmer. All of the devices mentioned so far are supported by AVRDUDE, an open source tool which I am using all the time. There are also pre-compiled binaries for Windows available somewhere.
There is also a whole IDE offered by Atmel (AVR Studio) which can be used to program their MCUs, but I never took a closer look at that one. Hence, I don't know which programmer types it would support.

In any case, you'll need a "non-standard" cable to attach the programmer to the controller board via the single-row 6-pin header. I'll add the pinout to the article later.

Note that once the AVR has been programmed with the boot loader image, the main firmware image can be uploaded and upgraded through a direct USB connection without the help of a programming device. You'll need a tool called BootloadHID for this, which is also included in my source tree. There are also pre-compiled binaries for Windows available, I think.

this is why i got a teensy... it has usb, and can program *itself*. uses the arduino software.

The teensy comes with an AVR with a pre-programmed boot loader so that no additional programming devices are required. Very convenient, and also a good way to get hand on the AVRs with USB support in hardware.

It might be a bit harder to make a drop-in replacement controller board since teensy is a complete development board, not only a chip. The keyboard controller will also be more expensive when based on the teensy (if you are ignoring the extra cost for the AVR programmer that would be required without a teensy, that is).

msiegel: are you using the hardware USB feature of the ATMEGA32U4 in the firmware?

[Mnemonix]

This looks fantastic...I wonder how adaptable this would be to 122-key terminal keyboards?

As long as we are not talking about capacitive switches (Model F), it should not be too hard.

Would just need to compensate for the larger and different matrix (easier said than done I'm sure).

Figuring out the matrix can be a bit tedious, but that's pretty much all that needs to be done to get the firmware working. Then you'll need to design the controller board, which is most likely a matter of figuring out the controller board dimensions and placing the connectors onto it.

If you know the keyboard matrix already, I can add it to the firmware sources and make firmware images for it.

[exia]

looks like a huge waste of time, you couldn't just slap a small heatsink on the old controller?

[kishy]

As long as we are not talking about capacitive switches (Model F), it should not be too hard.



Figuring out the matrix can be a bit tedious, but that's pretty much all that needs to be done to get the firmware working. Then you'll need to design the controller board, which is most likely a matter of figuring out the controller board dimensions and placing the connectors onto it.

If you know the keyboard matrix already, I can add it to the firmware sources and make firmware images for it.

I don't know it. Has anyone cracked one open for a bolt mod or anything?

I've got a 1986 122-key model m for sale. Price drop is in order for someone who publicly promises to provide the matrix info to Mnemonix since that will, at least eventually, help me get a new controller made for one or both of my two.

Edit:
Unless of course I can just go at it with a multimeter without fully disassembling the membrane assembly...in which case I'll get on that for you but I'm not sure how.

[Mnemonix]

looks like a huge waste of time, you couldn't just slap a small heatsink on the old controller?

A heat sink won't get me USB connectivity and Colemak in hardware.

[Mnemonix]

Edit:
Unless of course I can just go at it with a multimeter without fully disassembling the membrane assembly...in which case I'll get on that for you but I'm not sure how.

If you can find the time to do it, that would be great. Is there a picture of the original controller somewhere on the net? Are the connectors similar to those on the M controller?

[kishy]

If you can find the time to do it, that would be great. Is there a picture of the original controller somewhere on the net? Are the connectors similar to those on the M controller?

There should be photos in my giant thread (see signature). In the meantime I'll try to get clearer shots.

Connectors are the same type as a normal M but one or both is longer.

[kishy]

And here's the 1386887 controller. A concern: the connectors will be routed somewhat differently from the Boscom. This probably wouldn't involve any changes to the actual matrix except routing, right?

[Mnemonix]

That's a 20x8 matrix then. And it's a good thing that the keyboard doesn't have LEDs, because there are not enough I/O pins for the matrix AND the LEDs. Otherwise we would need an additional shift register and 8 diodes to free up some I/O pins--cheap, but somewhat annoying.

Are there variations of the 1386887 with LEDs?

Here's the matrix.

The pictures of the Boscom matrix are helpful for tracing the matrix with the multimeter quickly. Perhaps they are even good enough for tracing it visually.

And here's the 1386887 controller.

Wow, what are all those jumpers on the controller for? Configuring the terminal type? (Maybe I should read your thread...)

A concern: the connectors will be routed somewhat differently from the Boscom. This probably wouldn't involve any changes to the actual matrix except routing, right?

You mean the matrix sheets have their connectors in other locations? That's not a problem if the matrices are the same, from a software point of view. The controller boards for IBM and Boscom keyboards would be based on the same circuit diagram, but the physical layouts would have to be designed separately to fit into the keyboard.

[kishy]

That's a 20x8 matrix then. And it's a good thing that the keyboard doesn't have LEDs, because there are not enough I/O pins for the matrix AND the LEDs. Otherwise we would need an additional shift register and 8 diodes to free up some I/O pins--cheap, but somewhat annoying.

Are there variations of the 1386887 with LEDs?

Yeah, no LEDs. Would be nice to implement though, it's one of my hopes in having a new controller (which is why the AIKON looks so tasty I think).

The original terminal boards will not have LEDs (for the most part, I think there were 101 key versions almost exactly like a normal M that did have them), but later ones do, and terminal emulator ones do (such as ripster's former Boscom...pretty sure that had LEDs).

The pictures of the Boscom matrix are helpful for tracing the matrix with the multimeter quickly. Perhaps they are even good enough for tracing it visually.

I am concerned that for whatever reason the matrix may be different. I don't see why it would be but it's a concern we need to be prepared to address.

Wow, what are all those jumpers on the controller for? Configuring the terminal type? (Maybe I should read your thread...)

The jumpers take the place of DIP switches on certain models. They set the keyboard ID and on some keyboards are labeled as "KBDID A" and "KBDID B" in two segments.

I forget what ID is what, but the configuration shown there *should* be for a normal 101-key.

You mean the matrix sheets have their connectors in other locations? That's not a problem if the matrices are the same, from a software point of view. The controller boards for IBM and Boscom keyboards would be based on the same circuit diagram, but the physical layouts would have to be designed separately to fit into the keyboard.

Yeah, I know it makes no difference electrically, but that's what my concern is...possibly a different actual matrix on account of the different position of the connectors. I don't see why it would be though, it's still on the top edge. Again, just something to be ready for in case it happens to be the case.

[Specter_57]

That photo of the 122-key controller, the second-largest IC is a 4-16 line MUX, and so there are actually spare unused I/O lines, based on a schematic I have seen for this item, courtesy of Keyboard Babel.

And I have mapped out the matrix of my IBM 1390702 122-key terminal keyboards.


Anyway, I have attached to this posting a photo of the keyboard matrix row/columns assignments.

Maybe of use to someone here.

Hopefully my image and notes are clear enough.




Enjoy

Spec57

[kishy]

That photo of the 122-key controller, the second-largest IC is a 4-16 line MUX, and so there are actually spare unused I/O lines, based on a schematic I have seen for this item, courtesy of Keyboard Babel.

And I have mapped out the matrix of my IBM 1390702 122-key terminal keyboards.


Anyway, I have attached to this posting a photo of the keyboard matrix row/columns assignments.

Maybe of use to someone here.

Hopefully my image and notes are clear enough.

Enjoy

Spec57

3197 - yes, that helps, thanks! That's a real terminal keyboard and is scancode-compatible with my big 1986 ones, so surely the matrix is the same.

Not to say the Boscom isn't...there's just no way to be 100% sure without checking. Since that 1390702 is for a 3197 and 3197s are one of the interchangeable terminal types (with regards to keyboard compatibility) it's gotta be the same.

[DreymaR]

Wow, this is some awesome work! It might be the thing for getting a Colemak board on my PS3, even. Then it'd have to support some cheap sacrificeable keyboard that I have lying around...

Just downloaded and started browsing your code. One thing: It's 'Tarmak', not 'Tarpak' and its full name is 'Tarmak (transitional Colemak)'... I think. The idea is that like a tarmac it's paving the way!    I'm quite proud of it, to be honest, and honored if you'll want to implement it.

The code would be as follows; tarmak1.map (Phase 1 - LUI only):

Code: [Select]

KEY_U KEY_L
KEY_I KEY_U
KEY_L KEY_I

tarmak2.map (Phase 2 - right hand remapped apart from 'P'):

Code: [Select]

KEY_E KEY_smcol
KEY_Y KEY_J
KEY_U KEY_L
KEY_I KEY_U
KEY_O KEY_Y
KEY_J KEY_N
KEY_K KEY_E
KEY_L KEY_I
KEY_smcol KEY_O
KEY_N KEY_K

What's the VK_102 key called, by the way; is that the 'KEY_Euro'? I'd like to do the ZXCVB< ergonomic shift while I'm at it. Would be wonderful if that could be done independently from the QWERTY/Colemak/Tarmak remaps since it can be used in any of those layouts (albeit not in Dvorak obviously... that I've heard of at least; some Dvorak users might want to do it there too maybe?).

Code: [Select]

KEY_Euro KEY_Z
KEY_Z KEY_X
KEY_X KEY_C
KEY_C KEY_V
KEY_V KEY_B
KEY_B KEY_Euro

[Mnemonix]

Yeah, no LEDs. Would be nice to implement though, it's one of my hopes in having a new controller (which is why the AIKON looks so tasty I think).

OK, with LED support then.

I am concerned that for whatever reason the matrix may be different. I don't see why it would be but it's a concern we need to be prepared to address.

I guess you'll need to check this with a multimeter. It's probably enough to check just for 3 or 4 different keys if they are on the same rows and columns as given in Spec's picture. You'll need to find out which pin is "pin 1" on the two connectors first. Left Control is on row 1, column 1, so your multimeter should show 0 Ohm (or beep) when holding the probes to the correct pins and pushing the Control key. If there are more keys in the expected location, just assume that your matrix is the same. We can always adapt it later.

That photo of the 122-key controller, the second-largest IC is a 4-16 line MUX, and so there are actually spare unused I/O lines, based on a schematic I have seen for this item, courtesy of Keyboard Babel.

So they are using the chip to drive 16 of the 20 matrix rows? We could do the same for the replacement controller instead of using a shift register, depending on the total cost and availability of the parts.

And I have mapped out the matrix of my IBM 1390702 122-key terminal keyboards.

Cool! I've created the matrix file based on your picture--seems to work out well. My script generates the same matrix that you have drawn with O's and X's (albeit transposed).

As a reference for the key labels I have used the picture from this post.
There are only a few keys that I couldn't find USB equivalents for: "PA1/Dup", "Attn", "ErEOF", and the two blank keys on the far left in the bottom row. What is the purpose of these keys?

Wow, this is some awesome work! It might be the thing for getting a Colemak board on my PS3, even. Then it'd have to support some cheap sacrificeable keyboard that I have lying around...

Thanks a lot!
If you are planning to mod some cheap keyboard, make sure that you can attach the replacement controller to the matrix sheets somehow. The connectors are likely to have much finer pitch than the 2.54 mm on the old IBMs. Otherwise I'll happily help adding support for it to the firmware.

Just downloaded and started browsing your code. One thing: It's 'Tarmak', not 'Tarpak' and its full name is 'Tarmak (transitional Colemak)'... I think. The idea is that like a tarmac it's paving the way!    I'm quite proud of it, to be honest, and honored if you'll want to implement it.

Oops, a typo; but that was only in the TODO file.
Thanks for writing down the key map files, now I can remove that item from the TODO file. I'll add them to my source tree.

What's the VK_102 key called, by the way; is that the 'KEY_Euro'? I'd like to do the ZXCVB< ergonomic shift while I'm at it. Would be wonderful if that could be done independently from the QWERTY/Colemak/Tarmak remaps since it can be used in any of those layouts (albeit not in Dvorak obviously... that I've heard of at least; some Dvorak users might want to do it there too maybe?).

Yes, it's called KEY_Euro for some weird reason. Maybe I should check the USB HID specs in order to find a better name based on the name it has been given there.
Is that mapping complete? I can add it to the source tree then.

The shift mapping can be applied independently already since the script that processes the matrix definitions and key mappings can handle multiple map files. At least with Colemak it will work because the affected keys are not part of the Colemak mapping.
It doesn't work for Dvorak at the moment because the script simply assumes that all mappings are independent (otherwise the order in which the map files are passed to the script would become important). I'll think about a good solution.

[DreymaR]

Yes, it's called KEY_Euro for some weird reason. Maybe I should check the USB HID specs in order to find a better name based on the name it has been given there.

Is that mapping complete? I can add it to the source tree then.

The shift mapping can be applied independently already since the script that processes the matrix definitions and key mappings can handle multiple map files. At least with Colemak it will work because the affected keys are not part of the Colemak mapping.
It doesn't work for Dvorak at the moment because the script simply assumes that all mappings are independent (otherwise the order in which the map files are passed to the script would become important). I'll think about a good solution.

- I think I saw it called KEY_Euro2 in a USB spec? Even worse name, haha.

- Yes, the ZXCVB shift mapping is complete; it's a small but nice trick that 'anyone can use'.

- I don't need it to work for Dvorak and I doubt any Dvorak users are all that interested at the moment. If QWERTY and Colemak users can use it, I'm happy.

Much wants more as they say: Could there be an on-the-fly-remapping/extending possibility like the HHKB2's Fn key ('Extend' mode in PKL)? E.g., I press CapsLock and now the UNEI keys become bona fide arrow keys (and much more! - hopefully including making some keys into modifier keys!). Or, I press Ctrl+CapsLock and now the UNEI keys will send 5 arrow key presses per click until I release CapsLock again. Or, I press Alt+CapsLock and now the LUYNEIKM,. keys become the NumPad... etc etc.

[Shawn Stanford]

There are only a few keys that I couldn't find USB equivalents for: "PA1/Dup", "Attn", "ErEOF", and the two blank keys on the far left in the bottom row. What is the purpose of these keys?

PA1 is an interrupt key
Dup copies the character from the previous line to the current line
Attn is an interrupt key
ErEOF erases from the cursor positon to the end of the current unprotected area

Awesome thread, BTW.

[Specter_57]

Hello all.

Glad someone here is finding my tracing of the keyboard matrix of interest.

Pay close attention to how I numbered the illustrations of the cct connectors, ie number 1-end on the top, and 0-end on the bottom.

I see microcontroller circuits listing '0' as the first numeral, and on the cct board itself, '1' as the first numeral.  That is why I labelled them as I did..

In previous postings here on GH I attached pics of my cct board for the '0702.

See here:
My keyboard CCT board:

http://geekhack.org/attachment.php?attachmentid=2313&d=1240204836

http://geekhack.org/attachment.php?attachmentid=2312&d=1240204827

http://geekhack.org/attachment.php?attachmentid=2314&d=1240204843

and the schematic of that cct board, less the driver IC and Jumpers contacts at the top center of the schematic...otherwise it is identical (courtesy of Keyboard Babel):

the schematic:  http://www.kbdbabel.org/schematic/kbdbabel_doc_ibm3197_kbd.pdf

A pic of my particular keyboard is attached below.
.....

Ripster, thanks for the pics of the membranes for your keyboard.
I never took my keyboards down far enough to see the membranes themselves.

.....
Shift registers are a reasonable way to expand both inputs and outputs...look at this:

http://homepages.which.net/~paul.hills/Software/ShiftRegister/ShiftRegister.html

looks like all inputs and outputs could be handled with three lines...not to say that other problems could arise if that was done...

...and several other possibilites come to mind as well.

...

And since there is talk of Colmak and DVorak here...look at 'XPert Keyboard':  http://www.xpertkeyboard.com/index.htm

...

Enough for now.

Spec57
............

[Mnemonix]

- I think I saw it called KEY_Euro2 in a USB spec? Even worse name, haha.

No Euro2, but Int1, Int2, ..., Int9, Lang1, Lang2, ..., Lang9. I think they are called like that in the specs. The Euro key might have a better name, though.

- Yes, the ZXCVB shift mapping is complete; it's a small but nice trick that 'anyone can use'.

OK, added.

Much wants more as they say: Could there be an on-the-fly-remapping/extending possibility like the HHKB2's Fn key ('Extend' mode in PKL)? E.g., I press CapsLock and now the UNEI keys become bona fide arrow keys (and much more! - hopefully including making some keys into modifier keys!). Or, I press Ctrl+CapsLock and now the UNEI keys will send 5 arrow key presses per click until I release CapsLock again. Or, I press Alt+CapsLock and now the LUYNEIKM,. keys become the NumPad... etc etc.

"Simple" function keys that switch between alternative layouts should be possible and easy to implement; in fact, I planned to implement numpad emulation that way. Arrow keys on the main cluster would be exactly the same.

You can do this already with the current firmware by programming an alternative layout into some slot and activating it by hitting Scroll Lock followed by the number of your alternative key map. When you are done using the other key map, switch back to your main map. That would be clumsy, so a function key, as I have planned it, would act as a temporary, quick switch between the current and some alternative map. Of course, multiple function keys and combinations thereof could be supported.

I thought about on-the-fly remapping, but thought it would not be worth the trouble (because I could map everything "offline"). Technically, it would not be too difficult, I think, but I'm sure there are some pitfalls.

The Ctrl+CapsLock thing is more complicated, because it would involve some kind of macro playback which isn't planned at all at the moment. This is something for the future or the GeeKey controller (should it really be made some day).

[Mnemonix]

Plus, it supports AVRdude - which I saw as a sign of good karma for me since I have no idea what I am doing.

No problem, I didn't have a clue a few months ago, too. :lol:
It all becomes obvious once you have it all in front of you.

That Aussie device was available here, too, but the kit I've bought won just because it was cheaper then.

Thanks for the suggestion Mnemonix.  This one also appears to have excellent documentation.  PDF users manual link.

Nice docs. Man, so many instructions just to get the thing working on Windows...

[Mnemonix]

PA1 is an interrupt key
Dup copies the character from the previous line to the current line
Attn is an interrupt key
ErEOF erases from the cursor positon to the end of the current unprotected area

I cannot find USB key codes matching any of those. There are codes for other funny keys like "Help", "Menu", "Select", "Oper", and some more, but no interrupt keys. We could make them media keys, though...

I wonder which codes a USB converter would send when seeing the scan codes for these keys.

[Mnemonix]

Pay close attention to how I numbered the illustrations of the cct connectors, ie number 1-end on the top, and 0-end on the bottom.

I see microcontroller circuits listing '0' as the first numeral, and on the cct board itself, '1' as the first numeral.  That is why I labelled them as I did..

Computer vs. human thinking.
I didn't notice that (only starred at the row/column assignments all the time), thank you.

looks like all inputs and outputs could be handled with three lines...not to say that other problems could arise if that was done...

Two lines are enough even since CLEAR can be emulated by shifting a number of zeros into the register. Slower, but only required at initialization time and saves a line.

...and several other possibilites come to mind as well.

If they are better than shift registers (i.e., cheaper and working reasonably well), feel free to post them.

And since there is talk of Colmak and DVorak here...look at 'XPert Keyboard':  http://www.xpertkeyboard.com/index.htm

That looks... awkward? Don't know. Two E keys. :lol:
Did anyone ever try that layout?

[Shawn Stanford]

I cannot find USB key codes matching any of those. There are codes for other funny keys like "Help", "Menu", "Select", "Oper", and some more, but no interrupt keys. We could make them media keys, though... I wonder which codes a USB converter would send when seeing the scan codes for these keys.

Well, the rough equivalent to PA1 would probably be Ctrl-Break, and Attn would probably be SysReq. ErEOF equates to the key sequence '++, ', and there is nothing like the Dup key (also known as 'CopyUp').

[Mnemonix]

Well, the rough equivalent to PA1 would probably be Ctrl-Break, and Attn would probably be SysReq. ErEOF equates to the key sequence '++, ', and there is nothing like the Dup key (also known as 'CopyUp').

OK, I'll map Attn to SysReq then.

PA1 is currently mapped to Insert because of its location, so there are two Insert keys now... Probably not a popular choice.
ErEOF is "Execute" (whatever that is) and the two blank keys are Int1 and Int2 for now ("International" 1 and 2, according to the specs).

[DreymaR]

QUOTE=Mnemonix]I thought about on-the-fly remapping, but thought it would not be worth the trouble (because I could map everything "offline"). Technically, it would not be too difficult, I think, but I'm sure there are some pitfalls.[/QUOTE]

Oh, sorry: I didn't actually mean on-the-fly remapping, just the ability to switch to some layouts temporarily through the use of 'extend'/'Fn' key(s) so that navigation/NumPad/Multimedia/what-have-you keys can be made readily available on the main key block.

And since there is talk of Col[e]mak and DVorak here...look at 'XPert Keyboard':  http://www.xpertkeyboard.com/index.htm

You know, mapping Q and K to the home row and then taking money for it loses my respect. (I know, they thought the pinkies are weak but they aren't when they don't have to perform awkward stretches - at least, mine certainly aren't!) And duplicating the 'e' key loses the ';' key which seems more of a confusing sacrifice to me than it's worth. They fail to fix the awkward position of the common letter 't' (and others). And why the hell did they move the 'x' for instance - just so they could spell a slogan?!

Does anyone know anyone who actually uses that?

If you look at the Colemak site's list of alternative layouts you'll see that Shai Coleman rates it among the worst options so I think he'll agree with my sentiments for what that's worth. The whole thing strikes me as very odd indeed - and they claim to have loads and loads of downloads and happy customers?

[Specter_57]

Hey...I'm NOT promoting them (xpert keyboard layout...) in any way.

Just thought it was interesting....but I do not think it's worth paying for.

As was mentioned above, it was noticed there were two 'e' keys.
That is not so silly as it may at first seem...the letter 'e' is the most common letter in the English language.

Sam Morse figured that out when he was designing his code. I read somewhere a long time ago that he apparantly counted lettters from several different newspapers and did a frequency analysis of the letter usage...and so common letters had the shortest 'dit-dah' sequence, and uncommon ones longer sequences.

http://en.wikipedia.org/wiki/Morse_code
and for fun:
http://morsecode.scphillips.com/jtranslator.html

Dvorak...Colmak...or some combination of the better features of the two (a 'Col-vorak?  a Dvor-mak..keyboard.?) is something I've been thinking about for some time, off and on.

A controller board as is being discussed here and in other threads lends itself to remaps, among other things, obviously.

And...i'll examine that link shortly, thank you for posting it.

..........

And in a previous post, where I was talking about shift-register I/O expansion, and I mentioned there are more possibilities...

Basically I was thinking of various combinations of master/slave controllers to take care of pin shortages...but that (for me anyway) assumes DIP devices at 2.54mm (0.1") centers, not surface mount.
Being old-school, I use those devices on perf-board, and sometimes wire-wrap.

If SMD and other packages are acceptable, then simply get a device with the appropriate number of I/O pins and be done with it...no fooling around.

....

Also, and again NOT promoting this, only mention it for general reading interest...take a look at the keyboard encoder chips on this page:

Sprintek:
http://www.sprintek.com/

......
Spec57

[Mnemonix]

And in a previous post, where I was talking about shift-register I/O expansion, and I mentioned there are more possibilities...

Basically I was thinking of various combinations of master/slave controllers to take care of pin shortages...but that (for me anyway) assumes DIP devices at 2.54mm (0.1") centers, not surface mount.
Being old-school, I use those devices on perf-board, and sometimes wire-wrap.

Ah, a co-processor for handling matrix I/O.

If SMD and other packages are acceptable, then simply get a device with the appropriate number of I/O pins and be done with it...no fooling around.

I wouldn't mind if someone were up to build a controller with SMD parts on it, or to come up with completely new designs for keyboards that I don't have. It would simply mean that I couldn't build one myself at the moment, but I could still help with the software.
I'm focusing on DIP devices because that's what's easiest for me to handle.

[Specter_57]

Mnemonix:
You said: "I'm focusing on DIP devices because that's what's easiest for me to handle. "

Exactly.  I agree.
The DIP devices and 2.54mm grid are what I prefer myself...and as mentioned...I have used perf board (and a couple of times corrugated cardboard) for assembled projects and breadboards for testing out circuits.and short-term projects.
But a circuit board is to be preferred, one that can be made at home that is...using these DIP devices.

In my opinion, like you, I feel these devices and format are all around easier to use.
And if someone is using some of the older keyboards then space inside and absolute compactness of the controller board isn't that much of an issue.

Not hard to stuff a lot of stuff into one of these older keyboards we all seem to have such affection for, is it?  :-)

....

I do believe that ATMega devices can be connected to each other via I2C bus...?

and here also is an interesting idea, concept, for use with a breadboard.

http://www.ladyada.net/make/pshield/index.html


..............
Spec57

[spolia optima]

I just want to say that this mod (and thread) is killer. A lot of it is still over my head, but I've learned quite a bit in these 2 pages.

[Mnemonix]

(and a couple of times corrugated cardboard)

That's wild!

But a circuit board is to be preferred, one that can be made at home that is...using these DIP devices.

I'd love to be able to make my own circuit boards, but I don't have the equipment and don't want to worry about disposal of chemicals. Cutting wires and soldering them, however, might consume at least at much time as required to etch a PCB...
I think I'll try the toner transfer method one day since there's no developer solution involved. Only some acid to take care off.

I do believe that ATMega devices can be connected to each other via I2C bus...?

Yes, I think there is some support for I2C built in, but I haven't used it yet. I've only used the RS232 interface, but not for the keyboard controller.

[Specter_57]

Mnemonix

I like that etching method you linked to.

Because most of my electronics projects have been one-off or only a few pieces, never got into making circuit boards much...but have helped others doing so.

So, if you are only interested in a couple or three pieces...you have to decide which method is suitable to your situation.  But that's always the case.
Always a balancing act, a compromise...and part of what makes a project fun.

And don't forget, as you likely already know...anything you have to dispose of acidic is easily neutralized by Sodium Bicarbonate (that's baking soda...  :-)  )

Acid + Base => Salt + Water.

...........

spolia optima

If you want to be overwhelmed by technical information from time to time...you are in the right place.  :-)

If you look around GH you will see a lot more of these sorts of discussion threads and postings.  Believe me...this isn't the only one.

I'm certainly no expert...some of this stuff is above my head, for sure.

...........

Spec57

[Mnemonix]

Acid + Base => Salt + Water.

Yes, I know that. Problem is that there will still be copper residues left in the neutralized solution, so, being a heavy metal, it should not be disposed through the toilet. AFAIK, it would be illegal to do this where I live (bad for sewage treatment plants).

[Specter_57]

Yes.

You do not want to casually flush chemicals down the toilet or sewers.
Wrong morally as well as legally.

Spec57

[Mnemonix]

EDIT: Schematics are outdated and not supported by the firmware anymore. See post #105 or the project source tree for updated schematics.

Here are two circuit diagrams for 122-key terminal keyboards: one with LED support, and one without. I can provide firmwares for both of them.

The connections are made so that wiring is simple in practice (hopefully), but I cannot try it myself because I don't have one of these monster keyboards. If one of you terminal keyboard owners would like to give one of them a try, please let me know if there is something that needs to be changed.