Back plane and Board size

I've decided to go for DIN 41612 96 way connectors for the back plane. I've also decided upon having two connectors per board. This will allow the provision of a 32-bit address bus and a 32-bit data bus. Although the CPU will only use 16 data bits for now.

The hardware specification follows the theme of the NuBus.

The board depth will be 220 mm as standard. Allowing the use of a 235 mm sub-rack.

The board height will follow the IEC standard and be 6U ( 100 mm + (6/3 - 1) * 5.25" = 233.35 mm (9.19").

The 41612 connectors will be centered 50 mm from each board edge, and 5.25" center to center.

For the back plane the Harting 0903 296 6825 socket (Farnell #1096910) will be used.

For the cards the Harting 0903 396 6921 right angle plug (Farnell #1096950) will be used.

The back plane will be housed in a Schroff 24563-432 6U 235 mm sub-rack (Farnell #1455791).

Following will also be required:

Assembly kit 21100-435
Guide Rail 220 mm deep 24560-353
Torx panhead screw 2.5 * 9.3 mm 24560-141

Card spacing in the back plane will follow NuBus as 0.8". Maximum component height will be 13.97 mm. The maximum component lead length below the board will be 2.54 mm. The maximum bus length will be 13.2", allowing 16 card slots.

Clock termination will be 120R/180R at the far end, and address control lines will be terminated at both ends by 270R/470R.

Having a 32-bit address bus gives a maximum memory of 4GB, well enough. The top 256MB will be allocated as private to the slots, 16MB per slot. Back plane will provide each card with the ID number of the slot (0-15). The higher the number, the higher the slot priority.

There will be no top cover for the sub-rack, and so nothing to interfere with the cables up to the console PCB. The console PCB will be mounted on the back of a 3U front panel.

What a fixed up set of units, that is what you get by using standard parts.

 Doesn't sound much but that all took a whole day to work out.

Scope is here!

The scope is here, and it works fine. The photo shows the testing of the switch debounce circuit. The ATX bench power supply can be seen to the right of the picture.

The rack cabinet has been ordered, as have the base chips for the ALU. I've also ordered at extreme cost the pro version of Eagle. Have to have the pro version due to the size of the back plane PCB.

Underway

Well the project is finally underway, I fully expect this project to take several years, but it will be fun. I ordered an oscilloscope+logic analyzer earlier this week from Germany, should be here in a couple of weeks. I've also ordered some bits from Farnell to convert an ATX power supply into a bench power supply.

Have downloaded the free version of Eagle (a schematic and pcb development package), and have found BatchPCB on the web. BatchPCB seems reasonable price wise, so looks like I can avoid having to wirewrap everything.

The State Machine

So we have the instruction set, the majority of the ALU stuff. So how to make it tick?

This took me a while to understand, but now it is clear, and it is elegant!

At any given time the CPU is doing something, including nothing.

What the CPU is doing depends upon the current values of the CPU Control Signals.

The current values of the CPU Control Signals and the next State depend upon the current values of the Opcode, the Condition Codes (Flags), and the current State (a number).

The State Register contains the current state. The next state is latched into it on the rising edge of the clock cycle.

The Instruction Decoder takes the Opcode, Condition Codes, and current State values and decodes them into CPU Control Signals and the value of the next state. Think of it like the inputs are the address and the outputs are the data stored at the address. In fact that is a quite good way of thinking about it as we can implement the decoder in a ROM. The stuff stored in the ROM is called Microcode. Which makes this machine a CISC machine. You could implement the decoder in logic gates, and/or diodes, but a ROM is simpler and has the advantage of being software programmable.

For the selected instruction set we will need 10 bits for the Opcode, and for the Processor Status Word Condition Codes 4 bits, and for the State number, humm ...

In all of the homemade CPU's I've looked at on the net it seems like 16 states is enough, however I'm kinda tempted to allow for more in case I want to add multiplication and/or CORDIC in the future (I don't know how many states they will need yet). So for now I will allocate 5 bits for the state.

That gives us 10 + 4 + 5 = 19 bits. So we'll need a 512k ROM.

Each ROM will allow for 8 CPU Control Signals. If more than 8 Control Signals are required then the addresses can be paralleled with multiple ROMs.

Although out of sequence I'd just like to record that having a ROM decode was the real reason to go for the PDP-11 opcodes. You don't have to have a direct one-to-one matching between the opcodes and the control signals. Feed in anything you like, and get out what you require. It is software that does the mapping.

Also it has just popped into my head that a ROM could be used to store constants like +1, -1, AND masks, CORDIC parameters etc. Just mention that in case I forget about it.

The trouble with bytes

I've tried to convince myself that word addressing is best; 64k x 16bits. But you can't get away from the fact that we need data in byte size pieces sometimes. ASCII strings as an example. So, I'm changing my mind yet again (I think that this will be a common feature of this BLOG), the addressing of the machine will be byte aligned, however instructions must be even byte address aligned. Strangely enough, that is how the PDP-11 did it.

So when implementing memory:

1) Ignore bit 0 when addressing memory
2) Organize memory as words
3) Bit 15 indicates byte(1) or word(0) in an opcode
4) When byte only the LSB of register is used
5) Use bit 0 to decide if LSB or MSB of data bus to be used
6) Always fill MSB of register with MS-bit of LSB when loading bytes
7) When writing bytes to memory use bit 0 to determine which byte to latch

