Ronan Gaillard's Workshop

Teaching my Fujifilm X-T30 II to Print on an instax Link 3

Fri, 06 Nov 2026 22:00:00 +0100

Adding Bluetooth instax printing to a Fujifilm camera that never had it, and finding a bug in Fuji’s firmware along the way

The Problem

I travel with a Fujifilm X-T30 II and a small instax mini Link 3 printer, which I bought during a trip to China. I like giving prints to people I meet, or slipping them into postcards. I also like to travel without my phone as much as I can. But today the phone is the middleman: copy the photo to it, open the instax app, print from there. It works, but it is slow and it kills the fun.

Naively, I thought a fairly recent Fujifilm camera would print to it natively. I had even seen the “instax printer print” entry in the menus. It doesn’t. The X-T30 II only knows the old Wi-Fi printers (SP-1, SP-2, SP-3). Newer ones like the Link 3 use a different protocol over Bluetooth LE. Fujifilm added it to newer cameras like the X-S10, never to mine. And mine is already on its latest firmware, so no update is coming.

So the only way was to change the firmware. I had never looked at camera firmware before.

Rule zero: don’t brick the camera

Before anything, I set a few rules. A bricked camera is an expensive paperweight, and people in the community have bricked bodies by poking at random memory addresses.

I never write to the flash, the memory chip where the camera keeps its firmware. Everything runs in RAM, so pulling the battery brings back the stock camera. Every write to the camera needs my explicit OK, and the original bytes are checked first. I prefer reading files on the Mac over probing the camera. And I don’t waste film, because an instax sheet costs about a euro.

These rules made the project slower, but I never had a moment of panic.

Step 1: Opening the firmware

Fujifilm publishes firmware updates on its website, one .DAT file per camera. The format isn’t documented, but FujiHack had already done part of the work on older bodies.

Unpacking it took three steps. First, cut the header. The first bytes are an ID card for the file: camera model, version, checksums. The code comes after. Then, flip every bit: every 0 becomes a 1 and every 1 a 0. That’s all the “encryption” there is. Finally, decompress. What’s left is four compressed blocks. Fuji uses its own flavour of LZ, the classic trick behind ZIP: when a sequence of bytes repeats, it isn’t stored again but replaced by “copy 20 bytes from 300 bytes back”.

I wrote a small Python script, fujifw.py, that does all three. To check it, I had a free test: the firmware contains some well-known data tables from zlib, a public compression library. If they come out byte for byte identical to the published ones, the decompression is right.

Three of the blocks are machine code for the camera’s processor (an ARM Cortex-A7 running ThreadX, a small real-time OS). Machine code is just bytes. To read it I used Ghidra, a free reverse engineering tool released by the NSA. You give it a binary, it finds the functions and turns the bytes into assembly, then into C-like code. No names, no comments, but readable.

Ghidra first needs to know where each block sits in the camera’s memory. The firmware doesn’t say, so I had to work it out. The code is full of pointers to text messages. If I guess the wrong starting address for a block, those pointers land in the middle of nowhere. There is only one starting address where they all land on the start of a real message. With that, Ghidra found about 59,000 functions. I ran it from scripts instead of its interface, so Claude could ask it for any function directly.

Step 2: The code was already there

59,000 functions with no names is a lot. But I had a trick: the X-S10 uses the same processor and does print to Link printers. So I unpacked its firmware too and compared the two.

First I had to find the print code in the X-S10, among its own tens of thousands of nameless functions. Strings gave it away. The instax Link service has a known Bluetooth ID (a 128-bit UUID), published by the people who reverse engineered the protocol, and it appears in the X-S10 firmware. The code that uses it sits next to a task called instaxbt and debug markers like INSXSe or INSXPt, and it builds packets starting with the instax header. That’s the Bluetooth part. Then I listed every function that calls into it, and the functions around those: that’s the print app, 176 functions in one block.

I wrote a fuzzy matcher. It compares whole functions and ignores the addresses inside them, which change from one build to another (more on that later). I ran it on the 176 functions of the X-S10 print code. 109 of them had a twin in my camera that was at least 90% identical.

That was the big surprise: the X-T30 II already contains Fujifilm’s Bluetooth print app. Cropping, rotation, JPEG encoding, progress screens, it’s all there. Only the bottom layer, the part that talks to the printer over Bluetooth, was left out when Fuji built this firmware. In its place are empty functions, stubs that just return 0.

Even better, the camera already knows how to drive a Bluetooth device. Bluetooth LE (Low Energy) is the low-power flavour of Bluetooth used by watches, sensors and printers like the Link 3. In every connection one side is the central, which scans, connects and gives orders, and the other is the peripheral, which waits and answers. Usually the camera is a peripheral: the phone app connects to it. To print, it has to be the central and go get the printer.

The X-T30 II already plays that role in one case: Fujifilm’s Bluetooth shooting grip (most likely the TG-BT1), a small tripod handle with a shutter button that sends commands to the camera. The firmware has a module that looks for the grip and connects to it as a central. So I didn’t need to write a Bluetooth stack, just the missing glue.

I found one more problem at this stage. Before printing, the app needs to know which film is loaded, because a mini and a wide print don’t have the same size or shape. It doesn’t ask the printer directly. It reads the printer’s serial number and looks at the first digit: 1 means mini, 2 means wide, anything else means “unknown printer, stop”. That list was written for the printers that existed at the time. The X-S10, a bit newer, also accepts 4. My Link 3’s serial starts with 7, which no firmware I looked at knows about, not even the X-T30 III. So even with perfect Bluetooth, the camera would have rejected it. The fix is simple: treat 7 as a mini.

Step 3: Writing the missing piece

The instax Link protocol is well known thanks to people who recorded the Bluetooth traffic between the phone app and the printer: javl/InstaxBLE, linssenste/instax-link-web and others. It’s simple. Each packet starts with Ab, then a length, an opcode, a payload and a checksum. The camera asks a few questions, sends the JPEG in 900-byte chunks and says “print”.

I didn’t copy the X-S10 code. In a firmware like this, every function and every variable lives at a fixed address, chosen by the compiler when Fuji builds it. When a function calls another one, the call contains that address written in plain bytes. Change one line of code, recompile, and everything after it shifts. Two different cameras are two different builds, so the same function sits at a different address in each. Moving the X-S10 code into my camera would have meant finding and fixing hundreds of those addresses by hand. Instead, Claude and I wrote a small C module from scratch, linkxt. It takes the place of the stubs: the Fuji app calls it, and it calls the Fuji Bluetooth stack.

How do you plug new code into a firmware you can’t recompile? With those same fixed addresses.

First, linkxt needs a place to live. I can’t push existing code aside to make room, since that would move addresses. So I looked for space that already exists but that nobody uses. In the middle of the code there is a run of 4048 bytes of zeros, at 0x01e12030. No function points to it, and it’s still all zeros in a dump of the running camera’s RAM, so the firmware doesn’t use it at runtime either. That’s where linkxt goes. It also set the hard limit of the project: linkxt has to fit in 4048 bytes, debug logging included. Most debugging sessions started with “what can I remove to make room for this new trace?”.

Then the two pieces have to call each other. In one direction, Fuji calls linkxt. The print app still calls its 12 empty functions (“send the serial request”, “send a chunk”, “print”, “connect”…) at their usual addresses. I overwrite the first 8 bytes of each one with a tiny instruction, “jump to this address”, pointing to the matching function in linkxt. The app has no idea. It calls the stub as always and lands in my code.

In the other direction, linkxt calls Fuji. It needs firmware functions too, to open a Bluetooth connection, send a packet or write a file. I give the compiler a list of their addresses, found in Ghidra, and it calls them directly.

On top of that, a few single bytes change. I didn’t add a menu entry: the existing “instax printer print” entry passes a connection type to the print app, 0 for Wi-Fi. Two bytes turn that 0 into a 1, Bluetooth, so the same entry now takes the Link path (with this card, the old Wi-Fi printers are no longer reachable). And the serial check learns about 7.

All these patches go into the copy of the firmware loaded from the SD card (more on that below), never into the camera itself.

Before touching the camera, every build ran in an emulator. I used Unicorn to run the real ARM binary against a fake Link 3 printer written in Python. It caught a lot of bugs at zero cost.

Step 4: Running it without flashing

Now, how do you run modified firmware without writing it to the flash?

The answer came from jitl and the FujiMod project, found on the FujiHack Discord. Fujifilm cameras can boot from the SD card if you hold a secret button combo at power-on (on mine: Delete + press the rear dial). The card holds two files. ffinit.bin is a tiny loader. ffboot.bin is an image of the whole RAM (72 MB), built from the official firmware. The camera loads that image into RAM and runs it. The flash is never touched.

This had been shown to work on other bodies, but nobody had tried it on an X-T30 II. Getting there took 30 trials.

Trial 1: nothing. The camera started normally. I had pressed the front dial instead of the rear one. Trial 2: green LED, black screen. That green LED was jitl’s test loader saying hello: the camera’s boot ROM had read my card. First win.

Who reads the card at that point? Not the firmware, which isn’t running yet. It’s the boot ROM, a small piece of code burned into the processor itself. It can’t be changed and it runs first at every power-on. Its job is to wake up the hardware, then load the firmware from flash, or from the SD card if you hold the button combo. For that it carries its own tiny SD card driver and a FAT reader. Since it’s burned into the chip, its functions always sit at the same addresses. The X-T30 II has the very same ROM as the X100V, and the community had already mapped where everything is in it. So my loaders didn’t need their own SD driver. They just called the ROM’s functions (“init the card”, “read sector N”) by their address. Writing was harder, because the ROM never writes. I had to drive the SD card hardware myself, copying the way the ROM sends its read command.

Then came a long series of black screens. When you boot your own code this early, you have no screen, no debugger, no printf. The only thing I could control was the small LED on the back. So it became my debugger: the loader blinks green once for each stage it reaches, and goes red when something fails. I counted blinks with a stopwatch in hand.

