Modern fertilizer manufacturing uses the Haber-Bosch and Ostwald processes to fix aerial nitrogen as ammonia, then oxidize the ammonia to nitric acid. Having already created a Haber-Bosch reactor for ammonia production, [Markus Bindhammer] took the obvious next step and created an Ostwald reactor to make nitric acid.

[Markus]’s first step was to build a sturdy frame for his apparatus, since most inexpensive lab stands are light and tip over easily – not a good trait in the best of times, but particularly undesirable when working with nitrogen dioxide and nitric acid. Instead, [Markus] built a frame out of aluminium extrusion, T-nuts, threaded rods, pipe clamps, and a few cut pieces of aluminium.

Once the frame was built, [Markus] mounted a section of quartz glass tubing above a gas burner intended for camping, and connected the output of the quartz tube to a gas washing bottle. The high-temperature resistant quartz tube held a mixture of alumina and platinum wool (as we’ve seen him use before), which acted as a catalyst for the oxidation of ammonia. The input to the tube was connected to a container of ammonia solution, and the output of the gas washing bottle fed into a solution of universal pH indicator. A vacuum ejector pulled a mixture of air and ammonia vapors through the whole system, and a copper wool flashback arrestor kept that mixture from having explosive side reactions.

After [Markus] started up the ejector and lit the burner, it still took a few hours of experimentation to get the conditions right. The issue seems to be that even with catalysis, ammonia won’t oxidize to nitrogen oxides at too low a temperature, and nitrogen oxides break down to nitrogen and oxygen at too high a temperature. Eventually, though, he managed to get the flow rate right and was rewarded with the tell-tale brown fumes of nitrogen dioxide in the gas washing bottle. The universal indicator also turned red, further confirming that he had made nitric acid.

Thanks to the platinum catalyst, this reactor does have the advantage of not relying on high voltages to make nitric acid. Of course, you’ll still need get ammonia somehow.

For those of us who aren’t blessed with a green thumb and who are perhaps a bit forgetful, plants can be surprisingly difficult to keep alive. In those cases, some kind of automation, such as [Justin Buchanan]’s Oasis smart terrarium, is a good way to keep our plants from suffering too much.

The Oasis has an ultrasonic mister to water the plants from a built-in tank, LED grow lights, fans to control airflow, and a temperature and humidity sensor. It connects to the local WiFi network and can set up recurring watering and lighting schedules based on network time. Most of the terrarium is 3D-printed, with a section of acrylic tubing providing the clear walls. Before installing the electronics, it’s a good idea to waterproof the printed parts with low-viscosity epoxy, particularly since the water tank is located at the top of the terrarium, where a leak would drip directly onto the control electronics.

An ESP32-C3 controls the terrarium; it uses a MOSFET circuit to drive the ultrasonic mister, an SHT30 sensor to measure humidity and temperature, and a PWM driver circuit to control the LEDs. Conveniently, [Justin] also wrote a piece of command-line client software that can find online terrariums on the local network, configure WiFi, set the terrarium’s schedule, control its hardware, and retrieve data from its sensors. Besides this, Oasis also exposes a web interface that performs the same functions as the command-line client.

This isn’t the first automated terrarium we’ve seen, though it is the most aesthetically refined. They aren’t just for plants, either; we’ve seen a system to keep geckos comfortable.

[Ruud], the creator of [Capturing Dust], started his latest video with what most of us would consider a solved problem: the dust collection system for his shop already had a three-stage centrifugal dust separator with more than 99.7% efficiency. This wasn’t quite as efficient as it could be, though, so [Ruud]’s latest upgrade shrinks the size of the third stage while increasing efficiency to within a rounding error of 99.9%.

The old separation system had two stages to remove large and medium particles, and a third stage to remove fine particles. The last stage was made out of 100 mm acrylic tubing and 3D-printed parts, but [Ruud] planned to try replacing it with two parallel centrifugal separators made out of 70 mm tubing. Before he could do that, however, he redesigned the filter module to make it easier to weigh, allowing him to determine how much sawdust made it through the extractors. He also attached a U-tube manometer (a somewhat confusing name to hear on YouTube) to measure pressure loss across the extractor.

