98 lines
4.2 KiB
Markdown
98 lines
4.2 KiB
Markdown
# 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.
|