• Hey, guest user. Hope you're enjoying NeoGAF! Have you considered registering for an account? Come join us and add your take to the daily discourse.

N64 in FPGA gets playable games, including Super Mario 64. Amazing progress on the WIP MiSTer "impossible" core

VGEsoterica

Member
Now keep in mind that "playable" means a lot of things...and the visuals on the current core make it feel like maybe you ate a handful of mushrooms before you sat down...but from a technical standpoint seeing the real time progress on pivoting the N64 to FPGA code is nothing short of spectacular

Everyone considered the 64 to be the "impossible console" on MiSTer. People thought there was no way to fit the entirety of the silicon of Nintendo's last cart based console in the logic element quantity of the Terasic DE10 Nano...but it seems like its truly possible after all as the core has gone from "hello world" to playing some fan made games to now booting in game to multiple retail titles. Sure there is still a lot to go with the developer FPGAZumSpass finishing up work on the Reality Display Processor or RDP...but the work is progressing and you can now play some very seriously weird looking sessions of Super Mario 64 or Star Fox 64.

Playable enough that we've been challenging ourselves to see who can get furthest into Super Mario 64 currently.

But if you have a MiSTer...start checking it out! It's worth testing and if you are on the MiSTer Discord we share progress, etc etc.

But GAF...who on here is looking forward to N64 on MiSTer FPGA? and who owns a MiSTer? if you dont...run, dont walk...and build one!

 

Dacvak

No one shall be brought before our LORD David Bowie without the true and secret knowledge of the Photoshop. For in that time, so shall He appear.
This is absolutely nuts. The MiSTer has been the best gaming purchase I’ve made in decades, and it would be so awesome if it got N64 compatibility.

I still haven’t tried out the Saturn beta core, but between that and N64, MiSTer dev is so exciting right now.
 

deriks

4-Time GIF/Meme God
In like two months, people got the N64 rendering - not fully, but it's something great

I really think that next year we have achieved total run
 
This is absolutely nuts. The MiSTer has been the best gaming purchase I’ve made in decades, and it would be so awesome if it got N64 compatibility.

I still haven’t tried out the Saturn beta core, but between that and N64, MiSTer dev is so exciting right now.
Ain't that the truth. The Neo Geo core back in 2019 was already worth it for me. What has happened since is just bonkers
 
Ares? What's that?

Multi System Emulator​


ares is a cross-platform, open source, multi-system emulator, focusing on accuracy and preservation.

linkie:
edit: Note, I hate traditional software emulation with a passion. I would love to love, but I can never get into a game when using it. I have no idea why... OTOH, i have completed more games in the past 4 years on mister than at any other time in my life.
 
Last edited:
I'm afraid to ask.... but why should I prefer this thing over the emulation on a thousand other devices?
Straight to the metal chip emulation. No lag from juggling another OS. Otherwise, you need a good PC for cycle-accurate emulation (i. e. a quad core Sandy Bridge at the bare minimum for SNES).
 

nkarafo

Member
Straight to the metal chip emulation. No lag from juggling another OS. Otherwise, you need a good PC for cycle-accurate emulation (i. e. a quad core Sandy Bridge at the bare minimum for SNES).
If your PC is good enough you can also achieve better input lag than both FPGA or even a real console by just cutting 1 frame of lag using run ahead or pre-emptive frames.
 

Krathoon

Member
The Sega Saturn core was released a little while back. It is now on the Update All script. It has been officially released.

The only game I could not get to work was the USA version of the Horde.

Could someone try that out?
 

Chittagong

Gold Member
I don’t understand how a N64 FPGA can be made legally given that the chips were bespokely made for Nintendo by SGI. My understanding is that 8 bit and 16 bit FPGAs were possible because the consoles used fairly simple, off-the-shelf chips.
 
Last edited:

Ozzie666

Member
I'll be one of those suckers looking to get Analogue 3D N64 system and controllers. Not sure what year I'll get it, or how much it will cost. But for my collecting I think it stops with N64 and the cartridge based systems. I assume the Pocket wont be strong enough to run the core. Exciting times. I like the idea of single systems for specific purposes, evne if the Mister project is awesome. Amazing what people are getting out of this stuff.
 

Drew1440

