A hand holds a small PCB with an edge connector over the exposed, mostly black components of an M4 Mac mini. The bottom cover is hanging by an FFC cable off to the left of the

Upgrading The M4 Mac Mini With More Storage

Apple’s in-house chips have some impressive specs, but user serviceability is something Apple left behind for consumer machines around a decade ago. Repair legend [dosdude1] shows us how the new M4 Mac mini can get a sizeable storage upgrade without paying the Apple tax.

The Mac mini is Apple’s least expensive machine, and in the old days you could swap a SATA drive for more storage and not pay the exorbitant prices that OEMs demand. Never one to turn down a walled garden, later Intel machines and now the ARM-based M-series chips soldered storage into the machine leaving an upgrade out of the hands of anyone without a hot air station.

Both the Mac Studio and Mac mini now have proprietary storage cards, and after some tinkering, [dosdude1] has successfully upgraded the storage on the base model M4 mini. While most people don’t casually reball NAND chips while chatting on a video, his previous work with others in the space to make a Mac Studio upgrade kit give us hope we’ll soon see economical storage upgrades that keep the Mac mini affordable.

We’ve previously covered the first time Apple tried to make its own processors, and some of their more recent attempts at repairability.

Continue reading “Upgrading The M4 Mac Mini With More Storage”

A screen capture from Portal 2 running in Asahi Linux. The Asahi Linux logo is in the bottom right of the image as a watermark. The environment is a concrete and glass building with elements of nature taking over the room on the other side of the glass from the character. A red circle with a grey cube above it is in the foreground.

Asahi Linux Brings Better Gaming To Apple Silicon

For those of you longing for better gaming on an Apple Silicon device, Asahi Linux is here to help.

While Apple’s own line of CPUs are relatively new kids on the block, they’ve still been around for four years now, giving hackers ample time to dissect their innards. The team behind Asahi Linux has now brought us “the only conformant OpenGL®, OpenCL™, and Vulkan® drivers” for Apple’s M1 and M2.

The emulation overhead of the system means that most games will need at least 16 GB of RAM to run. Many games are playable, but newer titles can’t yet hit 60 frames per second. The developers are currently focused on “correctness” and hope to improve performance in future updates. Many indie titles are reported to already be working at full speed though.

You can hear more about some of the fiddly bits of how to “tessellate with arcane compute shaders” in the video below. Don’t worry, it’s only 40 minutes of the nine hour video and it should start right at the presentation by GPU dev [Alyssa Rosenzweig].

If you want to see some of how Linux on Apple Silicon started or some of the previous work on hacking the M1 GPU, we have you covered.

Continue reading “Asahi Linux Brings Better Gaming To Apple Silicon”

A RISC-V LISP Compiler…Written In Lisp

Ah, Lisp, the archaic language that just keeps on giving. You either love or hate it, but you’ll never stop it. [David Johnson-Davies] is clearly in the love it camp and, to that end, has produced a fair number of tools wedging this language into all kinds of nooks and crannies. The particular nook in question is the RISC-V ISA, with their Lisp-to-RISC-V compiler. This project leads on from their RISC-V assembler by allowing a Lisp function to be compiled directly to assembly and then deployed as callable, provided you stick to the supported language subset, that is!

The fun thing is—you guessed it—it’s written in Lisp. In fact, both projects are pure Lisp and can be run on the uLisp core and deployed onto your microcontroller of choice. Because who wouldn’t want to compile Lisp on a Lisp machine? To add to the fun, [David] created a previous project targeting ARM, so you’ve got even fewer excuses for not being able to access this. If you’ve managed to get your paws on the new Raspberry Pi Pico-2, then you can take your pick and run Lisp on either core type and still compile to native.

The Lisp-Risc-V project can be found in this GitHub repo, with the other tools easy enough to locate.

We see a fair few Lisp projects on these pages. Here’s another bare metal Lisp implementation using AVR. And how many lines of code does it take to implement Lisp anyway? The answer is 42 200 lines of C, to be exact.

Time’s Up For Mbed

In a forum post has come the announcement that mBed, ARM’s accessible microcontroller development platform, is to reach end-of-life in July 2026. This means that the online platform and OS will no longer be supported by ARM, though the latter will remain an open source project. The website will be shuttered, and no new projects can be created after that date using ARM infrastructure.

