Slashdot Mirror
Hacker Gets Super NES Games Running On Unmodified NES (arstechnica.com)
The latest project from Tom "Tom7" Murphy is an unmodified NES running Super NES games. "Murphy breaks down this wizardry in a pair of detailed videos laying out his tinkering process," reports Ars Technica. "Though the NES hardware itself is untouched, the cartridge running this reverse emulation is a heavily customized circuit board (ordered from China for about $10), with a compact, multi-core Raspberry Pi 3 attached to handle the actual Super NES emulation." From the report: The Pi essentially replaces the PPU portion of the cartridge, connecting to the NES via a custom-coded EEPROM chip that tells the system how to process and display what would normally be an overwhelming stream of graphical data coming from the miniature computer. Only the CIC "copyright" chip from the original cartridge remains unmodified to get around the hardware's lockout chip. Murphy -- you may remember him from previous efforts to teach an AI how to play NES games -- says that the Raspberry Pi actually has too much latency to effectively "stream" tile-by-tile graphical instructions to the NES' cartridge CPU. By the time the Pi manages to "discharge" a set of instruction bits (only 180ns after they were generated), the NES itself has already moved on to the next part of its read-write cycle.
Murphy used a one-cycle delay to compensate for this latency, essentially guessing where the fairly predictable PPU would be writing to next and just sending data to that location ahead of time. That process works pretty well but results in the persistent flickering and graphical noise you see throughout his video demonstrations.
Murphy used a one-cycle delay to compensate for this latency, essentially guessing where the fairly predictable PPU would be writing to next and just sending data to that location ahead of time. That process works pretty well but results in the persistent flickering and graphical noise you see throughout his video demonstrations.
First off, a very cool project. However, this is an example of how when you have a hammer, everything looks like a nail. The jitter in the resulting screen is horrible - probably the result of the CPU not having consistent timing.
The BeagleBone board has a main CPU along with some dedicated, single cycle, accurate timing, real-time processors. It would have been interesting to see such a board being used where the main CPU does the emulation and the real-time processors handle the actual final output. Alternatively, an iCE40 or similar FPGA could have been used. The Pi is just not the right tool for the job. Although, it would be interesting to see it paired with a small FPGA.
So it is great that Tom "Tom7" Murphy got this to work. An excellent first step. But if the jitter problem were to be solved it would be even better.. Oh who am I kidding, it is damn impressive even with the jitter.
Hacker gets video output (with significant glitches due to timing) of a SNES game executing instructions (and receiving controller input) via an Emulator running on a Raspberry Pi displayed on an unmodified NES. Still, good work m8.
Well, as mentioned in the video, the glitchiness is because he's having to guess what the address will be before it actually gets read from, modifying his guess when predicted wrong for the next pass. Yes, he mentioned some facets of the experience due to the non-RT nature of the platform, but largely it's because of the having to guess addresses to respond to in advance.
In essence, the NES is a particularly convoluted video output converter here. A very impressive and difficult way to do something relatively simple, largely to make a point about imagining technology augmented brain.
XML is like violence. If it doesn't solve the problem, use more.
Also this is how Super Mario Bros. 3 works: there is an ASIC instead of the PPU ROM, which is why it is not only quite large but supports both horizontal and vertical scrolling at the same time, with more palettes than normal. Except he put a Raspberri Pi in it instead of an ASIC. So he just decided to emulate SNES games for fun after figuring out the PPU.
More like "Hacker turns NES into a glictchy as fuck Pi video card, and then emulates SNES on Pi, on an 'unmodified' NES with a heavily modified NES game PCB"
It's not running on the NES any more than it's running on the tv set used to display the output...
The NES is merely being used as an intermediate output device, the actual game is running on the raspberry pi.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Also this is how Super Mario Bros. 3 works: there is an ASIC instead of the PPU ROM, which is why it is not only quite large
The Memory Management Controller (MMC3) helps make Super Mario Bros. 3 large, but it doesn't quite replace the CHR ROM. It just controls the high address lines (A16-A10) of CHR ROM and the high address lines (A17-A12) of PRG ROM. It's not conceptually different from the MMU used by a modern CPU to translate virtual memory addresses into physical memory addresses. MMC3 also contains a programmable interval timer that generates an IRQ by counting how often the PPU switches between reading sprite tile memory and reading background memory (which happens once per scanline). This timer is mostly used to switch between a game's playfield and its status bar.
but supports both horizontal and vertical scrolling at the same time
And a bunch of games that don't use MMC3 can do 8-way scrolling, such as Solar Jetman and Blaster Master. That's mostly a matter of the design of the game engine and, in some cases, of whether the cartridge has 8 KiB of supplemental work RAM on the CPU side (in addition to the 2 KiB in the NES) to cache a decompressed level map.
with more palettes than normal.
MMC3 does not extend the four background palettes and four sprite palettes, which are internal to the CPU. The closest a mapper can do is shrink the area affected by each palette from the normal 16x16 pixels. MMC5 has an "ExGrafix" mode that shrinks color areas to 8x8, and it was largely used for Koei's war sims but also saw use in Castlevania III and a handful of other games. But by the time developers started to figure out the MMC5's true capability, the TurboGrafx-16, Genesis, and Super NES were out, and game studios had mostly lost interest in the NES.
Sources: MMC3 reverse engineered docs; MMC5 reverse engineered docs; NesCartDB entries for SMB3 and other games