There is a quietly-impressive amount of dead tooling around retro consoles. Half-finished disassemblers behind dead SourceForge pages. Editors that only run on a 2008 Windows VM. Emulators with a custom installer that asks for your hard drive. hexenwerkzeug is a place to finish those tools, in a browser tab.
What's in scope
The first wave focuses on the consoles whose communities are big enough to support real work but small enough that nobody's shipping polished browser tools for them today:
| Platform | First workbench |
|---|---|
| Super Nintendo (SNES / 65C816) | ROM disassembler · WLA-DX integration · SPC700 audio viewer |
| Nintendo 64 (MIPS R4300i) | byte-true recompiler · texture / DList browser · symbol map editor |
| Nokia N-Gage (Symbian / ARM) | Metal Gear Solid: Mobile reverse-engineering kit |
| Sega Saturn / Dreamcast (SH-2/4) | ISO inspector · SH executable disassembler |
| MS-DOS / x86 | DOS executable explorer · DOOM-era WAD tools |
The contract
Three rules, non-negotiable:
- No install. A web page, a tab, your bytes in it.
- No binaries. Runtimes ship as WASM, served as static assets.
- No sign-in. Files come from drag-drop / File System Access; state stays in IndexedDB.
The UltraHLE moment
On January 27, 1999, two programmers going by Epsilon and RealityMan uploaded a 600 KB executable called UltraHLE. It ran Super Mario 64 on a Pentium II at playable framerates. The N64 was still a current-generation console — The Legend of Zelda: Ocarina of Time had only been on shelves for nine weeks — and now its biggest titles were running on a PC. Conventional wisdom said proper N64 emulation would take a decade. UltraHLE did it in a bedroom, and the binary was 600 KB.
The trick was a category change. Instead of decoding every MIPS R4300i instruction the N64 CPU runs, UltraHLE intercepted the high-level library calls the games made through libultra — Nintendo's own SDK. When a game asked the N64's RSP to draw a textured triangle, UltraHLE didn't simulate the RSP. It drew the triangle with OpenGL on the PC's GPU. Whole layers of CPU work evaporated. It was lossy, game-specific, and aggressively pragmatic — and that's exactly why it ran on a 1999 PC when cycle-accurate N64 emulation would take twenty more years to even begin to look credible.
The release itself was a flashpoint. Nintendo's lawyers were on the project within hours; the original distribution page was down within days. The binary survived anyway, the way binaries do — mirrored on a hundred FTPs, traded over IRC and Hotline, spread to bedrooms full of kids who watched their cartridges run on a friend's computer and quietly recalibrated their entire model of what software was allowed to do. That's the moment this site is named for. Hexenwerkzeug — witchcraft — was the only honest word for it.
Ocarina of Time on that early UltraHLE was real but rough: title screens and the opening areas ran with graphical artifacts in v1.0.0, with later patches cleaning up the worst of it. Anyone who saw both Mario 64 and OoT on a PC in early 1999 wasn't imagining it — they were watching the front edge of the HLE wave land at home.
UltraHLE lit the fuse. Project64 (1999), Mupen64 (2002), and a long tail of accuracy-first emulators came in its wake. The HLE instinct has aged interestingly: N64Recomp (2024) static-recompiles N64 ROMs into native x86 binaries that run faster than the original hardware. Same trick, twenty-five years on — intercept high, regenerate as native code, skip the cycles the silicon used to spend.
hexenwerkzeug is, at its core, a project to bring that feeling back — to ship tools so improbable for a browser tab that the first time you drop a 4 MB ROM and it just… works, you double-check the URL bar.
A chronology of the witchcraft
Three decades of public emulator releases, the consoles they cracked open, and the trick each one pulled. The hero timeline up top hits the headline beats; the table below fills in the ones that hovered just under the headline but moved the scene forward anyway.
| Year | Project | Platform | What it unlocked |
|---|---|---|---|
| 1996 | NESticle | Nintendo / NES | First widely-available DOS emulator that ran real-time NES games on a Pentium. Bloodlust Software's irreverent shareware turned NES preservation from theoretical to playable. |
| 1997 | ZSNES | Super Nintendo | Sub-frame-accurate enough to run Chrono Trigger and Final Fantasy VI. The PC suddenly had a better SNES than your SNES had. |
| 1997 | MAME 0.1 | arcade hardware (all of it) | Nicola Salmoria's framework chose preservation over playability. Game-by-game ROM dumps + cycle-faithful drivers = the only reason a 1985 arcade board still boots in 2026. |
| 1999 | UltraHLE | Nintendo 64 | High-Level Emulation of libultra calls. The N64 went from "a decade away" to "runs Mario 64 on a Pentium II" in one upload. Section above has the full story. |
| 2000 | ePSXe | Sony PlayStation | First PSX emulator to run a real swath of the library at full speed with plugin-clean audio/video. The CD-image era began here. |
| 2001 | VisualBoyAdvance | Game Boy / GBC / GBA | One emulator covering Nintendo's whole handheld lineage. Save states + breakpoints made it a debugging tool, not just a player. |
| 2003 | Dolphin | GameCube (later: Wii) | Started as a GameCube target; Wii support followed in 2008. Open-source from day one, which is why it's still actively developed twenty-three years on. |
| 2004 | bsnes | Super Nintendo | byuu's accuracy-first SNES emulator. Slower than ZSNES on purpose — the goal was to match the silicon, not to play fast. The lineage that became higan + bsnes-hd. |
| 2008 | PCSX2 0.9.6 | Sony PlayStation 2 | The release that took PS2 emulation from "runs the BIOS" to "runs Shadow of the Colossus." Compatibility leap of the decade. |
| 2009 | JSNES | Nintendo / NES (browser) | Ben Firshman's JavaScript NES emulator. The web platform's first credible "actually plays NES games" demo — and the proof point for everything in this hexenwerkzeug bet. |
| 2010 | higan | multi-system (cycle-accurate) | byuu's umbrella for SNES + Game Boy + Game Boy Advance + Famicom + Mega Drive accuracy cores. Coined the term preservation-grade for emulators. |
| 2017 | EmulatorJS | multi-system (browser) | Web frontend around libretro cores compiled to WebAssembly. Internet Archive runs on top of this — "play this 1986 arcade ROM in your browser" became a one-line embed. |
| 2024 | N64Recomp | Nintendo 64 | Static-recompile a N64 ROM to a native x86 binary. Zelda 64: Recompiled ships a Windows EXE built from the original cartridge bytes and runs faster than the N64 ever did. |
| 2026 | hexenwerkzeug | this site | Drop a ROM into a browser tab, get a workbench. No install, no binaries, no sign-in. The bet: the web platform is ready to host the next decade of preservation tooling. |
Why JavaScript, not WebAssembly (yet)
The default 2026 advice for “serious browser tooling” is to compile a C / Rust / Zig core to WebAssembly and call into it. We're not doing that — at least not first. Reasons:
- Readability. A disassembler written in plain JavaScript can be read by anyone who knows JS. A wasm blob is opaque. The open-source spirit lives in code you can read, fork, and re-glue on a Sunday afternoon.
- The WASM ↔ DOM boundary. Wasm runs in a sandbox; every interaction with the page (drawing a byte into the hex view, rendering a tree node) marshals through a JS shim. For workbench-style tools that read a file and paint UI, the round-trip cost is real. JS-native code skips the boundary entirely.
- V8 is a real compiler. Modern V8 tier-ups (Ignition → Sparkplug → Maglev → TurboFan) produce code that's surprisingly close to native for monomorphic hot loops. Take advantage of inline caches, hidden classes, and the
%directives (--allow-natives-syntax) and you get to watch the JIT work in slow motion. - Honest accounting. The right answer to “is wasm worth it?” isn't a vibe — it's a benchmark next to a working JS version. So we'll build the JS version first, push it hard, then decide where the WASM fallback is genuinely earning its keep.
Next up on the rabbit-hole list: a V8 compiler explorer — drop a function, see the bytecode, the Sparkplug code, and the TurboFan output side by side. Tweak it until the JIT settles. Join in.
Roadmap
- SNES workbench at /snes-wb — already running. 65C816 superset of the 6502 highlighter is next.
- MIPS R4300i flavor for the N64 disassembler.
- ARM-THUMB flavor + SIS unpacker for the N-Gage kit.
- SH-4 + GD-ROM parser for Dreamcast.
- Public field-notes here on every reverse-engineering rabbit-hole the team falls into.
Want a specific console?
Half the value of a project like this is picking the right first targets. If the SNES / N64 / N-Gage list above doesn't include your itch — Saturn? Jaguar? Master System? GBA? — say so and it goes on the board.