Reverse emulating the NES to give it SUPER POWERS!
suckerpinch
AI-assisted summary of Reverse emulating the NES to give it SUPER POWERS! — original source. Check the original for full context.
Source published:
Key ideas
- Tom (suckerpinch) introduces "reverse emulation"—retaining unmodified vintage console hardware while replacing passive cartridge ROM chips with high-speed computers like the Raspberry Pi Zero W and Pi 3 to inject dynamic data on the fly. (3:43)
- By dynamically altering palette attribute bytes on every 8x1 pixel scanline fetch, the setup bypasses the NES PPU's native 16x16 attribute grid and VBlank limits, enabling full-motion video playback on standard hardware. (7:46)
- Because the Raspberry Pi is only ~3× faster than the PPU bus clock, conventional read-then-write code arrives too late; the system relies on a predictive heuristic that writes guessed bytes onto the bus before sampling address lines. (10:41)
- Using an upgraded quad-core Raspberry Pi 3 cartridge board, the project successfully runs 16-bit Super Mario World in real time on an unmodded 8-bit NES, using an authentic NES gamepad for input. (15:52)
Detailed notes
## Background Published on YouTube by suckerpinch (Tom Murphy VII) on May 29, 2018, this video documents an experimental technical project to give the original NES "super powers." The video description teases that the presentation begins strangely and grows stranger before its ultimate purpose becomes clear, directing viewers to a companion video for deeper technical details.
## TL;DR Tom Murphy VII introduces the concept of "improper hierarchy" in comedy and computing before demonstrating "reverse emulation"—running stock, unmodified retro hardware while replacing passive cartridge ROMs with a high-speed Raspberry Pi. After revealing that the presentation slides and full-motion video are being rendered live through an authentic NES via real-time bus manipulation, he details the strict nanosecond timing, predictive bus writes, and CPU "knocking" protocols needed to bypass hardware limits. Upgrading the setup to a quad-core Raspberry Pi 3, he plays 16-bit Super Mario World directly on the 8-bit console using an original controller. He concludes with a playful philosophical thought experiment applying reverse emulation to the human brain to augment biological memory with high-speed coprocessors.
## Atmosphere & style The presentation blends deadpan intellectual wit, playful absurdity, and formidable low-level engineering skill. Tom delivers complex computing concepts with calm, wry self-deprecation, letting visual gags land naturally alongside oscilloscope traces and hardware schematics. The live reveal that his entire slideshow and video feed are running directly through a vintage front-loader NES creates an authentic sense of delightful technological subversion.
## Bulletin - [03:43](https://www.youtube.com/watch?v=ar9WRwCiSr0&t=223s) Tom (suckerpinch) introduces "reverse emulation"—retaining unmodified vintage console hardware while replacing passive cartridge ROM chips with high-speed computers like the Raspberry Pi Zero W and Pi 3 to inject dynamic data on the fly. - [07:46](https://www.youtube.com/watch?v=ar9WRwCiSr0&t=466s) By dynamically altering palette attribute bytes on every 8x1 pixel scanline fetch, the setup bypasses the NES PPU's native 16x16 attribute grid and VBlank limits, enabling full-motion video playback on standard hardware. - [10:41](https://www.youtube.com/watch?v=ar9WRwCiSr0&t=641s) Because the Raspberry Pi is only ~3× faster than the PPU bus clock, conventional read-then-write code arrives too late; the system relies on a predictive heuristic that writes guessed bytes onto the bus before sampling address lines. - [15:52](https://www.youtube.com/watch?v=ar9WRwCiSr0&t=952s) Using an upgraded quad-core Raspberry Pi 3 cartridge board, the project successfully runs 16-bit Super Mario World in real time on an unmodded 8-bit NES, using an authentic NES gamepad for input.
## Key takeaways - [00:00](https://www.youtube.com/watch?v=ar9WRwCiSr0&t=0s) Humor often operates by violating expectations through improper hierarchies, such as anachronisms or computational strange loops like Quines. - [03:43](https://www.youtube.com/watch?v=ar9WRwCiSr0&t=223s) Reverse emulation inverts traditional emulation by preserving stock retro console silicon and replacing passive cartridge ROMs with active, high-powered processors. - [06:06](https://www.youtube.com/watch?v=ar9WRwCiSr0&t=366s) The entire video presentation was covertly rendered in real time through an unmodified NES and controlled using an authentic NES gamepad as a slide clicker. - [07:46](https://www.youtube.com/watch?v=ar9WRwCiSr0&t=466s) The NES PPU draws background graphics in 8x1 pixel scanline strips, rereading attribute memory on every strip rather than once per 16x16 block. - [07:46](https://www.youtube.com/watch?v=ar9WRwCiSr0&t=466s) Manipulating bus responses during these 8x1 fetches bypasses normal attribute blockiness and unlocks substantially higher effective on-screen color resolution. - [09:22](https://www.youtube.com/watch?v=ar9WRwCiSr0&t=562s) Overcoming native PPU VBlank bandwidth bottlenecks allows an unmodded NES to render arbitrary per-frame tile data and display full-motion video. - [10:41](https://www.youtube.com/watch?v=ar9WRwCiSr0&t=641s) Strict nanosecond-scale bus timings force the cartridge Pi to preemptively write predicted data before reading the requested PPU address lines. - [13:05](https://www.youtube.com/watch?v=ar9WRwCiSr0&t=785s) Custom cartridges require an authentic harvested 10NES CIC lockout chip to boot successfully on unmodified front-loader consoles. - [13:05](https://www.youtube.com/watch?v=ar9WRwCiSr0&t=785s) The system implements a 'knocking' protocol using descending VRAM reads during VBlank to coordinate CPU-to-cartridge communication without corrupting graphics. - [13:05](https://www.youtube.com/watch?v=ar9WRwCiSr0&t=785s) Controller button states are transmitted upstream to the cartridge by embedding 8-bit button states directly into the address lines of dummy VRAM reads. - [15:52](https://www.youtube.com/watch?v=ar9WRwCiSr0&t=952s) Upgrading to a quad-core Raspberry Pi 3 dedicates one core exclusively to timing-critical PPU bus operations while other cores run game emulators. - [15:52](https://www.youtube.com/watch?v=ar9WRwCiSr0&t=952s) Super Mario World runs playable on the 8-bit NES, aided by matching controller bit layouts between NES and SNES hardware. - [15:52](https://www.youtube.com/watch?v=ar9WRwCiSr0&t=952s) Alternating the NES horizontal scroll offset by four pixels every other frame applies a temporal anti-blockiness effect, doubling perceived horizontal resolution. - [19:35](https://www.youtube.com/watch?v=ar9WRwCiSr0&t=1175s) Reverse emulation serves as an alternate metaphor for human cognitive enhancement, proposing biological hardware augmentation over full digital mind uploading.
## Detailed walkthrough ### [00:00](https://www.youtube.com/watch?v=ar9WRwCiSr0&t=0s) The Anatomy of a Joke and Improper Hierarchy
Tom (suckerpinch) introduces the video as a technical humor project centered on the Nintendo Entertainment System (NES). Before diving into the hardware, he chooses to tell the joke "inside out" by dissecting what humor actually is. He notes that pretentious thinkers have desiccated comedy into dry prune dust for centuries, citing an old-timey comedic premise: a movie of a sweating, disgusted man eating a boot is not funny, but a distinguished-looking man eating a boot with a neutral expression supposedly is. While Tom finds neither example funny today—acknowledging that boot-eating as the apex of slapstick might only be meta-funny—the underlying mechanic is valid: humor lives where expectations are violated.
Moving toward technical humor, Tom tests different comedic structures. Mario eating a boot is uninspired retro nostalgia, but Samus Aran eating Tide Pods in the year 1986 becomes funny through anachronism, as Tide Pods did not exist then. He then analyzes self-reference and recursion. Merely stating a fact like "my name is Tom 7" is not funny, but Douglas Hofstadter's concept of "strange loops" is. As an example, he presents a Quine—a computer program that produces its own exact source code as output when compiled and executed.
Tom argues that the comedic magic in a Quine lies specifically in the final step. Code is conventionally understood as the precursor to a program, so watching an executed binary spit out its own source code violates expectations regarding the sequential order of tools and artifacts. He generalizes this concept into what he calls "improper hierarchy": when an established sequence, dependency, or hierarchy is inverted or mangled. Anachronism is simply improper hierarchy applied to time (dragging the present back into the past). In a tongue-in-cheek self-promotion tip, he shows a Venn diagram placing improper hierarchy over strange loops and self-reference, noting: “draw that specious parallel and then you know no one no one can stop you.”
- The boot-eating trope illustrates the principle of comedic subversion through violated expectations. - Anachronisms (e.g., Samus eating Tide Pods in 1986) serve as chronological violations of hierarchy. - A Quine demonstrates an improper hierarchy by reversing the traditional relationship where source code strictly precedes and produces the executable program.
[03:43](https://www.youtube.com/watch?v=ar9WRwCiSr0&t=223s) Inside the NES and the Concept of Reverse Emulation
To apply improper hierarchy to computing, Tom examines the motherboard and architecture of the original NES. On the left sits the 8-bit Ricoh 2A03 CPU running at roughly 1.79 MHz; on the right is the Picture Processing Unit (PPU), a faster, non-programmable graphics processor. Next to them is the 10NES lockout chip (CIC), whose sole purpose is to monitor for authorization and reset the console if it senses something amiss. Tom debunks the widespread childhood myth of blowing into game cartridges, pointing out that moisture from breath is actively bad for the hardware, and that the flashing reset light is purely the result of this lockout chip.
```mermaid flowchart TD accTitle: NES Cartridge Architecture accDescr: Diagram contrasting standard NES cartridge ROMs with the reverse emulation approach using a modern computer.
subgraph StandardCart["Standard Game Pak"] PRG["PRG ROM (CPU Code)"] CHR["CHR ROM (PPU Graphics)"] CIC_C["Lockout Chip (CIC)"] end
subgraph Console["NES Console Motherboard"] CPU["CPU (8-bit @ ~1.79 MHz)"] PPU["PPU (Graphics Processor)"] CIC_M["Lockout Chip (Reset Monitor)"] CPU <--> PRG PPU <--> CHR CIC_M <--> CIC_C end
subgraph ReverseEmu["Reverse Emulation Concept"] RPI["Raspberry Pi Zero W (1 GHz, Modern RAM)"] RPI -.->|"Intercept Bus & Feed Dynamic Data"| CPU RPI -.->|"Intercept Bus & Feed Dynamic Data"| PPU end ```
The console interacts with the game cartridge (officially a "Game Pak," sold for $60 in 1980s money). Opening an American cartridge reveals a comically small circuit board housed inside a massive plastic shell. The Japanese Famicom cartridges were appropriately sized for the tiny board, but when brought to the United States, Nintendo built what Tom calls "the SUV of cartridges." Inside are two main memory chips—PRG ROM for the CPU program and CHR ROM for PPU graphics—along with the mating lockout chip.
Traditional emulation discards the physical hardware, replacing the console chips with software running on a PC to execute a game file. Tom proposes "reverse emulation," completely flipping this relationship: keep the physical, unmodified vintage console hardware, but gut the cartridge. Instead of passive, read-only memory chips that do nothing more than serve static lookups, he plans to replace the ROMs with an active, high-powered computing device.
- Traditional emulation: replaces retro console hardware with modern software while loading static game ROM files. - Reverse emulation: retains original, stock console hardware while replacing passive ROM silicon with an active, high-speed computer. - The vast empty air inside the oversized North American NES cartridge shell offers ample physical clearance to hide modern electronics.
[06:06](https://www.youtube.com/watch?v=ar9WRwCiSr0&t=366s) The Fantasy Schematic, FCC Rules, and the Live Demo Reveal
Tom selects a Raspberry Pi Zero W to sit inside the cartridge. At only $10, it packs a 1 GHz single-core CPU, substantial RAM, and onboard Wi-Fi. His "fantasy schematic" assumes that because the Pi is vastly more powerful than an NES—and his personal software emulator can run NES code at 28,000 frames per second—hooking the Pi directly up to the console should be trivial. The theoretical plan is to listen to the address bus as the NES requests data, perform on-the-fly modern computations, and feed custom values back into the bus, perhaps with a lone resistor tossed in somewhere.
Inspecting the underside of the NES, Tom jokes about finding FCC certification stickers requiring that the device "must accept any interference that may be received, including interference that may cause undesired operation." Tom quips: “basically this behavior is required by law so it has to work.”
At this moment, Tom reveals the central secret of the presentation: the entire video presentation thus far has been running live on an actual, completely unmodified NES. He pans a physical camera over to prove it, showing the console connected to the display while he uses an authentic original NES gamepad as a handheld slide clicker to advance his slides in real time—effectively running "Nintendo PowerPoint."
- The Raspberry Pi Zero W features a 1 GHz processor, wireless connectivity, and an ultra-low $10 retail price. - Tom's desktop-based software emulator executes NES instructions at roughly 28,000 FPS, highlighting the staggering performance gap between vintage silicon and modern machines. - The entire video lecture is rendered live through a stock NES console and controlled using a standard Nintendo controller.
[07:46](https://www.youtube.com/watch?v=ar9WRwCiSr0&t=466s) Subverting the NES PPU and Tile Rendering
Tom breaks down the inner workings of NES graphics to explain how the slides are being rendered on the fly. The NES PPU structures backgrounds around two tables: pattern tables containing fixed 8x8-pixel graphical tiles, and a separate memory region called the attribute table that assigns color palettes to screen regions. While the hardware can display up to 13 distinct colors simultaneously across four palettes chosen from the system's global palette, the attribute table normally restricts color assignments to large 16x16-pixel blocks (the size of a standard *Super Mario Bros.* question mark block). Tom points out that this severe restriction is why the famous Mario cloud and bush sprites share the exact same tile art, differing only by the palette assigned to them.
```mermaid flowchart LR accTitle: PPU Scanline Rendering Pipeline accDescr: Breakdown of standard 16x16 attribute blocks versus cycle-timed dynamic palette updates during 8x1 rendering strips.
subgraph StandardPPU["Standard Hardware Limitation"] A["16x16 Pixel Region"] --> B["Locked to 1 of 4 Palettes"] end
subgraph DynamicPPU["Reverse Emulation Injection"] C["PPU Scanline Fetch"] --> D["8x1 Pixel Strip"] D --> E["Address Requested from Bus"] E --> F["Pi Feeds Modified Palette on Each Read"] F --> G["Higher Effective Color Resolution"] end ```
Under normal circumstances, developers were chained to this coarse 16x16-pixel color grid. However, Tom explains that the PPU does not draw an entire 16x16 block in one operation; it renders backgrounds in discrete strips measuring 8 pixels wide by 1 pixel high. Crucially, the PPU rereads the color palette attributes from the bus every single time it prepares to draw one of these 8x1 pixel scanline slivers.
Because the reverse emulator controls the memory bus in real time, it does not have to return static values. Every time the PPU requests the same attribute address for an ongoing scanline, the Raspberry Pi can swap the returned byte on the fly. By continuously altering the color data between individual 8x1 pixel fetches, Tom can bypass the static 16x16 attribute grid and unlock far greater color fidelity across the screen than the original hardware was ever intended to produce.
- The NES renders background graphics using 8x8 pixel tiles, referencing an overall master palette through four active 3-color (+1 shared background) palettes, capping simultaneous on-screen colors at 13. - Normal NES attribute memory enforces a low color resolution, locking colors into coarse 16x16 pixel blocks. - The PPU processes display graphics line by line in 8x1 pixel slices, requesting attribute memory repeatedly for each slice. - By intercepting these reads and feeding different palette bytes on every fetch, reverse emulation changes colors per 8x1 strip, significantly overcoming native NES attribute limitations.
[09:22](https://www.youtube.com/watch?v=ar9WRwCiSr0&t=562s) Overcoming NES Update Limits and Full Motion Video
On a stock, unmodified Nintendo Entertainment System, screen rendering is constrained by strict hardware timing. The Picture Processing Unit (PPU) spends most of its time drawing 240 active scanlines, during which the CPU cannot safely touch graphics memory without triggering catastrophic visual glitches. Game code is forced to cram all visual updates into the vertical blanking interval (VBlank), an idle window lasting only about one-thirteenth of an entire frame. Coupled with the sluggish data bus between the CPU and PPU, games like *Super Mario Bros.* can alter only a tiny sliver of the display per frame, establishing a hard physics ceiling on how fast Mario can run before outstripping the console's ability to draw incoming terrain. By reverse-emulating the graphics directly inside the cartridge hardware, suckerpinch bypasses these constraints completely, freely rewriting any and every tile on the fly.
This capability makes it possible to play full-motion video directly on standard hardware. Suckerpinch demonstrates this by playing Rick Astley's "Never Gonna Give You Up," remarking that it might represent the best graphics ever displayed on the console. While noting that an entirely separate companion video covers the complete technical architecture, suckerpinch emphasizes the philosophical irony of pushing the console beyond its perceived specs: “functionality that it doesn't apparently have but it does in fact have because this is an unmodified Nintendo it just needed to believe in itself.”
- The NES draws 240 scanlines before entering VBlank, leaving only ~1/13th of a frame's duration to write updates to PPU memory. - Traditional games are restricted to small, incremental tile updates per frame, which limits maximum scrolling and character speeds. - Cartridge-side reverse emulation enables unrestricted per-frame tile replacement, making full-motion video playback feasible on an unmodded front-loader NES.
---
[10:41](https://www.youtube.com/watch?v=ar9WRwCiSr0&t=641s) The Timing Problem and Predictive Bus Writing
Implementing this in hardware requires operating within razor-thin timing margins. Suckerpinch captured an oscilloscope trace of the cartridge connector pins on the very Nintendo being used, stored that trace inside the cartridge, and piped it right back onto the TV screen over those exact same physical wires—a self-referential loop suckerpinch calls an example of improper hierarchy or a "strange loop." The PPU communicates with the cartridge ROM using timing pulses measured in nanoseconds, passing 16 address lines to request memory and expecting 8 data bits returned on the bus. While suckerpinch is accustomed to desktop emulation speeds hitting 28,000 frames per second, the Raspberry Pi driving the cartridge is only roughly three times faster than the native PPU ROM clock.
```mermaid flowchart TD accTitle: Predictive Cartridge Memory Bus Loop accDescr: Diagram illustrating how the Raspberry Pi preemptively writes data before reading the requested PPU address.
subgraph HardwareCycle ["PPU Bus Cycle"] WaitStart["Wait cycle begins"] WriteData["Pi preemptively pushes predicted byte"] ReadAddr["Pi reads incoming 16-bit address lines"] UpdateGuess["Update state machine prediction for next byte"] end
WaitStart --> WriteData WriteData --> ReadAddr ReadAddr --> UpdateGuess UpdateGuess -.->|"Ready for next cycle"| WaitStart ```
When taking real-world pin latency into account, standard hand-optimized assembly that simply waits for an address and outputs the corresponding byte arrives far too late for the NES to sample it. Suckerpinch solves this timing paradox with a clever shortcut: “you know if you can't submit your paper on time to the conference just submit on time for next year's deadline.” Rather than waiting for the read address, the software immediately fires data onto the bus the moment the cycle starts, allowing the electrical signal just enough time to stabilize before the NES reads it. The Pi only reads the address lines *after* the write has already been executed. Because the write occurs before the read, the system cannot know which address was requested; instead, it runs a predictive heuristic estimating what the PPU will demand next based on standard rendering patterns, refining its guess based on the trailing address reads. While effective enough to function, imperfect predictions cause the visual noise, analog waveform distortion, and jitter seen on the output.
- The PPU interface uses 16 address input lines, 8 data output lines, and control signals operating on a nanosecond scale. - A standard Raspberry Pi runs only about 3× faster than the PPU ROM interface speed, leaving almost no margin for bus turnaround latency. - Naive read-then-write assembly fails timing requirements, forcing the Pi to output predicted data immediately upon cycle start before sampling the requested address lines. - Real-world electrical signals behave as distorted analog waveforms rather than clean square waves, worsening latency and causing visual artifacts.
---
[13:05](https://www.youtube.com/watch?v=ar9WRwCiSr0&t=785s) Hardware Build, the CIC Chip, and CPU "Knocking" Communication
The physical cartridge PCB required a complex layout to interface the Raspberry Pi to the console's edge connectors. Building the cartridge necessitated harvesting an authentic 10NES lock-out chip (CIC) directly from an original retail cartridge, as the console flatly refuses to boot without one. Suckerpinch notes with regret that sacrificial NES cartridges must be desoldered, pointing out the market oddity that 30-year-old bargain NES donor carts have become more expensive than budget Super Nintendo games. Alongside the Raspberry Pi sits a dedicated CPU ROM containing custom machine code that handles controller input and updates the NES palette registers, choosing 13 colors out of the system's 64-color master palette before each frame begins.
```mermaid flowchart LR accTitle: Bidirectional CPU-to-Cartridge Knocking Protocol accDescr: Flowchart detailing the knocking sequence and controller multiplexing over graphics memory reads during VBlank.
subgraph VBlankPeriod ["VBlank Window (~1.5 ms total)"] A["CPU wakes via NMI interrupt"] --> B["Knocking: CPU reads VRAM in descending order"] B --> C["Cartridge recognizes CPU bus master"] C --> D["Cartridge streams 13-color palette data"] D --> E["CPU encodes 8-bit controller state into read addresses"] E --> F["Cartridge latches input; ~0.5 ms CPU budget remains"] end ```
Because the CPU and the custom cartridge board share no dedicated high-speed link, communication is multiplexed over the graphics bus during VBlank. While the PPU sits idle, the CPU reads graphics memory. To prevent the board from confusing CPU access with regular rendering, the CPU executes reads in strictly descending address order—a behavior dubbed "knocking"—which the PPU hardware never performs during its left-to-right scanline sweep. Once synchronized, the exact address values become irrelevant, letting the board safely feed palette data back to the CPU without corrupting screen graphics.
To send player controller data back in the opposite direction, suckerpinch exploits the address bus: since reading a byte requires putting an address on the bus, the CPU simply embeds the 8 controller button bits inside the address lines of its dummy reads. The cartridge snoops these addresses, decoding the controller state while returning junk data. However, this entire handshake consumes two-thirds of the VBlank window, leaving merely half a millisecond of CPU processing time—barely enough to swap presentation slides or run crude animations.
- Authentic CIC lock-out chips must be desoldered from vintage donor cartridges to bypass console lockout mechanisms. - The custom CPU ROM programs 13 active colors out of 64 into the NES palette prior to each frame. - "Knocking" uses descending-order VRAM reads to signal to the cartridge that the CPU, rather than the PPU, is requesting bus access. - Controller button states are transmitted upstream to the cartridge by embedding controller bitmasks into the VRAM read addresses. - The synchronization and data transfer handshake consumes roughly 1 millisecond (two-thirds of VBlank), leaving ~0.5 ms for CPU execution.
---
[15:52](https://www.youtube.com/watch?v=ar9WRwCiSr0&t=952s) Upgrading to Raspberry Pi 3 and Playing Super Mario World
To escape the strict computational bottleneck of the single-core board, suckerpinch constructed a second cartridge revision equipped with a quad-core Raspberry Pi 3. A multi-core processor allows one dedicated core to continuously service the relentless PPU bus timing while the remaining cores run complex application code, emulation, and rendering pipelines in parallel. Suckerpinch swaps the cartridge live on camera to maintain visual continuity, explaining, “I'm going through some trouble for continuity here so so no one can accuse me of cheating faking it.” While Linux kernel background interrupts introduce unavoidable visual flicker and blinking, the system successfully boots up.
The payoff is suckerpinch's punchline: running *Super Mario World*, the flagship 16-bit Super Nintendo launch title, fully playable on an unmodified 8-bit NES. The standard NES controller passes inputs straight into the game, aided by a fortunate mapping design:
> “coincidentally the controller I only have eight buttons on this thing right I don't have all of the buttons on a Super Nintendo but somehow like up on the Nintendo is the same bit as up on the Super Nintendo which is like a cosmic coincidence or perhaps they just you know got lazy”
Because the NES controller lacks the full SNES button layout, Mario is locked into running and spin jumps without standard jumps, though suckerpinch navigates the stage comfortably.
To overcome the visual limitations of the NES's 8×1 pixel color zones, suckerpinch applies an optical anti-blockiness technique: modulating the console's horizontal scroll offset and un-scrolling the rendered buffer by four pixels every other frame. This temporal grid alternation effectively doubles perceived horizontal color detail. Suckerpinch follows this demo by showing standard *Super Mario Bros.* running inside an NES emulator hosted on the Raspberry Pi inside the cartridge, whose video output is then piped back out through the real NES hardware, complete with authentic hardware noise and visual distortion.
- The cartridge upgrade integrates a quad-core Raspberry Pi 3, dedicating one core to real-time PPU bus management and background cores to SNES/NES emulation. - Kernel-level scheduling interrupts in Linux cause visible periodic screen flickering and dropouts. - *Super Mario World* runs in real time; NES controller inputs map directly to SNES controls via shared bit positions, though missing buttons restrict Mario to spin jumps. - Modulating the NES hardware scroll offset by 4 pixels on alternating frames shifts the 8×1 attribute grid to reduce tile blockiness and increase perceived color resolution. - The pipeline can also nest an NES emulator within the cartridge Pi and pipe the rendered frames back through the host NES PPU.
[19:15](https://www.youtube.com/watch?v=ar9WRwCiSr0&t=1155s) Comparing the Gags and Returning to Nintendo PowerPoint
Reflecting on the various visual stunts and recursive setups, Tom Murphy VII (suckerpinch) weighs which conceptual joke landed better. While he finds an elegant appeal in closing the loop, he admits his personal favorite remains the sheer absurdity of running the Super Nintendo through an original 8-bit NES. To him, violating computational status was the punchline all along: “I think this is a nice stroke it's elegant how it forms a loop but honestly I think that the Super Nintendo on Nintendo is a better joke and that's where I was going with all that stuff about improper hierarchy so I guess let me know which one you liked better but let's get back to Nintendo PowerPoint for a wrap up.” Returning to his presentation displayed directly on the hardware, he transitions into a broader philosophical takeaway before wrapping up the video.
[19:35](https://www.youtube.com/watch?v=ar9WRwCiSr0&t=1175s) Reverse Emulation, Artificial Intelligence, and the Human Brain
Looking beyond gaming consoles, Murphy muses on the broader utility of this approach. While reverse emulation is well suited to augmenting nostalgic hardware like the NES, Super Nintendo, Nintendo 64, or GameCube, he extends the thought experiment to another piece of legacy hardware: the human brain itself. He observes that humanity will eventually achieve true artificial intelligence, bringing with it an existential dread that goes beyond apocalypse scenarios. For Murphy, the deeper sting is obsolescence: “I worry a little bit about that not just because we might destroy ourselves and destroy society but because of the feeling of being left behind.” He points out that modern chess engines have already crossed this threshold—they are so overwhelmingly superior that playing against them has ceased to be fun. In that context, reverse emulation offers an alternative framework for the future of human intelligence.
```mermaid flowchart TD accTitle: Brain Emulation versus Reverse Brain Emulation accDescr: A comparison showing standard mind uploading on the left versus hardware augmentation on the right.
subgraph StandardUpload["Standard Emulation"] A["Human Mind"] -->|"Upload whole brain"| B["The Cloud / Virtual Server"] B -->|"Replaces biological self"| C["Virtual Entity"] end
subgraph ReverseEmu["Reverse Brain Emulation"] D["Biological Brain"] <-->|"Hardware interface"| E["Advanced Coprocessor"] E -->|"Intercepts queries"| F["Instant Computation"] F -->|"Feeds back into memory"| D end ```
Rather than standard brain emulation—uploading human consciousness into a cloud server—reverse emulation would leave the core biological person in place while swapping out internal components with hardware that far exceeds natural capabilities. Murphy imagines augmenting human memory so that difficult computational queries could be answered instantaneously:
* **Prime Factorization by Recall:** If asked to calculate the prime factors of an enormous number, the brain would not attempt mental math. Instead, it would simply trigger a recall loop, initiating a rote memory sequence like reciting "A-B-C-D," which the coprocessor intercepts and replaces with the computed factor digits (e.g., 472866029...). * **Perceptual Patching:** Because raw numbers lack the cadence of a nursery rhyme, Murphy jokes that the coprocessor would also need to trick the brain into perceiving that the multi-digit answer rhymes so the mind remains satisfied. * **Sacrificing Useless Pop Culture:** Realizing that reciting the alphabet is actually useful, Murphy proposes overwriting trivia nobody needs: “I realized I have all of these memories that I don't care about so what if instead it was something like Oh remember that time when in Charles in Charge Charles needed to factorize that number and the answer was blah blah blah blah that I think would be actually a pretty acceptable technology sign me up.”
Concluding the presentation, he thanks the audience for watching and humorously invites viewers to subscribe or “do what one does.”
## Mentioned Nintendo Entertainment System (NES), Famicom, Super Nintendo Entertainment System (SNES), Nintendo 64, GameCube, Ricoh 2A03, Picture Processing Unit (PPU), 10NES (CIC), Raspberry Pi Zero W, Raspberry Pi 3, Tom Murphy VII (suckerpinch), Mario, Samus Aran, Douglas Hofstadter, Rick Astley, Super Mario Bros., Super Mario World, Never Gonna Give You Up, Charles in Charge, Federal Communications Commission (FCC), Linux
## Video description The video begins in a strange way and gets stranger, but then, ideally, you understand why.
See the "making of" video for more technical information: https://youtu.be/hTlNVUmBA28
[Source](https://www.youtube.com/watch?v=ar9WRwCiSr0)