Member
I don’t understand how a N64 FPGA can be made legally given that the chips were bespokely made for Nintendo by SGI. My understanding is that 8 bit and 16 bit FPGAs were possible because the consoles used fairly simple, off-the-shelf chips.
The cpu was a standard MIPS VR4300 that also saw use in set top boxes and laster printers, so it was fairly common and well documented. Proprieatry stuff like the RCP usually gets decapped so they know how it works from a transistor level, from there they can rebuild the processor as an FPGA core
 

nkarafo

Member
This is just not true.

And what's your source? You just claim that without knowing any better i assume?

Runahead/pre-emptive frames in RetroArch has been a thing for a long time now. It's a thing on a few other emulators too lately. Now i admit it's not available yet on the N64 cores because it's too demanding. But in most other cores it is. And you can cut more than just a single frame. You can cut ALL the native lag frames a game may have on the original hardware. Super Mario World, for instance, has 2 frames of lag on the real SNES (and the FPGA as a result), you can cut both on every SNES core in RetroArch and have a more responsive game than the real thing.

Runahead:

Pre-emptive frames:


I can confirm these are working because i have been using RunAhead myself for years. But please, go ahead and explain how this is not true.


I don’t understand how a N64 FPGA can be made legally given that the chips were bespokely made for Nintendo by SGI. My understanding is that 8 bit and 16 bit FPGAs were possible because the consoles used fairly simple, off-the-shelf chips.

AFAIK, N64 FPGA is also emulation and not really cloned N64 chips. Some of the games have the exact same timing issues as software emulators had for years.
 
Last edited:

NeoIkaruGAF

Gold Member
And what's your source? You just claim that without knowing any better i assume?

Runahead/pre-emptive frames in RetroArch has been a thing for a long time now. It's a thing on a few other emulators too lately. Now i admit it's not available yet on the N64 cores because it's too demanding. But in most other cores it is. And you can cut more than just a single frame. You can cut ALL the native lag frames a game may have on the original hardware. Super Mario World, for instance, has 2 frames of lag on the real SNES (and the FPGA as a result), you can cut both on every SNES core in RetroArch and have a more responsive game than the real thing.
Honest question: why would you do this? Surely if adding lag is bad, cutting a game’s native lag changes the experience too? Why would SMW - a game that controlled perfectly on real hardware and tube TVs - benefit from this?
Of course, if a game originally had bad, noticeable lag, this is useful. No argument there.
 

RoadHazard

Gold Member
And what's your source? You just claim that without knowing any better i assume?

Runahead/pre-emptive frames in RetroArch has been a thing for a long time now. It's a thing on a few other emulators too lately. Now i admit it's not available yet on the N64 cores because it's too demanding. But in most other cores it is. And you can cut more than just a single frame. You can cut ALL the native lag frames a game may have on the original hardware. Super Mario World, for instance, has 2 frames of lag on the real SNES (and the FPGA as a result), you can cut both on every SNES core in RetroArch and have a more responsive game than the real thing.

Runahead:

Pre-emptive frames:


I can confirm these are working because i have been using RunAhead myself for years. But please, go ahead and explain how this is not true.




AFAIK, N64 FPGA is also emulation and not really cloned N64 chips. Some of the games have the exact same timing issues as software emulators had for years.


I thought the point of this was to actually replicate the original circuits to get perfect playback? It's just emulation? Then I don't get what the big hype is all about.
 

SScorpio

Member
I thought the point of this was to actually replicate the original circuits to get perfect playback? It's just emulation? Then I don't get what the big hype is all about.
It will probably end up recreating the logic output, matching the original hardware without a 1 to 1 recreation of the circuit and original logic design.

Emulation just means making one device behave like another. All FPGA cores are hardware emulators, versus something like Retroach that is software emulation.
 

nkarafo

Member
I thought the point of this was to actually replicate the original circuits to get perfect playback? It's just emulation? Then I don't get what the big hype is all about.

What exactly did you think the benefits of FPGA were VS software emulation? If you thought FPGA = "more accurate" or "closer to the real things" someone lied to you and it was probably the Analogue marketing team or some retro game collector who knows nothing about software emulation.

Accuracy does not depend on being FPGA or software. There is no magic sauce in FPGAs that make them inherently more accurate just because they are FPGAs. This myth needs to die already.

But let's see what the real benefits are:

1: There is no OS or background apps in the way, so you don't get any additional input lag from that.

2: The device is very compact and plug & Play.

3: Plays nicely with CRTs without much fuss.

4: Consumes much less power for the same amount of accuracy as a software emulator on a powerful CPU.


