GitHub – DOS 1.0: Transcription of Tim Paterson's DOS Printouts

s2l 136 points 9 comments April 29, 2026
github.com · View on Hacker News

Discussion Highlights (5 comments)

alberto-m

The official announcement contains many interesting complementary links: https://opensource.microsoft.com/blog/2026/04/28/continuing-...

shrubble

Now the debate over whether Gary Kildall’s claim of CP/M code being included in the first version of DOS can be examined in full; since the assembler code is available for scrutiny.

martinwoodward

The technology behind pulling together this is fantastic so def worth reading the links. Joshua's work around doing the OCR of the paper printouts and using the CRC's in the margin to self-error check is great. https://jscarsbrook.me/doshistory/

neilv

A guy I worked for owned a Seattle Computer Gazelle that he said "might be the one that DOS was written on". (Maybe he meant the model, rather than the exact serial number? But he was in the PNW, and I understand had been very involved in the early microcomputer scene there, so I wouldn't be surprised.) He was actively using it when he said this, so it still worked at the time. If he still has it, some company that built an empire atop DOS should find some money in the sofa cushions, and make him an offer.

marlburrow

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.

Semantic search powered by Rivestack pgvector
8,303 stories · 78,303 chunks indexed