Bare Metal Emulation on the Raspberry Pi – Commodore 64 | Hacker News Reader

Bare Metal Emulation on the Raspberry Pi – Commodore 64

accentual.com

135 pointsbane68 comments

Open articleView on HN

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!

No love for TI or trash 80?

I used the TI-994A. It was rubbish. Horribly constrained by a design that was cost-cut into uselessness.

But you know what, do a bare-metal Pi emulation of the Geneve 9640, which is what the TI99 could and should have grown up into, and I will start paying attention.

https://www.old-computers.com/museum/computer.asp?st=1&c=120...

The ultimate bare metal Amiga,

https://retrogamecoders.com/mister-fpga-amiga/

Was just going to say … you’d need some sort of FPGA style arrangement

Maybe PiMiga will hold you over..

This is my good friend Randy's project. I don't believe he's working on it anymore, as his main project right now is his FPGA re-implementation of the VIC-II chip.

http://accentual.com/vicii-kawari/

I like to think of BMC64 as a "unikernel" C64 emulator. Effectively it's VICE forked to run on the Circle library. The theoretical advantages are a) fast boot times b) low input device and display latency.

If you don't need a video showing the hardware and discussing all the details, you can find the emulator here: https://accentual.com/bmc64/

That's probably a better (or at least more canonical) URL for the project than youtube, so I've put it at the top. Thanks!

The submitted URL was https://www.youtube.com/watch?v=53wHr415LPU and people will probably want to look at both.

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.

I mean, these Z80 cards used the host computer as IO. Instead of emulating a CPU on the raspi, one could run native raspi code and use the host computer for IO... basically make the ancient host computer a graphics and sound card for a modern CPU.

It can and does, there is the facility to upload native rasp-pi code and have it execute natively, not even pretending to be an ARM1.

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.

Sigh. *pico, not zero. Fingers and brain are not coordinated today.

> 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 (<1s is possible), shields from the complications of the hardware which aren't of interest and allows some portability (even the various PI models are quite different under the hood). I'd think attempting to replace the Linux kernel just adds burden for little or no gain.

If you were to do it all from scratch I could agree, but there are projects to allow baremetal code to interact with the different hardware on the Pi (works on a bunch of different models.)

https://github.com/rsta2/circle

Now I don't want to stand in the way of progress, but while I admire the skill and endurance of the contributors, I fail to see the motivation (I only skimmed their readme) for this project. It looks to me one gets a subset of the features of the Linux kernel with a superset of its bugs. And for owners of a Banana Pi (or Orange Pi etc.) not even that.

I suggest checking out circle https://github.com/rsta2/circle since it's basically a library for the pi hardware. I'm doing some experiments with it myself now.

Ultibo is amazing for this kind of stuff:

https://ultibo.org/

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!

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.

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.

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.

This is an interesting dichotomy: analogue vs digital - but I think there’s a third leg to it which is DSP. When your floor is a 1 MHz 6502 and you have a DSP running at many many multiples of that, you can mimic analogue circuits almost perfectly, with identical latency, but better reliability, serviceability, and cheaper parts. The key thing to remember here is that the 2040 is more like a DSP emulating the signals than a regular pi emulating the system. Something as simple as a c64 it should be possible to emulate with DSP indistinguishable from discrete circuits.

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.

MiSTer is quite successful FPGA in the retrogaming scene though.

Every modern Xilinx FPGA with enough logic to implement a Commodore 64's functions can more than clock at the 1MHz required. 50MHz-200MHz is reasonable. A $40 Artix A35T can handle this.

Why do you need more?

You don't, for a C64. We weren't talking in this subthread specifically about the C64 but about the broader idea of FPGA vs CPU driven emulation.

When you get into higher spec machines, esp from the 90s, FPGA starts to not be the best choice $$ per clock.

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’)

Agreed. I might've put "human interface" as opposed to HID, to cover the output too.

We didn't design modern stacks to handle lowest latencies possible. Because everything is a tradeoff.

Take a look at audio I/O on normal PC in 2000s. Although input digitizing and output de-digitizing were always fast enough, the "DSP" (moving data to userspace, processing, and out) was slow. Because in software design it was given that millisecond latencies aren't a thing, we used a lot of locks and copying around to ensure the system works correctly for average use which isn't realtime IO. However when someone desired realtime IO they enhanced the drivers and/or the audio software stack.

That approach worked because there were no issues in electronics, so to speak. With gaming you have slow USB input and slow HDMI/whatever output.

In my view that is peripheral issue and not architecture issue, although you can also say it is a platform issue. The question is not that straightforward.

> With a 1982 commodore 64, a tight polling loop could detect a button press within 7 microseconds of its occurence.

Now if they just would have made multiprocessor C64s so that one could have been dedicated to that tight loop ...

In fast network processing on PC hardware, you process interrupts of NIC on a single core, automatically. That NIC is DMAing the data which you can poll and dequeue from memory via multiple consumer ring buffers. You have a single master core and N worker cores. If you go for performance and decide to dumb poll without any yields the system will be lightning fast (and max out your CPU usage)

But (as mentioned in reply above) good Ethernet cards have way less inherent I/O latency than USB input device<->HDMI screen chain.