It has a lot of benefits but better accuracy isn't one of them. Accuracy depends 100% on the developer and code, just like software emulation (and there are plenty of accurate software emulators btw).

Software emulators have their own benefits, like way more options and features being the most obvious.


Honest question: why would you do this? Surely if adding lag is bad, cutting a game’s native lag changes the experience too? Why would SMW - a game that controlled perfectly on real hardware and tube TVs - benefit from this?
Of course, if a game originally had bad, noticeable lag, this is useful. No argument there.

You must take into account that CRT TVs are no more. And modern LCD TVs have additional input lag on top of any native lag a game has. So if you play SMW on a real SNES connected to an LCD, you are not getting the original experience, you are getting a laggier experience, not to mention the raw pixels look that isn't the intended one. You only get the original experience if you also play on a CRT.

Enter RetroArch. This is a program that runs on various PCs and other systems. All these systems may add lag themselves, on top of the LCD lag. Lets say you get +1 frame from the System/OS and +1 from the LCD (worst case scenario). Add the 2 frames the game has natively and that's a total of 4 frames of lag, which is pretty bad for a 60fps platform game. So, by shaving off the 2 native lag frames from the game, you balancing it out and you get the 2 frames of lag original experience. However, you can't shave more frames than that because then you shave active frames and that can cause artifacts like stutters. Run-Ahead only shaves native game lag, not LCD or OS lag.

So, to get better response than the real game you can use RetroArch on a very fast VRR or CRT PC monitor and also use Run-Ahead on top of that setup. I have a 240hz VRR monitor and the difference in responsiveness is noticeable. If you want the "perfect" way to play this particular game, that's the way. It may not be the original experience but it's a better one and in the end, the thing is RetroArch (software emulation) gives you all these options and flexibility to make the game as responsive as you want.
 
Last edited:

RoadHazard

Gold Member
What exactly did you think the benefits of FPGA were VS software emulation? If you thought FPGA = "more accurate" or "closer to the real things" someone lied to you and it was probably the Analogue marketing team or some retro game collector who knows nothing about software emulation.

Accuracy does not depend on being FPGA or software. There is no magic sauce in FPGAs that make them inherently more accurate just because they are FPGAs. This myth needs to die already.

But let's see what the real benefits are:

1: There is no OS or background apps in the way, so you don't get any additional input lag from that.

2: The device is very compact and plug & Play.

3: Plays nicely with CRTs without much fuss.

4: Consumes much less power for the same amount of accuracy as a software emulator on a powerful CPU.


It has a lot of benefits but better accuracy isn't one of them. Accuracy depends 100% on the developer and code, just like software emulation (and there are plenty of accurate software emulators btw).

Software emulators have their own benefits, like way more options and features being the most obvious.




You must take into account that CRT TVs are no more. And modern LCD TVs have additional input lag on top of any native lag a game has. So if you play SMW on a real SNES connected to an LCD, you are not getting the original experience, you are getting a laggier experience, not to mention the raw pixels look that isn't the intended one. You only get the original experience if you also play on a CRT.

Enter RetroArch. This is a program that runs on various PCs and other systems. All these systems may add lag themselves, on top of the LCD lag. Lets say you get +1 frame from the System/OS and +1 from the LCD (worst case scenario). Add the 2 frames the game has natively and that's a total of 4 frames of lag, which is pretty bad for a 60fps platform game. So, by shaving off the 2 native lag frames from the game, you balancing it out and you get the 2 frames of lag original experience. However, you can't shave more frames than that because then you shave active frames and that can cause artifacts like stutters. Run-Ahead only shaves native game lag, not LCD or OS lag.

So, to get better response than the real game you can use RetroArch on a very fast VRR or CRT PC monitor and also use Run-Ahead on top of that setup. I have a 240hz VRR monitor and the difference in responsiveness is noticeable. If you want the "perfect" way to play this particular game, that's the way. It may not be the original experience but it's a better one and in the end, the thing is RetroArch (software emulation) gives you all these options and flexibility to make the game as responsive as you want.

I did think it was supposed to be closer to the actual hardware, i.e. more accurate, yes.

Alright, so VS a RPi with RetroPie it's pretty much just the lower input lag? And maybe the CRT aspect?
 
Last edited:

nkarafo

Member
I did think it was supposed to be closer to the actual hardware, i.e. more accurate, yes.

