WheatForce: Learning From CPU Architecture Mistakes

Nothing ever made is truly perfect and indeed, CPU architectures like x86, RISC-V, ARM, and PowerPC all have their own upsides and downsides. Today, I aim to make an architecture that learns from all these mistakes and improves architecture design for everyone.

I’ve consulted with many people opinionated on the matter, both from a software perspective, and from a hardware perspective. I have taken all their feedback in mind while creating this initial draft of the WheatForce architecture (PDF). It is inspired by pieces from many architectures: segmentation inspired by x86, hash table-like paging from PowerPC, dynamic endianness control from RISC-V and PowerPC, and more. Let’s look into each feature in a little bit more detail. Continue reading “WheatForce: Learning From CPU Architecture Mistakes”

A hex dump of the first iteration of the small ELF file

How Small Can A Linux Executable Be?

With ever increasing sizes of various programs (video games being notorious for this), the question of size optimization comes up more and more often. [Nathan Otterness] shows us how it’s done by minifying a Linux “Hello, World!” program to the extreme.

A naive attempt at a minimal hello world in C might land you somewhere about 12-15Kb, but [Nathan] can do much better. He starts by writing everything in assembly, using Linux system calls. This initial version without optimization is 383 bytes. The first major thing to go is the section headers; they are not needed to actually run the program. Now he’s down to 173 bytes. And this is without any shenanigans!

A hexdump of the final ELF file, significantly smaller than the original
The final tiny ELF file

The first shenanigans are extreme code size optimizations: by selecting instructions carefully (and in a way a C compiler never would), he shaves another 16 bytes off. But the real shenanigans begin when he starts looking for spaces in the ELF header that he can clobber while the program is still accepted by Linux: now he can move his already tiny x86_64 code into these “vacant” spaces in the ELF and program headers for a final tiny ELF file weighing in at just 120 bytes.

P.S.: We know it is possible to make this smaller, but leave this as an exercise to the viewer.

A laptop communicating with the drone via an Arduino

Reverse-Engineering The Holy Stone H120D Drone

There are plenty of drones (and other gadgets) you can buy online that use proprietary control protocols. Of course, reverse-engineering one of these protocols is a hacker community classic. Today, [Zac Turner] shows us how this GPS drone can be autonomously controlled by a simple Arduino program or Python script.

What started as [Zac] sniffing some UDP packets quickly evolved into him decompiling the Android app to figure out what’s going on inside. He talks about how the launch command needs accurate GPS, how there’s several hidden features not used by the Android app, et cetera. And it’s not like it’s just another Linux SoC in there, either. No, there’s a proper Real-Time Operating System (RTOS) running, with a shell and a telnet interface. The list of small curiosities goes on.

After he finished reverse-engineering the protocol, he built some Python scripts, through which you can see the camera feed and control the drone remotely. He also went on to make an Arduino program that can do the latter using an Arduino Nano 33 IoT.

A Univac 1219 cabinet

See The Computers That Powered The Voyager Space Program

Have you ever wanted to see the computers behind the first (and for now only) man-made objects to leave the heliosphere? [Gary Friedman] shows us, with an archived tour of JPL building 230 in the ’80s.

A NASA employee picks up a camcorder and decides to record a tour of the place “before they replace it all with mainframes”. They show us computers that would seem prehistoric compared to anything modern; early Univac and IBM machines whose power is outmatched today by even an ESP32, yet made the Voyager program possible all the way back in 1977. There are countless peripherals to see, from punch card writers to Univac debug panels where you can see the registers, and from impressive cabinets full of computing hardware to the zip-tied hacks “attaching” a small box they call the “NIU”, dangling off the inner wall of the cabinet. And don’t forget the tape drives that are as tall as a refrigerator!

We could go on ad nauseum, nerding out about the computing history, but why don’t you see it for yourself in the video after the break?

Continue reading “See The Computers That Powered The Voyager Space Program”

What Happens If You Speedrun Making A CPU?

Usually, designing a CPU is a lengthy process, especially so if you’re making a new ISA too. This is something that can take months or even years before you first get code to run. But what if it wasn’t? What if one were to try to make a CPU as fast as humanly possible? That’s what I asked myself a couple weeks ago.

Left-to-right: Green, orange and red rectangle with 1:2 aspect ratio. Each rectangle further right has 4x the area of its neighbor on the left.
Relative ROM size. Left: Stovepipe, center: [Ben Eater]’s, right: GR8CPU Rev. 2
Enter the “Stovepipe” CPU (I don’t have an explanation for that name other than that I “needed” one). Stovepipe’s hardware was made in under 4 hours, excluding a couple small bugfixes. I started by designing the ISA, which is the simplest ISA I ever made. Instead of continuously adding things to make it more useful, I removed things that weren’t strictly necessary until I was satisfied. Eventually, all that was left were 8 major opcodes and a mere 512 bits to represent it all. That is far less than GR8CPU (8192 bit), my previous in this class of CPU, and still less than [Ben Eater]’s breadboard CPU (2048 bit), which is actually less flexible than Stovepipe. All that while taking orders of magnitude less time to create than either larger CPU. How does that compare to other CPUs? And: How is that possible?
Continue reading “What Happens If You Speedrun Making A CPU?”

Is That A Coaster? No, It’s An LED Matrix!

I’m sure you all love to see some colorful blinkenlights every now and then, and we are of course no exception. While these might look like coasters at a distance, do not be deceived! They’re actually [bitluni]’s latest project!

[bitluni]’s high-fidelity LED matrix started life as some 8×8 LED matrices lying on the shelf for 10 years taunting him – admit it, we’re all guilty of this – before he finally decided to make something with them. That idea took the form of a tileable display with the help of some magnets and pogo pins, which is certainly a very satisfying way to connect these oddly futuristic blinky coasters together.

It all starts with some schematics and a PCB. Because the CH32V208 has an annoying package to solder, [bitluni] opted to have the PCB fab do placement for him. Unfortunately, though, and like any good prototype, it needed a bodge! [bitluni] had accidentally mirrored a chip in the schematic, meaning he had to solder one of the SMD chips on upside-down, “dead bug mode”. Fortunately, the rest was seemingly more successful, because with a little 3D-printed case and some fancy programming, the tiny tiles came to life in all of their rainbow-barfing glory. Sure, the pogo pins were less reliable than desired, but [bitluni] has some ideas for a future version we’re very much looking forward to.

Video after the break.
Continue reading “Is That A Coaster? No, It’s An LED Matrix!”

Creating 1 Um Features The Hacker Way

[Breaking Taps] has done some lithography experiments in the past, including some test patterns and a rudimentary camera sensor. But now, it’s time to turn it up a notch with 1µm garage semiconductor ambitions.

The e-beam lithography he’s done in the past can achieve some impressive resolutions, but they aren’t very fast; a single beam of electrons needs to scan over the entire exposure area, somewhat like a tiny crayon. That’s not very scalable; he needed a better solution to make 1µm semiconductors.

Test patterns from the first attempt

In his quest, he starts by trying to do maskless photolithography, using a literal projector to shine light on the target area all at once. After hacking a projector devkit apart, replacing blue with ultraviolet and adding custom optics, it’s time for a test. The process works for the most part but can’t produce fine details the way [Breaking Taps] needs. Unfortunately, fixing that would mean tearing the whole set-up apart for the umpteenth time.
Continue reading “Creating 1 Um Features The Hacker Way”