Byte Hamr Labs

Aztec C 3.2b on one 800K disk

Fri, 11 Sep 2026 00:00:00 +0000

I had the ProDOS release of Aztec C65 3.2b sitting around as eight 140K disk images. Swapping eight floppies to compile a file is nobody’s idea of fun, and I have a 3.5" drive on the IIe, so I wanted the whole thing on one 800K disk.

What I tried

AppleCommander’s acx did the merging. Created an 800K ProDOS image named /AZTEC, made CC, LN and UTIL directories, and copied the tools across from each disk. Every .LIB went into LN/ so the linker’s CLIB variable finds them in one place. The shell’s PROFILE assumed four separate volumes (/system, /cc, /ln, /util), so I rewrote it:

set PATH=:/ram:/aztec:/aztec/cc:/aztec/ln:/aztec/util
set INCLUDE=/aztec/cc/include
set CLIB=/aztec/ln/

Two acx surprises. create -f to copy boot blocks off the SYSTEM disk died with a null pointer, I think because there’s no BASIC.SYSTEM on it. And write -b refused to write blocks 0 and 1 to the 800K image at all. Ended up reading the two boot blocks out of the SYSTEM disk and dd-ing them into the first 1024 bytes of the .po file.

The eight disks hold more than 800K, so the .ARC library source archives and the DOS 3.3 target libs went on a second image. You don’t need either to compile.

First boot of the merged disk. Aztec C SHELL v1.99j, PROFILE banner, prompt.

It booted first try. Then I typed cc exmpl.c and got this:

cc ran, as ran, then the shell couldn’t reload itself. Any key just prints it again.

The Manx shell unloads itself to run a program and reloads SHELL.SYSTEM afterward. The reload is a little native stub the shell parks at $BD51, and it builds the pathname from a directory string the shell stashed at $BC11 plus the literal SHELL.SYSTEM. That stub loops forever on failure, so a reboot is the only way out. Typing set showed the problem:

set output. HOME is /AZTEC//AZTEC/SHELL.SYSTEM, which ProDOS rejects.

The shell computes its home as the ProDOS prefix plus whatever is sitting at $0280, the spot where the launcher leaves the name of the system file it just loaded. Manx assumed a bare filename there, which is what a 1986 Disk II boot gave them. On this machine $0280 had the full path, so the shell glued /AZTEC/ onto /AZTEC/SHELL.SYSTEM, and the double slash is an invalid ProDOS pathname. Setting HOME in PROFILE doesn’t help; the stub gets its copy during init, before PROFILE runs.

The fix is a loader that boots first. AZTEC.SYSTEM is 186 bytes of 6502: copy itself to $0300, SET_PREFIX to /AZTEC/, OPEN and READ SHELL.SYSTEM into $2000, write a bare SHELL.SYSTEM string to $0280, jump. ProDOS boots the first *.SYSTEM file in directory order, so I deleted SHELL.SYSTEM and re-added it after the loader.

With the loader in front. HOME is /AZTEC/ and cc comes back to the prompt.

cc calls as on its own, so there’s no separate assemble step. cc -A stops after codegen and leaves the .asm for reading.

Tail of the generated asm for hello world, then the link. 11,898 bytes total.

What I measured

Eight disks total 1,116,160 bytes used. An 800K volume has 819,200.
AZTEC.po: 1411 blocks used, 188 free, about 94K for source and objects.
Loader: 186 bytes.
Hello world with printf: code 11,274 bytes, data 552, uninitialised 68, total 11,898.
Linking that one object against c.lib (59K) off the floppy is slow enough to notice.

What broke or surprised me

The shell’s builtins are lowercase only. SET with caps lock on goes looking for a file called SET, fails, and drops into the same reload loop.
The 3.2a in every signon banner is fine. The READ.ME says 3.2a was the last beta and 3.2b is the same binaries with the beta label removed.
VED is arrow-key driven. hjkl does nothing.
11.9K for hello world. Aztec links whole library modules, and printf drags in stdio, buffered files, the ProDOS I/O layer, the console driver and malloc. Every C call goes through helper routines and a software stack because the 6502 has nothing that looks like a C frame.

Nothing on the C side. This was a one-off to see what the experience was like, and the answer is that Merlin is a better place to write for this machine. The disk stays useful for grep, diff, hd and a working 800K ProDOS boot. The loader trick applies to any old system program that expects a bare name at $0280.

The instruction set, all 174 of them

Thu, 10 Sep 2026 00:00:00 +0000

I’ve never written the instruction set down in one place. It lives in microcode_gen.py as a table of control-word rows, and the assembler and the oracle both read it from there, so the ISA has been whatever that file said. This entry is the readable version. The opcodes, byte lengths and T-state counts below are dumped from that table, so if this page and the machine disagree the page is stale.

The shape of it

8-bit data, 16-bit addresses. Three registers: A is the accumulator and the ALU’s first operand, B is the ALU’s second operand, C is scratch. B:C doubles as an index pair with C as the low half. There’s a 16-bit stack pointer, a program counter, and an 8-LED output latch called OB, which is the only way anything gets out of the machine besides the serial card.

Every instruction is a list of microcode rows in a 24-bit control word across three AT28C64Bs (U9, U15, U23). T0 is the fetch every instruction shares, then the rows run until one carries END. So a 2 T-state instruction is fetch plus one row.

ISA size: 174 opcodes, 82 free. The high nibble of the opcode is its family, which is why I can read a byte off the bus and know roughly what it is.

How to read a row

Hex is the opcode byte.
B is total length in bytes, operands included. Multi-byte operands are low byte first.
T is the T-state count including the fetch.
Flags: hold means the instruction doesn’t touch them. CZVN means all four update. ZN means it was a logic op: Z and N are valid, C is undefined because the ‘382 doesn’t specify carry out for logic functions and I’ve never scoped it. Don’t branch on C after AND, OR, XOR, CLR, SET or TST.
Notes call out clobbers B or clobbers C where a register you didn’t name gets overwritten, settle where one T-state is an idle pad, and unrun where the microcode is burned but the instruction has never executed on the hardware.

Flags update on any instruction that uses the ALU and hold across everything else. Loads, moves, stores and stack traffic don’t touch them. A Z set by AND still stands at a JNZ two instructions later.

The settle pads are on 23 instructions, added 2026-08-27 for a fault that turned out to be the ground return. Each one costs a T-state. Pulling them and re-running the soak is phase H work.

Addressing modes

Mode	Syntax	Count	How it works
Implied	`CLR`	85	Operands named by the opcode.
Immediate	`LDAI n`	25	One operand byte after the opcode.
Absolute	`LDA addr`	25	Two operand bytes, low first, loaded into MAR.
Indexed	`LDAX`	20	Address is B:C. C is the low half. No carry from C into B.
SP-relative	`LDAS`	13	Address is SP. Can’t share the stack with CALLs while doing this.
Memory-indirect	`LDAM ptr`	6	The pointer lives in memory. Operand names where the pointer is. Clobbers C, B survives.

Memory-indirect instructions are five bytes because the assembler emits the address twice, ptr and ptr+1. MAR loads only from the bus and has no increment, so the microcode reads the low byte through C, re-points MAR at the high byte, parks it in MDR and replays it.

Rules you find out the hard way

Set SP first. The ‘169 counters have no clear, so SP is random at power-up. LXISP before any push, pop, CALL or SP-relative access. Nothing warns you.
OB is never cleared. The output latch has no reset and holds whatever the last program left. Write a known-wrong value first (LDAI 0xFF; OUT) so a missing result shows up as missing instead of stale.
RET destroys C. C holds half the return address while RET rebuilds it. Wrap it in PUSHC/POPC if it has to survive a call.
One branch polarity. Every conditional is “taken if the flag is zero”. To branch on a flag being set, jump over a JMP. Six bytes.
Carry is NOT-borrow. SUB runs with carry-in set, so C=1 means A >= B unsigned and C=0 means A < B. JNC after CMP reads as “jump if less than”.
C is the low half of B:C. Always. A swapped pair is an off-by-256 that a write-then-read through the same pointer won’t show. Read the cell back by absolute address.

0x0x Control

Hex	Mnemonic	B	T	Operation	Flags	Notes
00	NOP	1	2	nothing	hold	0x00 is what blank RAM reads, so a PC that runs into it slides instead of stopping. First ran 2026-09-08.
01	RST	1	2	PC <- 0x0000	hold	unrun. Clears the PC and nothing else.

0x1x Immediate loads

Hex	Mnemonic	B	T	Operation	Flags	Notes
11	LDAI n	2	2	A <- n	hold
12	LDBI n	2	2	B <- n	hold	The 0xCx forms do LDBI plus ALU in one instruction.
13	LDCI n	2	2	C <- n	hold	Doesn’t survive a CALL.
14	LXISP addr	3	3	SP <- addr	hold	Required before any stack access.
15	LXIL n	2	2	SP low <- n	hold
16	LXIH n	2	2	SP high <- n	hold

0x2x Memory, absolute and SP-relative

A peripheral card is memory. The I/O window is 0x4000-0x7FFF in 2K slots, so LDA 0x4000 reads the DIP switch.

Hex	Mnemonic	B	T	Operation	Flags	Notes
21	LDA addr	3	4	A <- [addr]	hold
22	STA addr	3	4	[addr] <- A	hold
23	LDB addr	3	4	B <- [addr]	hold
24	LDC addr	3	4	C <- [addr]	hold
25	STB addr	3	4	[addr] <- B	hold
26	STC addr	3	4	[addr] <- C	hold
27	LDAS	1	4	A <- [SP]	hold	Read a stack slot without popping.
28	STAS	1	4	[SP] <- A	hold
29	LDBS	1	4	B <- [SP]	hold
2A	STBS	1	4	[SP] <- B	hold
2B	LDCS	1	4	C <- [SP]	hold
2C	STCS	1	4	[SP] <- C	hold

0x3x Flow

Hex	Mnemonic	B	T	Operation	Flags	Notes
31	JMP addr	3	4	PC <- addr	hold
32	JNZ addr	3	4	jump if Z = 0	hold
33	CALL addr	3	12	push return, PC <- addr	hold	Pushes PC+1, the address of its own operand bytes. RET steps over them.
34	RET	1	14	pop PC, step over 2 bytes	hold	clobbers C.
35	JMPX	1	4	PC <- B:C	hold	Computed jump.
36	JMPSP	1	4	PC <- SP	hold
37	JNC addr	3	4	jump if C = 0	hold	After CMP: jump if A < B unsigned.
38	JZX	1	4	jump to B:C if Z = 0	hold
39	JCX	1	4	jump to B:C if C = 0	hold
3A	JMPM ptr	5	10	PC <- [ptr]	hold	clobbers C. Vector table in RAM.
3B	JZM ptr	5	10	jump via [ptr] if Z = 0	hold	clobbers C.
3C	JCM ptr	5	10	jump via [ptr] if C = 0	hold	clobbers C.
3D	LDAM ptr	5	10	A <- [[ptr]]	hold	clobbers C.
3E	LDBM ptr	5	10	B <- [[ptr]]	hold	clobbers C.
3F	STAM ptr	5	10	[[ptr]] <- A	hold	clobbers C.

0x4x ALU

Two 74F382s with ripple carry. A and B feed the ALU from shadow latches that reload on every A or B load, so you never load them yourself. SHL, INR, DCR and NOT get to the ALU by staging a constant in B, so all four destroy it.

