BMC64, a bare metal C64 emulator for the Raspberry Pi

[rSl]

just found this little gem. i'm not using my rpi actively right now, but it sounds promising...

"a bare metal port of VICE (x64) for the Raspberry Pi called BMC64. You get true 50hz/60hz smooth scrolling (no horizontal tearing!), low input to audio/video latency and better audio/video synchronization.

What do you mean by bare metal?

There is no operating system! An O/S like Linux adds layers of abstraction between the application (VICE) and the privileged kernel code that has access to hardware. That adds latency in processing events. User space programs can't get notified directly from interrupts, for example. The interrupt has to be serviced by the kernel, into user space, into your program (at the mercy of the scheduler) before they can get processed. For sound production, the user space program must fill buffers to deliver to a sound driver in the kernel before it can pass it on to the hardware. With Combian/PiLizard and Chameleon installations, you are effectively installing a full blown linux distribution (1.5Gb image files!).

With BMC64, VICE -IS- the kernel and has direct access to the hardware. As soon as you power on the device, it goes straight into the emulator. The entire kernel is ~2MB."

announcement and code here

 

[LineOf7s]

Thanks for that. I've got a spare 16GB card lying around I might have to try this with the next time I'm feeling all C64-y.

 

[levi]

Very interesting. Technically speaking, I posit that there is still an OS; just the OS is VICE and the C64 OS, because you can't run the C64 OS written in 6502 machine code on an ARM host, despite the history between those two chips. Plus stuff like video rastering and driving the speaker was presumably done using motorola chips on the C64, while this has to implement that in software. But that's the benefit of using VICE to do all of that, I guess, cos it handles all of that stuff already. You just need to write enough code to either shim enough stuff to implement a framebuffer for vice to render against and stuff to pretend to be a USB keyboard module, or alternatively, tweak vice until it handles all that in the one big codebase.

But yeah, not running a multiuser, multiprocessing, multithreading system when FUSE probably doesn't need any of that should help simplify timing problems, which is the kind of thing that announcement is talking about in the main. It does kind of mean you have to burn an SD card for a 2MB kernel/emulator plus your set of C64 tapes. Maybe you could do something with uboot to install it alongside a linux kernel and filesystem.

Also, I'll just mention you can get almost all of those theoretical benefits by running RISC OS on your Pi and running VICE on that. I've no idea off the top of my head what the current situation is with a RISC OS port of VICE, but it was certainly done in the past. And I don't know how that performs compared to this, but it does mean you're not implementing multithreading, and the multitasking is entirely cooperative, so as long as your code doesn't go out of its way to implement it, it just stops happening until you quit the emulator. There's still a slight potential lag due to having to fill audio buffers, because the audio system on RISC OS is implemented by modules which latch on to timer interrupts, but that applied to all RISC OS software, and I never noticed problematic audio lags even on a 8MHz ARM2 chip. I'm pretty sure all of RISC OS plus VICE would come in at less than 10MB also.

 

[rSl]

v1.5 released

===============
!!! IMPORTANT PSA !!!
===============

First, my apologies...

BMC64 v1.0.6 through v1.4 were not properly putting the other 3 (unused) cores to a low powered mode and was causing CPU temperatures to rise close to or beyond automatic throttling limits. I'm very sorry about this. I don't believe this pushed the devices beyond their limits, it was just a waste of heat. The Pi will automatically throttle itself if CPU temperature goes beyond a certain limit. If you saw thermometer icons in the top right corner of your screen, this is probably why.

Thanks to lroby74 for bringing this to my attention!

I should have been putting the cores into a 'wait for interrupt' state. Instead, they were spinning inside a 'sleep' routine (constantly checking the system clock for a duration passed).

I've uploaded a v1.5 which is nearly identical to 1.4 + the cores being (I think) properly idled. CPU temperature is significantly lower now and I don't see any adverse side effects.

I also removed old versions from the downloads directory in case there were links to them.

Again, very sorry about this. I was aware of the heat but assumed it was due to the emulator doing its thing!

If there are any developers out there familiar with ARM, here are the instructions I used to idle the cores:

dsb
1: wfi
b 1b

Thanks!

more here

 

[Roberto]

@ #3 ,

I wonder why you have to look for an alternative when you already have a great product, light, fast, and constantly and continuously improving? What need is there to put a RISC OS with an emulator when the essential part (the emulator) that runs beautifully is directly there?

 

[levi]

I didn't know how featureful and well updated that would be when I wrote that, and considered it'd probably be less work to port VICE to RISC OS. But if the bare metal solution has already been worked out and is good and only getting better then I can't argue against that really.