The Art of Emulation – Part 2

In my last post I was using the NES as my example system. I'm now switching to the Atari 2600. I didn't give any real details on the NES and I know a bit more about the Atari 2600. So, changing gears shouldn't throw any of you off the scent. I'm going to go into a little more detail here so that when I wrap all this up by explaining what Console Classix plans to do in the future it will all make sense.

The CPU is the Central Processing Unit within a computer system. It has a limited number of instructions that it can complete. These instructions are known as Op Codes. If you take a look at the 6502 processor that was in the Atari 2600 and compare them with a modern PC you will find, in many cases, identical Op Codes. For instance, ADC is used to add two numbers with carry. Both the Atari 2600 and a modern PC have to be able to this. The trick is that Op Codes are actually accessed by using a one byte number (for the 2600) to represent the code's location in the CPU. The numbers within the two CPUs are not going to match. (The following numbers are arbitrary guys, so if you're a 6502 expert ignore them, I'm not explaining this to you...) So, say ADC is 0x65 on the Atari 2600 and 0x3E on your home PC. If you just tried to run an Atari game on your PC it would run into 0x65 and instead of running ADC would do something totally different. The result being that it wouldn't work!

Now, some emulation authors have simply remapped the Op Codes in order to emulate the CPU. They create a kind of go between that takes the Atari 2600 codes and translates them for the PC. So when it runs into 0x65 in Atari software it translates to 0x3E and does it's thing. This is an elegantly simple method and is very fast. However, it comes with a number of limitations that I won't go into now. (Just run with the idea that rewriting the functionality of the Op Code in something like C++ is more flexible.) Whatever method the emulator uses it has to give the same results as ADC would when it runs into that Op Code. In the case of the CPU core I wrote for our Atari 2600 emulator (that may be released one day) I used C++ and provided the same results as the expected Op Code.

This has been a very long way of explaining that you have to grab the data that is destined for an Atari 2600 CPU then process it and return the same results. It's a complicated subject, but I am honestly trying to keep it simple. When you look at the data on an Atari 2600 cart a large portion of it is just calls to Op Codes one byte at a time. So you grab the data read off the cartridge and start with the first Op Code (0x65 or what have you) and then step through one at a time doing what each one is requesting to be done.

More before long...