Uploaded on Dec 4, 2011
In this tool-assisted education video I create a NES emulator with C++0x. You see me type every line.
The emulator is very accurate, and sort-of portable; it compiles on any architecture that support libSDL, but it outputs audio through an external program and reads joypad input from a file.
This video is part 1/2.
-- Part 1 ( http://youtu.be/y71lli8MS8s ): Creating the emulator.
-- Part 2 ( http://youtu.be/XZWw745wPXY ): Compiling and running.

The source code is about 940 lines in total.
Download & resources: http://bisqwit.iki.fi/jutut/kuvat/pro...
FAQ: http://bisqwit.iki.fi/jutut/kuvat/pro...

Approximate count of lines of code per topic, in the source code:

• 20 lines, CPU: Declarations (registers, flags and internal memory)
• 100 lines, CPU: Interpreting and executing CPU opcodes & signals
• 100 lines, CPU&GamePak: Memory mapping (iNES mappers 0,1,2,3,7 are supported)
• 40 lines, PPU: Declarations (registers and emulator-specific status variables)
• 50 lines, PPU: Memory mapping and I/O
• 180 lines, PPU: Rendering and timing control
• 30 lines, PPU & IO: Joypad updating (PPU provides the timing for input-file access)
• 40 lines, PPU & IO: Color NTSC emulation (converting NES colors into RGB through NTSC modem)
• 15 lines, IO: libSDL initialization and rendering
• 35 lines, main&IO: ROM loading from file, initialization and emulation loop
• 200 lines, APU: Sound emulation (of which 40 lines are because of DMC/DPCM support)
• 130 lines, (other, such as comments, and inaccuracies in the above numbers)

Background music: Jinguji detective series. It was difficult to choose. I wanted good NES music, but I did not want it to too recognizable. I intended to convert something, but I had already spent months on this video... It was getting late.

Because of the 15 minute limit that YouTube still imposed on my account when this video was posted (for some reason that never got explained); I had to develop many techniques to shorten the code dramatically. I also had to type it very quickly... And I had to split the actual demonstration into a second video.

I use C++11 exclusive techniques extensively in the code. I am particularly proud of the CPU emulator. It is cycle and memory access accurate, and feature-complete. It is not very slow, either. It is only 100 lines long, thanks to a number of clever ideas. I thank byuu for a particular idea that helped make it horizontally shorter. Each if() in ins() is completely parsed and evaluated at compile-time. Effectively the compiler synthesizes 259 distinct ins() functions, each performing only the particular opcode's worth of work.

I architected all the components in as close conformance as I could to whatever documentation I found on nesdev.com regarding how they work. There may be a few minor shortcuts that I took in order to avoid the trap of investing 90 % of source code to fix a problem that affects 10 % of games.

In design, my primary guiding principle was the assumption, that the hardware was always designed for simplicity (with regards to chipspace consumption). Most compact design that gets the work done. This means, that whenever there is a behavior that seems to require extra-ordinary amount of work (code-lengthwise) from emulator authors to replicate accurately, I would take the extra effort to try and see the big picture and figure out how to generalize it. If the hardware does unproductive work at time, it is because they reused some component and did not needlessly create a special case to disable the component for those times where its function does not produce benefit. I would, rather than adding a special case to replicate that unproductive work, also find a way to reuse a productive part, so that the unproductive work comes automatically as a side effect, just like on the hardware.
I always tried to replicate that simplicity in my emulator. I think I managed quite well in that regard. It is not perfect though: It does not pass all tests by Blargg, and some games that should run, outright crash at start. But the compatibility according to my tests is still very high, and interestingly, many TASes made with FCEUX run also on my emulator.

Note that creating an emulator is perfectly legal. I wrote all the code from scratch; it comes from my mind, and is therefore entirely my copyright; it is not anyone else's copyright. I believe that programming is art, and my code is my means of expressing myself. There exists no legislation that prohibits anyone from e.g. printing this source code on a t-shirt (assuming that I gave permission to that). I am also not selling this as a product, i.e. even in the dystopian event that I should happen to be using algorithmic methods that someone else has previously patented against every notion of conscience and wisdom, I am still not infringing on any patents. Or so I believe.