Retrocomputing Stack Exchange is a question and answer site for vintage-computer hobbyists interested in restoring, preserving, and using the classic computer and gaming systems of yesteryear. It only takes a minute to sign up.
Sign up to join this community
To my knowledge, an emulator turns machine code for a console into something that your computer can understand. For example, assembly code from a Gamecube game is not the same as from a .exe file.
That said, why are multiple emulators needed to run games that are on platforms that run 6502 code? Shouldn't there just be a 6502 emulator that runs all 6502 platforms?
Emulators emulate entire machines, not merely CPUs. Even the likes of QEMU emulate an entire generic computer.
It helps if you think of the Apple II and NES not as singular units but as networks of components. The CPU, graphics unit, RAM and so on all have communications to each other and do so at a very fast rate. In order to emulate these machines, you need to emulate each and every one of these components as well as the network itself.
The Apple II and the NES had different and incompatible ways of handling graphics, memory, sound data, and so on. Even the network with which the components communicate are different and incompatible. These all need to be emulated seperately from the CPU, and while the emulators could share 6502 emulation code, they can't do so for the rest of the network of components as they are fundamentally different.
There are many answers to this and none might satisfy you.
First of all, an emulator doesn't just do a CPU, but a machine. The same way you can't run an NES game on an Apple II. So while one emulator may do multiple machines, different emulators can do the job as well.
Furthermore, there are different target platforms. Linux isn't Windows which again isn't MacOS and so on. Like any other application, an emulator needs to interact with the platform it's running on - especially for tasks like timing and graphics on frame level a rather tight integration is needed - using functions that vary greatly on each OS.
Similarly, not only OSes do provide an environment to adapt to, generic Emulators (like Mame), or Browsers do as well, requiring similar adaptions.
Last but not least, since when has the existence of an implementation (here a 6502 emulator) ever stopped a developer from writing his own implementation?
If you look at something like MAME it's basically a container for all of the different parts that would make up an arcade machine - each chip has code dealing with it and each ROMs file contains the game code and then the actual machines themselves would have had standard motherboards that'd run multiple different ROMs for different games.
As has been said the CPU is one part of the puzzle but there's no reason that means those chips can't be modules of an overall system implemented once. As to whether that is the case for any particular emulator is another matter - part of writing emulators for old systems is the challenge and joy and communities that develop around supporting older machines. There are no commercial entities I'm aware of doing such things so these hobbyists are preserving part of computing history. Often these are individuals or small groups doing this.
The 6502's 16-bit address bus can address 65536 (64K) different memory locations. This memory space is shared by RAM, program code (ROM) and all input/output (video processor, sound generator, keyboard interface, etc).
There are some restrictions imposed by the 6502's design: on reset it looks at the top of the address space for a pointer to executable code, so this area must be ROM. The bottom of the address space is used for zero-page registers and the CPU stack, so this must normally be RAM. The rest of the memory layout is a blank canvas, and can be defined by the designer of the computer system.
Different computer designers placed components in different memory locations. On the Apple I, the cassette interface was at &C100, whereas on the BBC Micro it was &FE08. Programs would be written with explicit references to these memory locations in their code. The result of this is that they wouldn't run on other machines without being rewritten.
In the same manner, an emulator needs to place these components in the memory locations used on the original machine, as that's where the software will expect to find them.
It is possible to use the same 6502 CPU emulator with different interface chips and memory maps, to simulate different machines. The MAME emulator is a good example of this.
Another important thing is cycle accuracy. Not every emulator is cycle-exact!
Each emulator has a different level of accuracy. While it might seem unimportant, without it some games are impossible to play
Let's take the case of Speedy Gonzales. This is an SNES platformer with no save functionality, and it's roughly 2-3 hours long. At first glance, it appears to run fine in any emulator. Yet once you reach stage 6-1, you can quickly spot the difference between an accurate emulator and a fast one: there is a switch, required to complete the level, where the game will deadlock if a rare hardware edge case is not emulated
Or consider Air Strike Patrol, where a shadow is drawn under your aircraft. This is done using mid-scanline raster effects, which are extraordinarily resource intensive to emulate. But without the raster effects, your aircraft's shadow will not show up, as you see in the screenshot below. It's easy to overlook, especially if you do not know that it is supposed to be there. But once you actually see it, you realize that it's quite helpful. Your aircraft has the ability to drop bombs, and this shadow acts as a sort of targeting system to determine where they will land.—something that's slightly more difficult without this seemingly minor effect.
...
The screenshot below is a great example of a niche game. It's actually a very good platformer, but few people have heard of it. It's a great example of why just because most popular games can run decently with inaccurate emulators, accuracy still matters. You never know when that slightly-less-common favorite game of yours may run into a bug like this. In the below screenshots, you see a switch. When this switch is hit in any other emulator, the game deadlocks instantly. What is supposed to happen is demonstrated in the subsequent screenshots: the switch moves a block into the middle of an electrical field. It is required that this is done to complete the level, and thus, the game. At the time of this writing, bsnes is the only SNES emulator capable of fully playing this game.
Accuracy takes power: one man’s 3GHz quest to build a perfect SNES emulator
For some others it might be still playable, but much more difficult or with some glitches.
Another example is Chrono Cross. In the past when I tried it with different Play Station emulators, some features work in ePSXe but not in others and vice versa. For example some menu doesn't open or just open then close right away so you can't complete many tasks
