076bb78b26
The 4004 chip now drives or samples the multiplexed nibble bus during
X2/X3 with CM-RAM (or CM-ROM) strobed for SRC, WRM, WMP, WRR, WPM,
WR0..3, SBM, RDM, RDR, ADM, RD0..3 — completing the I/O group that
was previously stubbed. The 4002 RAM chip is rewritten with a
phase-count-based timing model that samples the opcode at M1/M2 and
drives or latches the bus at the correct frame relative to the 4004's
drives.
Two new integration tests in 4002-ram.test.js wire a real 4004 + 4002
on the same board and prove the round-trip:
1. SRC P0 + LDM 3 + WMP — 4002 output port goes to 3.
2. SRC P0 + WRM 5 + CLB + RDM + WMP — 4002 output port goes to 5
(proves both write and read paths through the bus).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|---|---|---|
| .. | ||
| 4001-rom.c | ||
| 4001-rom.test.js | ||
| 4002-ram.c | ||
| 4002-ram.test.js | ||
| 8251-usart.c | ||
| 8251-usart.test.js | ||
| 8253-pit.c | ||
| 8253-pit.test.js | ||
| 8255-ppi.c | ||
| 8255-ppi.test.js | ||
| 8259-pic.c | ||
| 8259-pic.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.