The new third stage used impellers to induce rotational airflow, then directed it against the circular walls around an air outlet. The first design used a low-profile collection bin, but this wasn’t keeping the dust out of the air stream well enough, so [Ruud] switched to using plastic jars. Initially, this didn’t perform as well as the old system, but a few airflow adjustments brought the efficiency up to 99.879%. In [Ruud]’s case, this meant that of 1.3 kilograms of fine sawdust, only 1.5 grams of dust made it through the separator to the filter, which is certainly impressive in our opinion. The design for this upgraded separator is available on GitHub.

[Ruud] based his design off of another 3D-printed dust separator, but adapted it to European fittings. Of course, the dust extractor is only one part of the problem; you’ll still need a dust routing system.

Thanks to [Keith Olson] for the tip!

As far as giving mechanical instruments electronic control goes, drums are probably the best candidate for conversion; learning to play them is challenging and loud for a human, but they’re a straightforward matter for a microcontroller. [Jeremy Cook]’s latest project takes this approach by using an Arduino Opta to play a tongue drum.

[Jeremy]’s design far the drum controller was inspired by the ring-shaped arrangement of the Cray 2 supercomputer. A laser-cut MDF frame forms a C-shape around the tongue drum, and holds eight camera mount friction arms. Each friction arm holds a solenoid above a different point on the drum head, making it easy to position them. A few supports were 3D-printed, and some sections of PVC tubing form pivots to close the ring frame. [Jeremy] found that the the bare metal tips of the solenoids made a harsh sound against the drum, so he covered the tips of six solenoids with plastic caps, while the other two uncoated tips provide an auditory contrast.

The Arduino Opta is an open-source programmable logic controller normally intended for industrial automation. Here, its silent solid-state relays drive the solenoids, as [Jeremy]’s done before in an earlier experiment. The Opta is programmed to accept MIDI input, which [Jeremy] provided from two of the MIDI controllers which we’ve seen him build previously. He was able to get it working in time for the 2024 Orlando Maker Faire, which was the major time constraint.

Of course, for a project like this you need a MIDI controller, and we’ve previously seen [Jeremy] convert a kalimba into such a controller. We’ve seen this kind of drum machine at least once before, but it’s more common to see a purely electronic implementation.

If you’ve put in all the necessary practice to learn bike tricks, you’d probably like an appropriately dramatic soundtrack to accompany your stunts. A team of students working on a capstone project at the University of Washington took this natural desire a step further with the Music Bike, a system that generates adaptive music in response to the bike’s motion.

The Music Bike has a set of sensors controlled by an ESP32-S3 mounted beneath the bike seat. The ESP32 transmits the data it collects over BLE to an Android app, which in turn uses the FMOD Studio adaptive sound engine to generate the music played. An MPU9250 IMU collects most position and motion data, supplemented by a hall effect sensor which tracks wheel speed and direction of rotation.

When the Android app receives sensor data, it performs some processing to detect the bike’s actions, then uses these to control FMOD’s output. The students tried using machine learning to detect bike tricks, but had trouble with latency and accuracy, so they switched to a threshold classifier. They were eventually able to detect jumps, 180-degree spins, forward and reverse motion, and wheelies. FMOD uses this information to modify music pitch, alter instrument layering, and change the track. The students gave an impressive in-class demonstration of the system in the video below (the demonstration begins at 4:30).

Surprisingly enough, this isn’t the first music-producing bike we’ve featured here. We’ve also seen a music-reactive bike lighting system.

Thanks to [Blake Hannaford] for the tip!

For quite some time now, Marlin has been the firmware of choice for any kind of custom 3D printer, with only Klipper offering some serious competition in the open-source world. [Liam Powell] aims to introduce some more variety with the development of Prunt, a 3D printer control board and firmware stack.

