The file corruption analysis in the writeup is fascinating. The hypothesis that bytes were silently dropped during an RS-232 serial transfer from SCP's 8-inch floppies to the DECSYSTEM-10 makes a lot of sense when you look at the pattern: the missing chunks cluster in contiguous runs rather than being scattered, which is exactly what you'd see from a loose connector or intermittent signal on a serial line with hardware flow control disabled. The fact that line numbers remain in perfect linear sequence through the corrupted sections is the real tell, since it proves the file was already damaged before it was last edited on TOPS-10.
The STORE bug discovery is equally interesting from a software archaeology perspective. The NOP-patching of the conditional jump instead of removing the dead code path is a classic binary hotfix pattern: when you can't afford a full reassembly cycle (or don't want to risk introducing other regressions), you just neutralize the problematic branch in-place. This is essentially the 1981 equivalent of a live-patched production binary, and it means every known copy of "86-DOS 1.00" was actually running 1.01 logic for file sizes above 64K.
The ROL vs RCL assembler bug writeup is a beautiful bitwise brain-teaser. The original code shifts through CX which mixes CH (the register holding relocation bits) into the rotation, contaminating the result. The pencil fix using RCL chains through the carry flag to keep the two data streams properly separated across the 9-bit-wide path. It's a reminder of how much mental overhead 8086 assembly required for operations that would be a single shift instruction on a modern ISA.
The DLE-escaping problem the article mentions — where 0x10 bytes in PCM audio had to be doubled to 0x10 0x10 — is the same class of bug that plagued the Hayes +++ escape sequence in data mode, and it is striking that it was never properly solved. The fundamental issue is that the Smartmodem architecture multiplexed control and bearer on a single serial channel, and every framing scheme for doing that with an 8-bit-clean payload on an async serial link is either fragile (in-band escaping) or wasteful (COBS/SLIP-style byte-stuffing adds overhead proportional to the escape density). The multi-UART solution that modern cellular modems adopted — separate serial channels for control, bearer, GNSS, debug, etc. — is really the only correct answer, and it is interesting that it took nearly two decades to become standard practice. What Harald Welte describes in his 2017 post is not so much an "ugly hack" as it is the inexorable gravitational pull of the Hayes architecture: once you have committed to AT commands over serial as your control plane, every new capability including real-time voice must be shoehorned into that same channel, and the result is always going to look awkward. The persistence of this design through winmodems, ISDN terminal adapters, and into modern 5G USB dongles is a textbook case of interface lock-in outweighing architectural fitness. On the IVR side, it is worth noting that Asterisk's early versions (circa 1999) supported voice modems via TAPI before the project pivoted hard to VoIP and never looked back — Mark Spencer reportedly called the TAPI voice modem support the single most painful integration in Asterisk's history, which says something about the state of V.253 interoperability in practice.
Really cool. Out of curiosity, what's the per-frame cost of rendering
the splat scene compared to an equivalent triangle-mesh approximation?
I've been wondering when (if ever) splatting becomes the default for
web-delivered 3D content vs. just a research/SIGGRAPH-paper toy.
Browser support and file-size feel like the two big walls.