feat(cartridge): add 32 KiB SRAM save memory

Select it with --save-type sram (SaveDevice::Sram). The array is byte-wide,
starts erased, and repeats every 32 KiB through the 0x0e00xxxx save window.
A CPU byte store is staged and committed when its step completes, so failed
steps roll back and reads later in the step see the byte. Unlike Flash, SRAM
can be read from ROM code. Halfword/word access and DMA stay diagnostic until
the 8-bit bus behavior for those widths is verified.

SRAM shares the save-image API, host save files, and save states. Its device
code is new, so existing save states keep loading.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HhfHfHEuzv2AUTd6erW1gU

docs/architecture.md

@@ -50,6 +50,8 @@ The repository is a Cargo workspace with three crates:
 | `crates/gba-core/src/cpu/instruction_tests.rs` | Register operations, transfers, branches, and edge cases |
 | `crates/gba-core/src/cartridge.rs` | Explicit GPIO/RTC selection, ROM read overlay, pin directions, caller-clock routing, and bounded diagnostics |
 | `crates/gba-core/src/cartridge/flash.rs` | Explicit save devices, Macronix IDs/banks, delayed program/erase, bounded DQ7 polling, and staged mutations |
+| `crates/gba-core/src/cartridge/sram.rs` | 32 KiB byte-wide SRAM, mirrored offsets, one staged byte per step, and its save-state section |
+| `crates/gba-core/tests/sram.rs` | SRAM selection, mirroring, byte stores/loads from ROM code, SWPB, width/DMA diagnostics, and save states |
 | `crates/gba-core/tests/flash.rs` | Erased/supplied images, chip IDs, all bank addresses, invalid commands, reset limits, DMA rejection, and RTC independence |
 | `crates/gba-core/tests/flash_write.rs` | Program values, sector/chip scopes, delays, polling, cancellation, bit transitions, and HALT/STOP |
 | `crates/gba-core/src/memory/flash_write_tests.rs` | Store-phase start, completion overlays, dirty-state rollback, and speculative clock isolation |

docs/hardware/cartridge.md

@@ -35,7 +35,7 @@ Reads past supplied cartridge bytes remain explicit memory errors, not open-bus
 All three Game Pak ROM windows use the same supplied bytes and existing wait-state rules.
 Ordinary cartridge bytes remain read-only. CPU and DMA writes to the `0x08`–`0x0c` ROM windows pay their bus cost and are ignored, as on hardware.
 Writes to the `0x0d` window remain `ReadOnly` diagnostics until EEPROM is modeled there. Host `Memory::write*` calls stay strict everywhere.
