After an evening wrestling with Inkscape I’m ready for an early night. But the diagram actually looks pretty good, and means I’m significantly closer to publishing an article I wrote six months ago.
@RetroFunPL New ‘improved’ app, rewritten from the ground up.
The UX is horrible. The key pain point for me is that there doesn’t seem to be any way to connect to the NAS. Although it did work for the first five minutes, but the artists list had no A-Z quick links and I was having to scroll down through several hundred entries.
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
🧵
To poll a device for input data:
Set A to device address
EX ADR ;Device selected
EX STATUS ;Prepare to read status byte
INPUT ;Read status byte
Check value. If data available:
EX DATA ;Prepare to read data
INPUT ;Read data
Data is now in A register.
However, the output port is decoded on the decoder board using bits 4..1 of the instruction register. They're exposed on pins on the processor boards edge connector.
The instruction decoding for the INPUT command looks to be partial enough that it is issued irrespective of the port address. If so another board could be decoding I4..I1 to give an input port address.
(But the pinouts for every board are unique to that board. It's possible no other board has access to them).
BTW the 'Clocks' readout on the simulator counts half cycles. The simulation takes just over 700k half cycles to run. That translated to about 35ms at the 9.84MHz crystal frequency.
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).
Executing the LAM instruction (equivalent to LD A,(HL) in Z80) involves storing PC on the stack, asserting /ADDR_SEL.HL to set the multiplexers and /ADDR.LOAD to latch the data in the counters. Data latched whenever the signal is low.
But the simulator loads all 1 bits - the 'off' value for the multiplexers.
/ADDR_SEL.HL and /ADDR.LOAD are driven by the same circuit, timing separated by gate delays. Presumably this works in the original machine but my simulator is experiencing some kind of race condition which keeps.
I've tweaked the simulated gate delays for the multiplexers and the timing logs show they're changing /after/ LOAD is cancelled. Next stage is to add some detailed logging to the chips to see what's happening.
All these people getting excited about not seeing the sun for a few minutes should try living in Britain. We can go entire months without seeing the sun.
"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.
If you’re making an audio player and I press the back button two seconds into a track it probably means I want to play the previous track, not skip back to the beginning of the current one. #UXThatTriggersMe
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.
Note the Clocks count in the previous image: 2.6 million. That's counting half cycles of the 9.84MHz crystal.
So that simple code took over a tenth of a second to execute! This machine was not fast.
For every jump the shift memory has to be clocked until it's in the correct position. There are 512 bits per chip. At 1.2MHz it takes about 500uS for a full rotation, or about 2,000 rotations per second.
The same goes for any memory access and subroutine calls and returns.
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.
@poleguy If there were spare gates around that may have made sense.
I’m also wondering if the intermediate products were useful in some way. But if it’s more efficient to make and adder without XOR gates I feel like the entire electronics industry has missed something big!