The #Datapoint2200 keyboard PCBs have arrived and they look fantastic. Somehow larger than I expected, and very imposing.
The #Datapoint2200 keyboard PCBs have arrived and they look fantastic. Somehow larger than I expected, and very imposing.
Went out to dinner tonight with a red friend. Not a lawyer, not online, said he gets most of his info from the WSJ.
Anyway, he wants Trump gone. #datapoint
RE: https://bsky.app/profile/did:plc:cz3p35o2uexpt6l5sngcnu2j/post/3lkqzv3ts722h
https://www.europesays.com/1752822/ Nearly Half of Rural Small Businesses Use the Bank on the Corner ##banking #america #business #CommunityBanks #CreditUnions #DataPoint #DigitalBanking #FeaturedNews #MobileBanking #News #PYMNTSIntelligence #PYMNTSNews #SmallBusiness #SMBs #TheDataPoint #UnitedStates #UnitedStatesOfAmerica #US #USA
I've now added some photos to the repository (link in previous toot). Not the best quality but there's now something to look at.
Here's a couple of those for the Decoder PCB. There are more in the repository itself.
I've just pushed a very long overdue update to my Datapoint 2200 repository.
New stuff includes schematics for video, keyboard and keyboard logic.
I've added a fair few LEDs to the processor PCB for most of the main registers, but I need to analyse which other signals deserve to have them.
I also need to add some photos and PCB renders to the readme.
#Datapoint 2200: I have the memory cards designed and assembled but no memory chips. My plan is to add a 'backpack' board using modern parts.
Each card uses 32x 512 bit shift memory chips. The best modern option is probably 512 bit FIFOs and tie the outputs back to the inputs to recirculate data.
You can get 9-bit or 18-bit wide chips but every bit is read and written together. So you need a multiplexer on each bit to select new data or recirculate.
What's the main challenge in assembling old code on a modern(ish) assembler? The old assemblers only consider the first few letters of a mnemonic significant. The 8008 has an INC opcode. My assembler has an INCLUDE directive.
(The old code doesn't use INCLUDE, but I need to import symbols from other files. The easy way is to write public symbols to a file in suitable format for an INCLUDE).
I wrote a Z80 assembler a few years ago. Thankfully I subclassed out the Z80 specific stuff. I've been updating it for Datapoint mnemonics and syntax.
I've also typed in the #Datapoint operating system listing from the Programmers Manual (46 pages. Nothing to a child of the 80s).
I'm now working through the files to get them to assemble. Currently there's a circular reference to resolve (comment out on first build), a couple of directives to add and an opcode which doesn't officially exist.
Now to get memory writes working in the Datapoint simulator. There's a /MEMORY_WRITE_READY input which needs to be driven. The circuit for this is on the keyboard decoder PCB.
Unconnected to the rest of that board, except for a POR output. Not the first bit of circuit I've found spilled onto a different board.
The circuit drives the /MEM_WRITE_READY line while the hardware bootloader reads data from tape. I can just glue it high for now.
'Clear the carry tiggle'.
I think they meant to say 'toggle', although twice suggests it may be intentional.
The documentation usually refers to 'flip-flops' as opposed to 'flags', or 'toggles'.
I like how the #Datapoint assembler has pseudo instructions to load a 16-bit value into the H, L and D, E registers. Strangely there's no equivalent for B, C.
I'm spending the afternoon running through the #Datapoint2200 instruction set in the simulator to test everything.
So far, loads working, as are all the ALU operations, including the two shifts.
I've done my first ever use of the stack (with CALL and RETurn) which checks out okay.
Pretty much the only thing left to test is writes to memory. I'm fairly sure there's still a bug in the simulator code due to time when I'm clocking the memory bits. Should be a simple fix.
Long strings? What craziness is this!
(From the #Datapoint2200 Programmers Manual. The STATH library manipulates numbers stored in strings ('numeric strings')). In ASCII.
(I can't image how much that must have hammered numeric performance. And the Datapoint wasn't exactly the fastest machine to start with.)
Want to learn how to build and foster a strong, healthy #DataCulture in your organization?
Then you should definitely attend my session called "The #DataDojo: A #PowerBI #CommunityOfPractice" at #DataPointPrague2024 (May 30-31, #Prague, #CzechRepublic).
Register here: https://datapointprague.cz
Shout out to @StepanResl and #DataBrothers for organizing this conference, it's gonna be a real banger!
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
I'm adding a basic terminal to the #Datapoint 2200 simulator. It's listening to output ports (input still to do).
Here's a video of it saying "Hello World" in it's own fashion. Program listing in video comments.
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.