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.
What’s Included?
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.
Conclusion
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.
Addendum: SMALLDIR
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.
MSDOS.ASM includes a note that SMALLDIR was “killed” in v1.20 so there should be a few post v1.00 releases supporting both 16 and 32 byte directory entries, most likely for the early adoptees that were not IBM.
There are a few videos showing little bits of the early 86-DOS operation. 0.11 supports CALL 5. Multiple files with the same name were supported on the disk which was to be expected considering that READCPM doesn’t have the ability to specify user number.
Actually IBM did have DOS with 16-byte directory entries. In the COMMENTS file on PC DOS 0.90 (as we decided to call it), there is a mention of three different disk formats. The newest was the one PC DOS 1.0 used, with one reserved sector and 32-byte directory entries; this was introduced on 4/15/81. The older format had two reserved tracks and clearly also 32-bit directory entries, and did prompt for date at startup. However, the oldest format IBM mentioned had two reserved tracks and clearly 16-byte directory entries. The file mentions that the oldest DOS did not prompt for date at startup, and that the intermediate disk format was used for converting disks “to the new format directory”.
^Z is not ESC.
ESC is #27.
^Z is #26, which is SUB — SUBstitute character. It was intended to be used for padding to fixed-size blocks, which is exactly what it does here.
https://en.wikipedia.org/wiki/Substitute_character
Somebody figured out the nice trick of also using #26 as an EOF indicator because that would automatically render the correct behaviour when reading text files as sequential blocks.
Thanks, corrected the article.
and there is a port of 86-dos 0.11 to IBM PC: https://forum.vcfed.org/index.php?threads/earliest-known-copies-of-86-dos.1246146/post-1360046
It would be interesting to know how these early DOS versions were able to distinguish between all these diskette formats (I mean, 2 reserved tracks vs no reserved tracks, 16-byte directory entry vs 32-byte, etc.) After all, the BPB only appeared much later, in DOS 2.0 . It’s known that DOS 1.x used an alternative, if similar mechanism – FAT ID ( https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system#FATID ). But as far as I can understand things, to access the FAT ID, the system must first be able to find the FAT, and I’m not sure that it was trivial, due to the varying locations where the FATs could be written on the disks.
I think they just didn’t. You had an IO.SYS configured in some way and that was it.
Actually it would have been possible to have say drives A: and B: set up for disks with two reserved tracks and drives C: and D: mapping to the same physical drives but using just one reserved sector.
The MSDOS.ASM source for DOS 1.25 says that the first FAT entry was used to distinguish between 16-byte and 32-byte directory entries “if SMALLDIR is selected” (as a compile time option, presumably). Exactly how it was done is not clear. I believe it may have been the low bit of the first (12-bit) FAT entry. More research is needed.
“The MSDOS.ASM source for DOS 1.25 says that the first FAT entry was used to distinguish between 16-byte and 32-byte directory entries “if SMALLDIR is selected” ”
Interesting. I believe that the very first FAT entry from the first FAT copy (which corresponds to non-existing cluster number zero) happens to be exactly the “FAT ID” that later evolved into the “Media descriptor byte” from the BPB. Knowing where the first FAT is located (depending on whether two reserved tracks exist) it seems a feasible way for a DOS to determine the diskette format at runtime (16-byte vs 32-byte directory etc.) Maybe if this SMALLDIR was defined, then DOS 1.00 could read both disk formats, who knows?
Anyway, it would be interesting to know, what were the FAT IDs (first byte from the first FAT) of the 16-byte and the 32-byte Tarbell 8 inch diskettes used by DOS 0.11/0.34/1.00 . It would help to make the table at https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system#FATID more complete and more informative. There are some values there that look rather dubious.
OK, as far as I can tell, the old 86-DOS 0.x disks simply had 0xFF in the first FAT byte, and starting with 86-DOS 1.0 the first byte was 0xFE. Chances are that in those versions, the low bit indicated 16-bit directory entries when set.
However, I am pretty sure that in those days, the first FAT byte had no further meaning and didn’t say anything about the disk format.
“Unlike 86-DOS 1.0 from April 1984”
Should be April 1981 maybe?
Definitely. Thanks, fixed.
“OK, as far as I can tell, the old 86-DOS 0.x disks simply had 0xFF in the first FAT byte, and starting with 86-DOS 1.0 the first byte was 0xFE. Chances are that in those versions, the low bit indicated 16-bit directory entries when set.”
Ah yes, that must be it. Thanks for the info.
“However, I am pretty sure that in those days, the first FAT byte had no further meaning and didn’t say anything about the disk format.”
Definitely true in SCP/Tim Paterson context; and obvious if we remember the fact that essentially, the particular floppy controller SCP were using supported exactly one disk format for 8” diskettes; yet QDOS started being distributed to OEMs very early, during the times of 16-byte directory entry, and OEMs might have used different floppy controllers, different diskettes, formats etc. Sadly, we’ll likely never know.
IO.ASM has a list of all the disk formats supported by 86-DOS by controller. It seems that the drive identifier indicates which formats the drive supports. The Convert option lets the user choose between SCP or MS formats by using different drive letters to refer to the same drive. There is code for both SCP and Cromemco controllers to determine if the disk is 8″ or 5.25″ and the density to get to the one format that will be used. The density check is very simple. Try a read; if it fails, try the other density. Fortunately, mixed density formats never appeared in the micro world. The directory entry size is the only detail not obvious from the information returned by the disk controller.
INIT.ASM seems to confirm that by only having a single format available when compiled thus INITLARG and INITSMAL to format both 8″ and 5.25″ disks. There does not seem to be any provision for create new single density disks on a double density drive.
We know some of it. 86-DOS supported Tarbell and Cromemco floppy controllers quite early (86-DOS 0.34 for sure), and Cromemco supported both 8″ and 5.25″ drives. The 8″ and 5.25″ formats were not identical. The 5.25″ disks likely had 40 tracks with eighteen 128-byte sectors each. It was up to the I/O subsystem (IO.SYS equivalent) to tell DOS how those disks were structured (reserved sectors, cluster size, number of directory entries, FAT size and number, etc.) and deal with all low level access.
In other words, 86-DOS had no preconceptions about the exact FAT format, it was all up to the I/O subsystem and OEMs supplied that.
@Richard Wells
“There does not seem to be any provision for create new single density disks on a double density drive.”
I’m sorry for the nit-picking, but are you sure that there is such a thing as a “double density drive”? Did you mean “double density controller”?
IMHO, floppy drives are notoriously dumb beasts. I very much doubt they’ve ever been able to make any difference between FM and MFM (or even GCR, for that matter). We know that 500kbit/sec MFM and 250kbit/sec FM look similar enough at low level (magnetic flux level) so that a dumb device like a drive can’t distinguish them. Drives just pass through the low level signal between the controller and the medium back and forth. A “single density drive” than can 250kbit/sec FM (standard 250Kb 8” diskette) should also can 500kbit/sec MFM (hypothetical 500Kb SS/DD 8” format), provided that the controller can it too.
SCP defined things based on the drive. If the drive is set as double density, that is how it is treated. It was certainly possible to attach single density drives to double density controllers.
The earliest single density drives lacked the ability to push data through at MFM rates. You couldn’t simply attach a 43D to a double density controller and magically double the capacity. Now, by about 1978 or so, all the components to handle double density were so cheap that very few single density drives weren’t actually double density drives with double density turned off so few in the PC world ever saw that.
The standard floppy disk drive had a logic board that did a lot of the processing of the sector and automatically changing write current. All that made it quite expensive which shows up with much cheaper Apple Disk II design that stripped out all the controller and drive logic.
“(note the somewhat unfamiliar SCP assembler syntax)” – Do you mean first column comments or label, second column instruction, third column parameters?
I have seen that with assembly for early microprocessors. I believe that is a vestige from punched cards where some columns could have special meanings for the programs, like the first Fortran version.
Actually no… the columnar layout is indeed not that unusual. What I had in mind is e.g. using UP instead of CLD or LODB instead of LODSB.
Pingback: Tarbell to Cromemco | OS/2 Museum
“There’s considerably more than that on the disk… but it’s not very useful.”
That’s because the disk itself is most probably not an original, and some kid learning Assembly language had been playing with it. I find it hard to believe that Tim Paterson wrote the funny stuff 🙂
This might also mean that 86-DOS 0.34 was probably released closer to the final days of 1980 (as the published MSDOS source code claims) than to February 20, 1981.
In fact, the “f15sim” guy who released 86-DOS 0.11 and 0.34 on Internet Archive uploaded TWO different versions of 0.34 . You’re working with the earlier one, uploaded on Dec 29, and also found on Bitsavers. But another one, apparently much closer to the original (or the original itself) was uploaded on Dec 31, under the name 86-DOS 0.34 C. It is the correct image we should be working with, IMHO. It lacks the funny stuff, and has just what’s related to DOS itself.
Sure, the original disk is a better reference… but it’s not really any different, except EDLIN was renamed to EDIT. It just has obvious extra junk on it.
As for when 0.34 was released… that’s really hard to say. I think all we can reliably say is “between Dec 29, 1980 and Feb 20, 1981”. I agree that it was probably closer to late December.
Interesting, thanks for this post!
Seems like there are a few “16-bit” and “32-bit” (rather than bytes) typos still in the text.
Richard Wells: Side track: Afaik the Atari 8-bit disk drives used mixed density. Not relevant to 86-DOS and whatnot, but still an example of a micro computer with mixed density.
Michal: “The 5.25″ disks likely had 40 tracks”. IIRC I’ve brought up this subject before in comments to earlier posts, but I can’t remember the details. Do we know exactly when 5.25″ drives transitioned from 35 to 40 tracks? (It seems like most FM/MFM formats switched to 40 tracks “immediately” while the GCR formats that used variable data rate kept using 35 tracks as they would had needed an additional data rate to properly use track 36-40. Btw, this is also the reason for questionable disks and drives tend to fail on the higher tracks with FM/MFM drives/controllers – the data rate per physical length on the media is higher on the higher tracks on FM/MFM drives while GCR drives generally tries to keep it about the same across the disk. Also btw, the first disks being 35 tracks is most likely the reason for the weird 100 TPI drives, as using 100 TPI made it possible to have 77 tracks (like 8″ drives) within the same space as 35 tracks using 48 TPI).
Fixed the byte/bit thing, thanks!
I have no idea about 5.25″ drives… AFAIK the IBM PC was an early-ish 5.25″ system, and used 40 tracks of course. But I’m not sure when 5.25″ drives really started out.
Seems a bit hard to find out when the first 40 track 5.25″ drive came out :O
https://en.wikipedia.org/wiki/Shugart_Associates
“The 5+1⁄4-inch floppy disk drive was introduced by Shugart in September 1976 as the Shugart SA-400 Minifloppy” and “The original SA-400 was single-sided with 35-tracks”
https://en.wikipedia.org/wiki/History_of_the_floppy_disk
“The new drive of this size stored 98.5 KB, later increased to 110 KB by adding five tracks”
There are two references to this, but they seem a bit lenghty to plow through. Maybe it’s time to add a “when?” thingie to the Wikipedia page to trigger someone else to eventually find out? 🙂