Building an NES Emulator

An anonymous reader writes: Programmer Michael Fogleman recently built his own emulator for the original Nintendo Entertainment System. He's now put up a post sharing many technical insights he learned along the way. For example: "The NES used the MOS 6502 (at 1.79 MHz) as its CPU. The 6502 is an 8-bit microprocessor that was designed in 1975. ... The 6502 had no multiply or divide instructions. And, of course, no floating point. There was a BCD (Binary Coded Decimal) mode but this was disabled in the NES version of the chip—possibly due to patent concerns. The 6502 had a 256-byte stack with no overflow detection. The 6502 had 151 opcodes (of a possible 256). The remaining 105 values are illegal / undocumented opcodes. Many of them crash the processor. But some of them perform possibly useful results by coincidence. As such, many of these have been given names based on what they do." It's an interesting look at how software and hardware interacted back then, and what it takes to emulate that in modern times. Fogleman released the source code on GitHub.

Comments

Re:Nice Project, But...

[aardvarkjoe]

The story isn't that somebody made an NES emulator. Those have been around forever, and this is going to be uninteresting if all you want to do is play Mario. The story is that somebody wrote an article about it for anyone who is curious about some of the details.

The article does focus mostly on the NES hardware, though, and I was expecting some insight on interesting or difficult points of writing the emulator itself.

BCD mode

[flargleblarg]

BCD (Binary-Coded Decimal) mode was cool because it changed the way adding and subtracting worked. If you added 0x01 to 0x29, you'd get 0x30 instead of 0x2A. This was possible because there were actually two carry flags on the 6502 — one (named C) which was set upon overflow of values greater than 255, and the other (named D) which was set upon overflow of the low nybble (e.g., the low 4 bits).

6502.org Tutorials: Decimal Mode

Re:BCD mode

[Anonymous Coward]

To those of you wondering why BCD instructions would be useful, it has a lot to do with doing math with character-based input.

Today, we're accustomed to parsing strings of digits to turn them into numeric types. However, this is actually quite costly, and it turns out that there's a much cheaper way to accomplish the same goals if you're only doing simple arithmetic with these values.

Let's say you want to compute "2" + "3". "2" is 0x32 in ASCII or 0xF2 in EBCDIC, while "3" is 0x33 in ASCII or 0xF3 in EBCDIC. It is no coincidence that the low 4 bits of a digit's character encoding (in either of the two most popular encodings) correspond to that digit itself; it is specifically to support BCD math.

I'll focus on ASCII for the remainder of this post, though this all applies equally to EBCDIC. All you need to do is mask things correctly (0x32 & 0x0F is 0x02, and 0x33 & 0x0F is 0x03) to "parse" character-encoded digits. Then you can just add them together (0x02 + 0x03 = 0x05) and OR the appropriate high 4 bits (0x30 for ASCII) to get back to character encoding land: 0x05 | 0x30 is 0x35, or ASCII "5". Much cheaper than contemporary number parsing and string building algorithms.

Of course, if we had values that summed to 10 or more, we'd need to use the BCD-overflow flag to handle results properly (as 0x05 + 0x05 would yield 0x0A, which when transformed back to ASCII is ":", not "10") . This gets us into packed-BCD territory, which is beyond the scope of this post (but which can be summed up as packing two BCD values into a single byte ((a4) | b), which means we'd want 0x05 + 0x05 to give us 0x10, the packed-BCD value that represents the decimal number 10), as that's how BCD values with more than a single digit tend to be stored.

BCD was a clever hack that enabled crappy computers to do a lot of work despite their slow speeds. Today, we just parse numbers in software, because it's no longer cost-effective to squeeze this level of efficiency out of our hardware. They don't make 'em like they used to.

Re:Little-known fact

[Anonymous Coward]

I don't understand how this makes them bastards.

Re:Little-known fact

[tuffy]

Nintendo VS system was an adaptation of their home hardware for arcade use, not the other way around. The Famicom predates it by years, remember.

Re:Little-known fact

[Joehonkie]

I logged on to say just this. OP can shut up.

Re:Little-known fact

[bsolar]

Everyone except millions of gamers finally able to play at home.

Am I that old?

[William Baric]