Smooth motion control is Prunt’s biggest advantage: Klipper and Marlin use trapezoidal (three-phase) motion profiles, which aim for acceleration changes with physically impossible rapidity, leading to vibrations and ringing on prints. By contrast, Prunt uses a more physically realistic 31-phase motion profile. This lets the user independently adjust velocity, acceleration, jerk, snap, and crackle (the increasingly higher-order derivatives of position with respect to time) to reduce vibration and create smoother prints. To avoid sharp accelerations, Prunt can also turn corners into 15-degree Bézier curves.

The focus on smooth motion isn’t just a software feature; the Prunt control board uses hardware timers to control step generation, rather than the CPU. This avoids the timing issues which Klipper sometimes faces, and avoids slowing other parts of the program down. The board also seems to have a particular focus on avoiding electrical damage. It can detect short circuits in the heaters, thermistors, fans, and endstops, and can cut power and give the user a warning when one occurs. If the board somehow experiences a serious electrical fault, the USB port is isolated to prevent damage to the host computer. The firmware’s source is available on GitHub.

If you’re more interested in well-established programs, we’ve given a quick introduction to Klipper in the past. We’ve also seen people develop their own firmware for the Bambu Lab X1.

During Apple’s late-90s struggles with profitability, it made a few overtures toward licensing its software to other computer manufacturers, while at the same time trying to modernize its operating system, which was threatening to slip behind Windows. While Apple eventually scrapped their licensing plans, an interesting product of the situation was Rhapsody OS. Although Apple was still building PowerPC computers, Rhapsody also had compatibility with Intel processors, which [Omores] put to good use by running it on a relatively modern i7-3770 CPU.

[Omores] selected a Gigabyte GA-Z68A-D3-B3 motherboard because it supports IDE emulation for SATA drives, a protocol which Rhapsody requires. The operating system installer needs to run from two floppy disks, one for boot and one for drivers. The Gigabyte motherboard doesn’t support a floppy disk drive, so [Omores] used an older Asus P5E motherboard with a floppy drive to install Rhapsody onto an SSD, then transferred the SSD to the Gigabyte board. The installation initially had a kernel panic during installation caused by finding too much memory available. Limiting the physical RAM available to the OS by setting the maxmem value solved this issue.

After this, the graphical installation went fairly smoothly. A serial mouse was essential here, since Rhapsody doesn’t support USB. It detected the video card immediately, and eventually worked with one of [Omores]’s ethernet cards. [Omores] also took a brief look at Rhapsody’s interface. By default, there were no graphical programs for web browsing, decompressing files, or installing programs, so some command line work was necessary to install applications. Of course, the highlight of the video was the installation of a Doom port (RhapsoDoom).

This isn’t the first obscure Apple operating system we’ve seen; some of them have even involved updates to Apple’s original releases. We’ve also seen people build Apple hardware.

Thanks to [Stephen Walters] for the tip!

Most people know that they shouldn’t plug strange flash drives into their computers, but what about a USB cable? A cable doesn’t immediately register as an active electronic device to most people, but it’s entirely possible to hide a small, malicious microcontroller inside the shell of one of the plugs. [Joel Serna Moreno] and some collaborators have done just that with their Evil Crow Cable-Wind.

This cable comes in two variants: one USB-A to USB-C, and one with USB-C to USB-C. A tiny circuit board containing an ESP32-S3 hides inside a USB-C plug on each cable, and can carry out a keystroke injection attack. The cable’s firmware is open-source, and has an impressive set of features: a payload syntax checker, payload autocompletion, OS detection, and the ability to impersonate the USB device of your choice.

The cable provides a control interface over WiFi, and it’s possible to edit and deploy live payloads without physical access to the cable (this is where the syntax checker should be particularly useful). The firmware also provides a remote shell for computers without a network connection; the cable opens a shell on the target computer which routes commands and responses through the cable’s WiFi connection (demonstrated in the video below).

The main advantage of the Evil Crow Cable Wind is its price: only about $25, at which point you can afford to lose a few during deployment. We’ve previously seen a malicious cable once before. Of course, these attacks aren’t limited to cables and USB drives; we’ve seen them in USB-C docks, in a gaming mouse, and the fear of them in fans.

Thanks to [rustysun9] for the tip!

