47adb0b1c8
The gallery example loaded but the Z80 never visibly ran: the screen stayed frozen on garbage. Two multi-chip async-load races, neither caught by the existing headless tests (which drive RESET manually and attach the display before boot): 1. RESET edge-vs-level race. The Z80 only left reset on the RISING edge of RESET (a pin watch). In the browser the 7 chips instantiate asynchronously, so the small power-on-reset chip releases RESET before the larger Z80 has registered its watch -> the edge is lost and the CPU stays in reset forever. Fix: on_clock samples the RESET level (hardware-accurate; RESET is level-sensitive) so a missed edge self-corrects. An undriven RESET reads low, so the CPU safely stays in reset until something drives it high. Repro/guard: chipbus-galaksija-reset-race (race ordering must still boot). 2. Display-snoop load-order race. galaksija-display was a passive write-snoop; the ROM paints the screen ONCE at boot then idles, so a display that comes up late misses every write and shows stale content forever. A snoop cannot recover writes it never saw. Fix: fold the screen into the RAM chip (galaksija-ram-display) and render from the ACTUAL video RAM (0x2800-0x2BFF, internal 0x0800 with A0-A12 wiring) on a ~30 fps timer - correct regardless of load order, exactly how the real machine scans video RAM. Repro/guard: chipbus-galaksija-display-snoop-race (late snoop shows nothing) + chipbus-galaksija-ram-display (renders even when first paint is post-boot). The example now has 6 chips (RAM+display merged, gdisp dropped), 76 wires. Verified live in the browser: boots to "@'READY", shows the ">" prompt, and pressing A echoes ">A_" through keyboard -> Z80 -> video RAM -> display. The full chipbus suite is 45/45. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| fixtures | ||
| scripts | ||
| sdk | ||
| sketches | ||
| src | ||
| test | ||
| .gitignore | ||
| README.md | ||
| package-lock.json | ||
| package.json | ||
| vitest.config.js | ||
README.md
test_custom_chips
Sandbox aislado para validar el sistema de custom chips de Velxio antes de integrarlo al frontend. Cero dependencia de Wokwi.
Objetivos
- Probar que se puede cargar un
.wasm(chip compilado a partir de C) y enrutarlo al simulador. - Probar que un sketch de Arduino real (
.hexcompilado conarduino-cli) puede comunicarse con el chip vía GPIO e I2C. - Mantener fidelidad 1:1 con la infraestructura de Velxio (
PinManager,I2CBusManager,AVRSimulator) para que el código que se valide acá sea trivial de portar.
Estructura
test_custom_chips/
├── package.json
├── README.md
├── vitest.config.js
├── sdk/
│ ├── include/
│ │ └── velxio-chip.h ← API que ven los chips
│ └── examples/
│ ├── inverter.c
│ ├── inverter.chip.json
│ ├── eeprom-24c01.c
│ └── eeprom-24c01.chip.json
├── scripts/
│ ├── compile-chip.sh ← clang invocation Linux/macOS
│ ├── compile-chip.ps1 ← clang invocation Windows
│ ├── compile-all.sh ← compila todos los ejemplos
│ └── setup-wasi-sdk.md ← cómo instalar wasi-sdk
├── src/ ← runtime y mirrors de Velxio
│ ├── ChipRuntime.js ← loader WASM + host imports
│ ├── WasiShim.js ← WASI mínimo (fd_write, proc_exit)
│ ├── PinManager.js ← espejo de Velxio
│ ├── I2CBus.js ← espejo del I2CBusManager
│ ├── AVRHarness.js ← avr8js wrapper Velxio-fiel
│ ├── intelHex.js ← parser
│ └── index.js
├── fixtures/ ← .wasm compilados + .hex sketches
└── test/
├── js/ ← tests que NO requieren clang
│ ├── 01_pin_manager.test.js
│ ├── 02_i2c_bus.test.js
│ ├── 03_avr_harness.test.js
│ └── 04_runtime_imports.test.js
└── e2e/ ← tests que requieren .wasm compilado
├── 05_chip_inverter.test.js
└── 06_chip_eeprom_24c01.test.js
Quickstart
# 1. Instalar deps
cd test/test_custom_chips
npm install
# 2. (Solo para tests E2E) instalar wasi-sdk siguiendo scripts/setup-wasi-sdk.md
# 3. (Solo para tests E2E) compilar los ejemplos
npm run compile:examples
# 4. Correr tests
npm test # todo
npm run test:js # solo tests JS-only (no requieren wasi-sdk)
npm run test:e2e # solo E2E con WASM
Los tests e2e/ se hacen it.skip automáticamente si el .wasm correspondiente no
está en fixtures/. Eso permite correr la suite parcialmente sin tener wasi-sdk instalado.
Por qué un sandbox separado
Igual que test_circuit/ validó el solver SPICE antes de integrarlo, este sandbox valida
el runtime de chips antes de tocar el frontend de Velxio. Cuando los tests pasen end-to-end,
los archivos de src/ se portan al frontend (con tipado TS) e integran con el editor.
Estado actual
Ver ../autosearch/04_findings.md para el log corrido de qué funciona y qué falta.