[LeoPanthera]

I have an Analogue Pocket, which works really well, but the fact that it uses an FPGA is essentially meaningless to me. Is there really any significant difference compared to software emulation?

I know how they're different, I understand the mechanics of it, I just don't understand why it's not possible to make a software emulation that is as good as FPGA emulation. Or maybe it is possible. I always felt like doing it in software would be a lot more flexible.

[elipsitz]

I agree, and wrote a rant about this as part of the post: https://eli.lipsitz.net/posts/introducing-gamebub/#a-brief-r...

IMO: the only real advantage is that it allows you to meet the precise timing needed to interface with physical hardware, like cartridges and other consoles (with link cables).

I think they're also really fun to write, because you think more like a hardware designer than a software engineer.

[pipes]

Am I correct in thinking that FPGAs have an advantage over software emulators when it comes to latency? In particular the latency from the host operating system before input has even been received by the software emulator? I.e. FPGAs don't have a host OS and will have the same latency as original hardware?

This is very much a genuine question, I just want to know if my intuition about this is right or wrong.

Your project looks amazing btw!

[dailykoder]

FPGAs not only have no host OS, but they are actual hardware. The only thing you program are lookup tables which then represent logic gates/multiplexers which only have the normal hardware latency. There is literally no software involved in execution.

That's why you can build "any" hardware with them. Even CPUs which then execute your desired software

[elipsitz]

Yeah, that's another advantage. Theoretically you can get down to <1 frame of input latency with an FPGA. I haven't found the latency on a software GBA emulator running on a computer to be noticeable, but some people might find this to be another advantage.

I think with a dedicated emulation handheld (non-FPGA), you could probably pull some tricks to bring down the latency though.

[cladopa]

It deeds on the game and technology that you try to emulate. I wrote home-brew emulator software for the Nintendo DS. I could play Sega Genesis games without problems but some SNintendo games like StarFox game me literally headaches. Why? Because the SNES included special chips in the cartridge that were painful to emulate, badly documented and gave you screen flickering and stuff.

Those consoles are so old now that you could emulate them with anything, a Chinese chip that cost dollars will do. But you will be extremely wasteful, consuming tens or hundreds of times more energy(less battery time) for a worse result.

Software is way more flexible. Everything is prototyped first in software. In the past there were machines that consumed a hundredth of a watt of energy. Emulating them using 20Watts is so wasteful.

With software you had only one thing that needs to do totally different things. With hardware you can choreograph a chip working in parallel among others in an independent way.

[varispeed]

Software emulations typically are not real-time, so that's one substantial difference.

For instance when you press a button, it will take few ms to register with software emulation, whereas on FPGA it should be very much instantaneous.

[Y_Y]

Consider that you can emulate an FPGA on a CPU, just much slower.

[christkv]

Mostly input latency since it does not incur all the layers of latency in the os plus the emulator.