Both small children and cats have a certain tendency to make loud noises at inopportune times, but what if there were a way to combine these auditory effects? This seems to have been the reasoning behind the creation of the Meowsic keyboard, a children’s keyboard that renders notes as cats’ meows. [Steve Gilissen], an appreciator of unusual electronic instruments, discovered that while there had been projects that turned the Meowsic keyboard into a MIDI output device, no one had yet added MIDI input to it, which of course spurred the creation of his Meowsic MIDI adapter.

The switches in the keys of the original keyboard form a matrix of rows and columns, so that creating a connection between a particular row and column plays a certain note. [Steve]’s plan was to have a microcontroller read MIDI input, then connect the appropriate row and column to play the desired note. The first step was to use a small length of wire to connect rows and columns, thus manually mapping connections to notes. After this tedious step, he designed a PCB that hosts an Arduino Nano to accept input, two MCP23017 GPIO expanders to give it enough outputs, and CD4066BE CMOS switches to trigger the connections.

[Steve] was farsighted enough to expect some mistakes in the PCB, so he checked the connections before powering the board. This revealed a few problems, which some bodge wires corrected. It still didn’t play during testing, and after a long debugging session, he realized that two pins on an optoisolator were reversed. After fixing this, it finally worked, and he was able to create the following video.

Most of the MIDI hacks we’ve seen involved creating MIDI outputs, including one based on a Sega Genesis. We have seen MIDI input added to a Game Boy, though.

Most of us spend our lives within reach of a device that provides a clock, stopwatch, and a timer – you’re almost certainly reading this article on such a device – but there are fewer options if you want a screen-free clock. [Michael Suguitan]’s TOKIDOKI rectifies this situation by combining those three functions into a single, physical, analog clock face.

More after the break…

TOKIDOKI displays time by lighting the appropriate segments of two concentric rings of colored LEDs (Adafruit Neopixel rings); the inner ring indicates hours, while the outer ring displays minutes. There is one clock hand, and while it does indicate the passage of time in some situations, its main function is as a dial to control the clock’s different functions. The hand is connected to a Dynamixel XL-330 servo motor, which also serves as a position sensor. Winding the dial clockwise starts a countdown timer, with each successive full rotation switching to a larger unit of time (a fun/unsettling feature is that the largest chronometric unit is the user’s expected lifetime: 84 years). Winding counterclockwise either starts a stopwatch or sets an alarm, depending on how many full rotations you make.

A Raspberry Pi Pico running some MicroPython firmware manages the device and gets the current time from a local network. To soften the light’s quality, the LED rings are pointed backwards to provide back-lighting off of a recessed surface. The entire device is powered by USB-C, and is enclosed in a 3D-printed housing.

This project was designed as an experiment in minimal interfaces, and it certainly achieved that goal, though we imagine that it takes a bit of time to get used to using this clock. We always enjoy seeing innovative clocks here, from digital to analogue, and those that split the difference.

Despite the repeated warnings of system administrators, IT personnel, and anyone moderately aware of operational security, there are still quite a few people who will gladly plug a mysterious flash drive into their computers to see what’s on it. Devices which take advantage of this well-known behavioral vulnerability have a long history, the most famous of which is Hak5’s USB Rubber Ducky. That emulates a USB input device to rapidly execute attacker-defined commands on the target computer.

The main disadvantage of these keystroke injection attacks, from the attacker’s point of view, is that they’re not particularly subtle. It’s usually fairly obvious when something starts typing thousands of words per minute on your computer, and the victim’s next move is probably a call to IT. This is where [Krzysztof Witek]’s open-source Rubber Ducky clone has an advantage: it uses a signal detected by a SYN480R1 RF receiver to trigger the deployment of its payload. This does require the penetration tester who uses this to be on the site of the attack, but unlike with an always-on or timer-delayed Rubber Ducky, the attacker can trigger the payload when the victim is distracted or away from the computer.

