# PFES-ENG-030 — Firmware Emulation

## Purpose

Firmware emulation is a behavioral engineering instrument. It combines CPU
execution with modeled memory, MMIO, timers, interrupts, GPIO, persistent SCSI
state, media topology, and host transport.

## Canonical baselines

- v206 is the known-good Windows/iSCSI behavioral baseline.
- v258 is the current handoff baseline and closes READ(10) parser/descriptor
  state handoff.

A baseline records an accepted scope; it does not imply complete firmware or
hardware fidelity.

## Behavior and proof classes

Always label whether a result is:

- bridge/model behavior;
- seeded microprobe behavior;
- natural firmware execution;
- firmware state handoff across bounded phases;
- uninterrupted firmware execution;
- hardware validation.

Seeded state is not natural state. Bridge correctness is not firmware derivation.

## READ(10) state

The current closed chain proves:

- CDB opcode dispatch to the natural READ(10) handler;
- host-LBA assembly into SRAM `0x05EC`;
- command and phase state at `0x05F0` and `0x06F1`;
- phase-4 consumption;
- descriptor copy to `0x06E4` and arm at `0x06E0`.

The downstream descriptor/window selector and firmware-derived unlocked media
delta remain open.

## Timer and MMIO state

The GDR HL smoke reaching the handler and stalling at
`0x90006227..0x90006231` means the discriminator passed. It exposes missing
hardware/timer fidelity rather than a parser failure.

## Profile architecture

- device profiles come from analyzer knowledge;
- media profiles come from acquisition/media tooling;
- session profiles come from a separate builder and bind device, optional media,
  firmware path, bridge, logs, safety, and overrides;
- proof packs and JSON test manifests remain separate repeatable evidence inputs.

## Windows workflow

The accepted UX goal is to start one iSCSI optical target, let Windows detect the
emulated drive, exercise it with normal Windows software, and use eject/load as
part of media-state testing. Cleanup targets the emulator IQN/session/portal,
not a friendly-name match that could also identify physical hardware.

## Testing and logging

Default logging is quiet. Detailed trace/MMIO and per-instruction logging are
explicit debug modes. Probe/report-only work uses local validation and a quick
smoke. Runtime/state/media/bridge changes require the fuller accepted flow.

JSON test configurations are stable experiment descriptions and should remain
machine-generatable.

## Packaging

Runnable emulator ZIPs are clean and version-focused, preserve stable installed
filenames, and do not contain firmware binaries or accumulated obsolete history.
PFES snapshots remain complete and cumulative.

## Scope boundary

CCI is not an emulator-support claim. It remains an acquisition/export format
unless a separate decision changes that scope.
