Notes Concerning the
June, 1981 Pre-Release Copy
of IBM® Personal Computer DOS 1.00
(Also referred to as: "IBM PC DOS 0.90"; see below)
Web Presentation and Text are Copyright©2017 by Daniel B. Sedory
NOT to be reproduced in any form without Permission of the Author !
This page is about a June, 1981, pre-release version of the IBM® Personal Computer DOS 1.00 diskette; which wasn't completed until some time after August 13, 1981 (the latest dated file on that diskette). For a detailed examination of the DOS 1.00 release diskette, see our pages here. Neither IBM nor Microsoft assigned any version numbers (that we're aware of) to these IBM PC DOS diskettes prior to the production release of IBM PC DOS 1.00. However, apart from calling this a "June 1981 Pre-Release Copy" of IBM PC DOS, you should know that the image file of this diskette leaked to the OS/2 Museum used the filename "IBM-PCDOS_090" and was subsequently given that designation at the PCjs Machines web site. It has also appeared by that name on various other web sites; with copies available for download from servers all over the Net!
It turns out that the filename as leaked (via a 3rd party) can be traced back to me (see History section below). The disk from which this image
file was created was mailed to us in 2006 by retired IBM employee Dick Conklin (read our Brief History section for details).
Michal Necasek, at the OS/2 Museum, has done a good job of reviewing the whole image, so I also recommend reading his article at:
PC DOS 1.0, But Not Quite, after reading about its history below.
Some of the more important 'finds' on this disk include:
1) The full HEX2BIN.COM file; which we had already surmised was being used by the developers since we found a large piece of it in the Slack Space of the PC DOS 1.00 release diskette and were able to show a very high probability it was the same file found on an 86-DOS disk - which had also been confirmed by Tim Paterson. But now we have proof that the IBM developer's diskette contained this exact program; it is byte for byte identical.
2) The whole 20HAL.COM file, which we then knew for sure was an executable program; previously having seen the message "DEC-20 Downlink to Boca Raton [300-bps] 9-Apr-81" in the Slack Space of the PC DOS 1.00 diskette preceded by 22 hex bytes. Now, it's quite easy to see that all 22 of those bytes are part of this program's executable code.
3) ASM.COM - is almost identical to the ASM.COM program found on SCP's 86-DOS diskette. Both display the following when run:
|Seattle Computer Products 8086 Assembler Version 2.24|
Copyright 1979,80,81 by Seattle Computer Products, Inc.
In the Slack Space of Cluster 86 (Sector 91) you'll find "Version 2.10" of the Assembler mentioned. From ASM.ASM we know that version was created 22 FEB 81 and was revised again on 18 MAR 81, so here we have evidence of the slack space on this disk going back a few months prior to when it was last changed. If this diskette had not been in constant use all that time, then at least full disk copies of it had been (slack space is never copied to a new diskette unless you copy the whole disk; not just its files).
These and other 'finds' in this diskette image, show the IBM PC project (with Microsoft) began with the 86-DOS diskette, then both added new features and converted the operating system to run on the IBM hardware. But they also added many new IBM/Microsoft system utilities and Microsoft's BASIC language interpreters to arrive at the IBM PC DOS 1.00 release diskette.
In June, 1981, Richard ("Dick") Conklin was the IBM 'Product Planner' for their new PC project. He was a sort of middleman who worked with the various Programming and Marketing groups, Microsoft and others, to keep everything on schedule, and make sure their perception of the needs of the 'market' were being met. He also kept track of most of the problems that popped up along the way. "Don" Estridge (who tragically died on August 2, 1985) was the project leader, so Dick would have worked for him. During that time, both Dick and Don (any others?) were occasionally given full disk copies of the progress being made on what would become the final PC DOS 1.00 boot diskette.
About a year after I published my Forensic Exam of the PC DOS 1.00 Diskette, Dick wrote to me and asked if I wanted a "floppy containing a pre-release copy of DOS, something like 'PC-DOS 0.8'." He said it also contained "some interesting programmer comments in text files." (email from Dick Conklin, January 20, 2006). Well, of course I wanted a copy!
To show how easy it is for artifacts of computer history to be lost forever, Dick wrote to me late the next day: "I went through three drawers of old 3.5-inch floppies today, but haven't found it yet. There's no way I would ever throw it out. I'll keep looking. I hope it still can be read, because some of the other old floppies I found today were no longer readable." (email from Dick Conklin, January 21, 2006).
A couple days later, he wrote: "I tried to create a 'clean' disk that I could copy those old files onto, but couldn't make it work. The best I could do is boot up my original 3.5-inch DOS version 0.9 disk on my wife's old PC, then use the old DISKCOPY program to make copies (one of which I am sending you) to make more copies. Even then, some of the disks I used wouldn't accept the files: something about a Track 0 error." (email dated January 23, 2006). At that time, I was quite relieved he couldn't make a "clean disk" since it might have only the files and no slack space data!
After receiving and examining the disk Dick sent me, I wrote: "As soon as I saw it in the box today, I set up to make an image file of it! I used one of the old Norton DOS diskedit programs to view the sectors on the diskette and make an image copy to my HDD of exactly 320 sectors (160 KiB). This is 'gold' in terms of an historical viewpoint ... thank you very much for both keeping and making me a copy!" (email from myself to Dick Conklin, January 25, 2006; which included a copy of the image file I made and labeled as "320s_img.bin" in a ZIP file) Note: I was very happy to find that although Dick had sent me a 3.5-inch floppy disk, it actually contained an image of an original 5-1/4 inch diskette with ALL the Slack Space intact. There would have been somewhat less 'historical information' and questions about whether the disk was authentic without those extra bytes! Obviously, someone; possibly even Dick himself, had used a program that copied every sector of the original diskette to this later floppy technology.
In an email dated January 27, 2006, Dick again referred to the image file I'd made and sent back to him as "DOS 0.9" since we needed some way to refer to it (in my emails, I had referred to it as 'DOS 0.xx'). So, with Dick's twice suggested '0.90', after reviewing and comparing the files it contained to those on the final release diskette, I decided to label it as '0.90' as well; again, simply as a quick way to refer to it.
After attempting to 'boot' the image file under BOCHS and not being able to do so, I then had many other things to deal with in my life, such as job changes, moving (twice!), family issues, etc. etc. But, late in 2008, after being contacted by someone who worked at a prestigious technical university, whom I had some fruitful email exchanges with about DOS, I decided to give him a copy of this disk for 'educational purposes'; which was identical to the image file I made for Dick Conklin; except this time, I labeled the image file "IBM-PCDOS_090.bin" (still on an email server 'in the cloud'). Cut to almost 10 years later (when I'd almost completely forgot about this), and that former teacher and researcher was the 3rd party who leaked it to Michal Necasek at the OS/2 Museum; which I'm glad is now out for the public and PC historians to review, appreciate and perhaps find some answers to old questions, and think of new ones.
A very close copy of the image file can be downloaded by using the "save" button in the bottom menu as soon as this page has fully loaded: pcjs.org/disks/pcx86/dos/ibm/0.90/. Note: If you want to examine the file in
WinHex or some other Windows tool, we'd recommend editing the Boot Sector so that its last 2 bytes are 0x55 and 0xAA in that order. Be aware, that
this copy at PCjs already had some changes made to it:
1) The Boot Sector had been slightly altered by adding some BPB hex bytes to make it compatible with the PCjs simulator. The bytes shown in RED below, must be edited back to the characters (or set to zero) as shown by those in BLUE in the 'Figure 2' in order to make it exactly like an IBM PC DOS 1.00 Boot Sector:
Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F 0000 EB 2F 14 00 00 00 60 00 20 37 2D 00 02 01 01 00 ë/....`. 7-..... 0010 02 40 00 40 01 FE 01 00 08 00 01 00 00 00 00 00 .@.@.þ.......... Figure 1. Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F 0000 EB 2F 14 00 00 00 60 00 20 37 2D 4D 61 79 2D 38 ë/....`. 7-May-8 0010 31 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1............... Figure 2.
2) The AUTOEXEC.BAT file had its file name changed to: AUTOEXEC.BAK to prevent it from running at boot-up. To make it like the original,
change the character or byte at offset 0x82A from 4Bh ("K") to 54h ("T").
We recommend having both a copy of the original image file, and one you can open in WinHex or some other Windows tool.
The MD5 Checksum of the image file I made (of this June, 1981, Pre-Release version of IBM PC DOS 1.00) from the disk that Dick Conklin
sent me is:
If you get a different MD5 sum, or you'd rather contact me directly for a copy, you can email me here.
Note: It's also possible to run this image file under PCE. I'll have more to say about this in a future update.
Some comments from Dick about the disk he sent me:
The AUTOEXEC.BAT file runs two programs which create a BASIC interpreter environment: MOVBAS and BAS18. As I recall, neither BASIC.COM (BASIC without
graphics functions) [nor] BASICA were ready for prime time, so the MOVBAS and BAS18 programs (run in succession) were some kind of kluge that allowed BASIC
programs to run. Once you are in BASIC you can enter the FILES command to get a list of files on the disk. You can RUN (RUN "XYZ.BAS") BASIC programs,
which end in ".BAS" and ".MAC". I don't remember the significance of the .MAC file type. ...
Check out "20HAL" [and TTY.ASC] a communications program running at a screaming 300 baud that was used to exchange software.
Anyway, have fun with the disk, which I will mail tomorrow. If you have any questions, fire away, but I may not be able to answer them due to a 25-year memory lapse or because I was never involved in the bits-and-bytes level of things, just the big picture. As I remember, BASIC took up a lot of our attention, because in 1981, even with a starter set of applications, we still felt that most users would use BASIC for much of their work. It didn't take very long to realize that the world was quickly moving to ready-made apps and away from do-it-yourself programming.
At some time, there had been at least an 'Introductory phrase' about how to use a new PC DOS version, because the Slack Space of Cluster 109 contains the words: "LOOK AT FILE 'COMMENTS' BEFORE PROCEEDING." This not only could have been included in the AUTOEXEC.BAT file, but is in fact found in the slack space immediately after the 'end of file' mark (0x1A) of the current AUTOEXEC.BAT file!
As Dick mentioned, there is a COMMENTS file from one of the programmers(?) describing recent changes made to the diskette; the same words are also included in the COMMENTS.BAK file, except it has the misspelled word 'scren' (instead of 'screen'. I can't help but wonder if any important slack space data was lost due to that single correction? Yet 2 other spelling errors were not corrected). With the exception of 2 line returns being removed and all of the underlines, highlights AND notes in RED being my own, here's that file (which contains a little dry humor from its author only in note # 2):
Notes about this diskette 6/5/81 1. The autoexec facility has been fixed, and works on this system. 2. The system files1 have reverted to upper case letters again, but will not be included in any directory searches because of a new byte (attribute2) in the directory entry (they won't show on a DIR command, and can't be erased, copied, folded, spindled or mutilated). The FORMAT ans SYS commands both can be used to put these files on a diskette3 (if SYS is used, the disk must have already had the system on it4). In addition, FORMAT writes the boot record5 and copies COMMAND.COM6. 1 IBMBIO.COM and IBMDOS.COM. 2 Only the System bit was set at this time (attribute byte = 0x04); when released, these files had both System and Hidden attributes set (attribute byte = 0x06). This is the 12th byte in each Directory entry. 3 See our comments further below on the FORMAT and SYS commands. 4 So why was SYS.COM created, when it appears to have very little use? SEE NOTES BELOW for the answer! 5 By copying the Boot Record from Sector 0 of boot diskette; not by writing a new one from within the FORMAT.COM file itself as the later (release) FORMAT program does! 6 In addition to IBMBIO.COM and IBMDOS.COM, _when_ its '/S' switch is used. 3. The system now contains single-drive support that makes the dip switch settings very important. The DOS now conforms with the proper dip switch settings for number of drives namely - 7 on, 8 on - 1 drive 7 off, 8 on - 2 drives 7 on, 8 off - 3 drives 7 off, 8 off - 4 drives 4. The disk contains some extra programs, as follows - vcopy - used like the copy command - it's a batch file that invokes copy, then invokes a file compare program [FCOMP.COM] to verify the copied file is the same as the original. mode - changes the mode of the screen or line printer the command has two basic options OPTION 1 (line printer) ex: MODE LPT1:132,8 lpt<#> - specify printer number 1-3 , usually 1 m - 80 , 132 characters per line n - 6 , 8 specifies 6 or 8 lines per inch OPTION 2 (display) ex: MODE 80,r m - 40 , 80 characters per line n - r , l shifts the screen to the right or left (repeated use of this option allowed) diskcopy - 'DISKCOPY dr1 dr2" where dr1 will contain the source diskette, and dr2 will contain the target. If only the first dr is specified, the default dr will be used for dr2 - if both dr's are omitted, a single drive copy will be done on the default dr. comp - diskette compare, compares all 40 tracks of 2 diskettes (use after fcopy7 if you suspect a problem. 7 But there is no 'fcopy' on the diskette; must have meant diskcopy (was there ever an early; as in early 1981 or earlier, FCOPY program - possibly a beta version, or from SCP?). fcomp - file compare program - compares 2 files on the same or different drives, indicates up to 10 offsets that don't compare. To invoke, enter "FCOMP fn1 fn2". Both filenames may include drive specifiers and both are optional (the program prompts). Note that compares of non-text files (such as .COM files) will cause a message indicating no eof was found. This is normal for such files, and does not indicate an error - the program looks for an eof mark (1AH), which is present in source files, but not in .COM files. convert - To date, 3 different formats of diskette maps have been used by DOS. The first contained the dir on track 2 and was the system that did not prompt for tha date. The second was the system with the dir on track 2 and did prompt for the date - it was a conversion system to be used for converting diskettes with the first format to the new format directory. The latest system, (4/15/81 or later) contains another change - the dir has now been moved to track 0, and both previous formats are incompatible. If your diskettes are in the second format, use the FORMAT command on this disk to format a new disk, then enter "CONVERT". It copies all files from a diskette that has the second (date in dir, dir on trk 2) to the new formatted diskette. (Sorry, there's no program to go from the oldest to the newest format).
If you use the TYPE command on the COMMENTS file, all its lines will simply scroll down, making it impossible to read all of them. So how did users back then read a long text file? By either printing it out, or using EDLIN ("The IBM Personal Computer EDITOR") of course. And whoever edited the COMMENTS file, probably used EDLIN, since it made *.BAK back-up files as well. And because it did so, it will not allow you to open the COMMENTS.BAK file unless you first rename it! You'll have no problems attempting to view a .BAK file with EDLIN; it will merely display: "Cannot edit .BAK file--rename file"
However, NOTE this: If you use EDLIN.COM to simply view the COMMENTS file, doing so will ERASE the COMMENTS.BAK file! That is how I ran into a problem with an image file when I was writing the next section and came across some free space in the middle of the diskette. Now, I know it was the EDLIN program that had erased the file and changed its entry in the Directory to: "0xE5,OMMENTS$$$"; leaving me to wonder at the time why my disk editor was having such a problem with the image file. Note: This is also evidence that no one ever used EDLIN again to view the COMMENTS file on this diskette, after that spelling correction was made!
Figure 3. This is a marked-up and combined screens picture of a
Norton Disk Editor view of the Directory after EDLIN was used to only view the COMMENTS file; not make any
Note: Never attempt to open a 'FAT object' in Norton Disk Editor while Windows is running, it will always CRASH the program!
After extensive testing of the SYS.COM and FORMAT.COM programs in an emulator with two floppy drives (making it easy to eject and make changes to the 'virtual 160 KiB diskette' in drive B), we were able to show that the only way SYS.COM would actually write IBMBIO.COM and IBMDOS.COM to a diskette would be if it found intact entries for both of those files in the Directory. If the first letter of either file was 0xE5 (indicating it had been erased), SYS.COM would not write to the disk; instead it would state: "No room for system on destination disk" (which obviously is not a very accurate error message!). Those Directory entries and still having good FAT entries for IBMBIO.COM and IBMDOS.COM are the key, because overwriting every byte of both those files in their allocated clusters with 0xF6 bytes, does not prevent SYS.COM from writing all new bytes to both files! If, however, we used CHKDSK on the drive while either file was in an 'ERASED' state (its first character being 0xE5 in it Directory entry) which resulted in the message: "...bytes unallocated disk space freed" (meaning the FATs were altered), after setting the 0xE5 bytes back to an "I" and running SYS.COM on the drive, that would result in the error message: "File allocation table bad on drive..." So, why was SYS.COM created when it appears to have little use to us? Well, take yourself back to these critical days for the different utility and BASIC program developers working on this diskette: A guy pops into your office or cubical and says here's a new revision of IBMBIO.SYS or IBMDOS.SYS for you, and you have all your work on a number of different diskettes. How do you copy a new system file, both of which now have the new SYSTEM attribute set on them, to all your working and back-up diskettes? Remember, you cannot ERASE nor COPY a System file! (Look again at that funny list in the COMMENTS file of what can not be done with these files; copying is one of them.) So, there's our answer! It was the solution for copying any changes made to those files by developers to all existing diskettes... without having to make all new formatted diskettes and copy all the accessible files over. (Or, without having to be a binary hacker, and use DEBUG; which you might not have trusted at that time, to clear the System attribute byte, make copies and reset the byte... way more of a hassle than using SYS!) So it became a real necessity for the IBM and Microsoft programmers. And later on, just in case there was an official revision or patch for a system file, users would be able to do an upgrade of these system files as well. [Thank you to the reader who made me finally think some more about why SYS.COM was necessary!]
FORMAT.COM was the 'go to' application for creating both writable data storage and new boot diskettes. If you used it without any switches: "FORMAT <drive letter>" it would copy the boot diskette's Boot Sector to it and write all the necessary bytes for it to have the two FAT sectors and a ready to use file Directory. Figure 4 shows how to create a boot diskette using FORMAT's '/S' switch; and it doesn't care what's on a disk, or if it contains nothing but zero bytes as we started with here:
But note the following: Unlike later versions of the FORMAT command [when did it change?], the early versions did not create new tracks on the diskette, nor overwrite all existing data with 0xF6 bytes! There could still be valuable data stored in any file's slack space;even after filling the diskette with new files.
It should be noted that the DIR command of this early version did not display a 'Time Column'! (see our combined screens display in the next section showing all files an not time stamps). We have also provided a display here of BASIC's FILES command in use.
This is a detailed listing of the disk's contents as found in each sector; note that some of the files are not contiguous (they were fragmented
across multiple clusters on the diskette). As with our display of the contents of the DOS 1.00 Release
diskette, we've included the Absolute Sectors(s) with notes on fragmented files:
Sector 0: Boot Record
Sector 1: FAT 1
Sector 2: FAT 2
Sectors 3 - 6 are the Directory; Sectors 3, 4 and part of 5 being used ["Cluster" shows the starting Cluster of any run, but "Absolute Sector(s)" shows the sector(s) that contain that file's contents. All fragments for any fragmented files are listed. Also note that the last sector of any file is where you might find some interesting Slack Space.]:
The actual screen display of this version's DIR command has no
'Time Column' nor are file names listed in the same order found in the Directory (compare to our manually compiled listing at right):
Absolute Sector 3 ----------------- Absolute Name .Ext Size Date Cluster Sector(s) A R S H D V IBMBIO COM 2560 5-29-81 2 7-11 - - S - - - IBMDOS COM 5566 5-29-81 7 12-22 - - S - - - COMMAND COM 2576 5-29-81 18 23-28 DEBUG COM 5450 5-27-81 24 29-39 TIME COM 243 5-19-81 35 40 DATE COM 245 5-20-81 36 41 ASM COM 6389 5-15-81 37 42-54 FORMAT COM 2048 5-29-81 50 55-58 HEX2BIN COM 483 5-07-81 54 59 CHKDSK COM 1224 5-30-81 55 60-62 BASIC COM 11008 6-04-81 58 63 <- Fragmented 66 71-90 184 189 EDLIN COM 2231 5-29-81 59 64-68 COMMENTS 3561 6-05-81 64 69-70 <- Fragmented 112 117-121 MOVBAS COM 128 4-23-81 86 91 BAS18 COM 11008 6-04-81 87 92-112 <- Fragmented 127 132 Absolute Sector 4 ----------------- BASICA COM 14976 6-04-81 108 113 <- Fragmented 134 139-164 185 190-192 AUTOEXEC BAT 24 NONE* 109 114 SYS COM 896 6-03-81 110 115-116 DISKCOPY COM 1211 6-04-81 117 122-124 COMMENTS BAK 3560 6-05-81 120 125-131 BAS18A COM 14976 6-04-81 128 133-138 <- Fragmented 160 165-188 FCOMP COM 1408 4-13-81 188 193-195 KILO BAS 768 4-23-81 191 196-197 SPCWAR BAS 5120 5-22-91 193 198 <- Fragmented 202 207-208 208 213-217 215 220 222 227 CONVERT COM 3200 4-15-81 194 199-205 COMP COM 256 4-15-81 201 206 20HAL COM 1792 4-24-81 204 209-212 MODE COM 675 NONE* 213 218-219 TTY ASC 2432 5-22-81 216 221-225 VCOPY BAT 26 4-24-81 221 226 THREED BAS 3072 NONE* 223 228-232 <- Fragmented 297 302 SHIPS MAC 1792 6-01-81 228 233-236 CIRCLE MAC 384 6-01-81 232 237 Absolute Sector 5 ----------------- RBAS COM 32768 4-25-81 233 238-301 CUBE DAT 402 4-30-81 298 303 * The "NONE" entries mean no Date had been entered into the OS when these files were added; the Date bits in each of these file Directory entries were all zeros. Later versions would use a 'default date' of 1-1-80. Clusters Sectors Unused clusters/sectors on diskette: 299-314 304-319 Unused sectors at end of diskette = 16 (16 sectors x 512 bytes/sector = 8,192 bytes free space).
Here we see the beginning of the Slack Space after the last line of the COMMAND.COM file (which ends at offset 0x380F into the whole image file, or at offset 0x10 in Absolute Sector 28):
Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F 03800 20 50 52 4F 50 45 52 54 59 20 4F 46 20 49 42 4D PROPERTY OF IBM 03810 54 59 20 4F 46 20 49 42 4D 46 37 30 46 35 0D 0A TY OF IBMF70F5.. 03820 3A 31 41 30 41 44 37 30 30 37 39 37 32 36 39 36 :1A0AD7007972696 03830 37 36 38 37 34 32 30 34 39 34 32 34 44 32 30 34 768742049424D204 03840 33 36 46 37 32 37 30 32 30 33 31 33 39 33 38 33 36F7270203139383 03850 31 30 44 30 41 32 34 34 43 34 39 34 33 42 43 0D 10D0A244C4943BC. 03860 0A 3A 31 41 30 41 46 31 30 30 34 35 34 45 35 33 .:1A0AF100454E53 03870 34 35 34 34 32 30 34 44 34 31 35 34 34 35 35 32 4544204D41544552 03880 34 39 34 31 34 43 32 30 32 44 32 30 35 30 35 32 49414C202D205052 03890 34 46 34 37 35 32 34 31 34 44 32 30 35 30 31 38 4F4752414D205018 038A0 0D 0A 3A 30 45 30 42 30 42 30 30 35 32 34 46 35 ..:0E0B0B00524F5 038B0 30 34 35 35 32 35 34 35 39 32 30 34 46 34 36 32 045525459204F462 038C0 30 34 39 34 32 34 44 46 41 0D 0A 3A 30 30 30 30 049424DFA..:0000 038D0 30 30 30 30 30 30 0D 0A 1A 1A 1A 1A 1A 1A 1A 1A 000000.......... Figure 4.
The first interesting Slack Space information begins at offset 0x3819 into the image (at the end of the COMMAND.COM file): First, we see the same ASCII bytes for "TY OF IBM" repeated, but then the hex representation for half a byte ("F") and two more bytes ("70F5") followed by carriage return (0x0D) and line feed (0x0A). That would be all that remains of an Intel HEX file line that precedes three full lines of HEX code that can easily be deciphered using DEBUG. I purposely separated some of the bytes here to make it easier to understand:
:1A 0AD7 00 7972696768742049424D20436F727020313938310D0A244C4943 BC :1A 0AF1 00 454E534544204D4154455249414C202D2050524F4752414D2050 18 :0E 0B0B 00 524F5045525459204F462049424D FA :0000000000 Figure 7.
The first two bytes after the ":" give us the line length (0x1A for most lines; the last line being an exception), the next 4 bytes show the location in Memory where that line's hex code will be converted and loaded into. And in all the code we've examined, it's always followed by a "0x00" marker. Then it's all ASCII until the last 2 bytes of the line which are a Checksum. The very end of a .HEX file (again from what we've observed) is almost always a ":" and ten zero (0x30) bytes. These details can be very important in helping you piece together any incomplete lines! So, loading that into DEBUG, you would find at offsets 0x0AD7 through 0x0B18:
0AD0 79-72 69 67 68 74 20 49 42 yright IB 0AE0 4D 20 43 6F 72 70 20 31-39 38 31 0D 0A 24 4C 49 M Corp 1981..$LI 0AF0 43 45 4E 53 45 44 20 4D-41 54 45 52 49 41 4C 20 CENSED MATERIAL 0B00 2D 20 50 52 4F 47 52 41-4D 20 50 52 4F 50 45 52 - PROGRAM PROPER 0B10 54 59 20 4F 46 20 49 42-4D TY OF IBM Figure 8.
Another way to both see the data and get the file size of any Intel HEX strings you find is to put them into a text file, change the extension to .HEX and run the HEX2BIN.COM program on that file; converting it into a .COM file. HEX2BIN works under any DOS version; such as the Windows XP Command window or DOSBox. If you take those 4 lines in Figure 7, remove the spaces, put them in a file called SSC23.HEX, then run: HEX2BIN SSC23.HEX, you'll get an output file named SSC23.COM. Opening the file in a Hex Editor such as HxD will show all zero bytes until the end of the file:
Figure 9. Note: Offsets are shown in Decimal here.
This is rather good supporting evidence that what we have here (this "0.90" image file) actually came from a developer's diskette, since it would take a huge amount of time to absorb all of this material and then even more time trying to make it all fit together like this! Why? Because the only file in the image that ends with these bytes is COMMAND.COM, and it has a length of exactly 2,576 (or 0xA10) bytes: That bit of HEX code above ends at 0xB18 in Memory, but the HEX file began at 0x100 (as many of them do), so it has a length of 0xA19 bytes. And if you made changes to the file which resulted in it being 9 bytes shorter, what would you see in the Slack Space at the end? That's right, exactly the 9 ASCII bytes we see here: "TY OF IBM"! And that's what we mean by just this one piece of slack space being "supporting evidence" for its authenticity. Without data like this inside an image file or on a disk, you would need to ask yourself: 'Did someone simply assemble a bunch of old files together and then edit (i.e., fake) the dates?' As we look at more and more Slack Space evidence, we see no reason to question its history.
Another example (in Cluster 214/Sector 219; at the end of MODE.COM), provides us with a small part of an Assembly listing from that program (it's the only file on the diskette which includes the phrase "Illegal Device Name"). Here's the fragment of the listing; which was highly likely made by ASM.COM (since it normally creates both an Intel HEX output and such listings):
0370 C3 ret ;return to caller 0371 64 hundred: db 100 0372 0A ten: db 10 0373 0D 0A 49 6C 6C 65 err1: db 13,10,"Illegal Device Name",13,10,"$" 67 61 6C 20 44 65 76 69 63 65 20 4E
If we look at the end of MODE.COM, we find an exact match at the same offsets (the listing would have started at 0x100; instead of zero):
Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F 000270 C3 64 0A 0D 0A 49 6C 6C 65 67 61 6C 20 44 65 76 .d...Illegal Dev 000280 69 63 65 20 4E 61 6D 65 0D 0A 24 0D 0A 50 72 69 ice Name..$..Pri 000290 6E 74 65 72 20 45 72 72 6F 72 20 20 20 20 20 20 nter Error 0002A0 0D 0A 24 ..$
For those who wish to investigate the diskette's Slack Space on their own, I created two files:
1) All_HEX_or_Text_Slack_Space.zip contains all the 'significant' readable characters on the diskette listed in order under the Clusters in which they can be found. And...
2) ALL_Slack Space_Contents.zip which contains ALL the Slack Space on the diskette; so you'll need a hex editor to view this one.
First, if you want to experience the frustrations some of the early DOS developers may have run into, try assembling a large *.ASM file with many errors on a these diskettes: Even if you start with an empty 160 KiB disk in the B: drive, you could run out of room before all of the *.PRN file (listing the errors) was written to the diskette! That's one reason why they may have sent it to a printer instead (it was likely called a *.PRN file for that reason). I was successful, however, in learning how to use ASM.COM on a source code file for HEX2BIN.COM (v. 1.02), and discovered that the HEX2BIN.COM for early 86-DOS and on this diskette must be no later than version 1.01, since it's different than what that source code produces. So I created a revised HEX2BIN.ASM file (after a few trial/error runs; and a 'kludge') that will assemble into the same exact 483-byte .COM file on this diskette. Curiously, the HEX file contains not just one, but 54 End of File markers (0x1A); I'm not sure why.
For those who wish to try this or work with other early assembly files, you'll find the instructions for using ASM.COM in pages 21-43 of the file "86_Dos_usr_03.pdf" at Tim Paterson's web site. Look in the menus for 'Origins of DOS' and then 'Manuals'. The one you want is called: "86-DOS User's Manual - Version 0.3, ca Dec 1980."
You can also download a 160 KiB diskette image file with our HEX2BIN.ASM file already inserted plus separate copies of the *.PRN and *.HEX files it should result in, all available HERE.
Screenshots of HEX2BIN.COM being assembled on a drive B: diskette and confirmation it's the same program:
1[Return to Text] Both files are exactly 6,389 bytes, and only 5 bytes differ. The affected instructions are:
In 86-DOS'S ASM.COM In this ASM.COM Offset into files ------------------- ------------------- ================= BC3720 MOV SP,2037 BC8520 MOV SP,2085 0x78 BB3820 MOV BX,2038 BB8620 MOV BX,2086 0xE6 BC3720 MOV SP,2037 BC8520 MOV SP,2085 0x146 BB3720 MOV BX,2037 BB8520 MOV BX,2085 0xF0A And at offset 0xF0 into the files we have: ----------------------------------------- C70603203720 MOV WORD PTR ,2037 In 86-DOS ASM.COM C70603208520 MOV WORD PTR ,2085 In this ASM.COM
It's clear the Stack Pointer was moved from 0x2037 to 0x2085 for these and a few instructions which depend on that location. Yet there appears to be no mention of this in the Source Code for version 2.44; where we only find:
; 04/28/81 2.24 Allow nested IFs ; 07/30/81 2.25 Add Intel string mnemonics; clean up a little
Perhaps this change in 2.24 was considered too minor to mention.
2[Return to Text] The Assembly Source Code for ASM.COM (Version 2.44), as well as much of the source code for IBM PC DOS 2.0, has been publicly available for research purposes since March 25, 2014 (see this article by Len Shustek at CHM). In that file, you'll find:
; 02/22/81 2.10 Increased buffer size from 128 bytes to 1024 bytes ; 03/18/81 2.11 General cleanup and more documentation
Which leads us to believe this bit of slack space is from around the beginning of March, 1981.
3[Return to Text] This pre-release version of FORMAT.COM contains a unique oddity you won't find anywhere else in DOS. Its author, Bob O'Rear, for some reason decided to insert his name in the program in a way which would require more than a glance to notice. The final release verison did not include any of this (although his name is found there as well, because FORMAT.COM was revised to include a copy of the DOS 1.00 Boot Sector, which Bob had already inserted his name into!):
Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F 460 00 00 00 00 00 00 00 00 00 00 00 00 0A 0D 54 72 Tr 470 61 63 6B 20 30 20 62 61 64 2D 64 69 73 6B 20 75 ack 0 bad-disk u 480 6E 75 73 61 62 6C 65 24 B0 0A 0D 44 69 73 6B 20 nusable$. Disk 490 75 6E 73 75 69 74 61 62 6C 65 20 66 6F 72 20 73 unsuitable for s 4A0 79 73 74 65 6D 20 64 69 73 6B 24 B0 00 00 01 02 ystem disk$. 4B0 00 00 02 02 00 00 03 02 00 00 04 02 00 00 05 02 4C0 00 00 06 02 00 00 07 02 00 00 08 02 49 42 4D 42 IBMB 4D0 49 4F 20 20 43 4F 4D 04 00 00 00 00 00 00 00 00 IO COM 4E0 00 00 00 00 00 00 02 00 80 09 00 00 49 42 4D 44 € IBMD 4F0 4F 53 20 20 43 4F 4D 04 00 00 00 00 00 00 00 00 OS COM 500 00 00 00 00 81 02 07 00 00 13 00 00 43 4F 4D 4D . COMM 510 41 4E 44 20 43 4F 4D 00 00 00 00 00 00 00 00 00 AND COM 520 00 00 00 00 7C 02 11 00 00 0A 00 00 00 00 52 20 | R 530 4D 20 28 5F 2E 5F 6F 20 69 20 63 5F 2E 5F 62 20 M (_._o i c_._b 540 63 20 29 5F 2E 5F 65 20 72 20 20 5F 2E 5F 72 20 c )_._e r _._r 550 6F 20 49 5F 2E 5F 74 20 73 20 42 5F 2E 5F 20 20 o I_._t s B_._ 560 6F 20 4D 5F 2E 5F 4F 20 66 20 20 5F 2E 5F 27 20 o M_._O f _._' 570 74 20 43 5F 2E 5F 52 20 20 20 4F 5F 2E 5F 65 20 t C_._R O_._e 580 20 20 52 5F 2E 5F 61 20 20 20 50 5F 2E 5F 72 20 R_._a P_._r 590 20 20 2E 5F 2E 5F 20 20 20 20 20 5F 2E 5F 00 00 ._._ _._
Those color highlighted bytes above, are nothing more than:
Robert O'Rear Microsoft (c) IBM CORP.
First Published: 10 JUN 2017 (10.06.2017).
Updated: 10 JUN 2017 (10.06.2017); 16 JUN 2017 (16.06.2017); 18 JUN 2017 (18.06.2017); 19 JUN 2017 (19.06.2017); 21 JUN 2017 (21.06.2017); 22 JUN 2017 (22.06.2017); 25 JUN 2017 (25.06.2017); 1 JUL 2017 (01.07.2017).
Last Update: 26 FEB 2018 (26.02.2018)
You can write to us using this: email address (opens in a new window).
MBR and Boot Records Index
The Starman's Realm Index