What are the advantages/disadvantages of using retro hardware vs. FPGA emulation vs. software emulation? [closed]

Question

As someone who recently become interested in retro home computers of 80's and early 90's I'm wandering what are the differences between using a real hardware, FPGA based hardware emulators like MiSTer and the large amount of software emulators for different systems running on modern Windows, MacOS and Linux computers.

One thing which came to my mind is that both software and hardware emulators could be not precise enough to run all legacy software for the retro system which they are emulating without problems. But this seems to me like something depending on the quality of the implementation which can vary between different emulators and improve over time because of bug fixing, but not as a fundamental issue.

Also I'm hearing about the latency issue with the software emulators, but I'm a little surprised that something like this can really be felt on a computer which is probably millions time faster than the emulated machine.

Is there really a technical reason to prefer real hardware or FPGA based emulation vs. software emulation or this is just a nostalgia thing, caused by desire to fill like you are really back in the 80's or 90's?

Answer 1

An advantage which FPGA emulators generally share with vintage hardware is the ability to use devices that interact with the hardware in ways that are very timing-dependent. For example, if one has a game cartridge for the NES which triggers an interrupt every time the first line of data for a particular sprite is fetched, a console that reads out the contents of a cartridge and then emulates it would only be able to play the game correctly if it were able to recognize what the cartridge was doing with the interrupt line.

FPGA-based hardware would generally work as well as, if not more reliably than, vintage hardware, but there are a few weird quirks to bear in mind. Some prototype expansion cartridges for the Atari 2600, for example, relied upon the fact that even when the NMOS 6502 is trying to pull the data bus high, it's incapable of trying hard enough to either overpower an external device that's trying to pull the line low, nor damage itself in the attempt. Note that the reverse is not true: an NMOS device that tries to pull a line low while an external device is pulling it high can damage itself in the attempt (RIP 2600jr). If one were to plug into a modern recreation system an NMOS device which relied upon the ability to overdrive bus wires, and the system didn't limit the high-side drive current on those wires, it could damage the external device. I don't know to what extent that would actually be an issue, but since any devices that rely upon such techniques are probably rare, it would be very unfortunate if they were damaged.

Another potential issue is that vintage electronics were often rather slow to respond to signals, which meant that if a device were to very briefly output a signal on a wire, it would likely be ignored. Some vintage electronics would sometimes output brief glitch pulses if some combination of inputs changed between one state where the output should be low, and a different state where the output should be low. If an FPGA recreation isn't designed to ignore such pulses, they may cause erroneous operation on the recreated hardware even though they would have caused no problem on the original.

Personally, I think FPGAs are the best way of recreating systems. Vintage hardware is cool, but reliability is often problematic. Software emulation may work pretty well, but will be limited to interfacing with hardware the emulator designer knows about. A good FPGA-based recreation can interface with almost any kind of vintage hardware, including devices the FPGA designer knows nothing about, while offering better reliability than vintage hardware.

Answer 2

Preface: The question seams to ask for opinions, as it is opinion if someone accepts an emulation, no matter if software on a CPU or on a FPGA, as the same as the real thing or not.

---

Ask yourself, is driving a modern technology car pimped up to look like an SSK the same as driving the real thing? Do you want to ride a 1950s BMW with all it's sounds, smells and vibrations (and all the tinkering needed to keep it going) or a 2020 electric bike made to look like one, giving you the classic sound from a build in iPod?

---

I'm wandering what are the differences between using a real hardware, FPGA based hardware emulators like MiSTer and the large amount of software emulators for different systems running on modern Windows, MacOS and Linux computers.

If you're just a user, convinced with using your modern keyboard and modern mouse handling some image, that looks like 640 x 400, on your 4k screen, then software is all you need. Already a FPGA version will be overkill, as it uses the same modern devices.

On the other hand, if imaging is not enough, but you want to feel the bulky Atari mouse, the wiggly Amiga keyboard or the bulky C64 joystick, all presented with real CRT glare, then there is no other way than getting the real thing.

One thing which came to my mind is that both software and hardware emulators could be not precise enough

By now they are. in each and every detail. Modern hardware isfast enough to allow the use of HLL software to aquire cycle exact timing. Especially when all in and output is emulated anyway, mapped to modern devices.

But this seems to me like something depending on the quality of the implementation which can vary between different emulators and improve over time because of bug fixing, but not as a fundamental issue.