I read the summary and thought : why the fuck does it tell those common facts about the 6502. I mean who doesn't know this? And then there was this awkward moment when I thought to myself : am I that old?

Re:Am I that old?

[dannycim]

Funny coincidence, four days ago I woke up in an ambulance (long boring story) and the number on the inside door was 6502. I smiled stupidly and said "Hah! 6502!" and looked at the two EMTs sitting next to me. They looked quizzically at me.

"Oh right, I'm old." I said.

Opcodes still burned in my brain

[m.dillon]

I started serious programming (at around age 14) on the Pet. First in BASIC, but once I found out you could break into a machine language monitor by wiring up a NMI button (we called it the two-button salute), there began my machine coding. In HEX, directly. Didn't even have a relocator at the beginning. It was a year before I could buy the expansion rom to add disassembly and relocation features to the machine language monitor.

Ultimately I wrote an assmbler too. I don't think I have any of that code any more, it's been lost in time. Kinda makes me sad.

The PETs 8-bit IEEE-488 bus was pretty awesome. The PET had a 1 MHz 6502. The external floppy drive also had a 1 MHz 6502 in it, and you could reprogram it. So one of my many projects was to speed up the data transfer between the two by synchronizing the processors with a series of handshakes and then pushing or pulling the sector data without any further handshakes (using processor timing).

My friend did the same thing for the C64's serial interface (which didn't even have a uart) and sold a product called '1514 Flash!' that sped up the serial interface. Basically a little messing around at the beginning of each transfer to get the two sides synchronized within 1 clock cycle of each other and then pushing/pulling bits as fast as the little cpus would go without any further handshaking. The clocks would stay synchronized long enough to copy a whole sector.

Other projects on the PET... it had a character generator rom which I replaced with a static ram. so when I powered it up I had to load a copy of the original rom into the ram blindly (because the display was total garbage due to it being an uninitialized ram).

The PET had built-in CRT screen but the key was that the data input for the screen was actually a TTL input! So I could pop the wire off the connector and use it like a digital oscilloscope to probe various TTL-based projects (as well as the PET's motherboard itself).

Another project...the character generator rom had something called quarter-block graphics. Basically 16 characters that had all 16 combinations of four quarter-blocks (2x2), so you could (I think) 320x200 graphics on it. I spent many hours optimizing the machine code to generate a pixel pusher.

I got so good at writing editors from scratch, once when I went to computer camp and forgot to bring the tape I rewrote the text editor in machine code in less than an hour.

Met Richard Garriott at that camp too, we were both on staff. He was working on (I think) Ultima II at the time (on an Apple II I think) and had an awesome ram disk for storing code temporarily while he was working on it. Once his computer stopped responding and after unsuccessfully trying to resurrect it he finally gave up and power cycled it, losing his work in the ram disk. It turned out he had accidentally disconnected the keyboard and the computer was actually fine. Oh well! Richard taught a class at that camp on human-interface parsing... basically had people write a dungeon game where you typed in what you wanted to do in English. Primitive of course, but the kids had a blast.

I wrote a centipede game in machine code, incredibly fast and awesome (the last level the centipede was invisible and only blinked into existence for a second or two every few seconds), and submitted it to Cursor magazine. They rejected it because they thought I had stolen it from someone :-(. The only thing I ever tried to get published, rejected because the code was *too* good!

The 6502 had two awesome indirect EA modes. (TABLE,X) and (ADDR),Y, along with the standard modes.

Decimal mode wasn't as interesting, I wound up not using it for display conversion at all.

The 6522 I/O chip was an incredibly powerful chip for its time, with multiple timers and timer-driven events. It had a few bugs, too.

I remember all the unsupported machine codes the 6502 had. It was a hardwired cpu so all instruction codes did *something* (even if it was mostly to just crash the cpu). LDAX was my favorite. Mostly, though, the hidden codes were not very useful.

The list goes on. Twas an awesome time, a time before PCs took over the world.

-Matt

Re:Little-known fact

[MightyYar]

The VS system didn't come out until after the NES (well, the Famikon version from Japan). You have the timeline backwards.

Many of the cabinets on VS machines are older because they were converted Donkey Kong or Mario Bros cabinets.