8a1d75a96c
Three new bus-device chips, all clean-room from public Intel datasheets: - rom-1m: 64 KB ROM mapped at 0xF0000..0xFFFFF for 8086 boot. 20-bit address bus watch with out-of-range tristate. 16-byte known signature pre-loaded at the reset vector 0xFFFF0. - 8255 PPI: Mode-0 (basic I/O) only; three 8-bit ports with split upper/lower port C. Control word parsing for direction setup. Bit set/reset and Modes 1/2 deferred. - 8251 USART: async-mode UART using vx_uart_attach for bit-timing; mode word + command word + status interface; TxRDY/RxRDY/TxEMPTY status pins; DTR/RTS pass-through. Internal-reset honoured. Deferred to a follow-up Phase C+: - 4001 ROM and 4002 RAM (multi-phase 4-bit bus timing requires either an external clock-gen chip or Bus4004-equivalent host coordination that's only available in the JS test harness today). - 8253 PIT (6 modes, countdown logic). - 8259 PIC (ICW init state machine + cascade + INTA cycle). These are flagged in autosearch/18_complete_emulation_plan.md as deferred — Phase D (4004/4040 I/O) and the 8259 work depend on them landing first. Tests: test_buses 17 → 30 passing (+13). Total test_intel 73 → 86 passing, 0 failed, 17 todo. Master plan doc updated. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| 8251-usart.c | ||
| 8251-usart.test.js | ||
| 8255-ppi.c | ||
| 8255-ppi.test.js | ||
| README.md | ||
| latch-8282.c | ||
| latch-8282.test.js | ||
| ram-64k.c | ||
| ram-64k.test.js | ||
| rom-1m.c | ||
| rom-1m.test.js | ||
| rom-32k.c | ||
| rom-32k.test.js | ||
README.md
test_buses — External memory chips for retro CPUs
Real PCBs from 1976 don't put RAM/ROM inside the CPU package. Faithful emulation requires the same separation: the CPU drives address pins, chip-select, and RD̅/WR̅; separate memory chips on the canvas listen.
These chips are reusable across all five Intel/Z80 CPU projects.
Chips planned
| Chip | Pins | Source file | Status |
|---|---|---|---|
rom-32k |
27 | rom-32k.c |
✅ Implemented — 6/6 tests passing |
ram-64k |
29 | ram-64k.c |
✅ Implemented — 7/7 tests passing |
latch-8282 |
20 | latch-8282.c |
📋 Spec only (only needed for 8086) |
Why we still test these C chips even though tests use installFakeRom
The BoardHarness.installFakeRom() and installFakeRam() helpers
emulate memory in JS for CPU unit tests. They are fast, flexible,
and don't require a per-test compile.
The real rom-32k.c / ram-64k.c chips are needed because:
- End users wire them on the canvas. A user dropping a Z80 into velxio expects a draggable ROM and RAM next to it. The C chips ARE that user-visible primitive.
- Integration tests need the real chip. Once a CPU is verified
in unit tests with a fake ROM, an integration test runs the same
CPU with the real
rom-32k.wasm, proving the on-canvas demo will work.
So the test split is:
*.unit.test.js→ usesinstallFakeRom/installFakeRam, tests instruction semantics and bus protocol*.integration.test.js→ uses real compiled bus chips, proves the user-visible demo works
For now we have rom-32k.test.js and ram-64k.test.js covering the
C chip behavior in isolation — pin contract + read/write protocol
with hand-crafted bus stimuli.
ROM image loading — the SDK constraint
The velxio chip SDK does not (yet) support arbitrary-length blob
attributes. vx_attr_register only takes a double. So a 32 KB ROM
image cannot be passed in via .chip.json properties.
Workaround for now: the C source contains
const uint8_t rom_image[32768] = { /* baked-in */ };. Each "ROM
variant" is a separate compiled chip. For shipping examples we will
generate one variant per demo program; for tests we use a small image
embedded directly in rom-32k.c.
A follow-up SDK proposal — adding vx_attr_register_blob() or an
"asset" import mechanism — is tracked in
../autosearch/05_open_questions.md.
ram-64k notes
The RAM chip is simpler — no embedded image, just a static uint8_t mem[65536] zero-initialized at chip_setup. No SDK extension required.