Omnibus to USB!


Attention!

The information on this page is outdated and just for illustration purposes!

The definitive place to go is here!


Here you see a few pictures of my first Omnibus to USB converter prototype.

The most important facts:

  • KL8E compatible: Works with RIM-Loader, BIN-Loader, RK8E and other software without modification!
  • Based on the new and cool FTDI FT240X USB to parallel FIFO chip that presents itself as serial port on the PC side!
  • Lightning-fast operation (faster than the PDP8 can handle)!

    The design

    The board is a completely hand made prototype. Even the PCB is homemade. Initially I planned to use one of those CPLDs. But as it turned out I bought parts with too few legs. So I threw in three of them. The next version will use only one CPLD. The air wires come from mistakes when I connected to DATA00-07 instead of DATA08-11. Another wire is used to sample the TS3 signal on the bus which I thought to need at some point in history. The third wire is a workaround for a burnt CPLD pin. On the backside you see lots of wildly applied pullup resistors. I thought I could go with the CPLD's internal pullups - but that's far too slow. Next version will have the pullups in the design, of course. Soldering was an awful fight with the green solder stop laminate - which in fact seems to be something like a solder inhibitor.

    Programming

    The CPLD implements most of the KL8E instructions. Therefore for most software the board just looks like a KL8E. The FIFO design has full flow control, no byte is lost if you stop the PDP8 or the PC program. It works amazingly stable. The FT240X can transfer approx 1MByte per second. That means that the PDP8 can just push the data in and forget.

    I also implemented two extra instructions "KTURBO" and "TTURBO" with OPCODE 6XX7 that combine a transfer and skip on success. So it's possible to avoid the extra test and skip instructions.

    Normally you send a byte this way:
            KSF        / Skip if Keyboard flag set (i.e. data available)
            JMP .-1    / No? Keep retrying.
            KRB	   / Clear AC and read from keyboard
    
    With the KTURBO instruction that looks like this:
            CLA       / Needed because the instruction ORs into AC instead of clearing it.
            KTURBO    / If data available: OR data into AC and skip!
            JMP .-1   / nearly never executed.
    
    The AC is not cleared because I wanted it that way. The CPLD makes nearly anything possible. The main reason is the way the software I'm currently developing does a word transfer:
            CLA
            KTURBO
            JMP .-1
            BSW      / Swap upper and lower 6 bit byte
            KTURBO
            JMP .-1
    
    That results in 4 cycles when data is available. The PC program has to correctly format the data. For comparison here's the way you'd do it with pure KL8E commands:
            KSF
            JMP .-1
            RKB      / Read and clear AC
            BSW
            KSF
            JMP .-1
            KRS      / OR into AC
    
    This results in 5 cycles for one byte of data if data is available. That sounds no big difference but if you keep in mind that the PC can provide data with "infinite" speed, it makes a difference.

    Software compatibility and performance

    The usual stuff

    OS/8, RIM and BIN loaders work flawlessly. Interrupt based tranfers work as well without any issues.

    Dumprest

    The dumprest dumprk05 program works without modification. A disk transfer takes about 4.5 minutes. The restrk05 program needed a few modification because it assumed a hardware problem when there's too much data available :-)

    RK05 imaging performance

    I'm currently developing an own utility that does media dumps and restores. Transferring a RK05 image in either direction takes less than 50 seconds. But without double read and compare. A compare after write would take the same time again. Checksumming the received data is just unnecessary. I like the speed. The tool will be GREAT!

    One level up

  •  
    1024x768    Full size
      My current laboratory PDP8/e with the little board sitting on an Omnibus extender
     
     
    1024x768    Full size
      That's the way the board looks when active.
     
     
    1024x768    Full size
      Here you can take a closer look.
     
     
    1024x768    Full size
      The back looks a bit... strange... But read above. The pullups will be integrated into the design!