Petkn

Commodore PET keyboards

Note: this is a part of a larger set of repositories, with upet_family as the main repository.

This is part of a re-incarnation of the Commodore PET computer(s) from the later 1970s.

This repo shows how to build a keyboard for the Commodore PET, mainly for my own re-incarnation, but potentially for original PET as well (untested).

Keyboards can be seen in the PETindex keyboard section.

N-Type

This keyboard is the typewriter-stlye keyboard used in most 40 column models, except for the originals with the chicklet keyboard.

PCB

Open source PCB by Steve Gray

For my builds I started by using the N-type keyboard PCB by Steve Gray from his MX replacement keyboards projects As Steve only has the PCB, I designed a 3D-printable base support for the PCB. It is available on tinkercad and the STL files are also available here.

Based on that I created a new R3 version of the board that includes options for backlit LEDs and keyboard controllers allowing key re-mapping independent from the PET's own editor ROM. You can find it in PET-N

NOTE: In R3.0A you need to fix some things:

1. Connect the V33 and VCC33 lines - basically the oscillator for the Atmega controllers does not have power, so that needs to be supplied.
2. There is an off-by-one error on the row multiplexer. It has rows R0-9, while the keys are connected to R1-10. For now you have to connect R0 and R10, and fix the issue in the controller software.

In the current R3.0B these two fixes have been applied, but the actual PCB is not tested yet (and probably never will). A future 3.1 fix this for good.

Programming the R3 PCB

The R3 PCB has (optionally) two Atmega32a microcontrollers on board, that implement two functions:

1. mapping keys between the keyboard and the host
2. controlling the LEDs.

To program the Microcontrollers you need an AVR programming tool like the AVRisp MkII that I use, or similar, that can program via the SPI interface (plus Reset) on the 6 pin programming header (which exists separately for each of the two Microcontrollers)

Both microcontrollers are connected to the I2C bus on the extended UPET keyboard interface.

Functions of the keyboard controller

Currently the keyboard controller maps the keys 1:1 from the keyboard matrix to the host keyboard interface.

In addition it sends the pressed keys (hardware key index) via I2C to address 0x10 (which is the LED controller).

Also, the keyboard mapping has these options:

1. direct mapping - each key is directly mapped to the corresponding host key
2. The top row of characters is remapped from the PET-N's characters (like $, %, etc) to the digits you'd normally expect in this place. The original chars are available with Shift, the originally shifted characters are available with Ctrl.

Note that in the future more mappings may be implemented.

Selection of the mapping is done by pressing the SRQ key a few seconds long. The keyboard will then send a menu text to the host that instructs the user how to switch the mapping. It is best if the menu is triggered e.g. on the BASIC prompt.

The mapping is stored in the Atmega's EEPROM, and thus retained when the machine is switched off.

Functions of the LED controller

The LED controller listens on the I2C address 0x10 for commands.

With these commands you can set the constant value of each key LED, but also trigger certain programs that involve either a single key, or multiple keys. For single keys you can let the colour slowly get dimmer until the LED is off, and then optionally restart with the original value.

The DILUTE program tries to do a simulated flow of the colour from the given key to the surrounding keys. It is not as good and smooth as it could be as the Atmega lacks memory to store the required precision of colour values.

The LOGO just sends the logo onto the keypad, and then lets it decay.

        // single LED programs. Followed by index, three colours, and a parameter
        LP_CONST        = 0,    // constant value, using the three parameters as RGB
        LP_LINDECAY     = 1,    // linear decay (note may change hue while getting lower)
        LP_LINDECAYLOOP = 2,    // linear decay with restart

        // single command program
        SP_KEYPRESS     = 64,   // just followed by the index to indicate a pressed key

        // multi-key programs
        KP_DILUTE       = 128,  // set initial value to given params, then let it flow off 
        KP_LOGO         = 129,  // C= logo on the keypad

All commands except KEYPRESS expect the key index, three colours, and a parameter after the command, i.e. six bytes in total. KEYPRESS only has the index and thus requires only two bytes.

Supports for PCB

