Familiarity with hardware would be a good starting point - the author explained how he can made use the three tables used by the PPU to pick out objects and textures. There is a lot of information about the NES online which would be useful references.

Then a good set of debugging tools, which is possible for NES games as there are many different emulators written in all sorts of languages which would make for a good learning resource.

To get more involved, investate open-source emulation projects - building them yourself. Then get more involved - try to fix an open issue - which will help you get familiar with the project. Read up on reverse engineering and ask questions!

With just a bit of Google-foo and some persistence, you can have working emulators of the 8-bit systems by the end of the summer if you put your mind to it.

While I've not used it, this website seems pretty solid: http://www.codeslinger.co.uk/pages/projects/gameboy.html (You may want to make other choices; personally I'd go straight to the gameboy because it was a real console and skip the Chip8, but your mileage may vary.)

It's an excellent project. Great on a resume, too; if I saw a fresh grad show me their Gameboy emulator they wrote from scratch my head would be turning. I personally would expect you followed a site like that and know it's perhaps a deceptively simple project compared to what most would expect, but I'd still be quite impressed, and you have a pretty decent chance of hitting an interviewer who quite overestimates its difficulty too :)

And the power differential between the Gameboy and a modern computer is so vast you can even use Javascript in a browser if you like. Use whatever language you like. C/C++ is still not necessarily a bad choice or anything, but don't fall into the trap of thinking you need their performance in this case. You've got gobs of power, you can afford any current language you like or would like to learn.

Having started, but not completely finished (time constraints) a GameBoy emulator, I would actually say it's deceptively difficult.

The "easiest" part is emulating the basic Z80 CPU operations, but even that implies the individual (truly) understands how a CPU works: registers, op codes, timing, MSB/LSB, addressing, program counters/jump instructions etc.

Now, you have to add on how cartridges work: the various memory bank controller types, bank switching, save states, etc.

Then, you have code to display video, emulate audio, and controls.

Putting all that code together, in a nice OO organization, is top 5% coder level stuff. Anyone that did that would almost certainly get a 'hire' vote from me. It's probably 10-20X the complexity of most demo projects I've seen.

> Now, you have to add on how cartridges work: the various memory bank controller types, bank switching, save states, etc.

There must be some subset of games that don't have a mapper. It's good to know when you start that it's something you might want to do later, but you can get tetris going with out it.

And the link I pointed at also just punts on sound, for another example of a corner that you can cut.

I actually whacked a paragraph about how said emulator will not be the fastest emulator and it won't be a perfect emulator, but you'll certainly have some running games, and for that all the things I said will still be true. Making an emulator that exactly matches the console is hard, but making an emulator that more-or-less runs a game isn't that hard.

http://www.romhacking.net/ is a great resource for finding documentation on how things like CPUs and memory layout for older game consoles works.

Google, stack overflow, and this guy's video are likely all you need to make a significant leap forwards.