I’ve owned a Commodore PET* 8032 for a few years now. I’ve been able to download and run many different programs for it, like WordPro you see above. But one thing always remained elusive. I’ve long wanted to connect it to a standard RS-232 device and use it as a terminal. The PET’s classic shape, green monochrome monitor, and 80 column display all lend itself perfectly as a terminal.

Like it’s much more popular successors, it too lacked proper RS-232 UART hardware. Adding a modem meant you either had to purchase a IEEE-488 enabled modem (Commodore made the 8010), purchase an add-on board for your PET, or use the existing parallel user port to “bit-bang” RS-232 serial signals. The later is exactly what the Commodore VIC-20, C64 and C128 do– simulate RS-232 on user port pins by the CPU rapidly turning outputs on and off. They even have KERNAL ROM code (albeit broken at high speeds) that did the RS-232 handling for you.

The PET lacks this ROM code but it can added to drive RS-232 TTL signals over the user port. I found two methods that did this– a commercial product and a freeware one.

Before we continue, please– if you attempt any of this, make sure you understand the difference between RS-232 TTL level signals (0v to +5v) and proper RS-232 level signals (-13v to +13v or more). Connecting proper RS-232 level signals to your PET will damage your computer and make you sad. See this explanation for SparkFun about the differences in RS-232 levels.

---

The first was McTerm which was produced by Madison Computer. I knew of this company since I owned their McPen lightpen system for the VIC-20 and C64 but I didn’t know their pedigree went that far back. It was sold as three parts– software on floppy, a ROM chip that had to be installed inside the PET, and a user port cable that connected to the RS-232 device. I located the software and the ROM online [local cached copy] but I’ve never actually seen the user port cable before so this was going to be challenging.

The first step was to create the ROM using an EPROM. On the PET 8032, the ROM slot is UD12 which maps to memory location $9000. The ROM code was only 2 Kbytes but I only had 4 Kbyte EPROMs. That’s OK, I just filled the other half with 0xFF. The next problem was the PET ROM slot expected a 2532 style pinout but my EPROM was a 2732 which has a slightly different pinout. Luckily, this can be overcome by making an adapter carrier to swap the 3 of the pins around. This site was useful in creating the adapter so I won’t go into that here. (Note: There’s two adapters on that site, make sure you’re building the 2732 -> 2532.)

Next was the software, which was easy enough to transfer to a 1541 floppy disk that can be read with the IEEE-488 enabled Commodore 2031 Single Floppy Disk drive. I put it as the first item on the disk so the “shift-run/stop” trick will load and run the first item on the disk.

Finally, I needed to figure out how to make the cable. I was going to need to test the user port pins to locate which ones the program was using. I examined how the VIC-20 and C64 do RS-232 over the serial port first. Immediately, I found that pins B and C were tied together for receive (RX). Pin C is PA0 which is a GPIO pin and B is /FLAG2 which I believe is for an interrupt. This makes sense since you want to immediately begin processing incoming data as soon as possible. The PET user port pin B is CA1 is is also for an interrupt. I had a hunch it may be used the same way.

To test the pins, I tied pins B and C together and connected to a USB RS-232 TTL adapter. I used a terminal program called CoolTerm, set the baud rate properly and tried sending characters. Nothing. I then tried B and D. Nothing. I kept trying until I landed on B and F. This DID give me something on the PET screen. It wasn’t correct, but it was receiving something.

I repeated this hunting for the transmit (TX) pin but this time only on a single pin. I found pin H was being using for transmit but again, it wasn’t recognizable characters from the PET but something was being transmitted.

Next I wanted to troubleshoot the characters not being displayed right. First thing was maybe it was the wrong number of data or stop bits or even parity. I tried many different combinations: 7n1, 7e1, 8e2, etc. None of them seemed to make a different. Typing the alphabet “abcdef..” seemed to return the alphabet but in seemingly reverse order with some other characters interspersed.

I decided to get the scope out and look at the differences between the USB RS-232 and PET signals. I decided on the ‘0’ character since it’s the same for ASCII and PETSCII just in case that might be part of the problem. Below is a comparison of the two.

Immediately you can see the issue. The Commodore PET is using a logic low for false and logic high for true (which I’ve learned is called “non-inverse”). Standard RS-232 TTL signals are “inverse” of this using logic high for false and logic low for true. This would explain what I’m seeing since the bits are reversed. I connected the pins through a 7404 inverting IC to invert the singals to and from the PET.

This yielded partial success. I was now able to send characters to the Commodore PET.

Sending characters from the PET to the USB RS-232 TTL adapter revealed that it was setting bit 7 high. If bit 7 was set low, it would be working fine. I’ve still yet to figure this out. If you have an idea, leave a message in the comments.

I later found in the BASIC code of McTerm on line 1070 was a way to use inverted RS-232 which does work without the inverting circuit.

1070 sysa :rem ***** use a for regular modems, a+36 to invert


---

The second method was found in Transactor Magazine issue 3 volume 6. It included a type in terminal program (simply called “Terminal v11”) and simple instructions for building a user port cable. I believe this program was created by Steve Punter, who also created the only known BBS program for the Commodore PET. Being a type-in freebie in a magazine, it wasn’t as full featured as McTerm but it does do automatic PETSCII/ASCII translation and has file transfers using an early version of the Punter protocol. It is locked to 300 baud however.

Next up was the software. I really didn’t relish the idea of reliving that part of my childhood and typing all of those DATA statements. Modern technology to the rescue in the form of a free online OCR service. Much to my surprise, this service worked extremely well. I did have to process each column of code separately by extracting each from the PDF as a JPG. The most OCR errors were in the BASIC program but it was still dramatically lower than what I expected. Between the two ML programs with the DATA statements, those only had a single error! I later found version 12 of Terminal was available here [local cached copy].

This time, the PET user port pins were listed. Pins B and L are for RX and pin C is for TX. I swapped my user port adapter cable around to match this pinout, ran the signals through the inverter circuit and tried it. Immediate success in both directions!

Now that I have a working RS-232 cable and software for the PET, we can put it to use. I connected it to a SparkFun ESP8266 breakout board. This board connects over WiFi and can support a standard Hayes modem AT command set with the right firmware.

With this adapter, I’m able to “dial” into BBS systems that are accessible via IP. One such board is Level 29 which is run by @FozzTexx.

ATDT bbs.fozztexx.com:23

So, was non-inverted RS-232 TTL a standard 30 years ago since two separate terminal programs used it? When did inverted RS-232 TTL become the standard?

So, until I can figure out what’s wrong with McTerm transmitting with bit 7 set, use Terminal instead and you can use RS-232 on your PET.

*Actually, Commodore dropped the PET moniker shortly after they introduced the line and changed it to just CBM. The name PET just fits better I think.