Category: Daily Events

Disclaimer: not affiliated with, or endorsed by, ChefSteps or Breville.

While cleaning out some of our kitchen drawers, I found a device that I had nearly forgotten about: the Joule sous vide immersion circulator.

We bought this device years ago, wanting to experiment with sous vide cooking. But now I suddenly remember why we abandoned it so quickly afterwards.

The Joule is a pretty clever device from a hardware perspective. Don’t let the small form factor fool you: it packs 1100 watts of power, which will bring a pot of water to the desired temperature surprisingly quickly.

However, the annoying, obnoxious, frustrating thing about the Joule is, of course, that it requires an app to operate. And the official app is, unfortunately, an abomination. First, it requires you to sign in to your account, because god forbid anyone would want to sous-vide their food anonymously! Then it pairs with the Joule over Bluetooth, then makes your Joule connect to your WiFi network, and only when the Joule is safely linked and synced to your account over WiFi, only then does it start allowing you to make the Joule do its actual job. And this is assuming the app doesn’t crash, or doesn’t randomly disconnect, or the servers aren’t down.

Well, no more of this silliness. With Claude by my side, I knocked out my own app that controls the Joule, purely over Bluetooth, without any further need to connect to WiFi or requiring any accounts. (This was based on some excellent community reverse-engineering work done years ago [1] [2], I just took it the rest of the way.)

I give you… OpenSousVide!

This is a deliberately feature-less app for controlling the Joule. After connecting to the Joule, the app offers two things: a temperature setting, and a Start/Stop button. That’s all it does, because that’s all I need.

Once you press Start, the Joule will start and hold the temperature at the desired level, because that’s the only thing I want it to do. It will keep holding the temperature even if you close the app, or go out of range of the Joule, or turn off your phone entirely.

The app does not have a built-in timer. If you need to run the Joule for a certain amount of time, you can set a timer yourself, using whatever timing technology you like. When the time is up, you can open the app again and press the Stop button. Or you can just unplug the Joule. I don’t care.

If you need to leave your house while the Joule is running, you will not be able to monitor it, because it’s not connected to WiFi, and that is OK. In the old days, people would sometimes leave their house while cooking things in the oven, and would need to weigh the risks of leaving the oven unattended. You, too, must weigh the risk of leaving the Joule running unsupervised.

So, if you have one of these early-generation Joule devices, and were as frustrated as I am by the official app, now you have another option! The app is built in React Native, so it will run on Android or iOS. Visit the repository if you would like to download the app for your Android device. And for iOS, I may publish it on the App Store at some point, but until then you’re welcome to build the app and deploy it to your own iPhone.

One of my favorite articles on Wikipedia is called Timeline of the far future. The entire article is a gigantic table of events that are predicted to occur at various points in the future, based on our current understanding of everything including the environment, geology, physics, and ultimately cosmology and the fate of the universe.

Every single item in this huge table is fascinating to me, and every item can be a jumping-off point into a rabbit hole of exploration into that particular topic. It covers everything from mundane observations about lunar tides slowing down the length of our day over the next thousand years, then sometimes veers into the realm of science fiction with predictions about humanity becoming a Type II and Type III civilization, and eventually ends up in mind-bending time scales like 10¹⁰²⁶ years when all matter will quantum-tunnel into black holes, and beyond.

The only problem with this article is the presentation. It’s so boring! The matter-of-fact, wall-of-text table of events does so little justice to the profound, awe-inspiring insights contained in it. This article deserves so much better! It deserves to be seen, to be savored.

So I decided to kick it up a notch. Being a visual learner myself, and wanting an opportunity to improve my skills with three.js and typescript, I made a “reimagined” version of this article (with the help of my favorite AI assistant), giving it the visual treatment it needs so badly. Here is my take on the Timeline of the far future.

Every event in the timeline is a full-screen slide with the original text copied from the table in the article, but also includes an animation that illustrates what is being described. Many of the animations are my own artisanal code, and many are Claude-assisted but nevertheless verified to the best of my ability for accuracy and consistency.

You can scroll through the slides by scrolling your mouse wheel, or swiping on your mobile device. You can also jump to any event by selecting directly on the timeline ruler at the top.

If you want to share any of the individual slides, click the Share button at the top-right, which copies a link directly to the current slide, like this.

One major limitation of this presentation is that it’s based on one specific revision of the Wikipedia article. The article will almost certainly be edited in the future with new information, updated facts and figures, and many new predictions. My plan for the next iteration of this web app is to adapt dynamically to any new content added to the source article, and update the animations accordingly. Stay tuned, and as always, I welcome your feedback!

Recently I finished building another thing™ that’s been on my mind for a long time. It’s a simulation of a simple real-world environment, except for one important difference: the speed of light in this environment is extremely slowed down to exactly 5 kilometers per hour, a brisk walking speed. With this crucial difference, we’re able to observe relativistic effects at more human scales, thereby developing a better intuition of what actually happens when an observer approaches the speed of light relative to their surroundings.

