"Thirty years ago, when I was sitting in front of my living room TV-" Playing the NES, yeah, I remember that. "- playing Super Nintendo-" *YOU SHUT YOUR DIRTY MOUTH! I'M NOT OLD, YOU'RE OLD!*
little fun fact, the playstations 30th anniversary is in a few days. December 3rd 1994. (if your only counting north american release, then its turning 30 next year in september)
One thing that was not mentioned is reduced input lag that fpga can provide. This is due the parallel cycle accurate nature of the fpga emulation as it can run in sync with the display output as the original hardware did. Basically all the software emulators have render to a "backbuffer" which is displayed at least a frame later.
yeah... input lag is my main reason to buy FPGA system. other than that.. I actually prefer software based emulators because it has so many added functions- cheats, fast forward, etc.
@@edmundroth6337 Yeahhhhh... GPU sync and Runahead kinda invalidate the input lag argument. FPGA strikes me as being more helpful for systems that are actually really hard to emulate, as a cheaper alternative. Or for playing physical carts, I guess. Problem is that emulators gets better over time and hardware gets better and cheaper, so at a certain point, I question what niche it will even fill, if those hard to emulate systems become easier and cheaper to emulate over time. Maybe as a replacement for older hardware hooked up to CRT tvs? I'd take an FPGA PS2.
Software emulators can be as accurate as FPGAs, and FPGAs can be as bad as glitchy software emulators. The Air Strike quirk in software emulation has been fixed years ago, and not through tricks but actual cycle accurate software emulation. Same with Speedy Gonzales. It was one of BSNES's highlights to prove that it was more accurate than the other software emulators of its time, and that was like 14 years ago! If you still see that bug in handheld software emulation devices it can be for several reasons: the company selling these devices don't ship them with up to date emulators, you as a user or the company selling these products aren't using the right emulators, or the device is not powerful enough to run accurate emulators and has to resort to speed hacks that sacrifice accuracy for performance. 22:48 just like a well programmed software emulator. Why so many FPGA/Software emulation comparison videos focus on bad software emulators or emulators meant for cheap and under powered devices?
As I said in a separate comment: "God, I love the CPU section of the video. Thanks for actually explaining this shit to me whereas nobody has been able to do so till now."
You are making super comprehensive videos on super hard subject, thank you , and I’m a video game designer ;) was waiting years to get this level of clarity in an explanation. Ken you are a master of your craft, keep posting content !!!!❤❤
Thank you for the Super, kind comments, and encouragement - very generous! Very cool that you’re a game designer! Can you share any titles you’ve worked on?
I'm an FPGA engineer with some comments: Short explanation about "simulating clock cycle accurate requirements": Say I need accuracy because my FPGA is going to run a car's dashboard software and hardware interface. I'm expecting to simulate 1 second per DAY on a beefed up server farm for a simulated 1080p display. But this is important because I need to check the equivalent of Speedy Gonzalez button #523 in level 17, but for a car. Don't want your ABS to not work because it's January 19, 2038. HDLs are also completely compatible with creating an ASIC. That is, I can send over a netlist (intermediate design file) to the blokes over in Taiwan and after a few 1000s of dollars, I can create a big box of NES/PS1/N64 on chips the size of a particularly large postage stamp. Per unit cost is far, far cheaper. You often use FPGAs to prototype this kind of thing before sending it off to be fabricated. About power draw, we have a big honking huge window in the FPGA simulator that talks all about how the FPGA design you're making is gonna suck up the wattage of a hairdryer. And where do you think all of that energy goes? You'll be on the verge of deaf in FPGA labs from the cooling fans, let me tell ya. Finally, a lot of games work on BUGS of the console, rather than the intended functionality. You see 25:55, right? I can assure you that the dev of your childhood favorite game got a cool animation to work because they used undocumented opcodes that did weird things. Or maybe overloading the PSX vbuffer causes a rather cool transparency effect that's hard to emulate. What if you somehow got 2-3 FPS extra in a game by glitching out the GPU with some wild string of bits? I actually find a few bugs in FPGAs where signals are ten NANOSECONDS late and that causes a bug. That's how picky these effects can be.
Thank you for this video! I recently started using an Analogue Pocket because I didn't understand the hype for fpga when compared to cheaper emulation handhelds. But now I have a slightly better understanding and appreciation for fpga.
I heard the word fpga a lot and I just assumed it was a framework to physically hand create chips. I had no idea that you actually can flash them to different setups and emulate multiple systems off the same chip. That's super cool and super informative, thank you for this video!
Ignorance + Assumption = a great example of why it is possible to dig up decades old tech, add some catchy marketing, and pretend it is new. Electric cars are a great example of this, where people think it is new tech when in reality electric cars were available in the 1800s and failed for the same reasons then that they are failing now.
@@alphaforce6998 Electric motors are marginally better today than in the XXth century (because they were pretty much perfect devices already, far better in terms of efficiency than any combustion engine is and will ever be), but batteries are miles better today than even a few decades ago. Saying the tech is the same than in the XIXth or XXth century is false or at least not entirely true.
@@benjib2691 The battery tech may have improved, but it's still far from being even practical as compared to fuel...plus, there is no benefit to making heavy vehicles electric when there is an abundance of fuel. The entire eco-doom used to justify the inferior tech is based entirely on lies.
@@lpfan4491Apart from Teslas, sales of electric cars have been poor with most of the big automakers having lost money trying to convert their production lines to selling them. This is true even with all of the subsidies & corporate welfare that the government doles out for electric cars. The American public never wanted electric cars, they wanted Teslas. Heck these days even Tesla has seen some of their sales figures falling short of projections.
Rest in Peace to Bsnes’s developer, he took his own life years back and it was very sad. I remember reading that article years ago shown at 13:30 and being so interested in the progress of Bsnes. I try to use it any chance I get on my main gaming PC.
Only the online persona is gone, the actual man is still alive an healthy. Japan like most countries publishes all foreigners' deaths and there were none from that year.
The way the video was presented reminded me of one of those “How it’s made type shows.” I didn’t even know I was interested enough to know what’s going on behind the scenes of all these games and systems I play to watch this type of deep dive video, but this was really informative and genuinely fun to watch. Awesome job man!
I'd actually argue that software emulation is getting comparatively easier with more modern systems (meaning the required overhead for accurate-enough emulation is lower relative to the emulated system power) because consoles have become more like general purpose computers in that they employ increasing layers of abstraction between hardware and the application software. This allows for HLE (High-Level Emulation) which tends to be much easier on overhead while still being very accurate (to the point of the SDK APIs available to the developers). This is basically a symptom of the fact that such systems have inherent overhead (for hypervisors, OS, drivers and libraries; a.k.a. system firmware) even in their original form, and by employing HLE a lot of that overhead can be eliminated in an emulator, leaving more headroom for the (proportionally smaller) application code that must always run through emulation. These abstractions also tend to have a stricter API surface than old bare-metal hardware, making it harder for games to exploit edge-cases (They might break in the next system firmware update for example) which is the reason cycle-accuracy can be important for old systems. You could say the more defined API surface makes more "shortcuts" safe so long as they conform to the API contract. Then again, modern complex graphics APIs are still a big old mess, even on PC and especially on mobile-oriented graphics cores.
I'd argue translation layers aren't really emulation. You could argue programs like Box86 are as they need to translate to a different architecture, but programs like wine, proton, and dxvk are only really changing OS syscalls and apis. They aren't emulating any hardware.
The lockup in Speedy Gonzales only happens with very low accuracy SNES emulators like ZSNES, while the rotating text and shadow of the plane in Air Strike Patrol is the only game in the entire SNES library that requires the BSNES accuracy core to display properly. ZSNES in particular is a very problematic emulator and I would not recommend anyone to use it, unless you're still rocking one of those 90s Pentium processors. It can even run on a 486 if you're brave enough.
I love all the options. I have emulation running on my Steam Deck and use FPGA on my Analogue Pocket and Mister FPGA. I'm not sure I'm the type of person who would notice the differences too much between them.
I did a frame by frame count of Saturn emulation on my computer running it in Saturnus. It was on par with actual hardware for input latency and at most maybe a frame behind on rare occasion but that might be user error when I was counting. With run ahead it is a frame quicker. Run ahead for a frame on my 1 year old system running a Saturn game brings it to its knees and can I tell the difference. Honestly nope. Well I can tell if I got almost anything else open because my whole computer starts getting a bit choppy.
For me it's fine as long as it's running the games at adequate performance and don't cause any graphical corruption or sound issues. For example: I wouldn't care about the shadows in Air Strike Patrol, but I would notice the doubled "Good Luck" text. As long as software emulation is "accurate enough" it's fine by me. But I'm also the kind of person who runs software emulation for MIDI audio and switches soundfonts on a regular basis.
It's the edge-cases that get you on emus. Most games will Just Work but there are always a few that used undocumented or co-incidental behaviors of the system that really show where fpga can shine.
@@nobodynoone2500 In efficiency it will always go to a hardware solution. In flexibility and additional features software usually has an easier time implementing them. Both solutions can do mostly the same things the other can to differing degrees. But not being documented hurts both options equally. If not implemented it will not appear by magic.
I am glad I stumbled upon this video. It is an enlightenment to me as a casual gamer who has been confused about all these technical terms for a long time. I appreciate the pace you talked so I can really catch up, digest and understand the explanations. And the effort not to polarize opinions is commendable. Please keep up the good work and grow the content, and I am sure this channel will be a great success.
FPGAs allow more direct implementation of the original circuit, if it's known. This is a lot less error-prone and more reliable than coding it in software. In a lot of cases it's the only one possible performance-wise if you want 100% fidelity to the original because you have to take shortcuts in a software implementation. Both can still suffer from inaccuracy because they both require 100% accurate and complete reverse-engineering of the original system. This video is a good overview of emulation and the two main approaches.
@@desmondcayce I wrote that myself. Is that a compliment? I spent many years reverse-engineering consoles and writing emulators so I have a little bit of experience to draw on. I agree and despise people using AI to generate web pages, product reviews, social media posts, without labeling it as such.
my 4 year undergraduate in electronics and computers got its money worth while watching this video. thank you so much for such a comprehensive look on these systems.
You managed to make 27 minutes of technical information sound accessible and even conversational. I'll be coming back just to dig a little deeper into the topics covered here. THANK YOU!
I don't know if I've seen a video so thoroughly explain how software and hardware emulations works. And while I definitely need to rewatch this as well as look into more information on the topic, I really enjoyed this and it makes me want to understand how it all works more.
Really nice video explaining emulation and the software/fpga trade off. I wrote a software NES emulator a while back and it was a great project that helped me better appreciate the beauty and cleverness of these old systems, which went to great lengths to push amazing performance out of very limited hardware.
What a great explanation. I've had some of this explained to me in the past, but it was joy to hear it all over again delivered in this style. And I learned more about what FPGAs do too!
Great explanation and video. This whole thing reminds me of the audiophile stuff to some degree. Where if you have to point out very specific (or obscure) cases that are noticeably different, then it probably doesn't matter to 99.9999999% of the people. Even though I was really interested in the FPGA stuff when it was first becoming popular, I am now leaning back into software emulation. Because not only can I not tell the difference unless I am really looking, but I also get a much better QoL with software emulation. More devices emulated (espicailly when you are talking about arcade hardware and newer consoles), Run-ahead, RetroAchievements, online play, much better looking interfaces, bezel project, real-time translation (though I havent tried that yet) and just tons more options in general. Not even talking about the costs advantage, it really is hard for me to justify buying FPGA for the improvements I would never notice unless I was running something side by side (and maybe not even then). With that being said, I love all the options and if FPGA can add a lot of those same features that the software emulated solutions offer in the future, it would be amazing.
That's the argument I tend to use to defend software emulation. Most consoles up to the PS1 are in very good hands nowadays, it's really rare that a game would have game breaking issues. I think the reason why those two games he tested show such blatant errors is because the default emulator used in the miyoo mini is very outdated and optimised for weak arm chips,(Supafaust) but there's an option to use Snes9x too, which would probably solve those issues.
@@davidoli I use one of those Anerbernic devices and I am not sure how they compare hardware wise (aside from both being ARM) But it is similiar in that it easily does the older stuff np, but even though it is not perfect, Dreamcast and Saturn stuff works pretty good with solid framerates (I think I have a single frameskip option on one to fix audio breakup). I was honestly shocked because I never thought a device like it would be able to have those systems perform as well as they do. So while not perfect, at least portable software emulated devices can have those games playable. Who knows when/if we will ever see a portable FPGA device that can play something like Dreamcast. Also, I have all the above features I mention on my portable software emulated device as well. So using something like the Analogue Pocket would feel like a step backward in comparison (Aside from build quality)
The real big difference is that we're not just able, but we ARE having this discussion, rather than blindly go "so, erm, FPGA is like, better, so it's not emulation...?" In my experience gamers are jsut on a different level. The lower level. They take film industry terms like "genre" and "remaster" and absolutely mangle them into this consumerist mold, like "remaster is when it LOOKS BETTER". When in fact, a "remaster" WOULD BE something like emulation. The optimal "video game remaster" that people want out of remaster over a remake, would be the same as George Lucas "remastering" out the "dated" practical effects. But everyone just AGREES that mangling the original game with this contemporary plastic sheen of "modern standards" is GREAT. Like those AWFUL 30% resin "wood" dining tables that cost thousands of bucks. Or remastering LotR to look like HD Hobbit and every telenovela after 2007. Original TVs were a low tier consumer-grade device. There is no such thing as chasing the "authentic" experience the same way as films though, because TV release ALREADY was a heavily truncated and variable expereince, even on video games. You did NOT have some optimal conditions to "expereince the art" you're now trying to preserve, because it would be like Mona Lisa in a dimly lit room. "Most people who wouldn't care" are nostalgic for their POST CARDS of Mona Lisa from childhood. And that's always the exerience with art. Fantasy abut escapism completely ruins the interplay where YOU create the experience monstly for yourself, sme great PIECE of art is no more than a hint of th author's vision carrying on to you as a recipient. But it gets pretty bad when the DISCUSSION is "we should remaster Mona Lisa into a portable HD post card" the way it is with video game consumerism. There will be no return to Woodstock. That's not how genuine art WORKS, and Mozart didn't RECORD any of is pieces. They're recreations like art always would be. PIECES of art are always contemporary but what is ART as a whole is their addition to the historical canon. Somthin people CAN'T consume when they're so worried about spoilers. Then it stops beign a discussion with the artist and becomes a lecture, a little commecial escape room where the "art" is providing some puzzle of a metaphor you're too coy to address directly, like reading Animal Farm as a children's book. What art is that?
@@sboinkthelegday3892 Very well said. In general I can enjoy many aspects of how something is presented, but I tend to lean toward "authentic" when possible. So I have my real hardware and CRT to scratch that itch (as close as I reasonably can, it will never be exactly how it was when I was younger). But the newer way the content is presented and consumed, (pixel perfect/modern screens/emulated), I try and appriciate it as its own thing instead of a replacement.
Software Emulation and Hardware Emulation can be just as accurate as the other. It only depends on the time and dedication spent by the programers. Software emulation is more flexible and feature rich, but accuracy require more computing power so that's why emulation on cheap devices can be glitchy or laggy as they're using shortcuts/speed hacks in order to compensate the weakness of the host hardware. FPGAs are more efficient and usually don't necessitate as much tinkering from the user to get great results out of the box.
Well done video! I used vhdl in college and programmed in assembly on x86 and on 6502 and appreciate very much your fine explanation. The examples you chose of timing challenged games was perfect. I still wonder if those who don't understandeither would have have sat through your explanation 😮
I wrote a nintendo gameboy emulator in typescript from the ground up this year and really enjoyed the whole process. I can truely say I know what makes the thing 'tick' now
This video describing teh difference between software and FPGA is really a gem,i always wondered what teh difference was between those 2 , but a lot of videos i watched are to complex or tell it weird, yours i almost immediately understand. so a very high thx
One more thing i forgot to tell was, i love those animations of teh working of the insides you show, it makes things a lot easier to follow, also i hope to see some more videos about FPGA stuff, it really peaks my interest as somebody that watched the upcoming from pong to the newest games today, yes i am alreday 54 but i hope to see even more chanegs
That's so cool. I've been a software developer since the 70s, but I've never even so much as dipped my toes in to FPGAs. I might need a toy project to screw around with.
Excellent video, you covered pretty much all the major advantages and disadvantages of both approaches really well. The only things I would add is that in the software camp latency can often be an issue, due to overhead from the operating system for both receiving input and outputting to a display, especially where a modern dedicated GPU is involved. And in the FPGA camp one of the major downsides can be lack of enhancements or features - software emulation naturally lends itself to ie. high definition asset packs or widescreen hacks, whereas if they aren't designed with them in mind in the first place FPGA emulators will often be missing even fundamental features like save states, or even the ability to pause at all.
RetroArch on Linux is actually perfectly capable of matching FPGAs in input latency. By using the Linux kernel's realtime task deadline features, and starting RetroArch without a display server or desktop environment running, it guarantees system responsiveness, and takes complete, exclusive control over the graphics hardware and input devices. Then it can apply low-level optimizations, hard-synchronize the GPU, and have direct, granular control over the main framebuffer swapchains. After that, the only latency left is whatever's inherent to your display and controller. RA is also capable of delaying the emulator loop, to effectively finish processing and drawing a frame as late as possible into the refresh cycle, just before the GPU will need it for the screen and effectively racing the GPU to the framebuffer swaps. That's basically what a properly configured Lakka is. Of course, many old games have built-in input lag that shows up even in FPGAs and original hardware. And this is before even bringing Run-Ahead into the picture.
can you actually show how to do this? an article or something would help I remember Higan and Ares doing exclusive GPU and audio sync, the same thing you said here.
@@flintfrommother3gaming For starters, exclusive mode only really works with the Mesa graphics stack. So no NVIDIA proprietary driver. Preferably use an Intel or AMD GPU. Second, rather than manually setting all of this up on a standard, general-purpose Linux system, just install Lakka. It's a minimal, dedicated Linux distro with most of these things already setup for you. Then you enable hard sync on the Retroarch settings menu. The main ingredient making this work is running Retroarch in direct DRM/KMS mode, aka just running it on the commandline tty without any X or Wayland services running. If you have a display with Freesync, even better, since RetroArch will be able to synchronize the refresh rate to the old NTSC/PAL spec instead of the standard HDMI modes.
Nice video! A critical misconception about FPGA emulators that many people have is the assumption that they're intrinsically more accurate than software emulators when that is not necessarily the case. In the Gameboy example, let's take opcode 0xCB8F, which resets bit 1 in register A to 0. I can write some code that will essentially look like reg_A &= ~(1
Fortunately the resulting netlist can be simulated as well and compared against the original HDL. And when a bug is found, the bitstream can be replaced. I would therefore say that the possibility for accurary is better provided than with most software solutions. I do however understand what you say. The MiSTer is not perfect as well. Some cores have very special problems which are occuring as not much interest is there to maybe fix it or the problem is small or barely noticable. The Amiga mouse emulation is still a problem today... Still the more developers are participating, the faster could a problem be resolved. The N64 core of the MiSTer currently has a very big community which helps the developer out in finding unexpected behaviour.
For emulators that are cycle accurate such as Same Boy for the GB/GBC, Mesen for the NES and BSNES for the SNES, there is no perceivable difference if we compare these software emulators against their respective FPGA cores and real hardware, except maybe input latency. On the other hand there are experimental FPGA cores which are not 100% accurate to the real hardware, such as the new N64 FPGA core, due in part to the complexity of the system (long thought to be impossible to recreate on existing FPGAs) and the fact that many of the GPU functions are still largely unknown and undocumented.
@@elimalinsky7069 Can't argue with your first statement. Before I had my MiSTer, I've also played games on emulator. For something like GBA/GBC I don't want to feed my magnifying glass with batteries and just want to sit on my couch with a nice big screen and not hurt my eyes. So I guess that the software emulation might be sufficient most of the time. But there is one thing I admire about the hardware solution. The video signal is comparable to the original system. I can connect my MiSTer via SCART port to my Commodore 1084 and can play like in the old days. It is true that this is even possible with a modern GPU. With a custom modeline I've connected an RTX 2070 with the 1084 as well :-D. But it surely takes effort and sometimes the emulators are not designed for something like that.
@@Slamy4096 so the problem is that there are no good GPUs ? Even on a PC I could poll for hsync and the just in time fill the line into the framebuffer. But why? Controller input is only read once per frame. Poll for vsync. Get input, Render frame. Even sorting 256 sprites by Y only takes a line on a modern ARM.
@@ArneChristianRosenfeldt I assume this is lost in translation as english is not my native language. I wanted to say that the input latency is probably not that big of a deal for most games as I didn't notice issues during GBA emulation. I therefore agreed with elimalinsky7069 on that topic. What I've meant afterwards was the video signal itself. Producing a 15 kHz RGB signal on a modern graphics card takes effort and tedious configuration but is possible. But what I might have ignored here is that "dedicated software emulation solutions" might not even have that problem. But I don't posses a solution like this and don't even know if devices like these exist.
I think this is the most useful video I have found to date about this subject. Incredibly thorough explanations, examples, and resources that I appreciate as someone really interested in the hardware/logic of these systems.
Great video! I need to watch it again. I'm in the all 3 camp; 1- Software Emulation, 2- Hardware Emulation (FPGA), and 3- Real Retro Hardware from back in the day w/ or w/o modern enhancements (like SDC Floppy Emulators / upscalers for HDMI/VGA / etc...). There is NO wrong way to enjoy the hobby, don't let anyone convince you otherwise.
Excellent video! I wanted to better understand how FPGAs worked and this was a fantastic explanation: it provided enough detail to satisfy my curiosity while still being easy to understand and entertaining.
I bought a mister a few months ago and I love the mix of accuracy and improvements in the cores. Software emulation definitely offers more in terms of creature comforts though; especially in 3d consoles. You're not likely to see things like anti aliasing or fixing texture warping in fpga; at least not without significantly more powerful hardware. Still, I’ve been amazed to see that there are quite a few improvements to allow cpu overclocking for better framerate, and speedups to the disc drive in the PSX core. I find that I get an experience that lets me enjoy games that may not have ran well on original hardware, but still feel like I’m getting an authentic experience. It feels like a middle ground between the accuracy and rigidity of original hardware, and the tweaks and customization of software emulation. Ultimately, I’m just happy that we have the tools to preserve not only the games, but the hardware itself. It’s never a bad thing to have choices for how you experience the media.
Was looking for good intros to FPGAs and how it connects to emulation. I ran into this gem of a channel and cannot be happier. Thank you Ken, I subscribed on set for notifications 😊
I just ordered an Analogue Pocket today, mainly to have my Amiga 500 childhood memories in my pocket. And this great video supports my decision. Thanks!
25:30 True for FPGAs, but could something like a field-programmable analog array (FPAA) be used as an alternative for hardware analog emulation if they were commercially available? I might be oversimplifying them as the analog equivalent of FPGAs but there’s not many resources online.
25:09 This is mostly due to a lot of I/O blocks being in use. LUTs and FFs (the internal functional blocks) don't consume terribly much power. I wrote a RISC-V 2-core softcore running at 25MHz that consumed about 0.2W total on a Spartan-7 including video circuitry and SoC. Also, design tools can optimize for power use if you need it.
This is the first video about analogue pocket that clearly explains why fpga matters. All other videos says things like input lag or clock accuracy but doesn’t explain what this things change. Thank you for making me understand why I should care about theese
This is what I came for. Thank you for your time and effort and knowledge. Its like you are explaining the science of my childhood! Very professional content!
Just finished the video. Very well explained. I have both software and hardware emulators and your explanation really highlights the nuances between emulation approaches!
I've recently been delving back into retro gaming with an Analogue Pocket, and this video was such a great way to get a much clearer understanding of how the tech works under the hood! Awesome video and so appreciative for all of the research and effort you've put into this.
All that work on FPGAs and we still have bugs and accuracy problems that are already solved in (good) software emulation. I'm sure it will get there one day, but for now I see it as an overhyped money pit.
This was so informative! I came to learn about retro consoles but a lot of what you talked about helped me understand my actual job, haha. A lot of us got interested in technology due to these old achool consoles and its crazy to think that we can still learn from them today!
There's a common misconception here about how FPGA's work. They are essentially a bunch of lookup tables (LUT's), and when you program them You are defining the inputs and outputs of those LUT's. The LUT inputs/outputs can be *thought of* as giving the same behavior as a set of interconnected logic gates. FPGA's also typically have hardware defined specialized computing blocks that can talk to the lookup table stuff. There is routing, but it's not routing between elementary logic gates as shown in the video. It's routing between LUT's and other blocks.
One of the best contents on UA-cam and personally you have gave me more than enough reason now to consider using my expensive Analogue Pocket which I regreted buying it after the net cost. It is still in sealed box until now. I really would consider using it now after this presentation. Thank You.
wow, somehow UA-cam recommended me this video. It was amazing and very informative. I already subscribed to your channel and looking for good contents like this in the future. Good job Ken!
I don't have anything to say - I'm just here to like, comment and subscribe so that the UA-cam algorithm rewards insightful and level-headed content like this instead of sensationalist junk.
18:06 however a lot of new consoles will be relatively more simple to emulate because they mostly run on platforms that are well understood (industry standard) and based on either ARM or x86/x64. E.G. Xbox, Nintendo Switch.. I think sony also finally adopted pc-like components with the PS4. Also, i think less and less games are optimized to take advantage of bare-metal hardware features that an emulator might miss. I dont think any recent games are developed in assembly language, they will usually be made in high level languages and mostly based on well known game engines. BTW crazy that u only have 4,7k subs. subbed you, this is a really high quality channel.
Yeah, he skipped over hardware translation layers which is a great third option to actually take advantage of your own hardware processors. It's how arm devices can run x86 and amd64 software and is also what wine, dxvk, proton, and a lot of modern "emulators" use despite the fact that it's not really a form of emulation.
My first exposure to FPGAs was through the music tech world, in category-busting synthesizers that sit between analog and digital. Eventually got my hands on one of them and I love it, amazing technology. So cool to see the tech applied to videogames as well. I hope we see raspberry pi-like FPGA-based devices sooner than later for DIY experimentation, could be incredibly useful for homebrewing audio devices.
I'm doing some work with digital synthesizers, and also look up Black Mesa's board or the Lattice board that's based on Black Mesa's. My end goal is a complex synthesizer to build into a keytar (with built-in speakers). I can design an FM chip easily, but I want to do one based on the Yamaha DX-7 and I don't have full information about how it works (and reverse engineering Dexed from the source code is hard). The chip would be able to load DX-7 sysex, but it would have a different manner of configuration that supersets what a DX-7 can do (hence why I want to design a DX-7 chip first, or at least a hardware version of Dexed). My current project is a very enhanced AY-3-8930.
Man, I remember running ZSNES my old Pentium 166. The lack of usable transparency layers made playing games like Chrono Trigger fricking annoying. Retroarch is such a good platform for modern emulation. It handles all the games that my MAME can't get to.
i came back three days later to check in which rabbit hole i dropped. the rgb30 is ordered, i watched hours of console content. i mean i played a lot like snes, n64, ps1, ps2. but there is so much more out there!!! what amazing arcade games there are, not to mention the laser disc stuff. thanks for that journey :)
one of the best videos about emulators/FPGA I can also say as a newly proud owner of a MISTer FPGA i can say the system it is the closest thing for casual retro fans like me. Some people say the differences about the lags in software emulators are not very big. For me they were too big since i grew up with nes snes and co. so i know perfectly how the should behave. When you know what you want then MISTer FPGA is definetly worth the money.
I'm interested in FPGA (since I first heard of the ZX Next some years ago), but I admit I don't fully understand the difference. After watching your video I have a bit of a better understanding. But it got me wondering... are there an FPGA emulators we can use lol? to start writing FPGA maps/configs or whatever they are called without any physical hardware (other than our desktop PC for example)
There's really no reason for people to get tribalistic about this stuff. We all recognise the importance of computer game preservation and both software and hardware emulation have their place in this endeavour. Great vid. Learned some stuff 👍🏽
As an electrical engineer finishing my masters degree in embedded systems, I knew about 95% covered in this video already. Nonetheless it was very intersting to watch and the topics covered were explained in an easy manner without dumbing down the contents. I found it very enjoyable :)
I'm studying my first year of electrical engineering and this is the first time I fully understood what an FPGA actually is, even though I have used it countless times for digital electronics classes. Thanks!
first year and u say countless times? aint that too hard now, here the standard is so low, first year guys dont even know wtf an ic is the first time they see one some people go to their third year without ever seeing or touching fpga and fpga is only mentioned in digital classes separate subject for fpga
@@urnoob5528 This semester (my first semester of university) and also next year, we have a subject dedicated to digital electronics where we see theory about logic circuits, but also how to use an FPGA and how to write code in HDL. Our final project this semester was code the game Pong with an FPGA by using the VGA protocol. It's really interesting, but as I mentioned in my comment, we don't really get taught what exactly an FPGA is, so this video helped paint a clear picture.
That's a great introduction on how older consoles and FPGAs work! I've been really curious about it for a while and this video really helps! A lot of stuff still goes over my head, but that mostly on me not having an electronics/programming background heh As for the debate, I really enjoy emulating and playing on my Mini+, I couldn't enjoy the original consoles in my childhood, only a Famiclone which didn't last me long. Emulating is popular because having an original console and their cartridges is expensive and maybe even impossible in certain countries. FPGAs will always have a higher cost than emulation, simply because I can emulate with my phone, or computer, the few advantages that it has are outweigh by the investment and effort needed (buying, configuration, etc). If the price goes down, I can see it being used more widely, and I would certainly buy an FPGA console if it was more competitive with emulation consoles. Anyway, great video! :D
"Thirty years ago, when I was sitting in front of my living room TV-"
Playing the NES, yeah, I remember that.
"- playing Super Nintendo-"
*YOU SHUT YOUR DIRTY MOUTH! I'M NOT OLD, YOU'RE OLD!*
Hahaha ... truth!
Atari?... nobody else?
little fun fact, the playstations 30th anniversary is in a few days. December 3rd 1994. (if your only counting north american release, then its turning 30 next year in september)
One thing that was not mentioned is reduced input lag that fpga can provide. This is due the parallel cycle accurate nature of the fpga emulation as it can run in sync with the display output as the original hardware did. Basically all the software emulators have render to a "backbuffer" which is displayed at least a frame later.
yeah... input lag is my main reason to buy FPGA system. other than that.. I actually prefer software based emulators because it has so many added functions- cheats, fast forward, etc.
@@edmundroth6337 Yeahhhhh... GPU sync and Runahead kinda invalidate the input lag argument. FPGA strikes me as being more helpful for systems that are actually really hard to emulate, as a cheaper alternative. Or for playing physical carts, I guess.
Problem is that emulators gets better over time and hardware gets better and cheaper, so at a certain point, I question what niche it will even fill, if those hard to emulate systems become easier and cheaper to emulate over time. Maybe as a replacement for older hardware hooked up to CRT tvs? I'd take an FPGA PS2.
Wait till you try retroarch + run ahead. You can have better than native hardware latency.
@@overdriver99
Yes, it cheaper too!
Literally doesn't matter with run ahead. Mister blows
Those first 8 minutes or so are an amazingly done explanation of how computer hardware and software works in general.
Yeah, and the video editing is top-tier.
It's called a advert. These UA-camrs get paid to promote FPGA . It's all a scam .
My brain misheard the full name of FPGAs as "Field Programmable Gatorade" and I can't stop giggling
I'm drowning in tears (of laughter)
now i can stop giggling after reading your comment
You’re “giggling”?
that already happens on the football Field. Win game, pour gatorade on coach.
"I for one am ready for a nanotech beverage built to adjust to my hydration needs on the fly. No, I'm not a cyberpunk fan, why do you ask?"
Hands down, the best concise explanation of what an FPGA is. Subbed.
i am a computer engineer, I cant imagine how much work he put in this. R&D, explanation, videography, sounds, animation, testing, compiling .... wow
@@jstro-hobbytech mucho texto
@@jstro-hobbytech it's like this dude is stretching his vid by all possible means, except for "flashbacks from his past when he was a kid"😆
@@XQZ9789 like my overly wordy comment. Sorry man.
@@jstro-hobbytech believe me, i found it more appealing to read whole your comment, rather than watching this vid 😄
@@jstro-hobbytech what the actual fuck are you talking about?
Software emulators can be as accurate as FPGAs, and FPGAs can be as bad as glitchy software emulators. The Air Strike quirk in software emulation has been fixed years ago, and not through tricks but actual cycle accurate software emulation. Same with Speedy Gonzales. It was one of BSNES's highlights to prove that it was more accurate than the other software emulators of its time, and that was like 14 years ago! If you still see that bug in handheld software emulation devices it can be for several reasons: the company selling these devices don't ship them with up to date emulators, you as a user or the company selling these products aren't using the right emulators, or the device is not powerful enough to run accurate emulators and has to resort to speed hacks that sacrifice accuracy for performance. 22:48 just like a well programmed software emulator. Why so many FPGA/Software emulation comparison videos focus on bad software emulators or emulators meant for cheap and under powered devices?
This channel is such a hidden gem. Outstanding video, content, editing, it has it all. Great video, as always. Thanks, Ken.
As I said in a separate comment:
"God, I love the CPU section of the video. Thanks for actually explaining this shit to me whereas nobody has been able to do so till now."
You are making super comprehensive videos on super hard subject, thank you , and I’m a video game designer ;) was waiting years to get this level of clarity in an explanation. Ken you are a master of your craft, keep posting content !!!!❤❤
Thank you for the Super, kind comments, and encouragement - very generous! Very cool that you’re a game designer! Can you share any titles you’ve worked on?
I'm an FPGA engineer with some comments:
Short explanation about "simulating clock cycle accurate requirements": Say I need accuracy because my FPGA is going to run a car's dashboard software and hardware interface. I'm expecting to simulate 1 second per DAY on a beefed up server farm for a simulated 1080p display. But this is important because I need to check the equivalent of Speedy Gonzalez button #523 in level 17, but for a car. Don't want your ABS to not work because it's January 19, 2038.
HDLs are also completely compatible with creating an ASIC. That is, I can send over a netlist (intermediate design file) to the blokes over in Taiwan and after a few 1000s of dollars, I can create a big box of NES/PS1/N64 on chips the size of a particularly large postage stamp. Per unit cost is far, far cheaper. You often use FPGAs to prototype this kind of thing before sending it off to be fabricated.
About power draw, we have a big honking huge window in the FPGA simulator that talks all about how the FPGA design you're making is gonna suck up the wattage of a hairdryer. And where do you think all of that energy goes? You'll be on the verge of deaf in FPGA labs from the cooling fans, let me tell ya.
Finally, a lot of games work on BUGS of the console, rather than the intended functionality. You see 25:55, right? I can assure you that the dev of your childhood favorite game got a cool animation to work because they used undocumented opcodes that did weird things. Or maybe overloading the PSX vbuffer causes a rather cool transparency effect that's hard to emulate. What if you somehow got 2-3 FPS extra in a game by glitching out the GPU with some wild string of bits? I actually find a few bugs in FPGAs where signals are ten NANOSECONDS late and that causes a bug. That's how picky these effects can be.
Thank you for this video! I recently started using an Analogue Pocket because I didn't understand the hype for fpga when compared to cheaper emulation handhelds. But now I have a slightly better understanding and appreciation for fpga.
I heard the word fpga a lot and I just assumed it was a framework to physically hand create chips. I had no idea that you actually can flash them to different setups and emulate multiple systems off the same chip. That's super cool and super informative, thank you for this video!
Ignorance + Assumption = a great example of why it is possible to dig up decades old tech, add some catchy marketing, and pretend it is new. Electric cars are a great example of this, where people think it is new tech when in reality electric cars were available in the 1800s and failed for the same reasons then that they are failing now.
@@alphaforce6998 Electric motors are marginally better today than in the XXth century (because they were pretty much perfect devices already, far better in terms of efficiency than any combustion engine is and will ever be), but batteries are miles better today than even a few decades ago. Saying the tech is the same than in the XIXth or XXth century is false or at least not entirely true.
@@benjib2691 The battery tech may have improved, but it's still far from being even practical as compared to fuel...plus, there is no benefit to making heavy vehicles electric when there is an abundance of fuel. The entire eco-doom used to justify the inferior tech is based entirely on lies.
@@alphaforce6998 They are...failing? I thought they are doing decently for themselves currently.
@@lpfan4491Apart from Teslas, sales of electric cars have been poor with most of the big automakers having lost money trying to convert their production lines to selling them. This is true even with all of the subsidies & corporate welfare that the government doles out for electric cars. The American public never wanted electric cars, they wanted Teslas. Heck these days even Tesla has seen some of their sales figures falling short of projections.
Rest in Peace to Bsnes’s developer, he took his own life years back and it was very sad.
I remember reading that article years ago shown at 13:30 and being so interested in the progress of Bsnes. I try to use it any chance I get on my main gaming PC.
not going to rip someone who took his own life due to not being able to turn off the internet.
Only the online persona is gone, the actual man is still alive an healthy.
Japan like most countries publishes all foreigners' deaths and there were none from that year.
Absolutely delusional replies here. Near deserved way better. May they rest in peace.
The way the video was presented reminded me of one of those “How it’s made type shows.” I didn’t even know I was interested enough to know what’s going on behind the scenes of all these games and systems I play to watch this type of deep dive video, but this was really informative and genuinely fun to watch. Awesome job man!
I'd actually argue that software emulation is getting comparatively easier with more modern systems (meaning the required overhead for accurate-enough emulation is lower relative to the emulated system power) because consoles have become more like general purpose computers in that they employ increasing layers of abstraction between hardware and the application software. This allows for HLE (High-Level Emulation) which tends to be much easier on overhead while still being very accurate (to the point of the SDK APIs available to the developers).
This is basically a symptom of the fact that such systems have inherent overhead (for hypervisors, OS, drivers and libraries; a.k.a. system firmware) even in their original form, and by employing HLE a lot of that overhead can be eliminated in an emulator, leaving more headroom for the (proportionally smaller) application code that must always run through emulation. These abstractions also tend to have a stricter API surface than old bare-metal hardware, making it harder for games to exploit edge-cases (They might break in the next system firmware update for example) which is the reason cycle-accuracy can be important for old systems. You could say the more defined API surface makes more "shortcuts" safe so long as they conform to the API contract.
Then again, modern complex graphics APIs are still a big old mess, even on PC and especially on mobile-oriented graphics cores.
I'd argue translation layers aren't really emulation. You could argue programs like Box86 are as they need to translate to a different architecture, but programs like wine, proton, and dxvk are only really changing OS syscalls and apis. They aren't emulating any hardware.
This was a fantastic explanation of the differences between hardware and software emulation! You're consistently putting out great content.
The lockup in Speedy Gonzales only happens with very low accuracy SNES emulators like ZSNES, while the rotating text and shadow of the plane in Air Strike Patrol is the only game in the entire SNES library that requires the BSNES accuracy core to display properly. ZSNES in particular is a very problematic emulator and I would not recommend anyone to use it, unless you're still rocking one of those 90s Pentium processors. It can even run on a 486 if you're brave enough.
Zsnes is the best because it has comfy snow in the menu
I love all the options. I have emulation running on my Steam Deck and use FPGA on my Analogue Pocket and Mister FPGA. I'm not sure I'm the type of person who would notice the differences too much between them.
I did a frame by frame count of Saturn emulation on my computer running it in Saturnus. It was on par with actual hardware for input latency and at most maybe a frame behind on rare occasion but that might be user error when I was counting. With run ahead it is a frame quicker. Run ahead for a frame on my 1 year old system running a Saturn game brings it to its knees and can I tell the difference. Honestly nope. Well I can tell if I got almost anything else open because my whole computer starts getting a bit choppy.
For me it's fine as long as it's running the games at adequate performance and don't cause any graphical corruption or sound issues.
For example: I wouldn't care about the shadows in Air Strike Patrol, but I would notice the doubled "Good Luck" text.
As long as software emulation is "accurate enough" it's fine by me. But I'm also the kind of person who runs software emulation for MIDI audio and switches soundfonts on a regular basis.
It's the edge-cases that get you on emus. Most games will Just Work but there are always a few that used undocumented or co-incidental behaviors of the system that really show where fpga can shine.
@@nobodynoone2500 In efficiency it will always go to a hardware solution. In flexibility and additional features software usually has an easier time implementing them. Both solutions can do mostly the same things the other can to differing degrees. But not being documented hurts both options equally. If not implemented it will not appear by magic.
I am glad I stumbled upon this video. It is an enlightenment to me as a casual gamer who has been confused about all these technical terms for a long time. I appreciate the pace you talked so I can really catch up, digest and understand the explanations. And the effort not to polarize opinions is commendable. Please keep up the good work and grow the content, and I am sure this channel will be a great success.
FPGAs allow more direct implementation of the original circuit, if it's known. This is a lot less error-prone and more reliable than coding it in software. In a lot of cases it's the only one possible performance-wise if you want 100% fidelity to the original because you have to take shortcuts in a software implementation. Both can still suffer from inaccuracy because they both require 100% accurate and complete reverse-engineering of the original system. This video is a good overview of emulation and the two main approaches.
ai generated ahh comment
@@desmondcayce I wrote that myself. Is that a compliment? I spent many years reverse-engineering consoles and writing emulators so I have a little bit of experience to draw on. I agree and despise people using AI to generate web pages, product reviews, social media posts, without labeling it as such.
@@desmondcayce blue dot effect lol
u so used to seeing ai that u think everything is ai
this comment was so obviously not ai
my 4 year undergraduate in electronics and computers got its money worth while watching this video. thank you so much for such a comprehensive look on these systems.
You managed to make 27 minutes of technical information sound accessible and even conversational. I'll be coming back just to dig a little deeper into the topics covered here.
THANK YOU!
I don't know if I've seen a video so thoroughly explain how software and hardware emulations works. And while I definitely need to rewatch this as well as look into more information on the topic, I really enjoyed this and it makes me want to understand how it all works more.
Really nice video explaining emulation and the software/fpga trade off. I wrote a software NES emulator a while back and it was a great project that helped me better appreciate the beauty and cleverness of these old systems, which went to great lengths to push amazing performance out of very limited hardware.
Had to pause the video at 6:00 to subscribe and tell you this video is amazing. Looking forward to exploring the rest of your channel!
What a great explanation. I've had some of this explained to me in the past, but it was joy to hear it all over again delivered in this style. And I learned more about what FPGAs do too!
One of the best videos I’ve ever watched on the internet. Thank you.
Great explanation and video. This whole thing reminds me of the audiophile stuff to some degree. Where if you have to point out very specific (or obscure) cases that are noticeably different, then it probably doesn't matter to 99.9999999% of the people. Even though I was really interested in the FPGA stuff when it was first becoming popular, I am now leaning back into software emulation. Because not only can I not tell the difference unless I am really looking, but I also get a much better QoL with software emulation. More devices emulated (espicailly when you are talking about arcade hardware and newer consoles), Run-ahead, RetroAchievements, online play, much better looking interfaces, bezel project, real-time translation (though I havent tried that yet) and just tons more options in general. Not even talking about the costs advantage, it really is hard for me to justify buying FPGA for the improvements I would never notice unless I was running something side by side (and maybe not even then). With that being said, I love all the options and if FPGA can add a lot of those same features that the software emulated solutions offer in the future, it would be amazing.
That's the argument I tend to use to defend software emulation. Most consoles up to the PS1 are in very good hands nowadays, it's really rare that a game would have game breaking issues. I think the reason why those two games he tested show such blatant errors is because the default emulator used in the miyoo mini is very outdated and optimised for weak arm chips,(Supafaust) but there's an option to use Snes9x too, which would probably solve those issues.
@@davidoli I use one of those Anerbernic devices and I am not sure how they compare hardware wise (aside from both being ARM) But it is similiar in that it easily does the older stuff np, but even though it is not perfect, Dreamcast and Saturn stuff works pretty good with solid framerates (I think I have a single frameskip option on one to fix audio breakup). I was honestly shocked because I never thought a device like it would be able to have those systems perform as well as they do. So while not perfect, at least portable software emulated devices can have those games playable. Who knows when/if we will ever see a portable FPGA device that can play something like Dreamcast.
Also, I have all the above features I mention on my portable software emulated device as well. So using something like the Analogue Pocket would feel like a step backward in comparison (Aside from build quality)
The real big difference is that we're not just able, but we ARE having this discussion, rather than blindly go "so, erm, FPGA is like, better, so it's not emulation...?"
In my experience gamers are jsut on a different level. The lower level. They take film industry terms like "genre" and "remaster" and absolutely mangle them into this consumerist mold, like "remaster is when it LOOKS BETTER". When in fact, a "remaster" WOULD BE something like emulation. The optimal "video game remaster" that people want out of remaster over a remake, would be the same as George Lucas "remastering" out the "dated" practical effects. But everyone just AGREES that mangling the original game with this contemporary plastic sheen of "modern standards" is GREAT. Like those AWFUL 30% resin "wood" dining tables that cost thousands of bucks. Or remastering LotR to look like HD Hobbit and every telenovela after 2007.
Original TVs were a low tier consumer-grade device. There is no such thing as chasing the "authentic" experience the same way as films though, because TV release ALREADY was a heavily truncated and variable expereince, even on video games. You did NOT have some optimal conditions to "expereince the art" you're now trying to preserve, because it would be like Mona Lisa in a dimly lit room. "Most people who wouldn't care" are nostalgic for their POST CARDS of Mona Lisa from childhood. And that's always the exerience with art. Fantasy abut escapism completely ruins the interplay where YOU create the experience monstly for yourself, sme great PIECE of art is no more than a hint of th author's vision carrying on to you as a recipient. But it gets pretty bad when the DISCUSSION is "we should remaster Mona Lisa into a portable HD post card" the way it is with video game consumerism.
There will be no return to Woodstock. That's not how genuine art WORKS, and Mozart didn't RECORD any of is pieces. They're recreations like art always would be. PIECES of art are always contemporary but what is ART as a whole is their addition to the historical canon. Somthin people CAN'T consume when they're so worried about spoilers. Then it stops beign a discussion with the artist and becomes a lecture, a little commecial escape room where the "art" is providing some puzzle of a metaphor you're too coy to address directly, like reading Animal Farm as a children's book. What art is that?
@@sboinkthelegday3892 Very well said. In general I can enjoy many aspects of how something is presented, but I tend to lean toward "authentic" when possible. So I have my real hardware and CRT to scratch that itch (as close as I reasonably can, it will never be exactly how it was when I was younger). But the newer way the content is presented and consumed, (pixel perfect/modern screens/emulated), I try and appriciate it as its own thing instead of a replacement.
Software Emulation and Hardware Emulation can be just as accurate as the other. It only depends on the time and dedication spent by the programers. Software emulation is more flexible and feature rich, but accuracy require more computing power so that's why emulation on cheap devices can be glitchy or laggy as they're using shortcuts/speed hacks in order to compensate the weakness of the host hardware. FPGAs are more efficient and usually don't necessitate as much tinkering from the user to get great results out of the box.
Well done video! I used vhdl in college and programmed in assembly on x86 and on 6502 and appreciate very much your fine explanation. The examples you chose of timing challenged games was perfect. I still wonder if those who don't understandeither would have have sat through your explanation 😮
I wrote a nintendo gameboy emulator in typescript from the ground up this year and really enjoyed the whole process. I can truely say I know what makes the thing 'tick' now
That's awesome - I love typescript!
This video’s thumbnail sells it way short! This was great detail I’ve not seen any other pocket video do. I learned a lot, thanks!
This video describing teh difference between software and FPGA is really a gem,i always wondered what teh difference was between those 2 , but a lot of videos i watched are to complex or tell it weird, yours i almost immediately understand. so a very high thx
One more thing i forgot to tell was, i love those animations of teh working of the insides you show, it makes things a lot easier to follow, also i hope to see some more videos about FPGA stuff, it really peaks my interest as somebody that watched the upcoming from pong to the newest games today, yes i am alreday 54 but i hope to see even more chanegs
That's so cool. I've been a software developer since the 70s, but I've never even so much as dipped my toes in to FPGAs. I might need a toy project to screw around with.
Excellent video, you covered pretty much all the major advantages and disadvantages of both approaches really well. The only things I would add is that in the software camp latency can often be an issue, due to overhead from the operating system for both receiving input and outputting to a display, especially where a modern dedicated GPU is involved. And in the FPGA camp one of the major downsides can be lack of enhancements or features - software emulation naturally lends itself to ie. high definition asset packs or widescreen hacks, whereas if they aren't designed with them in mind in the first place FPGA emulators will often be missing even fundamental features like save states, or even the ability to pause at all.
Solid points!
This channel deserves way more attention
Thank you Ken. This was my first video from your channel, but it was a rollercoaster of context. Yummy, delicious context.
RetroArch on Linux is actually perfectly capable of matching FPGAs in input latency. By using the Linux kernel's realtime task deadline features, and starting RetroArch without a display server or desktop environment running, it guarantees system responsiveness, and takes complete, exclusive control over the graphics hardware and input devices. Then it can apply low-level optimizations, hard-synchronize the GPU, and have direct, granular control over the main framebuffer swapchains. After that, the only latency left is whatever's inherent to your display and controller. RA is also capable of delaying the emulator loop, to effectively finish processing and drawing a frame as late as possible into the refresh cycle, just before the GPU will need it for the screen and effectively racing the GPU to the framebuffer swaps.
That's basically what a properly configured Lakka is. Of course, many old games have built-in input lag that shows up even in FPGAs and original hardware. And this is before even bringing Run-Ahead into the picture.
can you actually show how to do this? an article or something would help
I remember Higan and Ares doing exclusive GPU and audio sync, the same thing you said here.
@@flintfrommother3gaming For starters, exclusive mode only really works with the Mesa graphics stack. So no NVIDIA proprietary driver. Preferably use an Intel or AMD GPU.
Second, rather than manually setting all of this up on a standard, general-purpose Linux system, just install Lakka. It's a minimal, dedicated Linux distro with most of these things already setup for you. Then you enable hard sync on the Retroarch settings menu. The main ingredient making this work is running Retroarch in direct DRM/KMS mode, aka just running it on the commandline tty without any X or Wayland services running.
If you have a display with Freesync, even better, since RetroArch will be able to synchronize the refresh rate to the old NTSC/PAL spec instead of the standard HDMI modes.
Nice video! A critical misconception about FPGA emulators that many people have is the assumption that they're intrinsically more accurate than software emulators when that is not necessarily the case.
In the Gameboy example, let's take opcode 0xCB8F, which resets bit 1 in register A to 0. I can write some code that will essentially look like reg_A &= ~(1
Fortunately the resulting netlist can be simulated as well and compared against the original HDL. And when a bug is found, the bitstream can be replaced. I would therefore say that the possibility for accurary is better provided than with most software solutions. I do however understand what you say. The MiSTer is not perfect as well. Some cores have very special problems which are occuring as not much interest is there to maybe fix it or the problem is small or barely noticable. The Amiga mouse emulation is still a problem today...
Still the more developers are participating, the faster could a problem be resolved. The N64 core of the MiSTer currently has a very big community which helps the developer out in finding unexpected behaviour.
For emulators that are cycle accurate such as Same Boy for the GB/GBC, Mesen for the NES and BSNES for the SNES, there is no perceivable difference if we compare these software emulators against their respective FPGA cores and real hardware, except maybe input latency.
On the other hand there are experimental FPGA cores which are not 100% accurate to the real hardware, such as the new N64 FPGA core, due in part to the complexity of the system (long thought to be impossible to recreate on existing FPGAs) and the fact that many of the GPU functions are still largely unknown and undocumented.
@@elimalinsky7069 Can't argue with your first statement. Before I had my MiSTer, I've also played games on emulator. For something like GBA/GBC I don't want to feed my magnifying glass with batteries and just want to sit on my couch with a nice big screen and not hurt my eyes. So I guess that the software emulation might be sufficient most of the time. But there is one thing I admire about the hardware solution. The video signal is comparable to the original system. I can connect my MiSTer via SCART port to my Commodore 1084 and can play like in the old days. It is true that this is even possible with a modern GPU. With a custom modeline I've connected an RTX 2070 with the 1084 as well :-D. But it surely takes effort and sometimes the emulators are not designed for something like that.
@@Slamy4096 so the problem is that there are no good GPUs ? Even on a PC I could poll for hsync and the just in time fill the line into the framebuffer. But why? Controller input is only read once per frame. Poll for vsync. Get input, Render frame. Even sorting 256 sprites by Y only takes a line on a modern ARM.
@@ArneChristianRosenfeldt I assume this is lost in translation as english is not my native language. I wanted to say that the input latency is probably not that big of a deal for most games as I didn't notice issues during GBA emulation. I therefore agreed with elimalinsky7069 on that topic. What I've meant afterwards was the video signal itself. Producing a 15 kHz RGB signal on a modern graphics card takes effort and tedious configuration but is possible. But what I might have ignored here is that "dedicated software emulation solutions" might not even have that problem. But I don't posses a solution like this and don't even know if devices like these exist.
Wow. Great video. Only 3.6k subscribers!? I definitely have stumbled upon a hidden gem. Looking forward to more!!
This channel is way underrated and I had no idea of these things even as a modern software developer.
wow! you even got the actual physical copies to test out what the article says. kudos my brother on giving us quality production.
Wow this is so cool, i have a cs background but never knew about the differences here. I love seeing the way retro computing evolves
I think this is the most useful video I have found to date about this subject. Incredibly thorough explanations, examples, and resources that I appreciate as someone really interested in the hardware/logic of these systems.
Great video! I need to watch it again. I'm in the all 3 camp; 1- Software Emulation, 2- Hardware Emulation (FPGA), and 3- Real Retro Hardware from back in the day w/ or w/o modern enhancements (like SDC Floppy Emulators / upscalers for HDMI/VGA / etc...). There is NO wrong way to enjoy the hobby, don't let anyone convince you otherwise.
Excellent video! I wanted to better understand how FPGAs worked and this was a fantastic explanation: it provided enough detail to satisfy my curiosity while still being easy to understand and entertaining.
I bought a mister a few months ago and I love the mix of accuracy and improvements in the cores. Software emulation definitely offers more in terms of creature comforts though; especially in 3d consoles.
You're not likely to see things like anti aliasing or fixing texture warping in fpga; at least not without significantly more powerful hardware.
Still, I’ve been amazed to see that there are quite a few improvements to allow cpu overclocking for better framerate, and speedups to the disc drive in the PSX core.
I find that I get an experience that lets me enjoy games that may not have ran well on original hardware, but still feel like I’m getting an authentic experience. It feels like a middle ground between the accuracy and rigidity of original hardware, and the tweaks and customization of software emulation.
Ultimately, I’m just happy that we have the tools to preserve not only the games, but the hardware itself. It’s never a bad thing to have choices for how you experience the media.
Was looking for good intros to FPGAs and how it connects to emulation. I ran into this gem of a channel and cannot be happier. Thank you Ken, I subscribed on set for notifications 😊
Almost as many likes on this video as total subscribers! Wow, I don't think I have seen that before. Loved the video, subbed.
I just ordered an Analogue Pocket today, mainly to have my Amiga 500 childhood memories in my pocket. And this great video supports my decision. Thanks!
25:30 True for FPGAs, but could something like a field-programmable analog array (FPAA) be used as an alternative for hardware analog emulation if they were commercially available? I might be oversimplifying them as the analog equivalent of FPGAs but there’s not many resources online.
25:09 This is mostly due to a lot of I/O blocks being in use. LUTs and FFs (the internal functional blocks) don't consume terribly much power. I wrote a RISC-V 2-core softcore running at 25MHz that consumed about 0.2W total on a Spartan-7 including video circuitry and SoC. Also, design tools can optimize for power use if you need it.
This vid is incredibly good and well done. Thank you so much for the 6502 ASM demo, I thought it was captivating and necessary.
This is the first video about analogue pocket that clearly explains why fpga matters. All other videos says things like input lag or clock accuracy but doesn’t explain what this things change. Thank you for making me understand why I should care about theese
Thi Video is incredibly in-depth while remaining super easy to comprehend. Well done!!
This is what I came for. Thank you for your time and effort and knowledge. Its like you are explaining the science of my childhood! Very professional content!
Thanks. This video one very best overview of software emulation vs FPGAs I have watched on YT.
Well done. Thanks. I am sure research and diagramming took longer than most realize.
Just finished the video. Very well explained. I have both software and hardware emulators and your explanation really highlights the nuances between emulation approaches!
i really love your intro, it really quickly tells me about your content!!!
quick, beautifull and very effective!
this was a great explanation of data and address busses alone, ive been looking for info like this. thank you so much
What a great channel!!! You will become a huge youtuber if you stay on this high quality videos. Thank you so much for your work.
I’ve been trying to understand these concepts for a long time. Thank you!
I've recently been delving back into retro gaming with an Analogue Pocket, and this video was such a great way to get a much clearer understanding of how the tech works under the hood! Awesome video and so appreciative for all of the research and effort you've put into this.
All that work on FPGAs and we still have bugs and accuracy problems that are already solved in (good) software emulation. I'm sure it will get there one day, but for now I see it as an overhyped money pit.
This was so informative! I came to learn about retro consoles but a lot of what you talked about helped me understand my actual job, haha. A lot of us got interested in technology due to these old achool consoles and its crazy to think that we can still learn from them today!
There's a common misconception here about how FPGA's work. They are essentially a bunch of lookup tables (LUT's), and when you program them You are defining the inputs and outputs of those LUT's. The LUT inputs/outputs can be *thought of* as giving the same behavior as a set of interconnected logic gates. FPGA's also typically have hardware defined specialized computing blocks that can talk to the lookup table stuff. There is routing, but it's not routing between elementary logic gates as shown in the video. It's routing between LUT's and other blocks.
Incredible video, indeed a hidden gem, you can tell so much work was put into this, thank you.
One of the best contents on UA-cam and personally you have gave me more than enough reason now to consider using my expensive Analogue Pocket which I regreted buying it after the net cost. It is still in sealed box until now. I really would consider using it now after this presentation. Thank You.
wow, somehow UA-cam recommended me this video. It was amazing and very informative. I already subscribed to your channel and looking for good contents like this in the future. Good job Ken!
This may be the best explanation on the subject I have seen :O
What a fantastic video, now my brain won't melt when someone discusses the topic.
The best explanation of this subject I've ever seen on this platform.
Excellent video. I admire that all the graphics were not only insightful but also logically correct.
I don't have anything to say - I'm just here to like, comment and subscribe so that the UA-cam algorithm rewards insightful and level-headed content like this instead of sensationalist junk.
Very nice - thank you so much!
Very technical and at the same time very interesting, thanks a lot for the time you put in this video, it really shows up.
18:06 however a lot of new consoles will be relatively more simple to emulate because they mostly run on platforms that are well understood (industry standard) and based on either ARM or x86/x64. E.G. Xbox, Nintendo Switch.. I think sony also finally adopted pc-like components with the PS4.
Also, i think less and less games are optimized to take advantage of bare-metal hardware features that an emulator might miss. I dont think any recent games are developed in assembly language, they will usually be made in high level languages and mostly based on well known game engines.
BTW crazy that u only have 4,7k subs. subbed you, this is a really high quality channel.
Yeah, he skipped over hardware translation layers which is a great third option to actually take advantage of your own hardware processors. It's how arm devices can run x86 and amd64 software and is also what wine, dxvk, proton, and a lot of modern "emulators" use despite the fact that it's not really a form of emulation.
My first exposure to FPGAs was through the music tech world, in category-busting synthesizers that sit between analog and digital. Eventually got my hands on one of them and I love it, amazing technology. So cool to see the tech applied to videogames as well. I hope we see raspberry pi-like FPGA-based devices sooner than later for DIY experimentation, could be incredibly useful for homebrewing audio devices.
I'm doing some work with digital synthesizers, and also look up Black Mesa's board or the Lattice board that's based on Black Mesa's. My end goal is a complex synthesizer to build into a keytar (with built-in speakers). I can design an FM chip easily, but I want to do one based on the Yamaha DX-7 and I don't have full information about how it works (and reverse engineering Dexed from the source code is hard). The chip would be able to load DX-7 sysex, but it would have a different manner of configuration that supersets what a DX-7 can do (hence why I want to design a DX-7 chip first, or at least a hardware version of Dexed). My current project is a very enhanced AY-3-8930.
This has opened my eyes to the differences in emulators and why people were raving about the Analogue Pocket. This is really fascinating.
Just found this channel and it's gold, really great explanation. You have a new subscriber!
This video is amazing. Well done on the depth of information. Fascinating!
Man, I remember running ZSNES my old Pentium 166. The lack of usable transparency layers made playing games like Chrono Trigger fricking annoying. Retroarch is such a good platform for modern emulation. It handles all the games that my MAME can't get to.
i came back three days later to check in which rabbit hole i dropped. the rgb30 is ordered, i watched hours of console content. i mean i played a lot like snes, n64, ps1, ps2. but there is so much more out there!!! what amazing arcade games there are, not to mention the laser disc stuff. thanks for that journey :)
one of the best videos about emulators/FPGA
I can also say as a newly proud owner of a MISTer FPGA i can say the system it is the closest thing for casual retro fans like me. Some people say the differences about the lags in software emulators are not very big. For me they were too big since i grew up with nes snes and co. so i know perfectly how the should behave. When you know what you want then MISTer FPGA is definetly worth the money.
great transitions and flow ken
Amazing quality video. Great work!
this video needs more view. it's a really good video
I don’t know how I never seen this guy’s channel before but this vid alone got me to Sub‼️
(Just stumbled upon it on my main feed)
This is insanely informative, instant subscription
I'm interested in FPGA (since I first heard of the ZX Next some years ago), but I admit I don't fully understand the difference. After watching your video I have a bit of a better understanding. But it got me wondering... are there an FPGA emulators we can use lol? to start writing FPGA maps/configs or whatever they are called without any physical hardware (other than our desktop PC for example)
This is an amazing video! Very well explained with good editing
After I finished watching I expected to see 1M+ subscribers because the content is outstanding
There's really no reason for people to get tribalistic about this stuff. We all recognise the importance of computer game preservation and both software and hardware emulation have their place in this endeavour.
Great vid. Learned some stuff 👍🏽
Este quizá ha sido el mejor video que he visto en todo el año.
What a gem video, man excellent explanation!. Thanks youtube algorithm for bring me this.
Fantastic. Comprehensive and enlightening. I love the way you made it so easy to understand the inner workings of the devices we all love.
Well this is just fantastic, I was just wondering what the hubbub around FPGA's was and this video does a remarkable job getting me up to speed.
As an electrical engineer finishing my masters degree in embedded systems, I knew about 95% covered in this video already. Nonetheless it was very intersting to watch and the topics covered were explained in an easy manner without dumbing down the contents.
I found it very enjoyable :)
I'm studying my first year of electrical engineering and this is the first time I fully understood what an FPGA actually is, even though I have used it countless times for digital electronics classes. Thanks!
first year and u say countless times? aint that too hard now, here the standard is so low, first year guys dont even know wtf an ic is the first time they see one
some people go to their third year without ever seeing or touching fpga
and fpga is only mentioned in digital classes
separate subject for fpga
@@urnoob5528 This semester (my first semester of university) and also next year, we have a subject dedicated to digital electronics where we see theory about logic circuits, but also how to use an FPGA and how to write code in HDL.
Our final project this semester was code the game Pong with an FPGA by using the VGA protocol.
It's really interesting, but as I mentioned in my comment, we don't really get taught what exactly an FPGA is, so this video helped paint a clear picture.
So this was incredibly informative. I'm a developer, and have been curious about FPGA development. Now I know enough to go about toying around.
That's a great introduction on how older consoles and FPGAs work! I've been really curious about it for a while and this video really helps!
A lot of stuff still goes over my head, but that mostly on me not having an electronics/programming background heh
As for the debate, I really enjoy emulating and playing on my Mini+, I couldn't enjoy the original consoles in my childhood, only a Famiclone which didn't last me long.
Emulating is popular because having an original console and their cartridges is expensive and maybe even impossible in certain countries.
FPGAs will always have a higher cost than emulation, simply because I can emulate with my phone, or computer, the few advantages that it has are outweigh by the investment and effort needed (buying, configuration, etc).
If the price goes down, I can see it being used more widely, and I would certainly buy an FPGA console if it was more competitive with emulation consoles.
Anyway, great video! :D