The LED taught me a few things the hard way. First, patience. For several trials I thought the loader was stuck on red, but it wasn’t: the ROM reads the 72 MB image sector by sector, and that takes a minute and a half.

Then, emulators lie a little. One of my loaders froze silently. The C compiler had turned a byte read into a 4-byte read at an address that isn’t a multiple of 4. Once the system is running, that’s fine. This early in boot, the processor refuses it and stops. Unicorn didn’t model that, so all my tests passed. One compiler flag fixed it.

Finally, blinks don’t scale. So I created an empty file, LOG.BIN, on the card from the Mac beforehand. The loader found it with the ROM’s file reader and wrote its log straight into the card sectors behind it. After each trial I opened LOG.BIN on the Mac to see where the boot had stopped.

The log said the kernel started, but the camera app never did. And most of my log points, the ones placed later in the boot, never wrote anything at all.

So why did it take 30 trials? Because the bug was in none of the places I was looking. The card was fine, the loader was fine, the kernel started fine. I found the answer by reading the kernel code on the Mac, not with another trial.

Remember that the 72 MB image is a copy of the RAM: every byte lands at the same address in memory. In that image there is a 128 KB area full of zeros. It looks unused, so jitl’s first boot recipe (“startup”) put some of its own code there, code the app needs later. I did the same with my debug code.

But that area isn’t unused. It’s where the kernel writes its logs, and one of the first things the kernel does is clear it: a short title, then zeros everywhere. Our code was erased a split second before it was needed. When the app jumped to jitl’s code, the processor found only zeros and froze. No error, no log, just a black screen.

jitl’s recipe had failed the same way on an X100V. His other recipe, “cold”, doesn’t put anything in that area, so I switched to it.

Trial 30: no LED at all, then after a minute or two, a normal live view. But was it really running from the card, or had the camera given up and started from its flash? Trial 31: same card with the big image renamed. Nothing, ever. So trial 30 had really booted from the SD card.

Trial 32: my first mod. It turned the LED red for 10 seconds, then let the camera boot. Useless, and the best red LED I’ve ever seen.

(I also spent a few evenings on a USB “service mode” route that can read and write RAM while the camera runs. It was great for checking my RAM image against the real thing, but useless for running code.)

Once linkxt was on the card, the camera showed a new screen: “connecting”… then “CAN NOT BE CONNECTED”. No details.

I needed logs. In the firmware, I found the function Fuji uses to write A:\UILOG\COUNTER.TXT to the SD card, and I reused it. From then on, linkxt wrote everything it did to A:\LINKXT.TXT. Each trial became the same loop:

With logs, things moved fast.

On trials 34 to 36, linkxt scans, connects, finds the instax service and turns on notifications. Bluetooth works.

Trial 37 is the first real instax exchange. The camera’s first question is opcode 0x0000, a “who are you, what do you support?” request. The Link 3 answers, but the Fuji app rejects the answer. It expects a set of flags laid out like on the older printers, and the Link 3 sends 00 02 00 00 00 00 instead. I still don’t know what those bytes mean. Since the app doesn’t use them for anything else, linkxt simply replaces them with the values the app wants.

On trial 38, all the questions pass and the photo upload starts. On trial 39, the Link 3 accepts a print, and the film counter goes from 7 to 6!

The pink ghost

Trial 39 printed. The sheet came out white and slowly developed into… an almost white picture with a faint pink boat. Not quite what I was hoping for.

Since prints cost money, I switched to “no-print” cards. They do everything, but instead of sending the JPEG they save it to the SD card and stop. The JPEG was garbage: pink, zoomed 2×, with stripes on every other column.

Trial 44

Trial 45

The JPEG the camera builds for the printer, before and after the fix. Drag the slider.

I first suspected my code, then the file size, then the source image (an S-size JPEG gave the same result). It was none of those. So I made linkxt dump the image buffers between each step of Fuji’s pipeline, and decoded them on the Mac.

After the resize, the image was perfect, in YUV (“Y Y U V”). After the rotation, it was not YUV at all but 32-bit ARGB pixels.

Reading the code around it explained everything. In one of its answers, the printer lists its capability flags. When capability bit 3 is set, the app runs an extra colour pass: YUV to ARGB, colour tweak, back to YUV. Then a copy meant for printers without that bit runs anyway, and overwrites the clean result with half of the ARGB buffer. The JPEG encoder reads ARGB as if it were YUV, and you get a pink ghost.

It looks like a real Fujifilm bug. Maybe no printer ever set that bit for this code path, and the Link 3 is the first. The fix is one line in linkxt: hide bit 3 from the app. Trial 45, still without film, gave a clean JPEG.

It works!

Trial 46: real card, real film. I picked a photo in the playback menu, hit “Print”, got a progress bar, and the Link 3 started whirring. A few minutes later, the boat appeared.

No phone in the middle, and nothing written to the camera. Pull the card and it’s stock again.

Tools and sources

What	Used for
Python	firmware unpacker, function matcher, card builder, buffer decoders
Ghidra (headless)	disassembly and decompilation of the X-T30 II and X-S10 firmwares
Unicorn	running linkxt against a fake Link 3 before every trial
arm-none-eabi GCC	building linkxt (Thumb-2, under 4 KB)
Claude Code	reading thousands of decompiled functions, writing the tools and the module, keeping notes
FujiHack Discord, FujiMod	SD boot, button combos, and a lot of advice from jitl
javl/InstaxBLE, linssenste/instax-link-web	the instax Link protocol

What’s next

It’s still a debug build, and landscape photos haven’t been tested since the fix (before it, they froze on “Sending”). Next, I want to clean it up and turn linkxt into a proper FujiMod mod.

The code is on GitHub: ronangaillard/xt30ii-instax-link. It contains no Fujifilm code: you download the official firmware yourself, build jitl’s SD boot card (FujiMod’s “recovery” card) yourself, and a script patches it. If you have an X-T30 II on firmware 2.04 and a Link 3, try it, at your own risk, and tell me how it goes.

Factory DS: a Factorio-like on a 67 MHz Nintendo DS

Tue, 13 Oct 2026 10:00:00 +0200

Or how I ended up building a factory game for a 2004 handheld with 4 MB of RAM, with a lot of help from Claude Code

Yes, I even made a game card for it. No, it’s not for sale.

Download Factory DS (factory-ds.nds, 1.9 MB, in English and French). It runs on a real DS with a flashcart, or in an emulator like melonDS.

Why the Nintendo DS?

I think the Nintendo DS is one of the best consoles ever made. It’s far from the most powerful, but I find it one of the best designed. Two screens, a real d-pad, four buttons and two shoulder buttons, and everything falls right under your thumbs. It’s a clamshell, so you can throw it in a backpack without being afraid of breaking it, and it’s simple: you open it and you play, you close it and it sleeps. And of course there is some nostalgia, I spent a lot of hours on it as a teenager.

The problem is that I had run out of games that really kept me hooked on it. The DS library is huge and I have played a lot of great games on it, but the games I spend my evenings on today are more “modern” ones, and none of them exist on the DS.

So I started wondering, why not the other way around? Why not bring a modern game to the DS? The first one that came to my mind was Factorio, the one I play way too much. If you don’t know it, you land on a planet and build a factory: drills mine the ore, conveyor belts carry it everywhere, robotic arms (called inserters) move items in and out of machines, and you spend your time fixing bottlenecks and optimizing ratios. It’s a game about systems more than graphics, so it should fit on a 2004 console, right?

Getting started on a console I had never touched

I had never written a single line of code for the DS. I didn’t know the SDKs, the memory map or how the screens work. So I did what I do now for most of my side projects: I opened Claude Code and started from there.

The first evening was only about the setup. We looked at the options together and I went for BlocksDS, a modern SDK built on top of libnds (the historical C library to talk to the DS hardware). I didn’t want to install an ARM toolchain on my Mac, so I asked Claude to make everything run in a Docker container:

docker run --rm -v "$PWD":/work -w /work skylyrac/blocksds:slim-latest make

You get a .nds file, you open it in the melonDS emulator, and that’s it. A blank screen, but a blank screen that compiles!

Before going further I read a bit about the hardware, because I knew it would drive a lot of decisions later:

	Nintendo DS
Main CPU	ARM946E-S at 67 MHz, with no division instruction!
RAM	4 MB
Fast memory (ITCM)	32 KB for code, much faster than the main RAM
Screens	2 × 256×192
Saves	a small save chip in the cartridge, or files on the SD card of a flashcart (the cartridge you use to run homebrew games)

The first specs

Then I wrote the first specs of the game. Nothing fancy, just a short list:

a 2D world seen from above, with biomes (grass, forest, lakes, desert, snow)
wood, stone, iron, copper and coal to mine by hand
a player who walks around with the d-pad, with a cursor in front of him
the world on the top screen and the interface on the bottom one
drills, furnaces, belts and inserters, and that’s all for a start
everything playable without the stylus

For the graphics I picked the CC0 Kenney tilesets (Tiny Town and Tiny Factory). They are 16×16 pixels, which is exactly the right size for a 256×192 screen, and they still look good that small.

I also decided to draw everything as a bitmap, where each pixel is one byte pointing to a palette of 256 colors, instead of using the tile engine of the DS. The tile engine is the classic way to make a 2D game on this console, but I wanted to be free to draw whatever I wanted: items sliding on belts, inserter arms rotating, smoke, and later trains. I think it was the right call, even if it’s also where most of the performance problems came from.

The very first build was just colored squares. A red square for the drill, grey rectangles for the belts, orange dots for the items and some debug text on the bottom screen. It was ugly, but the belts were moving and that was enough to keep me going. Then real tiles came in, then a mini-map, then objectives… Here is how it evolved:

From colored squares to the current version. These screenshots are in French, but the game is now also in English.