This was largely inspired by MIT’s OpenRelativity project, which was released around 2012, and is intended for use in the Unity engine. I, however, wanted to make something much more lightweight: plain javascript and WebGL, usable in a web app. I also wanted to make it as physically accurate as possible, while maintaining fairly good performance, paying particular attention to relativistic Doppler effects (redshift, blueshift, transverse effects) and effects from light travel delay such as Terrell rotation and temporal Doppler nuances, the latter of which OpenRelativity seems to neglect.

Naturally I made heavy use of LLMs in building this simulation (Claude Opus 5), but this was only due to my inexperience with OpenGL, not any inexperience with the mathematics of special relativity. In fact, before anyone concludes that LLMs “understand” special relativity, I will note that I had to steer and re-prompt the LLM numerous times with the proper equations to get it to work properly.

Something remarkable about this kind of simulation is that the mathematics is really not very complicated; most of it is high school level algebra. So as long as we get the math right, all of the various effects and strange phenomena emerge automatically. The thing that continues to boggle my mind, and the thing that I appreciate even deeper after finishing this app, is how Einstein could have envisioned this geometry and all its implications from first principles, without the benefit of pretty visualizations. For the rest of us, I hope this visualization can serve as a reminder of how weird our world actually is, at high enough speeds and high enough energies.

Check it out, and let me know if anything appears inaccurate, or if you’d like to see any additional features!

(on Hacker News)
(on Gizmodo)

One of my favorite DOS games from the mid-1990s was Return to Zork. It was a bold departure from the purely text-based Zork games of old, with very nice VGA graphics and a point-and-click interface for interacting with the game’s world. My warm sentiment was not quite shared by my friends at the time, though. Professional critics also gave it mixed reviews, and with good reason.

Let’s just say I love this game more than it deserves. The biggest downfall of the game is the puzzles themselves which are woven through the story of the game. It’s clear that the intention of the creators was to make the puzzles light-hearted and whimsical, but the outcome turned out to be puzzles that are needlessly convoluted, and often frustratingly random.

Many of the puzzles require plain trial and error, seeing if any of the items in your inventory have an effect on your current surroundings. Some inventory items required to complete the game are only available at the very beginning, but if they are not obtained, the game still continues nearly to the end, until you realize that you needed the item all along, and can only obtain it by restarting the whole game. It was hardly possible to complete the game without a printed guide or walkthrough.

And yet, something about the quaintness of the game’s graphics, the corniness of the acting and dialogue, and the genuine technical impressiveness of the game’s engine makes me feel relaxed and at home in the Great Underground Empire. When not engaging with the game’s puzzles, it allows you to stroll freely through the environment in an open-ended way, which I recommend.

When I played the game in the 90s, I recall wanting to “mod” the game, in the sense of tweaking the graphics and sound (e.g. drawing graffiti on the walls of the buildings, inserting myself as one of the characters, and so on), or maybe even changing the script and the outcomes of certain actions.

Well, better late than never:

Now that we can will software into existence, here is a complete toolkit for unpacking all the assets of Return to Zork! Once unpacked, all of the graphics become PNG files, and all of the sounds become WAV files, editable as much as you like. When finished, the toolkit lets you re-pack everything, magically allowing the game to become playable with your new assets!
Look at the README in the repo for a complete breakdown of all the file formats and how they are packaged, as well as complete instructions for unpacking and rebuilding the game.

The end result? Here is me “standing in” for the character of Moadikum Moodock, the arms dealer who teaches the Player character how to play the mini-game of Survivor, vitally important for defeating the final boss Morphius:

Sorry you had to see that; it’s just a weird way in which I’ve always wanted to immerse myself in this game. No offense meant to the actor who actually portrayed Moodock (Ernie Lively, RIP) (yes, he was the father of Blake Lively!). This is meant purely as an homage, a love letter, to such a memorable character. His delivery of the line “Pull up a chair, and I’ll teach it to you!” is something I still quote to this day.
Care to try it yourself? ‘Course you do!

For my next trick frivolous use of LLMs, I’m building an emulated tape drive!

TLDR: The 86Box emulator now allows you to emulate a QIC-117 tape drive connected to the floppy controller, or to a parallel port, and make “backups” to virtual tape images using actual DOS and early Windows-era backup software.

I’ve always been rather obsessed with emulators. I have an extensive collection of bootable disk images that contain virtually every version of DOS, Windows, Mac System versions, Amiga OS, various Unixes, and other more obscure OSes, all ready to run at the click of an icon.

One of my favorite emulators for emulating DOS and early Windows-based systems is 86Box, which is an evolution of the great PCEm emulator. 86Box is a very “low-level” emulator that actually executes the BIOS ROM of various chipsets, and emulates a plethora of devices and peripherals very faithfully. 86Box also happens to be refreshingly accessible for developing and extending.

