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.
Turning pattern ROM into a framebuffer for a co-processor to access. I mean Starfox did it, but that doesn't count.
I'd be more impressed if there was an ASTC TV tuner SDR writing to the buffer letting me watch HD TV on the NES palette and resolution.
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.
tl'dr the jitter is because the 'guess' is wrong sometimes.
All this project is saying is that it can get a raspberry pi to run SNES games and offload the graphical results to an NES. NES isn't running shit anymore than a .22 can fire Nukes if somebody magically Star Trek transports the warhead just ahead of the barrel.
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"
First up: Watch the whole video. It's worth the time!
I've been wondering about the counter-side to this for years: Ubiquitous emulation.
As technology advances, emulators get more sophisticated. Eventually, emulators are going to be showing up earlier and earlier, and be better and better.
Functionally, you're only going to need any unique hardware plugged into a friendly interface, and a any system can act like a less efficient version of any other, perhaps one generation worth of speed lost for the conversion.
The Wii was especially great along these lines, because you just needed a wiimote and IR lights, and emulation was amazing.
Anyway - once you have established a working matrix of ubiquitous emulation, the whole framework of games becomes basically more accessible anywhere, as long as you could create a central licensing body - you could basically make the Everything version of Steam.
Sure - companies would be resistant to the idea at first - walled gardens and all that - but it's the same logic that leads to better results for legalizing some forms of drugs - licensing it is a LOT more income than letting the black market exist.
And if 99% of your income comes when your hardware is still uniquely capable and beyond cross-console emulation, then it doesn't hurt most of your walled garden.
Or, you know, it can happen completely in the face of the various markets control systems, like it already has been - where each manufacturer uses their own emulators to slowly trickle old games out. But like voting patterns and television markets, I think the younger audiences are increasingly picking up on the idea that there's a better way to play the whole "gaming" game.
Ryan Fenton
Okay, I <3 Tom, but it's worth picking out this bit:
"you may remember him from previous efforts to teach an AI how to play NES games"
And point out that that *may* have been a joke. Where he explained part of it in a Youtube video wearing a colander on his head. If he later actually made the joke work, that's terrific, but holy shit, submissions to SIGBovik aren't, uh, real?
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!
Yeah someone made Quake "run" inside xterm by making an adaptation layer converting the graphics to ASCII art. You can turn any computer into a dumb terminal with external processing. But that's not "running" a program on the actual machine, it's more like "streaming" :P
The NES isn't "running" SNES games, the RPi is. The NES is basically acting as a dumb terminal with shims to the sound, display and inputs. Why even stop at SNES? Whack a few other emulators on there.
on old home computers of the 8 and 16 bit era you can find similar projects.
most of the time these had a bus that could replace the main cpu, so some people replace them with fpga's or arms or whatever really.
you can then build some supercomputer with it, most of the time producing impressive results.
On a long enough timeline, the survival rate for everyone drops to zero.
Hackers are criminals. Anything this criminal has done is not only illegal but probably very dangerous. We can only hope authorities will get to the bottom of this and make high profile arrests.
If he actually understood how the NES PPU works, "guessing" the address would've been a total non-issue - if you know the initial scrolling offsets, the PPU's memory fetch pattern is 100% predictable, so you could just build a table of values and output the "next" one each time the PPU asks for a byte of anything. Of course, that would also require his CPU to be running in real time with no interrupts, which wouldn't have worked with the RPI 3.
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
Perhaps so, but I'll give him the benefit of the doubt that perhaps there's some complication since he did do a pretty impressive job. Of course he also says he could have done better on PPU fetch pattern prediction, which may be what you refer to.
Since it's just a fun stunt to pull, not like it has to be perfect anyway.
XML is like violence. If it doesn't solve the problem, use more.
It's not the first time even.
Some of the special ASICs used in official NES cartridges by Nintendo did feed programmable RAM instead of ROM to the PPU.
Wikipedia mentions Zelda and Castlevania that use the MMC1 to map RAM so they can animate backgrounds by modifying tiles.
Other posts here mention Mario 3 using ASIC for multidirectional scrolling, etc.
(And that for the NES only. Then the SNES came with its co-processors embed in cartridges, be it SuperFX accelerator, or the Super Gameboy cartridge)
So if you feel that Tom7's trick is cheating, Nintendo has been doing it for much longer.
But the novelties are :
- instead of using a special ASIC like most of the examples from Nintendo (save for the SGB), Tom7 is using a general purpose CPU (like the Z80 in the SGB).
- instead of using some special access to the PPU (like any example from Nintendo) Tom7's attempts try to drive the PPU straight from the Pi's GPIO pins.
- thus the latency problems that classic Nintendo problems avoid (using ASIC and RAM with a reasonable latency), requiring Tom7 to be creative (predict what the PPU will attempt to read, so by the time the PPU is reading it, the Pi has the answer ready on its simulated ROM bus)
That's worth tons of LULZ points.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
So basically similar to the Super Gameboy, but with a NES instead of SNES as the host and an (emulated) SNES instead of a GB as the guest.
and with a PiZero (powerpoint presentation) or a Pi3 (SNES game) driving DIRECTLY THE ROM BUS - and that's the freaking awesome part.
He's not writing to a dual-ported RAM that then the PPU reads instead of ROM (like tons of official games from Nintendo do), he's feeding the PPU input straight from the Raspberry Pis. He's basically emulating what the ROM chips would be answering to the PPU, *entirely in software* (no ASICs involved unlike classical Nintendo examples).
In other ways :
- the SNES emulation is just a party trick for fun.
- the "REVERSE EMULATION" part, is that he's emulating what a PPU ROM in a real cartridge would be doing, entirely in software, using Pi GPIO PINs.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
But... Can. It. Run! Crysis??/
"The jitter in the resulting screen is horrible - probably the result of the CPU not having consistent timing."
"Probably"?
It's in the fucking SUMMARY, and explained in the video!
I learn something new everyday. I was not quite right it seems. But it's interesting what they did to enhance the power of the NES near the end of its lifetime.
....Running Windows 10 on an unmodified Pentium MMX? Useful, huh?