So, I see the solution in a PCIx graphics card that can generate VGA signal and take PS/2 input via poll mode drivers. If you connect "real" peripherals to it you can go low-latency, if you connect HDMI/USB stuff via adapters you'll have arbitrary latency.

You could do processor offloading to the entirely separate 6502 in the CBM 1541 disk drive, like this fractal generator.

https://www.c64-wiki.de/wiki/Mandelbrot-Construction-Set

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.

Could you explain why latency is better on such system ? I fail to see why by just reading the tech spec... Thx.

It doesn't seem like it in this case. The article states there's 2-4 frames of video lag even on composite and 5-6 frames of audio lag.

Maybe it's just me but I'd be much more interested to see a bare-metal C65 emulator. The C65 was a far more interesting computer than the C64 or the C128 IMHO, and if all you want to do is play games then the C65 can run C64 stuff in its C64 mode anyway.

There are existing C65 emulators -- MAME supports it and there's the standalone Hi65: https://devilmaster.altervista.org/hi65.html

There seem to have been discussions about incorporating C65 into VICE, which BMC64 is based on, but it doesn't seem to have happened yet. That would be, for me, much cooler and more fun to experiment with.

Thing about the C65 is … what do you emulate?

Since it only ever got to prototype stages, the original C65s that are out there run a bewildering array of slightly buggy systems. All have quite different capabilities. Was it supposed to have a UI? We'll never know, and you won't get a unified answer from the ex-Commodore folks

This is apparently a FAQ when it comes to C65 emulation, and as such, the developer of Hi65 has answered it in quite a few places already.

There aren't _that_ many -- few leaked, so it's not a big array of kit. The latest ROM would be preferable, and possibly fixing any outstanding bugs in it.

Another alternative is simply to emulate the Mega65.

https://mega65.org/

This could be the chance for a rebirth for the machine and thus set the standard rather than trying to follow it.

The 'bare metal' part is interesting, but I'd assume dealing with things like video or audio directly on the HW, especially in modern hardware is a PITA

A very bare-bones linux or BSD should add minimum overhead and make things much easier

The Circle library handles all of that... Remember, this is just for Raspberry Pi hardware, so it's not like they have to support that many different types of hardware.

There is a back and forth in the YT comments where one commenter insists that Linux OS is still running under the hood…

So the Linux OS never boots, correct? It’s booting directly from the c64 bin so to speak? Feels very Justine Tunneyish almost..

Correct. It is booting from the BMC64 image.

And it doesn’t look like there is any Linux or supporting Linux elements embedded into that image I don’t think? (From what I saw in the page dang posted/updated)

Correct, there is no linux.

It is open source:

https://github.com/randyrossi/bmc64

No Linux kernel there

https://github.com/randyrossi/bmc64/blob/master/kernel.cpp

That is pretty friggin awesome. And even more awesome that you can just copy over whatever d64s to the image that I assume are easily accessible in the c64 environment once booted. I was considering trying something like Combian64 but this seems way tighter. Edit ah too bad actually was looking for something that would work with my pi400 but I guess bmc64 only works up to pi3. If anyone could port bmc64 to pi4 or make it work that would be amazing (unfortunately not I as I don’t have the technical know-how)

Unfortunate the Pi 4 is more like a PC with a few layers of turtles between the user and the hardware. Up until then the pi were more like a microcontroller with a UI layer atop. You could peel that back and get at the raw goodies. The newer pi is vastly more complex and requires all these dark processes and proprietary firmware blobs beneath the OS to make it go.

Ah interesting thanks for the info and context

> Up until then the pi were more like a microcontroller with a UI layer atop.

This is not my area of expertise but from my understanding and reading, I would dispute that, strongly.

The Pi 1, 2 & 3 all run the ThreadX RTOS on the GPU as their "firmware" and the Arm core(s) are started by ThreadX:

https://en.wikipedia.org/wiki/ThreadX

Now ThreadX is owned by Microsoft but it wasn't when the Pi was designed and built.

I love your turtles allusion but the Pi never was a simple or clean (or FOSS) design.

The Pi Pico is, relatively speaking, but it's not really a Pi.

I perhaps overpaid the simplicity of the early pi’s but the point I was was making that you missed was more of comparison between the pi4 and the earlier models. Thanks.

Is the Pi 4 so different in this regard?

It has more flexibility in what it boots from and so on, but ThreadX and so on are still involved.

I was told that the Pi 5 is significantly different, but not the 4. Are you perhaps mixing them up?

Maybe pal

Hostile, unpleasant, threatening, and not the sort of thing I want to see on HN.

Rude, unhelpful, condescending and pedantic. All too common on HN but not at all clever.

The bare metal library is mentioned in the repo in different places, but might be worth adding a link to it as well, it's Circle: https://github.com/rsta2/circle

> Feels very Justine Tunneyish almost..

I'm not sure I get this reference

https://github.com/jart/blink

Does it use a bare metal API like Circle? Are there other APIs like this for other platforms?

Or you can use a bare metal compiling environment like Zig or Cosmopolitan?

It uses Circle.

Between two and four frames of lag even on composite, and five or six frames of audio lag. Is that the best we can expect from a Raspberry Pi?

Reply on news.ycombinator.com