A world that does not fit in memory

Next I wanted a big world, the kind of world where you have to build trains to bring oil from far away. I set the target to 2048 × 2048 tiles, which is 4.2 million tiles. Even with one byte per tile, that’s already the whole RAM of the console.

Just asking for “a bigger map” would have ended with a giant array and a crash, so Claude and I spent an evening on the design first, going back and forth until it fit. We ended up with this:

the terrain is not stored at all. Any tile is computed when needed from its coordinates, with a hash function and some value noise (a smooth kind of random) that decide where the forests, lakes, ore patches, deserts and snow are
only what the player changes is stored, in a hash table of modified tiles (an ore patch you mined, a tree you cut)
buildings live in a pool indexed by position, with another hash table
the save file only contains the differences with the generated world, in a compact format (6 bytes per belt)

On the left, the real generated world, all of it (one pixel is 4×4 tiles). On the right, a small base. Only the tiles the player changed (orange) and the buildings (blue) take memory.

Claude wrote the code and it worked as I hoped. A save slot is 64 KB, there are 3 of them (3 files on the SD card with a flashcart), and a big factory fits in one.

I still wanted to know what happens when it doesn’t fit.

In RAM, it can’t overflow. Every table is allocated once when the game starts, with a fixed size: room for 12,288 modified tiles and 12,288 buildings, 552 KB in total. There is no malloc anywhere in the game. When a table is full the game just refuses, with “too many buildings” when you try to place one more or “map saturated” when you try to cut one more tree. It doesn’t crash.

The save is another story. A building takes between 5 bytes (a rail) and 23 bytes (a machine with its state), a modified tile takes 6 bytes, and a slot is 64 KB. So I measured real saves of bigger and bigger factories:

Factory	Save size
The biggest save made by the test agents	under 8 KB
820 buildings	19 KB
1,830 buildings	34 KB
2,840 buildings	50 KB
around 3,500 buildings	doesn’t fit anymore

So no, it’s not guaranteed, and a player could build a factory too big to be saved. If that happens the game refuses to save and shows a message. The save is built in memory before anything is written, so the previous save is still there. You can’t save the latest version of your factory, but at least you don’t lose the old one.

I decided to stop there for now. Placing 3,500 buildings one by one with a d-pad is quite extreme, and the biggest saves made by the test agents are 8 times smaller than the limit. If someone ever gets there, I could compress the save or warn the player before the limit.

Machines, recipes and ratios

With the engine in place, the real game design could start, and it’s probably the part I enjoyed the most. I wrote down the machines, the recipes and their ratios. How many seconds for an iron plate, how many furnaces to feed one assembler, how much coal a steam engine burns… Then came the tiers:

electricity, with generators, steam engines, solar panels, batteries and finally a nuclear reactor
oil, with pumpjacks, pipes, refineries, plastic, sulfur and rocket fuel
science packs, labs and a research tree of 16 technologies, with recipes locked behind research
trains (more on them below)
logistic drones that carry items between chests
a rocket silo, around 50 objectives to guide you from the first wooden log to space, and an infinite research to keep going after the rocket

On the left the panel of a furnace, on the right the crafting menu.

Power grids and pipes

Electricity and fluids can get very expensive in a factory game. If you simulate the current going through every cable, or the water moving from one pipe to the next, a 67 MHz CPU gives up quickly. So for these the game doesn’t think in buildings, it thinks in networks.

For electricity the rules are quite simple. Two power nodes (poles, generators, solar panels and batteries) within 7 tiles of each other are linked automatically, there is no cable to pull. A pole powers the machines up to 3 tiles around it, and a generator up to 6. Twice per second each network compares what it produces with what its machines need, and the batteries charge or discharge the difference. If there isn’t enough power, every machine in the network slows down by the same amount. At 70%, everything runs at 70% speed, like in Factorio.

The expensive part is figuring out who is connected to whom, so it only runs when the factory changes. The nodes are sorted by x, so each one is only compared with the next ones up to 7 columns away. The groups are merged with a union-find, a classic little algorithm where each group points to a “leader” and merging two groups just means changing one pointer. The cables you see on screen are only the links that joined two groups, so you don’t get a spaghetti of wires. Step by step:

The same rules and numbers as in the game, replayed in your browser. Click the picture or a number to go step by step. The colored bar under a machine is its speed.

Fluids work the same way. A pipe network is one single tank. Its capacity is the sum of all its pipes and tanks, and it holds one amount of fluid. A pump adds to it, a machine takes from it, and nothing actually flows from one pipe to the next. When you cut or connect a pipe, each piece first gets back its share of the old network (in proportion to its capacity), then the networks are rebuilt and their shares added up. Only the fluid that was inside the removed pipe is lost, and as long as the pipes don’t change it costs nothing. Here is what happens when you connect and cut pipes:

One number per network instead of one per pipe. Click to go step by step.

All aboard

If you have played Factorio you know the moment. Your factory is running, the ore patch next to it is almost empty and the next one is far away. You place your first rails, your first station, your first locomotive, and that’s when the game gets really good. So a Factorio-like without trains was not an option for me.

They were also the hardest feature to get right. I wanted real trains and not just a cart on a rail:

rails, stations and locomotives that you place by hand, with up to three wagons behind each locomotive (cargo wagons for items, tank wagons for oil)
wagons that really follow the locomotive. Each train remembers its last positions, every 2 pixels, and the wagons are drawn along that path, so they bend in the turns exactly like the locomotive did
schedules with up to four stops, and a condition for each stop: wait 8 seconds, wait until full, wait until empty or refuel. Inserters next to a station load and unload the wagons. The classic “iron mine full, then smelter empty, then coal station” loop works! At every junction the train looks for its way to the next station with a breadth-first search on the rail network, in a buffer of fixed size, so even a big network can’t make it run out of memory
block signals. A signal cuts the track into blocks and only one train is allowed in each block. When a train passes a signal the next block is reserved and the light turns red for the others. Trains also keep a safety distance of two tiles, so they never run into each other
and you can ride them! Press A next to a locomotive and you hop in, and the camera follows the train across the map

Getting several trains to share a network without deadlocks took a lot of evenings and a lot of scripted test sessions. I had two trains face to face on the same track, each one politely waiting for the other forever (now one of them backs off after a while), trains without a path because a rail was rotated the wrong way, and a train save format that had to change three times… But once it worked, I could watch three trains share the same loop, stop at the red lights and wait for their turn for ten minutes.

Three trains with cargo and tank wagons on the same loop. The little red flags are block signals, a train waits until the block in front of it is free. Captured from the game itself, at 30 fps.

Wires, clocks and logic gates

The other thing Factorio players love is automation that thinks by itself, like “stop the drills when the chest is full” or “only let the train leave when the wagons are loaded”. I didn’t want to go as far as the Factorio circuit network, with numbers on every wire, so I went for something closer to Minecraft redstone, with on/off signals only.

There are sources (a lever, a button that sends a 2-second pulse, a clock that switches every 1, 2, 4 or 8 seconds, and a sensor that watches a belt, a chest, a machine or a station), wires that carry the signal from tile to tile, and NOT, AND and delay gates. Chain a few delays and you get timers. At the end of the chain, a machine next to a signal pauses, a lamp turns on, a belt gate opens, or a station keeps its train at the platform.

With that you can build the classic “sensor on the chest, the drills stop when it’s full”, or keep a train at the station until a sensor says the chest next to it is empty.

The simulation runs every 4 frames, in three passes. First every source and every gate computes its new output from the state of the previous pass. Then the wires are flooded from the active sources with a breadth-first search. And finally each building reads the signal of its neighbors. Because the gates only look at the previous state, a loop of gates can’t get the game stuck in an infinite loop, it just oscillates like in real electronics. And if you haven’t placed a single logic piece, the whole thing is skipped.

A clock switches on and off every 2 seconds and the signal travels through a chain of delays, so the lamps light up one after the other. The vertical wire on the left opens the gate of the bottom belt while the wave passes, and the plates pile up behind it the rest of the time. The top belt is behind a NOT gate, so its copper plates go through when the bottom gate is closed.

Testing (and balancing) a DS game without a DS

Testing was a problem from the very beginning. Every time Claude wanted to check something, an emulator window popped up on my screen. And I had no way to know if a change broke something three hours of play later.

So I asked Claude to prepare an environment where an agent could test the game on its own, by building it locally on my Mac and running it headless (without any window). The game now also compiles for macOS, against a tiny fake version of libnds. Instead of drawing on a screen, it writes PNG files of both screens. On top of that, a small text interface lets the agent drive the real game code with commands like press A, hold RIGHT 30, step 600, shot factory.png or state.

With that, play sessions become text files that can be replayed after every change. We ended up with around 470 of them, from “cut a tree” to “build a train network with signals”. They all run with the compiler’s sanitizers turned on, which stop the game as soon as it reads the wrong memory or does something undefined in C. And since Claude can play the game and look at the screenshots, it can check its own work before telling me it’s done.

A real session: the script, the screenshot it produced, and the state of the game it printed.

Some bugs were really sneaky. My favorite one: if the game auto-saved during the 8 seconds of the rocket countdown, the silo stayed full forever and the game could never be finished. The odds were around 2.7% per rocket. In another one, a pumpjack connected to a full pipe network kept its last barrel of oil waiting to be pushed out, and never pumped again. Without the scripted sessions I would have found these after hours of play, or never.

The same setup gave me an idea for the balancing. Instead of playing 10 hours after every change in the ratios, I asked Claude to launch several agents that play the game through the text interface, each one on a different part of it. One played the beginning (the first 15 objectives) with the real buttons, without any cheat, and timed every objective. Another one measured the production rates of the mid- and late-game factories, a third one played the end game up to the rocket, and a last one tested the infinite research. There was also an “analyst” that read the code to list every rate and recipe, and computed how long the whole game would take. At the end each agent wrote a report about where it got stuck, how long each step took and what was too slow or too fast.

