The Omni-USB project

Introduction

One problem when dealing with vintage PDP8 computers is finding reliable and effective ways to communicate with the "modern world" of computers. The main application of a PDP8 to PC connection is to backup and restore vintage mass storage like RK05 disk drives or TU56 DECtapes.

The KL8E and its derivates provide an asynchronous serial port (20mA and RS232) to connect to the outer world. On a PDP8/e system the KL8E is used as the console port, additional lines can be used for other purposes. Therefore everybody has been using an RS232 connection to a PC for decades. This works quite reliable with software like Kermit or the very cool Dumprest tools.

So what's wrong with that? It sounds as there's already good PCP8 to PC connectivity!

Nothing. But ...

• What about speed?
  A KL8E supports a maximum baud rate of 19200. With a little trick it runs at 38400 baud. Doing image transfers of mass storage media works nicely. You only need very much patience. And if you have lots of DECtapes or RK05 disks to process, you will very easily grow old while waiting and waiting and waiting.
  
  
• You begin to realize that the availability of RS232 ports on the PC side has begun to cease.
  Yes, of, course, your PC still has an RS232 port! And there are USB to serial converters. Yes, I know. So there is still RS232 around. And it surely will be for some time. But it will be more and more forgotten.
  Linux kernel support for 8251 and friends has seen better times as well.

And what the hell is that Omni-USB thing?

It is a wonderful Omnibus compatible board that connects your beloved Omnibus PDP8 to any crappy PC or whatever that comes with an USB host adapter!

What about software compatibility?

• On the PC side you need a driver for the "serial" converter. You can get it directly from FTDI. They make those wonderful USB to FIFO converter ICs that show up as a serial port on your PC. The Linux kernel natively supports the FTDI chip via its "ftdio_sio" module.
  
  
• On the PDP8 side the board is mostly KL8E compatible. You put it into your machine, set the device codes (via two rows of DIP switches) and start to use it like any KL8E. There are some small differences and improvements that will be discussed below. I could not yet find any existing PDP8 software that did not work flawlessly and out of the box with Omni-USB!

Instruction set

About the pseudo flag
The FIFO chip provides a signal that tells whether the FIFO can accept data or not. This signal is used to determine if we can send a byte ("teleprinter flag set"). But we cannot use this signal as value for the teleprinter flag because the original teleprinter flag can be set and reset by the user. The second aspect is that the original flag is initially (after a reset or CAF) unset. And the interrupt is initially enabled. So directly using the FIFO's ready signal as teleprinter flag would result in a permanent interrupt condition from the interface.
The solution was to introduce the pseudo flag. It is maintained in the CPLD only and has no relationship to the communication. It is set and reset like the original teleprinter flag and set with each of the two print instructions. The interrupt condition is "FIFO ready AND pseudo flag set". So if interrupts are enabled and a character is sent, the interrupt will occur when the FIFO is ready to accept the next character.
To the PDP8 this masquerade feels quite straightforward

The incompatibilities The instructions KCF, KIE, TFL and TSK are not found on PDP8 computers prior to the 8/e. Douglas Jones recommends not to use them because they are not portable between all PDP8 computers.
I had to search the DEC docs for more or less clear information about them. My implementation of those is based on my personal understanding at the time I released the 1.00 CPLD.
My KCF instruction clears the AC. This seems to be wrong. And my TSK skips if the board has an interrupt condition. I think I read it exactly that way. But Doug Jones describes TSK as "Skip if teleprinter or keyboard flag set" - without the interrupt condition. I don't know what is right here.
Good code does not use those. And if you want 1000% compatibility, the CPLD has to be updated.
My advice: Do not use those instructions in your code and be happy! I found out about my wrong KCF assumption while writing this text - not during the many hours of Omni-USB usage!

KCF
On the PDP8E (not yet found in the 8/i handbook!) this instruction clears the keyboard flag. Omni-USB does not maintain a keyboard flag. It uses the FIFO's data available signal as the value for the keyboard flag. It is therefore impossible to clear this flag.
Omni-USB clears the AC on this instruction. This seems to be wrong. The AC is cleared only with KCC. Just forget about KCF - nobody wants or uses it!

KSF
Skip if the FIFO has data available. Nothing else to say.

KCC
On the PDP8 this clears the AC and the keyboard flag. It also sets the "reader run" flip flop for DEC modified ASR33 teleprinters. Omni-USB does not support "reader run" and the keyboard flag (see above). So all this instruction is to clear the AC.

KRS
If data is available from the FIFO, a byte will be taken out of the FIFO and OR'ed into the AC.

KIE
AC11 is put into the interrupt enable register.

KRB
The AC is cleared, and a character is taken from the FIFO to the AC.

KTURBO
This instruction is more complex and cooler than the DEC people ever planned.
If a character is available in the FIFO, the instruction works like a KRB and then skips the next instructio. If there is no data, the next instruction (usually a JMP .-1) will be executed.

TFL
Sets the pseudo flag. Nothing else happens.

TSF
Skip if FIFO can take data. Attention: The pseudo flag does not have any influence in this place!

TCF
Clear pseudo flag.

TPC
Send out a character. The pseudo flag is also set by this instruction.

TSK
Skip if interrupting (Interrupting = FIFO has data OR (FIFO can take data AND pseudo flag set))

TLS
Send out a character. The pseudo flag is also set by this instruction.