86-DOS Revisited

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.

86-DOS version 0.34 disk

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
86-DOS version 0.34
Copyright 1980 Seattle Computer Products, Inc.

COMMAND v. 0.2

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


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):

        PUT     0100H
        ORG     0100H
        MOV     CX,CHARCOUNT
        MOV     SI,OUTBUFF
        MOV     DL,AL
        MOV     AH,2
        INT     21H
        LOOP    LOOP
        INT     20H
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.

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.

This entry was posted in DOS, PC history. Bookmark the permalink.

24 Responses to 86-DOS Revisited

  1. Richard Wells says:

    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.

  2. Michal Necasek says:

    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”.

  3. Peter Lund says:

    ^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.


    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.

  4. Michal Necasek says:

    Thanks, corrected the article.

  5. vbdasc says:

    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.

  6. Michal Necasek says:

    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.

  7. vbdasc says:

    “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.

  8. Michal Necasek says:

    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.

  9. random lurker says:

    “Unlike 86-DOS 1.0 from April 1984”

    Should be April 1981 maybe?

  10. Michal Necasek says:

    Definitely. Thanks, fixed.

  11. vbdasc says:

    “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.

  12. Richard Wells says:

    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.

  13. Michal Necasek says:

    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.

  14. vbdasc says:

    @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.

  15. Richard Wells says:

    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.

  16. Fernando says:

    “(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.

  17. Michal Necasek says:

    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.

  18. Pingback: Tarbell to Cromemco | OS/2 Museum

  19. vbdasc says:

    “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.

  20. Michal Necasek says:

    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.

  21. MiaM says:

    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).

  22. Michal Necasek says:

    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.

  23. MiaM says:

    Seems a bit hard to find out when the first 40 track 5.25″ drive came out :O

    “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”

    “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? 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.