Alright, so VS a RPi with RetroPie it's pretty much just the lower input lag? And maybe the CRT aspect?
VS the Pi the FPGA its also more accurate. Because the Pi is the bottom of the barrel for software emulation. Its the weakest device. For accurate software emulation you need a low-mid range PC mostly.
 

raul3d

Member
Accuracy does not depend on being FPGA or software. There is no magic sauce in FPGAs that make them inherently more accurate just because they are FPGAs. This myth needs to die already.
Not to start a philosophical discussion or to derail the thread (too much), but this is also not completely true: FPGAs do have an inherent advantage by their very nature of emulating in hardware. When emulating systems, with many components working in parallel and influencing each other, it fits the nature of the FPGA and it's programming model. For software emulation, you have to throw more hardware resources at the issue (higher clocks and more threads). Sure, in the end, it depends on the abilities of the developer and both can get the job done, but depending on how accurate you want to be (e.g. bus contentions and other side effects), the hardware requirements for software emulation can be considerable, even for rather old and slow systems.
 

nkarafo

Member
Not to start a philosophical discussion or to derail the thread (too much), but this is also not completely true: FPGAs do have an inherent advantage by their very nature of emulating in hardware. When emulating systems, with many components working in parallel and influencing each other, it fits the nature of the FPGA and it's programming model. For software emulation, you have to throw more hardware resources at the issue (higher clocks and more threads). Sure, in the end, it depends on the abilities of the developer and both can get the job done, but depending on how accurate you want to be (e.g. bus contentions and other side effects), the hardware requirements for software emulation can be considerable, even for rather old and slow systems.