Hex	Mnemonic	B	T	Operation	Flags	Notes
40	BIT	1	2	A AND B, discarded	ZN	Mask test.
41	ADD	1	2	A <- A + B	CZVN
42	SUB	1	2	A <- A - B	CZVN
43	AND	1	2	A <- A AND B	ZN
44	OR	1	2	A <- A OR B	ZN
45	XOR	1	2	A <- A XOR B	ZN
46	CLR	1	2	A <- 0x00	ZN	One byte, shorter than LDAI 0.
47	SET	1	2	A <- 0xFF	ZN
48	BSUB	1	2	A <- B - A	CZVN
49	CMP	1	2	A - B, discarded	CZVN	Flags update even with no destination.
4A	CMPB	1	2	B - A, discarded	CZVN
4B	TST	1	2	A OR A, discarded	ZN	Zero test on A alone.
4C	SHL	1	4	A <- A + A	CZVN	settle, clobbers B.
4D	INR	1	4	A <- A + 1	CZVN	settle, clobbers B. B staged with 0xFF, A - 0xFF.
4E	DCR	1	4	A <- A - 1	CZVN	settle, clobbers B. A + 0xFF.
4F	NOT	1	4	A <- NOT A	ZN	settle, clobbers B. A XOR 0xFF.

0x5x Output

OB latches whatever is on the internal bus. Sourcing it from A was a microcode convention, so anything that can drive the bus can go to the display. Every variant except OUT and OUTI is unrun: the self-test reads OB, so it can’t judge an instruction whose only effect is writing OB.

Hex	Mnemonic	B	T	Operation	Flags	Notes
51	OUT	1	2	OB <- A	hold
52	OUTB	1	2	OB <- B	hold	unrun
53	OUTC	1	2	OB <- C	hold	unrun
54	OUTSPL	1	2	OB <- SP low	hold	unrun
55	OUTSPH	1	2	OB <- SP high	hold	unrun
56	OUTPCL	1	2	OB <- PC low	hold	unrun
57	OUTPCH	1	2	OB <- PC high	hold	unrun
58	OUTI n	2	2	OB <- n	hold
59	OUTM addr	3	4	OB <- [addr]	hold	unrun
5A	OUTMX	1	4	OB <- [B:C]	hold	unrun
5B	OUTMS	1	4	OB <- [SP]	hold	unrun

0x6x Stack and pointers

Empty-descending. SP points at the next free slot. Push stores then decrements, pop increments then loads. Every stack access copies SP into MAR first, which is where the extra two T-states go.

Hex	Mnemonic	B	T	Operation	Flags	Notes
60	PUSHPCH	1	5	push PC high	hold	unrun
61	PUSHA	1	5	[SP] <- A, SP–	hold
62	POPA	1	5	SP++, A <- [SP]	hold
63	PUSHB	1	5	[SP] <- B, SP–	hold
64	POPB	1	5	SP++, B <- [SP]	hold
65	PUSHC	1	5	[SP] <- C, SP–	hold
66	POPC	1	5	SP++, C <- [SP]	hold
67	INXSP	1	2	SP <- SP + 1	hold	The only 16-bit increment in the machine.
68	DCXSP	1	2	SP <- SP - 1	hold
69	SPHL	1	3	SP <- B:C	hold
6A	HLSP	1	3	B:C <- SP	hold
6B	PUSHSPL	1	5	push SP low	hold
6C	POPSPL	1	5	pop SP low	hold
6D	PUSHSPH	1	5	push SP high	hold
6E	POPSPH	1	5	pop SP high	hold
6F	PUSHPCL	1	5	push PC low	hold

0x7x Indexed through B:C

Hex	Mnemonic	B	T	Operation	Flags	Notes
71	LDAX	1	4	A <- [B:C]	hold
72	STAX	1	4	[B:C] <- A	hold
73	LDBX	1	4	B <- [B:C]	hold	Overwrites the pointer’s high half.
74	STBX	1	4	[B:C] <- B	hold
75	LDCX	1	4	C <- [B:C]	hold	Overwrites the pointer’s low half. Linked-list walk.
76	STCX	1	4	[B:C] <- C	hold
77	MVIX n	2	6	[B:C] <- n	hold	Fill through the pointer without touching A.
78	STADDX	1	4	[B:C] <- A + B	CZVN
79	STSUBX	1	4	[B:C] <- A - B	CZVN
7A	STBSUBX	1	4	[B:C] <- B - A	CZVN
7B	STANDX	1	4	[B:C] <- A AND B	ZN
7C	STORX	1	4	[B:C] <- A OR B	ZN
7D	STXORX	1	4	[B:C] <- A XOR B	ZN

0x8x Register and pointer moves

One row past the fetch. Cheapest instructions in the machine.

Hex	Mnemonic	B	T	Operation	Flags	Notes
81	MOVAB	1	2	A <- B	hold
82	MOVAC	1	2	A <- C	hold	C can’t be an ALU operand, so this is how C reaches the ALU.
83	MOVBA	1	2	B <- A	hold
84	MOVBC	1	2	B <- C	hold
85	MOVCA	1	2	C <- A	hold
86	MOVCB	1	2	C <- B	hold
87	MOVASPL	1	2	A <- SP low	hold
88	MOVASPH	1	2	A <- SP high	hold
89	MOVSPLA	1	2	SP low <- A	hold
8A	MOVSPHA	1	2	SP high <- A	hold
8B	MOVAPCL	1	2	A <- PC low	hold	Tapped at the counters’ Q outputs.
8C	MOVAPCH	1	2	A <- PC high	hold	unrun

0x9x Reserved

Held empty for opcodes that need hardware the machine doesn’t have yet: SHR, MOV A,FLAGS, ADC, SBB, and the branch families that need CW22/CW23 landed.

0xAx Pointer save and restore, immediate stores, computed output

Hex	Mnemonic	B	T	Operation	Flags	Notes
A0	LDSPL addr	3	4	SP low <- [addr]	hold
A1	LDSPH addr	3	4	SP high <- [addr]	hold
A2	STSPL addr	3	4	[addr] <- SP low	hold
A3	STSPH addr	3	4	[addr] <- SP high	hold
A4	STPCL addr	3	4	[addr] <- PC low	hold	unrun
A5	STPCH addr	3	4	[addr] <- PC high	hold	unrun
A6	MVI addr, n	4	6	[addr] <- n	hold	Got a settle row on 2026-09-05 after PROG_test5 caught it writing a mix of the old byte and the new one.
A7	MVIS n	2	6	[SP] <- n	hold
A8	OUTADD	1	2	OB <- A + B	CZVN	unrun
A9	OUTSUB	1	2	OB <- A - B	CZVN	unrun
AA	OUTBSUB	1	2	OB <- B - A	CZVN	unrun
AB	OUTAND	1	2	OB <- A AND B	ZN	unrun
AC	OUTOR	1	2	OB <- A OR B	ZN	unrun
AD	OUTXOR	1	2	OB <- A XOR B	ZN	unrun

0xBx B and C to and from the pointers

With the ALU these let a routine do arithmetic on SP, or borrow SP as a second index register and hand it back.

Hex	Mnemonic	B	T	Operation	Flags	Notes
B0	MOVBSPL	1	2	B <- SP low	hold
B1	MOVBSPH	1	2	B <- SP high	hold
B2	MOVCSPL	1	2	C <- SP low	hold
B3	MOVCSPH	1	2	C <- SP high	hold
B4	MOVSPLB	1	2	SP low <- B	hold
B5	MOVSPHB	1	2	SP high <- B	hold
B6	MOVSPLC	1	2	SP low <- C	hold
B7	MOVSPHC	1	2	SP high <- C	hold
B8	MOVBPCL	1	2	B <- PC low	hold
B9	MOVBPCH	1	2	B <- PC high	hold	unrun
BA	MOVCPCL	1	2	C <- PC low	hold
BB	MOVCPCH	1	2	C <- PC high	hold	unrun

0xCx ALU with an immediate

Two bytes where LDBI plus the ALU op costs three. The constant comes in through B, so every one of these overwrites B unless B is the destination. Every row here carries a settle pad, which is why they’re 4 T-states and not 3.

Hex	Mnemonic	B	T	Operation	Flags	Notes
C0	ADI n	2	4	A <- A + n	CZVN	settle, clobbers B
C1	ADI_B n	2	4	B <- A + n	CZVN	settle
C2	ADI_C n	2	4	C <- A + n	CZVN	settle, clobbers B
C3	SUI n	2	4	A <- A - n	CZVN	settle, clobbers B
C4	SUI_B n	2	4	B <- A - n	CZVN	settle
C5	SUI_C n	2	4	C <- A - n	CZVN	settle, clobbers B
C6	BSUI n	2	4	A <- n - A	CZVN	settle, clobbers B
C7	BSUI_B n	2	4	B <- n - A	CZVN	settle
C8	BSUI_C n	2	4	C <- n - A	CZVN	settle, clobbers B
C9	ANI n	2	4	A <- A AND n	ZN	settle, clobbers B
CA	ANI_B n	2	4	B <- A AND n	ZN	settle
CB	ANI_C n	2	4	C <- A AND n	ZN	settle, clobbers B
CC	ORI n	2	4	A <- A OR n	ZN	settle, clobbers B
CD	ORI_B n	2	4	B <- A OR n	ZN	settle
CE	ORI_C n	2	4	C <- A OR n	ZN	settle, clobbers B
CF	XRI n	2	4	A <- A XOR n	ZN	settle, clobbers B

0xDx Immediate ALU continued, and results into B or C

Where the result lands decides what survives. Into B, it becomes the next op’s second operand. Into C, neither operand is touched.

Hex	Mnemonic	B	T	Operation	Flags	Notes
D0	XRI_B n	2	4	B <- A XOR n	ZN	settle
D1	XRI_C n	2	4	C <- A XOR n	ZN	settle, clobbers B
D2	CPI n	2	4	A - n, discarded	CZVN	settle, clobbers B. `CPI n; JNC` is compare-and-branch in four bytes.
D3	ADD_B	1	2	B <- A + B	CZVN
D4	ADD_C	1	2	C <- A + B	CZVN
D5	SUB_B	1	2	B <- A - B	CZVN
D6	SUB_C	1	2	C <- A - B	CZVN
D7	BSUB_B	1	2	B <- B - A	CZVN
D8	BSUB_C	1	2	C <- B - A	CZVN
D9	AND_B	1	2	B <- A AND B	ZN
DA	AND_C	1	2	C <- A AND B	ZN
DB	OR_B	1	2	B <- A OR B	ZN
DC	OR_C	1	2	C <- A OR B	ZN
DD	XOR_B	1	2	B <- A XOR B	ZN
DE	XOR_C	1	2	C <- A XOR B	ZN
DF	CPX	1	2	A XOR B, discarded	ZN	Equality test, both operands intact.

0xEx Compute and store

A MAR load and an ALU row that writes RAM. The result never sits in a register.

Hex	Mnemonic	B	T	Operation	Flags
E0	STADD addr	3	4	[addr] <- A + B	CZVN
E1	STSUB addr	3	4	[addr] <- A - B	CZVN
E2	STBSUB addr	3	4	[addr] <- B - A	CZVN
E3	STAND addr	3	4	[addr] <- A AND B	ZN
E4	STOR addr	3	4	[addr] <- A OR B	ZN
E5	STXOR addr	3	4	[addr] <- A XOR B	ZN
E6	STADDS	1	4	[SP] <- A + B	CZVN
E7	STSUBS	1	4	[SP] <- A - B	CZVN
E8	STBSUBS	1	4	[SP] <- B - A	CZVN
E9	STANDS	1	4	[SP] <- A AND B	ZN
EA	STORS	1	4	[SP] <- A OR B	ZN
EB	STXORS	1	4	[SP] <- A XOR B	ZN

