I/O on the #Datapoint 2200 (as I'm understanding it) :
The instructions are similar to the i8008. Bits 4 to 1 of the bytecode code the I/O port. 32 addresses, but the first 8 are inputs, mapped to instructions IN 0..7. The remaining 24 are outputs mapped to instructions OUT 0..23.
The Datapoint uses the instruction EX for outputs (short for external IIRC)). Rather than port numbers it uses names. The first 8 are generic:
EX ADR
EX STATUS
EX DATA
EX WRITE
EX COM1 though EX COM4
🧵
Returning to the #Datapoint simulator to try and fix a thorny issue that's been eluding me for a while.
The four chips at the bottom are '193 counters which normally house the program counter. Above are a row of '153 4-to-1 multiplexers. These can load an address from the stack, the H, L registers or the temp address register (for inline jump, call addresses).
"A programmer that's never programmed a computer in binary is like a child that's never run barefoot over Lego."
Also can you spot the schoolboy error in the first line of code? Which means all the jump target addresses are wrong and I need to redo a lot of stuff.
I fixed the ALU issue. The clock input of the carry flag latch wasn't triggering. The circuit uses a couple of open-collector gates and a pull-up. A bug in my simulator failed to recognise the net's rising edge.
A few upgrades to the simulator so it can free run and some speed ups. Below is after adding 1 to A and looping until the carry flag is set, using a JFC (Jump if Carry False) and HALTing.
Todays test program: load values into the A and B registers, add (or subtract) them and loop.
I've got the jump working but the ALU ops are not so pretty. It's inverting each bit of A if the bit in B is set. The circuit for the ALU is all standard gates, and I'd be surprised if there's any bugs in there given the rest of the simulator is working so well.
So it's probably a schematic issue, and one which will take a bit of debugging.
"Hello!!" (Read the registers from top to bottom <g>).
(I had to fix a bug in the 7474 simulation to get this to run. It was listening to the SET and RSET pins if they went low. But the design had both low at the same time, the first one to go high 'lost'. The simulator now updates if either pin changes to any state (it already checks them to overrides CLK updates they're active)).
This feels like a good time to look at what is needed to start the #Datapoint 2200 processor.
The Datapoint has no ROM, not even a boot ROM. On reset it rewinds tape deck 1, loads the first file, and executes it. All of this is done in hardware.
The #Datapoint 2200 gate simulator can now import data from multiple projects and I can join boards together via connectors. So I now have the Decoder, Motherboard and Processor boards imported with net data propagating across them.
Some of the nets can have multiple drivers across different boards, so the simulator needs to examine all pins across the joined nets, and propagate the results back to all pins.
I'm now adding tooling ready to try and boot the processor, such as the scaling here.
My #Datapoint 2200 net simulator is now generating output which matches my analysis of the Decoder board schematic (see comments on the image).
One full cycle takes 80 clocks. First SYS_CLK is divided in two and split into four T states. T0 clocks a decade counter (C0..C4). Most outputs are a combination of counter and T states.
Counts 0 to 7 are when memory and/or registers are clocked (PHIxx). Counts 8 and 9 are when 'other' stuff happens (STROBEx).
The #Datapoint processor board is large, expensive, and will take a long time to solder up. It could have errors from my transcribing the schematics or the schematics themselves. It may even have deliberate traps to stop competitors stealing the design.
I really need a way to prove the design works. I could use Logisim for that. But re-entering the whole thing would take ages, and have issues of it's own (and assuming it could cope with the design).
Current status: proof reading the schematics. I’m following every connection and using highlighter pens to mark where I’ve been. And doing the same to my schematics. The assortment of colours helps to stop me getting muddled.
Thus probably counts as tedious but my brain enjoys this kind of task.
Adding a page of spare units, based off the table on the original schematics, but the design checker doesn't like it.
So, the original is hard to read, and I've not double checked what I've copied, but it clearly shows Z95 with some spare units. But Z95 is one of the RAM chips making up the stack. So this table is definitely error prone.
Adding footprints. No difficulty here. There's only 8 different footprints across the board: 3 for connectors; 2 for capacitors; 1 for resistors; and 2 for chips.
This was the early days of 74 series logic so only 14- and 16-pin packages in use.
Now this is the dictionary definition of tedium. An entire page of power units for the logic gates.
Gaps are for chips with power connections on the main symbol. Not, BTW, the same as chips containing a single unit - there are several 8-input gates with one unit per chip but those still have a separate power unit.
I've copied the Decoder PCB to get the edges of the Processor PCB. I'm using a print out of the decoder PCB and the long edge dimension of the decoder board to work out the scale of the print out.
I can then measure and scale up from the print out.
I'll keep the old decoder components and silk screen for the moment to reuse dimensions and design standards.
Next up, H and L registers. Probably the simplest schematic of the lot.
These shift registers output to the /DATA bus via an open collector NAND gate. The /DATA line takes output from all the registers, the memory cards, and the tape board - which reads a file on reboot.
Inverters (top left) output to
the REG_DATA line which is used as input by the B,C,D,E,H,L registers,
the DATA line which is input to everywhere else (IR, ALU, temp addr reg)
And the address multiplexers. Data can be loaded into the address registers from 3 sources: the stack, the H and L registers or the temp address register. The multiplexers select the source.
The Temp Address Register is used when reading a call or jump inline address. These are the only instructions which take an immediate address. All other memory references have to go via the H and L registers.
It's worth noting that this circuit functions for every opcode in the instruction register even if it's not a branch instruction.
It's only at the next stage that the processor examines whether the opcode is a jump, call or return and sends signals elsewhere to load an immediate address, push the program counter on the stack or pop a return address off the stack.