The title is misleading and the video is a bit obtuse, but the project is really fun. Basically, he’s driving a physical NES through it’s cartridge slot using a custom rigged hardware+software package based on a Raspberry Pi.
I mean, he explains in the video what he means by "reverse emulating". Instead of emulated hardware (software) driving software, he's having the actual hardware interface with hardware.
Maybe a misnomer, but a fairly accurate description, IMO.
The reverse part is that he's running the real hardware with an emulated cartridge ROM, rather than a (dump of) a real ROM on emulated hardware. It's explained in the video.
Awesome video! Really worth the watch until the end, with the interesting mix of explaining an electronics project, philosphy, AI and brain augmentation.
Cartridges with CPUs inside is not new and was used in real games.
The website or video description could use a bit more context around it:
-In the youtube video, how is one to know tom7 refers to the author when his youtube name is suckerpinch.
-On the website, how is one to know what this is about when it's just talking about "some project that was 24 hours backdated and blah blah...", and in the further text still doesn't explain what it is, just things like "it was presented in seattle" etc...
It's a personal blog post with a link to his new video. It's not the author's job to write his entire bio in every blog post. He didn't post it to HN himself.
One thing that’s interesting is that is also how the SuperFX chip for the SNES worked, IIRC. It basically was it’s own processor and rendering loop. The SNES’s onboard CPU was provided only a basic program to interface with the frame buffer, sound, and input.
The major difference is that in addition to the actual rendering CPU, it also had hardware that specifically converted the frame buffer into the SNES tile format to easily dump without issues.
Most Super FX games actually just used the Super FX as a specialized graphics processor and put all the game logic, as well as a lot of the graphics, on the stock SNES hardware. The Super FX was designed to generate sprite data on the fly for the SNES GPU ("PPU") to composite into the scene.
Kind of? SuperFX was essentially a second CPU paired with RAM that served as a framebuffer. You would set a pointer that contained code in its ISA format and it would asynchronously calculate graphics (almost like a second thread) and dump it into the RAM, which the SNES would then DMA right into its tile-based VRAM.
I thought the project was fun and the video was interesting and well made.
There is something that reminds me of Bret Victor about his reasoning. Is this a thing? I will call it Engineering Epistemological Reasoning - can more people pull that off now? Awesome. If so great news for me, because I enjoy such reasoning immensely.
I'm not sure many people can pull this off. The author here was also great in his presentation about automated NES playing, https://www.youtube.com/watch?v=xOCurBYI_gY. You don't see often academics & hacker work that is also combined with the right amount of humor. He even 3Dified the original Zelda!
No, those didn't drive more powerful system through the PPU of the less powerful system. They used a separate communication channel to connect to the graphics output of the host device.
It's the difference between hooking a device up your video card's input port and running a whole external computer system via the USB mass storage API. The latter is way more of an amazing hack.
That's wrong. The Super Gameboy worked exactly like this.
It was a SNES ROM which displayed an external framebuffer using PPU sprites. The external frames came from a hardware Gameboy CPU, but could have just as easily come from anything else - an Atari 2600, an XBox One, an iPhone, etc.
I had desire to do similar things but with a HP48 calculator. Basically have a beefy arm thing as a 'coprocessor' to unload long computations and let the calculator be mostly the user interface.
