Rack Cage Generator Gets Your Gear Mounted

Sometimes, as hackers and makers, we can end up with messy lashed-together gear that is neither reliable nor tidy. Rackmounting your stuff can be a great way to improve the robustness and liveability of your setup. If you find this appealing, you might like CageMaker by [WebMaka].

This parametric OpenSCAD script can generate mounts for all kinds of stuff. Maybe you have a little network switch that’s just a tangle of wires on your desk, or a few pieces of audio gear that are loosely stacked on top of each other and looking rather unkempt. It would be trivial with this tool to create some 3D printed adapters to get all that stuff laced up nice and neat in a rack instead.

If you’re eager to get tinkering, you can try out the browser-based version quite easily. We’ve featured similar work before, too—many a maker has trod the path of rackmounting, as it turns out.

PSX Development With Unity And LUA

The Unity game development platform was first released in 2005, long after the PlayStation had ceased to be a relevant part of the console market. And yet, you could use Unity to develop for the platform, if you so desire, thanks to the efforts of [Bandwidth] and the team behind psxsplash. 

Yes, it really is possible to design games for the original PlayStation using Unity and Lua. Using a tool called SplashEdit, you can whip up scenes, handle scripting, loading screens, create UIs, and do all the other little bits required to lash a game together. You can then run your creation via the psxsplash engine, deploying to emulator or even real hardware with a single click. Currently, development requires a Windows or Linux machine and Unity 6000.0+, but other than that, it’s pretty straightforward to start making games with a modern toolset for one of the most popular consoles of all time. Just remember, you’ve only got 33 MHz and 2MB of RAM to play with.

We still love to see the legendary grey machine get used and hacked in new and inventive ways, so many decades after release.

Continue reading “PSX Development With Unity And LUA”

Three-Monitor Ridge Racer Machine Emulated In MAME

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)

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

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

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

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.