Ludde's FPGA NES
fpganes.blogspot.se
fpganes.blogspot.se
http://en.wikipedia.org/wiki/Ludvig_Strigeus
Edit: He added his previous projects to his profile after I wrote this comment.
uTorrent is kind of a good example for the 'monetize by bundling crapware' category of software, btw.. I recommend forgetting that this software existed and moving on to sensible projects.
If you click through the quaint image map it's actually a fairly detailed description of what he did. Actually, explore his whole site, Kevin was a true emulation scene legend and his projects were all wild.
A group of guys I know did a similar piece of work when creating the Ms Pac Man / Galaga 20th anniversary machine for Namco. They took the original Ms Pac schematic (Z-80 based), a board that looks like this:
http://images.cloud.worthpoint.com/wpimages/images/images1/1...
and shrunk it down to a couple of FPGAs and an EPROM:
> The NES contains a Ricoh 2A03 CPU, virtually identical to the MOS 6502 CPU used in Commodore 64, but includes an on chip APU (Audio Processing Unit), while removing some CPU features such as Binary Coded Decimal arithmetic, supposedly to avoid paying patent royalties. Side by side to the CPU is a PPU (Picture Processing Unit), which is responsible for generating a 256x240 sized image.
The NES is a popular choice, but many other game consoles and computers have been modeled as well
There's another project called the Powerpak, which is essentially an FPGA programmable flash cart. You can put it in your nintendo, and it will allow you to play nintendo roms stored on a CF card. What might help you about this, I think, is that the mappers are loaded dynamically off the card. So this allows the creator of it to add support for more mappers as time goes by. I don't know if this would help you, but maybe you could use this for your own project as well? After all, if your FPGA nes is the same as a normal nes, then you could use an FPGA flash cart to load all your games. At the very least, maybe looking at the mappers would help you out.
The thing is, game designers are all about juicing functionality. If they could take advantage of something that isn't in the spec ( like the extra instructions the author mentions ), they probably did. So you have to find all the common mis-behaviours, some of which might have been side effects of analog components included in the console. Similarly, the analog hardware on your FPGA board is probably nothing like what the original console contained; the sound and video output are hard or impossible to get right.
In short, you can avoid the conditions that they discuss like deadlocks more easily in a VHDL design, but things like the colours in the video may be impossible to get right (the author points this out as well).
On a side note, I don't fully agree with the linked article's 'twice as accurate, twice as slow' hypothesis. A lot of the cases they discuss are either analog effects which are expensive to reproduce in a digital emulator, or just hardware edge cases which don't add a lot of processing overhead. Basically, recreating a quirk can be very expensive or pretty cheap computationally, and there's no reason to say they'll average out over time.