Stop-and-swap is a cartridge-swap exploit used on the Nintendo 64 to alter Banjo-Kazooie’s runtime memory by pausing the game, physically changing the inserted ROM, and resuming play so the engine reads unexpected data; that change can produce major sequence breaks, early exits, or injected state useful to Any% and low% routes.
Why stop-and-swap is a game-changer for Banjo-Kazooie runs and glitches
Stop-and-swap lets you turn a single pause into a deterministic state change that the game treats like an actual progression event, so runs can skip load sequences, spawn items early, or pivot the pointer table to different assets.
Speedrunners use it to shave minutes off Any% and low% routes by forcing the engine to load pointers or level data from the swapped cartridge instead of the original, enabling major sequence breaks and early exits otherwise impossible on a single-cart run.
Collectors and retro hardware fans study the trick because it exposes how the N64 cartridge bus and ROM mapping behave under nonstandard access, revealing persistent SRAM/WRAM effects and partial asset loads that are otherwise hidden.
How the stop-and-swap cartridge-swap glitch actually manipulates N64 memory and game state
The core behavior is that pausing can stop CPU-driven asset requests while the PIF and CIC chip interactions with the cartridge bus remain in a semi-consistent state; swapping the ROM during that window can leave pointers pointing at new data or produce partially populated buffers.
Partial asset loads occur because the game sometimes reads chunked data directly from ROM into VRAM or working buffers; if the ROM source changes mid-transfer, the CPU may use the newly read bytes while leaving other areas unchanged, creating usable corrupted pointers or intentional state injection.
Timing matters because the N64 bus, cart edge connector, and mapper logic determine when reads complete; a frame-perfect swap or controller-hold cue can cause the game to perform reads after the physical exchange, producing consistent results rather than random corruption.
Performing stop-and-swap on original N64 hardware: a safe, step-by-step protocol
Required hardware: two cartridges (one source, one target) or a single target if your route uses specific ROM contents, a stable power supply, a clean contact surface, and a practice plan with non-run attempts before recording timed runs.
High-level sequence: 1) reach the defined pause state in the route; 2) hold the required controller inputs to lock animations or freeze read loops; 3) unseat the cartridge smoothly, swap, reseat, and resume when the swap window passes; 4) perform in-game verification immediately.
Timing cues to watch: the pause menu rendering frame (visual freeze), controller input responsiveness (unresponsive inputs mean reads are blocked), and specific animation frames used by the community for that route; these cues mark when the cartridge bus is in the right state for a swap.
Preparation checklist before you attempt a live cartridge swap
Clean contacts with isopropyl alcohol and a soft cloth; dirty pins increase resistance and cause intermittent reads that ruin precision swaps.
Ensure the console sits on a stable, nonconductive surface and that the cart clicks flush into the slot; wobble increases wear and the chance of contact loss mid-swap.
Back up saves to an EverDrive or a memory backup device and remove the Controller Pak if a route instructs doing so to reduce SRAM interference; always verify backups before attempting risky swaps.
Choose target cartridges used by the community—commonly tested ROMs and known-good backup carts—then practice the swap sequence on those carts away from a timed run until results are consistent.
Executing the physical swap and verifying success
Execute swaps with two hands: one steadying the console, the other performing a single smooth vertical pull and replacement motion to minimize lateral stress on pins.
Feel and watch for swap cues: the pause menu should remain visible but inputs may be locked; if the controller re-registers input immediately after reseating, you likely hit the correct window.
Quick in-game checks after resume: confirm expected asset or pointer changes within the first few seconds—spawned objects, skipped cutscenes, or altered inventory are common verifications. If nothing changes within the documented verification window, reset and replay the sequence.
Emulator and flashcart alternatives: safer equivalents to stop-and-swap (Project64, EverDrive)
Emulators and flashcarts remove most physical risk by letting you recreate the same memory behavior deterministically: save-states reproduce exact RAM, memory editors let you patch pointers, and ROM patching can inject data at known offsets.
Project64 or Mupen64 provide frame-stepping and save-state tools to find the exact frame where a swap would succeed; then replicate that RAM image on an EverDrive or use a patched ROM to reproduce the effect on hardware without repeated physical swaps.
EverDrive setups can load deterministic payloads: preload the swapped-ROM data into WRAM or configure a launch sequence that mimics the physical swap, giving consistent testing and safer verification prior to attempting a live swap.
How speedrunners use stop-and-swap in Banjo-Kazooie routing: categories, rules, and record examples
Which categories allow it: glitch-permitting categories like Any% often permit stop-and-swap if the leaderboard and moderators have accepted it; glitchless and official tournament rules typically ban any cartridge manipulation beyond normal play.
Common uses include level-skips by forcing different level table entries, item injection by redirecting pointer tables to other ROM assets, and early exit tricks that rely on altered memory to bypass required objectives.
Run verification: community VOD reviewers expect clear documentation of the swap, hardware checks (console model, cart labels), and multiple angles when possible; reproducible footage and emulator corroboration speed validation.
Troubleshooting failed swaps and recovering corrupted saves or states
Common failure modes: immediate console reset, garbled textures, missing meshes, or a soft lock where inputs are ignored but the system hasn’t fully bricked; hard corruption can render a save unreadable if SRAM writes were interrupted.
Recovery steps: perform a safe reset sequence as recommended by community guides, avoid repeated power cycling, then restore from backups on EverDrive or memory backup devices. If save data is glitchy but present, clear SRAM only when you have a verified backup.
If the console appears dead after a swap attempt, remove power, reseat everything, and run diagnostics with known-good cartridges before concluding permanent damage occurred.
Hardware safety, risks, and damage mitigation when swapping cartridges live
Real risks include bent pins, worn cartridge slot contacts, static discharge, power surges that stress the board, and potential loss of saves due to interrupted SRAM access.
Mitigation tactics: minimize lateral movement, use a slow and vertical swap motion, keep the power supply stable (use a surge protector), and consider cartridge adapters that reduce wear; always maintain current backups to mitigate save loss.
If you intend to practice extensively, invest in an EverDrive or a dedicated test console to preserve your primary hardware and reduce cumulative wear on a collector cartridge.
Practice drills and timing techniques to master a reliable stop-and-swap
Run the sequence slowly at first and film with a high-frame-rate camera to identify the exact swap window in frames; review footage to mark the microsecond where the cartridge change correlates with successful state change.
Use partner-assisted swaps for stability: one person steadies the console and watches cues while the other performs the swap; this reduces console movement and increases repeatability.
Emulation tools like frame stepping and audio cue analysis help you count frames and create a scripted practice routine; repeat the exact motion until muscle memory reproduces the camera-timed window reliably.
Alternatives and complementary glitches to chain with stop-and-swap
Commonly chained tricks include clipping (to bypass geometry), hitbox manipulation (to trigger unintended collisions), and camera exploits that alter update order; combining these with a successful swap can compress several objectives into a single sequence.
Choose combos that maximize route savings without compromising consistency; if a chain increases variance, prioritize reproducibility over theoretical time save for leaderboard reliability.
Community resources, video tutorials, and where to validate run legitimacy
Primary resources: Speedrun.com route pages, category-specific Discords, detailed YouTube step-by-step demos, and TASVideos analyses for frame-accurate reference; these sources provide community-tested procedures and verification norms.
Best submission practices: record multiple camera angles (console view plus controller and cart), include a hardware check at the start, timestamp the swap in the VOD, and mark the exact category and routing decisions for reviewers.
Next steps for learners: building a safe setup, practicing runs, and contributing discoveries
Start on emulator with save-states and frame stepping to isolate the precise swap window, then graduate to EverDrive testing for deterministic hardware-like behavior, and finally practice physical swaps on a dedicated test console.
Document reproducible steps: keep clear timing notes, record high-frame-rate clips, submit write-ups to community wikis, and provide patchable memory images or EverDrive payloads so reviewers can replicate your results.
Contribute findings responsibly by labeling runs accurately, sharing backups, and submitting reproducible demonstrations to route maintainers so the community can adopt safe, verified techniques.
