An NES emulator written in Rust
- The default workspace developer path (
cargo build,cargo test) now coversnerust_core,nerust_persistence, andnerust_console. - Their in-workspace dependencies still build transitively, but GUI frontends, backend-specific crates, and ROM tooling are now validated with explicit package commands.
cargo test -p nerust_core persistence_tests --lib
cargo test -p nerust_console --lib
cargo test -p nerust_persistence --libRun support-crate unit tests explicitly when touching cartridge parsing, filters, buffers, or timing:
cargo test -p nerust_cartridge_data --lib
cargo test -p nerust_screen_buffer --lib
cargo test -p nerust_screen_filter --lib
cargo test -p nerust_timer --libRun ROM tooling and generated regression tests explicitly when touching manifest, tooling, or ROM-test behavior:
cargo test -p nerust_rom_testRun frontend and backend validation explicitly when touching OpenGL or UI code:
cargo test -p nerust_screen_opengl --lib
cargo test -p nerust_gui_runtime --lib
cargo build -p nerust_gtk --release
cargo build -p nerust_tao --release- Cargo
- Rust
- GTK 4.0 or greater
cargo build -p nerust_gtk --releasetarget/release/nerust_gtk- Cargo
- Rust
- Linux では GTK3 開発パッケージ (
libgtk-3-devなど)
cargo build -p nerust_tao --releasetarget/release/nerust_tao [Rom File Path]引数なしで起動して File -> Open から ROM を開くこともできます。
ROM regression cases are defined in core/rom_tests.yaml, with
NESdev-style categories and short descriptions for each case.
# Validate configured ROM cases, print per-case progress,
# and write an HTML report to target/rom-tests/validate/
cargo run -p nerust_core --features rom-tooling --bin rom_tool -- validate
# Capture actual hashes/screenshots with the same progress output
cargo run -p nerust_core --features rom-tooling --bin rom_tool \
-- capture --case cpu.nestest
# Benchmark perf-enabled ROM cases from the shared manifest
cargo run -p nerust_core --features rom-tooling --bin perf --release -- \
--case cpu.nestestnerust_coreownsPERSISTENCE_SCHEMA_VERSION,MachineStatePayload,MapperSavePayload, and the nestedRomIdentity/CoreOptionschecks used during import.nerust_consoleownsCONSOLE_STATE_SCHEMA_VERSION,ConsoleStatePayload,ControllerStatePayload, and thepaused/frame_counter/source_framewrapper fields around opaque core state bytes.nerust_persistenceownsSTATE_ARCHIVE_SCHEMA_VERSION,StateArchiveMetadata, archive entry names, slot filtering, and thumbnail presence/blob handling;state.binremains opaque console state.- Nested payloads without their own version are covered by the
nearest owning outer schema version. For example, changing
controller representation bumps
CONSOLE_STATE_SCHEMA_VERSION, while changingRomIdentityorCoreOptionscomparison semantics bumps the owning core/archive schema and corresponding reject/filter tests. - Field addition, removal, type changes, or meaning changes that affect accepted bytes are schema changes. Bump the owning version constant before refactoring those fields.
- After merge to
master, payloads produced by the shipped schema versions must not break silently. Either keep them loadable with explicit compatibility tests, or intentionally reject them behind a version bump with explicit reject tests.
Schema change workflow:
- Identify the owning layer (
core,console, orpersistence). - Decide whether the change alters accepted bytes, target comparison, or archive interpretation.
- Bump the owning schema version when compatibility changes.
- Update the representative fixtures plus compatibility/reject tests for that layer.
- Confirm how previously shipped
masterpayloads are handled before starting the refactor.
- NRom (Mapper 0)
- MMC1 SxRom (Mapper 1)
- UxRom (Mapper 2)
- CnRom (Mapper 3, Mapper 185)
- MMC3 / MMC6 (Mapper 4)
- MMC5 (Mapper 5)
- AxRom (Mapper 7)
- BnRom (Mapper 34)
- NINA-001 (Mapper 34)
- TxSROM (Mapper 118)
- Load & Save
- Android support
- Other Mappers
- Network multiplay