Then I read the reports and decided what to change. Cheaper labs here, a shorter objective there, an oil patch closer to the start… The agents play badly, and where they get stuck a new player probably will too.

Hitting the performance wall

Then my first big factory arrived, and it could not hold 60 frames per second. Walking around stuttered. A 67 MHz CPU is not much when you want to simulate thousands of machines and redraw a full screen 60 times per second.

Before changing anything I wanted numbers, but printf does not go anywhere on a DS! So I asked for a benchmark mode in the game. It loads several test factories and writes its timings into a buffer in RAM, and a small Python script reads that buffer through the debugger connection of melonDS (its GDB stub). melonDS runs in the background with the sound off and its JIT disabled (the JIT makes the emulator faster by translating the DS code for my Mac, but then the timings mean nothing). melonDS is very accurate, but it’s still an emulator, and I’ll come back to that at the end.

Then we went through the problems one by one. Measure, fix the worst one, measure again.

The ground. Redrawing the whole ground every frame was way too slow. The DS video hardware can stack several layers and scroll each of them by itself, so I split the top screen into two layers. A large 512×256 ground layer lives in video memory, and only the new tiles entering the view are drawn into it. The hardware scrolls it during the vertical blank (the short pause between two frames when the screen is not being drawn), so scrolling is free. Buildings, items and the player are drawn on a second layer on top, where color 0 is transparent. This alone removed more than 5 ms per frame and the stuttering disappeared.

The two real layers of the top screen, pulled out of the game. The ground layer is bigger than the screen, so the tiles around the view are already there when you walk.

Night for free. The game has a day and night cycle, and my first thought was that at dusk I would have to redraw everything darker, including the big ground layer. But each pixel is not really a color, it’s an index in a palette of 256 colors. So night is not drawn at all! When the light changes, the game recomputes the 256 colors of the palette, a bit darker and a bit bluer each time, and the hardware applies them to every pixel of the screen at once. That’s 256 values to write instead of 49,152 pixels. The few colors used by the interface and the cursor are never darkened, so they stay readable at night. The only things actually drawn are the lights: the glow of the lamps and furnaces, and the fireflies.

The same frame, rendered once with the day palette and once with the night palette. 97% of the pixels have exactly the same value in both images (the other 3% are the lights), only the colors below change.

Fast memory. The ITCM is 32 KB of memory right next to the CPU, much faster than the main RAM. The hot loops go there: the simulation of the machines, the belts and the drawing of the buildings. 32 KB is not much, so I only put there what runs every frame, and every new feature in one of these loops means checking the size of the .itcm section again (22 KB are used today).

No division. The ARM9 has no division instruction. The DS has a separate division unit, but a plain / in C becomes a slow software routine. When infinite research arrived, it added a harmless-looking time * 20 / (20 + level) per machine and per frame. The benchmark caught it, the number of slow frames in the stress test almost doubled. We replaced it with a multiplication by a precomputed fixed-point factor, and the slow frames went from 581 back to 312.

The interface. Even the bottom screen became a problem when I redesigned the menus (more on that below), a full redraw took 14 ms. The rectangle function was checking every single pixel, and every letter of text went through it. Clipping once and writing whole rows at a time brought it down to 4 ms.

The intro. The splash screen was stuttering too. A nebula was computed pixel by pixel every frame (105 ms!). Computed once at startup, it takes 6 ms.

Average time per frame, measured on melonDS with the JIT off. The DS screens refresh at about 60 Hz (59.8 to be exact), so a frame has 16.7 ms. Below that, the game runs at full speed. A lot of 3D DS games actually run at 30 fps, but for a 2D game with belts everywhere I really wanted 60.

On melonDS, a factory of almost 900 buildings runs at a steady 60 fps. The stress test with 3,630 buildings is under 16.7 ms on average, but about 300 of its 1,200 frames are still too slow. That’s way bigger than what you can reasonably build with a d-pad though (and more than what a save can hold anyway).

These are melonDS numbers. The real console is a bit slower, more on that at the end.

Playing it, again and again

Once everything was there, I played. A lot. And every session ended with a list of things I didn’t like, that I sent to Claude, often with a screenshot.

Designing an interface for a d-pad and 256×192 pixels is hard, and the bottom screen was rewritten many times. A selection frame was covering the number of items, two lines of the same description were in two different whites, some texts were too long for their box (they now scroll back and forth)… Removing a building used to need a “remove” tool, which I found painful, so now it’s a long press on B and the tool is gone. And START and SELECT were the other way around compared to most DS games.

Then I went through every screen, one by one, for a complete redesign. The first menus were plain text on a purple background, and every screen got rebuilt with cards, drawn buttons and icons, so you always know which key does what.

The options menu, before and after the redesign.

On the left the world map, on the right the research tree, with the infinite research in the top right corner.

The finishing touches

I spent (too much) time on graphic styles. I asked Claude for several palettes and tile variants and kept the ones I liked. The Kenney one stayed the default, and there is also a blueprint style, a flat one and an industrial one, that you can switch at any time from the menu. There was a Game Boy palette too, but I killed it.

The four styles of the game.

For the sounds, I asked Claude to find a few CC0 candidates on Freesound for each one, and I picked them by ear. Then they were all normalized to the same loudness, because the DS speakers are tiny and some sounds were inaudible next to the music. I also added rain, snow, sand wind in the desert, butterflies and fireflies (there were birds at some point, but they were distracting).

The game was first written in French, so at the end I asked Claude to translate it into English too, around 1,300 texts in total. They had to stay as short as the French ones to fit in the little boxes of the interface. The language follows the setting of your console, and you can switch it at any time from the title screen or the options menu.

And finally a small cinematic when you start a new game. Your ship drifts between the stars, the engine dies, and you wake up in the grass next to it. The first version was very “epic”, with big flashes and shaking, but I wanted something calmer and more dreamy, so we toned it down until I liked it. Everything is drawn with code, there is no video in the ROM.

Next: the real console

You can now play Factory DS from start to finish, from cutting your first tree to launching rockets, and keep going after that. The ROM is under 2 MB.

But there is one thing melonDS didn’t tell me. On my own DS, with a flashcart, the game’s frame counter showed around 30 fps instead of 60, all the time. So I ran the benchmark ROM on the real console, it writes its results to the SD card, and compared them with melonDS line by line.

The real DS is about a third slower than the emulator for this game. The factory of 890 buildings takes 12.2 ms per frame instead of 9.1 ms, and clearing the big buffer of the top screen takes 4 times longer, writing to the main memory is much slower on the real hardware than in melonDS. That’s still under the 16.7 ms of a frame most of the time.

The 30 fps came from somewhere else, and it’s a bit funny. The frame counter is shown in the statistics screen, and this screen was fully redrawn on every frame. On the real console that alone took almost 16 ms, so as soon as you opened the statistics, the game dropped to 30 fps… and showed you 30 fps. The screen now refreshes 8 times per second and the counter shows the real speed. Small and medium factories run at 60 fps on the real console, and only very big ones slow down a bit.

There is still some margin to win on the real hardware, starting with that buffer that is cleared on every frame, and I’ll probably write a second part about it. In the meantime you can already try the game on your own DS or in melonDS. And maybe one day I’ll try local wireless multiplayer, with two DS building the same factory!

Download Factory DS (factory-ds.nds, 1.9 MB, in English and French). It runs on a real DS with a flashcart, or in an emulator like melonDS.

Reverse Engineering the Epson FilmScan 200 for Classic Mac

Tue, 30 Dec 2025 22:00:00 +0100

How I wrote a SCSI driver from scratch to scan 35mm film on a Mac SE/30 running System 7

The Problem

I shoot and develop 35mm film at home. It’s a nice hobby, and I do my own prints in a small darkroom. But sometimes I want digital copies to share online or just to archive.

A while ago I found an Epson FilmScan 200 on leboncoin (the French Craigslist) for 10 euros. It’s a dedicated 35mm film scanner from 1997 that scans at 1200 DPI optical. At that price, worth a try.

The catch? This scanner only has a SCSI interface and the official drivers only work on Mac System 7/8 or Windows 95/98. My main machines are modern Macs. I could install a virtual machine, but SCSI passthrough is basically impossible. I could use a USB-to-SCSI adapter, but those are expensive and often don’t work well with scanners.

But wait. I have a Mac SE/30 sitting on my desk. The same one I brought back to life a few years ago. It has SCSI. It runs System 7. Could I scan directly on it?

The official Epson TWAIN driver exists, but it’s a complex plugin designed for Photoshop. I wanted something simpler: a standalone app that scans frames and saves them as files I can transfer via FTP.

Time to write my own driver.

Understanding the Hardware

The first step was understanding how this scanner actually works. I found a service manual PDF online, which gave me crucial information:

Spec	Value
SCSI device type	“Processor” (0x03), not a standard scanner
Protocol	ESC/I commands encapsulated in SCSI SEND/RECEIVE
Resolution	Up to 1200 DPI optical
Frame size	24x36mm = 1120x1680 pixels at max resolution

The “Processor” device type was interesting. Unlike standard SCSI scanners that use vendor-specific commands, this one uses generic SEND (0x0A) and RECEIVE (0x08) commands to exchange ESC/I protocol data. The ESC/I protocol is Epson’s standard scanner command language, same family as what their flatbed scanners use.

I was surprised by how technical the service manual is. It details SCSI timings, command sequences, data exchange formats… Did technicians really use this to repair people’s scanners back in the day? I guess they did. Either way, it gave me a solid foundation, even if it stayed a bit high-level and didn’t detail every command parameter.

I also extracted the original 68k driver from the Epson TWAIN plugin (a 748KB resource fork) and started disassembling it to understand the command flow. Why not just use SANE on Linux? Because SANE doesn’t actually support the FilmScan 200 out of the box. The mainline epson backend doesn’t include it. So I was on my own.

