I heard that FPGAs get the best performance for game emulation since they can be programmed to mimic almost any hardware. Their performance is only 2nd to the actual hardware itself. Has anyone worked with one before? Are there any good tools out there for turning one into an emulator?
are you retarded?
>>12034289No.
>Are there any good tools out there for turning one into an emulator?Bro...Just get a mister
At this point they're no more accurate than a software emulator so there's really no point. In the future there might be actual circuit-level clones of game systems on FPGA but none exist yet. It's basically a platform for running an emulator on a chip at this point.
>I heard that FPGAs get the best performance for game emulation>FPGA>emulationyou retarded OP?
>>12034304They are far more accurate than software emulation. But not for the reason you might think, its not actually the software which makes software emulation inaccurate but rather pc graphics and sound hardware. FPGA is not just the emulator core, the fpga also provides video and audio output, but without the horrible limitations that pc graphics and sound hardware have.
>>12034273>i herd u liek fpgasNever change dumb kids
cant even emulate a sid chip from a commodore 64. fpga is a scam like link was
>>12035098>like link was
>>12034273You shouldn't talk about "performance" as that mostly means "how many CPU cycles can we get out per second".You may need to look up what "CPU cache" and "cache miss" are to understand this post.What you want is cycle accurate emulation. For the oldest system that gets emulated, that's quite simple. But once you get up to the PS1 CPU, where you have things like cache memory in the CPU there will be a big divergence between what a normal emulator does and what an FPGA does.Normal emulation will not to proper cache emulation. Some emulators fake this. You can see this by running Battle Arena Toshinden in Retroarch. It really sucks and you have to tweak the settings a lot to get it *just right*.If you instead do a PS1 in an FPGA the cache thing will be built-in/solved by how you model the hardware. So whenever the original hardware would make a cache miss, the FPGA hardware would also do one, making it cycle accurate.Then you have things like controller input;For most consoles there's a 2 frame delay for controller inputs. This is in the games logic and due to electrical characteristics. If you connect a NES controller to a MiSTer you will get the exact delay behavior as the original NES.If you use an emulator then the signal will have to travel and translate through the software and computer kernel before the emulator gets it. So you have the 2 frame delay from game logic, but then you have even more delay from the computer hardware interface code. And maybe you're using a NES to USB adapter, which would add even more signal delay.So in short:An FPGA will be the most precise "emulator" you can get. But if you're just playing something like Final Fantasy Tactics, where controller delay or cycle precision matters, then an emulator is fine. But as soon as you pop Vagrant Story in, then you *really* want the minimum delay an FPGA gives you -- or you will miss all your chain hits.
>>12038110>Normal emulation will not to proper cache emulation. Some emulators fake this. You can see this by running Battle Arena Toshinden in Retroarch. It really sucks and you have to tweak the settings a lot to get it *just right*.What isn't right exactly? You never describe the issue. I'm curious.
>>12034273>I heard that FPGAs get the best performance for game emulation since they can be programmed to mimic almost any hardware."Performance" is not the right word, that's like arguing CPU processing power when the end goal is to replicate another system as closely as possible, not make it as powerful as possible. The main advantage of FPGAs is that they can electronically replicate other hardware, in this case electronically replicating the chips retro consoles had. This can inherently give you more accuracy (if the core is programmed well) but another big advantage is that it can execute in parallel like the real hardware did while software emulation cannot do this and it can introduce lag, and it can also take native inputs and outputs so that it does not add additional lag and can natively output to CRTs.>Has anyone worked with one before?What, you mean a FPGA device like a MiSTer or FPGAs in general? I have a MiSTer and I took FPGA programming courses during my computer degree, but I haven't written a core if that's what you mean.>Are there any good tools out there for turning one into an emulator?You would need to find a suitable FPGA and then development software for it. There is no specific emuFPGA development suite made just for this, not a universal one that works on any FPGA. FPGAs still have architectures like CPUs do, especially when talking about an entire dev board like the DE-10 Nano and just not the bare FPGA chip itself.>>12034304>At this point they're no more accurate than a software emulator so there's really no point.Extremely incorrect. Most of the cores are far more accurate and don't introduce additional latency when doing it. The most accurate Genesis software emulator despite being based on the current MiSTer core still scores lower in accuracy tests... while taking several HOURS to run a test it takes a few seconds to run on FPGA.
>>12038135>You never describe the issue. I'm curious.First we need a bit of grasp of the subject. Read the paragraph under the heading "Simple understanding of cache and memory":https://deavid.wordpress.com/2020/02/11/cpu-cache-and-memory-bottleneck/And how is this reflected in the PS1? Search for the word "cache" on this page:https://en.wikipedia.org/wiki/PlayStation_technical_specificationsIn order for a (modern) CPU to run an instruction the instruction itself, and its operands, has to be available in cache memory. So say that you have this code:new_player_x_pos = current_player_x_pos + x_movement_this_frame;(abbreviations new_x = curr_x + delta_x)This will become something like this fake asm code:# semantics:# instruction target, source_A, source_Bload reg_1, $curr_xload reg_2, $delta_xadd reg1, reg_1, reg_2store $new_x, reg_1When this is executed all the values stored in RAM (prefixed with $) aren't updated instantly. Instead the calculated values (what's stored in reg_1 and then put in $new_x) are stored in cache until some other variables needs to be loaded into cache.When the CPU needs to use values currently NOT in cache, what is currently there will be written back into RAM. Doing this will pause the CPU until the transfer is done.An emulator running on a computer CAN simulate this, but doing so will be very (CPU cycle) expensive and complicated to get right. Doing this on an FPGA is a lot more straight-forward and easy to implement....continued below...
>>12037059I hate to admit it but I'm getting horney looking at that picture
>>12038135>>12039059...continued from above...When a game doing a frame-skip (draw the same frame twice) means that it didn't get all the necessary work done in time for picture to get drawn. Basically there weren't enough CPU cycles to calculate all the things. One thing which eats CPU cycles is when the values are NOT currently in cache and things needs to get switched out and in.For the first Battle Arena Toshinden they had a pretty horrible memory layout, causing the game to have a LOT of cache misses. If you don't model cache misses then the emulated game will run without any slowdown at all, when the original had them. Retroarch has an option to "reduce" the clock speed of the CPU to simulate cache misses. It's rough and nowhere near precise. But if you tweak it a lot it's precise enough to fool most users.
>>12034419Nah hes right.
>>12034273
>>12034497>fpga is emulating hardware but isn't an emulator and is as accurate as original hardware.Kek.
>>12039068I see, that's interesting.
>>12034273I remember reading some issue with the mister on the PS1 core that it's only 99% accurate UNLESS you're using a dual ram setup? What's not accurate without the dual ram?
>>12034304No software only emulator can work with real light guns on a CRT
>>12039838Not really much of the case anymore. In a handful of games the audio timing is better by a few milliseconds, apparently at a difference that isn't really perceptible unless you use measuring equipment.
Yeah probably
