• Please review our updated Terms and Rules here

Ultimate PDP-8 ideas thread

antiquekid3

antiquekid3

Veteran Member
Joined
Nov 10, 2009
Messages
594
Location
Alabama
I have been discussing many projects with various people lately, and thought it would be a good idea to get these out to everyone to "vote" on them and express interest to help myself and others prioritize. I will also touch on projects already completed by others for added visibility.

Without further ado...

Omnibus projects:
  • Bus analyzer card to easily probe the backplane with a logic analyzer
  • PDP-8/A MMU for 128kW
  • "The Ultimate" block device, featuring single-cycle data break, SD card storage, 4095 blocks per device, zero seek time, etc.
  • CPLD CPU set
  • CPLD EAE set
  • TD8E controller clone
  • TU10 controller clone
  • RL01/02 controller clone
  • Punched card reader controller clone
  • Paper tape punch/reader controller clone
  • VGA graphics board (possibly emulating a storage 'scope, supporting bitmapped and vector graphics)
  • Programmable real time clock
  • Posibus converter plus multi-data break board
  • Multi serial/SPI/422/485/MIDI interface board
  • Massive parallel I/O card
  • Sound card and general DAC/ADC board
  • LAB-8/E boards and peripherals
  • LINC/TC12/VC12 coprocessors
Many people want more Omnibus boards. Roland has already done a great job providing perfect copies, including the TA8E controller and the RX8E controller, the latter of which can be used with Don's RX emulator. We already have fast serial boards thanks to Philipp's Omni-USB serial board and other CPLD-based solutions, too. Bootloader, memory, and even the VC8E are all taken care of thanks to the efforts of many, including Roland, Vince, and originally, Steve Lafferty for the memory.

Posibus projects:
  • Expansion chassis (allowing small, pluggable modules, smaller than an Omnibus board)
  • TTY interface (Vince has nearly completed this one)
  • VC8I (point plot display controller)
  • KV8I (vector display controller)
  • TC08 (intelligent DECtape controller)
  • DW8E (for connecting to many Omnibus peripherals)
  • DM04 (data break multiplexer)
  • DF32/RF08 controllers and emulators
  • Negative to positive logic converter
We don't want to leave out people with Negibus/Posibus machines, so having some Posibus peripherals would be useful. These of course can be used with Omnibus machines with the appropriate Posibus converter board. The VC8I and KV8I options could be cloned as they are for an 8/I backplane, as well reformatting them onto a single board for the Posibus expansion chassis. David has already created a working DF32 emulator, but controllers are hard to find. Probably not as hard as finding a working DF32, though...

Schematic projects:
  • Digitize PDP-12 schematics
  • Digitize FPP-12 schematics
  • Digitize FPP-8/A schematics
Vince has already done an incredible job digitizing numerous schematics, including the complete PDP-8/I print set, among many others. Here's the print set for the 8/I: https://svn.so-much-stuff.com/svn/trunk/Eagle/projects/DEC/PDP8I/pdp8i-decSCH.pdf This obviously has many benefits over the original, including readability, text searchability, and the ability to export a netlist and turn it into a Verilog PDP-8/I. The same could be done for the PDP-12 and others, once their schematics are drawn.

Simulation projects:
  • SimH LINC/LINC-8/PDP-12
  • Verilog PDP-12
  • Verilog PDP-8/E
Vince, yet again, has been working on modifying SimH's PDP-8 simulator to support the related LINC machines. He's made tremendous progress so far, but it's difficult when so much of those computers were dependent on the peripherals, which can be difficult to simulate.

Other projects:
  • FPGA PDP-12 (would be particularly fun given the number of cool peripherals)
  • FPGA PDP-8/I
  • FPGA PDP-8/E
  • PLL board for an RK05 to use 12 sector packs in place of a 16 sector one
  • Cataloging all PDP-8 software using SHA signatures, keeping track of metadata, etc.
  • A proper vi clone text editor
  • A comprehensive, all-in-one device dump and restore utility with additional error reporting, based upon David's dumprest utilities
A lot of fun could be had with FPGA clones of these computers, since they could even connect to real peripherals and such, given the appropriate bus interfacing. A PLL board replacement in an RK05 allows us to use PDP-11 packs as if they were PDP-8 packs, so long as they are reformatted.

I'd love feedback on any and all of these ideas, and I suspect some new threads will grow out of this one to discuss specific projects.
 
I would love to see a Unibone/QBone like device for the OmniBus. That probably covers most of the items on your Omnibus list, as long as someone writes the software (other than the logic analyzer probe).
 
I agree, an Omnibone would be a very useful device. There are many design philosophies for vintage computing, and I tend to personally err on the side of not putting a microprocessor in the backplane. Others don't mind CPLDs and FPGAs, and some make the distinction between the two. Others want straight TTL, plain and simple. I tend to fall in the CPLD camp but would consider an FPGA solution if I needed the pin count (such as accurately driving a display panel for the TC08).

So while I might not be the one to design an Omnibone, I would still fully support seeing one, and would be tempted to buy one myself for posterity!
 
Kyle,

This is a very interesting list! I look forward to assisting with the handler parts.

nadaveiron said:
I would love to see a Unibone/QBone like device for the OmniBus. That probably covers most of the items on your Omnibus list, as long as someone writes the software (other than the logic analyzer probe).
Click to expand...
I understand how the Unibone works on an 11. The 8 does not use memory mapped I/O so you would need something that watches for IOTs and then does something with them. It would need to be able to read and write memory in order to perform single cycle data break.

If your goal is to attach virtual devices to OS/8 then my Console Serial Disk project would be a good place to start. If you use a 12 bit parallel port instead of the console serial port you can get performance almost as good as most of the Data Break devices. It looks like you could read a word from the virtual device every 9.6 us for a transfer rate of 104kwps. Writing to a virtual device is slightly slower at 10.8 us per word or a rate of 92kwps. For comparison the DF32 transfers a word every 32 us when operated on 60 hz power. It looks like the RK05 does a Data Break every 8us for a transfer rate of 120kwps. I did a study of unrolling the loop and it would speed up the handler just enough to beat the RK05 data break. But it isn't clear that it would fit in a 1 page handler.

I currently allow a virtual RK05 device as RKA:, RKB:, and a virtual DECtape device as DTA:. I changed the names in case you have real hardware to eliminate confusion. I will be adding RX0X devices soon. These plus the the four CSD virtual devices are all in a single one page non-sys handler.
 
antiquekid3 said:
Posibus projects:
  • Expansion chassis (allowing small, pluggable modules, smaller than an Omnibus board)
  • TTY interface (Vince has nearly completed this one)
  • VC8I (point plot display controller)
  • KV8I (vector display controller)
  • TC08 (intelligent DECtape controller)
  • DW8E (for connecting to many Omnibus peripherals)
  • DM04 (data break multiplexer)
  • DF32/RF08 controllers and emulators
  • Negative to positive logic converter
We don't want to leave out people with Negibus/Posibus machines, so having some Posibus peripherals would be useful. These of course can be used with Omnibus machines with the appropriate Posibus converter board. The VC8I and KV8I options could be cloned as they are for an 8/I backplane, as well reformatting them onto a single board for the Posibus expansion chassis. David has already created a working DF32 emulator, but controllers are hard to find. Probably not as hard as finding a working DF32, though...
Click to expand...
I'll put in a "dissident" plug for the Posibus! I have an 8/L that I'd like to get back to restoring. So some Posibus support for at least mass-media would be great. Of course, only 4K built-in memory is problem ...

I don't see listed in your project-set memory expansion (/I or /L) -- other than the 8/A MMU. It's a small target audience, alas. Adapting Vince's MM8I prototype (you should include it on your list, I think) is a possibility, especially if one ignores the pair of high-order bit switches/lights. Or possibly brings those out to a rear connector for off-chassis implementation, in which case I'd bring out all three IF/DF controls/indications for a integrated solution. I'd put those in the Posibus Expansion Chassis ...
 
pbirkel@gmail.com said:
I'll put in a "dissident" plug for the Posibus! I have an 8/L that I'd like to get back to restoring. So some Posibus support for at least mass-media would be great. Of course, only 4K built-in memory is problem ...

I don't see listed in your project-set memory expansion (/I or /L) -- other than the 8/A MMU. It's a small target audience, alas. Adapting Vince's MM8I prototype (you should include it on your list, I think) is a possibility, especially if one ignores the pair of high-order bit switches/lights. Or possibly brings those out to a rear connector for off-chassis implementation, in which case I'd bring out all three IF/DF controls/indications for a integrated solution. I'd put those in the Posibus Expansion Chassis ...
Click to expand...
I've seen the first version of Vince's MM8I project running on his PDP-12. It is 5 boards that plug in where the cables go for the memory expansion in the backplane. The boards are tied together with a ribbon cable along the side. This should work on the 8/I the same way. The L is a more difficult nut to crack. The Straight 8 and 8/S are also more difficult to add memory to. Just because it is difficult doesn't mean we shouldn't do it.

I am still planning on doing my own Omnibus memory board just because I want to do it the Right Way.

The PDP-8 memory cycle was developed for core memory. Every memory cycle begins with a read which has the side effect of clearing that word. This is always followed by the write portion of the cycle. The value written does not have to be the same as what was read. If you break down a read as a series of register transfers it looks like this.
  1. MA <- address to be referenced.
  2. MB <- MEMORY[MA]
  3. MEMORY[MA] <- 0
  4. if instruction is ISZ or a DEFER CYCLE and MA is between 0010 and 0017 then MB <- MB + 1
  5. MEMORY[MA] <- MEMORY[MA] | MB
If you get rid of the core memory It would not be out of the question to nearly double the speed of an Omnibus machine by re-working the M8330 board to eliminate the unnecessary half of the cycle. The only time you need to do the read followed by write back is the case of the ISZ or the auto index register mentioned in step 4 above. A memory cycle takes 1.2 us or 600 ns for each portion. Get rid of the need for most of the write backs when reading or the pre-read to clear the value in that location for a write and you double the speed. This would have been possible with many of the early semiconductor RAM chips. You would probably have needed the 500 ns versions of the parts to get a 600 ns time. The PDP-8/e is only a little slower than the cheap Arduinos. That would not be the case after this upgrade if possible.
 
>PDP-8/A MMU for 128kW

The KT8-A could be merged with the MSC8DJ and would probably take up just part of a quad-board.
I wonder if the KT8-A could be enhanced to support more than 128k?
 
The RICM has an OMD8S that would let us expand a PDP-8/S to 8k. If someone made a modern replacement for the MC8S it might be possible for us to get this system working and use it for comparison to the new design. We don't have any of the ME8S/MM8S chassis to expand the system to 32k.

I wonder if Vince's MM8I could be modified to work as a ME8S?
 
m_thompson said:
I wonder if Vince's MM8I could be modified to work as a ME8S?
Click to expand...
The 32K MM8i project uses (modern, sort of) delay lines to create timing chains. The delayed MEM_START and TP3 pulses are used to set and clear the various lines which control memory access to the two 32Kx8 SRAM chips and to enable buffers for the input and output lines. That's basically the whole thing. There's a decoder and some shorting blocks to determine which of up to eight fields it will respond to.

I suspect that's a good bit of what the ME8S does, but of course the MM8i is all positive logic, so level converters would be needed at the least.
 
m_thompson said:
>PDP-8/A MMU for 128kW
The KT8-A could be merged with the MSC8DJ and would probably take up just part of a quad-board.
I wonder if the KT8-A could be enhanced to support more than 128k?
Click to expand...
CESI had an Omnibus memory controller that handled 512K. Probably required CESI backplane/Omnibus to support the extra address lines. There are quite a few unassigned pins on the E (fifth) connector so that's not a problem.
Too bad there seems to be no extant CESI technical documentation (engineering drawings, etc..) for products like their CPU8 (2901 bit-slice 8/E), MDC8 (DMA disk controller), MEC8 (512KW mem ctrl).

re: "The Ultimate" block device, featuring single-cycle data break, SD card storage, 4095 blocks per device, zero seek time, etc.
That's close to what Charlie Lasner had with the CESI MDC8 controller.
 
Last edited:
Vince: Curious if someone had an 8i with either no core or faulty core, could this MM8i expansion support the full 32k without the two core modules in the main backplane? I am guessing not, but kind of curious.
 
tradde said:
Curious if someone had an 8i with either no core or faulty core, could this MM8i expansion support the full 32k without the two core modules in the main backplane?
Click to expand...
In theory it could, but you'd have to disable the pre-wired circuitry that attempts to access fields 0 and 1. Whether that requires more than removing modules from the back-plane would be the question.
 
m_thompson said:
>PDP-8/A MMU for 128kW

The KT8-A could be merged with the MSC8DJ and would probably take up just part of a quad-board.
I wonder if the KT8-A could be enhanced to support more than 128k?
Click to expand...
Not and remain compatible. On the surface they added 2 more bits to the CDF and CIF encodings. How many IOT device codes can you afford to steal? But there is lots more that this card does. It has been a while but I remember that they had a way to map any 4 k to any of the lower 8 fields. It would make a great swap device for TSS8 because swap is basically one instruction. The lines on the extra connectors that were used to expand memory were not just 2 extra address bits. They were decoded as 32k board select lines so there were 4 lines of board select for memory beyond 32k. I don't remember what they called them. This reminds me of the Straight 8 memory expansion which defines 7 lines as the field select. Field 0 was internal so it doesn't need a select on the cable. You would jumper the field select line in each 4k expansion.
 
I would think that would be a fantastic tweak to TSS/8: swapping to upper memory beyond the 32k.
 
I never understood why they had dedicated IOTs for every CDF and CIF, 0 through 7. Seems like a waste. Why couldn't they have read AC and used its value to set the bits? Top half could be used for IF and bottom could be DF to accommodate a 6-bit EA, and use a single CDIF instruction, even. CDF and CIF could still be supported separately, of course. Yes, it would take a couple more cycles, but "Look Ma, No Self-Modifying Code!"
 
antiquekid3 said:
I never understood why they had dedicated IOTs for every CDF and CIF, 0 through 7. Seems like a waste. Why couldn't they have read AC and used its value to set the bits? Top half could be used for IF and bottom could be DF to accommodate a 6-bit EA, and use a single CDIF instruction, even. CDF and CIF could still be supported separately, of course. Yes, it would take a couple more cycles, but "Look Ma, No Self-Modifying Code!"
Click to expand...
If only there was someone we could ask.

Once you start down a path it is difficult to change. The docs seem to indicate they did it the same way on the PDP-5 as well. I am sure a 6 bit device code seemed generous at the time.
 
DougIngraham said:
If only there was someone we could ask.

Once you start down a path it is difficult to change. The docs seem to indicate they did it the same way on the PDP-5 as well. I am sure a 6 bit device code seemed generous at the time.
Click to expand...

Anyone seriously interested in the DEC 12b computer family (LINC, PDP-5/8/12) should read Chapter 7 of the DEC Engineering book from 1978.
PDF available here on bitsavers: http://bitsavers.org/pdf/dec/_Books/Bell-ComputerEngineering.pdf
 
Last edited:
Looks like an interesting read. Never seen this one mentioned before. Thank you.
 
You must log in or register to reply here.
Back
Top