For anyone else wondering about the name: it's actually "MiSTer", from "MiST on Terasic [FPGA board]", with "MiST" being a previous "aMIga/ST" FPGA reimplementation effort.
There's one thing you don't get, which I see many people find they miss: savestates. It's technically possible and I know a few cores try to support them, but it's just a million times easier (and more reliable) if you do everything in software anyway.
Hardware emulation has a pretty small niche between software emulation and real hardware. If you care about accuracy at all costs, real hardware is usually still available and not too expensive, and if you care about convenience, software emulation is better.
> real hardware is usually still available and not too expensive
I all depends. There's a "retro" bubble currently and people ask silly money for the original hardware. Then capacitors burst, original hardware needs maintenance, and is not something everybody can do.
The MISTer provides an experience that gets very close to the original hardware, without all those nuances.
Oh they ASK silly money sure, but do they get it? I only keep track of the Commodore part of the retro world, and from what I've seen, most machines are still cheaper than they were at launch, not only in inflation adjusted terms but in absolute terms too. Even machines which are bought for restoration and resold (with fresh capacitors and QoL modifications like modernized video output) are very reasonably priced. I think the underlying reason for those low prices is that software emulation really is the better option for most people.
I’m unsure what you mean about hardware emulation not being reliable.
Save states is a good point. SNES for example does not have them. Adding that stuff as an after thought is extremely tricky. Most newer cores are creating with save states in mind for two reasons. Makes debugging much easier as you can share states with testers on top of the QOL you get with that feature for end users. PSX for example has really good save state support with rotating save states.
Hardware emulation is of course reliable, it is hardware save states which might not be. And yeah, if you design for them for the start they probably work better. Possibly "newer" architectures like PSX are also cleaner about where they keep state?
I personally have found it more enjoyable to play a lot of games without savestates.
Playing earthbound a few years ago I was constantly savescumming. My recently replay on mister without savetsates was way more enjoyable because the stakes were higher.
Wouldn’t want to play a Mario World rom hack without them though
OSSC is reasonably inexpensive, and with the exception of the NES and N64 nearly all retro consoles output RGB without modification (but may require the appropriate cable).
There are better scalers and mods for possibly cleaner audio and video for nearly all consoles, but with few exceptions an OSSC or RetroTink will get you 99% of the way there. The last 1% is chasing audiophile levels of quality improvement for audiophile levels of money, imho.
RetroRGB and My Life in Gaming are fantastic resources for nearly all retro gamers of any budget. You don’t have to spend a lot to get old hardware looking really great and low latency on modern displays.
I was lucky enough to get in on this when the boards were ~$130. It’s one of my favorite pieces of tech. It “just works” and the UI is very good. Updating is super easy and it even goes and grabs the MAME Roms for you. CPS2 games feel much different than my MAME box running Arch. I can 100% pick up the controller and I’m a few seconds know which one I’m playing. The video processing presets have some that make the games look amazing. Psx I mainly play rpgs so latency isn’t a huge deal there.
If anyone has any specific questions let me know. I think they are twice the price now but even at that I would probably rebuy. I use it probably 8-10 hours a week so worth a good investment.
FPGAs are fun, for sure, but I still have never felt the flair of “authenticity” from the use of FPGA as opposed to software emulation on a microcontroller or the PC. In fact, software emulation is so much more practical, and you can simulate pretty much any aspect of it that you wish, not just the CPU and some peripherals. A modern flight simulator is another example of using software to bring the user’s experience close to what it would be in reality (especially with the VR gear).
Often times it's not flair but latency! I have yet to find a handheld that plays my GBA titles with the same feel as my actual SP, save my Analogue Pocket which has an FPGA.
Um, I don’t understand how you might feel software emulation has more “flair of authenticity” than a MISTer rig. FPGAs don’t emulate hardware, they are hardware. They are almost exactly like the original.
They're hardware, but not the same set of logic as the original systems. They still rely on reverse engineering efforts that occur when developing software-based emulators. They produce the end results that were measured from the original system, but not the exact behavior. As a result, they're not naturally more exact than a software emulator.
Where the FPGA comes in handy is in concurrent logic and a fixed clock. This makes synchronization easy, and that is what makes software emulators much more demanding.
Some chips are well documented and some actually get decapped. There are cases where retro console cores really can be the same logic as the original. It's a lofty goal and we're certainly not there currently. Often software emulation is content to mimic the inputs and outputs and complete the task as observed. There can (and often are) strange corner cases or subtleties that are difficult to catch. Is it a big deal? Not usually, but it's an interesting challenge to pursue a perfect logical re-implementation that can survive longer than we will.
The most important thing is that many emulators are not modeled in such a way as to offer cycle-accurate results, whereas this is easier to achieve with FPGA implementations of devices. You can see evidence of syncing issues from emulators just from reading things like the Dolphin emulator's update blog and how many times they're dealing with them [1]. This is a double-edged sword of course, as a cycle-accurate reproduction of the original hardware doesn't give the same opportunities to offer modern improvements like arbitrary scaling, updating textures, and makes state saving more of a challenge.
(the linked example also highlights how variations in hardware memory architecture present real hard challenges for software emulation, which would be simple to overcome in an FPGA)
In many cases they are the same set of logic as the original systems. That’s the point. Some are reverse-engineered guesses but the vast majority are tick for tick identical. How could a software emulation be more authentic?
They can both be equally authentic, there's nothing preventing either from doing the exact same thing as the other. But the software based one will have a lot more overhead keeping track of cycles and making sure things interact at the right time.
As willis936 points out, decapping can let us see the exact logic a chip uses, but only a minority of chips are decapped. It's extremely expensive and analysis is time-consuming. Most stuff is reverse-engineered. That doesn't mean it's all HLE, we can infer a lot of behavior, and the composite timing is known, so it's close enough to use, but not to archive the design for future generations.
I wonder how much the misapprehension that FPGAs somehow emulate is due to the fact that the way we configure them looks so much like code. VHDL is ghastly, but I prefer it over verilog bc verilog seems to actually try to look like C. I think especially for beginners it's too easy to lose sight of the fact that while you may "read through" your VHDL/verilog, that when it hits the FPGA fabric it's all going to happen in parallel. Maybe if the source matter were made to resemble data more than code, we could simultaneously ditch the verbosity of VHDL and the imperative algorithm appearances of verilog. I'm thinking maybe JSON at the moment. =P
The main disadvantage of software emulation is that really making the timing consistent with the original hardware is computationally expensive because it needs to account for things like bus arbitration and DMA interactions between the CPU and graphics hardware. This means that you can't get away with JIT translation, or even having your CPU emulation iterate over a bunch of instructions at once. For most games this doesn't make a big difference, but it matters in some edge cases, and also for accurate slowdown behavior (most old-school game engines let physics slow down when the CPU falls behind), which is important for speedruns and other high-level play on some games.
While it's not intrinsic to software emulation, modern PC and mobile operating systems tend to be somewhat bad about input lag by default. This can be overcome, but it's work, and vendors seem to invent an exciting new way to fuck it up every few years.
Similarly, a lot of old-school hardware ran at oddball frame rates that modern systems won't do without a bit of coercion (e.g. NTSC SNES runs at around 60.09 Hz in most modes), so you're usually forced to choose between running the system at a slightly inaccurate speed or allowing periodic stuttering. That being said, modern displays don't necessarily support the original refresh rates either, so FPGA-based systems have needed to make the same compromises, just less often than software emulators.
Interestingly, most 60hz monitors I've tested can tolerate the SNES/NES weird refresh rate without problems. In Windows you can create such a video mode with ToastyX's CRU, and with custom modelines on Linux. All you have to do is take your monitor's native modeline and multiply the pixel clock value by the ratio of 60.0988/your_normal_refresh rate. Within a thousandth of a frame or so is usually close enough, but if you mess with the blanking intervals a bit you can get exactly the same rate.
Monitors generally don't hit 60Hz exactly anyway. A lot of cheap monitors have really inaccurate default refresh rates, like 59.93Hz instead of 60. Some may use 59.94Hz to match NTSC's rate.
It doesn't matter how fast your emulator is, throughput-wise. Your operating system (and other stuff) sits between it and output and input devices. And usually adds multiple frames worth of latency. There's ways to improve this, certainly, but you won't get that experience "out of the box."
Now, it's also possible to accomplish this by running emulators "bare metal" or "close to the metal" like my friend Randy did with his BMC64 project: https://github.com/randyrossi/bmc64
As long as the correct output signals are generated before the clock edge, there is little meaningful difference between software or hardware implementations.
A cycle-accurate software emulator can actually replace a hardware CPU. Consider this example of a cycle-accurate software emulator running on a 600 MHz Teensy/ARM microcontroller board plugged into the CPU socket of an Apple II:
The 8088 version (an impressive achievement, though he had to overclock the microcontroller to 800MHz) apparently also worked as a drop-in replacement for MiSTer's FPGA implementation - he suggests that graphical bugs in the area 5150 demo were not due to the CPU but due to timing issues with MiSTer's PC XT peripheral implementations.
No, that's not at all the case for what the poster I was replying is referring to. I think you misread them/me. They seemed to be talking about software emulation on commodity PCs.
Total time, from input to physical display on the screen is not under the user space programmer's control if you're running an emulator on a Linux or Mac or Windows system.
You can be cycle accurate all you want. That doesn't get you past the windowing system, GPU, display controller, HDMI interface, etc. any faster. All of that sits between you and pixels.
It is possible, on an FPGA (or under any hardware you control directly, really) to go straight from framebuffer to HDMI (or etc) signals without pauses inbetween. In some ways it's easiest on FPGA.
Your example is running on custom hardware. That is entirely feasible, yes. But isn't what was being asked about. That's similar to the BMC64 example I gave.
I think we're making compatible points. You noted that you can bypass the OS by running on bare metal. (True! You can also use real-time OS features, devote one or more cores entirely to running the emulator flat out, write directly to a frame buffer - or maybe even generate the actual video signal[1], etc..) Another nice thing about a microcontroller board like a Pi or Teensy is that you can easily get signals in (e.g. controllers, keyboards) and out (e.g. sound, video) of it.
Note that Linux (which I'm familiar with) makes it fairly easy to bypass much of the OS for real-time applications, but you can get most of the benefit by simply running a single process (i.e. just run the kernel and a single emulator process.)
My point is similar to yours actually: that as long as you calculate the output signals on time (e.g. before the clock edge) there is not a meaningful difference between hardware and software implementations.
You can get the precise scanout positions easily. For direct scanout: Windows has fullscreen exclusive mode, X11 has unredirecting, and Wayland recently added direct scanout surfaces. There's major API extensions to query the vblank times, so you can set up the next frame to start scanout precisely when a console would. Now, you won't be able to modify the image when it's displaying--no racing the beam tricks, but consoles usually locked the vram outside vblank anyway.
This is interesting - are you saying it's possible with appropriate synchronization to race the scanout on a modern GPU/display to get true line-by-line display for an emulator and avoid the buffering delay (e.g. 1/4 frame at 120 Hz)?
Presumably native graphics and games already need to sync with fixed rate displays to avoid tearing (or buffer and pay a latency price.) The fact that tearing exists would seem to indicate that you can update a frame while it is being scanned out.
I imagine that racing the beam (or video signal scanout in the case of non-CRTs) might actually work, especially with VGA where you could set to an appropriate resolution.
A Raspberry Pi is a popular emulation platform. There's essentially zero latency to read a GPIO pin. Even on macOS or Windows 10 platforms, one way serial-to-USB latency seems to be less than a millisecond.
It's a good way to learn about FPGA's. Other thna that, the FAQ has a good example about where the Amiga software emulation falls short:
> Let's take a well-known emulator, UAE, emulating an Amiga. On a Raspberry Pi 3, you can run some Amiga CPU benchmarks and get crazy numbers like 100 times the original 68000 processor. So you may assume you have an emulated Amiga that is 100 times faster than real one. No, you don't. If you run different kinds of demos or games, you will see the video stutters sometimes. For example, if you play the well-known "State of The Art" demo by Spaceballs, you will notice video stuttering at some points, while a real Amiga 600 with 1x CPU speed plays the whole demo very smoothly.
If you want to eg add original ports and hardware interfaces that tends to be easier with an fpga: cartridges, midi etc. Of course you can do that in software/ bit bang. Though it’s complicated by emulator timing, they tend to run frame by frame and sync at the end of a frame.
I've wanted to give Mister FPGA a go for the longest time, but the boards are never in stock any time I look. How are people getting their hands on them?
Apparently if you buy direct from Terasic you can get hold of them. The downside is a large shipping cost and import duties/taxes on top. I have heard of people successfully getting them shipped from Terasic offices within the same country as them to avoid the import duties issue.
The Terasic boards are essentially an evaluation board and despite the recent price increases, still give you a lot of hardware for the money. Other boards that come close in capability and have what you'd want for something like an emulator platform (like HDMI out) are a lot more expensive. Pretty sure Sorgelig (project lead) has said he has no interest in ever porting it to a new platform. Doesn't mean someone else couldn't, but it would be a major effort to do so and keep up.
There’s a required RAM module for most cores that slides into the de10 nano. The software and the Linux kernel are also tightly coupled. Individual cores can be ported to different FPGAs though. The SNES one for example was recently ported to the analogue pocket.
Tough, given the difficulties the last few years I guess.
But Terasic have the FPGA board listed for pre-order with estimated shipping at the end of this month.
I haven't had opportunity to get one before either, so I'm not sure how the availability for expansion cards has been.
For those more generally interested in learning FPGAs and computer architecture, MiSTer is a nice platform to explore. I recently found a good series of videos looking at it from this perspective [1].
I applaud the MiSTer Project for their brilliant work. I'd even be interested in buying something like it. But the most complex console it can emulate is a ps1 and that can be emulated perfectly fine in software. I wish most 5th gen/6th gen consoles were in reach to emulated with it. But alas that's out of the question and even software emulation is still far from great for most of these consoles and require beefy hardware...
