a2nr
/
velxio
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
velxio/test/test_custom_chips
History
David Montero Crespo 47adb0b1c8 fix(chipbus): Galaksija boots + displays + types live in the browser 
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>
 		2026-06-05 15:47:30 -03:00
..
fixtures Add ESP32 chip demos and comprehensive tests for I2C, SPI, and UART interactions 2026-04-28 19:24:39 -03:00
scripts Add ESP32 chip demos and comprehensive tests for I2C, SPI, and UART interactions 2026-04-28 19:24:39 -03:00
sdk fix(chipbus): Galaksija boots + displays + types live in the browser 2026-06-05 15:47:30 -03:00
sketches feat(i2c): cross-board bridging across all velxio boards (AVR/RP2040/ESP32 xtensa+riscv) 2026-05-12 17:51:39 -03:00
src Add ESP32 chip demos and comprehensive tests for I2C, SPI, and UART interactions 2026-04-28 19:24:39 -03:00
test Add ESP32 chip demos and comprehensive tests for I2C, SPI, and UART interactions 2026-04-28 19:24:39 -03:00
.gitignore Add ESP32 chip demos and comprehensive tests for I2C, SPI, and UART interactions 2026-04-28 19:24:39 -03:00
README.md Add ESP32 chip demos and comprehensive tests for I2C, SPI, and UART interactions 2026-04-28 19:24:39 -03:00
package-lock.json Add ESP32 chip demos and comprehensive tests for I2C, SPI, and UART interactions 2026-04-28 19:24:39 -03:00
package.json Add ESP32 chip demos and comprehensive tests for I2C, SPI, and UART interactions 2026-04-28 19:24:39 -03:00
vitest.config.js Add ESP32 chip demos and comprehensive tests for I2C, SPI, and UART interactions 2026-04-28 19:24:39 -03:00

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

  1. Probar que se puede cargar un .wasm (chip compilado a partir de C) y enrutarlo al simulador.
  2. Probar que un sketch de Arduino real (.hex compilado con arduino-cli) puede comunicarse con el chip vía GPIO e I2C.
  3. 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.