0xFx Halt

Hex	Mnemonic	B	T	Operation	Flags	Notes
FF	HALT	1	2	T-counter stops	hold	0xFF so an erased EEPROM halts instead of running. Same byte fills unused microcode slots and parks the bus.

Opcode map

256 slots. 174 assigned, 16 reserved (family 9), 66 free. Free slots are the gaps you can see in the tables above: 0x02-0x10, 0x17-0x20, 0x2D-0x30, 0x50, 0x5C-0x5F, 0x70, 0x7E-0x80, 0x8D-0x9F, 0xAE-0xAF, 0xBC-0xBF, 0xEC-0xFE.

What has actually run

The tables describe what’s burned. What has been witnessed on the hardware is a narrower claim.

Burned images in the repo: U9 0xC52B, U15 0xDCD1, U23 0xCB8E, CRC-16 pinned in the host tests so a reburn is deliberate. The U15 in the socket is 0x45F9, which adds an OUT settle row from 2026-09-08 that fixed nothing and comes back out on the next burn.
PROG_isa runs 147 subtests, one per instruction it can observe through OB, and reads 0xB4 at 1.024 MHz. PROG_isasoak repeats them 64 times per run and read 0x00 on 50 runs in a row, 470,400 subtest executions.
RET, OUT, OUTI and HALT have no subtest because the harness is built from them. Every coverage image since phase C runs all four. NOP first ran on 2026-09-08 in the OUT-before-RET chase. That’s 152 instructions witnessed.
22 have never executed: RST, MOVAPCH, MOVBPCH, MOVCPCH, PUSHPCH, STPCL, STPCH, and the fifteen OUT variants (OUTB, OUTC, OUTSPL, OUTSPH, OUTPCL, OUTPCH, OUTM, OUTMX, OUTMS, OUTADD, OUTSUB, OUTBSUB, OUTAND, OUTOR, OUTXOR). The OUT ones can’t be self-tested because their only effect is the display. The rest just don’t have an image yet.

Phase H: pull the 23 settle pads and the OUT settle row, reburn U9 and U15, rerun PROG_isasoak. If it stays at 0x00 the pads were never needed.
Scope the ‘382 carry out after a logic op so the ZN rows can say what C actually does.
Decide which of the fifteen OUT variants earn their slot. Something has to watch the LEDs to test them, so probably a camera or a second latch on the bus.

Cursors, measurements, and the write that flips the scope into Track

Thu, 10 Sep 2026 00:00:00 +0000

What I tried

v0.4 turns on the Cursors and Measure keys. Both cards follow the same rule as the rest of the panel: the app shows what the scope reports, and a click sends a request and waits for the next poll to confirm it.

Cursors card: Mode Off/Manual/Track, Type X/Y/X-Y, and four knobs named like the scope’s own, X1 X2 Y1 Y2. The plot draws the cursors as dashed lines in the source channel’s colour and you can drag them. The readout chip in the corner is the scope’s own CRVA? numbers (dX, 1/dX, X1, X2, and the Y trio), nothing computed on my side. The cursor source follows whichever channel is selected, because the scope has no query for it; the trace prefix on the CRST write is what sets it.

Measure card: the scope’s five custom slots, read every cycle with PAVA? CUSTn (or STATn when statistics are on, which also gives mean/min/max/std/count). An Add button opens a picker with the 28 single-channel parameters and the 10 delay types (MEAD, channel pair). The live values also sit as a row of pills along the bottom of the plot.

The scheduler got a fourth work kind, Measure, after the poll slice. Cursor positions are hot fields only while cursors are on.

What I measured

One SCPI query is about 2.5 ms. The measure step costs 7 queries in the common case and 12 in the worst (statistics on, empty slots), so 20 to 30 ms per cycle.
CRST HREF reads back in seconds and CRST VREF in volts, both absolute. A V write reads back as written minus 2 times the channel offset, checked at 0, 2 and 5 V. The app writes V + 2·ofst and the line lands where the scope’s screen shows it.
CRVA? HREL comes back as delta, 1/delta, X2, X1, in that order, with unit suffixes glued to the numbers.
Live view in the captures ran 4.5 fps at 180 queries/s with two channels on, 7 Mpt memory, and five slots installed.
--selftest gained a cursor step: X1 round trip within 1% of a division, Y1 round trip through the 2·ofst correction, and a CRTY X-Y round trip. Still ends SELFTEST OK.

What broke or surprised me

PACL does nothing on this firmware. There is no SCPI way to remove a measurement. The slot list is a FIFO: a sixth PACU drops slot 1 and shifts the rest up. The card says so and leaves an Add button on slot 5.
Any CRST HREF or HDIF write puts the scope into Track mode. Any VREF or VDIF write sets the type to Y. Reads never change anything. I lost most of an afternoon on this: the scope kept ending up in Track after a live session and I blamed Auto Setup, a stale USB handle, then the scope’s own menu state, because my probes only ever wrote CRTY and VREF. The bisect that found it replayed the app’s traffic group by group and checked CRMS? after each. The fix is two extra commands after every position write in Manual, CRMS MANUAL and CRTY <type>, coalesced by the scheduler so a knob drag doesn’t multiply them.
The scope has a third cursor type, X-Y, all four cursors at once. CRTY? returns X-Y; CRTY XY is ignored. I’d built the card with two knobs before Rico pointed at the scope’s own menu.
Chaining commands with ; doesn’t work. The second command garbles the first one’s value.
QStringLiteral("Add\xE2\x80\xA6") renders as Addâ€¦. Escaped UTF-8 bytes need QString::fromUtf8.
Y cursors at the same volts as the trace’s low level are invisible: same colour, drawn on top. A dark halo under the dashed line is on the list.
My scope MCP server holds the USB interface while it’s loaded, so the app fails with “claim interface 0 failed”. Only one process gets the scope.

Halo under the cursor lines so they survive sitting on a trace.
Manual acceptance checklist for v0.4 is written but unticked; measurement values only got eyeballed live, not recorded.
Deep capture export, Linux build, the rest of the menu keys.

v0.4 headless capture: Manual X-Y cursors on CH1, readout chip from CRVA?, five measurement pills under the plot.

Later the same day

The app has a name now, SigScope, and a public repo: github.com/robertrico/sigscope. Rico picked the name after I offered a few. The bundle is SigScope.app; the internal namespace stayed osc. The README got the two v0.4 captures, a platforms table (macOS tested, Linux untested, Windows out), and a paragraph on the firmware quirks the app works around.

CI runs for the first time, and the wrapper had drifted off the core

Thu, 10 Sep 2026 00:00:00 +0000

I sat down to write this project up for the site and read my own last commit. It said D and W over the LAN were returning 0x44. I remembered it working. Turned out I’d done the fix on the other machine and never pushed, so I pulled six commits from 2026-08-09 and one of them was a verification workflow that had never run. Pushing it ran it. Red.

First failure was mine. The core repo’s FuseSoC generator finds GHDL through a GHDL environment variable and falls back to ~/oss-cad-suite/bin/ghdl. My Makefile set that variable and never exported it, so it only ever worked on machines where the fallback path existed. One export GHDL line.

Second failure was the real one. make convert builds the netlist from the core repo at HEAD, and the core repo moved on 2026-08-08. Commit c05c7c7 purged the EXTERNAL_RAM generic, the ram_ext_* bus and the 3-bit int_vector from b8008_top. My wrapper still declared all three. Nine port errors. It had worked locally for a month because the netlist on disk was built in August and nothing regenerated it.

I went down a hole first. The bring-up commit says the DHCP lease needed liteeth at master 276c9e3, and this machine had it at the 2026.04 tag, so I tried pinning it forward. liteeth 28b4493 from June uses litex master’s new CSR aliases, CSR.wr_stb, which litex 2026.04 doesn’t have. Elaboration dies in the MAC SRAM. Back to the tag. There’s a make liteeth-pin LITEETH_REV=… knob now for a bench session, and make litex-env never moves a checkout on its own.

Then I pinned CI to the last core commit that still had the old ports, 70c7498, and cancelled the run when I realized that was freezing the wrapper on an August core. The core’s fine. The wrapper needed to follow it.

The change is smaller than it sounds. EXTERNAL_RAM=false already instantiated ram_sync inside b8008_top. The external mode just routed the same latched_address, data, rw_n and cs_n out to the bus, where my Migen side fed a 16 KB Memory. ram_sync.vhdl and address_decoder.vhdl are byte-identical across the purge. The old jam byte was "00" & int_vector & "101" with vector 000, which is 0x05. The new int_instruction default is 00000101, also 0x05. ROM interface untouched. So the wrapper drops its ram_* ports and the vector latch, the Migen side drops its RAM, and both boot testbenches drop their RAM models. The Verilator bench was also still wiring ctl_* and sts_* ports I’d deleted in August. S-CORE-3 got a dated amendment re-freezing the port list.

Convert now stamps the netlist with core 342f8cd. The GHDL sim prints the banner through “8008 Mon”, the Verilator sim through “8008 “, and make test is green, 4 C binaries, 105 host and 48 SoC tests.

Then three more red runs, all one bug. On the runner, litex_setup.py clones the vendored trees under .venv/. On this Mac they’re at the repo root from July. liteeth-pin, the C test include path and the fork-drift test all assumed root. They accept either now.

Run 34549971806 went green at 2026-09-11 01:21 UTC. Five and a half minutes end to end on a fresh runner, of which the seven SoC elaborations take three. Convert takes 4 s. That’s the first green run this repo has had, and every failure on the way was something that only shows up on a machine that isn’t mine.

What I have not done is put this on the board. The logic is the same but the 16 KB RAM used to be a Migen Memory and is now inferred by yosys from the GHDL netlist. That’s a different path to block RAM. make check-synth counts DP16KD for exactly this reason, and the core repo’s own monitor build infers this same ram_sync fine, but a green test suite is not a working machine. Next is a bitstream, make selftest, and D and W by hand.

Why this site exists

Wed, 09 Sep 2026 00:00:00 +0000

Hardware projects generate notes: measurements, dead ends, part numbers, photos of a scope screen. Most of that ends up scattered across a lab notebook, a chat history, and a README nobody updates. This site is the fix. Every project gets one overview page, and every working session that produces something worth keeping becomes a dated log entry under it.

A few rules keep it cheap to maintain:

Static HTML built by Hugo, hosted on S3 behind CloudFront. No server, no database, nothing to patch.
No JavaScript, no external fonts, no analytics. The page you see is the page that was written.
Publishing is a git push. A GitHub Actions workflow builds the site and syncs it to the bucket.
A build log belongs to exactly one project. Logs get corrected in place when I learn better; git keeps the history.

This entry is the one exception: it belongs to the site itself, not to a project. Everything after it is project work.

Projects currently listed: Byte Hamr, an ECP5-85K FPGA peripheral card for the Apple IIe, plus several others that are still stubs. The projects page shows current status for each.

Talking to the SDS1204X-E over USB from a Mac

Wed, 09 Sep 2026 00:00:00 +0000

