Backplane

RDP-9

Project Description

This project aims to build an ISA-compatible clone of the DEC PDP-9 system using primarily technology from the late 1970s - early 1980s period. I did this to ensure my design followed the same constraints that later genuine minicomputer systems were built with, while being able to significantly reduce the size and complexity compared to an actual PDP-9. The specifics are as follows

• Use only 74-series logic and other similar TTL logic level parts that would be available around the later 1970s timeframe. The exception to this is RAM, which I plan to use more “modern” SRAM chips instead of torturing myself with dynamic RAM.
• No FPGAs, PALs, GALs, microcontrollers, etc in the main processor path. The only exception to this is using standard 27C style ROM chips to hold the microcode.
• Usage of a period correct microcontroller or microprocessor for the disk / drum subsystem. Using another simpler processor to control complex devices like disks was done frequently on other minicomputer designs, so I’ll be doing it here too.

My end goal is to build a system that is capable of running most of the interesting software of the period. This includes DECsys, ADSS, DOS-15, and UNIX V0. To do this, the system will need:

• Full compatibility with the PDP-9 instruction set. This includes EAE instructions and extended memory
• The ability to hook up to a real or emulated paper tape punch / reader.
• The ability to hook up to a real or emulated ASR-33 teletype or similar serial terminal
• 8" floppy drive interface in place of DECtape. Software will require patching but it's better than trying to emulate DECtape
• IDE hard drive support using RB09/RF09 interface

Theory of Operation

Due to the complexity involved with the architecture of the DEC PDP-9, the system is split into two subsystems:

The first subsystem is the processor itself. It has a full 18-bit datapath with 15-bit address bus, and is implemented entirely using TTL logic.

The second subsystem is the I/O bus. This is directly controlled by the processor itself and is capable of servicing the following operations:

• Device interrupts
• IOT transactions
• Add-to-memory operations
• Data channel transfers
• DMA transfers
• READ-IN operation

Device Interrupts

Device interrupts simply tell the processor to begin an interrupt operation. When an interrupt is accepted, the I/O bus will be notified of the action and is responsible for turning off the "Program Interrupt" flag. If this does not happen, interrupts will continuously loop.

Steps:

1. Interrupt is accepted. MA is completely zeroed and the "INTERRUPT_DETECT" pulse is asserted for this clock cycle.

2. PC is stored in MB, OB

3. The logical OR of MB and OB is place in CORE at MA. The crossbar will add the LINK and MEMM flags

4. MA + 1 is placed in the PC. Extend is enabled to ensure that bank 0 is selected. The next fetch will ignore device requests

IOT Transactions

IOT transactions allow data to be transferred to or from the accumulator. IOTs also allow for skips to be requested. Every IOT is treated by the CPU as a Read-Modify-Write operation. By using the "EXTRN" signal, devices can notify the processor to read from the I/O bus instead of the writeback register. When the I/O bus is being sampled, the "IOT_SKIP" signal can be asserted to tell the processor to perform an addition increment of the program counter.

A wait signal is sampled at the beginning of the IOT as well. This can be used to add cycles to the writeback phase of the IOT if the device needs it.

Steps:

1. IOT transaction begins. Device address is placed on the I/O address bus. AC (or 0 if the flag is set) is written to the WRTBK register.

2. Signal "IOT_PULSE" is asserted.

3. Signal "IOT_PULSE" remains asserted. External input is sampled into MB. Signal "EXTRN" must be asserted to take value from device bus.

4. IF "IOT_WAIT" is asserted, goto step 3 in place. No IOT signals are asserted. Interally, the CPU is performing the logical OR and writeback of potential provided data.

5. No IOT signals are asserted. Internally, the CPU will perform the skip here if it has been requested. The next fetch cycle will ignore interrupts and device requests.

Device Requests

The final three transaction types (Add-to-memory, data-channels, and DMA transfers all share the "device request" pathway.

Steps:

1. Signal "REQ_ADDR_PHASE" and "DEV_REQ_GRANT" asserted and held. External value written to MA.

2. If DMA is selected, core is read at MA and written to WRTBK with next as step 8. Otherwise core is read at MA and written to MB, OB. "REQ_ADDR_PHASE" held

3. Value in MB, OB incremented and written back to core at MA and OB. "REQ_ADDR_PHASE" held

4. Value in MA incremented. If add to memory selected, Jump to fetch without device request logic. "INCREMENT_ZERO_PUSLE" will be generated if needed. "REQ_ADDR_PHASE" held

5. Core is read at MA and written to MB, OB.

6. Value in MB, OB incremented and written back to core at MA and MA

7. Core is read at MA and written to WRTBK

8. External value written to core at MA. "DEV_REQ_GRANT" reset. Jump to fetch without device request logic

READ-IN Operation

The read-in is used to transfer a set series of words into memory from one of the I/O devices. Only one I/O device can be be allowed to respond to READ-IN at any one time. When a READ-IN transaction is active, the CPU will stall until the designated device signals that it is ready. The device will either signal the CPU to commence another READ-IN cycle, or to terminate the READ-IN after any given transfer.

Steps:

1. SWR is moved into PC

2. "READ_IN_PULSE" is asserted, step will loop till either "IOT_WAIT" or "IOT_SKIP" are asserted.

3. "READ_IN_PULSE" remains asserted. EXTRN is moved into core at PC. Continue having the constant value asserted.

4. "READ_IN_PULSE" reset. If "IOT_SKIP" is asserted, jump to CONT logic. Otherwise move PC + 1 into PC

5. Null phase, "READ_IN_PULSE" remains reset.

6. Null phase, "READ_IN_PULSE" remains reset. Jump to step 2 on completion