Jump to content
Due to a large amount of spamers, accounts will now have to be approved by the Admins so please be patient. ×
IGNORED

DE-10 Nano Mister FPGA emulation


Recommended Posts

I have only just heard about this new device, and it looks really, really cool. It's still a bit fiddly and difficult, but I imagine when the project has been running for a bit longer, it could be quite impressive.

 

 

A guy here has it running in an arcade cab, so the first steps for arcade emulation are already happening.

 

 

While it's still pretty limited, this could scratch the itch of people who want arcade perfect emulation in a small form factor for classic 80s games. It's the first I am learning about FPGA emulation, and it seems promising.

Link to comment
Share on other sites

Promising yes, but it's got a long way to go.

 

I'll throw this out there now - FPGA does not automatically mean a 1:1 hardware experience.

 

Sure, I get that it's got a long way to go, but it does seem really cool at this earlyish stage. It will be an interesting project to keep an eye on.

Link to comment
Share on other sites

Definitely, I completely agree.

 

It has promise and once the cores are refined it will be a great emulation solution, surpassing the Pi in every way.

 

I'm very ignorant to FPGA but I was under the impression that if done right it beats all emulation? I've seen Bob on RetroRGB mention the Mister a few times but have been waiting until it reaches a more user friendly stage. Right now no emulation solution I've tried has even come close to groovymame in performance. How do you think the Mister would compare to a groovymame setup on a beefy PC?

Link to comment
Share on other sites

FPGA is still emulation and still only as good as the programming behind it. A well done software implementation can be just as good, if not better, than hardware based FPGA solutions.

 

FPGA has the inherent advantage of being hardware based and therefore free from any software overhead. That said, once again, it all comes down to the quality and accuracy of the programming behind it.

 

There seems to be a misconception that FPGA is identical to real hardware, it is not. Some prefer not to tie the term emulation and FPGA together, but it is indeed an emulation of ICs. Call it a simulation or approximation if you prefer.

 

Companies like analogue are spinning marketing hype with claims of their FPGA consoles being 'no emulation, no lag' etc. Deceitful marketing ploys to sell a product at an inflated price.

Link to comment
Share on other sites

  • 1 month later...
I'm very ignorant to FPGA but I was under the impression that if done right it beats all emulation?

As others have said, it always boils down to the code quality.

 

Where FPGA shines is latency. If folks are contributing cycle-accurate cores, then often the latency is reduced right down to match real hardware 1:1.

 

However documentation is key, and there's a lot of weird proprietary stuff on old computers and consoles where people have to investigate things "black box" style (typically with a logic probe and slow, painful troubleshooting and testing), which means there's no way to guarantee "cycle accurate" behaviour for everything.

 

For common stuff - Z80s, M68Ks and other chips that appeared in a lot of old systems - yes, both accuracy and latency is great, even in a project as young as this.

 

 

I'm very ignorant to FPGA but I was under the impression that if done right it beats all emulation? How do you think the Mister would compare to a groovymame setup on a beefy PC?

MAME is a 22 year old project, and has had a hell of a lot of very clever people writing drivers for it for a long time. You've literally got some of the world's best commercial emulation and low-level assembly, encryption and CPU architecture minds donating time to the MAME project for a long time now.

 

With that said, MiSTer and MAME are complimentary, and a hell of a lot of the effort that has gone in to MAME serves as excellent documentation for a multitude of projects (even real hardware repair can use MAME as documentation sometimes). That doesn't mean that it's "easy" to write MiSTer cores in HDL from MAME's C/C++ code. But it does mean that clever people who are good at this stuff have more documentation today than they might have 20 years ago to verify or compare their findings (remembering that MAME isn't perfect either, and constantly re-verifying things is proper scientific process).

 

However answering your question directly - right now MiSTer (especially over non-scaled analogue output) offers objectively lower latencies than any MAME setup. Whether you notice it or not is subjective person to person, but the results are measurable. With that said, RetroArch now offers "run ahead" emulation, which is a bit tricky to explain, but the end result is lower latency than most other emulators (and sometimes even real hardware, which is pretty astounding to think about). But RetroArch's choice of emulators frequently choose speed over accuracy, which might affect your opinions on it depending on how much of a purist/pedant you are.

 

There's no clear "best" solution. Software emulation is far easier to set up, but sacrifices latency and often accuracy. MiSTer FPGA is offering quite a few cycle-accurate cores, but not everything is 100%, and it is a bit fiddly for non-technical users (especially if you're not familiar with Linux - although I've been telling folks to use Linux for 20 years, so that's an "I told you so" from me). Real hardware is clearly the most accurate compared to itself, but has the disadvantage of needing maintenance and repair, sometimes modding to get better quality video quality out of it, and lately is becoming a bigger pain in the arse to connect to modern displays if you don't have a CRT available (things like NES and SNES sync jitter are causing headaches even for OSSC/RetroTink-2X users on certain displays).

 

Ultimately, it's up to you to choose what you want to sacrifice on a per game, per system basis. I like real hardware for my favourite systems, but am more than happy to use MiSTer for systems that are too expensive and I'm going to play less frequently (try finding a Sharp X68000 in 2019 for less than $500). Also MiSTer can't yet do CPS2 simulation for example, so I turn to GroovyMAME to play those games on an arcade cabinet (with full understanding that I'm sacrificing latency for the lower price and ease of multi-game setup).

 

The good news out of all of this is that there's now lots of options to play lots of games, and those options all have solid communities of clever people working on them. From a long term preservation point of view, it's a pretty exciting time.

 