For a while I’ve had this idea in the back of my mind to combine two of my obsessions: emulation and tape media. Wouldn’t it be neat if we could emulate a tape drive, with a virtual tape cartridge, reading from a virtual tape image file? As far as I know, there are no emulators currently available that emulate a QIC tape drive (specifically QIC-80 and its later cousins like QIC-3020).

I deal with recovering data from QIC tapes on a regular basis. And as someone who cares about digital preservation, I always make sure to obtain a complete binary image of the tape, so that it might be possible to reproduce the image onto a different tape, exactly as the original backup software would have written it. (Side note: a truly “proper” preservation of a tape would be to save the actual flux transitions, instead of the higher-level binary bytes, but that’s a subject for a future post.)

And so, with the binary tape images in hand, it would be great to “close the loop” by allowing the original backup software, running in an emulator, to read these tapes by believing that it’s communicating with a real tape drive. Fortunately we are living in a time when one person’s backlog can become their AI agent’s top priority.

These QIC tape drives, such as the Colorado 250, Travan, and so on, communicate over the floppy controller using a special protocol called QIC-117. The complete specification of this protocol is readily available on the web. You would think, therefore, that all that’s necessary is for our emulated drive to implement the entire QIC-117 spec, and all will be well.

Sadly that’s not quite the case. In addition to all the standard QIC-117 functions, the spec allows for manufacturer-specific “diagnostic” commands that basically open the spec up to completely arbitrary behavior that the manufacturer desires. And indeed, the manufacturers make generous use of these diagnostic commands, particularly in the detection phase of when the host driver wants to determine the type of drive that is connected.

With just the bare QIC-117 spec implemented, which took Claude Opus 5 just three or four prompts to complete, only a single backup utility for MS-DOS would agree to detect and read from the drive, namely HP Colorado Backup 7 (QBACKUP). This was actually the first utility I tried, which initially gave me false hope, because afterwards I started realizing that different utilities employ wildly different ways of detecting these drives, and QBACKUP happened to employ the least manufacturer-specific trickery.

When I tried using tools like Microsoft Backup for Windows 95, for example, I noticed it putting the drive into diagnostic mode and attempting to issue manufacturer-specific commands. Since I was emulating a Colorado drive (the QIC-117 spec requires the drive to reply with a “vendor code” from a predefined list of known vendors), MS Backup was clearly trying to do Colorado-specific things with the drive, which are not documented anywhere.

There are two ways we could uncover what the diagnostic functions do: we could connect a real Colorado drive and attempt to monitor the traffic that goes across a real floppy controller, or…

We could unsolder the ROM chip from the drive, perform a disassembly of the ROM, and get a complete understanding of all the commands that the drive supports, including all the diagnostic bits!

Armed with nothing more than a dump of the ROM and a photo of the PC board, I told Claude to “see what you can do with this”, and it obediently disassembled the ROM and laid out exactly what custom commands the drive supports, and exactly how the drive deviates from the spec for certain standard commands. Have a look at the repo where I put the resulting analysis of the ROM disassembly from the Colorado drive, as well as a few other related drives in my collection. You’ll find all of these rather interesting tidbits in the repo:

• A FINDINGS.md document with an extremely detailed breakdown of all the commands supported by the drive, including some very interesting possibilities for future work in enabling the drive to read tapes that were previously believed to be unreadable, as well as enabling a custom controller, such as a Greaseweazle, to control the drive and read the raw flux transitions, for truly proper digital preservation.
• Disassembler (written in Python) for the Intel 8051 processor, which is the main IC that controls the drive. There is also a disassembler for the Zilog Z8 processor, used by a couple of the other drives. Both of these disassemblers were thrown together by the LLM as an effortless prerequisite for its work.

This filled in all the missing pieces necessary to complete the emulated QIC-117 drive, now usable in 86Box:

Afterwards, for the sake of completeness, I also implemented support for a parallel port version of these drives (LPT port with EPP), which emulates an Iomega Ditto drive. This drive is actually a QIC-117 drive internally, but contains an extra chip that allows it to communicate over the parallel port using a protocol called Backpack, developed by MicroSolutions.

The Iomega Ditto 2GB drive in particular is one of my go-to drives for reading QIC cartridges, because of its excellent backwards compatibility with older cartridges, being able to read not only the first-party Ditto cartridges, but other smaller-capacity tapes like Travan, QIC-3020, all the way down to QIC-2080. All of these are now supported as emulated cartridges in 86Box, when configuring your emulated Ditto drive on the parallel port.

One minor quirk is that Ditto cartridges always came pre-formatted, and there’s no way for the end user to format a completely blank tape image. Therefore I made a repository of pre-formatted tape images for you to download and use for yourself. The repository also contains a Python script that lets you generate a tape image with your desired capacity and custom label. Have fun!