The I/O latency is typically much closer to the original hardware. OSs have become a bit careless about latency, and LCD screens add some more delay on top. It all adds up, and the result is a slightly inauthentic-feeling experience.
Hardware emulation can make the timings between multiple chips more accurate as processes actually can be done in parallel and in sync with a shared clock. This is harder to get perfect with software emulation. In theory.
Hardware emulation cannot actually make the emulation more accurate than software emulation. That doesn’t make any logical sense. If you know what the correct timing is, you can emulate it in hardware or software.
It’s not harder to do in software. It’s just hard to get the timing correct, regardless of whether you are using software or hardware. There are certain cases where it’s hard to get good performance out of a software emulator, that’s really the main difference.
It's not that simple. Yes, from the point of view of the emulated system, it does not matter if the emulation is software or "hardware" (i.e. an FPGA), as it will always observe correct relative timings.
But if you want actually correct timings in the real world, i.e. to wall clock, a modern software environment will make it harder for you in practice. If you don't have an OS with any real-time capabilities, that's your first problem: You have no (good) guarantee when and for how long your threads are scheduled, how long allocation and system calls will take and block you, and generally whether you can reliably meet any of your deadlines.
On Linux with VICE, I would not be shocked at all if I occasionally observed VICE stuttering for a millisecond.
With baremetal (or an OS with sufficient real-time capabilities), you can make your deadlines meet with some care. You will still have some (possibly negligible) amount of jitter: Superscalar CPUs and caches are just some of the culprits.
Does the jitter, or even the lack of deadline guarantees on plain Linux with VICE, matter in practice? Maybe not. With a fast enough machine you might not notice at all. Is it easier, and to some extent more efficient, to just sidestep those issue with an FPGA implementation that is guaranteed accurate to wall clock (not just emulated clock)? Probably. Comes at the cost of having FPGAs, though. On the other hand, a real NTSC/PAL output is going to be pretty real indeed!
As said, not that simple. How hardcore you are on your wall clock accuracy requirements probably depends on how much of a "preservationist" you are.
It sounds like you've rephrased and elaborated exactly what I just said, but the way you've phrased it makes it sound like you're disagreeing with me. So I'm unsure what, exactly, you disagree with.
The statement is about relative timings, to be clear, and you agreed with that.
I'm not trying to be clever here to win an argument, I really just think that good relative timing is implied by "accuracy", and good wall-clock timing is not--that's "performance". It makes sense to me that these terms are separate, so I can say something like "I have a cycle-accurate emulator that runs at 25x realtime".
For stuff like game systems, you generally don't need a ton of wall-clock accuracy anyway. You're going to be plugged into some kind of LCD panel, and you just need to make sure that it gets fed with the correct data every 16 ms or whatever the correct update rate is. The fact that your input controller isn't getting probed at the exact right time relative to the screen update is kind of a non-issue.
Yeah, we agree on relative timings, and I guess I'm okay with using "accuracy" without qualification for that, i.e. what the machine observes. It wasn't clear to me that "timing" meant cycle-accuracy, so I guess we do agree after all.
As for how much wall-clock accuracy you need... Eh, as said, it depends on how much of a preservationist you are. If you plan to actually generate an NTSC or PAL signal on a low level (including actually performing the quadrature amplitude modulation), it can well become relevant, and phase noise affects color.
Otherwise maybe not, though again I'm not surprised if some standard Linux on some RPi actually shows visible glitches from time to time. Irrelevant for most users, but then again most users may also just want to play the game on a rudimentary emulator, or even a more modern version of the game. This is all either for fun or for preservation, after all.
If you do need (video signal) or want (anal retentiveness) high wall-clock accuracy, an FPGA then also has the advantage that whatever ARM core or whatever you have next to it can implement UI and control in whatever is most convenient, on any non-RT run of the mill OS, without any risk to negatively affect the rock-solid, cycle-locked emulation in the FPGA. On an overall weaker overall SoC at lower frequency, even.
It should be easier to do in software. What's hard is, modelling the hardware accurately, getting the timing correct, AND getting everything performant enough to run at the original hardware speeds. It takes a beefy system to accurately emulate even SNES hardware at full speed. An FPGA can be programmed with accurate hardware models and run them all in parallel at the same speeds the original hardware ran at (up to a limit, I believe today it's somewhere in the low hundreds of MHz for a CPU). This allows for a closer approximation of the original hardware running at usable speeds.
It used to take a beefy system to emulate the SNES at full speed. Emulator performance has improved, CPU performance has improved, and nowadays, an outdated and low-spec x86 laptop will run BSNES.
You will have problems running BSNES on a Raspberry Pi, though, although I've heard the RPi 4 can do it.
Moreover, it can actually be at least "more straightforward" to reach accurate wall clock timings with an FPGA, than by trying to meet deadlines in a common OS environment, as the FPGA is "just" loaded with a bitstream that will it do more or less exactly what the original chip did and nothing else, spoken strictly in the digital domain.
I'd also like to think that it's more efficient, since at least in theory it could be (cutting down on all the extremely superfluous software overhead for the task), but sadly I don't actually know how common FPGAs really perform in that specific case against reasonably efficient modern CPUs.
Maybe holding some real hardware gives much joy? I'm thinking about maybe emulating it using a Pi and buy some peripherals such as external floppy. Not sure if it's doable though.
The real real hardware - sure, but emulated on a FPGA… not so much. But that’s just me.
Emulation in software (and the virtual space in general), on the other hand, is close to perfect these days. In fact, material things get boring pretty fast (and tend to end up in the attic) whereas virtual reality (like games) remain a source of perpetual joy.
After some thoughts I believe I agree with you on both points.
A replicate but with new board and new chips for buyers to solder their own hardware would be really interesting and educational.
On the other side, I already have some retro hardware collecting dust so tonight I'm going to get one out to play CD music I just bought. Only vintage laptops have CD players installed.
FPGA is a simulation, not an emulation. Emulation does everything serially while simulation does everything in parallel, just like the real hardware.
Also, software emulation on a non-real-time OS such as Windows, macOS or Linux can result in lag when the OS is busy with other things. You never get that on FPGA simulation.
It’s all emulation—either in hardware or software, in parallel or in series.
I used to work on simulation software professionally. The idea that simulation is parallel while emulation is serial is completely foreign to me, and I suspect foreign to others as well.
I have worked on simulators for most of my life and the GPs definition is not true.
There's no formal distinction between the two, but conventionally emulation is more faithful whereas simulation is more high-level. Still, the two are used fairly interchangeably.
To me the distinction seems obvious: simulation reproduces the external behaviour of a system i.e from observers pov; emulation reproduces the internal behaviour. Typically the external behaviour emerges from this as a matter of course, but in many cases such a “bottom up” approach isn’t possible or even necessary.
It is foreign to me, for sure. I have been experimenting with FPGA-based retro systems for years (started with a MIST.) I still consider them "emulators."
I work in silicon development, and we call software models "simulation" and FPGA models "emulation."
Both terms are a little arbitrary, but logic on an FPGA is not a simulation, for most definitions of "simulation." Perhaps more accurate than either term is "implementation," since it is an honest-to-God implementation in a digital circuit of the logic.
Think of it this way: software tells a computer what to do, gateware tells an FPGA what to be.