Siglent doesn’t ship a Mac app for the SDS1204X-E and the Windows one isn’t much anyway. The scope has a USB device port that enumerates as USBTMC, so I wanted to see how far libusb alone would get me before committing to a real app.

What I tried

Plugged it in. macOS has no USBTMC driver, which turns out to be the good case: nothing grabs the interface, libusb claims it from user space, no kext. VID 0xF4EC, PID 0xEE38.

First attempt with python-usbtmc died on the first control transfer. pyvisa-py got *IDN? back. Then I wrote my own 80-line USBTMC framing in pyusb because pyvisa-py kept hanging on waveform reads, and that harness became the reference for the C++ transport later.

The command set is the old LeCroy-style short form, not the :TIMebase:SCALe tree. C1:VDIV 1.3V, TDIV 50NS, TRSE EDGE,SR,C1,HT,OFF. CHDR OFF first or every reply comes back with a header and units glued on.

What I measured

2.5 ms per short query, median. 70 queries in 0.3 s.
7 000 point waveform fetch: 81 ms. That’s 12 fps if you do nothing else.
Full 7 M point record: 15.4 s. USB on this scope is full speed, 12 Mbit, about 500 KB/s real.
WFSU SP,5000,NP,1400 gives 1 400 points spread across the whole 7 M record in 0.3 to 0.5 s. Sparsing only works if NP is also set, otherwise it’s ignored and you get the whole thing.
PNSU? returns the entire panel setup as 88 KB of XML. Takes 12.8 s every time, so it’s a connect-time thing only.
SCDP screenshot: 768 067 byte BMP in 1.3 s.
60 s stress of 20 queries plus 2 waveforms per round: 377 rounds, zero failures.

The volts formula checked out against the scope’s own measurement to the last digit: code × VDIV / 25 − OFST, 25 codes per division. Rising edge landed on sample 3500 of 7000, so the trigger point is dead center.

What broke or surprised me

Bare SANU? hangs the link. SANU? C1 is fine. It’s on a denylist now.
The scope rejects USBTMC INITIATE_CLEAR and INITIATE_ABORT, which is what most libraries send when a read times out. That’s why they hang. Recovery is a USB port reset plus draining whatever is still in the pipe, about 1.5 s.
It pads bulk-in transfers and sometimes ends them early. You read until the header’s byte count is satisfied and ignore the packet boundaries.
MSIZ silently ignores 14K/140K/1.4M/14M when three or four channels are on. Only the 7K series is valid then.
If you kill the app mid-transfer, the scope keeps streaming the rest of the record at the next program that opens it. My first C++ reader treated an all-zero header as “more coming” and looped forever. The Python harness never validated tags so it never noticed. Fixed with tag checking, a deadline on every read, and a drain on open.

The app shell works: live 4-channel plot, run/stop/single/force, edge trigger panel, V/div and time/div, screenshot to the Desktop with Ctrl+S, and it follows the scope’s physical knobs within about a second by polling. It looks like a Qt example though. Next is making it look and work like the actual front panel.

The scope’s own screen, pulled over USB with SCDP. 768 KB BMP in 1.3 s.

Front panel, scope-style trigger, and persistence

Wed, 09 Sep 2026 00:00:00 +0000

What I tried

The first version worked but I couldn’t find Single, everything was a combo box, and turning a knob on the scope took over a second to show up. So version two copies the front panel. Four channel columns with a volts/div knob and an offset knob each, lit AC/DC/BW/INV buttons, a time/div knob, trigger source and slope as button rows, and a big Run/Stop. The trigger now works the scope’s way: pick Auto, Normal or Single, then press Run/Stop to go. Single re-arms a running scope instead of stopping it, which took one review to catch.

The knobs are painted with QPainter, 20 detents over 300 degrees, a colored arc showing where you are in the 1-2-5 ladder. Mouse wheel is one detent, vertical drag is 12 px per detent.

Auto Setup used to drag the whole link into recovery, so it moved into a Utility menu and now pauses the live feed, waits for the scope to answer again, does one full poll, and resumes. There’s a Pause/Live button for the same reason.

Then persistence. A Display card with Off, 1s, 5s, 10s, 30s and infinite. It sends the scope’s own PESU command so the scope screen matches, and the app keeps an accumulation image per channel, stamps each new sweep at low alpha, and multiplies the alpha down every frame for the timed modes. Live trace is drawn on top at full brightness. Then an intensity row because the persisted band was as bright as the live trace and you couldn’t tell them apart.

The front-panel layout connected to the scope, square wave on CH1 at 50 µs/div, 8.3 fps.

Infinite persistence with the trigger free-running. Every past sweep stays as the yellow band, the live sweep on top.

What I measured

Full state poll: 276 ms before, 163 ms after moving the hot fields (scales, offsets, trigger level, run state) into every poll slice.
Knob on the scope to panel in the app: about 0.2 s now, was about 1.2 s.
Live round of 18 hot queries plus one 1400-point waveform: 8.8 rounds/s, p50 114 ms.
Deep memory no longer matters for the live view: 14 Mpt at 1400 decimated points fetches in 352 ms.
Auto Setup settles in about 4 s.
Persistence stamp alpha 0.15 per sweep, so full brightness after about 30 overlapping sweeps. Layers are about 3.5 MB each at a 1440-wide window.

What broke or surprised me

After ASET the scope is silent for about 3 s. The first SAST? times out at 2 s and its reply arrives late. My transport checks the USBTMC tag on every reply, so that late reply made every following read fail, 22 errors in a row until the 8 s budget ran out. The Python harness, which doesn’t check tags, never saw it. Fix was to drain stale output inside the settle loop after any error.
8-bit premultiplied alpha never reaches zero when you multiply it down by a factor near 1. Pixels get stuck at alpha 4. The fade pass now zeroes anything under 8 every eighth frame.
A negative frame delta (clock jitter) would have made the fade factor exceed 1, produced an invalid QColor, and wiped the whole layer. Caught in review before it hit hardware.
A stably triggered square wave shows no persistence at all, every sweep lands on the last one. Same on the real scope. You have to let the trigger free-run to see the smear.
Screenshot to the desktop with Ctrl+S still works, and the scope’s own dense persistence comes through that path.

Cursors and measurements. Both menu keys are already on the panel, disabled. The SCPI for them is documented and I’ve already read PAVA? values off the scope in the first day’s spikes.

OUT before a RAM fetch halts; the breadboard is done

Tue, 08 Sep 2026 00:00:00 +0000

What I tried

RAM programs were stopping. life.asm printed row 0, OB read 0x01, and the machine froze with no response to keys. bigxfer at 2233 bytes has gone in and streamed itself back clean several times, sometimes back to back, and then a table bump or a wire out of line stops it (one run: monitor sum 0x69 against host 0x29, OB 0xC2, monitor unresponsive). Every earlier RAM program had done five firsts at once, so I wrote a staircase, asm/ram/step1..8, one first per step, with the Python oracle as the answer key.

step2 is LDAI 0x22; OUT; RET. It OUTs 0x22 and freezes. Fetch, OUT, HALT, RET and CALL from RAM all work on their own; only OUT immediately before another instruction fetched from RAM halts. Data-independent: four OUT values all froze, and OUT of 0x34 with REG_A already 0x34, no bus transition, still froze. One instruction between them cures it (step2a). One NOP cures it (step2g, OB 0x22, prompt back). That was NOP’s first execution on silicon.

First model: OUT was one row driving MDR from REG_A and strobing the output latch in the same T-state that carried END, so the next fetch began before the bus released. Fix: a SETTLE row that drives nothing before END. Reburned U15, CRC 0xDCD1 to 0x45F9, one chip.

What I measured

With the settle row burned, step2 still halts, OB 0x22. The settle fixed nothing.
step2 halts at 1.024 MHz and above, returns at 500 kHz.
Half-window 488 ns fails, 1000 ns passes, so the real first-fetch-after-OUT settle is somewhere in 488 ns to 1000 ns.
Datasheet budget to IR is 382 ns worst case and closes at 488 ns. The missing 100 ns to 600 ns is not in the datasheet path.
Machine draw on the bench supply ammeter: 1.25 A to 1.34 A at 5 V.

What broke or surprised me

Idle T-states between OUT and the RET fetch do nothing; only a real intervening fetch cures it. So the bottleneck is the RET fetch’s own single T-state, whose setup deadline is the clock edge, and states before it cannot lengthen it. The extra delay is breadboard bus capacitance (100+ pF against the 45 pF a 74LS245 tPD is specced into) plus the REG_A to RAM buffer cross-driver handoff that only an OUT-then-fetch sees. A fetch after a fetch is the same buffer both times, no contention. A driving settle does not help either: OUT cannot know whether the next fetch is ROM or RAM, and a RAM-driving last row makes the ROM case a bus fight.

An earlier note had predicted slower is worse from a transparent-IR-dwell model. The bench said slower is better. That model is retracted, and so is the settle row: it costs a T-state and should be reverted on the next burn.

Zero-burn workaround: never put OUT immediately before RET in RAM code.

Stepping back: every error since the ISA went green has been noise. Ground offsets, a ringing clock stub, a wrong capacitor, a reset wire in the wrong bundle, bus capacitance, and now a transfer that a bump can stop. None of it has been the logic.

The breadboard is at the end of what it can do. Decision: one 2-layer mainboard, the phase E slots as its only connectors, and power designed first. Wrote POWER.md with the record of every power or ground fault chased as logic since 2026-08-24, eight entries, the supply options (old ATX on hand, PicoPSU, plain 5 V brick) and the bench checks that pick between them. Which supply is an open item I have not dug into.

Monitor loads hex over serial, and RAM is proven whole

Mon, 07 Sep 2026 00:00:00 +0000

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 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.

LEDs on a RAM byte, DIPs unplugged, and a make target for the console

Thu, 03 Sep 2026 00:00:00 +0000

What I tried

b8008_top gains a LED_SHADOW_ADDR generic and a ram_byte_led output, a shadow of one RAM byte the same way the boot vector shadows byte 0. Both board tops put it on LEDs 7 to 1, bit n to LED n, 1 is on. LED0 (D25) stays the CPU-running light. In the monitor build the byte is 0x3FFF, so W 3FFF,FE lights all seven. In the BASIC build it’s 0x00FF, reached with MON, then W 00FF,FE, then G 1FB6. Port 8 is still latched by the core and no longer shown.

A cylon_ram sample sweeps the seven LEDs through the byte, G 2100, any key exits.

What broke

The DIP bank. On this board ON reads as 0. With the old wiring, my all-OFF bank selected the fetch-capture LED mode, and any flip of switch 6 or 7 halted the CPU through the READY hold or the interrupt input. So sw(1) through sw(7) are no-connects in both tops now: no capture modes, no switch interrupts, READY tied high, post-bootstrap break off. Only DIP 1, reset, remains.

What I measured

Two new regressions: monitor_led_tb at 900 ms of simulated time, and basic_led_tb at 2.1 s covering a full boot, MON, W, G 1FB6 and LIST. Timing reports refreshed.

The serial side: make monitor opens minicom, make kill-monitor closes it, and make send-hex HEX=name resolves against the samples directory. kill-monitor waits for minicom to finish its hangup and then settles 2 s before the port is reopened. At 0.5 s the first bytes of a send came through corrupted. Validated on the board.

No plan for the core. This is the state the Byte Hamr card’s 8008 and the Apple II toolchain build on.

Both machines booting

