Three-Monitor Ridge Racer Machine Emulated In MAME

April 18, 2026 by Zoe Skyforest 12 Comments

When Ridge Racer hit the arcades in the early 1990s, it came in a few different versions. The last variant used three large CRTs to create a wraparound display for the player. Incredibly rare, it’s believed that only a single-digit number of machines remain in existence. [beaumotplage] has secured a remaining example, and been working to preserve this historical artifact.

The first mission when it comes to this machine was to dump the ROMs, which have thus far not been preserved in any major archive. With that done, [beaumotplage] worked to hack a version of MAME that could emulate the Three Monitor Version’s unique mode of operation. As it turns out, each screen is driven by its own arcade board, with the three boards linked via C139 serial links. To emulate this, the trick was simply to write some C139 linkup code and run three versions of MAME all at once, letting them communicate with each other as the original boards would have. It’s a little janky in operation right now, but it does work!

You can download the hacked version of MAME for three-monitor operation here, though note that this does not include the ROM dumps from the machine itself. We look forward to seeing if the hardware ends up getting a full restoration back to operational standard, too.

Overall, this work goes to show that arcade preservation and archival work sometimes requires getting deep into the nitty-gritty technical stuff.

Continue reading “Three-Monitor Ridge Racer Machine Emulated In MAME” →

FRED Comes To Hobby Operating Systems (and Linux)

April 17, 2026 by Julian Scheffers 13 Comments

Those who have worked on a hobby operating system for x86 will have interacted with its rather complex and confusing interrupt model. [Evalyn] shows us why and how to use Flexible Return and Event Delivery (FRED), a new standard by the x86 Ecosystem Advisory Group.

Of course, it would be silly to omit the fact that Linux received patches first. But that isn’t the interesting part; after all, Linux is often the first place to have support for this kind of thing. No, what’s interesting is [Evalyn]’s implementation, to our knowledge among — if not the first — non-Linux operating system to support it.

Part of the startup log of EvalynOS — The kernel confirming that FRED has been detected and enabled

To know why we should switch to FRED, we must first understand what it replaces. The Interrupt Descriptor Table (IDT) tells the CPU what code to run when certain interrupts or faults happen. The big problem that the IDT has is inconsistency, most egregiously the fact that the stack layout depends on which interrupt happened. To solve the issues with the IDT, FRED was created.

[Evalyn] shows us the process, starting at the documentation, then finding an emulator capable of it and culminating in a demo where DOOM runs in EvalynOS with FRED enabled.

Pentium II die shot. Martijn Boer, Public domain.

Rust-y Firmware For Waveshare Smartwatch

April 11, 2026 by Tyler August 18 Comments

Waveshare makes a nifty little ESP32-S3 based smartwatch product, but its firmware is apparently not to everyone’s liking. Specifically, it’s not to [infiniton] a.k.a [Bright_Warning_8406]’s liking, as they rewrote the entire code base in Rust. No_std Rust, to be specific, but perhaps that doesn’t need to be specified when dealing with ESP32.

On the Reddit thread about the project, he lists some of the advantages. For one thing, the size of the binary has dropped from 1.2 MB to 579 kB while maintaining the same functionality. More interesting is that he’s been able to eliminate polling entirely: the firmware is purely event-driven. The CPU is not just idle but parked until a timer or GPIO event wakes it up. For this form factor, that’s a big deal — you can’t fit a very large battery in a watch, after all.

Getting drivers for the AMOLED display, touch sensor, audio, and RTC modules written from scratch is an impressive accomplishment. Apparently the screen driver in particular was “a nightmare” and we believe it. There’s a reason most people go for existing libraries for this stuff. [Bright_Warning] did not post screenshots or video, but claims his version of the watch watch can make HTTP calls to Smart Home, play MP3s, play the old phone games– Snake, 2048, Tetris, Flappy Bird, Maze– and even comes with a T9 keyboard for text input.

If you’re looking to get closer to bare metal, and don’t mind it being Rust-y, take a look at the code on GitHub in the first link above. This author isn’t enough of a rustacean to say if the code is as good as it sounds at a glance, but nothing egregious jumps out. The documentation describing exactly what’s going on under the hood isn’t half-bad, either. If you aren’t into Waveshare products, you could easily adapt this code into a more DIY ESP32 watch, too.

If you’re not into Rust, uh… washing soda and electric current can get it off of steel, and probably microcontrollers too. We can’t say that the chip will work after that, but hey — no rust.

USB, Abstracted

April 9, 2026 by Al Williams 16 Comments