Setting Up the Development Environment

For development, I used THINK C 5.0 on the SE/30. Yes, I’m writing 68k code in 2025. There’s something satisfying about it.

The project setup is minimal. You just link against ANSI for printf/FILE functions and set partition size to 8MB (color scans need ~5.6MB buffer).

The SCSI Manager API on classic Mac OS is… interesting. You call SCSIGet() to acquire the bus, SCSISelect() to select a device, then SCSICmd(), SCSIRead()/SCSIWrite() with Transfer Instruction Blocks (TIBs), and finally SCSIComplete(). Every step can fail, and you need to handle cleanup properly.

First Success: Single Frame Scan

After a few evenings of coding, I got my first successful scan! The basic flow is:

SCSIGet / SCSISelect
SEND: ESC @ (Init)
RECEIVE: ACK (0x06)
SEND: ESC C + 0x00 (Set mono mode)
RECEIVE: ACK
SEND: ESC R + resolution (Set 1200 DPI)
RECEIVE: ACK
SEND: ESC A + area (Set scan area)
RECEIVE: ACK
SEND: ESC G (Start scan)
Loop: RECEIVE header + data, SEND ACK until done
Save as PGM file

The data comes back line by line, each with a 4-byte header containing status flags and byte count. You keep reading until the “end of data” status bit is set.

I saved the raw data as a PGM (Portable GrayMap) file, a dead simple format that’s just a header followed by raw pixel bytes. Preview on modern macOS opens them directly.

The scratches on the film? One of my first home developments. I had a hard time getting the film out of the reel. Image inverted with Filmvert for viewing.

The Frame Selection Problem

Here’s where things got frustrating. The FilmScan 200 has a 6-frame carrier. You load a strip of film and can scan frames 1 through 6. My first scan worked, but I couldn’t figure out how to select different frames.

The service manual mentioned an ESC P (SetBay) command with 2 parameter bytes. I tried everything:

[frame-1, 0]    what the disassembled 68k driver seemed to use
[frame, 0]
[0, frame]
[frame-1, frame-1]

Nothing worked. The scanner would just scan frame 1 every time, or worse, return an error.

I spent hours in the disassembler, tracing through the original driver. I found a function at offset 0x47080 that handled ESC P, and it seemed to use 0-indexed values. But when I replicated the exact sequence, it still didn’t work.

Then I noticed something odd: some commands in the driver called a function that checked for a handle called “OnionCommsRef” with magic bytes ‘Comm’. Without this handle, the commands were blocked on the driver side before even reaching the scanner. Was the ESC P format I found never actually used?

The Breakthrough: A Hidden Website

After much frustration, I stumbled upon a hidden gem: http://www.vjet.f2s.com/linux/scanner/download.html. This site, maintained by someone named Clive, contains a patched SANE driver specifically for the FilmScan 200. It’s not in the mainline SANE project, just sitting there on this old website that somehow still works in 2025.

I downloaded epson_17062002.c and started reading. And there it was, on line 2447:

simplecommand(SET_BAY, s, s->val[OPT_BAY]+1, s->val[OPT_BAY]+1);

The format is [frame, frame], both bytes identical, 1-indexed!

/* This is what works */
gCmd[0] = frame;  /* 1 for frame 1, 2 for frame 2, etc. */
gCmd[1] = frame;  /* same value repeated! */

I still don’t know why both bytes need to be the same. Maybe it’s a confirmation/validation thing. Maybe it’s a quirk of this specific scanner model. But it works!

Another tip from the SANE source (in a comment): “It wastes a lot of time on the filmscan moving the slide around if you send a reset every scan..” So you should only send ESC @ (Init) once at startup, not before each frame. This saves about 30 seconds of recalibration per frame.

Thank you Clive for writing this driver back in 2002, and thank you for keeping your website online all these years. It saved my project.

Adding Color Support

Mono scans were working great, but I wanted color. According to the documentation, you just set ESC C to 0x02 instead of 0x00.

Easy, right? Not quite.

My first color scan showed three columns side by side, each column was a grayscale version of the image. Classic sign of getting RGB data in the wrong format.

Each column is one color channel. Not quite what I was hoping for.

After more digging in the SANE driver, I found that in color mode, the scanner sends 3 separate data blocks per line, one for each color channel. And they come in G, R, B order (not RGB!).

For each scan line:
  RECEIVE: header + G data (1120 bytes)
  SEND: ACK
  RECEIVE: header + R data (1120 bytes)
  SEND: ACK
  RECEIVE: header + B data (1120 bytes)
  SEND: ACK (unless end of frame)

I had to buffer each color channel separately, then merge them into interleaved RGB for the output file:

for (i = 0; i < width; i++) {
    output[i * 3]     = rBuf[i];
    output[i * 3 + 1] = gBuf[i];
    output[i * 3 + 2] = bBuf[i];
}

The first version came out way too green because I had G and R swapped. Once I got the order right, beautiful color scans!

Quick inversion with Filmvert. The colors aren’t perfect, but it’s just for preview. You can always fine-tune later manually or with something like Negative Lab Pro.

The Final Result

The finished driver is about 450 lines of C code. It initializes the scanner once at startup, lets you specify a folder name and starting pose number, scans 1 to 6 frames in a batch, saves as PPM (color) or PGM (mono) files, and asks if you want to continue with more frames.

A full 6-frame color scan at 1200 DPI takes about 10 minutes on the SE/30. Not fast, but not bad for a 35-year-old computer talking to a 27-year-old scanner.

To get the files off the SE/30, I run a Python FTP server on my modern Mac and use Fetch on the SE/30 to upload. Works great.

And honestly? There’s something nice about this whole setup. Shooting film, developing it myself, then scanning on hardware from the same era. Staying in the 90s, before the digital revolution took over. Full nostalgia, and I love it.

Lessons Learned

Old hardware documentation is gold. The service manual and SANE source code were essential. Without them, I’d still be guessing at protocol details.

Disassembly isn’t always the answer. I spent hours in the 68k disassembler when the SANE source had all the answers in readable C.

Don’t trust 0-indexed vs 1-indexed assumptions. The frame numbering mismatch cost me a whole evening of debugging.

Old computers are still useful. My SE/30 now has a real job: digitizing my negatives.

The code is available on GitHub: fs200-classic-mac

Now if you’ll excuse me, I have about 50 rolls of film to scan…

From Frustration to App Store: The Story of Workspace Profiles

Wed, 03 Sep 2025 15:30:00 +0200

Or, how I turned an annoying daily routine into a Mac app.

The Problem: The Tyranny of Manual Settings

Like many developers, my day is punctuated by context switches. I plug my MacBook into a docking station at the office, connect it to an external monitor at home, put on a headset for a call… and each time, it’s the same ritual: open System Settings, find the right Display panel, rearrange my screens, then go to the Sound panel to select the correct microphone and speakers. It’s a waste of a few seconds, but repeated multiple times a day, it became a constant source of frustration.

It was this small, daily annoyance that sparked the idea for a solution. A generic solution. A simple, lightweight app that would live in the menu bar and let me switch between my configurations with a single click. Today, I’m incredibly proud to announce that this idea has become a reality: Workspace Profiles is now available on the Mac App Store!

The Workspace Profiles settings window where you can configure your different profiles.

The core of the problem is simple: macOS remembers some configurations, but it’s far from perfect. If you use multiple external monitors or various audio devices at different times, the system can get confused.

My typical use cases:

At the Office: My MacBook is connected to two Dell monitors. I want the left monitor to be my primary display, and I need the audio to come out of the monitor’s built-in speakers.
At Home: I plug it into my Studio Display. This screen should become the primary one, and the sound needs to go through my external USB speakers.
On the Go / Podcasting: Just the MacBook, but I want my external Rode NT-USE mic to be the default audio input as soon as it’s connected.

Each transition required manual reconfiguration. I wanted a solution that would understand the context and adapt automatically.

The Solution: Profiles for Every Workspace

Workspace Profiles is built on a simple concept: Profiles. A profile is a snapshot of a desired configuration. For each profile, you can define:

Display Arrangement: Whether you want an extended desktop or mirrored displays
Primary Display: Which of your monitors should have the menu bar and the Dock
Audio Devices: Which microphone (input) and speakers/headphones (output) to use by default

Once you’ve created your profiles (e.g., “Office”, “Home”, “Presentation”), you can switch between them in three ways:

Manually from the menu bar icon.
With a global keyboard shortcut that you can set for each profile
Automatically using “Triggers”.

This last feature is, in my opinion, the most powerful. You can link a profile to the connection of a specific device. For example: “When my Dell monitor is connected, automatically activate the ‘Office’ profile.” And just like that, the magic happens!

A Technical Look Under the Hood

Developing this app was an interesting journey into the low-level APIs of macOS, far from the usual comfort of SwiftUI. Here are a few of the most interesting technical challenges I tackled.

Detecting Hardware Changes

The first essential building block was knowing when a display or audio device was connected or disconnected. To do this, I had to dive into macOS’s C-based frameworks.

For displays, I used the CGDisplayRegisterReconfigurationCallback function from the Core Graphics framework. This allows you to register a callback function that the system will call whenever the display configuration changes.

For audio, it’s a similar approach with AudioObjectAddPropertyListener from the Core Audio framework. This lets you listen for changes to the kAudioHardwarePropertyDevices property on the global system object.

In Swift, the code to bridge these C calls looks like this:

// In HardwareManager.swift

func startMonitoringDisplayChanges() {
    CGDisplayRegisterReconfigurationCallback(displayReconfigurationCallBack, nil)
}

func startMonitoringAudioChanges() {
    var propertyAddress = AudioObjectPropertyAddress(
        mSelector: kAudioHardwarePropertyDevices,
        mScope: kAudioObjectPropertyScopeGlobal,
        mElement: kAudioObjectPropertyElementMain
    )
    AudioObjectAddPropertyListener(
        AudioObjectID(kAudioObjectSystemObject), &propertyAddress, audioDevicesPropertyListener, nil)
}

