Emulators 101: How To Write A Program That Functions Like An NES CPU

We’d bet everyone reading this article has played a game on an emulator at some time or another. And you may have a base idea of how those emulators work. But we’d wager the vast majority of you are clueless about the actual implementation of game emulators (we know we are). But that has all changed after seeing this demonstration of how [Bisqwit] wrote his own NES emulator. The description doesn’t cover anything more than the basics of writing code that emulates the NES CPU hardware itself. But it’s presented in such a way that makes it quite easy to understand for anyone who has a basic knowledge of programming. He starts with a switch statement for handling the processor’s opcodes and then moves through piece by piece showing how he refined his code to make it work while keeping it readable. We think this is a great teaching method and appreciate the time he put into producing this tutorial.

The explanation starts about 4:22 into the video which is embedded after the break. You’ll also find the first two demo videos there. Those involve mostly fast-motion text editing of the emulator coding process with some gameplay tests at the end of the second video.

Explaining how to emulate CPU operations (jump to 4:22)

Emulator programming & Demo:

[via Reddit]

27 thoughts on “Emulators 101: How To Write A Program That Functions Like An NES CPU

    1. I suggest you start with a CHIP-8 emulator. Simple CPU (well, more of a virtual machine), simple graphics.

      I’ve written one, then I moved onto a Space Invaders emulator. Problem was you would die as soon as the game started so I was obviously missing some flag or mis-emulating a Z80 instruction. Never could find that bug.

      1. Yeah I saw sprite_m’s article on the chip8 and I found it pretty interesting. I was considering that but I would love nothing more than to write an emulator that could play SMB.

    1. On my internet I can’t even watch youtube on the 240p setting in realtime, ie it buffering at a rate greater than me watching it. I have to wait a good 10 minutes to watch a 5 minute video….

      Video tutorials for me are useless, also they are harder to look back and forth over. I prefer a well written series of pages to read, maybe the odd 30 second video clip if needed.

    2. I wholeheartedly agree (also with the other comments to your comment). Videos can be a great addition to see something “in action” but as the primary means of delivery it is really bad (and there are so many ways to do it wrong; bad picture, bad sound, accents, etc)

      But I also think anyone who makes something have the right to present it in the way they want to. however stupid I may happen to find it :-)

    3. Actually I thought that the iterative coding in the first video provided a very effective way of explaining what he did that was really easy to follow. If I was trying to get any actual work done with this information I would probably be annoyed, but I actually thought the video was pretty entertaining to watch.

    4. I actually prefer the video. This may be a generation gap kind of thing. I usually feel that older people prefer written articles. I enjoy them as well but I usually will first try and get the info I am looking for in video format.

      Kudos to the author of the video. Great stuff!! I wonder what was the editor he was using.

  1. I have played with CPU emulation on a PIC18F before, (doing a 6502) it was always a toss up of writing code for each instruction or writing code that understands the bits in each opcode, that is to simulate the gates, etc… Trying to minimize and speed up emulation

  2. As a fellow emulator author, I have to say I’m impressed. I wonder how well this captures the odd overflow flag and BRK behavior. One strong advantage of this code is because it uses a decode matrix, it is much more likely to reproduce the behavior of the bare-metal 6502. Look at his code and then look at a physical picture of the CPU circuit. Mind. Blown.

    1. Hi BLuRry, thank you for your feedback. I just noticed this page here.

      My program passes all the most rigorous CPU tests that currently exist, but it probably does NOT handle the IRQ-BRK coincidence properly (there is no test that tests it, and I could not produce one even though I spend days trying to make one). But that’s allright, for there is probably zero games that utilize the BRK opcode in the first place. There were two bugs in the YouTube release concerning the CPU that I fixed later.

      One advantage of the opcode decoding matrix is that I maximally avoid any code duplication related bugs. In the real 6502 there is just one section in the CPU that does $action, and in my core similarly there is just one. There is no five different implementations. Mostly! It is not an authentic reproduction of the opcode decoding matrix though. It is still an emulator, not a simulator.

  3. An incredibly good example on how write-only code is evolved. Its good work!
    I dont know a compiler that will handle constants larger than… 64 or 96 bits (long long and long double) long long is 0x55AA669955AA6699
    An evil trick I do often thats similar is to use 64 bit variables for 4 bit strings.
    long long a = ‘HELP’; note the single quotes, compliler complains, but it works. good reason to make 4 character commands on console interfaces. You can test them in 1 instruction.
    I’m glad to see someone out there does optmizations as crazy as mine.

Leave a Reply to BLuRryCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.