Level data was extracted from the game’s original WAD data files using code written in Rust. Maps are described by multiple “lumps” within the WAD file format, each containing information on vertexes, walls, and floors. This data was scraped and converted into SVG files suitable for laser cutting. [Theor] then built a visualizer that could display what a stacked-up laser cut map would look like in 3D, to verify everything worked correctly. With that done, the map could be laser cut without worries that it would come out a jumbled, janky mess.
[Theor] kept the finished product simple, creating the map as a stack of blue acrylic pieces. We can imagine this tool being perfect for creating a high-quality diorama though, with some work done to paint the map to match what the player sees in game. If you happen to take that approach, don’t hesitate to notify the tipsline!
There’s something to be said for über-powerful cyberdecks, but there’s also a certain appeal to less powerful decks squeezed into a tiny form factor. [Christian Lo] has designed a cyberdeck that looks like a simple ortholinear keyboard but is running a more flexible environment.
There are games and animations you can play on QMK, but [Lo] felt that a different framework would give him more flexibility to really stretch the limits of what this Raspberry Pi Pico-powered deck could do. He decided to go with a Rust-based firmware with the keyberon library and says, “it felt like I was in control of the firmware.” While the board is using Rust for now, [Lo] says he’s open to conversations about other firmware options to achieve his goals, like a virtual pet game for the board.
The PCB is described as “bog standard” with the possible exception of placing the Pi in a cutout on the board to keep things as low profile as possible. The trade-off comes in the form of reduced board rigidity and potentially increased strain on the connections to the microcontroller.
Ever been frustrated that a software package was missing a feature you want? In the best-case scenario, the software would be open source and you could just tweak the code and rebuild. But in many cases, the software is closed-source. In the case of [Faster than lime], he found a SNES emulator (Snes9X) that didn’t support controllers to showcase the technique. So with a little bit of Rust, he wrote some code that could be injected into the emulator via DLL injection.
It’s a fantastic tutorial that shows the technique. He starts by creating a Rust project that uses the DLL-Syringe crate (the rust version of dependency management). This crate does much of the heavy lifting involved with injecting a DLL into a target process. The rest of the journey is an excellent process of going through the Windows documentation and implementing the features. The DLL just reads the controller and then sends the right input to the program. In the end, [Faster than lime] has a great injected DLL and we have a wonderful time learning about Rust and debugging in an injection environment!
Here at Hackaday, we are big proponents of using the best tool for the job (or making your own tool if required). But when all you know how to use is Java, everything looks object-oriented. Bad jokes aside, it is important to have many tools at your disposal to allow you to choose wisely. Why not spend a few minutes with [No Boilerplate] and understand the basics of Rust?
The focus of the video is to go through as much Rust as possible and teach you how to read it. The idea is that rather than work your way from basic concepts, [No Boilerplate] will go over the vast majority of what you’ll see in a Rust-based program. Whether you’re coming from an object-oriented, functional, or just plain C-based background; you’ll feel comfortable since he makes an effort to compare to what you already know. Some of Rust’s more unique features are covered such as mutability, scope, matching, and strings. However, lifetimes, closures, and traits were left out to keep the video short. These topics are covered in an excellent blog post by [Faster than lime] which this video was based on.
There is gathering momentum around the idea of adding Rust to the Linux kernel. Why exactly is that a big deal, and what does this mean for the rest of us? The Linux kernel has been just C and assembly for its entire lifetime. A big project like the kernel has a great deal of shared tooling around making its languages work, so adding another one is quite an undertaking. There’s also the project culture developed around the language choice. So why exactly are the grey-beards of kernel development even entertaining the idea of adding Rust? To answer in a single line, it’s because C was designed in 1971, to run on the minicomputers at Bell Labs. If you want to shoot yourself in the foot, C will hand you the loaded firearm.
On the other hand, if you want to write a kernel, C is a great language for doing low-level coding. Direct memory access? Yep. Inline assembly? Sure. Runs directly on the metal, with no garbage collection or virtual machines in the way? Absolutely. But all the things that make C great for kernel programming also make C dangerous for kernel programming.
Now I hear your collective keyboards clacking in consternation: “It’s possible to write safe C code!” Yes, yes it is possible. It’s just very easy to mess up, and when you mess up in a kernel, you have security vulnerabilities. There’s also some things that are objectively terrible about C, like undefined behavior. C compilers do their best to do the right thing with cursed code like i++ + i++; or a[i] = i++;. But that’s almost certainly not going to do what you want it to, and even worse, it may sometimes do the right thing.
Rust seems to be gaining popularity. There are some ambitious projects out there, like rewriting coreutils in Rust. Many other standard applications are getting a Rust rewrite. It’s fairly inevitable that the collection of Rust developers started to ask, could we invade the kernel next? This was pitched for a Linux Plumbers Conference, and the mailing list response was cautiously optimistic. If Rust could be added without breaking things, and without losing the very things that makes Rust useful, then yes it would be interesting. Continue reading “Things Are Getting Rusty In Kernel Land”→
[Joe Wingbermuehle] has an interest in computers-of-old, and some past experience of building computers on perfboard from discrete transistors, so this next project, Q2, is a complete implementation of a PDP8-like microcomputer on a single PCB. Like the DEC PDP-8, this is a 12-bit machine, but instead of the diode-transistor logic of the DEC, the substantially smaller Q2 uses a simple NMOS approach. Also, the DEC has core memory, but the Q2 resorts to a pair of SRAM ICs, simply because who wants to make repetitive memory structures with discrete 2N7002 transistors anyway?
Like the PDP-8, this machine uses a bit-serial ALU, which allows the circuit to be much smaller than the more usual ALU structure, at the expense of needing a clock cycle per bit per operation, i.e. a single ALU operation will take 12 clock cycles. For this machine, the instruction cycle time is either 8 or 32 clocks anyway, and at a maximum speed of 80 kHz it’s not exactly fast (and significantly slower than a PDP-8) but it is very small. Small, and perfectly formed.
The machine is constructed from 1094 transistors, with logic in an NMOS configuration, using 10 K pullup resistors. This is not a fast way to build a circuit, but it is very compact. By looking at the logic fanout, [Joe] spotted areas with large fanouts, and reduced the pull-up resistors from 10 K to 1 K. This was done in order to keep the propagation delay within bounds for the cycle time without excessive power usage. Supply current was kept to below 500 mA, allowing the board to be powered from a USB connector. Smart!
Memory is courtesy of two battery-backed 6264 SRAMs, with the four 12-bit general purpose registers built from discrete transistors. An LCD screen on board is a nice touch, augmenting the ‘front panel’ switches used for program entry and user input. A 40-pin header was added, for programming via a Raspberry Pi in case the front panel programming switches are proving a bit tedious and error prone.
Seems like all the cool kids are rewriting legacy C programs in Rust these days, so we suppose it was only a matter of time before somebody decided to combine the memory-safe language with some of the most historically significant software ever written by way of a new Apollo Guidance Computer (AGC) emulator. Written by [Felipe], the Apache/MIT licensed emulator can run either ROM files made from the computer’s original rope core memory, or your own code written in AGC4 assembly language.
It’s worth noting that the emulator, called ragc, needs a bit of help before it can deliver that authentic Moon landing experience. Specifically, the code only emulates the AGC itself and stops short of recreating the iconic display and keyboard (DSKY) module. To interact with the programs running on the virtual AGC you’ll need to also install yaDSKY2, an open source project that graphically recreates the panel Apollo astronauts actually used to enter commands and get data from the computer.