Sat, 29 Aug 2026 00:00:00 +0000

What I tried

The other good ST-251 into the 5160 on its own controller card. Different card from the 5271’s, so a different format, but the same process through DEBUG. FDISK, FORMAT, DOS 5.

What I measured

Both machines boot from A: and from C:. On the 5271 I loaded DOS and typed around with the Inboard in. If the Inboard didn’t work, the machine wouldn’t.

What broke or surprised me

Nothing.

The Inboard’s DOS utility. The alignment tool. Eventually the 3270 side.

Dynamic mode format

Sun, 23 Aug 2026 00:00:00 +0000

What I tried

A known-good ST-251 this time. Back into G=C800:5, dynamic configuration, 820 6 821 821 11 7. That’s 820 cylinders, 6 heads, reduced write current and precomp starting at cylinder 821, 11-bit error burst, step rate select 7. Interleave 5 first, then reformatted at 3. Then FDISK, then FORMAT C: /S, then DOS 5. All with the Inboard 386 in.

What I measured

FDISK showed the full drive. DOS 5 installed and the 5271 boots from C:.

What broke or surprised me

Nothing this time.

Same on the 5160.

Tandon alignment

Sat, 22 Aug 2026 00:00:00 +0000

What I tried

Swapped the two full-height Tandons between machines until the problem followed one drive. Then followed the classic-computers.org.nz TM100 procedure: scope on the analog test points on the drive’s logic board, head parked on a track and reading continuously, adjust the head cam.

To park the head I wrote a small program in DEBUG with a 100 that seeks to a track and reads it in a loop. I made the track number a variable so I could move between tracks without leaving the session.

What I measured

Signal amplitude at the test points on the Siglent, on the tracks the procedure calls for. The numbers came out near what the website says they should be.

What broke or surprised me

The DEBUG loop only tells me the head is reading. It can’t tell me which track is actually under the head. I wrote a spec for a proper DOS tool that uses the FDC Read ID command for that and sweeps every track for read reliability.

The aligned drive reads and writes disks from the other drive and from OEM disks. Now the hard drives.

Floppy controller tantalum

Sun, 16 Aug 2026 00:00:00 +0000

What I tried

In the morning the floppy read fine. By afternoon DIR worked sometimes. By evening freshly formatted disks wouldn’t boot. By night the machine went straight to Cassette BASIC with no non-system disk message, meaning the BIOS never read sector one.

I chased the drive: head contamination, belt, spindle speed, alignment, a capstan on the stepper shaft that looked like it might have slipped. I also found one disk that had been sitting on a MacBook lid and was partly erased by the magnets, which muddied things further.

Then I pulled the floppy controller card and put the meter across the +5 V edge pins.

What I measured

Continuity across +5 V and ground on the controller. I didn’t want to desolder every cap to measure them, so I found the shorted tantalum with continuity checks on the board, replaced it, and the floppy read again.

What broke or surprised me

A tantalum failing progressively looks like several unrelated things getting worse over a few hours. When multiple subsystems degrade together, look for one common factor first. Also, on a tantalum the stripe marks positive, which is backwards from an aluminum electrolytic.

Figure out why disks written on one machine won’t read on the other.

A dead ST-251

Sat, 15 Aug 2026 00:00:00 +0000

What I tried

Identified the 5271’s controller from the silkscreen: Western Digital WD1002A-WX1, assembly 60-600003-02, BIOS ROM 62-000094-030, the Super BIOS. Ran the on-card formatter from DEBUG with G=C800:5. Tried SpeedStor 6.0.3 too, but DEBUG against the card’s own formatter worked best. Swapped drives, cables and cards in and out for a while.

What I measured

The first format completed and reported 612 cylinders and 4 heads, about 21 MB. The ST-251 is 820 cylinders, 6 heads, 17 sectors, about 40 MB. That’s the card’s fixed mode: geometry comes from a drive table selected by the S1 jumpers, and the table stops at 663 cylinders.

In dynamic mode with the right geometry the format ran for hours and never finished. The drive swept full stroke about once a second the whole time.

What broke or surprised me

The drive was dead. The same process worked fine on two other ST-251s. Of the four, two are good.

Also, SpeedStor’s MediaAnalysis scans cylinder 0 head 0, which is where the WD card keeps its dynamic geometry, and wipes it.

Floppies before hard drives. The 5271’s floppy had started acting up.

D and W check out by hand, and the network stack gets the core repo's test rigor

Sun, 09 Aug 2026 00:00:00 +0000

Day after bring-up, on the other machine. The README’s status paragraph got a truth pass and now says memory read and write through the monitor is verified by hand over the LAN. That closes the 0x44 thing from the day before. None of the day’s commits names a fix for it, so I’m treating it as a bring-up artifact rather than a bug that got patched.

SPEC.md section 12 got a dated amendment instead of a rewrite. The hardware Etherbone wire contract is superseded by the software server, with the CommUDP dialect written down, a structural bound that a reply never exceeds the request length plus 16 bytes, and the broadcast-request, unicast-reply rule with the reason it exists. Section 13 gained the ARP keepalive requirement and a requirement that the RX path accept both limited and subnet broadcast, which is why udp.c is a fork. VPLAN grew 14 rows for the software transport and now counts 44 of 133 passing.

The bulk of the day was tests. The firmware C compiles on the host against a mocked ethmac, a 4-slot model with a scripted auto-responder. eb8008.c got 26 directed tests plus a 2149-case adversarial sweep over truncated and oversized records, which settled a suspected reply-buffer overflow by showing a read record always consumes at least as many bytes as its reply produces. udp.c got 46 tests covering the subnet-broadcast fix, min-frame padding, source MAC capture, ARP-free replies, and ICMP both directions. The serve glue came out of main.c into eb_serve.c so it could be tested too, 15 tests through the real receive, serve and transmit path including NAT-rewritten ports. dhcp8008.c got adversarial parser cases. A coverage gate fails below 100 percent of lines on all four files. main.c is the one file left without a harness.

On the host side, a golden differential encodes every request with litex’s own EtherbonePacket and decodes the C server’s replies through a pipe harness, plus 50 seeded random records against a Python reference model. A fork-drift test pins the sha256 of the vendored udp.c base and checks each load-bearing change is still there. And a conftest guard makes any UDP sendto off the loopback raise, because the broadcast-probe change had three tests emitting probes onto the bench LAN. Host pytest is 105 and the SoC tier is 48, the latter elaborating all three ethernet configurations through the real CLI.

Mutation pass. Seven bugs planted one at a time, each required to fail its test, then reverted. The subnet-broadcast fix dropped, TX padding dropped, correlation id zeroed, port mirroring hardcoded, MAC-capture reply replaced with broadcast, and 8 bytes of slack either way in both bounds checks. The two bounds mutants survived the first time. The sweep was checking the reply-size contract and a canary but not what the parser did to the bus with truncated input. It now checks that a record section executes only if every one of its bytes arrived, against per-cut expectations across all 2149 cases, and that kills both.

The old Verilator CSR bench is deleted. It drove the Wishbone RAM window and the run/stop control, both removed by the spec, and the structural test asserts the RAM window is gone, so the bench couldn’t even elaborate.

make selftest is new. Five checks over the live board with no arguments, using the same discovery and bridge as make login. Identifier read, console banner, an H command, a scratch write and readback with three patterns, and a 255-word burst read. The bridge startup window went from 5 s to 15 s because a board mid-DHCP can take that long to answer a probe. The board was powered down before it got a live run, so the code path is verified up to discovery only.

Last, a GitHub Actions workflow mirroring the core repo’s. It bootstraps the gitignored LiteX environment on the pinned tag, installs oss-cad-suite, checks out intel-8008-vhdl for the core, and runs the C tests with the coverage gate, both pytest tiers and the SoC elaboration on every push.

Next is TODO.md, which is the plan to get all 133 rows to pass or waived with cocotb, SymbiYosys and EQY, and a b8008net load tool that paces a hex file against the monitor’s echo.

Spec first, and the gateware is wrong in 12 places

Sat, 08 Aug 2026 00:00:00 +0000

I wrote SPEC.md and docs/VPLAN.md before correcting any RTL, and declared the spec authoritative. Every normative sentence has an ID like S-RX-3, every plan row cites one, and the plan bans the words “correctly”, “properly” and “as expected” from its pass conditions. Then I walked the existing gateware against it and wrote down where they disagreed. There were 12.

The worst ones. The cd_b8008 reset synchronizer was gated only on the PLL lock, with no power-on reset or button in the fan-in and no ordering against cd_sys, so the console logic and the core could come out of reset in either order. The console read register was a destructive pop, and LiteX’s CommUDP retries a read that times out, so a dropped reply packet ate a byte silently. The RX FIFO dropped bytes on the floor when full instead of stalling the 8008. A TX write while full was discarded without a flag. And five retired control inputs, run/stop, step, interrupt request and vector, were left undriven at the netlist boundary going into the CPU’s run and interrupt logic.

The fixes came in as their own commits. ConsoleBridge got extracted from the integration module as a pure Migen block. console_rx became a non-destructive read of data, valid and level in one word, with console_rx_pop as a separate write. Backpressure went in with hysteresis at 4032 and 3968 bytes, gating the core’s run_enable hold. A sticky console_err register with three bits, where a set that coincides with a clear resolves in favor of set. TX writes while full are rejected and flagged. The cd_b8008 reset is now synchronized off the PLL lock and the board reset together, and ordered after the console logic’s reset. The dead controls, the hardcoded triggered status and the Wishbone RAM window are gone from the CSR map and from the VHDL entity itself.

SPEC.md was wrong twice. S-RST-3 said no reset reached cd_b8008 at all, and it did, it was just mis-gated. S-CDC-1 miscounted the crossings. Both corrections are noted in the document where they happened instead of being quietly edited.

Then the first real bitstream build, yosys through ecppack. It succeeded, and the post-PnR report printed a critical path report for a cross-domain path from the etherbone clock to the b8008 clock. S-CLK-3 wants those two declared as separate clock groups. LiteX’s add_false_path_constraints() turns out to be inert on the ECP5 Trellis toolchain and never reaches the generated .lpf or nextpnr. I found no mechanism to declare the groups, so D-12 stays open.

A final review pass found six plan rows in the test suite tagged against the wrong assertion, and one row, RX-6, had no genuine test behind its tag and went back to unimplemented. The count went from 32 to 31.

Where it landed. 11 of 12 divergences resolved. 31 of 119 verification rows pass, 88 unimplemented, 11 imported from the core repo and never re-run here. The host package has 86 tests passing. make login exists as a console client with discovery by cache, then DNS, then a subnet sweep. Nothing had run on the board yet when this closed.

Every module machine-checked, and the checkers find three bugs the board never showed

Sat, 08 Aug 2026 00:00:00 +0000

Before this

On 2026-07-29 the carry look-ahead block got wired in as the ALU’s adder. It had compiled and had a testbench and nothing instantiated it. The toolchain was inferring the adder from numeric_std and the look-ahead was decorative. It now has a 9-bit carry-out and a sum output, SUB, SBB and CMP feed it two’s complement and invert the carry into the 8008 borrow flag, and an exhaustive testbench sweeps all 656,384 arithmetic cases against a reference model.

What I tried, 08-07

