At the end of December 2023, several disk images of very old versions of Seattle Computer Products 86-DOS unexpectedly turned up. This includes previously unseen releases of 86-DOS version 0.11 and 0.34 (going by the version number in the 86-DOS kernel).
Just how old these releases are is somewhat difficult to establish. Unlike 86-DOS 1.0 from April 1981, the older versions used a different format of FAT directory entries. The old format only used 16 bytes per entry (rather than 32) and had no room to store any timestamps, much like CP/M formats of the era.
The 0.34 disk (8″ of course) has a handwritten label which includes a date, 81/02/20. If the disk was written and the label was made on February 20, 1981, the 86-DOS files on the disk are presumably not newer than late February 1981.
The file INIT.ASM on the 86-DOS 0.34 disk contains the following comment:
; Translated from the Z80 on 12-19-80 and subsequently upgraded to handle ; all of the following controllers. Set switch to one to select.
Assuming the comment is correct, 86-DOS 0.34 must have been released sometime after December 19, 1980 but before late February 1981.
The file MSDOS.ASM released by the Computer History Museum includes revision history that starts with version 0.34, which is dated as December 29, 1980. It is likely that the date refers to the DOS kernel itself and not necessarily when 86-DOS 0.34 was shipped to customers.
The 86-DOS 0.11 disk contains no real clues about its age. The sign-on message says “Copyright 1980 Seattle Computer Products, Inc.” which is not too helpful. An interview with Tim Paterson from 1983 suggests that “QDOS 0.11” was finalized in August 1980. While this is possible, the interview is somewhat questionable because there is no sign of “QDOS” in 86-DOS 0.11; the system clearly identifies itself as “86-DOS version 0.11”.
In any case, August 1980 is at least plausible as a release date of 86-DOS 0.11. If so, it would pre-date the release of the IBM PC (and PC DOS) by a whole year.
Old Directory Format
Cracking the ancient 16-byte FAT directory entry format took a little bit of effort, but in the end the format turned out to be very straightforward. There does not (yet) appear to be any public documentation of what the directory entries used to look like.
From looking at the disk images it’s obvious that the first 11 bytes are the file name and extension, just like in the newer 32-byte directory entry format. But the remaining five bytes were somewhat mysterious.
Logically, 86-DOS must have stored information about the starting cluster of a file, as well as the file size. But was there anything else?
The release notes for 86-DOS 1.0 mention that with the new 32-byte directory entry format, file sizes are no longer limited to 16 megabytes. At the same time, prior to 86-DOS 1.0, file size was only recorded with the granularity of 128-byte records (ever wondered why text files used to end with ASCII SUB aka Ctrl-Z?). Perhaps file sizes were stored in units of 128-byte records?
Upon closer examination, it turned out that the last three bytes of a 16-byte directory entry are simply the file size in bytes, stored in LSB order. Due to the 128-byte granularity, the low byte of the file size only ever contains the value 00h or 80h.
The remaining two bytes (at offset 11 and 12 in the directory entry) are the file’s starting cluster, again stored in LSB order.
The 16-byte directory entry is then formatted as follows:
- 8 bytes of file name, padded with spaces
- 3 bytes of file extension
- 2 bytes of starting cluster (LSB order)
- 3 bytes of file size in bytes (LSB order)
This information takes up 16 bytes and there is no room for timestamps, attributes, or anything else.
The 16-byte directory entry is a proper subset of the 32-byte directory entry, and is therefore easy to convert to a 32-byte entry with no date or time stamps and no attributes set.
The 86-DOS 0.11 disk has very little on it. There is COMMAND.COM, SYS, the RDCPM utility, plus the SCP development tools: EDLIN, ASM, TRANS, and HEX2BIN. There is no DEBUG yet, but there is a chess program of unknown provenance.
The 86-DOS 0.34 disk is rather more interesting. It newly includes CHKDSK, as well as DEBUG. There is also SCP source code for a firmware monitor, boot loader, and the 86-DOS I/O subsystem: MON.ASM, BOOT.ASM, and DOSIO.ASM. There’s also INIT.ASM, a low level floppy disk format utility.
There’s considerably more than that on the disk… but it’s not very useful. Consider the following (transcript from a SIMH simulator session):
SCP 8086 Monitor 1.5 >B ☺ 86-DOS version 0.34 Copyright 1980 Seattle Computer Products, Inc. COMMAND v. 0.2 A:aargh GEE... I DIDN'T KNOW YOU SPOKE CHINESE! A:damn! THERE'S NO NEED TO SWEAR! A:shit NOT HERE, PLEASE. IT STAINS THE CARPET. A:dir *.asm BOOT ASM 2688 CPMTAB ASM 1152 MON ASM 35584 INIT ASM 4992 DOSIO ASM 11008 MOVE ASM 512 DAMN ASM 384 SHIT! ASM 384 AARGH ASM 384 SPEEDCHK ASM 128 SHIT ASM 384 AARGH! ASM 384 A:
It is worth noticing that 86-DOS 0.34 displayed file sizes (in bytes), though of course no timestamps were shown. Version 0.11 only showed file names without any further information.
Here’s what AARGH.ASM contains (note the somewhat unfamiliar SCP assembler syntax):
; A PROGRAM TO EXPRESS HOW I FEEL. PUT 0100H ORG 0100H MOV CX,CHARCOUNT MOV SI,OUTBUFF UP LOOP: LODB MOV DL,AL MOV AH,2 INT 21H LOOP LOOP INT 20H ; BUFFERS AND CONSTANTS OUTBUFF: DM "GEE... I DIDN'T KNOW YOU SPOKE CHINESE!" CHARCOUNT: EQU 39 ; END OF *AARGH*
The contents of AARGH!.ASM, DAMN.ASM, etc. are quite similar. While the programs are all amusing, it would be an exaggeration to say that they are of historical significance.
However, the 86-DOS 0.34 disk as such is certainly historically significant, and shows just how far the development of 86-DOS was (or wasn’t) at the beginning of 1981.
For example, the DEBUG utility was able to single step programs and show register state or dump memory… but it was not yet able to disassemble instructions. It was clearly meant to be used with a printed program listing in hand, which is not something that’s always available.
Even after more than 40 years(!), old software releases and pre-releases can still surface. In the case of 86-DOS 0.11 and 0.34 it’s practically a miracle, since there were probably never very many copies in existence.
For the first time since the early 1980s, FAT formatted floppies with the primordial 16-byte directory entry format have come to light. The old 16-byte directory entries were gone by 86-DOS 1.0 in April 1981 and of course never appeared in any public PC DOS release.
These prehistoric versions of 86-DOS allow us to fill in further missing pieces in the puzzle of DOS origins. It is fascinating to follow how DOS developed from almost nothing to a multi-million dollar business in the course of just a few years.
The previously mentioned DOS 1.25 source code mentions that one of the changes in version 1.20 was to “Kill SMALLDIR”. Further comments mention that “Entry number zero [in the FAT] is used as an end-of-file trap in the OS and as a flag for directory entry size (if SMALLDIR selected).”
In the CREATE function, there is an unreferenced label called SMALLENT which is clearly a remnant of the SMALLDIR support.
Examining 86DOS.SYS in 86-DOS version 1.10 allows the reader to form a good idea about what the SMALLDIR logic was about. If the first FAT byte was FFh, the disk was considered to be using the original “small” 16-byte directory entries. Any other value (in practice FEh) indicated 32-byte directory entries.
All code locations where 86-DOS dealt with directory entries (not too many) checked the first FAT byte and used either 32-byte or 16-byte directory entries.
It is likely that starting with version 0.42 (02/25/81, “32-byte directory entries added”) and prior to version 1.20 (12/31/81), 86-DOS was (optionally) able to read and write disks with both 16-byte and 32-byte directory entries. 86-DOS 1.10 certainly appears to be able to do just that.
After several months, disks with 16-byte directory entries were considered obsolete and only the support for 32-byte directory entries remained.
Note that PC DOS 1.0 was apparently built with SMALLDIR not set and was thus only able to work with 32-byte directory entries.