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, 2019, 2021 by Daniel B. Sedory
NOT to be reproduced in any form without Permission of the Author !
Introduction
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.[1] 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[2] 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.
The History of this Pre-Release Image File
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.
 | |
Photo of Dick Conklin's business card (at the time; we blocked-out address &
phone numbers) AND the 3.5-inch diskette received from him on January 25, 2006. Dick wrote on the label you see:
“DOS, 6-5-1981”
BOOTABLE DISK ON OLDER SYSTEMS
TO EXIT BASIC: SYSTEM
SAMPLE BASIC PROGRAMS ARE
FILETYPES
“.BAS” & “.MAC”
EXAMPLE (IN BASIC): RUN “THREED.MAC” This diskette was formatted the same as the early IBM
PC DOS 1.00 diskettes; with only 8 Sectors/Track (and 40 tracks on one side, for a total of: 163,840 bytes; 160 KB) instead of the later 9 Sectors/Track
(still at 40 tracks, they had a capacity of: 184,320 bytes; 180 KB). So, placing this floppy disk in even a rather old PC which uses the now standard 18
SPT for a 3.5-inch floppy disk (with 80 tracks on both sides, for a total capacity of: 1,474,560 bytes; 1440 KB), will result in DISK READ ERRORs; even
when using programs like HxD and trying to read only the hexadecimal bytes. |
NOTE: Just yesterday (21 July 2019), using a fairly old PC (Soltek SL-52B2 motherboard, Intel Pentium-S, 100 MHz and 1996 BIOS), we were able
to boot-up the diskette from Dick Conklin in that PC's old 3.5-inch floppy drive; which immediately ran the AUTOEXEC.BAT file to set the date and then start
the BASIC application. Using the original IBM DISKCOPY program on the disk, we also created a copy of this 160 KB diskette onto another 3.5-inch
floppy disk (having to swap the SOURCE and TARGET disks back and forth in the same drive FIVE times). Here are a few photos of the PC and the diskette booting-up.
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').
Jump to almost 10 years later (at a time when I'd almost completely forgotten about this disk image), and that former teacher and researcher turned out to
be the 3rd party who leaked the image file to Michal Necasek at the OS/2 Museum; which I am happy 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.
How to Obtain a Copy for Your Own Research
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/. Do not do anything in that window prior to
saving the file (doing so may affect the MD5 checksum)!
The MD5 Checksum of this image file should be: EE6AFF11F396964E2420EAB99D64DA42.
Note: If you want to examine the file in WinHex or some other Windows tool, we'd recommend changing the last 2 bytes of the Boot Sector (at
offsets 0x1FE and 0x1FF into the image file) to: 0x55 and 0xAA in that order. However, PCjs did not make that change, and it would not be
necessary (nor recommended) to run the image in an IBM PC emulator; such as PCE.
Here we describe the changes made in the PCjs image (with MD5 checksum above) compared to the original image file from Dick Conklin:
1) The Boot Sector has been altered by adding some BPB hex bytes to make it compatible with the PCjs simulator. The bytes shown in RED (PCjs changes) below, must be changed back to the characters (or set to zero) shown in BLUE
(original image; see 'Figure 2') to make it exactly like an IBM PC DOS 1.00 Boot Sector (13 bytes were changed here):
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 has also 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"); which comes
makes a total of 14 bytes having been changed in the PCjs image.
We recommend having multiple copies of the original image file (at
least one being WRITE PROTECTED once it has the correct MD5 checksum provided below), one you can open in WinHex or some other Windows™ tools (a
2-byte change) in addition to the one from the PCjs web site (14 bytes different). It's also possible to create a FAT12 version to examine under later
IBM PC or Microsoft DOS versions.
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: 5EF60998B138B866783AB0FEE88336AE.
If you get a different MD5 sum, or you'd like to contact me regarding this image file, you can email me here.
Note: It's also possible to run this image file under PCE (the PC Emulator).
Some Comments from Dick Conklin on the Disk's Contents
Some comments Dick made 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.
The Comments File on the Diskette
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
changes.
If you do so; without making another edit change, then EDLIN erases its 'back-up' file (COMMENTS.BAK) as shown within the GREEN circle.
Notice how Norton's Disk Editor considers all 3 files (in RED) as having
errors because there are only zero bits in their 'Date bytes'. The disk's COMMAND.COM program simply ignores these and doesn't display anything for them.
| | 
Note: Never attempt to open a 'FAT object' in Norton Disk Editor while Windows is running, it will always CRASH the program! |
Use of the FORMAT and SYS Commands
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[3] 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:
Figure 4.
Early DIR Command, AUTOEXEC.BAT and BASIC's FILES Command
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.
Figure 5.
Detailed Locations of Every File on the Disk
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):
Figure 6. The 3 files with no listed date had zero bits in their 'date bytes';
the DIR command of this version's COMMAND.COM displays no date when encountering that 'technical error' (there cannot be a zero-th month or day, but all
zero bits for the year does mean 1980). |
|
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). |
Examples of Data Found in Slack 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 4EIf 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 ..$
Download All the Slack Space Data
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.
How to Use ASM.COM on this Disk
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.
Note: The end of the HEX file contains not just one, but 54 End of File markers (0x1A), because it was based upon the style of CP/M records
having exactly 128 bytes! Thus, the last "record" output by ASM.COM used the End of File marker to fill-in the number of bytes required
after the actual end of HEX2BIN.HEX data to total up to 128 bytes:
Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F
480 36 34 32 34 34 34 36 39 37 33 36 42 32 30 42 41 64244469736B20BA
490 0D 0A 3A 30 46 30 32 44 34 30 30 36 34 36 39 37 ..:0F02D40064697
4A0 32 36 35 36 33 37 34 36 46 37 32 37 39 32 30 36 26563746F7279206
4B0 36 37 35 36 43 36 43 32 34 34 46 0D 0A 3A 30 30 6756C6C244F..:00
4C0 30 30 30 30 30 30 30 30 0D 0A 1A 1A 1A 1A 1A 1A 00000000........
4D0 1A 1A 1A 1A 1A 1A 1A 1A 1A 1A 1A 1A 1A 1A 1A 1A ................
4E0 1A 1A 1A 1A 1A 1A 1A 1A 1A 1A 1A 1A 1A 1A 1A 1A ................
4F0 1A 1A 1A 1A 1A 1A 1A 1A 1A 1A 1A 1A 1A 1A 1A 1A ................
This was mentioned in an email by a visitor to our web pages, Miguel Garcia of Spain, who also pointed out that this version of ASM.COM used the CP/M BDOS
function "CALL 0005" with 0x15 in the CL register. However, in the source code for version 2.44, he saw this comment:
; 08/02/81 2.30 Re-write pass 2:
; Always report errors to console
; Exact byte lengths for HEX and PRN files
And noted that all the CP/M BDOS functions had been replaced with MS-DOS functions for writing out .HEX files.
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:
Footnotes
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 [2003],2037 In 86-DOS ASM.COM
C70603208520 MOV WORD PTR [2003],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, in which Bob had already inserted his name!):
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); 26 FEB 2018 (26.02.2018); 22 JUL 2019 (22.07.2019) - added picture of diskette Dick Conklin sent us and comments
on how it still boots-up! 28 SEP 2020 (28.09.2020) - added notes on CP/M function calls in this version of ASM.COM.
Last Update: 9 FEB 2021 (09.02.2021) - Corrected MD5 Checksum, made some clarifications.
You can write to us using this: email address (opens in a new window).
MBR and Boot
Records Index
The Starman's Realm Index