mBed was originally launched back in 2009, as a competitor to the Arduino IDE for ARM’s chips. Its easy development made it attractive and there were soon an array of boards from different manufacturers supporting it, but perhaps due to its support for only the one architecture, it failed to find success. It’s certainly not the first time a single-architecture microcontroller development platform has been discontinued, we need only look to the Intel Edison for that, but given the success of ARM platforms in general it’s still something of a surprise. Perhaps it’s time to take the press release explanation that other platforms such as Arduino have simply been much more popular.

Will a community form around an open source mBed? Given that it’s been a definite minority among Hackaday projects over the years, while we hope it does, we’re not so sure.

mBed board image: Viswesr, CC BY-SA 3.0.

M1 Development Board From Scraps

Apple is fairly notorious for building devices that are difficult to repair, but with the right tools it’s often not completely impossible to circumvent some of their barriers. As they say, every lock has a key. [dosdude1] has wanted a specific M1 development board for a while now and has been slowly piecing together everything he needs to cobble one together, and finally got this unit running despite many roadblocks put in his way by Apple.

The development kit is a Developer Transition Kit  or “DTK” meant for developers during Apple’s transition from Intel chips to their own in-house ARM-based M1 platform. This particular version is in a Mac Mini form factor but it has a few hurdles to clear before it powers on. First, the board was cut in a critical location that shorted out many of the PCB layers, so this had to be carefully filed down to remove the shorts. It was also missing a few tiny surface mount components and a NAND chip, but these were scavenged from other scrapped parts and assembled into a fully working machine.

There are a number of other non-physical problems to solve here as well, too. Apple coded their NAND chips to work with specific WiFi modules so if these aren’t programmed to work together the computer will get stuck in a boot loop. But with that and a few other details out of the way [dosdude1] finally has his DTK up and running in a 2018 Mac Mini chassis, right down to the working power LEDs. We’ve seen all kinds of PCB damage before (although not often quite this intricate) and even PCBs repaired that were snapped in half.

Thanks to [CodeAsm] for the tip!

Continue reading “M1 Development Board From Scraps”

RISC OS Gets An Update

There should be rejoicing among fans of the original ARM operating system this week, as the venerable RISC OS received its version 5.30 update. It contains up-to-date versions of the bundled software as well as for the first time, out-of-the-box WiFi support, and best of all, it can run on all Raspberry Pi models except the Pi 5. If you’ve not encountered RISC OS before, it’s the continuing development of the OS supplied with the first ARM product, the Acorn Archimedes. As such it’s a up-to-date OS but with an interface that feels like those of the early 1990s.

We like RISC OS here, indeed we reviewed the previous version this year, so naturally out came the Hackaday Pi 3 and an SD card to run it on. It’s as smooth and quick as it ever was, but sadly try as we might, we couldn’t get the Pi’s wireless interface to appear in the list of available network cards. This almost certainly has more to do with us than it does the OS, but it would have been nice to break free from the tether of the network cable. The included Netsurf 3.11 browser is nippy but a little limited, and just as it was during our review, sadly not capable of editing a Hackaday piece or we’d be using it to write this.

It’s great to see this operating system still under active development, and we can see that it so nearly fulfills our requirement here for a lightweight OS on the road. For those of us who used the original version, then called Arthur, it’s a glimpse of how desktop computing could, or perhaps even should, have been.

Why X86 Needs To Die

As I’m sure many of you know, x86 architecture has been around for quite some time. It has its roots in Intel’s early 8086 processor, the first in the family. Indeed, even the original 8086 inherits a small amount of architectural structure from Intel’s 8-bit predecessors, dating all the way back to the 8008. But the 8086 evolved into the 186, 286, 386, 486, and then they got names: Pentium would have been the 586.

Along the way, new instructions were added, but the core of the x86 instruction set was retained. And a lot of effort was spent making the same instructions faster and faster. This has become so extreme that, even though the 8086 and modern Xeon processors can both run a common subset of code, the two CPUs architecturally look about as far apart as they possibly could.

So here we are today, with even the highest-end x86 CPUs still supporting the archaic 8086 real mode, where the CPU can address memory directly, without any redirection. Having this level of backwards compatibility can cause problems, especially with respect to multitasking and memory protection, but it was a feature of previous chips, so it’s a feature of current x86 designs. And there’s more!

I think it’s time to put a lot of the legacy of the 8086 to rest, and let the modern processors run free. Continue reading “Why X86 Needs To Die”