Absolutely 0 mentions of the word "MiSTer" negatively impacts this "open" project.

Their self-appraising pitch applies more to the MiSTeX project than themselves.

[https://github.com/MiSTeX-devel]

Yeah but they seem to be suggesting no one has done fpga emulation before.

(I'm biased, I love my mister!)

After DE-10 Nanos what up in price (likely due to MiSTer), there was rumblings that it was too tied to the hardware to be portable.

I missed out when things were cheap and always assumed buying a board at the higher prices would be the trigger which caused the project to move to the next generation of hardware.

Yeah I paid the higher price unfortunately. The best thing about it is I don't spend all my time fiddling with settings like I do with software emulators.

Which is just rich, as Analogue takes advantage of preorders to limit hardware on a per-order basis, meaning they are always out of stock. Don't have this issue with the MiSTer.

Five years ago the Mister people were similarly unable to STFU about raspberry pi’s. Mister is still emulation, it still has tons of issues, and it’s still $700 invested before you’re actually playing games. Meanwhile we’re in a golden age of RGB mods, flash carts, and optical drive emulators for original hardware.

While I'm a strong supporter of your position that the MiSTer (and any FPGA console implementation) is still emulation, it's worthwhile to keep in mind that this will indeed be _a_ future for preservation (unsure about it being the only, and warmer to, but not sold on it being the best way).

Original hardware is great, but it's getting older, and failing. The Super Nintendo / Super Famicom, for instance, uses a ceramic oscillator as a clock source for its sound processing unit, and as the console is designed, the sound clock is essential for keeping the entire system in sync. Members of the Tool Assisted Speedrunning community have been experimenting with parts replacements to resuscitate this clock source with only mixed successes. This is one of many pieces of silicon on these old platforms that will continue to fail as time goes on.

We can't make brand new classic consoles because the parts are just unavailable, and the industry has a well trodden path of reimplementing discrete electronics in FPGA for decades now with great success. If your goal is to keep playing games for a while longer on your OG console, then heck yeah, go for it. It does indeed do the thing. But if we want to be able to preserve this history in as close to the original form factor and play environment as possible, then we have to explore other options, and FPGA system cloning is a grand way to do this.

I think the most worrying thing about emulating old consoles by reverse-engineering them is that you're running out of time to test it. Say for example that the original Luigi looks blue in the hardware it was made for, but in an emulator he looks green. If there are no original NES left, you will never be able to know the emulator's code doesn't match how the NES actually worked. From that point on, the emulator experience is as canonical as it gets.

Different NES revisions actually output different colors. Plus, originally it's an RF signal, then composite. It was displayed on some CRT. It's possible to RGB mod an NES, but is that authentic? No.

The one true color of Luigi is the one that you saw as a child on a sunday afternoon in the eighties. Lost in time, like tears in rain.

My MiSTer FPGA was about $200 before I was playing games. $700 is either hyperbole or have DE10 Nano board prices really gone up THAT much?

After DE10 Nano, you need just a RAM module and a I/O board and you're ready to go.

The MSRP of the de10 nano is $225, but they are commonly out of stock still. The going price for a scalped de10 nano is over $300, so all is you are likely looking at $400 to $500. I kick myself often for not getting multiple de10 nanos earlier (there are more projects that used them than just mister).

Just tried from Terasic website. Tried to order two for $225 each, they seemed to be available.

That said, the price has almost doubled in a few years...

"FPGA is emulation"

You can have any number of issues with Mister, but this is just flat out incorrect if you know the definition of either of those words.

They may have read this article written by Near arguing that FPGA-based products are still (hardware-based) emulation: https://archive.is/fWosI

It's a well-written article, and presents a balanced view. Its stance is against the idea that FPGA-based emulation is always better than CPU-based emulation.

There's no circuit-level reproduction happening anywhere yet, it's basically emulation with a hardware clock. Analogue and kevtris know that FPGA isn't magic. Rather than contribute to the knowledge pool, like the MiSTer project, they're being bad actors and trying to muddle the situation to make money off of it. Near was trying to clarify the situation, but now we see where good intentions gets you.

That is a fantastic read. Thanks.

Of course Mister uses emulation - there are only few chips in older arcade boards that truly can be simulated in FPGA with circuit-accuracy.

The Mister SNES core has less accuracy like the software emulator bsnes, not all game work or there a bugs - they still "emulate" the hardware how they interpret it.

FPGA is just a different way of "hardware emulation" instead of traditional "software emulators".

The only real advantage of FPGA compared to software is the improved latency.

An FPGA can be 100% hardware perfect with practically no extra processing cost. The potential is there, even if it's not initially exploited.

CPU based emulation will require a fairly powerful CPU just to emulate SNES. It's pretty expensive to emulate hardware in 180-190 ns increments.

This isn't quite true - you lose some of the weird analog stuff that may have happened. On a well-designed board, though, you can get essentially perfect cycle-accurate reproduction.

Not only, the ability to replicate hardware allow to render some effects that can’t be render with software emulation. I’ll try to find the video I saw on YT explaining that point.

Perhaps you are referring to this video [0] by What's Ken Making which goes into detail about the advantages/disadvantages of both software and hardware emulation?

At 13:43, he demonstrates a couple of snes games with effects that don't work well in software emulation (along with what the effects / game mechanics should be on original hardware). At 22:25 he shows these same games running on FPGAs (analogue pocket, mister) and behaving correctly, just like on original hardware.

As an aside, if this isn't the one you were referring to, it's still an awesome video by an amazing creator; I'm a big fan of this stuff after discovering it on accident. He gives a nice introduction to FPGAs in this same video.

[0] https://youtu.be/sMMiBEhnizE?si=E08sfoc--NlgiqGu&t=824

The argument being made is that the distinction between an FPGA and CPU is irrelevant to determine whether something is emulation.

An emulator accelerated by an FPGA is still an emulator and a CPU simulating a console at the circuit level is no different in accuracy than an FPGA doing the same thing.

The main difference is the experience, where the FPGA can offer an experience closer to the original than a CPU running an operating system can, especially for older consoles. Not because of a difference in emulation accuracy, but because the user experience is different.

That’s just building a unit to spec using an fpga instead of a chip fab. If it’s a 1-1 copy, emulation would not appear to be the correct term.

If I have a black box chip that takes in 3 bits and spits out 3 based on the input. If I make a bit perfect implement of it, but my chip has additional outputs that correspond to unused input, hence never used. Is it still considered emulation? It differs minimally in a negligible manner.

> if you know the definition of either of those words

Let's put that to the test, ok

https://www.merriam-webster.com/dictionary/emulate

1a: "to imitate by means of an emulator"

https://www.merriam-webster.com/dictionary/emulator

2: "hardware or software that permits programs written for one computer to be run on another computer"

Yup, FPGA recreating other hardware definitely fits the bill of emulation. Granted, Analogue has played up a marketing spin that boxes in "emulation" to mean "software running on some generic CPU" in order to claim "no emulation", but it's just marketing doing the work of marketing.

WINE fits that definition but is generally considered to be Not Emulation in a technical (if not colloquial) sense.

It depends on your interpretation of the definition. If the two "computers" that the webster definition is referring to have a different architecture, then Wine does not fit that definition, because Wine relies on the fact that it's the same computer architecture, namely an x86 PC.

If you combine Wine with Rosetta to run Windows programs on an M1 Mac, then it is definitely emulation by any definition. But then it's not Wine that's doing the emulation, it's Rosetta.

It doesn't implement the original hardware. It's not copy of the original chip. Reverse engineering is used to get the behavior of the hardware. They reproduce the inputs and outputs with Verilog and write it to an FPGA.

If it weren't emulation, they would decap the original chip and directly copy the chip, gate-by-gate. It could be done, but it hasn't been done that way anywhere to date.

At the end of the day both FPGAs and software emulators are Turing machines that produce a set of outputs given a set of inputs : any logic an FPGA can implement can also be implemented in software, it's computer science 101

FPGAs aren't magically more accurate. That is only up to the programmer and what effort they put in.

The main difference is efficiency and parallelism : it's much easier to reliably produce cycle-accurate parallel outputs in real time with an FPGA, compared to software running on a multi-tasking OS with many layers of abstraction and no deterministic real-time guarantees.

But, as a single-core processor can fake multitasking, by slicing time between processes (preemptive multitasking), software emulation can mimic parallelism if the host is beefy enough compared to the old school system it's emulating. The larger the performance / clock speed gap between the host and target, the more indistinguishable from a truly parallel FPGA an emulator can be.

Software emulation also has practical advantages for developers : while FPGAs force you to painstakingly implement every bit of functionality at the logic gate level, with software you can start off with a much higher level model of the target system that's much easier to implement, and mix & match that with more precise low level simulation where it matters. The time this frees up (+ the availability of various libraries) allows the developer to spend more time researching the original system and adding modern quality of life features that just wouldn't be possible otherwise.

Great article on the topic : https://archive.is/fWosI

Nobody has put these chips under a scanning electron microscope, catalogued each gate, and then recreated those in extremely verbose Verilog.

That's what "implementing the target hardware" in an FPGA would consist of.

Even if this extremely-arduous process were to take place, you would likely still be unable to reproduce the analog chips used for audio and video in most FPGAs - certainly not the cheap FPGAs MISTer and friends use.

> Nobody has put these chips under a scanning electron microscope, catalogued each gate, and then recreated those in extremely verbose Verilog.

I don't think anyone was doing that when iterating on the hardware back in the day, either. Dollars to donuts, the 65C02 was not based on a deep empirical analysis of the behavior of as-implemented 6502s, but was rather produced from modifications to the design spec that the original 6502 was itself implemented from, with the intent of maintaining compatibility with the original design.

Same thing here. An FPGA implementation of the original schematics of the hardware can be viewed as another instance of variant hardware built against the original design, whereas software emulation is simulating the outward behavior of the original hardware without any ability to be implemented directly from the original design at all.

> Even if this extremely-arduous process were to take place, you would likely still be unable to reproduce the analog chips used for audio and video in most FPGAs

Which returns us to the original description of these solutions being mostly hardware implementation via FPGA, but not entirely, as some emulation is still needed.

FPGAs are reimplementations, to me, not emulation. But I don’t begrudge anyone who wants to be a stickler on the definition of “emulation”.

Even the original hardware “emulates” a game if you want to get down to it.

That’s how I see it too. The FPGA version are knock offs, like would have been done back in the day but with fancy future hardware. A gate level reproduction would be kinda strange aside from pure desire for preservation. (Which is still a decent goal, just not of these projects)

So your argument is that its closer to virtualization, than to emulation?

Not really. And I'm not sure the concept of virtualization makes sense when applied to hardware in the first place.

The FPGA is actually implementing the hardware. It's like using a newly manufactured edition of the original.

The FPGA is used to implement an approximation of the original hardware’s functionality - not a perfect clone of the original hardware itself, which means they have their own unique bugs and inaccuracies compared to the original designs.

I think “emulation” fits as a reasonable description of this, personally - at least as something an average person will understand.