Having a working Amiga 500 that’s able to run most classic games is nice, but having one that’s also able to run some of the newer software is much, much better.

The Amiga 500 comes with 512 KB of RAM soldered on the board, acting as what it’s called Chip RAM. Let’s see how much we can add on top of that.

RAM: The fast, the slow and… the chip?

Being a newcomer to the world of Amiga computers, everything related to RAM was very confusing to me. Long story short, on the Amiga 500 you can roughly have three types of RAM:

At the end of part 1 we had a clean Amiga 500, both in the inside and the outside, which we couldn’t test because the power supply that came with it was broken.

With a brand new power supply here, it’s time to find out what it works and what it doesn’t.

The first boot

While I’ve never been much of a collector myself, over the last couple years I’ve acquired a taste for retrocomputing content, avidly consuming the videos produced by people like The 8-Bit Guy, Adrian’s Digital Basement and Jan Beta, among others.

I’m amazed by the love they put on testing and restoring all kinds of old computers, and it’s definitely contagious. So, some months ago I decided to go shopping myself.

Being able to run AI models locally is one of the coolest tech things 2023 brought to the table. But given the extremely heterogeneous software stack for AI accelerators, doing that in an efficient way on your own laptop is not always as easy as it should be.

For instance, if you’re running macOS on an Apple Silicon machine, you can easily build llama.cpp with its Metal backend and offload the inference work to the M-based GPU. But can you do that from a container?

It’s been almost a year since I transitioned from the Virtualization to the Automotive team at Red Hat with the goal of ensuring RHIVOS ships with a powerful Virtualization stack. While there’s a large overlap between a Virtualization stack for Servers and the one for Automotive platforms, the latter is much more demanding on one particular aspect: GPU acceleration.

For me, personally, that meant having to delve into the Linux graphics stack, both kernel (DRM, GEM, KMS…) and userspace (Mesa, virglrenderer…), something in which, so far, I only had a superficial knowledge. And, when facing a new field, my preferred approach is looking for an interesting project that would both motivate me to play with those software components.

There’s this interesting idea of adding support for running Wasm/WASI payloads in libkrun, which is something we could easily achieve by simply embedding a Wasm runtime, statically built for Linux, into initrd.

Now, the problem with this approach is that, despite having a payload (the Wasm runtime) with a well-known behavior, we would still be using a (built with a minimal config, but otherwise complete) Linux kernel, despite only needed a small amount of its functionality. In other words, the workload’s TCB would not be optimal.