-Optional `--save-type flash64` or `--save-type flash128` enables [nominal Flash programming, erase, and reads](saves.md).
+Optional `--save-type flash64` or `--save-type flash128` enables [nominal Flash programming, erase, and reads](saves.md); `--save-type sram` selects [32 KiB SRAM](saves.md#sram).
 Without `--save-file PATH`, changes remain volatile. With it, the frontend loads an exact-size image and persists changes on clean exit or when a ROM window ends on a diagnostic.
 Missing images start erased. Existing images receive unique backups before replacement; incomplete Flash operations refuse persistence.
 Read the [storage safeguards and limits](saves.md#desktop-persistence) before using a valuable save.

docs/hardware/saves.md

@@ -1,14 +1,15 @@
-# Cartridge Flash and save files
+# Cartridge Flash, SRAM, and save files
 
 The core supports explicit Macronix Flash selection, identification, bank selection, byte programming, and sector/chip erase.
 Operations complete after nominal delays and expose bounded data polling. They do not complete immediately on the command write.
 The desktop can load and persist raw images through explicit `--save-file PATH` selection.
 Original ROM tests verify save/restart/load across processes. Saving in an external game remains unverified.
-SRAM, EEPROM, and other manufacturers' protocols remain separate work.
+The core also supports explicit 32 KiB SRAM; see [SRAM](#sram).
+EEPROM and other manufacturers' Flash protocols remain separate work.
 
 ## Selection and core API
 
-Use `--save-type flash64` or `--save-type flash128` in terminal or window ROM modes.
+Use `--save-type flash64`, `--save-type flash128`, or `--save-type sram` in terminal or window ROM modes.
 Selection is independent of `--rtc`. Omitting the save type leaves save memory unmapped.
 No filename, ROM signature, or first-write detection changes the selected device.
 Without `--save-file`, the selected device starts erased (`0xff`) and all changes remain volatile.
@@ -16,7 +17,7 @@ The ROM suite schema still has no save-selection or save-file field.
 
 Core APIs on `Memory`:
 
-- `set_save_device(SaveDevice)` selects `None`, `Flash64`, or `Flash128` and initializes an erased array.
+- `set_save_device(SaveDevice)` selects `None`, `Flash64`, `Flash128`, or `Sram` and initializes an erased array.
   GPIO/RTC state is preserved.
 - `load_save_image(&[u8])` accepts exactly the selected capacity. It resets commands, pending operations, ID mode, bank, and modification tracking.
   Invalid size or missing hardware changes nothing.
@@ -29,6 +30,16 @@ Configuration, loading, and host inspection occur between machine steps.
 The core has no file, clock, window, or host-audio dependency. Frontends supply image bytes and own durable storage.
 A browser frontend can use the same API with browser storage instead of filesystem paths.
 
+## SRAM
+
+`SaveDevice::Sram` is a 32 KiB byte-wide array with no command protocol. It starts erased (`0xff`) like Flash.
+The 32 KiB array repeats twice through the `0x0e000000..0x0e00ffff` save window; higher addresses stay unmapped.
+CPU byte stores take effect when the instruction's step completes. Reads later in the same step already see the new byte.
+Byte stores and loads may execute from ROM; the Flash work-RAM read restriction does not apply.
+Halfword and word reads and writes, and DMA transfers, remain diagnostics until 8-bit bus behavior for those widths is verified.
+SRAM shares the save window's WAITCNT wait states, save-image API, host persistence, and save states with Flash.
+A save state records the selected device. Restoring it into a machine with another save device is rejected as a cartridge setup mismatch.
+
 ## Bus and commands
 
 Only `0x0e000000` through `0x0e00ffff` are mapped. Accesses are byte-only.

docs/status.md

@@ -82,6 +82,7 @@ Update this file when a feature lands or a limit is removed.
 - Cartridge GPIO and Flash controller changes participate in CPU/DMA rollback and block-store preflight without modifying ROM bytes.
 - Explicit Macronix Flash64/Flash128 identification, bank selection, delayed byte programming, sector/chip erase, and nominal DQ7 polling.
 - Transactional Flash completion and modification tracking, with exact-size core image loading and inspection.
+- Explicit 32 KiB byte-wide SRAM (`--save-type sram`), mirrored through the save window and readable from ROM code.
 - Optional desktop `--save-file` loading and clean-exit persistence, with exclusive locks, atomic installation, and unique previous-image backups.
 - Original ROM save/restart/load checks across processes, including native-window persistence on Darwin arm64.
 - Whole-machine [save states](hardware/save-states.md): `Machine::save_state`/`load_state` with image and cartridge identity checks, a checksum, and verify-before-mutate loading; ROM windows bind F5 (save) and F9 (load) to a `--state-file` slot.
@@ -155,7 +156,7 @@ Individual fetch timing, hardware-accurate work cutoffs, video-bus contention, a
 ROM windows offer opt-in Darwin audio output with `--audio` and explicit save persistence with `--save-file`.
 The [Flash subset](hardware/saves.md) supports programming and erase with nominal delays and bounded DQ7 polling.
 Flash timing, STOP clocking, and cancellation are not hardware-verified. Wider accesses and unverified busy addresses remain diagnostic.
-SRAM, EEPROM, other manufacturers, autosave, crash recovery, and game-level save transactions remain unsupported.
+EEPROM, other Flash manufacturers, SRAM halfword/word access, autosave, crash recovery, and game-level save transactions remain unsupported.
 Persistence is tested on Darwin arm64 with original programs, not yet with external-game saves.
 The optional [cartridge GPIO/RTC subset](hardware/cartridge-gpio.md) supports calendar/control transfers and explicit clock updates, selected with `--rtc` in ROM modes.
 RTC persistence, interrupts, invalid-date correction, physical subsecond timing, GPIO aliases, and byte writes remain unsupported or unverified.

docs/usability-roadmap.md

@@ -69,7 +69,7 @@ Next implementation steps:
    Use original regressions for any hardware correction; do not invent connected serial devices.
 2. Validate an external game's completed save/restart/load cycle using a disposable `--save-file` path.
    Refine nominal Flash timing and polling only with independent evidence and original regressions.
-3. Add SRAM separately when the independent candidate requires it; verify widths, mirroring, and waits first.
+3. Byte-wide 32 KiB SRAM is now available with `--save-type sram`. Halfword/word SRAM access stays diagnostic until verified.
 4. Resume the second-game run and implement demonstrated audio requirements rather than accepting writes without behavior.
 
 ## Development loop