This project is based around the ATmega16U2, and runs a firmware based on microdevt, a C framework for embedded development which [Krzysztof] also wrote. The project includes a custom compiler for a reduced form of Hak5’s payload programming language, so at least some of the available DuckyScript programs should be compatible with this. All of the project’s files are available on GitHub.

Perhaps due to the simplicity of the underlying concept, we’ve seen a few open source implementations of malicious input devices. One was even built into a USB cable.

It’s a problem that few of us will ever face, but if you ever have to calibrate your scanning electron microscope, you’ll need a resolution target with a high contrast under an electron beam. This requires an extremely small pattern of alternating high and low-density materials, which [ProjectsInFlight] created in his latest video by depositing gold nanoparticles on a silicon slide.

[ProjectsInFlight]’s scanning electron microscope came from a lab that discarded it as nonfunctional, and as we’ve seen before, he’s since been getting it back into working condition. When it was new, it could magnify 200,000 times and resolve features of 5.5 nm, and a resolution target with a range of feature sizes would indicate how high a magnification the microscope could still reach. [ProjectsInFlight] could also use the target to make before-and-after comparisons for his repairs, and to properly adjust the electron beam.

Since it’s easy to get very flat silicon wafers, [ProjectsInFlight] settled on these as the low-density portion of the target, and deposited a range of sizes of gold nanoparticles onto them as the high-density portion. To make the nanoparticles, he started by dissolving a small sample of gold in aqua regia to make chloroauric acid, then reduced this back to gold nanoparticles using sodium citrate. This gave particles in the 50-100 nanometer range, but [ProjectsInFlight] also needed some larger particles. This proved troublesome for a while, until he learned that he needed to cool the reaction temperature solution to near freezing before making the nanoparticles.

Using these particles, [ProjectsInFlight] was able to tune the astigmatism settings on the microscope’s electron beam so that it could clearly resolve the larger particles, and just barely see the smaller particles – quite an achievement considering that they’re under 100 nanometers across!

Electron microscopes are still a pretty rare build, but not unheard-of. If you ever find one that’s broken, it could be a worthwhile investment.

The Functionalist design philosophy that Dieter Rams brought to Braun from the 50s to the 90s still inspires the look of a few devices, including Apple’s iPod, Teenage Engineer’s synthesizers and recorders – and [2dom]’s IR7 streaming radio.

The streaming radio was inspired by Braun’s portable radios, particularly the SK2, TP1, and the T3 pocket radio. [2dom] started with the T3’s circular pattern of holes and experimented with several variations, finally settling on a cylindrical shape with a central display; a prototype with a low-power monochrome rectangular display was eventually rejected in favor of a circular LCD. The housing consists of four 3D-printed components: an upper and lower shell, a resonator for the speaker, and a knob for a rotary encoder.

Electronics-wise, an ESP32 handles the computing requirements, while the LCD and rotary encoder provide a user interface. For audio, it uses a VS1053 MP3 decoder, PAM8403 amplifier, and a wideband speaker, with an audio isolation transformer to clean up the audio. To reduce power consumption, a MOSFET cuts power to the peripheral components whenever the device is in sleep mode. The full design is available on GitHub.

The end result of this effort is a quite authentic-looking 21st-century adaptation of Rams’s original designs. If you’re interested in more Braun designs, check out this replica of one of their desk fans. We’ve also seen a restoration of one of Braun’s larger radios, the TS2.

For all the remarkable improvements we’ve seen in desktop 3D printers, metal printers have tended to stay out of reach for hackers, mostly because they usually rely on precise and expensive laser systems. This makes it all the more refreshing to see [Dan Gelbart]’s demonstration of Rapidia’s cast-to-sinter method, which goes from SLA prints to ceramic or metal models.

The process began by printing the model in resin, scaled up by 19% to account for shrinkage. [Dan] then used the resin print to make a mold out of silicone rubber, after first painting the model to keep chemicals from the resin from inhibiting the silicone’s polymerization. Once the silicone had set, he cut the original model out of the mold and prepared the mold for pouring. He made a slurry out of metal powder and a water-based binder and poured this into the mold, then froze the mold and its contents at -40 ℃. The resulting mixture of metal powder and ice forms a composite much stronger than pure ice, from which [Dan] was able to forcefully peel back the silicone mold without damaging the part. Next, the still-frozen part was freeze-dried for twenty hours, then finally treated in a vacuum sintering oven for twelve hours to make the final part. The video below the break shows the process.

