Deferred Features

Deferred Features

An honest running list of what Rusty2600 explicitly does not do — either permanently, by scope decision, or temporarily, pending a specific real-world blocker clearing. Distinguishing these two categories matters: some items on this page will never close no matter how many future releases ship; others are waiting on one concrete thing (a Mac toolchain, an upstream crate publishing a real release, live cloud credentials).

Permanently out of scope

These are scope decisions, not gaps waiting to be closed by more engineering effort:

• Cheat-code (Game Genie-equivalent) system — no meaningful historical Atari 2600 analog existed, unlike consoles that had real commercial Game Genie products.
• Zapper / light-gun peripheral modeling — extremely rare historical peripherals with negligible real-world software support.
• Four-Score-style 4-player multitap — 2600 hardware itself never supported more than 2 controller ports; there's no analog to build.
• Cart header/info parsing in the iNES style — 2600 .bin/.a26 images have no header structure analogous to iNES; cart/mapper metadata display is scoped to what detect() itself resolves, not header parsing that doesn't exist for this console.
• Chasing an open-ended mapper-number count — the Cart-Catalogue is a small, closed, fully-known set, already complete at 26/26. There is no larger number to chase the way an open mapper registry would require.

Researched and declined

• 2600 keyboard controller / Trak-Ball peripherals — researched as a real question, not skipped by assumption. Concluded not worth modeling: genuinely obscure historical peripherals with a vanishingly small commercial-software footprint.

Permanently blocked by external constraints

• Full TIA/RIOT test-ROM corpus conformance. No freely-redistributable 2600-specific TIA/RIOT test-ROM corpus exists anywhere — researched twice, confirmed by Gopher2600's own README making the identical admission. See Testing-Strategy for how accuracy work continues anyway, via differential-oracle cross-checking against known-hard commercial titles.
• HBLANK-region collision detection. Real hardware's collision-detection logic runs continuously regardless of HBLANK blanking; Rusty2600's collision evaluation is currently scoped to the visible 0–159 pixel window only. A real, if obscure, hardware behavior some advanced homebrew reportedly exploits as an invisible timing signal — deliberately deferred rather than rushed, since fixing it risks the already-verified visible-window positioning logic. See TIA.
• The 2600's exact TIA audio-clocking model for AUDC modes 0xA/0xB. Investigation found the classic simplified 16-entry lookup table (the model most emulators, including this one, historically use) doesn't match what Stella's current source actually implements for two of the sixteen distortion modes — the real hardware splits AUDC's bits into two independent phase-clocked counters at four fixed color-clock positions per scanline, not a simple per-tick lookup. Fixing this needs a dedicated audio-clocking rearchitecture, not a two-entry patch — tracked as real future work, not silently ignored.

Blocked on an upstream milestone

• In-browser Lua scripting. mlua's native backend cannot target wasm32-unknown-unknown at all (a hard wall in its vendored C build). The intended pure-Rust fallback, piccolo, was investigated for real and found not yet workable: its only published release is missing most of Lua's string/table standard library, and its gc-arena-based architecture is a genuine mismatch for this project's current VM-embedding shape. Revisit once piccolo publishes a release with real stdlib coverage — an upstream milestone this project doesn't control the timing of. See Scripting-Engine.
• Native (non-browser) WebRTC netplay. Browser-to-browser was always the primary target; a native path stays explicitly deferred. See Netplay-and-Rollback and Architecture-Decision-Records ADR 0008.

Blocked on environment access

• iOS Xcode/Simulator/device verification. The iOS app is source-complete but has never been compiled or run — this development environment has no Mac toolchain at all. Not closeable by more release planning; needs a real Mac session. See Mobile-and-Cross-Platform.
• Real physical Android hardware verification. Only an Android emulator has been available so far; genuine physical-device or cloud-device-farm verification remains open.
• Cloud save-state sync (Android/iOS). The concrete reference implementations (CloudKit on iOS, Google Play Games Services v2 Snapshots on Android) are documented, but both need live backend credentials this development environment doesn't have.
• Cross-machine / cross-NAT netplay verification. STUN's request/response round trip and WebRTC's connection-establishment code path are both proven against real infrastructure, but full traversal between two independently-NATed peers on two different real networks has not been verified end-to-end — a single-host sandbox structurally cannot provide that test.

Open research questions

• The PAL visible-line budget (192 vs. 228 lines) is flagged pending a PAL test ROM to confirm definitively.

See also

Testing-Strategy · TIA · Scripting-Engine · Netplay-and-Rollback · Mobile-and-Cross-Platform · Roadmap