Production for the Nintendo Classic Mini: NES continues, and NOE [Nintendo of Europe] will continue to ship units to retail on a regular basis.

The way that CPU's in classic 80's arcade games work is that they all require a clock which alternates between a high and low state at a frequency usually in the low megahertz range (ie 1 MHz). They also usually have at least 16 address lines and at least 8 data lines.

The CPU's 16 address lines are always outputs, meaning that the CPU is the only device in the computer that is allowed to change its address. The CPU's 8 data lines can be either inputs or outputs. The CPU has other lines on it which indicate whether it is trying to read from its data lines or write to its data lines.

Each CPU instruction takes a specific number of clock cycles to complete.

If I were trying to implement a CPU inside of an FPGA, I could (if I do it correctly) have the FPGA's input/output lines behave exactly like the original CPU. And if the FPGA's I/O behaves exactly like the original CPU's I/O, then the FPGA could be considered to be 100% compatible with the original CPU and one could use it as a drop-in replacement for the CPU without sacrificing any sort of accuracy. This is what people mean by "one to one." I should note that from what I have seen of efforts to implements CPU's inside of FPGA's, I am not convinced that the people who put forth the effort were terribly concerned about accuracy, and may have been more concerned about making the FPGA version CPU perform faster than the original. So just because an FPGA could in theory be a 100% accurate replacement for the CPU does not mean that this is what is happening.

Now, what might people mean when they say "not emulation" ?

CPU emulators [ ... ] do not emulate the clock of the CPU, but instead are designed to execute a variable number of cycles in one shot as quickly as the host machine (ie a modern x64 computer) can execute. The code that is driving this execution is then responsible to regulate the overall speed of the system so that it does not run too quickly.

This creates an unauthentic experience because it means that instead of instructions being executed at a steady slower cadence, they are executed in quick bursts with delays in between. This is usually not noticeable by a human playing the emulated game because it's just 1 ms, but several problems can arise depending on the other architecture of the original hardware.

On a game like Dragon's Lair where there is just one CPU and a steady clock that never varies, the above method of emulation is "good enough." A human is not really going to notice any meaningful difference in accuracy.

But what of the game has multiple CPUs such as a dedicated sound CPU? Now the emulator has to execute a smaller slice of cycles on the first CPU, then switch to the second CPU and execute another smaller slice of cycles. If there are interactions between these two CPUs (and there usually will be), the slice of cycles that gets executed needs to be small enough so that there is no unnatural lag in the interactions which hurts performance of the overall system. And even if each CPU takes turns executing just 1 cycle, the potential for an inaccurate interaction between the two emulated CPUs still exists since the emulator does not take into account the clock.

On a lot of the Williams games, like Joust, their custom DMA chip will actually halt the CPU while the DMA operation is running. On Star Rider, the CPU's clock gets halted every field for unknown reasons (that's on my TODO list to figure out why). Last time I checked, this behavior was not emulated very well in MAME (it may have improved since I last checked) and certainly Daphne is not equipped to handle this type of scenario. However, an FPGA would be able to handle it just fine.

As modern computers get faster, it will become more feasible for emulators to become more accurate without hurting performance. I believe that aside from the problems associated with running on a modern operating system (with many processes and threads all competing for the CPU's time), there is no reason why software-based emulators cannot achieve 100% accuracy as their architectures are improved. However, I do not believe that that day is here... yet.

my NES core has a "real NES" video output mode where it recreates the exact same voltages and transitions using a DAC to recreate the video signal. There's no lag involved- it is generated in the same way a real system generates its video signal, complete with the same steps and transitions. I guess the lag, if you can call it that, will be a few nanoseconds for the data to propagate through the DAC and be presented on the output pin. My "real NES" video is an exact reproduction (well it looks like that on a scope and on a monitor using direct A/B testing) of what a real system outputs. You'll have trouble making a software emulator do this.

Nintendo will discontinue the Nintendo Entertainment System: NES Classic Edition and the last shipments will go out to retailers throughout this month.

A Nintendo representative provided the following statement to IGN:

“Throughout April, NOA territories will receive the last shipments of Nintendo Entertainment System: NES Classic Edition systems for this year. We encourage anyone interested in obtaining this system to check with retail outlets regarding availability. We understand that it has been difficult for many consumers to find a system, and for that we apologize. We have paid close attention to consumer feedback, and we greatly appreciate the incredible level of consumer interest and support for this product.”

Given the widespread excitement, interest, and sales of the NES Classic, it only makes sense for Nintendo to stop selling it.