The PCB needs some kind of support to be mounted into the PET or the Ulti-/Micro-PET cases. There are two versions for Steve's and my derived PCB, the first one for the extended that caters for the different connector, and the one better suitable for the original PCB.

• New support structure extended PET-N keyboard

• left part of the support

• right part of the support

• support structure for Steve's N-type keyboard at tinkercad.

• left part of the support

• right part of the support

Texelec Petskey keyboard

This is the PET N-type keyboard available from Texelec.

As this is the PCB only, I have created a support structure for this too. Note, however, as I now prefer Steve's PCB, I only have an old version of the supports on tinkercad.

Two of each of these supports make up a keyboard base plate, where you only need to clip in the PCB for the keyboard with the mounted key switches. Then they have about the same dimensions as a C64 keyboard, and you can use them on top of the C64 keyboard support stands.

• Petskey 1.0 keyboard on Texelec
• Petskey support on tinkercad

Key caps

There are two options, either use standard key caps, or 3D-printed ones.

Standard Keycaps

As, for the self-built keyboards from option 1 or 2 some standard MX switches are used, standard key caps can be used as well. There is one caveat, however.

Newer key caps typically have a different inclination for each row of keys, that is the angle of the top key surface against the horizontal is different for each row. This is to facilitate easier typing. In fact even the C64 keyboard has this. The old PET keyboards, however, have the same angle - which is not zero! - for all rows. This makes it easier to use the same cap (in terms of physical dimensions) on all rows, and just print on a different character for each key. Read more on those key profiles.

I used two type of standard key caps:

1. XDA profile, unmarked: this set of key caps does not have a print on it, and all keys have the same angle - zero. So it is possible to use any of the key caps in any row. Which is important, as you need a specific number of keys for each key width. Also, this set has space bars in different lengths, and there is one that fits the 6.25 character wide space bar for the petskey and sjg keyboards. For the markings I just used a pen...

2. This one Glorious PC Gaming Race ABS Doubleshot black, ANSI layout GAKC-045 I actually bought more or less by accident. I only noticed that it has different angles per row when I tried it out. However, with the amount of caps I was able to only use a wrong angle on Shift Lock, left Shift, Return and "4" - but it's barely noticable. For the markings I used template from Steve's page, printed it on sticky paper, cut it out and glued it on the keys where the original did not fit.

Printed Keycaps

As a third option I used 3-D printed key caps that I designed myself.

The keycaps are made of three parts each:

1. a key form created by a parametric generator,
2. the top character print, extruded from the key form,
3. the front character (mostly the shifted character), extruded from the key form.

I created all parts, and integrated them in the Tinkercad web tool.

The key form is created using OpenSCAD by a parametric generator (by Thingieverse user rsheldiii, published under the CC BY-SA 3.0 license). Here is the parameter file. Only the key width needs to be adapted, and the inversion of the top for the space key.

Most of the top character prints are made from a Microgramm font, converted to SVG using the Font Squirrel web page.

Some top characters, and especially the top words ("SHIFT", "RUN STOP" etc) are taken from Steve's github page. As SVG exported from inkscape did not work when imported into tinkercad, I had to make screenshots from each character, and convert these screenshots into SVGs using this online converter.

The front characters are all from an SVG file from wikipedia, from which I also took screenshots and converted to SVG as above.

You can find an oder version of the the STL files here, in four parts due to its size. The current version is linked from tinkercad below. Please note that it took me about 100+ hours just to print the full set of keys on my Snapmaker printer in high quality. After printing you have to remove the supports that anchor the stem to the outside of the keycaps so it does not break away when printing.

For your convenience there is an open project at PCBWay to print the key caps, see the links.

• Keycaps for resin printing
• Master file for keycaps [//] # * Open project at PCBWay 3D printing

Switches

The PCBs work with standard Cherry-type/-compatible switches. I only tested Cherry brand switches, though. You may select depending on your preference regarding force needed, click noise etc.

I found the MX1A-C1NW a good compromise for me.

• Cherry MX1A-C1NW at Mouser

Gallery

Assembled keyboard with white resin printed caps, with key prints painted with black alcohol ink Assembled keyboard with black PLA printed caps, with key prints painted with white alcohol ink Assembled keyboard with black PLA printed caps