"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.
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 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.
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.
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!
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.
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 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.
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.
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!
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.
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!
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 😮
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.
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 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
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.
@@CoffeeDrinkerKim”deserved”? They “deserved” to have the world play their pretend pronoun game and for trolls online to not exist? They offed themselves for a ridiculous reason
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.
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 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
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.
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!
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.
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.
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?
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.
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.
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.
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 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.
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!
Good video! Another thing to remember is that many more people use software emulators and therefore more bug reports are sent to the developers, who can fix them. Even if theoretically an FPGA should have higher compatibility, the best software emulator is always better than the best fpga for the respective system because of that. That's my experience at least.
One of the best contents on RUclips 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.
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.
Just finished the video. Very well explained. I have both software and hardware emulators and your explanation really highlights the nuances between emulation approaches!
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!
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.
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.
Abrupt explaination going off rails @20:16 FPGA's are configured using a *bitfile*. The bitfile is compiled by a compiler running on a regular computer processing instructions in files written in a HDL. The bitfile is the equivalent of the binary code for a microcontroller, it's what gets stored in the ROM. FPGA's have a little bit of fixed-function 'machinery' which is just enough so that on power up (or on command), they can load their own bitfile into themselves, then reset that hardware and let it run. The bitfile is just loaded across the whole FPGA into registers used to setup the FPGA fabric to 'BE' the digital hardware as described using the HDL. This includes setting up and connecting clocks, inputs, outputs, and even setting the initial contents on on-chip RAM's and ROM's. This all happens usally within a barely perceptible moment after physical reset or power up. From that point onwards, the configured FPGA *IS* the hardware as designed in the HDL. The configuration bits as set in the bitfile simply stay as they are. Unallocated parts of the FPGA simply lay idle. They might be used by another compiled version of the same HDL, as the compilation process has a fairly high degree of randomness to it. This means that the performance possible with a particular design may vary from compilation to compilation, and also depending on how good the compiler is. Good FPGA tools will actually run a timing analysis after compilation, and will tell you what actual max clock rate the specific bitfile will work at, and whether this is higher than the currently chosen clock rate. Better tools will take the chosen clock rate into account, and change the layout of allocated resourced on the FPGA to better meet the requirement; Worse tools will just 'fail'. Being able to take timing into account is called 'timing driven layout', where as the inferior tools simply try to get the design to 'fit' at all. Eg, nextpnr vs arachne-pnr. But generally, given a certain silicon chip process node, FPGA implementing logic is approx 30x worse in performance AND area than the same logic implemented on the same process node with the chip as a fixed-at-manufacture ASIC. Typical system clock rates in FPGA's are 30 - 90 MHz max on small/cheap FPGA's, and may go up nearly an order of magnitude on higher performance FPGA's. The reason FPGA's can emulate old hardware, is because they can already outperform said old hardware. The whole point of an FPGA is that it is configured only at the moment of power up at run time, so it is relatively trivial to change the 'firmware' (AKA, the bitfile) which allows for massive flexibilty, therefore design-level robustness compared to ASICS: Make one mistake with design on an ASIC, and you're throwing away millions of dollars on a run to produce junk. This makes FPGA's of massive value to those producing large and expensive ASIC's (like modern CPU's and especially GPU's are). They give you the opportunity to 'try out' your CPU/GPU logic design before committing to an ASIC production run, albeit at the lower clock rates. So there exist very large / powerful FPGA's, usually used only by the likes of CPU and GPU manufacturers. These can cost as much as a car. There are also much smaller, cheaper FPGA's (down to about $10 or less, now) which are still big enough to fit vintage hardware, and indeed even enough of a 'soft' core SoC to run Linux. These are massively useful PC hardware because they usually feature I/O features that allow them to be used as 'universal logic glue' to connect different digital chips and interfaces together - for instance, a bunch of 2.5V parallel ADC chips to a PC's PCIe bus, with also a built-on RAM interface for buffering smooth data collection at multi-gigabit data rates. (This is how scientists often use them, eg: The square kilometer array has *many* copies of this). They're also getting cheap enough that most automotive manufacturers have begun replacing microcontrollers with FPGA's, for much the same reason FPGAs are better at emulation than even fast new microcontrollers are: They are smoother, and are able to work more reliably in a real-time control mode than a microcontroller can be, and with far less programming and formal program verification cost. HDL code itself can be emulated, broken down into separate blocks, and the blocks can be simple enough to be *exhaustively* tested to ensure they work exactly as expected, with no possible ways to crash. Thus, the blocks can be trusted, and then assembled into a system which can be tested (or deployed!) in an FPGA. For car manufacturers, this means if a mistake is found after production, the problem can be fixed and firmware updated by technicians at the dealership. It also means that a FPGA centric controller (eg, brake controller) can be more quickly engineered to extreme reliability standards than could a microcontroller-centric design. All this means that as small cheap FPGA's get cheaper, bigger and faster, the need for microcontrollers recedes back into the final two specific niches they will likely always dominate: Being cheap, and being low power. Microcontrollers always were designed to be cheap, first and foremost, right from the beginning. And a side effect of that makes them tend to low power. But newer ultra-low power microcontrollers also exist, with ironically some similarity to FPGA's. (eg, GreenArrays' chips, which use special 'self clocked' logic to dispense with system clocks entirely). Amusingly, there is a new kind of chip which is a Field Programmable Analog Array, which aim to complement low-power microcontrollers with lower-power analog data processing. Which also dispenses with clocks as well. So, if low cost is the need - you should use only the lowest of cost microcontrollers - about 4cents per chip IIRC. But check out LCSC.com. Low power? FPAA's or green arrays. High performance? ASIC's. Everything else? FPGA's - but sticking to those with open-source toolchain support is a must for sure long-term support. Emulating vintage hardware to perfection nowadays fits in 'everything else'. And the FPGA's affordably include enough extra space to emulate CRT's with high-def displays, even in a handheld form factor now too. Still with perfect cycle-accurate timing.
I don't have anything to say - I'm just here to like, comment and subscribe so that the RUclips 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.
wow, somehow RUclips 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 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 :)
Now i get why some retro console handhelds cost sometimes thrice as much as some others. Very nice video !! i encounter it by a chance but i'm happy with my finding.
"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)
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 RUclipsrs get paid to promote FPGA . It's all a scam .
Hands down, the best concise explanation of what an FPGA is. Subbed.
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
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 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.
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?"
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 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?
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!
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.
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 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.
This was a fantastic explanation of the differences between hardware and software emulation! You're consistently putting out great content.
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.
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!
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!
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.
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!
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 😮
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
One of the best videos I’ve ever watched on the internet. Thank you.
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 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
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.
@@CoffeeDrinkerKim”deserved”? They “deserved” to have the world play their pretend pronoun game and for trolls online to not exist? They offed themselves for a ridiculous reason
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.
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 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
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!
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!
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.
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.
Thank you Ken. This was my first video from your channel, but it was a rollercoaster of context. Yummy, delicious context.
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 channel is way underrated and I had no idea of these things even as a modern software developer.
Wow. Great video. Only 3.6k subscribers!? I definitely have stumbled upon a hidden gem. Looking forward to more!!
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?
wow! you even got the actual physical copies to test out what the article says. kudos my brother on giving us quality production.
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.
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 channel deserves way more attention
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.
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 😊
This vid is incredibly good and well done. Thank you so much for the 6502 ASM demo, I thought it was captivating and necessary.
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.
Well done. Thanks. I am sure research and diagramming took longer than most realize.
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!
Almost as many likes on this video as total subscribers! Wow, I don't think I have seen that before. Loved the video, subbed.
Good video! Another thing to remember is that many more people use software emulators and therefore more bug reports are sent to the developers, who can fix them. Even if theoretically an FPGA should have higher compatibility, the best software emulator is always better than the best fpga for the respective system because of that. That's my experience at least.
Thanks. This video one very best overview of software emulation vs FPGAs I have watched on YT.
Thi Video is incredibly in-depth while remaining super easy to comprehend. Well done!!
One of the best contents on RUclips 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.
i really love your intro, it really quickly tells me about your content!!!
quick, beautifull and very effective!
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.
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.
The best explanation of this subject I've ever seen on this platform.
this was a great explanation of data and address busses alone, ive been looking for info like this. thank you so much
I’ve been trying to understand these concepts for a long time. Thank you!
What a fantastic video, now my brain won't melt when someone discusses the topic.
Just finished the video. Very well explained. I have both software and hardware emulators and your explanation really highlights the nuances between emulation approaches!
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!
Excellent video. I admire that all the graphics were not only insightful but also logically correct.
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
Incredible video, indeed a hidden gem, you can tell so much work was put into this, thank you.
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.
This may be the best explanation on the subject I have seen :O
amazing, I'm not a programmer and some things were really obscure to me, now I get almost everything I needed it to understand the difference!
Abrupt explaination going off rails @20:16
FPGA's are configured using a *bitfile*. The bitfile is compiled by a compiler running on a regular computer processing instructions in files written in a HDL.
The bitfile is the equivalent of the binary code for a microcontroller, it's what gets stored in the ROM. FPGA's have a little bit of fixed-function 'machinery' which is just enough so that on power up (or on command), they can load their own bitfile into themselves, then reset that hardware and let it run.
The bitfile is just loaded across the whole FPGA into registers used to setup the FPGA fabric to 'BE' the digital hardware as described using the HDL. This includes setting up and connecting clocks, inputs, outputs, and even setting the initial contents on on-chip RAM's and ROM's.
This all happens usally within a barely perceptible moment after physical reset or power up. From that point onwards, the configured FPGA *IS* the hardware as designed in the HDL. The configuration bits as set in the bitfile simply stay as they are. Unallocated parts of the FPGA simply lay idle.
They might be used by another compiled version of the same HDL, as the compilation process has a fairly high degree of randomness to it. This means that the performance possible with a particular design may vary from compilation to compilation, and also depending on how good the compiler is.
Good FPGA tools will actually run a timing analysis after compilation, and will tell you what actual max clock rate the specific bitfile will work at, and whether this is higher than the currently chosen clock rate. Better tools will take the chosen clock rate into account, and change the layout of allocated resourced on the FPGA to better meet the requirement; Worse tools will just 'fail'. Being able to take timing into account is called 'timing driven layout', where as the inferior tools simply try to get the design to 'fit' at all. Eg, nextpnr vs arachne-pnr.
But generally, given a certain silicon chip process node, FPGA implementing logic is approx 30x worse in performance AND area than the same logic implemented on the same process node with the chip as a fixed-at-manufacture ASIC. Typical system clock rates in FPGA's are 30 - 90 MHz max on small/cheap FPGA's, and may go up nearly an order of magnitude on higher performance FPGA's. The reason FPGA's can emulate old hardware, is because they can already outperform said old hardware.
The whole point of an FPGA is that it is configured only at the moment of power up at run time, so it is relatively trivial to change the 'firmware' (AKA, the bitfile) which allows for massive flexibilty, therefore design-level robustness compared to ASICS: Make one mistake with design on an ASIC, and you're throwing away millions of dollars on a run to produce junk.
This makes FPGA's of massive value to those producing large and expensive ASIC's (like modern CPU's and especially GPU's are). They give you the opportunity to 'try out' your CPU/GPU logic design before committing to an ASIC production run, albeit at the lower clock rates. So there exist very large / powerful FPGA's, usually used only by the likes of CPU and GPU manufacturers. These can cost as much as a car.
There are also much smaller, cheaper FPGA's (down to about $10 or less, now) which are still big enough to fit vintage hardware, and indeed even enough of a 'soft' core SoC to run Linux. These are massively useful PC hardware because they usually feature I/O features that allow them to be used as 'universal logic glue' to connect different digital chips and interfaces together - for instance, a bunch of 2.5V parallel ADC chips to a PC's PCIe bus, with also a built-on RAM interface for buffering smooth data collection at multi-gigabit data rates. (This is how scientists often use them, eg: The square kilometer array has *many* copies of this).
They're also getting cheap enough that most automotive manufacturers have begun replacing microcontrollers with FPGA's, for much the same reason FPGAs are better at emulation than even fast new microcontrollers are: They are smoother, and are able to work more reliably in a real-time control mode than a microcontroller can be, and with far less programming and formal program verification cost.
HDL code itself can be emulated, broken down into separate blocks, and the blocks can be simple enough to be *exhaustively* tested to ensure they work exactly as expected, with no possible ways to crash. Thus, the blocks can be trusted, and then assembled into a system which can be tested (or deployed!) in an FPGA.
For car manufacturers, this means if a mistake is found after production, the problem can be fixed and firmware updated by technicians at the dealership. It also means that a FPGA centric controller (eg, brake controller) can be more quickly engineered to extreme reliability standards than could a microcontroller-centric design.
All this means that as small cheap FPGA's get cheaper, bigger and faster, the need for microcontrollers recedes back into the final two specific niches they will likely always dominate: Being cheap, and being low power.
Microcontrollers always were designed to be cheap, first and foremost, right from the beginning. And a side effect of that makes them tend to low power. But newer ultra-low power microcontrollers also exist, with ironically some similarity to FPGA's. (eg, GreenArrays' chips, which use special 'self clocked' logic to dispense with system clocks entirely).
Amusingly, there is a new kind of chip which is a Field Programmable Analog Array, which aim to complement low-power microcontrollers with lower-power analog data processing. Which also dispenses with clocks as well.
So, if low cost is the need - you should use only the lowest of cost microcontrollers - about 4cents per chip IIRC. But check out LCSC.com.
Low power? FPAA's or green arrays.
High performance? ASIC's.
Everything else? FPGA's - but sticking to those with open-source toolchain support is a must for sure long-term support.
Emulating vintage hardware to perfection nowadays fits in 'everything else'. And the FPGA's affordably include enough extra space to emulate CRT's with high-def displays, even in a handheld form factor now too. Still with perfect cycle-accurate timing.
I don't have anything to say - I'm just here to like, comment and subscribe so that the RUclips algorithm rewards insightful and level-headed content like this instead of sensationalist junk.
Very nice - thank you so much!
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)
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.
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!
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.
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.
This has opened my eyes to the differences in emulators and why people were raving about the Analogue Pocket. This is really fascinating.
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.
Amazing quality video. Great work!
this video needs more view. it's a really good video
wow, somehow RUclips 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!
You explain very easily and simply, I liked it. Thank you!
Este quizá ha sido el mejor video que he visto en todo el año.
This is an amazing video! Very well explained with good editing
This video explained the topic very well! Thank you for making this!
What a gem video, man excellent explanation!. Thanks youtube algorithm for bring me this.
This is insanely informative, instant subscription
Really informative video and the explanation is spot on! You get a sub, kind sir.
Excellent video Ken. I use both software and FPGA emulation and find this topic fascinating.
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 :)
Now i get why some retro console handhelds cost sometimes thrice as much as some others. Very nice video !! i encounter it by a chance but i'm happy with my finding.
Fantastic. Comprehensive and enlightening. I love the way you made it so easy to understand the inner workings of the devices we all love.
Wow I learnt a huge amount in this video - thanks a lot for explaining all this!
After I finished watching I expected to see 1M+ subscribers because the content is outstanding
Wow, gret explanation about how these CPUs work too.. Nicely done!!!
great transitions and flow ken