If I had a hypothetical computer just like nowaday's computers, but it had an NMOS 6502, would it provide me with a better emulation experience than if I were to emulate the 6502 inside software? Also, would it make a difference to have the PPU's chips as well?

  • It really should be called "simulation" instead of emulation. As in all simulators, some aspect of the real/genuine always suffers. That said, the latest NES emulators ("simulators") have excellent fidelity. So, just toss your old NES console into the trash, right?
    – Brian H
    Commented May 25, 2020 at 17:12
  • A simulator only outputs a representation of what the real device would do, but an emulator replaces actual hardware. A console simulator would just show the contents of registers and memory etc. as it ran, but a console emulator allows you to play games on it just like a real console. Compare to eg. a flight simulator - screen display shows what the real aircraft would have done, but it won't fly you anywhere. Commented May 27, 2020 at 21:24

4 Answers 4


For purposes of emulating program execution using only new hardware, I don't think inclusion of vintage components would be particularly helpful except in cases where behavior would be affected by aspects of the original that aren't fully understood, or could vary in "interesting" ways (e.g. because waving one's hand over the machine would affect the value seen by the CPU during an "open-bus" state).

On the other hand, if one has a cartridge that's designed for use in vintage equipment, and relies upon precise signal timings, using a vintage CPU might be helpful. Many modern machines have an average instruction execution speed that is more than three orders of magnitude faster than vintage consoles, but that average speed comes at the expense of variability. A 6502 that receives a value on the data bus at the end of one cycle can forward it to the address bus at the start of the next cycle (but not before the end of the one where it was fetched!), and a game cartridges may rely upon such timing. A modern CPU may be able to execute billions of instructions per second, but that doesn't imply an ability to perform any particular operation within a 50ns window. Someone who was in control of the operating system could almost certainly arrange things so the worst-case timings would meet requirements, but guaranteeing that may be hard while running any kind of time-shared OS even on a multi-core system (if one core is talking to the cartridge while three other cores are running programs that access memory in such a way that data the first code is going to need gets evicted from cache, and they then have cache misses just before the first core gets a cache miss on that data, the first core may have to wait awhile to get its data).

I think the best design approach for an emulator is to use FPGAs. Those can mimic the timing of native hardware very precisely, and should be compatible with a wide range of cartridges that use the bus in interesting ways, without the emulator having to know or care what the cartridge is doing. For example, some cartridges may include a RAM which has one of the address wires open-circuited (I think Qix did that with A1). This effectively creates pairs of addresses, two apart, such that reading either address of a pair will yield the last byte of data that was written to either address of the pair. An emulator that knows about that could simulate that behavior, but an FPGA-based emulator could yield proper behavior without have to know or care about what the cart was doing. If a cartridge fetches a byte from RAM when given one tile-row address, and then fetches a byte from the same piece of RAM when given a different address, the PPU wouldn't need to know or care where those bytes came from--it would simply display the second row like the first because it received the same pattern of bits.


Well, if your computer had a 6502 and the PPU & PSG (for the sound) chips, then it would be basically a NES, so there would be little left to emulate.

Now if your computer only had the 6502, and the rest to emulate, no it wouldn't change, since nowadays emulation cores for 6502 are cycle exact, so it wouldn't be that interesting to have a real 6502 in your machine.

Plus, without the other chips, you would have to interface the 6502 with some other sound & video hardware, which isn't exactly a piece of cake. The video isn't really an issue, because video memory is usually scanned periodically and drawn to screen, but sound emulation usually requires to intercept read and writes to given memory locations...

The more interesting chip to have would probably be the PSG for a super-faithful sound, and also maybe the PPU if an analogue output could be connected for a real analogue feeling.

The closest real-life example I can think of is the capability (now lost) that old versions of MAME had to use Soundblaster (inc. AWE64) Yamaha chip directly for games that had that chip in their hardware (Dragonninja for instance). This produced super neat FM sound and that was really cool.

  • Ok but If I did have a real 6502 in my computer, wouldn't it be more accurate than just a software-based one, since it is real hardware? Commented May 25, 2020 at 17:02
  • No. "Cycle exact" means that the emulation core's behaviour is indistinguishable from real hardware.
    – ssokolow
    Commented May 25, 2020 at 17:08
  • 2
    @MarkWilliams 6502 emulators on a computer are likely to be cycle-exact. I'm not sure if emulation of the N64's MIPS-ish CPU is an issue; the most notorious problem is the Mario Kart in-game video screen, which relies on the code being able to read from video memory, something that's hard with modern GPUs. It's not about the CPU, and it's a similar issue to Fabre's answer.
    – prosfilaes
    Commented May 26, 2020 at 7:07
  • 1
    N64 takes really a lot of CPU and is way more complex. And being 100% accurate would eat too much CPU for most cases The aim of emulators in that case is to make games work even with small graphical glitches or such. On NES the aim is to be 100% accurate given that the chips are way simpler and a modern CPU can take the overhead to avoid taking shortcuts Commented May 26, 2020 at 7:43
  • 1
    about GBA emulation on NDS, the main problem is that games are designed with ARM7 and GBA architecture in mind, if you run that on a faster processor you have issues (see my related answer here: retrocomputing.stackexchange.com/questions/13531/…) Commented May 26, 2020 at 7:45

There is currently lots of development around FPGA implementation of old game consoles and computers.

A FPGA is a reconfigurable chip which can be programmed to implement any logic circuit, including CPUs, video controllers, .... It is now possible to implement NES, SNES, Genesis... on affordable hardware (<200$).

Compared to emulators, an FPGA implementation can sometimes be more accurate (because it's easier to implement cyle exact concurrent behaviour of hardware than with emulators) and with lower latency (same latency as actual hardware, not needing the drivers, OS, USB bus... of an hosted emulator)


No, and very probably no.

Emulating a 6502 cycle-exact and in real time is well within reach of even a 30 year old 486, so there is nothing to be gained by using a real 6502, or modern successor.

As for "the PPU", that's a bit vague (what are its capabilities?), but all of the standard 80's video chips have been emulated quite well for over a decade. You may want to check retrolib or MAME for what's available. Is there anything in particular you are missing?

  • 1
    The only exceptions I can think of are non deterministic chips like the SID, which are hard to emulate. For everything else, CPUs are finite state machines. Commented May 25, 2020 at 17:08
  • 1
    @MarkWilliams I took PPU to mean Picture (or Pixel) Processing Unit, i.e., some kind of video circuitry. For sound synthesizers, you are correct. Commented May 25, 2020 at 17:39

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .