back
38 comments
I hadn't seen this before. This is amazing, and well presented. I looked at some of his other videos like making programs that can also be ascii text.

Insane! Why solve such insane problems? I feel like the constraints are the kinds of things you come up with at a party with people you work with at 2am while drunk.

You should look at some other things the author did. They fit in the same area of craziness, and are absolutely great. For example https://www.youtube.com/watch?v=QVn2PZGZxaI, Portmantout: A portmanteau of every English word, or the first one, https://www.youtube.com/watch?v=xOCurBYI_gY, Computer program that learns to play classic NES games. I also liked the humor in What, if anything, is epsilon?, https://www.cs.cmu.edu/~tom7/papers/epsilon.pdf.
Insane that he used an older version of GL just so that he could use that headline. That just took it to whole another level:)
I suspect that he feels like me that glBegin and glVertex are very convenient to make low performance prototypes. When you initialize a gl context it is not always to feed it millions of polygons.
I just got the joke after you said that - legend is to glEnd. Wow!
Why solve such insane problems?

Because some people find it fun and it keeps the brain sharp. Conversely, I don't find hiking or playing cricket fun but millions do :-)

They are related to automated game AI. He tells it is another of his interests.
Tom also built Learnfun and Playfun, which was Lexicographic Ordering applied to... playing video games.

http://www.cs.cmu.edu/~tom7/mario/

Truly awesome stuff.

The Episode 2 video with learnfun/playfun is really good, too [0]. Tom7 is a fun guy.

[0] https://www.youtube.com/watch?v=YGJHR9Ovszs

What is the knowledge (low-level/math/computer-graphics/etc/etc/...) required to create something like this.

I am a student in 1st year currently. And I am very much interested in Emulation as well as crazy stuff like this.

Can anyone please explain in a bit of detail what all knowledge is required to build such a thing.

Familiarity with hardware would be a good starting point - the author explained how he can made use the three tables used by the PPU to pick out objects and textures. There is a lot of information about the NES online which would be useful references.

Then a good set of debugging tools, which is possible for NES games as there are many different emulators written in all sorts of languages which would make for a good learning resource.

To get more involved, investate open-source emulation projects - building them yourself. Then get more involved - try to fix an open issue - which will help you get familiar with the project. Read up on reverse engineering and ask questions!

With just a bit of Google-foo and some persistence, you can have working emulators of the 8-bit systems by the end of the summer if you put your mind to it.

While I've not used it, this website seems pretty solid: http://www.codeslinger.co.uk/pages/projects/gameboy.html (You may want to make other choices; personally I'd go straight to the gameboy because it was a real console and skip the Chip8, but your mileage may vary.)

It's an excellent project. Great on a resume, too; if I saw a fresh grad show me their Gameboy emulator they wrote from scratch my head would be turning. I personally would expect you followed a site like that and know it's perhaps a deceptively simple project compared to what most would expect, but I'd still be quite impressed, and you have a pretty decent chance of hitting an interviewer who quite overestimates its difficulty too :)

And the power differential between the Gameboy and a modern computer is so vast you can even use Javascript in a browser if you like. Use whatever language you like. C/C++ is still not necessarily a bad choice or anything, but don't fall into the trap of thinking you need their performance in this case. You've got gobs of power, you can afford any current language you like or would like to learn.

Having started, but not completely finished (time constraints) a GameBoy emulator, I would actually say it's deceptively difficult.

The "easiest" part is emulating the basic Z80 CPU operations, but even that implies the individual (truly) understands how a CPU works: registers, op codes, timing, MSB/LSB, addressing, program counters/jump instructions etc.

Now, you have to add on how cartridges work: the various memory bank controller types, bank switching, save states, etc.

Then, you have code to display video, emulate audio, and controls.

Putting all that code together, in a nice OO organization, is top 5% coder level stuff. Anyone that did that would almost certainly get a 'hire' vote from me. It's probably 10-20X the complexity of most demo projects I've seen.

> Now, you have to add on how cartridges work: the various memory bank controller types, bank switching, save states, etc.

There must be some subset of games that don't have a mapper. It's good to know when you start that it's something you might want to do later, but you can get tetris going with out it.

And the link I pointed at also just punts on sound, for another example of a corner that you can cut.

I actually whacked a paragraph about how said emulator will not be the fastest emulator and it won't be a perfect emulator, but you'll certainly have some running games, and for that all the things I said will still be true. Making an emulator that exactly matches the console is hard, but making an emulator that more-or-less runs a game isn't that hard.

http://www.romhacking.net/ is a great resource for finding documentation on how things like CPUs and memory layout for older game consoles works.
Google, stack overflow, and this guy's video are likely all you need to make a significant leap forwards.
Amazing and well-detailed video - kudos to Tom!

One question - what, if any, is the difference between the NES's PPU (Picture Processing Unit) and today's GPU?

The most significant difference between a graphics processor like the NES PPU and a modern GPU is that the PPU didn't have a frame buffer. There wasn't enough memory to keep an array of the color of each pixel on screen. The PPU worked instead with sprites and background tiles and color palettes and indexes into those tables. The PPU's job was to composite the scene on the fly while keeping pace with the scan-out to the CRT: the pixels' values were computed in order and just in time for the electron beam to draw them, one pixel being generated per clock cycle. It didn't have the time or memory or programmability to do any fancy 2D effects or transformations, let alone 3D.
In terms of 3D SNES graphics, the few later games that did support 3D graphics (e.g. Starfox) had an "enhancement chip" built into the game cart that allowed for it. And by "enhancement" I mean the SuperFX chip basically ran the game and the SNES just provided power and A/V out.
> And by "enhancement" I mean the SuperFX chip basically ran the game and the SNES just provided power and A/V out.