These callbacks then post a notification via Swift’s NotificationCenter so the rest of the app can react cleanly.

Handling Notification “Bursts”

A gotcha I quickly encountered, especially with audio devices, is that the system sometimes sends a burst of notifications for a single event (e.g., a device initializing). If I applied the profile on every single notification, the app would perform redundant actions.

The solution is a classic technique called “debouncing”. Instead of handling the event immediately, I schedule it to run after a one-second delay using a DispatchWorkItem. If a new notification comes in during that short window, I cancel the previously scheduled task and plan a new one. This ensures that only the last event in a rapid series is actually processed.

// In ProfileManager.swift

private var audioChangeWorkItem: DispatchWorkItem?

@objc private func scheduleAudioChangeHandler() {
    self.audioChangeWorkItem?.cancel() // Cancel the previous one

    let newWorkItem = DispatchWorkItem { [weak self] in
        self?.handleAudioChange()  // Run the actual logic
    }

    // Schedule the new one
    DispatchQueue.main.asyncAfter(deadline: .now() + 1.0, execute: newWorkItem)
    self.audioChangeWorkItem = newWorkItem
}

Implementing Global Keyboard Shortcuts

To allow users to trigger profiles from anywhere in macOS, I needed to implement system-wide (or “global”) hotkeys. Modern Swift and AppKit APIs are sandboxed and don’t make this easy. The solution was to reach back to an older, but incredibly powerful, C-based framework: Carbon.

By using the RegisterEventHotKey function, the app can tell the system to listen for a specific key combination, no matter which application is currently active. The system then sends an event to my app when the hotkey is pressed. It feels a bit like archeology, but it’s the most reliable way to get this done on macOS.

What’s Next

Building Workspace Profiles has been a fantastic learning experience, taking me from a simple idea born out of personal frustration to a polished app on the Mac App Store. It was built natively with SwiftUI to feel right at home on your Mac.

I invite you to check it out on the Mac App Store. Your feedback is invaluable, so please don’t hesitate to report bugs or request new features on the project’s GitHub repository. Thank you for your support!

A Cheap and Simple ADB to USB Converter

Fri, 05 Nov 2021 10:44:00 +0100

A Pro Micro, a resistor, a mini-DIN connector and a tiny PCB to use my Apple keyboard on a modern Mac

Updates

[April 2022] Added the tips from the 68kMLA forum thread at the end of this post.

I discovered the Apple Keyboard M0116 with my Mac SE/30 and I fell in love with it. The Control key is where it should be, next to the A. The Alps switches feel great, a bit noisy but not too much. And the style : the Apple font of the time on the keycaps, the little rainbow Apple logo in the corner… This keyboard is incredible, so I really wanted to use it every day on my modern Mac. And I have been doing so for more than a year now.

Photo : baku13, Wikimedia Commons, CC BY-SA 3.0

The only problem is that it speaks ADB, the bus Apple used before USB.

When I looked for an ADB to USB converter I was shocked by the price. Then I found out that QMK, the firmware a lot of people use on their DIY mechanical keyboards, supports ADB keyboards. All you need is a microcontroller with native USB like the ATmega32U4.

So I bought an Arduino Pro Micro, flashed it with QMK and I was good to go. Except that for more than a year I had three wires flying between the Pro Micro and the ADB connector, and they kept disconnecting. So I finally drew a small PCB to clean this up.

The board

There is not much on it : the footprint of the Pro Micro, a 4 pin mini-DIN connector for the ADB cable, and a resistor. The resistor is a pull-up on the ADB data line, anything between 1k and 10k works. Everything is through hole so anyone can solder it.

The ADB connector is a standard 4 pin mini-DIN, the same one used for S-Video, so it is easy to find.

The KiCad files are on GitHub : ronangaillard/adb2usb. I ordered mine from JLCPCB, it was around 4.50$ for 5 boards shipping included. Add a Pro Micro (around 10$) and the converter costs a fraction of the commercial ones.

Flashing

The first time, you need to flash the DFU bootloader on the Pro Micro with an ISP programmer, following the QMK guide. Then on macOS install QMK :

brew install qmk/qmk/qmk

Build the firmware :

qmk compile -kb converter/adb_usb -km default

And flash it :

qmk flash -kb converter/adb_usb -km default

And you’re good to go !

A really cool thing with QMK is that you can change the key mapping very easily. For instance I remapped the Power key at the top of the keyboard to Play/Pause.

What happened next

I posted it on the 68kMLA forum and it got a lot more attention than I expected. People from the forum ordered boards, built converters and helped each other with the flashing. A few useful tips came out of the thread :

any Pro Micro compatible board with an ATmega32U4 works, like the Elite-C. Boards with a USB-C port are a good idea since the micro USB port of the Pro Micro tends to rip off the board
you can solder the Pro Micro on the underside of the PCB, so the board supports its USB port
boards like the Elite-C already come with a bootloader that works with QMK Toolbox, no ISP programmer needed

68net : A Modern SCSI2Ethernet Board - Part 1

Tue, 10 Nov 2020 10:30:29 +0100

Want to discuss about this project ? Go here !

Introduction

I had been looking to connect my SE/30 to the internet but I struggled to find PDS boards that would fit in it. It is particularly difficult as such boards are rare, but there is also very little space available in the SE/30, so most cards won’t fit in. Apart from the internal PDS port the SE/30 has another expansion port : SCSI, which is an improved parallel port. It is available at the back of the computer as a DB25 port. But all SCSI to Ethernet devices from back in the days that I found were missing floppies with drivers. Moreover most of this stuff was in the US so shipping would be really expensive. Then I found about scuznet, a modern design by @saybur. It was really interesting because it was made to work with an unpatched Nuvotech driver. But there was a few things I did want to change/improve to the design, including the fact that it would be really cool to be able to upgrade the firmware by USB so that the community could easily develop and upgrade the firmware.

The goals of this project is to make a cheap, open source, community driven, and reliable board.

This is the original design by @saybur :

So I decided to create a new design based on this. Here are the main things I changed/added to the original design :

The microcontroller is replaced by a STM32 (ARM chip) that will be upgradable by USB. In the future it also means a firmware could handle Ethernet over USB, and you could share files between your modern computer just by connecting to you vintage mac by USB;
The board is self powered by the SCSI
In case external power is needed (such as on the Macintosh Plus I guess) it can be provided by USB (instead of a power jack on the original design)
I added mouting holes to the PCB so that we can design an acrylic case later;
I removed the SD Card slot because I like things that does a simple task but does it well (Good design is as little design as possible)
Designed in Kicad 5 (instead of Kicad 4)

On my design, power can be provided by the SCSI bus or/and the USB port. The board has some circuitry that automatically switches between these two sources, so for the end user it is really convenient. On a Mac that has a stable SCSI 5V you just have to plug the board, on other Macs plug the board and connect the USB port to a USB wall charger and that’s it. It also means the board can be connected to the turned on Mac while updating the firmware, which will also be super convenient while developing a new firmware.

SCSI Termination is for the moment always enabled, I do not see this as an issue. If I discover that it should be software controlled I will tweak the design in the future.

Here is what the final board could look like :

That design is available on my GitHub.

Next steps

Wait for some feedbacks and eventually tweak a bit the current design (~1 week)
Manufacture some boards and assemble them (~1 month as boards will get manufactured in China)
Write an initial firmware and make sure design works as expected (~1 week to get basic stuff running)
Port the Nuvotech protocol to the board (and find a way to make it work with A/UX if time is found) (timing depends on so much things)
Try to distribute the board as a kit or pre-assembled (timing depends on so much things)

On The Technical Side

Schematics are available here (may not be up to date, check on my GitHub for latest content).

The design is based around an STM32F072R8, for three main reasons :

it’s an ARM chip, so development tools are open source and powerful (and I have experience with STM32 as well)
it has an USB DFU bootloader, so any end-user will be able to upgrade the board without expensive hardware flashing tool
it has a lot of GPIOs that is necessary to talk using SCSI

The signals between the STM32 and the SCSI are divided into three main categories :

SCSI -> STM32 (ATN, ACK, …) : these are unidirectional signals from initiator, I use a 74LVC14 chip to do the level conversion. Indeed the SCSI bus communicates at 2.85V but some peripherals can talk at 5.5V, so we need to protect the STM32 which does not have a lot of 5V tolerant GPIOS.

STM32 -> SCSI (CD, IO, …) : these are unidirectional signals from target, I use multiple 74LVTH126 to drive these control pins in Open Drain, this make sure no device on the bus can be damaged in case of multiple devices talking at the same time. This also make sure the board talks at the 2.85V SCSI voltage.

STM32 <-> SCSI : bidirectional signals that will use the 74LVTH126 and the 74LVC14. One particularity is the data lines. You may have noticed that the 74LVC14 inverts the signal logic. This is not an issue for control lines, as software can handle inverted signal with simple not. The problem for the data lines is that you often want to transfer the data received as quickly as possible to your peripheral (here the Ethernet chip). If you want to be fast you don’t want to not all received data before transfering, that’s why you’ll see the 74LVC245 chip handling the received data line that does the level convert without inverting the data.

You may now wonder where does the 2.85V comes from. I use a simple adjustable LM1117 to generate it, but you may notice that it produces something more like 2.63V. It is due to the fact that termination resistors (RN1 and RN2) are supposed to be 110ohms, but 110ohms resistor networks are not available at the time of writing on DigiKey. So I chose the nearest available value which is 100ohms, and for that value the voltage should be 2.63V. (and yes SCSI devices need a termination to avoid reflection).

The rest is relatively classical design, the STM32 is connected to the Ethernet chip ENC28J60 by SPI. You can also notice the two schottky diodes managing the input voltage (USB and SCSI TRMPWRP) with a low lost voltage.

