HotelMarioRecomp

Hotel Mario (USA) running as a native Philips CD-i build on the sibling cdirecomp static-recompilation engine.

⚠️ Very early development

This is a research preview. The real CD-RTOS BIOS boots, the player shell opens the disc, the Philips Interactive Media bumper plays with decoded XA audio, and normal-speed input has cleared Hotel 1 Stages 1–3, reaching Stage 4. Intro transitions and repeated death/restart paths now work in recorded probes. Full campaigns, bosses, ending and correct save restoration remain unverified. Expect rough edges and breaking changes.

_{Hotel Mario reaching its title card through the real recompiled BIOS — booted through the real CD-i system ROM.}

Recorded progress — 2026-10-09

• Early gameplay: the indexed LLE build cleared the first three Hotel 1 stages through ordinary input. A separate seeded two-player build reached Stage 3 for Mario and Stage 5 for Luigi. Both full campaigns remain open.
• Owner playtest: basic gameplay and the title-screen background are reported working well. Minor visual flickering remains, tracked as beads-ssy9.1; its cause has not been investigated.
• Checks: six compiler and eleven runtime component checks passed. The latest default build passed 30/30 headless cold boots. The preceding build passed 30/30 windowed boots; both latest windowed batches ended early and remain failed.
• Attract and audio: three complete attract circuits are not certified. The latest DirectSound run ended before its required capture; older long runs lost coverage evidence. Long gameplay also recorded dummy-output PCM drops. Audio listening and sustained performance checks remain open.
• Saves: a named original-game save survived a normal close and cold boot. Restoring the correct active stage still needs validation.
• Fresh builds: v0.0.2 Windows x64 ZIP and Linux x86_64 AppImage include the indexed coverage fix. Both passed packaging audits and short normal-speed boots to the exact title screen; all 17 Linux component tests passed. See build notes for artifacts, identities and validation limits.
• Checkpoint: implementation and campaign probes are paused. Full playthrough certification remains open; these packages are development previews.

See ISSUES.md and the engine's detailed validation ledger for exact build identities, evidence locations and untested behavior.

How it works

This repo is thin. It contains only game-specific build glue, identity metadata, and acceptance tooling — it builds the cdirecomp runtime with a Hotel-Mario-specific product identity and asset contract. It does not contain a CD-i BIOS, any Hotel Mario disc data, generated game code, or any emulator/tooling forks. All of the interesting work lives in cdirecomp, whose philosophy is low-level, static, native-first: the whole CD-RTOS system ROM is recompiled and executed as native C (no OS-9 HLE), and the game boots on top of it exactly as on hardware.

What you must supply

You provide both, from your own legally dumped media (see DISC.md for the verified identities):

1. A 512 KiB CD-i player BIOS (cdi490a.rom).
2. A Hotel Mario (USA) raw Mode-2 .cue + .bin image (select the .cue).

The runtime validates the exact generated BIOS identity and disc format at startup. Loaded native modules must match their complete image SHA-256; the entire disc's identity is recorded by acceptance tooling. Neither asset is embedded in the executable.

Building & running

Place this repo beside cdirecomp:

Projects/
├── cdirecomp/
└── HotelMarioRecomp/

Requirements: CMake, Ninja (or another generator), a C11 compiler, and SDL2.

./tools/build.ps1 -Disc "path/to/Hotel Mario (USA).cue"
./tools/launch.ps1    # first run asks for the BIOS + disc, then remembers them

The first launch saves the chosen paths in git-ignored bios.cfg / disc.cfg sidecars; later launches reuse them.

Generate the BIOS in the sibling engine first, using its documented CdiRecompBios workflow. build.ps1 -Disc generates all distinct executable OS-9 modules before building the product. Generated code remains local. -ModuleSeeds optionally adds image-bound callbacks observed during real execution and exported by the engine's collect_module_seeds.py; this is offline static recompilation. No HLE replacement is enabled.

Linux uses the same generated BIOS/modules and LLE runtime. After generating the sources with the matching BIOS and USA disc, build and package on an x86_64 Linux host with CMake, Ninja, a C11 compiler and SDL2 development files:

BUILD_JOBS=4 sh tools/build-linux.sh
VERSION=0.0.2 sh tools/package_appimage.sh

The package scripts follow the TombaRecomp Windows ZIP/Linux AppImage workflow. The experimental Linux baseline is Ubuntu 24.04; its AppImage contains the runtime and SDL2 dependencies, while assets and writable player state remain outside. See RUNTIME-README.md for launch instructions. Both package formats are development previews and retain the playthrough limitations above. Packaging tasks are beads-ssy9.2 and beads-ttbl.2.

Controls: on Windows the mouse controls Hotel Mario directly — it drives the CD-i pointer and both buttons through the recompiled runtime's input model, in-game as well as in the shell. Arrows/WASD also move the pointer; Enter/Space/Z is button 1; Backspace/X is button 2; F11/Alt+Enter toggles fullscreen; Esc exits.

Acceptance gate

With your own BIOS and disc:

./tools/accept-attract.ps1 -Bios path/to/cdi490a.rom -Disc path/to/HotelMario.cue

It enters through the real player-shell input path and checks the pixel-exact title, populated intro planes, clean bumper/intro XA audio with zero drops, expected disc progress, zero native dispatch misses, and real-time field pacing. See ISSUES.md for the intentionally narrow current certification.

License

PolyForm Noncommercial License 1.0.0 — © 2026 Matthew Stan. Covers this repository's build glue and tooling only. It grants no rights to Nintendo, Philips, or any other third-party intellectual property; you must supply your own legally obtained BIOS and disc image.