#zero_page

The MOS 6502 was an incredibly adopted chip for its time. It showed up in many famous computers and entertainment systems of that era. It did, however, have some drawbacks. Namely, there were a lot of known bugs that exist on the chip. While these were mostly straightforward to work around, the chipset was later extended with the superior 65C02 chip.

Not only did the 65C02 fix the quirks of the original chip it was based on, it also added some handy extra opcodes for programmers to utilize. This chip was further extended by Western Design Center to include a little-known instruction: WAI.

The purpose of the instruction was to effectively shut down the chip's power consumption and wait for an interrupt to come from the hardware in order to wake it back up. This would allow programmers to suspend execution of a program while also drastically reducing its power draw.

Electrical power isn't necessarily very interesting in this case, but I do have cases where terminals are running software that want to wait around for the game engine to poke them awake again. Pretty much exactly like how the WAI command was meant to be used. But instead of taking less electrical power they can now take less processor power.

It's worth noting that the emulator works by running a fixed amount of processor cycles per frame to run at the proper 1MHz that the Apple II ran at. Even if the machine is just sitting in a loop waiting, that waiting requires as much processing power as when the emulator is crunching a lot of numbers. Cycles are cycles, whether they're doing real work or just idling. So the WAI command allows me to specify when the game should just ignore the terminal and cut its cost.

What followed was a lot of learning about the early days of computers and how machines of old linked their hard and software unlike anything we're capable of doing these days. There's a real simplicity and cleverness to how it all hangs together, and I think it's worth anyone's time to jump head first down the rabbit hole of building an emulator.

A Quick Caveat

Before you fire up your favorite compiler and start typing up your own NES emulator, it's worth noting that you're starting down a path many have gone down before. Spending five minutes on an emulator enthusiast bulletin board will give you handfuls of links to people's half-finished work. There are some really bulletproof emulators around these days, mostly because there's a wealth of experience and knowledge (and documentation) around the whole thing. There are a few novel examples of people doing new things in the space, but for the most part it's a solved problem.

So if you're going to go down this road, just know that few people are going to congratulate you or be very interested in the end result. Don't spend too much time coming up with a catchy name for your emulator, because at the end of the day no one is going to choose it over what's already out there.

Why Bother?

So if it's been done before, why bother? Well, for one it's a wholly unique experience in the field of programming. Usually when you build something that has a high tech investment you're dealing with a lot of variables. You don't know exactly what specifications you want to use for it. How much memory would it need? What's the video resolution? How does the controller work? Typically you would iron these details out over months or years before you could even think of building the first product to actually run on it.

Emulators don't have any of these problems. Your task is to recreate the behavior of a known piece of hardware as exactly as you can. Everything about the machine is generally available for your inspection so you're working from a complete and "shipped" technical spec. What's more, you have a massive (and generally very familiar) set of products that have already shipped on the machine. So you have all the known test cases in the world at your disposal at any given time. This means that you don't have to build complex systems and hope an artist or designer can figure them out and use them, you just have to make Mario jump on the screen and have it scroll to the next (which is actually easier said than done).

What you're in for, generally, is a lot of debugging. And if done right this is a fantastic way to get better at that crucial skill set. You'll most likely sit down and read a piece of the documentation for the hardware, write your first take at it, fire up a ROM to check it against, then invariably scratch  your head at the weird result you see. Then you'll check the docs again, cross reference with some other sites, look at the code again, step through it all, rinse, repeat. It can be really tedious and confusing sometimes, but it's incredibly fulfilling when you fix an issue and suddenly a big chunk of a game comes to life before your eyes. That fulfillment generally diminishes a bit when you find the next issue, but over time you see your work get more and more robust, playing a greater number of titles.

Which is the other great thing about making an emulator: It's a lot of fun to test it! You're playing games you may have grown up with, but now you're seeing them through fresh eyes because you know how the sprites are being drawn on the screen and how the color palette works. You appreciate the logic being strung together in 6502 assembly code, and just how little resources were available to make these great titles.

For all those reasons I think it's a really fantastic project if you like to code. Just know when you're into the point of diminishing returns on making your emulator "perfect". It's driven many a coder insane, and as mentioned before, other people have already climbed that mountain before you.

Where to Start?

There are plenty of good resources for learning about making an emulator. It's going to be tempting to want to dive in and figure out how to draw things or make sounds (spoiler: the latter task sucks) but I would stress that you'll want to start out with a solid 6502 emulation. The 6502 is the processor at the heart of the NES. It was cheap and relatively powerful for its price point, so it found its way into many well-known products of that era. The nice thing is that it's also a fairly simple thing to wrap your head around once you get started. I won't go into the details of the registers and status flags, there are plenty of resources for that as well. What I would say though is to get a CPU unit test program like nestest to verify that your work is behaving properly. Writing an emulation for the processor is tedious, but gloriously so. You implement an opcode, test it, and watch it do what you expect. Then you move to the next and repeat. You slowly build up not only a working processor but also your understanding of exactly what it's doing.

One tip I would give you is to pay attention to cycle counts as you write this. It seems pointless when you're just starting out, but being wrong by even a few cycles here or there can cause lots of headaches down the road. The documents will tell you exactly how to count cycles, so just get in the habit of doing it as you go along.

Next Steps

Once the nestest ROM is working, you're ready to start seeing something on the screen. When I started I wanted to jump into the background images first, but I would suggest a different tack: once you have the barest background working, move on to sprites. Why? They're simple and they will show you real working code faster. The first time I could see characters moving around on screen with real code controlling their movement it was like magic.

Now at this point you're going to go out and download Super Mario Bros and try to get it running right away. Don't do that. I did that starting out as well thinking that since SMB came with the system it must be fairly rudimentary. But sadly SMB is not rudimentary and it's not straightforward. It will bite you in a bunch of different ways I can't even begin to explain yet, so just put that ROM on the shelf and come back to it much later.

Instead, try something simple like Balloon Fight. Never heard of it? Neither had I, but it's basically a Joust-alike. What makes it a good choice is that it is actually straightforward and has no scrolling. This means you can pretty rapidly go from nothing on the screen to seeing things moving, to actually controlling those things and playing the game. I ironed out a lot of issues on that ROM before ever setting foot into another.

Off Into the Wilderness

Once you've got those basics working it becomes more of an open exploration of the software space. Do you want to handle scrolling and memory mirroring? Maybe you want to run a certain title so you'll need to wrap your head around memory mappers to actually get at the data. Or you've got those working and you're wondering why your backgrounds don't scroll like they should. Have fun with "sprite zero" collisions! Once you've got a foothold and you can see things happening on the screen, you're either going to be hooked or exhausted.