Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bare Metal Emulation on the Raspberry Pi – Commodore 64

accentual.com

Post reply on HN
Print view View original

21–30 of 69 posts

Re: Bare Metal Emulation on the Raspberry Pi – Commodore 64

#21

Post by cmrdporcupine »

DCKing wrote: post #20

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

Re: Bare Metal Emulation on the Raspberry Pi – Commodore 64

#22

Post by DCKing »

cmrdporcupine wrote: post #21
DCKing wrote: post #20

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

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.

Re: Bare Metal Emulation on the Raspberry Pi – Commodore 64

#23

Post by LeoPanthera »

actionfromafar wrote: post #17
LeoPanthera wrote: post #16

See also, PiTubeDirect[1], which runs on a Raspberry Pi which you have plugged into the second processor port of a BBC Micro[2], and turns the Pi into emulator for a number of different processors, notably an arbitrarily fast 6502, a Z80, or an 80286. [1]: https://github.com/hoglet67/PiTubeDirect [2]: https://en.wikipedia.org/wiki/BBC_Micro_expansion_unit#Secon...

Hey… it could run ARM code.

It can, it does.

Re: Bare Metal Emulation on the Raspberry Pi – Commodore 64

#24

Post by dzdt »

DCKing wrote: post #20

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?

Re: Bare Metal Emulation on the Raspberry Pi – Commodore 64

#25

Post by mlongval »

This is a really nice project. I built one on a RPi 3b+ a couple years ago when the project started. I got to chat with Randi Rossi about attaching a C64 keyboard to it via his adapter. He is a really cool and talented guy. Very down to earth (for such a genius).

It’s too bad that there isn’t someone else who could take up the project. I have a dream of seeing his Kawarii extensions to the VicII implemented in the emulator. Wow what a blast that would be!

Re: Bare Metal Emulation on the Raspberry Pi – Commodore 64

#26

Post by cmrdporcupine »

mlongval wrote: post #25

This is a really nice project. I built one on a RPi 3b+ a couple years ago when the project started. I got to chat with Randi Rossi about attaching a C64 keyboard to it via his adapter. He is a really cool and talented guy. Very down to earth (for such a genius). It’s too bad that there isn’t someone else who could take up the project. I have a dream of seeing his Kawarii extensions to the VicII implemented in the em…

I've known and worked with and been friends with Randy since 1999 and agree with your assessment: cool, down to earth, and talented.

But also very modest, so he'd probably be flustered by these comments here so I will make a point of not making him aware of them ;-)

Anyways, I think you could probably make a go of the Kawari extensions in emulation yourself. And to be clear, the changes you'd want would be in VICE, not BMC64 -- which is just a fork of VICE. I have read the VICE source before and it's fairly straightforward what's going on there.

And in fact, I recall part of Randy's test harness for Kawari has been to run the same program through both VICE and Kawari and compare output. So by implementing in VICE you'd be helping extend the test harness.

Re: Bare Metal Emulation on the Raspberry Pi – Commodore 64

#27

Post by zare_st »

dzdt wrote: post #24
DCKing wrote: post #20

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?

Yes but our default USB HID stack isn't made for it. USB is not good for sub millisecond latency.

If you make a keyboard that can send signals fast-clocked over wire to PCI interface card and use polling in the driver you can go as fast as you want. A microsecond poll is not a burden for the CPU core.

Re: Bare Metal Emulation on the Raspberry Pi – Commodore 64

#28

Post by cmrdporcupine »

DCKing wrote: post #22
cmrdporcupine wrote: post #21

Earlier quoted context omitted.

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

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.

Re: Bare Metal Emulation on the Raspberry Pi – Commodore 64

#29

Post by dgacmu »

rusk wrote: post #12
ryandrake wrote: post #11

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.

Sounds like you want ESP! Check out ESPhome and Tasmota

Or a pi zero, if you want to stay in raspberry land and/or trade higher power draw for a fair bit more SRAM.

Re: Bare Metal Emulation on the Raspberry Pi – Commodore 64

#30

Post by bluescrn »

zare_st wrote: post #27
dzdt wrote: post #24

Earlier quoted context omitted.

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?

Yes but our default USB HID stack isn't made for it. USB is not good for sub millisecond latency. If you make a keyboard that can send signals fast-clocked over wire to PCI interface card and use polling in the driver you can go as fast as you want. A microsecond poll is not a burden for the CPU core.

‘Input lag’ in games is rarely about input.

It’s usually all about the latencies involved in getting graphics onto the screen after responding to the input.

Even an FPGA-based ‘emulator’ or real retro hardware with the fanciest low-latency upscaler won’t feel truly responsive if connected to an LCD TV that adds 60-100ms of latency (yes, some are really that bad, especially if not in ‘game mode’)

Post reply on HN