I think that should work.

Addressing Modes

In some opcodes there are source and destination fields (SS/DD). These fields are 6 bits wide. The bottom 3 bits (0-2) indicate the register, the top 3 bits (3-5) indicate the addressing mode.

The addressing modes are as follows (all lifted from the PDP-11):

0 - Register contains operand.

1 - Register contains address of operand.

2 - Register is used as a pointer to operand, then the contents of the register are incremented (by 2 for word, 1 for byte).

3 - Register is used as a pointer to the address of the operand, then the contents of the register are incremented by 2 (always).

4 - The register is decremented (by 2 for word, 1 for byte), and then the register is used as a pointer to the operand.

5 - The register is decremented by 2 (always), and then the register is used as a pointer to the address of the operand.

6 - The Index value (stored at PC+2) is added to the address in the register. The sum points to the operand.

7 - The Index value (stored at PC+2) is added to the address pointed to by the register. The sum points to the operand.

I was slightly confused by the lack of immediate loads of addresses and constants etc. However, you don't need special case opcodes as the Program Counter is a general register. After each instruction is decoded the PC is incremented. So the PC points to the memory that contains the immediate data.

So for operations using the Program Pointer (R7):

Mode 2 - Immediate - Operand N follows instruction

Mode 3 - Absolute - Address of operand follows instruction

Mode 6 - Relative - PC + 4 + X is address of operand

Mode 7 - Relative Indirect - PC + 4 + X is address of address of operand

You will note that Mode 5 is the implementation mechanism for the Stack. I know I wasn't going to have a stack but hell why not.

Reviewing the situation

I've been reading the PDP-11 manual mentioned earlier. It is so cool, I can see why the PDP-11 was in production for 20+ years.

Anyway, I'm not going to build a PDP-11, just a machine that internally is very similar.

Registers:

R0
R1
R2
R3
R4
R5
R6 (Stack Pointer)
R7 (Program Counter)

Instructions (the numeric values of the opcodes below are in octal):

00 00 00 HALT
00 00 05 RESET
00 01 DD JMP
00 02 0R RTS
00 02 40 NOP
00 03 DD SWAB
00 04 XXX BR
00 10 XXX BNE
00 14 XXX BEQ
00 20 XXX BGE
00 24 XXX BLT
00 30 XXX BGT
00 34 XXX BLE
00 4R DD JSR
00 50 DD CLR
00 51 DD COM
00 52 DD INC
00 53 DD DEC
00 54 DD NEG
00 55 DD ADC
00 56 DD SBC
00 57 DD TST
00 60 DD ROR
00 61 DD ROL
00 62 DD ASR
00 63 DD ASL
00 67 DD SXT
01 SS DD MOV
02 SS DD CMP
03 SS DD BIT
04 SS DD BIC
05 SS DD BIS
06 SS DD ADD
07 4R DD XOR
07 7R NN SOB
10 00 XXX BPL
10 04 XXX BMI
10 10 XXX BHI
10 14 XXX BLOS
10 20 XXX BVC
10 24 XXX BVS
10 30 XXX BCC, BHIS
10 34 XXX BCS, BLO
10 50 DD CLRB
10 51 DD COMB
10 52 DD INCB
10 53 DD DECB
10 54 DD NEGB
10 55 DD ADCB
10 56 DD SBCB
10 57 DD TSTB
10 60 DD RORB
10 61 DD ROLB
10 62 DD ASRB
10 63 DD ASLB
11 SS DD MOVB
12 SS DD CMPB
13 SS DD BITB
14 SS DD BICB
15 SS DD BISB
16 SS DD SUB

In the above:

DD means destination field (6 bits)
SS means source field (6 bits)
XXX means an offset (8 bits), +127, -128
N means a number (3 bits)
NN means a number (6 bits)
R means general register (3 bits), 0, 7

I've decided for the time being to not implement the PDP-11 traps, interrupts, and modes (user/kernel).

In an earlier post I had decided to have separate memory and i/o spaces sharing the same address bus. I have now changed my mind, we will have all i/o mapped into the memory space as per the PDP-11.

The External Flag (used for the 20ms IPS pseudo-interrupt) will now be memory mapped instead of being a bit in the Processor Status Word (PSW) aka Flags Register. The PSW is rather empty:

Bit 0 - C (Carry)
Bit 1 - V (Overflow)
Bit 2 - Z (Zero)
Bit 3 - N (Negative)
Bits 4-15 Reserved

PDP-11 Manual

Yesterday I found a scan of the PDP-11/40 Processor Handbook, and printed it out. It is amazing how close my ideas are compared to the 1972 real PDP-11 machine. Now I'm really tempted to try and make a PDP-11, but I have to tell myself to learn to walk first. Remember that DEC started with the PDP-1 first before they got to the PDP-11!

Two things jump out; the PDP-11 had memory mapped registers, and any memory location could be used as an accumulator (albeit indirectly). I'm going to go through the manual, and pick out the cool bits. I guess create the PPDP-1 (Paul's PDP-1).