A significant advantage of this method is that it can produce parts with much higher resolution and better surface finish than other methods. The silicone mold is precise enough that the final print’s quality is mostly determined by the fineness of the metal powder used, and it’s easy to reach micron-scale resolution. The most expensive part of the process is the vacuum sintering furnace, but [Dan] notes that if you only want ceramic and not metal parts, a much cheaper ceramic sintering oven will work better.

We’ve seen sintering-based metal printers a few times before, as well a few more esoteric methods. We’ve also covered a few of [Dan]’s previous videos on mechanical prototyping methods and building a precision CNC lathe.

Thanks to [Eric R Mockler] for the tip!

Usually when we see a project using a software-defined radio (SDR), the SDR’s inputs and outputs are connected to antennae, but [FromConceptToCircuit]’s project connected an ADALM-Pluto SDR to an RF bridge and a few passive components to make a surprisingly effective network analyzer (part two of the video).

The network analyzer measures two properties of the circuit to which it is connected: return loss (S11) and insertion gain or loss (S21). To measure S21, the SDR feeds a series of tones to the device under test, and reads the device’s output from one of the SDR’s inputs. By comparing the amplitude of the input to the device’s output, a Python program can calculate S21 over the range of tested frequencies. To find S11, [FromConceptToCircuit] put an RF bridge in line with the device being tested and connected the bridge’s output to the SDR’s second input. This allowed the program to calculate the device’s impedance, and from that S11.
The RF bridge and other components introduce some inaccuracies to the measurements, so before making any other measurements, the system is calibrated with both a through connection and an open circuit in place of the tested device. The RF bridge’s directivity was the biggest limiting factor; transfer back from the bridge’s output line caused the reflection under load to exceed the reflection of an open circuit in some frequency ranges, at which point the analyzer couldn’t accurately operate.

[FromConceptToCircuit] was eventually able to make measurements throughout most of the 0.1-3 GHz range with a dynamic range of at least 10 dB, and expects a more directive RF bridge to give even better results. If you’d like to repeat the experiment, he’s made his Python program available on GitHub.

We’ve previously seen [FromConceptToCircuit] use the Pluto SDR to make a spectrum analyzer. We’ve also featured a guide to the Pluto, covered a project that improved its frequency stability, and seen it used to transmit video.

For some people (e.g. this author) solder wick is a tool of last resort. Unfortunately, solder suckers and vacuum pumps lose most of their utility when you move from through-hole to SMD components, forcing us to use the dreaded wick. For those of us in this mindset, [nanofix]’s recent video which we’ve placed below the break on tips for solder wick could make desoldering a much less annoying experience.

Most of the tips have to do with maintaining proper control of heat flow and distribution. [nanofix]’s first recommendation is to cut off short segments of wick, rather than using it straight from the roll, which reduces the amount of heat lost to conduction along the rest of the length. It’s also important to maintain a certain amount of solder on the soldering iron’s tip to improve conduction between the tip and the wick, and to periodically re-tin the tip to replace absorbed solder. Counterintuitively, [nanofix] explains that a low temperature on the soldering iron is more likely to damage the board than a high temperature, since solder wick getting stuck to a pad risks tearing the traces.

[nanofix] also notes that most boards come from the factory with lead-free solder, which has a higher melting point than tin-lead solder, and thus makes it harder to wick. He recommends first adding eutectic lead-based solder to the pads, then wicking away the new, lower melting-point mixture. Other miscellaneous tips include cutting a more precise tip into pieces of wick, always using flux, avoiding small soldering iron tips, and preheating the board with hot air.

We’ve seen a couple of guides to desoldering before. If you’re looking for more exotic methods for easing the task, you can always use bismuth.

