Files
Stefan ArentzandClaude Opus 4.8 4aa5364c3d Mouse PIA plan P5: docs (notes/MOUSE.md as-built) + cleanup (#336)
Rewrite notes/MOUSE.md as the real-hardware as-built: the 6520 PIA + 6805
controller + banked 342-0270-C ROM, the port-B handshake, the commands, the
X=$Cn/Y=$n0 calling convention and the screen-hole layout (Pos/Read
slot-indexed; ClampMouse's fixed slot-0 quirk), the interrupt model (][+
works, //e backlog), host input, the EWM integration, and the MousePaint
confirmation. Drop the retired synthetic-firmware description and its (now
resolved) "Known limitation".

Update README and notes/IDEAS.md to describe the mouse as the card's real
hardware, and mark plans/20260721-01 (the synthetic card) as superseded by
this plan.

Docs only; no code change.

Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-21 11:52:51 -04:00

471 lines
28 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# EWM Feature Ideas
A living backlog of feature ideas, gathered from a survey of the established
Apple II emulators — AppleWin (Windows), Virtual ][ (macOS), MAME's apple2e
driver, izapple2 (Go), Apple2TS (TypeScript) — plus the "Future work" lists
already in `REWRITE.md`, `APPLE_IIE_ENHANCED.md` and `WOZ1.md`. This is not a
plan: when an idea graduates, it gets its own working document in the style
of `APPLE_IIE_ENHANCED.md` / `WOZ1.md` (phases, gates, one PR per phase).
Sizes are the house scale (S/M/L). *(infra: …)* notes point at existing EWM
code an idea builds on.
**Where EWM stands today**, for contrast: Apple 1 / Replica 1 / ][+ /
Enhanced //e; 6502 + 65C02; Disk II with `.dsk`/`.do`/`.po`/`.nib`/WOZ 1.0
(read-only); slot 7 hard drive (boots Total Replay); Thunderclock; speaker
audio; paddles/buttons/joystick; 40/80-col text, LGR/HGR/DLGR/DHGR in color
or green mono; command palette (reset, pause, fullscreen, 3 CPU speeds);
status bar with drive lights; `--trace`; headless terminal examples; a
deterministic golden-BMP test culture.
## Hardware support (peripheral cards)
- **Mockingboard / Phasor** (M/L) — the single biggest game-compatibility
card: AY-3-8910 PSGs driven by 6522 VIAs (slot 4/5). Ultima III–V, Skyfox,
many demos. AppleWin and Virtual ][ both emulate it; AppleWin adds the
SSI263 speech chip. *(infra: `snd.rs` already has a cycle-stamped audio
path; the 6522 is a well-contained new device; and the AppleMouse card
(`notes/MOUSE.md`) built the reusable maskable-IRQ line the 6522 VIAs
assert.)*
- **Super Serial Card** (M) — slot 2 serial. The killer feature is the
**virtual modem**: bridge the SSC to a TCP socket so period terminal
software can "dial" modern telnet BBSes. AppleWin and Virtual ][ do this.
- ~~**AppleMouse card**~~ — **landed** (`plans/20260721-03-mouse-pia-hardware.md`,
as-built `notes/MOUSE.md`): `{"card": "mouse"}` in any slot 1–7, the card's
**real hardware** (a 6520 PIA + a 6805 controller + the `342-0270-C` ROM, so
MousePaint et al. drive it), host pointer input, and VBL/movement/button
interrupts on a new reusable maskable-IRQ line (which Mockingboard inherits).
A first synthetic-firmware version (`plans/20260721-01`) was replaced when it
could not drive MousePaint on the //e.
- ~~**RamWorks III aux-slot memory**~~ — **landed**: `--aux
ramworksiii[:SIZE]` (64K..8MB, bank register `$C073`), built on a new
`AuxCard` trait (`ewm/src/aux/`) that also brought the plain 1K
80-Column Text Card; the aux slot is now swappable per card file.
- **Z80 SoftCard → CP/M** (L) — a second CPU core (Z80) sharing the bus;
boots CP/M, WordStar, Turbo Pascal. MAME/AppleWin/izapple2 have it. Big,
self-contained, very fun.
- **Uthernet II / FujiNet** (L) — networking: a W5100-style ethernet card
(AppleWin) or the FujiNet virtual network device (izapple2, fujinet-
AppleWin fork). Unlocks Marinetti-era and modern network software.
- **No-Slot Clock** (S) — a phantom DS1216 clock accessed through ROM-space
reads; some ProDOS setups expect it. We already ship a Thunderclock, so
this is polish.
- **Cassette interface** (S/M) — `$C060`/`$C020` tape in/out against WAV
files (Virtual ][ emulates this "for nostalgic reasons"). Pairs nicely
with the Apple 1 side of EWM, too.
- **Printers** (M) — Virtual ][ emulates an ImageWriter II / Epson FX-80
and renders the output to PDF; even PrintShop graphics work. An EWM
version could render to PNG/PDF in the host filesystem.
- **VidHD ROM signature** (S) — izapple2/AppleWin implement just enough of
VidHD for Total Replay to detect it and enable Super Hi-Res artwork.
(Full SHR rendering is IIgs-sized; the signature stub is small.)
## Machine models
- ~~**NMOS //e (unenhanced)**~~ — **landed** (`plans/20260720-02-original-iie.md`):
`builtin:apple2e` is a 6502 //e with the 342-0134/0135 system ROMs and the
342-0133 video ROM (inverse upper case where the Enhanced //e shows
MouseText); today's Enhanced //e became `apple2enhanced`.
- **Original Apple ][ (Integer BASIC)** (M) — needs the Integer ROM set and
the 13-sector boot ROM (see Storage below); completes the Woz lineage
story the README tells.
- **Apple //c** (L) — MMU/IOU cousins of the //e work, built-in drives,
mouse, serial. The //e plan's "future work".
- **PAL variants / 50 Hz** (S/M) — a `--region pal` that adjusts the frame
loop's cycle budget and vertical timing; matters for European software
timing loops.
## Emulation accuracy
- **//e Ctrl-Reset should clear the MMU soft switches like the RESET line**
(S) — on a real //e the hardware RESET line resets the memory soft
switches (80STORE, RAMRD, RAMWRT, ALTZP, INTCXROM, SLOTC3ROM, and the
INTC8ROM latch) to their default main-memory / slot-ROM state *before* the
reset handler runs; the ROM handler relies on that and only re-clears what
it needs for the display. EWM's Ctrl-Reset (`Cmd-R`, and the Cmd-Shift-R
power-cycle) is just `cpu.reset()` — it reloads the CPU registers but
touches no soft switch — so whatever a program left on stays on. Measured
during the original-//e work: after Ctrl-Reset from an all-switches-on
state, RAMRD / RAMWRT / ALTZP / INTCXROM all persist on **both** //e (only
80STORE is cleared, in software by the ROM; SLOTC3ROM only on the
Enhanced). Consequence: a program that leaves **aux memory** active and
then Ctrl-Resets comes back *still running in aux memory* — reset does not
cleanly recover the machine, which never happens on hardware.
- **Fix shape:** a hardware-reset hook (e.g. `Two::reset` / `IouE::reset`)
on the Cmd-R / power-cycle path — distinct from a *program's* own soft
reset through the `$FFFC` vector, which must **not** reset the switches —
that resets the documented switches, then does the CPU reset.
- **Pin before implementing:** the exact switch set against the //e
Technical Reference / AppleWin / MAME. The **video** switches
(TEXT / MIXED / PAGE2 / HIRES / 80COL / ALTCHARSET) stay ROM-controlled —
80COL and ALTCHARSET are confirmed *not* hardware-reset (it's why the two
//e differ on whether Ctrl-Reset drops out of 80-column); PAGE2 / HIRES
membership needs checking.
- **Scope:** //e only. The ][+ has no MMU and its RESET resets nothing
notable (its language-card bank state persists across reset, as on real
hardware).
- *(infra: the switches live in `IouE` in `two.rs`; the golden-BMP
screenshots don't exercise reset, so they stay the tripwire that the
rest of the render path is untouched. Add a test that Ctrl-Reset from an
aux-active state returns to main memory.)*
## Storage & disk images
- **Disk II write support + write-back** (M) — currently writes only touch
the in-memory nibble stream (REWRITE quirk #2). Real write support (nibble
writes for `.dsk`/`.nib`, then saving back to the image file, dirty-flag
in the status bar) makes the emulator usable for actually *working* in
AppleWorks/DOS. WOZ stays read-only (spec discourages WOZ1 writes).
- **WOZ 2.0** (M) — variable-size TRKS, optimal bit timing field, FLUX
chunk, `requires_machine` metadata. The parser already detects and rejects
`WOZ2` cleanly; the bit engine is container-agnostic. *(infra: `woz.rs`.)*
- **13-sector boot ROM (P5)** (S/M) — a `--boot13` option or automatic
selection, unlocking DOS 3.2 disks (`DOS 3.2 System Master.woz` is already
in the test set, documented out of scope in `WOZ1.md`).
- **Remaining WOZ stragglers** (M?) — Stargate (`I/O ERROR` after boot) and
First Math Adventures (`BRK` at `$A853`) still defeat the bit engine; the
investigation notes live in `WOZ1.md`'s compatibility table.
- **`.2mg` and compressed images** (S) — 2IMG headers for ProDOS images;
transparently reading `.gz`/`.zip` images the way AppleWin does.
- **Disk image tools** (M) — a `ewm disk catalog <image>` subcommand that
lists DOS 3.3/ProDOS files without booting; maybe extract/insert files.
Great for tests and scripting, all headless.
## Video & display
- **NTSC artifact color** (M/L) — a shader-quality composite model for HGR
(and the DHGR **sliding-window** color already prototyped on the
`iie/experiment-dhgr-color` branch — see `notes/DHGR_COLOR_EXPERIMENT.md`
for its promotion checklist). AppleWin's NTSC mode is the reference.
- ~~**Monitor styles**~~ — **landed**: green / amber / white monochrome and
color via `--color [green|amber|white|rgb]` and the palette's
"Monitor Style" choice submenu.
- ~~**Scanlines**~~ — **landed**: `--scanlines [off|light|heavy]` + the
palette's "Scanlines" choice submenu (a multiply-blend overlay). A real
**CRT bloom** stays open — it needs shader/render-target work.
- **Video recording** (M) — capture the frame buffer to animated GIF or
MP4; pairs with the deterministic emulation for perfectly reproducible
demo captures. *(infra: `encode_bmp` + the `--screenshot` plumbing.)*
- **Screenshot polish** (S) — promote the hidden `--screenshot` flag to a
palette command ("Save Screenshot") writing PNG with a timestamped name.
## Audio
- **Speaker filtering & volume** (S) — a simple low-pass over the 1-bit
speaker stream and a volume control (palette entries); reduces the harsh
edge on click-heavy software.
- **Tape-out as audio** (S) — see the cassette interface above; recording
`SAVE` output to WAV doubles as a fun preservation trick.
- *(Mockingboard/SSI263 belong here too — listed under Hardware.)*
## Input
- ~~**//e paddle timers**~~ — **landed**: the `$C070`/`$C064`-`$C065`
timer model ported from `TwoIo` into `IouE`, parity-tested against the
][+ (found the moment a real Xbox pad met Wings of Fury on the //e).
- **Gamepad support polish** (M) — *partially landed*: **hot-plug**
(Bluetooth pads auto-connect on appearance, auto-fallback on disconnect)
and the **palette "Controller" picker** (choice submenu, active pad ✓,
button events filtered to the active pad) are done, and the **D-pad**
maps onto the joystick axes (full deflection, wins over the stick).
Still open: custom button mapping, per-axis deadzone/calibration.
- **Keyboard-as-joystick** (S) — arrows/WASD emulating the stick with
configurable throw, for laptops without a controller.
- **Mouse-as-paddles** (S) — map mouse position to the paddle timers, the
classic way to play paddle games (and how a Koala Pad could be faked).
## Debugging tools
The REWRITE explicitly lists "a debugger" as never-implemented future work,
and AppleWin's symbolic debugger is the genre benchmark. **Planned**: the
minimal always-present slice of this section — WozBug, CPU breakpoints,
device-state commands, built-in symbols — has a plan in
`notes/DEBUGGING_TOOLS.md`; the bullets below remain the long-range
backlog beyond it.
- **Interactive debugger** (L) — pause-and-inspect: breakpoints (PC, memory
read/write watchpoints, soft-switch access), single-step / step-over, and
a disassembly view. *(infra: `ewm-core/fmt.rs` already disassembles; the
CPU is a clean step()-driven core; the palette overlay proves we can draw
UI panels over the emulated screen.)*
- **Memory viewer/editor** (M) — hex view of main/aux/LC banks with live
updates; AppleWin-style mini-views for the text/hires pages.
- **Soft-switch state panel** (S) — we already track every //e switch in
`IouE`; a debug overlay showing TEXT/MIXED/PAGE2/HIRES/80COL/ALTCHARSET/
RAMRD/RAMWRT/ALTZP/80STORE/DHIRES and the LC state would have shortened
several of our own investigations.
- **Symbol tables** (M) — load Merlin/LISA/`.sym` labels; ship built-in
symbols for the Monitor, DOS 3.3 and ProDOS entry points (AppleWin does).
- **Real measured MHz + cycle counters** (S) — replace the fake status-bar
MHz (REWRITE quirk #3) with the real measured rate; add a user cycle
counter (reset/read) for timing work.
- **Trace improvements** (S/M) — CPU tracing exists (`debug.trace` /
`--set debug:trace=…`); add address-range
filters, soft-switch access logging (we hand-rolled this repeatedly during
the //e work), and trace-to-ring-buffer with a palette "dump last 10k".
- **Disk activity inspector** (M) — current track/sector/bit position, head
movement log, nibble stream tap. Would have cut the WOZ protection
debugging time in half. *(infra: `Dsk::half_track()` was the seed.)*
## Command palette
Today: Reset, Pause, Full Screen, three CPU speeds. Cheap, high-value adds:
- **Disk operations** (S) — insert/eject/swap disks per drive with a file
picker; "Swap drive 1 ↔ 2" (the classic two-disk-game convenience);
show the mounted image names.
- **Save Screenshot** (S) — see Video above.
- **Monitor style & color scheme** (S) — runtime toggle instead of
the startup setting.
- **Save/Load State** (see next section) as palette entries.
- **Copy screen text** (S) — `text_screen()`/`text_screen_80()` already
produce exactly what "Copy Text Screen" should put on the clipboard.
- **Paste text** (S/M) — feed clipboard text through the keyboard latch
(respecting the strobe), like AppleWin/Virtual ][ paste; makes typing
BASIC listings from the web painless.
- **Machine info** (S) — a read-only panel: model, ROM hashes, mounted
images, switch states.
- **Game cheats** (M) — a "Cheats" palette submenu: pick "Hard Hat Mack —
more lives" and it pokes the right zero-page/memory locations (or patches
code) on the running machine. Backed by a small cheat database: per-title
TOML files (name, description, pokes `addr = value`, optional code
patches), matched to the mounted image by name or content hash, shipped
in-repo and user-extendable in the disk library. The 4am write-ups
document many of these addresses. *(infra: the bus makes pokes trivial;
the palette's per-open command registration means cheats can appear only
when a matching disk is mounted.)*
## Configuration & launch experience
The north star: **start `ewm` with no command-line options and fully use it
from there** — boot to the menu, configure a machine, insert disks, play.
Everything in this section serves that goal.
- **Machine config files** (M) — **landed**: see `notes/JSON_CONFIG.md`
— `ewm two --config myiie.json` with the committed
`schema/ewm-config.schema.json` covering every CLI and palette
setting; real slot flexibility (multiple Disk ][ controllers, empty
slots, cards in any slot); and the full source surface from
`plans/20260718-02-config-sources.md`: built-ins
(`--config builtin:apple2plus`), partial `--config-overlay` layers,
`--set`, `--print-config`. Remaining: "save current setup" from the
palette (JSON_CONFIG Phase C; the Options→Config mapping already
exists). Virtual ]['s configurable virtual machines remain the
reference.
- **Disk management** (M) — the full story, not just palette entries:
start with **no disks mounted**, then insert/eject/swap floppies and
mount HD volumes on the HDD card at runtime from the Command Palette
(file picker + recently-used list). Drive doors and image names in the
status bar. Ejecting flushes (once write support lands).
- **A disk library** (S/M) — a well-known images directory the pickers
default to (`~/Library/Application Support/EWM/Disks` on macOS,
`$XDG_DATA_HOME/ewm/disks` elsewhere; the repo's `disks/` as a dev
fallback), with recently-used tracking. Where downloads (next item) land.
- **Fetch from the Internet Archive** (M/L) — archive.org has a documented
JSON API (advanced search + per-item metadata endpoints, direct file
downloads), and the 4am collections ("Apple II Library: The 4am
Collection", the woz-a-day series) are exactly the WOZ images our bit
engine was built for. A palette flow — search archive.org, browse the 4am
collection, download into the disk library, insert into drive 1 — would
make EWM self-sufficient for software. (Respect rate limits; cache
downloads; surface item metadata/credits.)
- **Zero-flag startup** (theme) — with config files + disk management +
the library in place, the CLI becomes optional: `ewm` → boo menu →
pick/configure machine → insert disks from the palette. Tracks the
gaps blocking that flow.
## Save states & rewind
- **Save/load state** (L) — full machine snapshots (CPU, RAM/aux, devices,
disk position). AppleWin's `.aws.yaml` is the reference; EWM's flat,
`Rc`-free ownership model makes serialization unusually tractable.
Versioned format + a golden round-trip test.
- **Rewind** (M, after save states) — Apple2TS's "go back in time" feature:
a ring buffer of periodic snapshots with a palette "Rewind 5s". EWM's
determinism makes replay-from-snapshot exact.
- **Boot snapshots** (S, after save states) — `--resume <state>` to skip
the ~10s DOS boot during development and testing.
- **Quit & resume** (S, after save states) — persist across emulator
restarts: auto-save the machine state on exit (opt-in, per machine
config), restore it on the next launch — quit mid-game tonight, continue
exactly there tomorrow. Needs care with mounted-image paths moving
between runs.
## Automation & scripting
- **Embedded scripting** (M/L) — the original C EWM had Lua hooks
(dropped in the Rust port, listed as REWRITE future work): per-instruction
and soft-switch callbacks, machine control from scripts. Virtual ][ ships
AppleScript automation for the same reasons. Candidate runtimes below —
the owner is open to Lua but prefers something more static (TinyGo-ish).
### Embedded scripting: runtime options
Whatever the language, the real design work is the **hook API**, and it is
shared across all options: machine control (boot/reset/insert/key/screen),
memory peek/poke, soft-switch and I/O-access callbacks, and per-instruction
hooks (perf-sensitive — see the note below the table).
| Option | Crate | Typing | Notes |
|---|---|---|---|
| **Lua 5.4** | `mlua` | dynamic | The incumbent — closest to the original C EWM scripts. Mature bindings, tiny runtime, instant iteration (edit + rerun). |
| **Luau** | `mlua` (feature flag) | **gradual** | Roblox's typed Lua: type annotations + a real type checker, sandboxed by design, faster than stock Lua. The strongest "Lua, but more static" answer — same `mlua` API either way, so this choice can even be deferred. |
| **Rhai** | `rhai` | dynamic | Pure-Rust embedded language built exactly for this; zero C deps, painless `#[derive]`-style API binding, no `unsafe`. Weakest typing story. |
| **Rune** | `rune` | dynamic | Pure-Rust, Rust-flavored syntax, async-friendly. Similar trade to Rhai with nicer syntax, smaller ecosystem. |
| **Starlark** | `starlark` (Meta's) | dynamic, **hermetic** | Python-ish and *deterministic by construction* (no ambient I/O, reproducible) — a striking match for EWM's deterministic-test culture. Optional type annotations in the Meta implementation. |
| **WASM plugins** | `wasmtime` | **static — any language** | The TinyGo answer: EWM embeds a WASM runtime and defines a host API; scripts are compiled `.wasm` written in **TinyGo**, Rust, Zig, C, AssemblyScript… Real type systems and toolchains, strong sandboxing, near-native hook performance. Cost: a compile step per iteration (no REPL feel) and the host-API/ABI design (WIT or hand-rolled hostcalls), plus the heaviest runtime dependency of the table. |
| **TypeScript / JS** | `rustyscript` (deno_core) or `rquickjs` | static *authoring* (TS) | Typed developer experience, huge ecosystem. deno_core is a heavy dependency; QuickJS is light but plain JS. |
| **Gluon** | `gluon` | **static** (ML-family) | A genuinely statically-typed embeddable language — but a niche syntax and quiet maintenance make it a risky bet. |
Notes that cut across all of them:
- **Per-instruction hooks are the perf cliff.** At ~1M instructions/second,
calling into *any* scripting runtime per instruction hurts (WASM least,
interpreted Lua most). Mitigate in the host API: hooks register address
ranges / soft-switch filters and the emulator only calls out on matches —
the debugger's breakpoint machinery and this filter can be the same code.
- **Determinism:** scripts become part of a run's behavior; hermetic
runtimes (Starlark, WASM without WASI) keep scripted runs reproducible
and CI-able, which is very EWM.
- **They compose:** a plausible endgame is *two* tiers sharing one hook
API — Luau (or Rhai) for interactive poking, WASM for serious typed
plugins (a TinyGo-written debugger extension, a protection analyzer).
- **Recommendation shape:** if the old Lua feel matters, **Luau via
`mlua`** is the best of both (types + Lua compatibility + one crate). If
the static preference wins, **`wasmtime` + TinyGo/Rust plugins** — and
since the MCP server / control socket / expect-driver (above) already
demand the same host API, building that API first keeps every option
open.
- **Expect-style headless driver** (S/M) — our own tests already do
"boot, wait for text, type line, assert screen" (`two_dos.rs`,
`two_woz.rs`). Exposing that as `ewm two --script <file>` (type/wait/
screenshot/assert commands) would make it a user feature and a great
CI tool for *other people's* Apple II software.
- **Control socket / REPL** (M) — a simple line protocol (read/write
memory, key injection, screenshot) for driving a windowed instance from
outside; the automation counterpart of the debugger.
## Distribution & platforms
- **Native macOS app** (M/L) — **planned**: see `notes/MAC_APP.md` for the
four-phase plan (self-contained `EWM.app` with file associations →
signing/notarization → `.ewmachine` machine documents → a VMware-style
library app). Virtual ][ is the native-feel benchmark.
- **Raspberry Pi boot image** (L) — flash a card, power on, and the Pi *is*
an Apple ][+ / //e: a minimal Linux (or bare KMS/DRM console) image that
boots straight into the boo menu, from which you pick the machine — the
bootloader's original purpose, finally literal. Needs SDL on KMS without
X, GPIO-friendly shutdown, and the disk library on the card. (Appliance
cousins: RetroPie ships emulators this way.)
- **Hosted / virtual Apple //e** (L) — run the emulator server-side and use
it from a browser: boot instances from a small web UI, interact via VNC
or a web VNC client (noVNC). The headless core already runs without SDL;
the missing piece is a frame-buffer → RFB/WebSocket bridge plus keyboard
injection (which the control socket above provides). "Virtual Apple //e
hosting" — shareable, embeddable, demo-able.
- **WebAssembly build — EWM in the browser** (L) — compile the emulator to
WASM and run it entirely client-side: a canvas for the 560-wide frame,
Web Audio for the speaker, keyboard/gamepad events in, no server at all.
The cleanest "try EWM in one click", an embeddable widget for blog posts
("here, *play* the bug I'm describing"), the no-install path on mobile
Safari, and the zero-ops sibling of the hosted instances above. *(infra:
the `ewm-core` / frontend crate split already isolates SDL; the pure
`Scr` renderer and headless machines are WASM-ready as-is — the work is
a `wasm32` frontend crate and asset/file plumbing.)*
## AI
The headless core is unusually AI-friendly: deterministic execution,
`text_screen()`/`text_screen_80()` as ground-truth screen text (no OCR),
keyboard injection, and save states (once landed) as perfect episode resets.
- **MCP server** (M) — expose EWM to AI agents as tools: boot a machine,
insert a disk, type, wait-for-text, read the screen, screenshot, poke/peek
memory. Everything our own integration tests do, packaged for Claude and
friends — "load Hard Hat Mack and tell me how the protection works", or an
agent that plays Planetfall. *(infra: the expect-style driver and control
socket under Automation are 90% of this; MCP is a thin protocol layer.)*
- **AI debugging assistant** (M) — feed the trace ring buffer, disassembly,
and soft-switch log to an LLM to explain what the machine is doing —
literally how the E7 protection and the //e lowercase bug were cracked
during EWM's own development, productized.
- **Cheat finder** (M) — diff memory snapshots across "lost a life" events
to locate lives/score counters automatically, then emit a cheat-file entry
(see Game cheats). Classic Cheat-Engine flow; determinism plus snapshots
make it reliable, and an LLM can name/describe what it found.
- **BASIC copilot** (S/M) — prompt → AppleSoft BASIC → auto-pasted through
the keyboard latch and run; the screen scrape closes the loop for
self-correction. A lovely demo of paste + scripting + AI in one.
- **RL / game-playing harness** (M/L) — frame buffer + joystick as a gym
environment; deterministic stepping and snapshot resets are exactly what
RL wants and real hardware can't give.
## Cloud & web
Extends "Hosted / virtual Apple //e" under Distribution; the client-side,
no-server counterpart is the **WebAssembly build** there.
- **Cloud disk library & save-state sync** (M) — the disk library and
quit-&-resume states in S3/iCloud; start a game on the desk, resume it
anywhere. Pairs with the Archive.org fetcher.
- **Shareable replays** (M) — determinism means a session is fully defined
by (config, images, timestamped inputs): record tiny replay files,
share a link, the server re-executes into video or a live view. Demo
captures, bug reports, and speedruns all fall out of one feature.
- **Spectator mode / pass-the-controller** (M/L) — one instance, one
driver, N viewers over the RFB/WebSocket fan-out; hand the keyboard to
another viewer. Retro game night, remote demos, teaching.
- **Emulation API service** (M) — the control socket as a hosted REST/WS
API: POST a disk image, drive it, get screenshots/screen text back.
CI-for-Apple-II-software as a service; the expect-style driver is the
local version of the same contract.
## Mobile
- **iPad / iPhone app** (L) — App Store rules now allow retro emulators
(2024's policy change; Delta et al.). Touch keyboard overlay with the
//e layout, tap-to-insert disks from the Files app / disk library,
MFi + Bluetooth gamepads, external keyboards. The SDL frontend would be
replaced by a small native shell over `ewm-core` — the crate seam again.
- **Touch & motion controls** (M, after the app) — drag = paddle, virtual
stick overlay, tilt-as-joystick for Choplifter.
- **Handoff** (S, after cloud sync) — quit on the Mac, resume the same
state on the iPad via the synced save states.
- *(The WASM build is the no-install mobile fallback: EWM in mobile
Safari with a touch keyboard, zero App Store involvement.)*
## Apple Watch (yes, really)
Not the emulator *on* the watch — the watch as the world's smallest Apple II
peripheral, talking to a Mac/hosted instance:
- **Digital Crown = paddle** (M) — the crown is a rotary encoder and Apple
paddles were rotary knobs; this is the most faithful paddle controller
Apple has shipped since 1983. Breakout on a //e, controlled from the
wrist. *(infra: paddle injection already exists via `set_joystick`; this
is a WebSocket bridge + a tiny watch app.)*
- **Status complication** (S, after hosted instances) — your cloud //e's
drive light and MHz on a watch face; tap to peek at the text screen
(40×24 fits a watch better than most modern UIs).
- **Wrist notifications** (S) — the speaker BELL or a finished long-running
BASIC program pings your wrist: "your //e wants attention."
## References
- [AppleWin](https://github.com/AppleWin/AppleWin) — debugger, save states,
NTSC/RGB video, Mockingboard/Phasor/SAM + SSI263, Uthernet I/II, RamWorks,
VidHD, CP/M SoftCard.
- [Virtual ][](https://www.virtualii.com/) — ImageWriter/Epson printing to
PDF, cassette tape, AppleScript scripting, mouse, Z80, configurable
machines.
- [MAME Apple II driver](https://wiki.mamedev.org/index.php/Driver:Apple_II)
— breadth of peripheral cards, Z80 SoftCard, accuracy reference.
- [izapple2](https://github.com/ivanizag/izapple2) — FujiNet, RamWorks,
VidHD signature, Z80, portable Go design.
- [Apple2TS](https://apple2ts.com) — rewind ("go back in time"), on-demand
state saves, RamWorks.
- EWM's own future-work lists: `REWRITE.md` (Lua, disk writes, debugger,
real MHz), `APPLE_IIE_ENHANCED.md` (//c, NMOS //e), `WOZ1.md` (WOZ 2.0,
13-sector, protection stragglers), `DHGR_COLOR_EXPERIMENT.md` (sliding
window promotion).