In it, we learn that the aforementioned black paint from Ford had so much asphalt in it that black was the only color that would work. Not to go down a This Is Spinal Tap rabbit hole, but there were several kinds of black on those Model Ts. Over 30 of them were used for various purposes. The paints also dried in different ways. While the assembly only took 12 hours, the paint drying time took days, even weeks backing up production and begging for innovation. [edconway] then fast-forwards to an era of “conspicuous consumption and ‘planned obsolescence’” with DuPont’s invention of Duco that brought color to the world of automobiles.
See the article for the real story of advances in paint technology and drying time. Paint application technology has also steadily improved over the years, so we recommend diving in to get the century’s long story.
Doom has a larger cultural footprint than the vast majority of video games ever made. That inspired [Theor] to see if it was possible to laser-cut some of the game’s maps to create a real-world model of those famous original levels.
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!
It’s been a while since we last covered DLL injection, and it’s nice to see how the process has evolved. Video after the break.
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?
SMT components for easy machine placement
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.
Discrete transistor D-type flip flop with indicator. Latest circuit switched to 2N7002 NMOS.
In terms of the project write-up, there is plenty to see, with a Verilog model available, a custom programming language [Joe] calls Q2L, complete with a compiler and assembler (written in Rust!) even an online Q2 simulator! Lots of cool demos, like snake. Game of Life and even Pong, add some really lovely touches. Great stuff!
