USB for a 1977 Keyboard
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Ouellet, Jeremy (Angel)
The talk will be about how I bought a retro keyboard for a VISTA80 from the Canada Science and Technology museum and reversed engineered it to convert it passively to USB. The VISTA80 was a machine built in Canada and was used to "Create pages of text for cable TV systems or to create running lines of text or titles for television displays."¹ The VISTA80 was manufactured around 1995-1997 and was "One of the first character generators to use a computer chip (Intel 8080A) as a controller"¹. - The history of the Vista80 - A look inside of the keyboard - The Original circuitry - Prototype - Mapping the matrix - Making the circuit board - Highlights and Lessons learned I would potentially like to collaborate with the museum to get more information on the device.
 Hello everyone, my name is Angel and today I'm here to talk to you about my experience in making a USB adapter for the 40 year old keyboard for the Vista 80. First, a little about me. I'm a hardware hacker and programmer. I live in Montreal, Canada and have always loved retro technology. Now, a little history about the keyboard and its purpose. The Vista 80 was one of the first character generators to use a computer chip as a controller. At its core, it houses an Intel 8080a and stores data on dual 8 inch floppy. The museum says that its purpose was to create pages, lines of text or titles for television broadcasts. This specific model was used in the first broadcast in the Canadian House of Commons in 1977. In the House of Commons, it was mainly used to write the descriptions of what was going to happen at the start. The names and titles of people and the order of the day. Here are some samples from the brochure of the Vista 90 provided by MPB Communications. As you can see, it could do different fonts, different styles, it could do maps, different backgrounds, some basic 3D, it could also do technical information, some charts, scientific data, diagrams and even basic animation. It was a highly flexible device. These units were manufactured by a Montreal based company called Bytec Electronics and sold by MPB Technologies in the 70s and 80s. I may not have the Vista 80 in its entirety, I wish, but in May 2019 I purchased 3 of the keyboards from GC Surplus, a government surplus website and picked them up from the Canadian Science and Technology Museum in Ottawa. This specific keyboard seems to have also been made around 1977 according to the date codes. As you can see, this keyboard is very colorful, not unlike other keyboards of its type. I originally assumed that the keyboard had yellowed with age, but the inside is the same color and the museum website seems to mention the yellow color in their archive. It is made of a very brittle plastic that has sadly started to crack on some of the keyboards. We can see the Vista 80 badge and the MPB Technologies badge at the top of the keyboard. MPB Technologies is the parent company of Bytec and is still active today as MPB Communications. We can also see the big red power button at the top. It's there because of this keyboard, as you can see in a moment. Has its own power supply and does not take power from the main device. This also explains the power cord. Let me take the cover off so we can see inside. So here we can see the Matrix, the encoder board and a bit of a power supply. The Matrix was made by Honeywell and is custom for this keyboard. It uses Honeywell's solid state hull defect switches. The only moving part in these is a spring that is very easily replaceable, meaning that these switches, even after 40-50 years, work just like new. This board only has basic Motorola logic chips, some of which I could not find the day to shoot for easily, and some support components. Let me get this out. This is the encoder board. It takes data from the Matrix and sends it to the computer. The star of the show is the Nitron NC 2257LC. This chip was built to replace a Motorola chip from the 70s called the MC 2257L. Information on this chip I was very scared, but I was able to find a block diagram and pinout on archive.org. The NC 2257 seems to be an old USARC chip. It allows the keyboard to convert the data from its Matrix directly into a serial stream. By reverse engineering the board, I was able to find how it sends the data. First, the clock is generated via 555 timer and sent to pin 8. The NC 2257 then divides this clock by 16. It then uses even parity and once top it and sends that information to the link. The information is then sent to the 75150TC, that changes the 5V logic into minus 12 and plus 12 logic. On the other side, after changing the logic back to 5V, its counterpart chip, the NC 2259LC, recovers the clock and decodes the packet and splits it back into parallel. Now for the power supply. Under here there isn't much apart from the very simple power supply composed of a simple transformer and regulation board. The regulation board only produces minus 12V, plus 5V and plus 12V. At the top we can see a DB25 connector. Oh, give me a second. It's stuck. Yes, here. Only 5 pins on it are used. Data, ground, twice V+, and earth. Sorry. So when I first got these keyboards, I immediately knew I wanted to make one work with USB. These are so beautiful and classic. The first thing I tried was to hook my tiny portable oscilloscope to the data pin and I started making a spreadsheet, but I quickly realized that this setup was not optimal. My oscilloscope wasn't triggering, the signal was glitchy and I couldn't see all the bits. I got tired of things not working out, so I decided to take a Chinese copy of the TC2.0 and decided to solder it to the back of one of the encoder boards. The TC2.0 is a board made by PJRC. It runs at 16 MHz, has 32 kilobytes of flash, 2.5 kilobytes of RAM, and 1 kilobyte of EEPROM. The newer ones are very powerful ARM-based microcontrollers. I own many of them. I encourage people to buy them directly from PJRC as Paul Starfroghan is a great developer and a gift to the open source community. I plugged the keyboard in and used the same small oscilloscope to probe the pins to find all the pins that change when I press the keys. In total, I found 9 pins, 7 data pins, and 2 trigger pins. I had enough data so I made this. This is my prototype. It's a bit ugly, but I just needed something I could use for tests. All this is, is just a TC I had in my things. I soldered it to Voltage, Ground, and Data Pins. Next, I needed to start mapping the matrix. So after flashing a new bootloader on the TC to make it work like a normal Arduino, I wrote a quick little strip in C to output the state of the data pins on the serial bus. I started pressing random keys and I started noticing a few things. Firstly, I noticed that no matter how many keys you press at once, the only key is sent to the board. Only one key is sent to the board. I also noticed that holding in a key sends just one trigger signal, registering a single key. This keyboard seems to have 3 modifier keys, Shift and Control. The Shift key does what you would expect. It makes it so that you can access symbols and capital letters. There is a key called Shift Lock. It does the same behavior as holding the Shift key. The Control key, however, seems to make every key behave differently, but for some reason, the changes it makes overlap with other keys. I have not yet found out how this key is supposed to work, but I have some ideas. Since you can't hold a key to repeat a key, they had a key called LabeledREPT. When held, as long as another key is pressed, this key will pulse the trigger line, registering multiple characters. Instead of storing all the key codes in a single table, I decided to use the three upper bits as an index to eight different tables. This ended up working out, as tables 0 and 1 were lowercase, tables 2 and 3 were uppercase, 4 was numbers, 5 was symbols, and 6th and 7th were the special keys. The people who designed this keyboard must have decided to make it simple, as the letters and numbers were automatically in order. Each table was four bits, and therefore we had eight tables with 16 characters each. With the Arduino HID library, it was very easy to just decide if a character was uppercase or lowercase, without even thinking about the Shift key. All that was left was to assign some keys for normal modifiers you find on a normal computer, like Meta, Control, Shift, and Out. I originally settled on the Blue key, Center key, Channel key, and Alpha key respectively. With all this information, I felt I was ready to finally make the circuit board that would replace the encoder board. I started by writing down my requirements for the project. For all my previous projects, I've always favored AT-Tinies, as they are small and powerful. I also have a preference for always using the minimal, viable microcontroller. I wanted to use the VUSB library, and I also wanted to try not using the Arduino IDE for once, so I looked online and found that the AT-Tiny 2313 was quite popular, and then offered a 4K variant, the AT-Tiny 4313. The AT-Tiny 4313 uses the RISC architecture. It has 4KB of flash, 256B of RAM, 256B of EEPROM, and 18I Opens. Limited and just enough for my project. Mapping the Iopens I would need, I got the following, 7 IO for the data from the keyboard, 1 IO for the trigger pin, 3 IO's for the status LEDs, 2 IO's for the crystals, 2 IO for USB, and the last pin was reset. That left me with 2 IO pins that I used as a serial board. I opened Kycat and started laying out the schematic. One of the small problems I faced was that while my keyboard and the microcontroller worked at 5 volts, USB worked at about 3.3 volts. I got around this by using Zenerdias to reduce the voltage on the lines. This solution did make the circuit slightly more vulnerable to noise, but I haven't had any problems with that. I was feeling kind of lazy, so I didn't measure the components, and I just used what seemed right. This is the PCB I made. The only mistake I ended up making was picking the footprint that was a little bit too big for the resistors, which didn't end up hurting Indiana anyway. Here's the board I made. I could have made the board much smaller by using Sodermat resistors and making the board double-sided. I could also have used USB micro, mini, or C to make it more modern, but I instead chose USB-B as I like the big retro-ish connectors. The through-hole resistors also make it look like it could have been made at the time. Now that the hardware was done, I only needed to port my Arduino code to this. Apparently on Linux, if you don't want to mess with setting all the parameters, you have to settle for Eclipse. After installing it and setting it up, I started writing the code for this. As it was mostly the same, except I had to swap the pins around and figure out how to send HID keyboard code. The USB.com website has all the documents you need to find the code for each key. So wonderful. Once I wrote the code and the descriptor, I tried flashing it to the board. And nothing happened. D-Message told me the device was not responding. Troubleshooting time. Maybe I was just too ambitious. I started by writing a quick hello world to blink to LEDs just to make sure that the processor was actually running. And it started flashing. Good start. I then suspected that my descriptor may have been wrong. I don't remember how I created the original descriptor, so I went to the VUSB project page and saw that someone called Mikhail Holm-Olsen had posted a project where he converted a Commodore 64 to USB. I copied his descriptor, and suddenly the computer recognized my keyword. It was super slow, but it worked. I then spent a couple hours rewriting the proper key code and optimizing my code so that it didn't run at one key per second. Turns out, one of the big problems was just that I was printing at the console at each key press. That was fine on the FastTeenC, but it was too slow for this small chip. I also moved all the modifiers to the left side of the keyboard so that I wouldn't have to remember where they were. One last thing I had to figure out was to be able to tell if the keyboard was still connected. I settled in a very dirty system of sending a packet every so often and checking if I received a response. If no answer is received, the LEDs will flash until a connection is established. In the end, my code took up 91% of the ROM and 51% of the RAM. Just trying to use printf would make the code too large for the chip. This project was very interesting, and I planned to make another version that plugs into the back instead so as to be less invasive. I would like to thank the Canadian Science Technology Museum for providing me with the keyboard. MPB Communications for providing me with the brochures of the Vista AD N90, Mikhail Holm-Olsen for the USB descriptor, Kaikad for providing a free and open source software for circuit design, and all the people that helped me with this talk by reviewing it. If you have any questions, please feel free to contact me at any of these links. My talk, the slides, and the script will be made available on my website, www.jewelette.net after Fostum. Thank you very much for listening.
 Hello everyone, my name is Angel and today I'm here to talk to you about my experience  in making a USB adapter for the 40 year old keyboard for the Vista 80.  First, a little about me.  I'm a hardware hacker and programmer.  I live in Montreal, Canada and have always loved retro technology.  Now, a little history about the keyboard and its purpose.  The Vista 80 was one of the first character generators to use a computer chip as a controller.  At its core, it houses an Intel 8080a and stores data on dual 8 inch floppy.  The museum says that its purpose was to create pages, lines of text or titles for television  broadcasts.  This specific model was used in the first broadcast in the Canadian House of Commons in 1977.  In the House of Commons, it was mainly used to write the descriptions of what was going  to happen at the start.  The names and titles of people and the order of the day.  Here are some samples from the brochure of the Vista 90 provided by MPB Communications.  As you can see, it could do different fonts, different styles, it could do maps, different  backgrounds, some basic 3D, it could also do technical information, some charts, scientific  data, diagrams and even basic animation.  It was a highly flexible device.  These units were manufactured by a Montreal based company called Bytec Electronics and  sold by MPB Technologies in the 70s and 80s.  I may not have the Vista 80 in its entirety, I wish, but in May 2019 I purchased 3 of the  keyboards from GC Surplus, a government surplus website and picked them up from the Canadian  Science and Technology Museum in Ottawa.  This specific keyboard seems to have also been made around 1977 according to the date  codes.  As you can see, this keyboard is very colorful, not unlike other keyboards of its type.  I originally assumed that the keyboard had yellowed with age, but the inside is the same  color and the museum website seems to mention the yellow color in their archive.  It is made of a very brittle plastic that has sadly started to crack on some of the  keyboards.  We can see the Vista 80 badge and the MPB Technologies badge at the top of the keyboard.  MPB Technologies is the parent company of Bytec and is still active today as MPB Communications.  We can also see the big red power button at the top.  It's there because of this keyboard, as you can see in a moment.  Has its own power supply and does not take power from the main device.  This also explains the power cord.  Let me take the cover off so we can see inside.  So here we can see the Matrix, the encoder board and a bit of a power supply.  The Matrix was made by Honeywell and is custom for this keyboard.  It uses Honeywell's solid state hull defect switches.  The only moving part in these is a spring that is very easily replaceable, meaning that  these switches, even after 40-50 years, work just like new.  This board only has basic Motorola logic chips, some of which I could not find the day to  shoot for easily, and some support components.  Let me get this out.  This is the encoder board.  It takes data from the Matrix and sends it to the computer.  The star of the show is the Nitron NC 2257LC.  This chip was built to replace a Motorola chip from the 70s called the MC 2257L.  Information on this chip I was very scared, but I was able to find a block diagram and  pinout on archive.org.  The NC 2257 seems to be an old USARC chip.  It allows the keyboard to convert the data from its Matrix directly into a serial stream.  By reverse engineering the board, I was able to find how it sends the data.  First, the clock is generated via 555 timer and sent to pin 8.  The NC 2257 then divides this clock by 16.  It then uses even parity and once top it and sends that information to the link.  The information is then sent to the 75150TC, that changes the 5V logic into minus 12 and  plus 12 logic.  On the other side, after changing the logic back to 5V, its counterpart chip, the NC 2259LC,  recovers the clock and decodes the packet and splits it back into parallel.  Now for the power supply.  Under here there isn't much apart from the very simple power supply composed of a simple  transformer and regulation board.  The regulation board only produces minus 12V, plus 5V and plus 12V.  At the top we can see a DB25 connector.  Oh, give me a second.  It's stuck.  Yes, here.  Only 5 pins on it are used.  Data, ground, twice V+, and earth.  Sorry.  So when I first got these keyboards, I immediately knew I wanted to make one work with USB.  These are so beautiful and classic.  The first thing I tried was to hook my tiny portable oscilloscope to the data pin and I  started making a spreadsheet, but I quickly realized that this setup was not optimal.  My oscilloscope wasn't triggering, the signal was glitchy and I couldn't see all the bits.  I got tired of things not working out, so I decided to take a Chinese copy of the TC2.0  and decided to solder it to the back of one of the encoder boards.  The TC2.0 is a board made by PJRC.  It runs at 16 MHz, has 32 kilobytes of flash, 2.5 kilobytes of RAM, and 1 kilobyte of EEPROM.  The newer ones are very powerful ARM-based microcontrollers.  I own many of them.  I encourage people to buy them directly from PJRC as Paul Starfroghan is a great developer  and a gift to the open source community.  I plugged the keyboard in and used the same small oscilloscope to probe the pins to find  all the pins that change when I press the keys.  In total, I found 9 pins, 7 data pins, and 2 trigger pins.  I had enough data so I made this.  This is my prototype.  It's a bit ugly, but I just needed something I could use for tests.  All this is, is just a TC I had in my things.  I soldered it to Voltage, Ground, and Data Pins.  Next, I needed to start mapping the matrix.  So after flashing a new bootloader on the TC to make it work like a normal Arduino, I  wrote a quick little strip in C to output the state of the data pins on the serial bus.  I started pressing random keys and I started noticing a few things.  Firstly, I noticed that no matter how many keys you press at once, the only key is sent  to the board.  Only one key is sent to the board.  I also noticed that holding in a key sends just one trigger signal, registering a single  key.  This keyboard seems to have 3 modifier keys, Shift and Control.  The Shift key does what you would expect.  It makes it so that you can access symbols and capital letters.  There is a key called Shift Lock.  It does the same behavior as holding the Shift key.  The Control key, however, seems to make every key behave differently, but for some reason,  the changes it makes overlap with other keys.  I have not yet found out how this key is supposed to work, but I have some ideas.  Since you can't hold a key to repeat a key, they had a key called LabeledREPT.  When held, as long as another key is pressed, this key will pulse the trigger line, registering  multiple characters.  Instead of storing all the key codes in a single table, I decided to use the three upper  bits as an index to eight different tables.  This ended up working out, as tables 0 and 1 were lowercase, tables 2 and 3 were uppercase,  4 was numbers, 5 was symbols, and 6th and 7th were the special keys.  The people who designed this keyboard must have decided to make it simple, as the letters  and numbers were automatically in order.  Each table was four bits, and therefore we had eight tables with 16 characters each.  With the Arduino HID library, it was very easy to just decide if a character was uppercase  or lowercase, without even thinking about the Shift key.  All that was left was to assign some keys for normal modifiers you find on a normal computer,  like Meta, Control, Shift, and Out.  I originally settled on the Blue key, Center key, Channel key, and Alpha key respectively.  With all this information, I felt I was ready to finally make the circuit board that would  replace the encoder board.  I started by writing down my requirements for the project.  For all my previous projects, I've always favored AT-Tinies, as they are small and powerful.  I also have a preference for always using the minimal, viable microcontroller.  I wanted to use the VUSB library, and I also wanted to try not using the Arduino IDE for  once, so I looked online and found that the AT-Tiny 2313 was quite popular, and then offered  a 4K variant, the AT-Tiny 4313.  The AT-Tiny 4313 uses the RISC architecture.  It has 4KB of flash, 256B of RAM, 256B of EEPROM, and 18I Opens.  Limited and just enough for my project.  Mapping the Iopens I would need, I got the following, 7 IO for the data from the keyboard,  1 IO for the trigger pin, 3 IO's for the status LEDs, 2 IO's for the crystals, 2 IO for USB,  and the last pin was reset.  That left me with 2 IO pins that I used as a serial board.  I opened Kycat and started laying out the schematic.  One of the small problems I faced was that while my keyboard and the microcontroller  worked at 5 volts, USB worked at about 3.3 volts.  I got around this by using Zenerdias to reduce the voltage on the lines.  This solution did make the circuit slightly more vulnerable to noise, but I haven't had  any problems with that.  I was feeling kind of lazy, so I didn't measure the components, and I just used what seemed  right.  This is the PCB I made.  The only mistake I ended up making was picking the footprint that was a little bit too big  for the resistors, which didn't end up hurting Indiana anyway.  Here's the board I made.  I could have made the board much smaller by using Sodermat resistors and making the board  double-sided.  I could also have used USB micro, mini, or C to make it more modern, but I instead chose  USB-B as I like the big retro-ish connectors.  The through-hole resistors also make it look like it could have been made at the time.  Now that the hardware was done, I only needed to port my Arduino code to this.  Apparently on Linux, if you don't want to mess with setting all the parameters, you  have to settle for Eclipse.  After installing it and setting it up, I started writing the code for this.  As it was mostly the same, except I had to swap the pins around and figure out how to  send HID keyboard code.  The USB.com website has all the documents you need to find the code for each key.  So wonderful.  Once I wrote the code and the descriptor, I tried flashing it to the board.  And nothing happened.  D-Message told me the device was not responding.  Troubleshooting time.  Maybe I was just too ambitious.  I started by writing a quick hello world to blink to LEDs just to make sure that the processor  was actually running.  And it started flashing.  Good start.  I then suspected that my descriptor may have been wrong.  I don't remember how I created the original descriptor, so I went to the VUSB project page  and saw that someone called Mikhail Holm-Olsen had posted a project where he converted a  Commodore 64 to USB.  I copied his descriptor, and suddenly the computer recognized my keyword.  It was super slow, but it worked.  I then spent a couple hours rewriting the proper key code and optimizing my code so that  it didn't run at one key per second.  Turns out, one of the big problems was just that I was printing at the console at each  key press.  That was fine on the FastTeenC, but it was too slow for this small chip.  I also moved all the modifiers to the left side of the keyboard so that I wouldn't have  to remember where they were.  One last thing I had to figure out was to be able to tell if the keyboard was still connected.  I settled in a very dirty system of sending a packet every so often and checking if I  received a response.  If no answer is received, the LEDs will flash until a connection is established.  In the end, my code took up 91% of the ROM and 51% of the RAM.  Just trying to use printf would make the code too large for the chip.  This project was very interesting, and I planned to make another version that plugs into the  back instead so as to be less invasive.  I would like to thank the Canadian Science Technology Museum for providing me with the  keyboard.  MPB Communications for providing me with the brochures of the Vista AD N90, Mikhail Holm-Olsen  for the USB descriptor, Kaikad for providing a free and open source software for circuit  design, and all the people that helped me with this talk by reviewing it.  If you have any questions, please feel free to contact me at any of these links.  My talk, the slides, and the script will be made available on my website, www.jewelette.net  after Fostum.  Thank you very much for listening.
retro_usb_kbd_0_167.png retro_usb_kbd_168_2039.png retro_usb_kbd_2040_4043.png retro_usb_kbd_4044_4103.png retro_usb_kbd_4104_5651.png retro_usb_kbd_5652_6899.png retro_usb_kbd_6900_9527.png retro_usb_kbd_9528_9899.png retro_usb_kbd_9900_10055.png retro_usb_kbd_10056_10763.png retro_usb_kbd_10764_11759.png retro_usb_kbd_11760_13343.png retro_usb_kbd_13344_14963.png retro_usb_kbd_14964_15731.png retro_usb_kbd_15732_16055.png retro_usb_kbd_16056_16127.png retro_usb_kbd_16128_16691.png retro_usb_kbd_16692_17891.png retro_usb_kbd_17892_18803.png retro_usb_kbd_18804_19499.png retro_usb_kbd_19500_19919.png retro_usb_kbd_19920_20435.png retro_usb_kbd_20436_21159.png