It would be hard to find any electronics still in production which use CRT displays, but for some inscrutable reason it’s easy to find cheap 4-inch CRTs on AliExpress. Not that we’re complaining, of course. Especially when they get picked up for projects like this Retro CRT Weather Display from [Conrad Farnsworth], which recreates the interface of The Weather Channel’s WeatherStar 4000+ in a suitably 90s-styled format.

The CRT itself takes up most of the space in the enclosure, with the control electronics situated in the base behind the display driver. A Raspberry Pi Zero W provides the necessary processing power, and connects to the CRT through its composite video output.

A custom PCB plugs into the GPIO header on the Raspberry Pi and provides some additional features, such as a rotary encoder for volume and brightness display, a control button, a serial UART interface, and a speaker driver. The design still has one or two caveats: it’s designed to powered by USB, but [Conrad] notes that it draws more current than USB 2.0 can provide, though USB-C should be able to keep up.

On the software side, a Python program displays a cycle of three slides: local weather, regional weather, and a radar display. For the local and regional weather display graphics, [Conrad] created a static background image containing most of the graphics, and the program only generated the dynamic components. For the radar display, the regional map’s outlines come from Natural Earth, and a Python program overlays radar data on them.

We’ve seen other attempts at recreating the unique style of the WeatherStar system, but nothing quite beats the real thing.

It’s not often that we can include an operating system in a Hackaday article, but here’s the full 46-byte source of [Philippe Brochard]’s 10biForthOS in 8086 opcodes:

50b8 8e00 31d8 e8ff 0017 003c 0575 00ea
5000 3c00 7401 eb02 e8ee 0005 0588 eb47
b8e6 0200 d231 14cd e480 7580 c3f4

Admittedly, this is quite a minimal operating system. It’s written for the Intel 8086, and consists of a Forth implementation with only two instructions: compile (1) and execute (0). It can receive commands over a serial connection or from a keyboard. This allows a host computer to load more complex software onto it, one byte at a time. In particular, [Philippe] provides instructions for loading more advanced compilers, such as subleq-eForth for a more complete Forth implementation, or SectorC for C programming. He’s also written a 217-byte port of the OS to Linux Intel x64.

[Philippe] doesn’t take a strong stance on whether this should technically qualify as a Forth implementation, given that the base implementation lacks stacks, dictionaries, and the ability to define words. However, it does have an outer and inner interpreter, the ability to compile and execute code, and most importantly, “the simplicity and hacky feeling of Forth.”

[Philippe] writes that this masterpiece of minimalism continues the tradition of the minimal Forth implementations we’ve covered before. We’ve even seen Forth run on an Arduino.

It’s hard to imagine now, but in the mid-1980s, the Internet came close to collapsing due to the number of users congesting its networks. Computers would request packets as quickly as they could, and when a router failed to process a packet in time, the transmitting computer would immediately request it again. This tended to result in an unintentional denial-of-service, and was degrading performance significantly. [Navek]’s recent video goes over TCP congestion control, the solution to this problem which allows our much larger modern internet to work.

In a 1987 paper, Van Jacobson described a method to restrain congestion: in a TCP connection, each side of the exchange estimates how much data it can have in transit (sent, but not yet acknowledged) at any given time. The sender and receiver exchange their estimates, and use the smaller estimate as the congestion window. Every time a packet is successfully delivered across the connection, the size of the window doubles.

Once packets start dropping, the sender and receiver divide the size of the window, then slowly and linearly ramp up the size of the window until it again starts dropping packets. This is called additive increase/multiplicative decrease, and the overall result is that the size of the window hovers somewhere around the limit. Any time congestion starts to occur, the computers back off. One way to visualize this is to look at a graph of download speed: the process of periodically hitting and cutting back from the congestion limit tends to create a sawtooth wave.

[Navek] notes that this algorithm has rather harsh behavior, and that there are new algorithms that both recover faster from hitting the congestion limit and take longer to reach it. The overall concept, though, remains in widespread use.

If you’re interested in reading more, we’ve previously covered network congestion control in more detail. We’ve also covered [Navek]’s previous video on IPV5.

Thanks to [Mahdi Naghavi] for the tip!