31–40 of 69 posts
In a similar vein for those looking for more: ZX Spectrum https://zxmini.speccy.org/en/index.html Gameboy https://github.com/angeris/CS107E-GB-Emulator 8086 / 80186 https://github.com/jhhoward/Faux86 Dragon32 https://github.com/eyalabraham/Dragon32-RPi-Bare-Metal Those are all I know. :) I dream of a bare metal Amiga!
One of the key advantages of FPGA retro game emulation is its low overhead processing input and audio. This is because the FPGA emulates hardware directly and doesn't have to go through OS abstraction layers built to accomodate multitasking. I wonder if bare metal emulators can achieve similar latency for software emulation.
In a similar vein for those looking for more: ZX Spectrum https://zxmini.speccy.org/en/index.html Gameboy https://github.com/angeris/CS107E-GB-Emulator 8086 / 80186 https://github.com/jhhoward/Faux86 Dragon32 https://github.com/eyalabraham/Dragon32-RPi-Bare-Metal Those are all I know. :) I dream of a bare metal Amiga!
One of the key advantages of FPGA retro game emulation is its low overhead processing input and audio. This is because the FPGA emulates hardware directly and doesn't have to go through OS abstraction layers built to accomodate multitasking. I wonder if bare metal emulators can achieve similar latency for software emulation.
yes and no. no or little OS abstraction, but still there's layers in the way, and it's still sequential in places where an FPGA could be parallel, etc. a Pi etc has a huge advantage in raw clock speed. FPGAs are pretty slow. at least the ones that you and i can afford
In a similar vein for those looking for more: ZX Spectrum https://zxmini.speccy.org/en/index.html Gameboy https://github.com/angeris/CS107E-GB-Emulator 8086 / 80186 https://github.com/jhhoward/Faux86 Dragon32 https://github.com/eyalabraham/Dragon32-RPi-Bare-Metal Those are all I know. :) I dream of a bare metal Amiga!
The ultimate bare metal Amiga, https://retrogamecoders.com/mister-fpga-amiga/
One of the key advantages of FPGA retro game emulation is its low overhead processing input and audio. This is because the FPGA emulates hardware directly and doesn't have to go through OS abstraction layers built to accomodate multitasking. I wonder if bare metal emulators can achieve similar latency for software emulation.
A particular point in the space I find very appealing is emulators running on RP2040 class microcontrollers such as Raspberry Pi Pico. These have most of the advantages of FPGA, including latency measured in microseconds, near instant boot, and "racing the beam," but at considerably lower cost.
Earlier quoted context omitted.
What layers do you mean that would remain? I wouldn't expect the experience to be identical nor quite as accurate [1], but if audio and input latency could be made indistinguishable between a Raspberry Pi and a Mister FPGA that would already be quite a significant feat :) [1] FPGA emulation is not intrinsically more accurate, but most Mister cores are considered to be more accurate than popular Retropie cores.
Framebuffer is one such layer. The output from the emulator goes into a framebuffer before being rendered. It's not going to "race the beam" the same way a FGPA'd VIC-II would. Same with USB input stack, though I guess MiST/Mister has that too. Same with SID emulation, which would render into audio buffer samples of certain size (and therefore latency), whereas a hardware or FPGA SID could drive the DAC directly.
The key latencies you describe (frame buffer, audio) aren’t really an issue in the DSP scenario. Also, non linear components like the SID are going to be harder to reimplement in discrete circuits and in fact I’d expect DSP would do better.
DSP wins every time in all domains. Problem is you need to have a much more fine-grained knowledge of the physical underpinnings of the system, not just the system itself.
Very cool project! I've been getting more and more interested in "bare metal" projects, and one day am just going to dive right in. There's something weirdly unsatisfying about building a Raspberry Pi appliance that boots to Linux just to do a Thing, when it could just boot to the Thing.
Well, I think here the distinction between Linux the kernel and Linux the OS (may RMS forgive me) is important. I agree that booting a Linux OS to run a single application seems overkill and adds little other than maintenance burden and boot time. The Linux kernel however, particularly when stripped to the minimum needed, boots fast (quite different under the hood). I'd think attempting to replace the Linux kernel just adds burden for little or no gain.
One of the key advantages of FPGA retro game emulation is its low overhead processing input and audio. This is because the FPGA emulates hardware directly and doesn't have to go through OS abstraction layers built to accomodate multitasking. I wonder if bare metal emulators can achieve similar latency for software emulation.
With a 1982 commodore 64, a tight polling loop could detect a button press within 7 microseconds of its occurence. An onscreen change could be displayed with another 5 microseconds (more if the display happened to be in horizontal or vertical refresh at the event time, but still.) Can any modern system give such tight IO timing?
Now if they just would have made multiprocessor C64s so that one could have been dedicated to that tight loop ...