Don’t hesitate to give some feedback here !

My Mac SE/30 Is Back Alive

Sun, 25 Oct 2020 23:02:46 +0100

Or how I fixed my Mac SE/30 that was not booting unexpectedly

Updates

[02 November 2020] This article was also featured on Hackaday : BODGE WIRE SAVES A VINTAGE MAC SE/30 FROM THE HEAP

One day around a year ago I was playing with my SE/30 (the best looking computer ever) and I was trying to install Debian on it for fun. But after inserting some floppies and trying to boot from them the computer wouldn’t turn back on. I mean it would turn on but with weird static graphics and no sound at startup. I already had a hard time figuring out how I would boot Linux on that machine (which I succeeded at doing) that I did not want to spend more time fixing it.

Here is what I was left with :

A few weeks ago I really wanted to play again with my old Macintosh and experiment with A/UX, the first Apple unix OS ! So I started looking on the internet to see if the problem I had was common. And indeed it was ! I learnt it was called Simasimac and often happened because old electrolytic capacitors would leak. It could lead to two main things : traces could be connected together because this leak could be conductive, or it could corrode traces and make them not continuous anymore.

So I had to open my Mac SE/30 for the first time. Hopefully I had bought a few years ago the very long screwdrivers you need to open these vintage Macs. And after taking the logic board out I did notice some minor leakage but no sign of “cracks” on the capacitors. An easy solution I found on the internet was to wash the logic board in the dishwasher (crazy !?), and it happened to often solve the first problem of capacitor leaks : the short circuit between traces. As I had no dishwasher I took a tooth brush and wash the logic board under clear water insisting on areas with leakage. I let it dry for one big day, finished cleaning it with alcohol and tried to boot the SE/30 again. But it would still display those weird zebra stripes on the screen and would not boot.

The logic board before cleaning :

I also saw on the internet that a bad/discharged battery (the red one you see on the previous picture) could lead to boot problems and simasimac. I did not really trust this as I am convinced this is only used to keep time and some user settings (such as mouse speed) in a volatile RAM. And I knew it was discharged from a long time ago (even when the Mac did boot normally) because the Mac would not keep time when it was turned off. Anyway I would still need a new battery when the Mac would be back to normal so I bought one off Amazon, put it in and tried to boot again. But no surprise it still did not want to boot !

Later readings also taught me that if the simasimac stayed after Logic Board cleaning one solution could be to recap the all board. Thanks to this excellent article : https://recapamac.com.au/macintosh-se-30/ I was able to quickly buy the needed caps off DigiKey and receive them in less than 48 hours (even in France !).

For reference here are the parts I ordered :

Capacitance	DK Part Number	Qty
1uF	399-3730-1-ND	1
220uF	1572-1103-ND	1
470uF	1572-1494-ND	1
47uF	399-18075-1-ND	10

I would highly advise to recap your vintage Mac as soon as possible to avoid such issues I had (and that many others have). It could destroy your Logic Board and you could never boot you mac again. It’s quite easy to do if you have some equipment, patience and some little skills.

So I used my hot air gun to remove all these caps and most of the little one exploded. They do really smell awful when they do so, I would advise to do it in a well ventilated area. I have to say I was a bit scared to damage the PCB because some traces looked really fragile. I had some issues removing the axial capacitors because the original soldering tin was hard to melt. I’m not sure why, I tried to change temperature from 300 degrees Celsius to 400, but it was not really easy.

I then soldered back every caps, again axial caps where hard to put back because even with my desoldering needles I had a hard time putting the capacitors legs through the holes. Anyway, everything was soldered back :

I’m not super happy about the result, contacts are well made and well soldered but capacitors are not always well aligned.

But I was super excited because I thought my problem was be solved. Most sites and articles I read said recapping was the ultimate fixing step. So I confidently plugged everything back and turned on my Mac. Nothing was fixed at all, it was still in the same state as the beginning.

So I was back to reading articles, blog posts, forums and reddit to find people having the same issues. I found out bad RAM chips could lead to my issue, so I started removing RAM bars or swapping them but nothing changed. So I posted to Reddit to get some feedback and advice : https://www.reddit.com/r/VintageApple/comments/jh5oo1/simasimac_even_after_recapping_any_hint_or_advice/

I learnt that it could be a problem with the ROM : either the chip itself or the traces between the CPU and the ROM. I did not really know where to start, so I searched for the SE/30 schematics and found them here : https://museo.freaknet.org/gallery/apple/stuff/mac/andreas.kann/schemat.html I noticed the ROM is directly connected to the CPU (which is in fact of no surprise and classical design as it is the first boot device). So I searched for the 68030 (CPU) pinout on Google and found it at the end of the NXP datasheet : https://www.nxp.com/docs/en/reference-manual/MC68030UM.pdf The next thing I had to do is to make sure each address trace, and each data trace was well connected between the CPU and the ROM socket. I used my multimeter in continuous mode and got the following pin mapping on the Logic Board :

So I knew my CPU was well connected to my ROM. My ROM itself could have defects but I wanted to make sure every peripherals worked before buying a new ROM because they are quite expensive on eBay.

After some more discussion on Reddit I decided to do the same thing I did with ROM but for the RAM. If you look at the schematics you’ll notice that the connections between the RAM and the CPU is a bit more complex because it involves many more logic (for paging for instance). So I started to check the traces between the CPU and the Glue Logic Chip (which is the chip between the CPU and the RAM). Still using the schematics I noticed that not all address bus bits were connected between these two chips. So I tested the one that were supposed to be connected with my multimeter, and I found out that the A24 trace seemed to be not continuous :

I was half surprised because the A24 trace goes below the C11 capacitor. And that non continuous trace could be explained by the fact that the old C11 capacitor leaked, and that the leakage corroded or destroyed the trace. So I did a hot fix with a stripping wire going directly from the Glue Chip to the CPU :

I then plugged everything back, and success !! It’s alive ! The weird zebra stripes had disappeared and it was showing the mouse cursor !

Unfortunately it does not boot from the internal hard drive, I’m not sure if I wiped it when trying to install Linux or not. So I created a new floppy boot disk with System 7.5. But unfortunately again the SE/30 does not want to boot from that floppy disk. I am still a bit confused as the floppy drive used to work really well. So I removed it from the Mac case and cleaned the drive heads with alcohol. But still, it doesn’t want to boot from my floppy. I guess the next step is to dismantle the whole floppy drive and give it a good clean. In the mean time I bought a SCSI2SD which will make everything easier and more reliable.

Thanks again to everyone on Reddit who did advise me well on how to spot the issue on my Mac SE/30. Today the floppy drive problem does not frighten me as I’m confident to fix it easily, and even if I don’t fix it I will be able to use the SCSI2SD to boot and use my SE/30.

Turning an Arduino into a Logitech Wireless Mouse

Thu, 02 Feb 2017 21:00:00 +0100

A 2 euros radio module, a Logitech Unifying dongle and a mouse you wear on your wrist : our last year project at Supélec

Updates

[10 March 2018] This project was featured on Hackaday : WIRELESS PROTOCOL REVERSE ENGINEERED TO CREATE WRIST WEARABLE MOUSE

This winter, for our last year project at Supélec, Guilhem and I had to build a wireless 3D mouse : you move your arm, the cursor moves on the screen. I took care of the wireless part and Guilhem of the motion sensing.

Why not just make our own dongle ?

The obvious way to do it is to make two boards : one in the mouse and one plugged into the computer. Our first version did exactly that, with an mbed board and an nRF24L01 radio module acting as a USB mouse. It worked, but it was boring. Everybody already has a Logitech dongle plugged into their computer, so why not talk to it directly ?

Opening a Logitech keyboard

I had a Logitech wireless keyboard (the one with the touchpad) at home, so I opened it to see which radio it used. The chip is an nRF24LE1 from Nordic : basically an nRF24L01, the 2 euros module everybody uses with Arduinos, with a microcontroller in the same package. That was great news : it meant we could speak the same “language” as the dongle with cheap off the shelf modules.

Listening to the pairing

With an nRF24 in sniffing mode we found the address the dongle listens to when it is in pairing mode, and the channels it uses : 25 channels, 3 MHz apart starting at 2402 MHz.

Then we put the dongle in pairing mode with the Unifying software, paired the keyboard and recorded everything. The pairing is made of 4 packets sent by the device. Each one starts with a packet type and the step number of the pairing, and ends with a checksum. The checksum turned out to be simple : add up all the bytes and negate the result.

The tricky part was the answers. The dongle never sends packets of its own : it replies inside the acknowledgement of our packets (the nRF24 “ACK payload” feature). So the device sends a packet, then a short one just to give the dongle a chance to reply, and reads the answer in the ACK. In the first answer the dongle gives the new address the device must use from now on.

Once we replayed these 4 packets from an Arduino, with the new address and the right checksums, the Unifying software was happy. It even told us our Arduino was a keyboard, since we had copied the keyboard’s packets !

Moving the mouse

Once paired, moving the mouse is easy. A movement packet holds the state of the buttons, the X and Y velocity, the vertical and horizontal scroll and, of course, the checksum.

We wrapped all of this in a small Arduino library : begin(), pair(), reconnect() to reuse a previous pairing, then move(), scroll() and click(). The code is on GitHub : ronangaillard/logitech-mouse. The example makes the cursor draw circles on the screen.

The 3D mouse

For the motion part Guilhem used an MPU6050, a 6 axis IMU that costs less than 2 dollars. The first idea was to integrate the acceleration to get the speed of the arm. It did not work : the small error on the acceleration adds up and the speed drifts away, even when the sensor does not move.

So we switched to the orientation of the sensor, computed by the MPU6050 itself. The yaw moves the cursor horizontally, the pitch vertically, and the roll changes the behaviour (right click, scrolling). A click is detected when you tap your fingers : it makes a very characteristic high frequency signal on the 3 axes.

