I have always found emulators rather fascinating. I would seriously like to create an emulator for an older ganeration console or handheld. It would help me gain a greater appreciation of the hardware and the games which were created for that hardware. However, people are always saying how hard it is and that I should not even try. I would like to know why that is.
Also, I would like some suggestions on a good place to start and where can I find the information I need?
This seems to be a popular resource about how they work.
TL;DR - The architecture is totally different, and this takes a lot of parallel resources to achieve the original architecture.
The CPU architecture for game consoles is often somewhat exotic compared with your average desktop machine. Emulation means to perform in software everything that the original hardware did. That is, while the original console may have had dedicated graphics, audio, etc. chips as well as a CPU with a different instruction set, the emulator must perform all the functions of these parallel resources at speed.
Unless the console's GPU is old, it almost certainly must be emulated on the GPU of the host machine, as modern graphics cards, even cheap ones, have many times the throughput (for graphics workloads) of even the most expensive multicore CPUs. Compounding this difficulty is the fact that communication between CPU, GPU, any other onboard DSPs, and memory was probably highly optimized on the console to take advantage of the specifics of the hardware configuration, and therefore these resources must be rate-matched as well.
Compounding all these difficulties, usually little is known about the specifics of the console's hardware, as this is kept very much under wraps by design. Reverse engineering is getting less and less feasible for hobbyists to do.
To put things into perspective, an architectural simulator (a program which can run, for example, a PowerPC program on an x86 machine and collect all sorts of statistics about it) might run between 1000x and 100000x slower than real-time. An RTL simulation (a simulation of all the gates and flip-flops that make up a chip) of a modern CPU can usually only run between 10Hz and a few hundred Hz. Even very optimized emulation is likely to be between 10 and 100 times slower than native code, thus limiting what can be emulated convincingly today (particularly given the real-time interactivity implied by a game console emulator).
A major difficulty with trying to develop emulators for older machines is that on such older platforms, there are aspects of behavior which weren't intentionally designed to fit together in any particular way, but nonetheless happened to fit together in ways that some game designers have exploited. Sometimes these aspects of design may be documented, individually, in a way that would imply their interactions, but in other situations they might not.
For example, on the Atari 2600, storing a value to HMP0, storing a value to HMOVE on the first cycle of a horizontal blanking, and then waiting awhile before writing to either HMP0 or HMOVE, will cause the player 0 sprite to be moved to the left by a signed 4-bit number of pixels specified in the upper bits of HMP0, i.e. anywhere between 7 pixels left and 8 pixels right. As a side effect, the first 8 pixels of the next scan line will be blanked. If the store to HMOVE happens two cycles before the start of horizontal blanking, however, the start of the next scan line won't be blanked but all sprites will be moved to positions 8 pixels to the left of where they would otherwise have gone. Some programs exploit this to avoid having to the system blank the leftmost eight pixels of the line after the HMOVE.
If the designer of an emulator is aware of this behavior, it may not be particularly difficult to emulate, but the designer of an emulator isn't aware that the HMOVE circuitry works this way, programs that rely upon it would not be emulated correctly. Emulation of older systems is difficult because it's impossible to know about all the behavioral quirks that programs might be expecting. While one could take the attitude that any game which performs an HMOVE two cycles before the specified time is "broken", such an attitude would imply that all games must forego the use of the leftmost 8 pixels on the line after any sprite is moved. Code which uses cycle-74 HMOVEs may be able to achieve a cleaner looking display, and will work either on original vintage hardware or on emulators that support that behavior. Accurate emulation of all games would require knowing all of the aspects of hardware upon which those games would rely, which would be impossible on any system for which unreleased prototype games might exist.