I literally posted the same thing. That accuracy on software emulators requires more resources. Both software and FPGA can reach 100% accuracy (Bsnes is software emulation and it's pretty much 1:1 cycle accurate) but FPGA can do it with less resources. That doesn't make FPGA more accurate, it makes it more efficient.
 

Grechy34

Member
What exactly did you think the benefits of FPGA were VS software emulation? If you thought FPGA = "more accurate" or "closer to the real things" someone lied to you and it was probably the Analogue marketing team or some retro game collector who knows nothing about software emulation.

Accuracy does not depend on being FPGA or software. There is no magic sauce in FPGAs that make them inherently more accurate just because they are FPGAs. This myth needs to die already.

But let's see what the real benefits are:

1: There is no OS or background apps in the way, so you don't get any additional input lag from that.

2: The device is very compact and plug & Play.

3: Plays nicely with CRTs without much fuss.

4: Consumes much less power for the same amount of accuracy as a software emulator on a powerful CPU.


It has a lot of benefits but better accuracy isn't one of them. Accuracy depends 100% on the developer and code, just like software emulation (and there are plenty of accurate software emulators btw).

Software emulators have their own benefits, like way more options and features being the most obvious.




You must take into account that CRT TVs are no more. And modern LCD TVs have additional input lag on top of any native lag a game has. So if you play SMW on a real SNES connected to an LCD, you are not getting the original experience, you are getting a laggier experience, not to mention the raw pixels look that isn't the intended one. You only get the original experience if you also play on a CRT.

Enter RetroArch. This is a program that runs on various PCs and other systems. All these systems may add lag themselves, on top of the LCD lag. Lets say you get +1 frame from the System/OS and +1 from the LCD (worst case scenario). Add the 2 frames the game has natively and that's a total of 4 frames of lag, which is pretty bad for a 60fps platform game. So, by shaving off the 2 native lag frames from the game, you balancing it out and you get the 2 frames of lag original experience. However, you can't shave more frames than that because then you shave active frames and that can cause artifacts like stutters. Run-Ahead only shaves native game lag, not LCD or OS lag.

So, to get better response than the real game you can use RetroArch on a very fast VRR or CRT PC monitor and also use Run-Ahead on top of that setup. I have a 240hz VRR monitor and the difference in responsiveness is noticeable. If you want the "perfect" way to play this particular game, that's the way. It may not be the original experience but it's a better one and in the end, the thing is RetroArch (software emulation) gives you all these options and flexibility to make the game as responsive as you want.

If you ask the FGC scene these days you'll note the increasing using of FPGA hardware at their tournaments. They never considered software emulation and according to many I've asked were due to certain timings they were never able to replicate at a high level consistently. FPGA has been a complete game changer for them for games emulated on that particular hardware.

In saying this I do believe software emulation is great and I'm happy that people enjoy these games however they wish, I think it's fair to say we are spoiled for choice even on a budget.
 

SScorpio

Member
If you ask the FGC scene these days you'll note the increasing using of FPGA hardware at their tournaments. They never considered software emulation and according to many I've asked were due to certain timings they were never able to replicate at a high level consistently. FPGA has been a complete game changer for them for games emulated on that particular hardware.

In saying this I do believe software emulation is great and I'm happy that people enjoy these games however they wish, I think it's fair to say we are spoiled for choice even on a budget.
I'm not sure if it's that Brooklyn shop, but I saw a tweet recently where the owner of a known arcade in the FGC community mentioned that he had MiSTers in a few of his Candy Cabs for a few years and hasn't told anyone. So they are mixed in next to original boards. And no one has questioned it, or spotted anything off.

It is still something someone has made so there can always be bugs with odd corner cases that nobody has run into yet. But a complete JAMMA MiSTer setup can be less than the cost of some of the original boards it can do. And you can very quickly switch between games as easily as a multicart for the NeoGeo or one of the CPS systems, only it can be a completely different board.

And even when an FPGA core seems 100% comparable to the original hardware. There are still people decapping chips or using electron microscopes to scan custom chips, and the logic is then rewritten to be an exact match, versus what was observed by probing the inputs and outputs of the chips, even for scenarios that wouldn't occur with any of the existing software for the platform. There will always be people claiming that software emulation is good enough, but they seem to ignore that issues and fixes that are found make their way into the software emulators as well. So everyone benefits from the work being done to understand are preserve the hardware.
 
Last edited:

NeoIkaruGAF

Gold Member
You must take into account that CRT TVs are no more. And modern LCD TVs have additional input lag on top of any native lag a game has. So if you play SMW on a real SNES connected to an LCD, you are not getting the original experience, you are getting a laggier experience, not to mention the raw pixels look that isn't the intended one. You only get the original experience if you also play on a CRT.

Enter RetroArch. This is a program that runs on various PCs and other systems. All these systems may add lag themselves, on top of the LCD lag. Lets say you get +1 frame from the System/OS and +1 from the LCD (worst case scenario). Add the 2 frames the game has natively and that's a total of 4 frames of lag, which is pretty bad for a 60fps platform game. So, by shaving off the 2 native lag frames from the game, you balancing it out and you get the 2 frames of lag original experience. However, you can't shave more frames than that because then you shave active frames and that can cause artifacts like stutters. Run-Ahead only shaves native game lag, not LCD or OS lag.

So, to get better response than the real game you can use RetroArch on a very fast VRR or CRT PC monitor and also use Run-Ahead on top of that setup. I have a 240hz VRR monitor and the difference in responsiveness is noticeable. If you want the "perfect" way to play this particular game, that's the way. It may not be the original experience but it's a better one and in the end, the thing is RetroArch (software emulation) gives you all these options and flexibility to make the game as responsive as you want.
Yeah, I know what RetroArch is and I knew about the Run-Ahead function.
I was just wondering about the actual usefulness of the function. I played for 10 years on a plasma that, as far as I could ascertain via online sources, had a 22ms lag and I never noticed in actual gaming. CRTs also had 8ms lag to my knowledge, but we used to call that "no input lag". Gaming mode on some modern TVs has brought lag down as low as 4ms if I'm not mistaken, making them MORE responsive than CRTs if you don't consider the lag from wireless controllers.

I guess if you know the exact lag your controller and screen are adding, the Rum-Ahead function can be very useful. In most cases though, I guess there's a lag threshold between 8ms and 20-something ms that is virtually unnoticeable while playing unless you're playing something that requires literally instant response.

I guess this is derailing the thread a bit though. Sorry about that.
 

marquimvfs

Member
I don’t understand how a N64 FPGA can be made legally given that the chips were bespokely made for Nintendo by SGI. My understanding is that 8 bit and 16 bit FPGAs were possible because the consoles used fairly simple, off-the-shelf chips.
Legally you can reverse engineer (open, study, observe, document, etc) every piece of hardware inside a system and use your knowledge to create a chip (or several ones) by your own with the same functionality. Given that it's not a copy pasta and you don't use any piece of proprietary software that may reside within the chips (bioses, for example), you will be more than allright, talking about the law itself. You just need to be smart at replicating functionalities without replicating the component itself.
 
Last edited:

nkarafo

Member
If you ask the FGC scene these days you'll note the increasing using of FPGA hardware at their tournaments. They never considered software emulation and according to many I've asked were due to certain timings they were never able to replicate at a high level consistently. FPGA has been a complete game changer for them for games emulated on that particular hardware.

In saying this I do believe software emulation is great and I'm happy that people enjoy these games however they wish, I think it's fair to say we are spoiled for choice even on a budget.

There are some arcade boards that are emulated more accurately on FPGA currently AFAIK. And there is also the matter of input lag, which by default is lower for the reasons i already stated.

Also, even though software emulators can be just as accurate or more (like how Bsnes is currently more accurate than Analogue and FPGA SNES cores) they are still more finicky and may perform differently depending on the host hardware and setup/options. FPGAs don't really have much to setup and just like consoles, they are all the same so they also perform the same. Which is a very important thing for fair play in tournaments.


Yeah, I know what RetroArch is and I knew about the Run-Ahead function.
I was just wondering about the actual usefulness of the function. I played for 10 years on a plasma that, as far as I could ascertain via online sources, had a 22ms lag and I never noticed in actual gaming. CRTs also had 8ms lag to my knowledge, but we used to call that "no input lag". Gaming mode on some modern TVs has brought lag down as low as 4ms if I'm not mistaken, making them MORE responsive than CRTs if you don't consider the lag from wireless controllers.

I guess if you know the exact lag your controller and screen are adding, the Rum-Ahead function can be very useful. In most cases though, I guess there's a lag threshold between 8ms and 20-something ms that is virtually unnoticeable while playing unless you're playing something that requires literally instant response.

I guess this is derailing the thread a bit though. Sorry about that.

You are talking about screen lag here. But this isn't the only source of lag. I gave Super Mario World as an example. That game has 2 frames of native lag, which means 32ms just from the game itself. Even if you have a zero lag screen, a zero lag system/OS and a zero lag controller, you would still have those 32ms of lag because it's hard coded into the game.

Run Ahead will take care of that game native lag. That is it's usefulness. I tested the game myself on my setup, with 2 frames shaved off and i can feel the difference. The game was responsive enough before but with the native lag frames taken care off, it feels even better.

Some games have even more frames of lag. The Mortal Kombat ports on SNES have much more lag than the Genesis ports and this is why the later play better. But the SNES ports look better so by shaving a few frames to make them as fast as the Genesis versions you get the best of both worlds. If for some reason you don't want to play the Arcade versions that is.
 

SScorpio

Member
Yeah, I know what RetroArch is and I knew about the Run-Ahead function.
I was just wondering about the actual usefulness of the function. I played for 10 years on a plasma that, as far as I could ascertain via online sources, had a 22ms lag and I never noticed in actual gaming. CRTs also had 8ms lag to my knowledge, but we used to call that "no input lag". Gaming mode on some modern TVs has brought lag down as low as 4ms if I'm not mistaken, making them MORE responsive than CRTs if you don't consider the lag from wireless controllers.

I guess if you know the exact lag your controller and screen are adding, the Rum-Ahead function can be very useful. In most cases though, I guess there's a lag threshold between 8ms and 20-something ms that is virtually unnoticeable while playing unless you're playing something that requires literally instant response.

I guess this is derailing the thread a bit though. Sorry about that.
CRTs didn't have lag anywhere near that, a Time Sleuth on a CRT will report back something in the range of 0.14-0.22ms on a PVM. You have an analog signal that an electron beam is drawing across the screen in real-time. There's a fun book that talks about the early days of the Atari 2600 called Racing the Beam. The 2600 didn't have much in the way of resources, and what was being computed to be displayed was happening synchronously.

Modern displays rely on a frame buffer, so there will always be at least one frame behind to just send the image to the display. Then the display itself will add even more lag as it takes time to process the signal and draw it. Sure on that 240hz monitor you have a crazy high refresh rate, but are you sure you aren't seeing 2-3 frames in the past?

Try something like NES Punchout that relies on split-second reaction time for some of the tells to get one-hit KOs, and play with run ahead turned off and on and see if you can feel the difference. Not everyone can, but a good number of people do notice differences.
 

Futaleufu

Member
There are some arcade boards that are emulated more accurately on FPGA currently AFAIK. And there is also the matter of input lag, which by default is lower for the reasons i already stated.

I would assume someone setting up a patreon for FPGA core development has more motivation than someone who writes and submits code for MAME in their free time as a hobby.
 
Top Bottom