4 reasons for something being hard to emulate.
1) There was an extra chip involved.
2) There was some kind of weird input extra.
3) For newer machines doing dynamic recompilation then that method fails to work as much as it could by virtue of some code not being compiled as much as assembled.
4) Code exploiting non standard or esoteric implementations of the hardware that most emulators don't care to imitate, or possibly even know to emulate.
1) Most probably start with the SNES here (wikipedia I know but today at least they will give a decent overview
https://en.wikipedia.org/wiki/List_of_Super_NES_enhancement_chips ,
https://en.wikibooks.org/wiki/Super_NES_Programming/Super_FX_tutorial if you want to go further) and the "special chips" its carts sometimes carried that allowed it to do all sorts of processing extras. Flash carts and emulators then have to replicate these (or scavenge one from an original cart) to have it work. While the SNES is probably the most prominent there are any number of others -- everything from the more exotic NES mappers to the gameboy memory bank controllers mbcs to some of the N64 chips (though these were usually closer to anti piracy) to real time clocks where they might not have been present on the host systems (though some lump those in with 2) below, and it is not entirely unjustified).
2) Input extras are a fairly wide ranging one, and I will lump things like the dreamcast VMU and Sony's PocketStation in here as well. This can be anything from the various 4 player adapters built into carts on the megadrive to Boktai's solar sensor on the GBA, and the various tilt sensors of the GBA. You can also consider it other ways with things like the GBA link for the gamecube which allowed a GBA (a fully fledged device in its own right) to act as an input, and on the GBA where you had things like Legendz and Plaston gate which were some kind of precursor to the spyro skylanders
3) I have less of a list here but it is fairly obvious if you are familiar with the idea of dynamic recompilation. If not then dynamic recompilation was pioneered for practical purposes on the early N64 emulators -- it was noted that much code for the N64 was written in C and while you can't readily decompile it from a ROM you can do much better if you are running at the time and only want a snippet. This means that rather than emulating the whole system at varying degrees of accuracy you have a piece of code that is native to your system and thus far faster (an old rule of thumb was emulation would take a processor some 10 times more powerful than the host to emulate, the N64 was a 90 something MHz complex processor,
http://processortimeline.info/proc1996.htm for PCs of the same year).
4) Three links to start with
https://trixter.oldskool.org/2015/04/07/8088-mph-we-break-all-your-emulators/
https://arstechnica.com/gaming/2011...-3ghz-quest-to-build-a-perfect-snes-emulator/
Those will likely have covered much of the good stuff but there are all sorts of weird quirks that you can emulate, right down to the screen it runs on
http://bogost.com/games/a_television_simulator/
and as I am linking things like this
http://macgateway.com/featured-articles/sound-card-history/
http://nerdlypleasures.blogspot.com/2015/05/sound-card-replicas.html
As for the matter of the game and watch some have argued it is not emulation but simulation -- they were not processors as we know them today but a series of what would now be considered rudimentary logic operations.
