Monitor loads hex over serial, and RAM is proven whole

What I tried

Two new monitor commands in ROM. L addr,len takes hex digits off the wire, writes them to RAM and prints a running 8-bit sum so the host can check the transfer. G addr does a CALL into RAM, so a loaded program ends with RET and lands back on the prompt. No microcode burn; it is all program ROM.

On the host, dinoload.py assembles a .asm, sends L, streams the bytes and compares the monitor’s sum against its own. The first version burst the whole line and the machine dropped characters. Four fixes in a day: flush the port and retry the sync CR, type one character at a time and wait for its echo before the next, keep bytes that arrive past the delimiter, and show the session live with echoes, the sum line and a byte counter. A per-character echo check means a wrong echo names the position.

Then RAM. Every bench-green image so far had kept its cells and stack inside 0x8000-0x80FF, so RAM above that was formally open. Wrote data and fetched instructions across the range.

What I measured

• Paced typing, one character per echo: no drops. Burst: drops. So it’s the machine.
• bigxfer, an early RAM program that CALLs into the monitor’s ROM subroutines and RETs back into RAM, printed 261 bytes to the terminal. CALL from RAM into ROM and RET from ROM into RAM both work.
• RAM 0x8000-0xFFFF: data lands and reads back, instructions fetch, across the whole 32K.

What broke or surprised me

The loader was sensitive to everything. It worked sometimes, which meant noise, and the noise was on the DINO side: the serial card is the only device in the machine that counts strobes or has an asynchronous reset, so so a serial-only fault with the ISA self-test clean has to be a strobe or a reset.

Next

Next is loading something real: life.asm, Rule 30 on the terminal, seeded from the DIP switch, with the rule table patchable from the monitor prompt. Then a large transfer both directions to see whether the wire has settled.