# Open questions

Things to resolve before committing emulator code.

## Q1. Do we need a generic external memory chip first? — **RESOLVED**

**Decision:** yes, build `rom-32k.c` and `ram-64k.c` as separate
reusable chips. They live in `test/test_intel/test_buses/`. Tests
exist (`rom-32k.test.js`, `ram-64k.test.js`); chip code is the next
phase.

For CPU **unit** tests we use `BoardHarness.installFakeRom()` and
`installFakeRam()` (pure-JS) — no per-test recompile. The real C chips
are needed for **integration** tests and for end-user demos on the
canvas (where the user drags ROM/RAM next to a CPU).

## Q2. Where exactly should vendor emulator cores live? — **RESOLVED (moot)**

**Decision:** we don't vendor any third-party emulator cores. All five
CPUs are clean-room implementations from public datasheets. The risk
of GPL contamination outweighs the convenience of porting an existing
emulator, and we get a higher quality bar by writing it ourselves.

Reference emulators listed in
[04_open_source_emulator_references.md](04_open_source_emulator_references.md)
remain useful as **behavioural references** (look up "what should
DAA produce after 0x99 + 0x01?") but no code is copied.

## Q3. Is there a built-in "address latch" primitive?

The 8086 needs an external `8282`-style address latch to demultiplex
`AD0..AD15` into stable `A0..A15`. We can:

- Author it as another custom chip (most consistent — but extra work).
- Inline the demux into the CPU itself by exposing already-demultiplexed
  pins (un-realistic but pedagogically simpler for a first cut).

**Status:** I have not searched for an existing latch chip in
`test/test_custom_chips/sdk/examples/`. The current list (per
`autosearch/01`'s file inventory) does not include one. Confirm
before writing.

## Q4. How are chip-config blobs (ROM images) wired? — **RESOLVED (with caveat)**

**Finding:** the SDK has no blob-property mechanism. `vx_attr_register`
takes only a `double`. The existing EEPROM examples
(`eeprom-24c01.c`, `eeprom-24lc256.c`) hardcode their initial state in
C as `static uint8_t mem[SIZE]` (zero-initialised at chip_setup); they
do NOT load anything from `.chip.json`.

**Decision for now:** each ROM variant is a separately compiled chip
(`rom-32k-cpudiag.wasm`, `rom-32k-helloworld.wasm`, etc.) with its
image baked into a `const uint8_t rom_image[]` in C.

**Future enhancement (deferred — explicitly not done before chip code
lands):** propose adding `vx_attr_register_blob(name, default_bytes,
default_len)` to the SDK, returning a `(ptr, len)` pair the chip can
read at startup. This would let one `rom-32k.wasm` serve any image
loaded from the diagram editor. Open as a follow-up SDK PR after
the first CPU is shipped.

## Q5. What is the realistic upper bound on timer fire rate?

The runtime ticks chips during the simulation frame. If we run a Z80
at 4 MHz with a per-T-state timer (250 ns period) we'd be asking for
4 million callbacks per simulated second, which the host loop very
likely can't sustain in real time. Two implications:

- We may have to coalesce multiple T-states per callback (do the
  whole instruction in one tick), losing some single-step fidelity
  but staying tractable.
- Pure simulated-time timing (`vx_sim_now_nanos`) may decouple
  enough — the chip *thinks* it's running at 4 MHz even when wall-clock
  throughput is lower. Confirm by reading the timer dispatcher in
  `frontend/src/simulation/customChips/`.

**Status:** unverified. Run a tight-timer benchmark before committing
to a target clock rate.

## Q6. Power pins — collapse or model?

Real 8080 needs +12 V, +5 V, −5 V. Velxio is digital. Plan: expose a
single `VCC` and `GND` pin on every CPU. Document the simplification
in each chip's README.

**Status:** decided (collapse). Recorded here for transparency.

## Q7. Are open-drain / bus-tristate semantics modelled?

Real CPUs tristate the data bus during writes-from-other-masters. The
velxio pin model is digital HIGH/LOW; "tristated / Z" is generally not
a first-class state. We will model bus-release by setting the pins to
input (`vx_pin_set_dir(pin, VX_INPUT)`) and rely on no other chip
asserting them simultaneously.

**Status:** convention adopted. Verify there are no contention
warnings in the runtime that would fire during a normal CPU bus cycle.