Everything fits in a 3D printed case : an Arduino Nano, the nRF24L01, the MPU6050 and 4 CR2025 coin cells.

And here it is in action :

Of course Bluetooth would have been simpler, but the point of the project was to build the whole communication chain ourselves. And having an Arduino that can pair with any Logitech dongle is quite fun.

The presentation we gave at the end of the project (in French) is here.

XTrem Kernel : my Own RTOS for ARM Cortex M3

Thu, 14 Jul 2016 22:20:00 +0200

Tasks, priorities, semaphores, mutexes and a little shell, written from scratch for the mbed LPC1768

I wrote XTrem Kernel in 2015 and it has been sitting on my hard drive since then, so I just put it on GitHub : ronangaillard/xtremkernel.

I wanted to know what really happens inside a real time operating system, and the best way to know was to write one. In less than two months I wrote a multitask kernel for ARM Cortex M3 processors : thousands of lines of low level C and a few hundred lines of assembly. It runs on the NXP LPC17XX chips, so on the original mbed LPC1768 board.

The kernel

A SysTick interrupt every millisecond gives the kernel its heartbeat. The scheduler keeps one queue of runnable tasks per priority level, always runs the highest priority one, and does round robin between tasks of the same priority.

The context switch itself is a few lines of assembly in the PendSV handler, the lowest priority interrupt of the Cortex M3 : it saves the registers of the current task on its stack, switches the stack pointer, and restores the registers of the next one. The Cortex M3 port of TNKernel was a great help to understand how to do it.

On top of that the kernel provides what you expect from an RTOS :

tasks with priorities, created with their own stack, and sleep()
timers and timeouts
semaphores
mutexes, with priority inheritance : when a high priority task waits for a mutex, the task holding it temporarily gets its priority, so it can’t be blocked by a medium priority task

The screenshot above is the classic first test : two tasks printing on the serial port, task 1 more often than task 2.

A small computer

Once the kernel worked, I wanted to use it for something. So I added :

a basic shell (ls, mount, whoami, reboot…)
a PS/2 keyboard driver
a VGA output through a Gameduino board on the SPI bus, with an 8x8 font
SD card support, with the FatFs module to read files and navigate in folders

With the keyboard and the screen, the mbed became a small standalone computer, running my own OS.

The next steps were to load binaries from the SD card and run them as tasks, and to move the shell and the FAT support out of the kernel and load them as modules, UNIX style. The hardware specific code is well separated from the kernel core, so porting it to other ARM processors should be easy too.

A Lamp That Reacts to Music

Thu, 19 Mar 2015 16:15:00 +0100

A CD spindle, RGB LEDs, an Arduino, and a beat detection algorithm running on my computer

I wanted a lamp that changes color on the beat of the music, whatever the song style and whatever the volume. Here it is :

The lamp

The lamp is an old CD spindle case, with RGB LEDs I soldered in bands inside. An Arduino in the lamp drives the LEDs, and listens to the computer on the USB port.

Detecting the beat

The hard part is on the computer side, in Processing. The program does an FFT of the sound to split it into frequency bands. For each band it computes two averages of the energy : a long term one and a short term one. When the short term average jumps above the long term one, that’s a beat. Since everything is relative to the long term average, it works with a quiet song as well as with a loud one, and with any style of music.

At each beat the computer sends a random color to the Arduino, and the lamp changes color.

The videos

A first version in October 2014, in a tall column lamp :

The new lamp in its CD case, with the Processing program on the laptop :

And the final version :

Arduino as a PIC Programmer

Mon, 20 Feb 2012 19:12:00 +0100

Burning Microchip PICs from USB with an Arduino Uno, a resistor and a 12V supply

Updates

[3 March 2012] New version of the C# program and of the Arduino firmware, it now works with many 16F PICs.
[May 2012] Other people built on it : a version for the PIC18F family and a programmer for PIC32. Each PIC family has its own programming protocol and I am a student with a lot of homework, so I can’t maintain it anymore.
[2016] More than 20,000 downloads !
[2020] Eight years later, people are still posting their PIC references in the forum thread, hoping theirs is supported.

PIC microcontrollers are everywhere, but programming them needs a dedicated programmer. The cheap ones use a serial or parallel port that no modern computer has anymore, and the USB ones are expensive. I had an Arduino, so I wondered : why not make it do the job ?

The circuit

A PIC is programmed through ICSP (In-Circuit Serial Programming) : a clock line, a data line, and 12V on the MCLR pin to put the chip in programming mode. The Arduino handles the clock and data, and the 12V comes from an external supply.

That’s all : pin 8 is the data line through a 330 Ω resistor, pin 9 the clock, and pins 4, 5 and 6 are tied together to power the PIC. I used a PIC 16F628, but it should work with most 16F PICs. One safety rule : always reset the Arduino before putting the 12V.

The firmware

The Arduino sketch bit-bangs the ICSP protocol described in the Microchip datasheets : a 6 bit command, then a 16 bit word for the data (a start bit, 14 bits of data and a stop bit). On the USB side it accepts simple one letter commands on the serial port :

s : start in High Voltage Programming mode (S for Low Voltage)
wXXXXXXXXXXXXXX : write a word at the location pointed by the program counter
i : increment the program counter
r : read the current location
e : erase the full program memory
R : reset the PIC (program counter back to 0)

Every command answers D when it is done.

The software

Typing words one by one in the serial monitor gets old fast, so I wrote a small C# program for Windows. It reads a .hex file, sends it word by word to the Arduino, writes the configuration word, and can read the program memory back to check it.

Screenshot : Nishant_Sood, the first one to try it on the forum

It’s still a first version, so check your PIC with a regular programmer if you can. The code, the C# program and the list of tested PICs are on the Arduino forum : if you try it with another PIC, tell me there so I can add it to the list !

MiniOS : an Arduino Talking to a Minitel

Thu, 15 Apr 2010 18:54:00 +0200

A DIN plug, a resistor and an Arduino Mega to bring the good old French Minitel back to life

Updates

[16 April 2010] This project was featured on the Arduino blog : Minitel is not dead!
[20 December 2013] The photos were featured on TEXT-MODE, a blog about text graphics through the ages (ASCII, PETSCII, Teletext, mosaics…)

The Minitel is the French terminal that brought online services to millions of homes long before the Internet. There are still plenty of them sleeping in attics, and they have a nice feature : a “péri-informatique” DIN socket at the back, which is just a serial port. So I plugged an Arduino into one and wrote MiniOS, a tiny OS for the Minitel.

The wiring

There is not much to it : a male DIN plug wired to the second serial port of an Arduino Mega, and a 4.7 kΩ resistor. The two LEDs are only there to show what is going on.

The Minitel speaks at 1200 bauds, with 7 data bits and an even parity bit. The Arduino serial library could not do that at the time, so I set the UART register directly before starting the port :

UCSR1C = B00100100; // 7 bits + parity bit
Serial1.begin(1200);

Drawing on the screen

Once connected, the Minitel behaves like a simple terminal : you send it text, and control codes to move the cursor, clear the screen or change the font. For example ESC followed by O makes the text double size, ESC H makes it blink and ESC ] inverts the background. The whole OS is just a few functions that print screens and wait for a key :

a boot screen, with a blinking “Appuyez sur une touche…” (press any key)
a menu, quite empty I admit
“Fakebook”, for fun
the credits

All the code (a single file) is in the forum thread.

What happened next

I posted it on the French Arduino forum and the Arduino blog picked it up the next day. Other people rebuilt it, ported it to the Duemilanove (replace Serial1 with Serial and UCSR1C with UCSR0C), mapped the keys of the keyboard, and even added a speaker to play music. Not bad for a menu with two entries !

Ronan Gaillard's Workshop

Teaching my Fujifilm X-T30 II to Print on an instax Link 3

The Problem

Rule zero: don’t brick the camera

Step 1: Opening the firmware

Step 2: The code was already there

Step 3: Writing the missing piece

Step 4: Running it without flashing

Step 5: Debugging blind

The pink ghost

It works!

Tools and sources

What’s next

Factory DS: a Factorio-like on a 67 MHz Nintendo DS

Why the Nintendo DS?

Getting started on a console I had never touched

The first specs

A world that does not fit in memory

Machines, recipes and ratios

Power grids and pipes

All aboard

Wires, clocks and logic gates

Testing (and balancing) a DS game without a DS

Hitting the performance wall

Playing it, again and again

The finishing touches

Next: the real console

Reverse Engineering the Epson FilmScan 200 for Classic Mac

The Problem

Understanding the Hardware

Setting Up the Development Environment

First Success: Single Frame Scan

The Frame Selection Problem

The Breakthrough: A Hidden Website

Adding Color Support

The Final Result

Lessons Learned

From Frustration to App Store: The Story of Workspace Profiles

The Problem: The Tyranny of Manual Settings

The Solution: Profiles for Every Workspace

A Technical Look Under the Hood

Detecting Hardware Changes

Handling Notification “Bursts”

Implementing Global Keyboard Shortcuts

What’s Next

A Cheap and Simple ADB to USB Converter

The board

Flashing

What happened next

68net : A Modern SCSI2Ethernet Board - Part 1

Introduction

Next steps

On The Technical Side

My Mac SE/30 Is Back Alive

Turning an Arduino into a Logitech Wireless Mouse

Why not just make our own dongle ?

Opening a Logitech keyboard

Listening to the pairing

Moving the mouse

The 3D mouse

XTrem Kernel : my Own RTOS for ARM Cortex M3

The kernel

A small computer

A Lamp That Reacts to Music

The lamp

Detecting the beat

The videos

Arduino as a PIC Programmer

The circuit

The firmware

The software

MiniOS : an Arduino Talking to a Minitel

The wiring

Drawing on the screen

What happened next