A synth-plugin target using the ghdl-yosys plugin, and a netlist-vhdl target that runs each module through Yosys write_vhdl so the round-tripped netlist can be checked against the RTL. Then, module by module: stack_pointer got PSL properties proven by k-induction under SBY plus a miter against its netlist, and a cocotb random walk that runs against both. state_timing_generator got a full property suite, 21 arcs and the status table, proven by k-induction. machine_cycle_control got bmc and cover. condition_flags k-induction. The ALU’s write_vhdl round trip was proven equivalent by an SBY miter. Combinational modules went through EQY. The instruction decoder got an exhaustive 256-opcode sweep against a Python model written from the datasheet, and that found issue #4.

write_vhdl splits vector flops, which breaks EQY’s partition matching, so sequential modules use SBY miters instead. GitHub Actions runs all of it on push.

What I tried, 08-08

register_file, stack_memory, instruction_register, temp_registers, interrupt_ready_ff and ahl_pointer all got properties and miters. memory_io_control got a 21-scenario cocotb suite. The assembly regression suite joined CI with the AS assembler built from pinned source, which exposed that NUL bytes in the sim log had been blinding GNU grep. ANA, XRA and ORA joined the ALU sweep, now 1,049,600 cases. A READY/WAIT stress test, interrupt jams with NOP, HLT and 3-byte instructions and during WAIT, 14-bit PC wrap, a 48-combination conditional matrix, and composition proofs across the cycle-control and timing-generator cluster.

The verification plan was audited row by row against the spec stack. All 15 open spec questions were ratified and isa.json realigned with the PDFs. Orphan modules and dead fabric were deleted.

What broke

Three RTL bugs, none of which the board had ever shown.

The external cycle code on D6 and D7 was transposed relative to the datasheet’s table, and during H:L data cycles the raw H byte rode the bus where the code belongs. Nothing on the Versa decodes those bits, so silicon never noticed. A period-correct external controller would have. The new cocotb bus-protocol monitor caught it on its first run: 265 violations before the fix, 0 after, across 341 T1 and 341 T2 checks.

The decoder flagged CPr with opcode 0xFF as memory-indirect.

INP wasn’t driving the condition flip-flops onto the bus at PCC T4.

What I measured

Every checker was mutation-tested by planting a bug and confirming it fails. The differential fuzzer generates seeded random legal programs (forward-only jumps, leaf-only calls, terminating by construction) and runs them whole-system on both the RTL and netlist cores under three oracles: the bus monitor, a per-instruction datasheet timing check, and an rtl-vs-netlist trace diff. 20 seeds on both cores, all traces identical, zero violations. A dropped ALU inverter planted in the netlist was caught by the trace diff on 2 of 20 seeds.

Plan rows	102
Formal	23
Exhaustive	8
Directed	66
Incidental	3
Constraint	2
Gap	0

Regression suite is 37 programs.

Nothing on the verification side. The README scorecard shows every module with something machine-checked behind it.

Ethernet bring-up: hardware Etherbone is dead on silicon, so Etherbone goes in software over broadcast

Sat, 08 Aug 2026 00:00:00 +0000

Same day as the spec work, the bitstream went on the Versa for the first time.

Timing came first. At the stock 75 MHz the sys and etherbone domain closed at about 66 MHz. SYS_CLK_FREQ is 60e6 in the Makefile now and it closes with margin. The b8008 domain at 25 MHz was never the problem.

With no network I needed a console, so --debug-uart puts the LiteX UART on X3, FPGA transmit on B19 and receive on B12, into a 3.3 V FTDI. The firmware grew bring-up instrumentation to print there at boot. An MDIO scan finds the Marvell 88E1512 at address 0. Its MSCR2 reads 0x1076, meaning the PHY adds the RGMII delays internally in both directions, so the FPGA-side delays have to be 0 and 0. MAC RX and TX counters, and a PHY internal loopback self-test that passed 3 of 3.

The CPU path through the plain ethmac worked. Gigabit link, loopback clean, and a DHCP lease from the LAN. That needed LiteEth vendored at master 276c9e3. The pinned 2026.04 release mangled the preamble on transmit frames in PHY loopback.

The hybrid path is the part where LiteEth’s hardware does Etherbone, ARP and ICMP alongside the CPU’s MAC, and it’s what the spec assumed. On silicon it never answered. I tried LiteEth 2026.04 and master, data width 8 and 32, static IP and the dynamic mux, the stock add_etherbone and a local reconstruction of it. Every permutation dead. The upstream test/test_mac_hybrid.py passes in sim. I couldn’t find a public report of hybrid working at gigabit, and my guess is a rate or clock-crossing defect in the hardware path that doesn’t show at 100 Mbit. The bisect flags, --stock-hybrid and --eb-static-ip, stay in the tree, and --ethmac-only is the production config.

So Etherbone moved into firmware. eb8008.c is a software Etherbone server on the VexRiscv speaking the litex CommUDP dialect, probe plus read records answered as writes with the request’s base return address as the correlation id, 32-bit big-endian. I validated it host-side against litex’s own encoder and decoder before flashing.

Then the network on the bench got in the way. The mesh router, an MR60, drops or NATs unicast from a WiFi client to the wired LAN, and it negative-caches an unanswered ARP and never asks again. Broadcast gets through. So udp.c is now a local fork of libliteeth’s. Upstream has a bug where the destination-equals-my-IP filter in process_frame makes the broadcast callback path unreachable. The fork fixes that and adds /24 subnet-broadcast acceptance, minimum-frame padding on transmit, a gratuitous ARP announce, a forced gateway ARP refresh, and udp_set_peer so replies skip ARP. The serve loop takes a DHCP lease, then answers Etherbone on both the unicast and broadcast receive paths. Replies go unicast straight to the requester’s captured MAC and mirror the request’s ports.

One more firmware trap. The generated regions.ld gets rewritten by the builder with ROM shrunk to whatever the previous firmware measured, so any build that grows fails with “region rom overflowed”. linker.ld has fixed ROM and SRAM ceilings now.

Host side, eb_server.py replaces litex_server --udp. It broadcasts requests to the subnet, accepts unicast replies, and ignores the socket’s own broadcast echo. discovery.py tries one broadcast probe before the cache, DNS and sweep. board.py spawns this bridge instead of the stock server.

Verified on the board: discovery finds it, a RemoteClient reads the SoC identifier, a CSR write reads back, and make login lands at the 8008 monitor prompt over the LAN.

What broke next. The monitor’s D and W commands return a constant 0x44 and writes don’t stick. This is the first time the b8008 console path has run on silicon and I haven’t looked at it yet.

5271 first power

Sat, 08 Aug 2026 00:00:00 +0000

What I tried

Inspected the 5271’s PSU. It looked fine and stayed original. Then I swapped video cards around between the two machines to get the 5160 live on the 5153 with the best of what I had. It took a few tries. An EGA card in CGA mode is what finally worked on that monitor. With the 5160 settled, the 5271 got a VGA card and came up next, with the Inboard 386 still installed.

What I measured

Both machines POST. The 5271 shows ERROR at boot with no code and continues.

What broke or surprised me

The 5153 is pickier than I expected about which EGA card it will show a picture from.

Hard drives.

Model F refurb

Sat, 01 Aug 2026 00:00:00 +0000

What I tried

Complete disassembly on both boards. Every key pulled and cleaned, the steel frame cleaned, then an electric duster at high RPM through everything. Loud.

What I measured

Nothing. It’s a passive device. I cleaned and tested every key.

What broke or surprised me

Nothing broke. Both work fabulously. I now understand what the eBay listings mean by “clicky.”

Get the 5271 up.

5160 PSU and first power

Sat, 25 Jul 2026 00:00:00 +0000

What I tried

Opened the 5160’s IBM 130 W supply. The RIFA cap had cracks in it, so I replaced it and the large ceramic next to it before applying power. Inspected every tantalum on the motherboard and the cards. Then the listen test with no video card, then a video card and the 5153.

What I measured

One long and one short beep with no video, which is the board complaining correctly. With video, a memory count and a picture.

What broke or surprised me

A lot of dust. It took some shaking off, and I needed the floppy and a keyboard working before it went anywhere useful. Both of those got their own sessions.

Keyboards.

Pickup in Chehalis

Sat, 18 Jul 2026 00:00:00 +0000

What I tried

Met Dan in Chehalis after about four months of emails. He’d said what he had and I took as much of it as I could fit.

What I measured

Two machines, a 5160 and a 5271 with an Inboard 386 in it, an IBM 5153, two Model F keyboards, a 122-key 3270 keyboard, four ST-251s, and a box of ISA cards including the 3270 display adapter and host connect card. All Tektronix surplus, stored since the 1990s.

What broke or surprised me

Nothing had been powered on. The 3270 keyboard controller card wasn’t in the lot.

Inspect the power supplies before anything gets plugged in.

Carved out of the core repo, and the LiteX chain builds again

Fri, 10 Jul 2026 00:00:00 +0000

The Ethernet monitor design spec went into the core repo on 2026-07-09, and the next day I pulled projects/b8008_net out of intel-8008-vhdl at commit 311df3f into a fresh repo called remote_8008. Tracked files only. The vendored LiteX trees and build products get recreated by make litex-env, which pins LiteX 2026.04 into a local venv. The top-level Python moved into soc/, and rom_4kx8_bram.vhdl came across from the monitor project.

The core itself doesn’t get copied. It comes in as the FuseSoC core greygiant:retro:b8008 through its ghdl_synth_verilog generator, with CORE_DIR pointing at the core checkout. This is the same arrangement the Byte Hamr card uses, so the 8008 has one source of truth and two consumers.

Two things broke on the move. soc/versa_soc.py computed the netlist path relative to its own directory instead of the repo-root build/, so make build couldn’t find what make convert had just produced. The same fix had already gone into the bench script. And host/tests/test_selftest.py still looked for host_selftest.py one level above host/, where it sat in the monorepo layout.

The third thing wasn’t the repo. Every RISC-V compile, BIOS and firmware alike, died with “internal compiler error: Abort trap: 6”. otool -L on cc1 showed it couldn’t load libisl.23.dylib or libmpc.3.dylib. brew install isl mpfr fixed it. Homebrew’s riscv-gnu-toolchain had lost its runtime deps and was reporting it as a compiler bug.

A fresh checkout has an ordering problem too. make bootstrap-headers has to run before make firmware, and it can’t be an automatic prerequisite without a circular edge between build and firmware. It’s in the README and a Makefile comment.

After that, make sim-core, make sim-netlist, make sim-bench and make build all pass in the new layout. Nothing has been loaded on the board from this repo yet.

An Intel 8008 in the card, and a whole 8008 toolchain that lives on the Apple IIe

Wed, 08 Jul 2026 00:00:00 +0000

What I tried

The 8008 core is the cycle-exact one from my Intel 8008 VHDL project. GHDL synthesizes it to a Verilog netlist and Yosys takes that unmodified, so the Byte Hamr build never needs VHDL support. On 2026-07-07 I dropped it into gateware/rev2/b8008_hamr/ using the SDRAM monitor’s bus idiom: the bootstrap FSM that jams RST 0 at T1I, ported verbatim from the core’s monitor top; 64-deep TX and RX FIFOs on IN 1 and OUT 9 with USART snapshot-and-pop semantics; an OUT 31 checkpoint latch; reset and go controls; live PC registers; ID $B8 at $C0CF. The 256-byte slot ROM is the whole glass terminal in 122 bytes, so PR#4 drops you at the 8008 monitor prompt with no OS in the loop. Ctrl-Q exits, Ctrl-R reboots the 8008 alone.

