Fixing the Site's Soft Navigation
July 2, 2026
This site swaps page content in place instead of doing a full reload for local links — faster, and it keeps the crossfade transition working. The old implementation cut a few corners though, and today's update fixes them.
Modified clicks now fall through to the browser instead of being hijacked. Cmd/Ctrl/Shift/Alt-click, middle-click, and right-click all behave normally, so opening a link in a new tab still works. Same-page hash links are left alone too; only cross-page links carrying a hash get intercepted, and those now scroll to the matching heading once the swap finishes.
Clicking through several links quickly used to race: whichever fetch happened to finish last would win, even if it wasn't the last thing clicked. Navigation now carries an incrementing token plus an AbortController, so only the most recent click's response is ever applied and the superseded request gets cancelled outright.
Back and forward now restore scroll position instead of snapping to the top of the page, with the browser's own automatic scroll restoration turned off so the two mechanisms don't fight each other. After a swap, focus moves to the new content and a screen-reader-only live region announces the new page title, so the transition isn't silent for anyone not looking at the screen.
None of this changes how the site behaves with JavaScript disabled: every link is still a plain anchor pointing at a real HTML file.
Profile Feedback, Compatibility Patches, and GSO v0
July 2, 2026
Phases 52 through 56 landed. The local tree now has 57 development phases and 399 passing tests.
Phase 52 (Graphics Profile Feedback) closes the loop on the GPU axis: runtime shader and pipeline usage gets logged as profile events, aggregated, and promoted into hints that steer the next compile/rebuild cycle, the same closed loop the CPU side already had.
Phase 53 (Title Behavior Patch System) adds typed compatibility metadata that can change executable runtime behavior, not just describe it. A required patch stays enabled even if a caller asks to disable it, and the resolver reports the ignored request rather than dropping it silently.
Phase 54 (GSO v0) is the first guarded speculative optimization path. A versioned profile is generated from runtime branch-target observations, but only for monomorphic sources. The native x86_64-v4 backend can lower the v0 guard shape for a terminal SUBS comparison, falling through on success and deopting to a reconstructed resume PC on failure.
Phase 55 (Official Title Profiles) bundles a title's behavior patches and GSO profile together, matched by title ID and a non-cryptographic content hash used as an identification aid, not an integrity guarantee.
Phase 56 (Profile Sanitizer) adds the export gate a local title profile has to pass before it can ever be shared: personal paths get stripped from free-text fields, and anything that looks like embedded blob content blocks the export outright. Local GSO overrides never appear in the shareable form at all.
All five phases currently exercise one synthetic built-in title. There is no signed profile format, no download/upload approval flow, and no compatibility database yet — those are later phases.
The project still has no public downloads, no commercial title import or title boot, and no firmware, keys, or bundled system files.
Shader AOT and Pipeline Cache
June 28, 2026
Phases 50 and 51 landed. The local tree now has 52 development phases and 343 passing tests.
Phase 50 (Shader AOT v0) adds a batch shader compilation pass during initial compile. It translates every shader in a set, caches each as a .nxshader object, and reports shader readiness in basis points. Shared profile hints steer compilation order so hot shaders compile first. Shader readiness feeds into Native Coverage as one axis of a min-gate: the weakest of CPU, shader, and pipeline readiness caps the combined number.
Phase 51 (Vulkan Pipeline Cache Integration) adds the pipeline cache infrastructure. PipelineCacheBlob persists opaque Vulkan pipeline cache bytes to disk with atomic writes. PipelineKey is a deterministic FNV-1a hash of shader combination plus render state. A PipelineMissLog records cache misses at runtime for future prioritization. Pipeline readiness is the third axis of the Native Coverage min-gate.
Neither phase generates real SPIR-V or creates real Vulkan pipelines yet. The shader translation remains a deterministic placeholder, and the pipeline blob starts empty. The infrastructure is in place so that when real shader compilation arrives (Phase 52+), readiness reporting and cache persistence are already wired.
The project still has no public downloads, no commercial title import or title boot, and no firmware, keys, or bundled system files.
Phase 49: Shader Skeleton
June 27, 2026
The local Nx86 tree now has 50 development phases present, through Phase 49. Since the last update, the project added self-modifying code tracking, atomics, barrier semantics, guest threading, scheduler replay, fiber mode, scalar FP, NEON, advanced vector lowering, hot/cold block splitting, native coverage, simple homebrew loading, HLE service skeletons, input runtime, guest IPC v0, an audio runtime skeleton, a Vulkan backend skeleton, and a shader translation skeleton.
The graphics work is still a skeleton. Vulkan can be detected and loaded, a device can be created where one is available, an offscreen frame can be rendered, and the rendered-frame path is exposed to the GUI. The shader side can model metadata, hash source bytes, create deterministic placeholder translations, and store .nxshader cache objects. Real SPIR-V generation, Maxwell/NVN shader translation, shader AOT, pipeline cache integration, and graphics profile feedback are still future work.
The project still has no public downloads, no commercial title import or title boot, and no firmware, keys, or bundled system files. The current homebrew path uses Nx86-owned .nxhb.toml descriptors rather than real NRO/NSO parsing or Horizon ABI coverage.
33 Phases Done
June 24, 2026
Nx86 has reached the end of Phase 32 (Memory Mirroring). That is 33 completed phases since the project started. The compiler pipeline, runtime, memory system, and GUI shell are all functional and covered by 215 differential tests.
Since the first post, the project has landed a multi-block dispatcher, an emergency JIT that compiles missing blocks on the fly, block chaining with guarded native exits, fastmem and slowmem for guest memory access, a runtime profiling system, profile-guided rebuilds, a CFG recovery pass, guard and deopt metadata, and a memory mirroring subsystem. The Inspector can show disassembly, CFG, NxIR dumps, and native mappings for any compiled function.
What is next: self-modifying code support (Phase 33), atomics (Phase 34), barrier semantics (Phase 35), and guest threading (Phase 36). These are the building blocks needed before real Switch software can start running.
The project is still not usable as an emulator. There are no public downloads, no game import, and no homebrew execution. But the foundation is getting solid. The code is on GitHub.
Hello, Nx86
June 21, 2026
This is the start of something I have been thinking about for a while. Nx86 is a Switch emulator, but not the kind you are probably used to. Instead of interpreting or JIT-compiling game code at runtime, the idea is to translate as much as possible into native x86_64 machine code before you even hit play. The result gets cached to disk, so the next time you launch the same game, it is already compiled.
The core bet is this: if you are willing to wait longer on the first launch, you get smoother, more native-feeling execution after that. And if the emulator runs into code paths it has not seen before during gameplay, it compiles those on the spot and adds them to the cache. The cache gets smarter every time you play. The project calls this Continuous Dynamic Compilation.
Right now the project is mostly compiler groundwork. The pipeline goes from raw ARM64 bytes through a decoder, into an intermediate representation called NxIR, through a register allocator and a hand-written x86_64 assembler, and out the other side as native machine code. Synthetic test programs can travel the full path already. Three-way differential testing (interpreter vs IR evaluator vs native execution) keeps things honest.
What is not there yet: real game execution, a public build, homebrew support, or anything you can download. The GUI exists as a small Linux app built with egui, but it is mostly a test harness right now.
What is next: a cache manager for persisting compiled blocks, a multi-block dispatcher for running them in sequence, and an emergency JIT path that kicks in when the emulator hits uncompiled code at runtime.
The project is written in Rust, lives in a monorepo with around 35 crates, and targets Linux x86_64-v4 as the first platform. The code is developed on Apple Silicon but the pure-logic parts run anywhere. Native execution is Linux-only for now.
If you want to follow along, the code is on GitHub.