Modern technology builds on abstractions. Most application programmers today don’t know what a non-maskable interrupt is, nor should they have to. Even fewer understand register coloring or reservation stations for instruction scheduling, and fewer still can explain the physics behind the transistors in the CPU. Sometimes tech starts out where you need to know everything (programming a bare-metal microprocessor, for example) and then evolves to abstraction. That’s where [WerWolv] wants to get you for writing USB code using the recent post USB for Software Developers.

Many USB tutorials assume you want to know about the intricacies of protocol negotiation, information about the hardware layer, and that you are willing to write a Linux kernel module to provide a driver. But thanks to abstraction, none of this has been absolutely necessary for many use cases for a long time.

While the post focuses on Linux, there is libusb for Windows. We presume the same principles would apply, more or less.

Continue reading “USB, Abstracted” →

WolfIP Doesn’t Allocate

April 9, 2026 by Al Williams 30 Comments

For some types of embedded systems — especially those that are safety-critical — it’s considered bad form to dynamically allocate memory during operation. While you can usually arrange for your own code to behave, it’s the libraries that get you. In particular, it is hard to find a TCP/IP stack that doesn’t allocate and free memory all over the place. Unless you’ve found wolfIP.

The library supports a BSD-like non-blocking socket API. It can act as an endpoint, but can also support multiple interfaces and forwarding if you were building something like a router. It doesn’t appear to be bare-bones either. In addition to the normal things you’d expect for IPv4, there’s also ICMP, IPSEC, ARP, DHCP, DNS, and HTTP with or without SSL TLS. There is also a FIPS-compliant implementation of WireGuard for VPN, although it is not directly compatible with standard WireGuard, only with other instances of itself (known as wolfGuard). There is a Linux kernel module for WolfGuard, though.

The code should be fairly easy to port, and it includes a binding for FreeRTOS already. If you’ve used wolfIP, let us know in the comments.

If you want to really get down to the low-level, try this project. Of, if you want a refresher on basics, we can help with that, too.

Turning A Bluetooth Caliper Into A FreeCAD Input Device

April 5, 2026 by Maya Posch 23 Comments

It’s a common ritual: whipping out those calipers or similar measuring devices to measure part of a physical object that we’re trying to transfer into a digital model in an application like FreeCAD. Wouldn’t it be nice if said measurements were to be transferred instantaneously into the model’s sketch, including appropriate units of measurement? That’s essentially what [stv0g] has done by merging a Sylvac Bluetooth-enabled caliper and FreeCAD using a plugin.

Key to the whole operation is a Bluetooth-enabled caliper like the Sylvac S_Cal EVO that [stv0g] managed to score on EBay for a mere €90 when it normally goes for multiple times that amount. This has BLE built in, using BLE’s standard GATT profiles for device communications specifications. Along with the provided Sylvac developer tools, this made it relatively easy to develop the InstrumentInput addon for FreeCAD.

Continue reading “Turning A Bluetooth Caliper Into A FreeCAD Input Device” →

Writing An Open-World Engine For The Nintendo 64

March 29, 2026 by Maya Posch 7 Comments

Anyone who has ever played Nintendo 64 games is probably familiar with the ways that large worlds in these games got split up, with many loading zones. Another noticeable aspect is that of the limited drawing distance, which is why even a large open area such as in Ocarina of Time‘s Hyrule Field has many features that limit how far you can actually see, such as hills and a big farming homestead in the center. Yet as [James Lambert] demonstrates in a recent video, it’s actually possible to create an open world on the N64, including large drawing distances.

As explained in the video, the drawing distance is something that the developer controls, and thus may want to restrict to hit certain performance goals. In effect he developer sets where the far clipping plane is set, beyond which items are no longer rendered. Of course, there are issues with just ramping up the distance to the far clipping plane, as the N64 only has a 15-bit Z-buffer, after which you get ‘Z fighting’, where render order becomes an issue as it’s no longer clear what is in front of what.

One fix is to push the near clipping plane further away from the player, but this comes with its own share of issues. Ergo [James] fixed it by doing two render passes: first all the far-away objects with Z-buffer disabled, and then all the nearby objects. These far-away objects can be rendered back-to-front with low level-of-detail (LoD), so this is relatively fast and also saves a lot of RAM, as the N64 is scraping by in this department at the best of times.

In the video the full details of this rendering approach, as well as a new fog rendering method, are explained, with the code and such available on GitHub for those who wish to tinker with it themselves. [James] and friends intend to develop a full game using this engine as well, so that’s definitely something to look forward to.

Continue reading “Writing An Open-World Engine For The Nintendo 64” →