PR#4 from the BASIC prompt drops into the slot ROM terminal and the 8008 monitor answers. H lists the whole command set: dump, write, load hex, go.

I wanted to write the 8008 code on the Apple itself. The first leg was MAC8008, the 8008 instruction set as Merlin macros generated from the ISA JSON, with semicolon two-operand arguments like MOV A;B. B8RUN reads a ProDOS BIN whose aux type is the ORG, turns it into Intel hex and streams it through the FIFO to the monitor’s L command. B8CMP byte-compares two files through the MLI. The second leg, 07-08, was ASM8, a native 8008 assembler written in 6502 that takes true 8008 syntax, MOV A,B and MVI C,41h, with a table generated from the same ISA JSON. A8 wraps it: an 80-column full-screen editor, ^A assembles in memory and jumps the cursor to an error line, ^G streams the object into the card and drops into the monitor, ^Q comes back to the editor with the buffer intact. On 07-10 the vendored netlist went away and FuseSoC generates it at build time from the core repo.

A8 after ^A on HELLO8R.ASM, the verbatim upstream ASL source in 8008new syntax. The status row reports OK $01C9 AT $2040: 457 bytes of object at the ORG, the same size as the ASL reference. ^G streams it into the card.

^G from A8, then the run. The editor streams Intel hex into the 8008 monitor’s L command, one dot per record, the monitor answers OK, and A8 hands the screen over as a TTY with the G address printed. It stops there on purpose. I typed G 2040, the 8008 printed HI and 0123456789 B8008-OK, and the monitor came back.

What I measured

Core in the ECP5: 1453 LUTs, 433 flip-flops, 10 DP16KD, Fmax 74 MHz to 95 MHz at a 25 MHz clock.
First flash: PR#4, monitor banner, live prompt. H, D, W, G all work. A program hand-keyed with W at $2000 printed 8008 and restarted the monitor.
ECHO8, 37 bytes, written in Merlin Pro on the IIe with MAC8008: the object dumped with D matched the Merlin32 build byte for byte. Loaded with B8RUN, ran, echoed keys, ESC returned to the monitor.
MAC8008 against the ASL golden hex: 6 of 6 upstream samples byte-identical, hello_8008_ram at 88 of 88 bytes.
ASM8 acceptance: HELLO8R.ASM, the verbatim upstream source, assembled on the IIe and B8CMP against the 457-byte ASL reference object reported PASS. The Python model of the same spec had already passed 6 of 6 samples on the Mac, so the bench only tested the 6502 implementation.
A8: ^A on the same file reports OK $01C9 AT $2040, and the object it writes passes the same B8CMP gate. I then wrote COUNT8 from scratch in the editor, assembled it and ran it on the card.

What broke or surprised me

B8RUN’s first bench run went wild. The FIFO put routine clobbered X and Y, the record loop ran off the end, and a 64K read sweep walked straight through the $C0xx soft switches: garbled screen, and the slot 6 drive motors came on in write mode. I checked the floppies afterwards. The driver preserves X and Y now, and I found five more 6502-side bugs the same session, none needing a reflash: the MLI prefix is empty at boot so raw MLI calls fail with $40 until you set it; an error printer that destroyed the code before printing it; lowercase input that ProDOS rejects; an unattended load that overflowed the 64-byte TX FIFO and dropped the monitor’s OK, fixed by draining TX to the screen per record.

Merlin Pro on the IIe loaded the whole 200-line macro file and defined every macro, then threw Operand too long on the generator’s 72-column header comment. Merlin Pro enforces line width and Merlin32 does not. Every generated source is clamped to 40 columns now. Real Merlin also scopes local labels between globals, so self-modifying loops use global labels only, and #',' will not parse, so it is #$2C.

The monitor’s W command chokes on trailing text. My first freeze was annotations typed in with the listing, which the monitor faithfully wrote as garbage into a $00 HLT wall. A program that waits silently for input also reads as hung; the first ECHO8 run got Ctrl-R’d during its own input wait.

SCELBAL as a second personality, a direct load and readback port for RAM snapshots, and merging the block device so the card boots itself. None of it started.

Cycle-exact T-states, then SCELBAL, then booting straight into it

Fri, 03 Jul 2026 00:00:00 +0000

Cycle-exact

The ISA table in docs/isa.json always said which T-slots each machine cycle skips. The RTL ran every cycle a fat five states. Now cycles end where the table says: fetch cycles of multi-cycle instructions end at T3 (except LMr, which does its register write at T4), middle cycles of 3-cycle instructions end at T3, a not-taken conditional RET is 3 states, and not-taken conditional jumps and calls drop their last two states, 11 down to 9. The new cycle_done path goes T3 or T4 back to T1 mid-instruction without the interrupt check, again per Figure 2.

The first cut skidded. Fetch-cycle decisions have to evaluate in the second half of T3, because at T3 entry the instruction register still holds the previous opcode and the decoder flags are stale. A new regression runs one instruction per timing class, counts simulated states between fetch markers, and diffs against the table.

Check	Result
Timing classes cycle-exact	27/27
Regression suite	28/28
Interrupt suite	10/10
Bitstream timing at 25 MHz	93 MHz clk / 114 MHz

Pi visibly prints faster on the thin cycles.

SCELBAL from RAM

RAM grew to 12 KB, 0x1000 to 0x3FFF, to fit a 7.3 KB interpreter under the monitor. The ledger for Jim Loos’s build came to six changes: the variable-page EQUs, the program-space bounds, one ORG, four deleted init lines, the two USART I/O shims (only A and B touched, output preserves A with the MSB restored, per SCELBAL’s documented contract), and CRLF in the banner. I added an auto-SCR at cold entry so G 2000 would land in initialized BASIC, then reverted it the same evening. Jim’s manual SCR stays.

First SCELBAL run, RAM-resident, loaded through the monitor and started with G 2000. FOR/NEXT with PRINT I+1.

Loading it exposed weak spots in my send_hex script, which now fails loudly on silently dropped records, counts the EOF record’s OK correctly, and refuses to send unless it sees the monitor prompt first.

The tiny OS

Loading BASIC through a monitor every boot is a workflow. Booting into it feels like a computer. New build, new memory map: RAM 4 KB at 0x0000, 12 KB ROM at 0x1000 holding the monitor and SCELBAL, and three bytes of block-RAM initialization at address zero, JMP 1800h. The memory map became generics on b8008_top and the ROM address widened to 14 bits so both builds are the same top.

MON lives in an unused zero-filled slack region of SCELBAL’s keyword lookup table, every original offset preserved, and jumps to the monitor. G 1FB6 warm-enters BASIC’s executive without re-initializing, so the program survives the trip. The boot vector was verified in the synthesized netlist: ram[0..2] is 44 00 18.

Relocating my own monitor exposed a hardcoded page-low-byte in its command buffer, the same class of bug as calc’s FININP the day before.

The full ceremony passed in a testbench over the real RTL with a real UART: power-on to banner with nothing typed, SCR and a program and RUN, MON to the monitor prompt, W and D alive there, G 1FB6 and LIST intact. Then on the board the same evening.

Boot-to-BASIC build on the ECP5. SCELBAL from ROM, a FOR/NEXT loop, MON dropping to the monitor to dump the tokenized program at 0100, and G 1FB6 back into BASIC with the program still there.

Prove the thing beyond my own tests. The self-test passing means the CPU agrees with my reading of the datasheet, which is circular. The period software helped. Formal is the next step.

Load anything over serial, and 1974 finds five CPU bugs the self-test missed

Thu, 02 Jul 2026 00:00:00 +0000

What I tried

L streams Intel HEX from the UART into RAM, with checksum, resync at the next colon, a ‘.’ or ‘?’ per record and an OK or ERR verdict. G runs an address through a JMP trampoline at 0x3F80, since the 8008 has no indirect jump. Monitor scratch moved to the 0x3F00 page so a payload owns 0x2000 to 0x3EFF. RST 1 through 7 ROM vectors forward to 8-byte RAM slots at 0x3FC0 plus n times 8, and an uninstalled slot reads 0x00, which is HLT. Senders have to pace: the USART holds one RX byte and the echo path costs about 4 ms per character.

Then five programs from Mike Willegal’s SCELBI apps page. The recipe for each: relocate into 0x2000 to 0x3EFF, swap the bit-banged serial for OUT 9 and IN 1, exit with jmp 0 instead of HLT. Everything else stays the author’s bytes, and each change is in the commit.

Mandelbrot. org 2040h so the page-zero data offsets stay valid on page 0x20. That’s the whole change.

SCELBI Mandelbrot renderer loaded over serial and started with G 2040. Only change from the original was the ORG.

Pi. Page-zero variables moved out of what is now ROM, and its RST 7 handler reaches the output routine through a forwarded RAM vector slot. The port also surfaced a bug in the original: the 2013-era bit-bang cout ends its delay loop with B at 0, and prbcd keeps its BCD digit pair in B across that call, so every second digit prints as ‘0’ on any hardware wired that way. My USART version paces on A and leaves B alone.

Pi digit generator. 49 of 50 digits correct. The 50th is guard-byte truncation in the original algorithm.

HEXPAWN (1973). Learns by modifying its own move lists, which is why it has to run from RAM. Page literals bumped by 0x20. These programs compare against MSB-set ASCII, and the monitor’s ready byte is already MSB plus character, so input needed nothing. It beat me repeatedly and got better at it.

HEXPAWN from 1973, running from RAM at 2100 because it modifies its own move lists as it learns.

Calc (1974). SCELBI’s 23-bit floating point package with self-modifying result dispatch. Moving its work area from page 0 to 0x2000 found a bug in the original FININP: one site sets the destination page with xra a then mov d,a, hardcoding page zero instead of loading it from H. The converted mantissa was being written into monitor ROM, the write died silently, and every result printed +0.000000E+00. The fix had to be mov d,h, same byte count, because the self-modifying code around it depends on intra-page addresses staying put.

SCELBI floating-point calculator, 1974. 12.2 x 5.11 = 62.34202 through a 23-bit FP package, after the FININP page fix.

Shooting Stars (Byte, May 1976). Talks through RST 6 and RST 7. A small boot shim installs forwarding stubs in the RAM vector slots and jumps to the unmodified game. It wants DEL (0x7F) for rubout, and echoes a backslash per deleted character, because there’s no cursor addressing in 1976.

Shooting Stars from Byte, May 1976. Talks through RST 6 and RST 7 vectors that a boot shim forwards to the monitor.

What broke

Five things in the CPU, each found by one of those programs, each fixed in one module and re-proven on the board.

INR and DCR must preserve carry. The FP package does multi-byte arithmetic with increment-driven loops between carry-chained adds, and my ALU clobbered carry on every increment.
Rotates write carry only. Z, S and P must be preserved.
A real WAIT state. READY parks the CPU between T2 and T3. My first attempt was a PC freeze on the side, and it double-fetched.
Interrupts at instruction boundaries only. Figure 2 of the User’s Manual reaches the INTERRUPTED? decision only when execution is complete. Mine could hijack a multi-cycle instruction between its own machine cycles. An interrupt storm of RST 7s into a spinning taken-jump loop crashed on silicon until this, with the post-handler resume landing one byte past the jump target.
The PC lives in the address stack. The real chip has no separate program counter. The PC is whichever of the eight 14-bit stack registers SP points at. CALL is SP moving on and the old slot keeps the return address, with no copy. RET is SP moving back. I rebuilt it that way and converted fetch to post-increment. The pc_was_loaded flag and the pre-computed return addresses deleted themselves. The stack wrap now emerges from the structure. One consequence: the bootstrap RST-0 jam consumes one level for good, so programs get six safe nesting levels, same as real silicon booted the same way.