Sorta—there was no direct video out from the cartridge on the SNES (though oddly enough, there were audio out pins), so the Super FX chip had to actually generate sprites on the fly for the PPU to composite together. This resulted in unfortunate color limitations.

You can see in the debug info for Star Fox 2 that the dynamically allocated sprite count was something that they had to constantly keep track of: https://r.mprd.se/fup/up/35454-Star_Fox_2_(Japan)_(Proto)_(A...

How was it economically viable to, iiuc, basically include computational power comparable to that of a full console, inside every single game cartridge? That sounds ludicrous! (Starfox on SNES was an excellent game, enjoyed it very much!)
Well, the CPU they added was probably far less than $1/each when bought in bulk, so if you were making a PCB with chips on it already, you might as well add an extra processing unit.
For one thing, it's the ultimate form of copy protection.
But most cartridges used the same design. So if you had one SuperFX cartridge, you could put it in your copiers cartridge slot and then play all the others.
That was true of the DSP-1, but not true of the SuperFX or SA1.

The DSP-1 was a preprogrammed microcontroller that preformed certain calculations that would have been inefficient to preform on the SNES CPU. The inputs were written to a memory mapped location, and the outputs read back. An interposed copier could simply redirect these reads and writes.

The SuperFX and SA1 used the cartridge's ROM and RAM for program and data, and therefore these enhancement chips are placed between the SNES bus and the cartridge memory. The cartridge memory is unavailable to the SNES bus while the enhancement chip is executing, as in the SuperFX, or the the enhancement chip enters wait states while the CPU is accessing the cartridge memory, as in the SA1.

GPUs deal with rendering to framebuffers. Old school graphics chips didn't have the memory to hold an entire framebuffer (memory was expensive!), nor the speed to clear & repaint a full framebuffer at 60Hz, so they'd generate the pixel colors for each screen location on the fly in real-time as the raster scanned the CRT picture, from tile-based graphics definitions and a bunch of registers that controlled positions, scrolling, and other properties of a generally fixed set of graphics capabilities.

Many game consoles gave their video chip its own internal memory, so the CPU would hit memory mapped I/O ports to set registers, like palette values or the position of sprites.* At each line (or character, or however it's timed), the video chip would read the current value of the palette & graphics bitmap data and stream it out the analog video generator pixel by pixel in sync. Multiple layers (SNES, etc) or sprites would all be read "live" per scanline, and the chip would decide, based on transparency & priority, which object's color would be visible for that final pixel output.

Graphic screens were usually a grid with a byte per "tile" or "character", often an 8x8 pixel chunk, which offers a form of dictionary compression. The tile ID byte + tile gfx dictionary (gfx were usually 1-4 bits per pixel, for 256 8x8 pixel tiles) + palette info constitued the screen graphics formats, with a similar setup for independently movable sprites.

Many effects could be achieved by having the CPU change registers mid-way down the screen. It can do color gradients by updating the palette every line, change tile or scroll definitions for different sections of the screen (like having a non-scrolling score/inventory section, then flipping to scrolling graphics for the other part of the screen). Many video chips signaled CPU interrupts at configurable scanlines, or allowed the CPU to set up display lists which had address/value/screen-location tuples that it would execute as it drew the screen.

Because all of this was real-time generated, most games were 60fps. If there was too much going on in some frame then graphics were simply lost or ended up in the next frame with wild visual glitches because the timed gfx changes happened at the wrong time & place. Nowadays, GPUs paint a framebuffer, and display that framebuffer when it's done being drawn, yielding variable frame rate. Some non-action games did that back in the 80s as well, and it was often slow enough to see each step of the image being drawn.

[* = most home computers held gfx and palette info in their "large" main memory, with the video chip having exposed configuration registers on the memory bus, instead of tunneling through I/O ports]

There are a few comments about the video here that you might be interested in: https://news.ycombinator.com/item?id=11411054
The video states the UI is out of reach.. but screen scroll glitch

Being able to move the player's character around would also be useful for goal setting out of local maxima wrt AIs

Side note: I don't remember the graphics of Nintendo looking so terrible. Was it just that on a low resolution crt screen they looked good somehow?
Crt had colour bleed that blended the sprites differently and made things look better.
Yes, that's a factor. Zelda also isn't the prettiest NES game by a long shot; you might be remembering later titles with slicker artwork like Kirby's Adventure, Crystalis, Little Samson, etc..
This makes me wish I had gone to grad school.
Well, if you mean because you get to do fun stuff like this then yeah!

This work is not really a product of higher education though. It's one of creativity, tenacity, good programming and more than that a deep knowledge of the NES architecture! Most people have the capability to do the last two regardless of education!

The more I read about 8 bit computing the more amazed I am. Needing a very detailed knowledge of the underlying system was a given then, unlike today. What's massively impressive is that some hit games back then were developed by teens in their bedrooms (so no grad school!). Miles away from the game industry we see today!

Having hung out with Tom 7: Grad school didn't make him like this, he just has an absolutely insane level of drive to create cool things. I don't think he could stop if he tried. And like most things, the way you get good at "making cool and hilarious hacks / techno-art" is to do a lot of it. So start hacking! :-)
Might want to add (2016) to the title.
Thanks!