I recently found a rare 80’s technology gem on the attic: An (almost) functional Commodore 1520 plotter. This was the only plotter ever sold by Commodore. It was a C64 peripheral, although even back then, it was pretty unknown (and fairly useless).

Surprisingly, after 25 years of deep sleep, the device powered up to self test. Two motor gears needed some glue and the ink in the pens had dried. A bit of water brought at least the blue pen back to life (the plotter has four pens in different colors, for a “perfect multimedia experience”).

Commodore, like just about everyone else back then, used a propietary protocol to drive the plotter. It is a weird serial protocol – in our official Everykey protocol weirdness scale, it beats most other protocols by far, making I2C and SPI look boring and straightforward. There’s even some (partially incorrect) documentation on the web. And you can still buy the 6-pin DIN plugs. There are some projects to control the Commodore 1541 floppy disk drive, but we didn’t find any good approaches on bringing the 1520 back to life. Challenge accepted!

The implementation was surprisingly simple – after categorizing the existing documentation into a) usable,  b) incomplete or c) just plain wrong. The Everykey connects through USB to a computer and shows up as a virtual serial port. It implements a tiny parser which interprets simple commands (such as MOVE, LINE, PRINT or COLOR) typed into the terminal and translates them into something that can be understood by the plotter. Here’s an early result (just blue – as mentioned, the other pens are still dry):

Commodore 1520 plotter
A Commodore 1520 plotter controlled by Everykey

The output quality is not perfect (for example, you can see that the vertical feed is off a little), cleaning the mechanics and replacing the pens should help. Even in perfect condition, the results could not compete even with the cheapest inkjet printer of today. So why did we do it? Because we can.

Code and schematics are not online yet since we decided to stop spamming our base repository. If you’re interested in how it works, let me know. If you have other peripherals waiting for resurrection, we might be able to help – did you know that we are for hire for this sort of stuff?

There’s a video of the plotter in action on youtube.

USB is a rather complex protocol. Its main advantage in computer history was that it promised to offer a useful replacement for legacy parallel and serial ports. In comparison though, USB is terribly complex, but it does not suffer the typical shortcomings of its predecessors and has some nice, built-in advantages: Hot plugging, device self description, automatic driver matching etc.

Keeping that in mind, it’s a bit surprising that the number-one mode of communication in embedded DIY projects that support USB is – a virtual serial port. This approach combines the complexity of USB with the inflexibility of serial ports. The worst of both worlds!

For certain purposes, serial ports are nice: Quick and dirty communication, debugging etc. So we’re happy to announce that our USB software stack now includes a virtual serial port implementation (USB CDC class, Abstract Control Model) – if you’re curious to see one of the weirdest USB class specifications, have a look at the USB CDC specification at USB.org.

To see it in action, compile and install the cdcleetifier example. Then replug your device. On Macs and Linux systems, it should appear as a serial device in the /dev subdirectory. Connect it to a serial terminal to see the old serial glory of the eighties (on a Mac, you may use “screen /dev/cu.usbserialV1.1” – quit with “ctrl-a k y”). Type some text – the example will turn your text into V3RY C00L l33TSP3AK on the fly.

We haven’t tested it on Windows yet, but it seems to require an additional (quite useless) configuration (*.inf ?) file that basically states that this serial device is a serial device (if someone manages to get it running, we would be happy to hear from you).

Posted in USB.
const uint8_t kbd_manufacturerName[] = {
  0x22,                   //bLength: length of this descriptor in bytes (34)
  USB_DESC_STRING,        //bDescriptorType: string descriptor
  'P',0,'r',0,'e',0,'s',0,'s',0,' ',0,'A',0,'n',0,'y',0,' ',0,'K',0,'e',0,'y',0,' ',0,'U',0,'G',0 //bString[]: String (UTF16LE, not terminated)
Posted in USB.