What else went in

The self-test grew to 46 with rotate flag preservation and INR/DCR carry cases. A parameterized 8 KB RAM behind an address decoder. The USART’s RX read became an atomic snapshot-and-pop after a race. Front-panel switches: sw(6) holds READY low to freeze the CPU in WAIT, sw(5) fires an interrupt with sw(7) picking RST 5 or RST 7, both with hltwake and intstorm test programs. A dead-board regression from a vector-mux race and inverted switch polarity got fixed the same day.

Cycle-exact T-states, then SCELBAL.

The monitor finally talks, and the flaky boot was the level shifters

Wed, 01 Jul 2026 00:00:00 +0000

What I tried

Fetch-capture instrumentation in the FPGA: latch every T3’s address and data onto the LEDs, and read them out when the CPU wedges. A black-box recorder that holds the killing instruction. Then a standalone rom_diag firmware that hex-dumps the CPU’s own view of its first 256 ROM bytes plus a RAM write and readback pattern, forever, with no receive path and no parsing. That proved the CPU, BRAM and UART transmit chain clean on their own.

What broke

Several independent things, which is why it took months.

The HW-221 breakouts are TXS0108E auto-direction shifters. I was running the 5 V EEPROM’s outputs into a bank whose VCCB rail was at 3.3 V. That’s an absolute-maximum violation on every read. Those parts wedge into a bad state until power-cycled, which is why boot reliability changed when I power-cycled the shifter board and nothing else. Auto-direction one-shot shifters were the wrong part for a memory bus regardless.

The bootstrap FSM was clocked on the derived phi2 signal with an async reset, so every path into it was unconstrained. Glitches re-jammed RST 0 (spontaneous restart to the banner) or re-fired the post-bootstrap hardware break (freeze). It now advances on a phi2 rising-edge enable inside the 25 MHz domain. No clock crossing remains.

The D command printed every low nibble as 0. send_hex_byte parked its byte in B, and char_delay counts B down to zero. Saved in C instead.

Weeks of “memory corruption” in the monitor turned out to be my backspace keystrokes going into the command buffer as raw 0x08 bytes. The hex parser stopped at them and mangled addresses. The CPU was never wrong about that one.

What changed

ROM went back inside the FPGA. The Yosys ROM problem from January got solved properly this time: a synchronous-read ROM that Yosys infers as DP16KD block RAM, with the one-clock latency invisible to the 8008. Firmware updates now go through ecpbram, which patches ROM contents into the post-PnR config. Unused ROM space is seeded with random bytes so ecpbram has a unique pattern to match, and it fails loudly if the pattern is missing, so the old silent corruption can’t come back silently.

The data RAM also went from async-read distributed LUTRAM with ‘Z’ outputs to synchronous block RAM. That LUTRAM was the design’s critical path.

Auto-start: a synthetic run press 2 ms after reset release, so the board boots hands-free. A W command for writing bytes. A boot testbench over the full top with a PLL stub and UART decoder, power-on to banner byte.

What I measured

Thing	Before	After
Firmware iteration	4 min resynthesis	0.66 s ecpbram
fmax	46 MHz	116 MHz
T-state		~4.4 us (real chip 4 us at 500 kHz)
ISA self-test on silicon		42/42

The self-test ROM runs on the FPGA and reports per test over serial: every ALU op in register, immediate and memory form, carry and borrow chains, all rotates, sign, parity, zero and carry branches, conditional CALL and RET both ways, 6-deep call nesting, a RAM pattern walk. The only bring-up failure was a wrong expected value in my own test. The CPU summed 0x11 times 28 to 0x1DC and the test wanted 0x1BC.

L to load Intel HEX over serial and G to run it. First payload is the 1974 SCELBI Mandelbrot from Mike Willegal’s page.

Conway's Multiverse: a soft 6502 on the card runs eight Life universes while the IIe watches

Wed, 10 Jun 2026 00:00:00 +0000

What I tried

The PicoPort’s PIO is driven by a small internal RISC-V, and that planted the question of whether the Byte Hamr could run its own processor next to the host. The ECP5 had the room. A 6502 made sense for this machine, so I put Arlet Ottens’ verilog-6502 in with its own block RAM and a $E000 write window that posts one SDRAM write through a two-client priority arbiter, monitor first, coprocessor second. Everything is one 25 MHz domain, no CDC.

C0 on 2026-06-08 was the steel thread: the coprocessor runs LDA #$42, STA $E000 from its own BRAM, the byte lands in SDRAM, and from the monitor B 000 then R 0040 prints 0040: 42. C1 the same day was a resident, hardware-protected kernel the host registers tasks into. C2 was a cooperative scheduler: two Merlin tasks race, the host reads 0102, retune the budgets and it reads 0201. C3 added a preemptive tick timer and an IRQ into the Arlet core, and a third task with no yields still gets sliced. C3.1 made the GO trigger a nonzero write so a stale count could not re-arm across runs. C-flash on 06-09 saves the task registry to flash and restores it on boot, with a magic-last header so a torn write fails safe. C4 the same day was async skill dispatch: a control-plane register block, a dispatcher inside the ISR, a slot mailbox ABI so a skill is reentrant, and CPLIB on the host with CP_CALL, POLL, WAIT and RESULT. Then a two-step $E004 to $E008 auto-increment read window, so the coprocessor can read SDRAM as well as write it. The demo needs that.

The demo is Conway’s Life, eight of them. LIFE8 is one registered skill that loops over eight independent universes in SDRAM forever, bit-packed cells, a three-row sliding window so each row is read once, wrap-around edges. The IIe picks a universe with the 0 to 7 keys, draws it, and otherwise does nothing. Switch away, come back, it has moved on.

Conway’s Multiverse. Eight Life universes evolving in the card’s SDRAM on the soft 6502; the Apple IIe is only the viewer.

What I measured

C0 build: about 2% of LUTs, 4 EBR, logic Fmax around 72 MHz against the 25 MHz clock.
Double Hi-Res grid, 560 by 192, about 107,000 cells: a few seconds per generation per universe on a 25 MHz 6502 doing one cell’s neighbors at a time.
Lo-Res grid, 40 by 48, about 56 times fewer cells: near real time with fat blocks. Both ship.
Gliders hold shape and wrap the torus. In simulation one crossing a packed-byte boundary lands one over and one down every four generations. The R-pentomino on channel 3 settles into beehives, blocks, blinkers and beacons.

The Lo-Res version, since it is the one you can actually watch:

Gliders in flight, wrapping around the torus edges.

Channel 3 after the R-pentomino settled: beehives, blocks, blinkers and beacons.

Soup that has organized. The box-and-bars structure is a period-2 oscillator, with beehives and a stray glider around it.

A different random seed mid-evolution, structures still resolving.

What broke or surprised me

Yosys will not infer a DP16KD with two write ports, so the kernel BRAM has one shared write port and a count-last rule. The Arlet core needed a registered synchronous data-in and a gate on SDRAM ready. A cooperative task has to end with JMP DONE and not RTS. Re-arming the count register is a level, so wait for DONE before re-arming or the kernel hangs.

The Gosper glider gun I seeded on channel 0 collapsed. On a torus the gliders come all the way round and hit the gun. Guns need an open field.

Lo-Res and Double Hi-Res are different memory formats. DHGR packs 7 pixels per byte so the render was a copy; Lo-Res is two stacked 4-bit color blocks per byte, so the renderer expands each cell bit into a $0 or $F nibble. And the double buffer that kept DHGR clean tears at Lo-Res speed, because the core laps the host inside one frame. The fix is a generation-stamped snapshot: copy the grid, check the generation counter did not change, retry if it did. Cloning the engine also broke on the row stride, which was a hand-written MUL80 and had to become MUL5 for 5-byte rows.

Other things that run on the card without the host asking. A live database the IIe queries, or a game where the day passes and crops grow whether or not you are looking. That became the farm.

Rev 2 cannot bus-master, so the hypervisor saves by shadowing and restores through the 6502

Sat, 06 Jun 2026 00:00:00 +0000

What I tried

The idea after the SDRAM monitor was a snapshot hypervisor: treat a whole booted machine, main 64K plus aux 64K plus registers and soft switches, as a guest that lives in one SDRAM context bank. Boot a disk, hit a hyperkey, the card traps the 6502 with NMI and INH, pages the guest out to SDRAM, pages the supervisor back in. The obvious fast path is DMA: pull the DMA line, halt the 6502, and let the card copy RAM to SDRAM itself.

On 2026-06-05 I went through the KiCad netlist to wire that up and found there is nothing to wire. The three address-bus level shifters, U8 for A0 to A6, U11 for A7 to A13 and U13 for A14 and A15, have DIR tied to +5 V and OE to ground. They pass slot to FPGA and nothing else. R/W is input-only at the FPGA on D10. The card can pull DMA low and stop the 6502, and after that no one can drive an address. The data bus through U12 is reversible and NMI, INH and RES are FPGA outputs, so the trap works, but nothing can drive an address.

So the mechanism changed. Save is continuous write-through shadowing: the card snoops every qualified CPU write, PHI0 falling with R/W low in a RAM region, and mirrors the byte into the active context’s SDRAM bank as it happens. The 6502 only drives the bus in phase 0, video and refresh are phase 1 reads, read-modify-write dummy writes self-correct because the last write wins, and the STA abs,X dummy cycle is a read, so that condition is enough. A soft-switch tracker supplies the main-or-aux bank bit per cycle, since RAMWRT and friends are not on the address bus. Restore is the 6502 pulling bytes out of the $C0Cx port with hardware auto-increment and storing them, with 256-byte dirty-page tracking so only clobbered pages get copied.

What I measured

SDRAM at 100 MHz against a roughly 1 MHz write stream: about 100:1, so the shadow keeps up with no buffering.
Estimated switch cost: 3.3 s for a naive full copy, 1.7 s with write-through save, 0.3 s target with dirty-page restore. A Rev 3 with DMA would be 50 ms to 100 ms.
06-06, restore on the bench: POKE 8192,17 into context 0, switch context, scribble 238 over the same RAM, BRUN SDMREST, PEEK(8192) reads 17. First 4 KB slice, $2000 to $2FFF main, software only, no gateware change.
06-07, trap unit 5c-2b: NMI vector hardwired to a handler in the $C800 ROM with INH forcing the fetch, captures a clean frame even with the vector page trashed and INTCXROM set.

What broke or surprised me

The SYNC line on B11 looked useful for the write snoop and is not. It marks opcode fetches, which never coincide with a write. It is parked as a future trace primitive.

BRUN needs ProDOS booted. Bare Applesoft gives ?SYNTAX ERROR because there is no DOS to hook the command.

Time-slicing the one host 6502 through this machinery costs seconds per switch, too slow to use it as a helper. A second CPU inside the FPGA gives real concurrency with no switch at all. That became the coprocessor, and the hypervisor stopped at 5c-2b on branch obscurus-sdram-monitor.

Rev 3 needs DIR and OE on U8, U11 and U13 routed to the FPGA plus an R/W output. I am not going to bodge three transceivers on a Rev 2 board. When Rev 3 happens, DMA drops in behind the same trap and vault logic as a speedup.