Lazy programming and maintenance doesn't invalidate the approach. For all purpose, except real hands on hardware, there is no difference.

Also I'm hearing about the latency issue with the software emulators, but I'm a little surprised that something like this can really be felt on a computer which is probably millions time faster than the emulated machine.

Maybe a hundred times, if at all. Keep in mind, most major components haven't gotten as much faster - and most of that has been eaten up by larger size devices and data needs.

The Latency issue is something that has been around since like always. There will be always some stating they can see/feel the difference. While this may be true in a few, very dedicatied situations it's rubbish most of the time. Claiming feeling a few microseconds, when testing a joystick already may cost more is simply fantasy.

Is there really a technical reason to prefer real hardware or FPGA based emulation vs. software emulation

What constitutes a technical reason for you? In itself the term is not clear when comparing complete different implementations.

or this is just a nostalgia thing, caused by desire to fill like you are really back in the 80's or 90's?

Have you ever sat in front of one of the old machines? It's surprising how different keyboards feel when leaving today's standardized equipment.

---

And then there is of course the hardware tinkering - not real fun with emulators, as here adding an interface is merely adding a few lines of code - or just configuration in some cases. No layout, not etching, no soldering and especially no cursing and patching until it works.

Answer 3

I'd like to clarify 'FPGA emulation' term mentioned in the question.

First, of course there is such thing as software emulation. Let's take as an example some (more or less) exact software emulators of the 6502 CPU. They try to emulate all external artefacts of the real CPU, such as number of cycles per each command, addresses of the memory accesses, and even 'internal state' (rather only the state of software-visible registers). Yet it has nothing alike with the real CPU, starting from the point it is pure software matter, not hardware device.

When any new feature of real 6502 is discovered (like new undocumented opcodes or flags or execution details), it is got inserted in the software emulator like 'another feature to implement'. No features of the real thing would emegre in the software emulator, if they are unknown to the implementer.

Then let's look at 6502-compatible HDL cores. They are now actually represent a real digital logic device -- or a model of that (in the case the HDL is simulated, not implemented in the real hardware like FPGA or ASIC). They now have real flipflop (or latch) storage for the CPU registers, they could implement real CPU bus signals and even be inserted in the retro computer instead of the original 6502. Yet they are made (more or less) 'from scratch', with the specifications of the CPU they are intended to replace, not its internal structure. And yet they would lack features not described in that specifications, that exist in real retro CPU, but are yet unknown to the implementer.

Another level of the reconstruction could be the HDL design built in the following way:

1. real retro CPU is decapped and photographed
2. then netlist and transistor-level schematics is recreated (either by hand or by some more or less automated tools)
3. netlist is converted to the gate level schematics and then to HDL description, that is in turn implemented in FPGA or ASIC.

Unlike previous cases, now almost all features of the real CPU become implemented 'natively', because the structure of the resulting HDL is more or less equvalent to the structure of the real thing (at logic gates and flipflops level).

Still there could be problems, for example 6502 has some instructions that behave erratically and I feel like such behavior wouldn't emerge in HDL naturally.

Generally speaking, I consider everything above the 'reverse-engineer, then recreate HDL' is actually an emulation, either in software or hardware, while the latter way is not.

In other words, let's consider preservation of the old software. We could run it on contemporary hardware, but if it is not available, software emulators come into play, yet the old software piece they are used to execute is still exactly the same.

Now we'd like to preserve old piece of hardware (CPU), but it authentic implementation is unavailable, so we recreate it using newer technology, but the logic structure of the CPU remains exactly the same.

Answer 4

To offer an answer on the latency question only, as an emulator author:

Exceptions abound but the general rule on original hardware of the '80s and into the early '90s is that joypad and keyboard input changes can be detected by hardware almost immediately after they happen, and that as video and audio is output from the machine it reaches the user almost immediately — e.g. for a classic CRT television the level the raster is painting right now is very nearly the live output of the machine.

With hardware now, input generally traverses a Bluetooth or USB stack, which may be inspected only at a certain interval by the host OS, and if anything has happened it then communicates that onward to the interested process which may or may not happen immediately depending on the specific scheduler.

Many emulators also implement a main loop that looks like how you might design a game:

1. collect all latest input and forward it to the emulated machine;
2. run the machine for a frame;
3. paint the next frame of output to an invisible buffer;
4. queue that up for display at the next vsync and block;
5. repeat.

For argument's sake, imagine your modern machine is very fast and that steps 2 and 3 are instant. Then:

• there's an average half a frame of input latency plus whatever Bluetooth/USB signalling and the OS added — any input that occurs just after the top of a frame won't be forwarded until the beginning of the next, any that occurs right at the end will be communicated at almost the right time, and the range of latencies in between is linear so the average is halfway between; and
• there's a fixed additional frame of output latency because you post a frame for presentation at the next vsync and then wait until it is time to be shown.

So with that simple loop, on ideal hardware, in the average case the delay between you pressing something and the screen reacting is around 1.5 frames more than real hardware. And that's only if host and emulated machines are running at the same frame rate.

Purists argue that some original games are so finely tuned, after the appropriate number of hours testing and tweaking back in the day, that 1.5 frames puts them at a disadvantage that they can detect.

FPGAs are usually* emulation, no matter how they're sold, because they're usually a person reimplementing a specification in a high-level hardware description language. But they seek to omit as much of that latency as possible — a good quality one will omit the video buffering entirely, run the rest of the system in real time and push input in with minimal delay.

* qualification added as per the correction provided by @lvd below. See his answer for more colour.

Of course, it's not hard to fix most of the software problems in software:

• forward input more often;
• don't use vsync to trigger new output to vsync; and
• don't use a double buffer.

In extremis, you can even race the raster for similar output latency to an FPGA — if you already have a high-frequency loop for frequent input, and if the base hardware supports any sort of output which can produce screen tearing, then you've got the tools.

Unfortunately such approaches weren't usually taken by emulators in the past, especially before latency became such a widely-discussed topic, and something of a negative image has stuck.

Answer 5

many aspects of the HW vs SW has been covered by other posts here so I will not touch them. Instead I would like to explain the LATENCY issue from mine point of view along with experience I acquired during coding my emulators for various platforms...

Making SW emulator on modern machines is much harder from latency aspect than it was back in the direct I/O access times. For home computers and game consoles we need to simulate/emulate sound,visual output and user input as precisely as we can. The biggest problem is with sound. That is because our hearing is much much better than any other of our senses and wee can feel/hear the difference if the sound is off by even few ms or Hz. If screen is off by 1 or 2 frames we can not see the difference. Also if the input is delayed a small bit its ok (for most of humans).

In modern machine architecture all is buffered (especially sound). So in order to output sound wee need to create a PCM data that is send over to sound chip and played through DMA+DAC. In order to do this usually 2 circular or many small linear buffers are used. Now to produce glitch-less sounds the buffers must be big enough. For example on Windows last time I check WAVEOUT needs at least 20-80 ms. DirectSound need >400 ms

Now if emulated program adjusts sound output it will outputted only after the already enqued sound is played out.

The same goes for I/O input on some platforms so the delays add up.

When you use FPGA then you have direct access to the sound output without any buffering. The same goes for input.

However game input latency (keyboard, joystick) have usually nothing to do with latency of the host system. The usual cause is that majority of emulators use clock tics to maintain emulated speeds. So they simulate the CPU or whatever and once reached desired number of simulated clocks per time they Sleep until next timer is issued or whatever. The faster the host computer the smaller time it needs to emulate hence the simulation will not react most of the real time.

For example let assume our simulation can run 100x faster than original speed of emulated computer. That means only 1% of time the simulation is doing something and rest is just Sleep(). During the Sleep the emulation can not respond to anything. So it can miss key strokes, fire clicks etc... To remedy that some emulators might use buffering again leading to the latency instead of ignoring input. There are also different style of controlling time that completely removes this problem. For more info about this subject see:

• Question about cycle counting accuracy when emulating a CPU

Answer 6

Vintage NTSC machines (and CRT Macs, etc.) can change their graphics output in the middle of CRT display refresh (part way down the vertical raster), thus tearing the image in response to real-time input.

Emulators using non-CRT monitors can’t do that in real-time, and can only fake a torn raster the next frame or field.

And the only way to test whether an emulation is accurate in to it compare against actual (ground truth) vintage hardware. See if there are are any undocumented hidden logic traps (defusion, etc.) or analog layout bugs under the various ASIC chip layers.