Yeah I didn't get into the analogue hype. An OSSC + whatever console always seemed like a much better choice if you're spending that much money.

Especially in the US, getting RGB out of consoles can be difficult, which meant attaching them to OSSCs was difficult too. The Analogue consoles offered people true "plug and play" solutions, and with a fraction of the cables needed. Great news for non-technical folks who just want to play games.

 

I mentioned above NES/SNES jitter as well. The Analogue consoles offered both cycle-accurate and an ever-so-slight adjustment mode to output true 60.00Hz signals. That's technically "wrong", and if played side by side with a real console over hours and hours would end up ever so slightly further ahead. But it means perfect compatibility with every TV on the market (something an OSSC can't do, because it's a slave to the input signal).

 

So as above, pros and cons to every solution. It's just great that options exist for everyone.

Link to comment
Share on other sites

However answering your question directly - right now MiSTer (especially over non-scaled analogue output) offers objectively lower latencies than any MAME setup. Whether you notice it or not is subjective person to person, but the results are measurable. With that said, RetroArch now offers "run ahead" emulation, which is a bit tricky to explain, but the end result is lower latency than most other emulators (and sometimes even real hardware, which is pretty astounding to think about). But RetroArch's choice of emulators frequently choose speed over accuracy, which might affect your opinions on it depending on how much of a purist/pedant you are.

 

Welcome to GroovyMAME 2012 :D

 

GM has been using frame-delay for just-in-time emulation for at least 6 years. Unless I miss my guess this is the same as run-ahead but named from the other end, no?

 

GM and WinUAE also offer partial frame updates or frame-slicing, allowing a response to control inputs during the current frame. I'm not sure about WinUAE, but very few drivers in MAME actually allow partial frame updates and the other devs have been a little snippy over the community asking about it :)

 

EDIT: actually, i guess frame-delay would be very slightly slower than run-ahead, now i think about it. On average, that is. But frame-slicing would be faster than run-ahead, if it worked perfectly.

Link to comment
Share on other sites

GM has been using frame-delay for just-in-time emulation for at least 6 years. Unless I miss my guess this is the same as run-ahead but named from the other end, no?

I think it's slightly different from what you're talking about. RetroArch allows what is a emulation run ahead, calculate input, savestate, roll back to save state and play. You're essentially running 2 versions of the game running faster than realitime in the background, using save states to capture that information and then load it into your current session.

 

Details here:

https://www.libretro.com/index.php/retroarch-1-7-2%E2%80%8A-%E2%80%8Aachieving-better-latency-than-original-hardware-through-new-runahead-method/

 

It's quite bananas, and even allows lower latency than real hardware in some circumstances. The devs note it's highly inaccurate and experimental (prone to breaking some games even), but works in practice pretty often.

 

It's crazy resource intensive - you're emulating an extra instances of the same game on top of each other. But for older systems that can be emulated at several hundred times realtime speed, not an issue from a performance point of view.

 

Either way, the partial/sub frame updates methods and others are all cool tool. Like I said above: lots of options, and that's good for everyone. Software emulation, FPGA simulation, real hardware with signal converters - all of these suit different audiences. I use all three methods (bought a DE10-Nano just this week, waiting on MiSTer Addons to arrive soon, have multiple Linux/GroovyArcade/GroovyMAME cabinets, and tonnes of real hardware including my beloved CPS3 Third Strike kit in a Sega head to head cabinet and all of the Sega/Nintendo/Sony/Microsoft consoles). I use all of them depending on what I'm playing and how I'm playing it, and I can't see myself getting rid of any of it.

 

More ways to play more games means more fun.

Edited by elvis
Link to comment
Share on other sites

I think it's slightly different from what you're talking about.

 

Yeah, thinking about it some more, it is quite different. I wrote a whole huge post that wasn’t correct but turned out to be a good way to think through the concept. The descriptions of it in your links aren’t very clear until you understand it already though. My take on it, and correct me if I’m wrong is that if we have three frames 0,1,2, running in a game with one frame of input delay and with frame 0 being drawn to the screen at current time and also being the frame during which an input is received, the original game would not show a reaction to input until frame 2. But run-ahead will load frame -1 from save-state, calculate a new frame 0 and save state but not show anything because the old frame 0 is on screen, then calculate a new frame 1 and show it. Obviously we can run further ahead for games with more than one frame of input lag, so 0,1,2,3 or more.

 

I guess that’s the only way the inputs could be going back in time, after the popular phrasing. It’s very clever. Otherwise it would be just-in-time emulation.

 

Cheers for making me think about this. Now if only RA had a useable frontend… :D

Link to comment
Share on other sites

My take on it, and correct me if I’m wrong is that if we have three frames 0,1,2, running in a game with one frame of input delay and with frame 0 being drawn to the screen at current time and also being the frame during which an input is received, the original game would not show a reaction to input until frame 2. But run-ahead will load frame -1 from save-state, calculate a new frame 0 and save state but not show anything because the old frame 0 is on screen, then calculate a new frame 1 and show it. Obviously we can run further ahead for games with more than one frame of input lag, so 0,1,2,3 or more.

Yup, you got it. And you can see why it's so crazy resource intensive because of how it works. But with some older systems, it's actually achievable given how fast modern PCs are.

 

I think it's a great idea even if it's just a purely academic exercise. PCs are only getting faster, so why not do cool things with all that left over grunt when it comes to emulation tricks?

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...