Last week a most interesting image of a 160K disk arrived at the OS/2 Museum. The files on the disk image are rather old. When the disk boots up (not trivial, see below), the following message appears:
Almost like PC DOS 1.0
Astute readers will notice that that’s exactly the same message as PC DOS 1.0 (August 1981) shows, but this COMMAND.COM did not prompt for the date. That’s because this disk is not from August but rather early June 1981—newest file is timestamped June 6, 1981—which may make it the oldest known surviving piece of software written for the IBM PC (not counting the IBM PC ROMs which are dated April 1981). It’s certainly the oldest known surviving PC operating system. It comes with a short text file which provides further insight into the development history of PC DOS.
Even better, the disk can be explored at pcjs.org live in its native habitat. Note that the original disk had AUTOEXEC.BAT which immediately asked for the current date and launched Advanced BASIC; for improved ease of use, the batch file was disabled by renaming it to AUTOEXEC.BAK.
This pre-release DOS has no special version number and refers to itself as 1.0, exactly like the final product. All core files are present but are older and slightly smaller than the final version. The list includes IBMBIO.COM, IBMDOS.COM, COMMAND.COM, CHKDSK.COM, FORMAT.COM, and SYS.COM.
PC DOS development disk directory listing
There is also DISKCOPY.COM included, but there’s no DISKCOMP.COM. The disk comparison program is called COMP.COM, and the file comparison program (COMP.COM in released PC DOS 1.0) is called FCOMP.COM instead. Yes, it’s confusing.
Miscellaneous utilities (BASIC.COM, BASICA.COM, DATE.COM, DEBUG.COM, EDLIN.COM. MODE.COM, TIME.COM) are also present. Again these are near-identical to the final release.
Development Tools
Where it gets interesting is the extras that do not exist on IBM’s PC DOS 1.0 disks. There is ASM.COM, SCP’s 8086 assembler which was used to develop early DOS versions.
SCP’s 8086 assembler version 2.24
There is 20HAL.COM, a tool that was clearly used during DOS development for exchanging files between Microsoft in Bellevue and IBM in Boca Raton. It is notable because its fragment can be found on the PC DOS 1.0 distribution disk, namely the string “DEC-20 Downlink to Boca Raton [300-bps] 9-Apr-81” at offset 0x16496 on the disk.
The mysterious downlink
There’s HEX2BIN.COM, another tool which left its fingerprints on the PC DOS 1.0 disks (“HEXCOMError in HEX file–conversion aborted” etc. at offset 0x576B on the 1.0 release disk).
When developing the early DOS versions, there was no linker. The SCP ASM.COM assembler did not produce object files. It had a built-in locator and produced HEX files (text files) which were converted by HEX2BIN.COM into binary executable files. It is likely that IBM and Microsoft exchanged HEX files rather than binaries, and those were converted into binaries as required.
And there is non-ROM BASIC, too. More about that later.
BIOS Trouble
The pre-release DOS is somewhat troublesome to run. In some situations, it calls into the BIOS with very little stack space (under 100 bytes) available, which is less than any released DOS version. As a consequence, especially newer BIOSes may cause hangs and may not boot this version of DOS at all. Using original IBM PC, PC/XT, or PC/AT BIOS works, although perhaps not reliably; there was no doubt a reason why the final PC DOS 1.0 provided more stack space; things get interesting when there is for example a BIOS disk call in progress, then the user presses a key triggering a keyboard interrupt, and then a timer interrupt arrives.
Differences and Similarities
The June 1981 version of PC DOS is in general rather close to the final release. As noted earlier, the pre-release does not prompt for the current date when COMMAND.COM is started.
FORMAT.COM does not include the boot sector; instead, it copies the boot sector from an existing disk. In FORMAT.COM there is a scrambled message which reads “Robert O’Rear Microsoft (c) IBM CORP.” Bob O’Rear was the Microsoft developer primarily responsible for porting DOS to the IBM PC.
CHKDSK.COM shows the number of “bytes total system RAM”, which is the same as 86-DOS 1.0, but not the same as final PC DOS 1.0 which shows “bytes total memory” instead.
The core DOS appears functionally almost identical to the final version with one major exception: No EXE file support. This shows that EXE file support was a rather late addition, happening in the last two months before PC DOS 1.0 was finalized.
BASIC
An interesting difference from PC DOS 1.0 concerns BASIC. There’s BASIC.COM and BASICA.COM (Disk and Advanced BASIC, respectively) which require BASIC in ROM. But there’s also BAS18.COM and BAS18A.COM which expect the BASIC “ROM” at segment 1800h (at 96K, clearly assuming a 128K machine) in RAM rather than at segment F600h in ROM.
Advanced BASIC
This scheme allowed BASIC.COM/BASICA.COM to be run on machines that either didn’t have the BASIC in ROM at all or perhaps had some outdated version. No such mechanism was available in any released PC DOS, only Microsoft offered an equivalent with GW-BASIC.
It is notable that the ROM BASIC image (RBAS.COM) is not identical to the one found in the ROM of IBM 5150 PCs. Although it reports itself as the same version (C1.00) and contains the same timestamp (25-Apr-81), several bytes are different. Their significance is currently unknown.
A BASIC 3D cube
What’s also interesting is that while the pre-release DOS came with several BASIC utilities and games (THREED.BAS, SPCWAR.BAS), these were completely different from what was shipped on the final PC DOS 1.0 disks.
BASIC Space Wars
A simple terminal program (TTY.ASC) was also provided:
A BASIC TTY program
In general it is apparent that assembler and BASIC were the primary development languages in the early IBM PC era.
Even More Ancient History
The previously mentioned COMMENTS file dated June 5, 1981 provides further insight into the history of PC DOS development.
In earlier PC DOS development versions, IBMBIO.COM and IBMDOS.COM used lowercase names on disk. That meant the files were visible but could not be easily manipulated, because DOS implements case-insensitive file searches by always uppercasing file names in the API and actually doing case-sensitive searches. By the end of May (FORMAT.COM is dated May 29, 1981), DOS added the ‘hidden’ attribute (the first file attribute defined) so that system files could not be modified or even seen in directory searches.
At some earlier point, the PC DOS disks were laid out differently. The directory (root and only!) was on track 2, with IBMBIO.COM/IBMDOS.COM presumably stored on tracks 0 and 1 and not part of the file system, just like in 86-DOS 1.0. In PC DOS 1.0, the directory starts on the 4th sector, after one boot sector and two copies of FAT (one sector each). It is likely that IBM did not want to waste valuable space on non-bootable disks.
An even earlier PC DOS development version likewise stored the directory on track 2 but did not record any date information in the directory entries. It is likely that that version of DOS used 16-byte directory entries rather than the usual 32-byte entries. Note that PC DOS 1.0 recorded the dates in the directory entries, but not the time of day (that had to wait for PC DOS 2.0). Implementing a UNIX-style make might be difficult under such conditions.
Final Thoughts
The pre-release version of PC DOS 1.0 is an interesting historical artefact, a true museum piece. Being from June 1981, it falls right in the middle between 86-DOS 1.0 (April 1981) and PC DOS 1.0 (August 1981), and while it’s not the oldest surviving version of DOS, it is the oldest known PC operating system.
Update: After this article was published, a little more information about the pre-release DOS disk came to light. The original floppy was most likely destroyed or lost decades ago, which is a shame. The surviving floppy image was sent in 2006 (on a 3½” diskette) to Daniel B. Sedory aka The Starman by Dick Conklin, a writer, book author, and lifelong Floridian who worked for IBM between the 1960s and 1980s and was a member of the IBM PC team in 1981.
This is certainly quite an interesting experience to say the least.
On that note, I have been considering adding in support for the early prototype IBM PC machines in my own emulator for some time now, especially since a scan of the original prototype system board is available in the September 1990 issue of BYTE Magazine, in the article “The Creation of the IBM PC.
The link to the magazine issue itself is here:
https://ia902707.us.archive.org/21/items/byte-magazine-1990-09/1990_09_BYTE_15-09_15th_Anniversary_Summit.pdf
From what I have seen, the components for the early prototype IBM PC system board are quite similar when compared against the system board for the final shipping product, though the components that were used for the prototype system board appear to be slightly earlier revisions.
The April 1981 revision of the IBM PC ROM BIOS is currently the earliest available online, however, if an earlier revision appears, then I’ll also add that into my emulator projects.
The DSKTEST switch in the source code is probably worth mentioning. It is still possible with newer versions, but DEBUG would have to be modified so that INT 28h point to an IRET instruction for example. They also STI after they are on the AUXSTACK instead of waiting after they are on the correct one. I wonder why?
This is a fascinating find! There’s already a disk of 86-DOS floating around, but it’s not a PC copy. (The .COM files from it, however, will run under PC DOS or MS-DOS).
This shows that IBM’s request to change the prompt from A: to A> made it in early in the process of converting 86-DOS to PC DOS, although I guess that was one of the easier changes to make!
There are also other little refinements made between this pre-release version and the final one: “dir foobar”, for example, will just do nothing on this version whereas on the released one it’ll say “file not found”. Typing “E:” says “No such drive” compared to the more familiar “Invalid drive specification”.
The system date is also interesting – it defaults to 00/00/1980, which is of course nonsensical! Saving a file from BASIC or using “copy con whatever” results in a file with no date. Setting the date to 1/1/80 still gives no file date with copy con, but works as expected with files saved from BASIC. This isn’t an issue with the released version as there’s that fudge to ask for a date when command.com first runs. (You can tell it’s a fudge too as the wording is quite different from the normal date command!)
Really cute! Just one nitpicking: wasn’t EXE file format introduced with DOS 2.x?
“DEC-20 Downlink to Boca Raton [300-bps] 9-Apr-81”
Seems that PDP-10 was still involved in early DOS development.
Do the references to strings appearing at certain offsets in the disk imply that the strings aren’t contained within files, but are for example past the EOF in the last sector of a file or in sectors which aren’t referenced by the filesystem?
Are there any good tools for dumping all the unreferenced parts of a disk [image] to look for other potentially-interesting stuff that might have been left behind like this?
Also, in “That meant the files were visible but could not be easily manipulated, because DOS implements case-insensitive file searches by always uppercasing file names in the API and doing case-insensitive searches.”, I’m assuming that the second-last word should have been “case-sensitive”?
@DOS
The references reference bits in the “slack space” on the disk. For more details, see this link:
http://starman.vertcomp.com/DOS/ibm100/index.html
(and the Forensics section therein).
With a 160K disk image you could just as well load the file in a hex editor (or even Notepad!) to see what’s on every byte of the disk.
No. PC DOS 1.0 in fact shipped with LINK.EXE (Microsoft Linker) on the disk. DOS 2.0 introduced hard disk support, sub-directories, handle-based I/O, loadable drivers, and many other goodies, but EXE files were there since 1.0.
My assumption is that EXE format was added by Microsoft to support Microsoft’s development tools (and multiple segments). The thing is that early DOS was not developed using Microsoft’s tools but rather SCP’s.
Oops, sorry. Yes, the actual searches are case-sensitive, but all file names are meant to be upper case only. Fixed.
Yes, the strings on PC DOS 1.0 disks are not contained within files, usually it’s in the “unaccounted-for” space within the last cluster (in the DOS 1.0 case, cluster = sector) of a file. DOS simply reused existing disk buffers so there is almost always something in the slack space. There may also be data from deleted/overwritten files left on a disk; that is less common on distribution disks but not unheard of.
I’m not aware of specific tools that look at slack space but I’m sure such tools exist. It’s not something many people need 🙂
The A: vs A> prompt was actually a compile option for COMMAND.COM (see CHM source code for SCP’s MS-DOS 1.25). This led me to realize that a compile option for IBMDOS.COM also sets ‘:’ as a valid delimiter, a difference from MS-DOS. Which means that “rename:blue.bas:red.bas” is a valid command in DOS 1.0, as weird as it is (there are other weird ones, like “rename[comm.bas]com.baz”).
Re date handling: I think this is a consequence of the original DOS file system not storing dates at all. DOS is essentially prepared to handle a file with no timestamp at all (as opposed to the earliest date that can be recorded), and in that case DIR does not show the date. Times of day are handled differently (DOS 2.0+) because zero is taken to mean 12:00am and is always shown.
Fascinating – the history I’d read said that the “A:” prompt was changed (somewhat grudgingly) at IBM’s request. I’d assumed that also affected MS-DOS but it’s clear from the source code that it didn’t.
Indeed, if you do an image search for “MS-DOS 1.25” you’ll see screenshots showing an “A:” prompt (and a slightly newer COMMAND.COM version too).
It looks as though by version 2, though, the “A>” prompt became the default for both the IBM and MS versions.
The earliest slack space viewer for DOS that I’m aware of is “SEEJUNK” that can be found in the SIMTEL20 archive.
@Retron, though eventually we’ve got mixed prompt – c:\>, as modern windows versions show. Not sure when this happened though.
The default prompt was A> up to DOS 5.0. MS-DOS 6.0/IBM DOS 6.1 (1993) sets the PROMPT environment variable to PROMPT=$P$G by default, which means users will see A:\> prompt. With no PROMPT env var set, MS-DOS 6.0 still shows A> prompt. PC DOS 7 is different and even when PROMPT is not set, it shows A:\> prompt. As far as users were concerned, the default prompt changed in 1993 with DOS 6.
MS-DOS 1.x/2.x and 3.0/3.1 releases were OEM only, so it was up to OEMs to set up the default prompt. With the generic MS-DOS 3.2/3.3 releases, it was A> in line with PC DOS.
If the image file you found is exactly the same as the one I examined at:
http://www.pcjs.org/disks/pcx86/dos/ibm/0.90/
Then your image file was _altered/tampered_ with, most likely in order to make it possible for some disk tool to get at the files inside it. How do I know? I used the DOS DEBUG command to took at the Boot Sector by doing:
L 100 0 0 1
And then dumping it (D 100) and you can see essentially the same sector as found in an official IBM DOS 1.00 image, except this one has some bytes normally found in the BPB area of a DOS 2/+ boot sector: You can easily see that the normal DOS 1.00 date “7-May-81” has had the “May-81” part overwritten by some hex bytes! Though not a technically complete BPB, if you add the missing 0x55 and 0xAA bytes at the end of this sector, these changes are enough for a program like WinHex to provide some meaningful data about each file in the image.
Where did this image file come from? A few names come to mind… or did you actually find it with some old PC that was donated to you?
I recall reading somewhere that IBM really really wanted the same prompt as CP/M. Microsoft wasn’t keen on it but IBM was paying 🙂
The image I received has boot sector 100% identical with PC DOS 1.0. The pcjs image came from me but the boot sector may have been modified (I know AUTOEXEC.BAT was renamed at my request).
I have no way to tell how original the image is, but so far I haven’t found anything that would indicate that it’s not from June ’81. I have a reason to believe that you have the same image and if you know more about its origin, I’d love to know.
Hi Michal,
I would agree that wherever this image file came from, it certainly appears to be a nice ‘snapshot’ of the work in progress at Microsoft, most likely in early June, 1981; due to both the file dates (earliest is: April 13, 1981 and latest is: June 5, 1981) and date strings in the image (e.g., 4 times we find “4-Jun-81” and once “2-Jun-81”) getting DOS ready for its IBM PC DOS release later that year.
It could also be pointed out that at this late a date of Microsoft working with IBM, it’s very reasonable to find IBM code in the image (e.g., “David Litton”, “Mel Hallerman” and “Ron Heiney” are the IBM authors in DISKCOPY.COM and MODE.COM). Yet, we see that all of the program files which made it into the final release; including both of these from IBM, were still going through changes, because none of them are exactly the same as found in the master released to production! Even the small DATE and TIME files had a lot of byte changes. As a matter of fact, the only file that remained constant throughout the time from 86-DOS to beyond DOS 1.00 was HEX2BIN.COM. And the one with the least amount of change in it (only 5 bytes) was the ASM.COM program; both from 86-DOS, and neither of which were in the final IBM release.
I compared this image to the IBM PC DOS 1.00 image and no byte strings of any significance (F6 and 00 are not significant!) ‘lined-up’ at the same offsets. Of course, with only 160 KiB to work with and so many file changes, files being deleted and many new files being added, that’s not really surprising. I’d hoped to find something, but for now, I don’t think anyone can say one way or the other as to whether this image could have ended up being the same media image given to production or that it was definitely not the same.
Regarding the disk image that Michal provided for use at pcjs.org, it was intended to be an exact copy — and it is, with the exception of the BPB bytes. That’s simply a side-effect of the pcjs disk image converter I wrote (DiskDump), which automatically “fixes” any BPB that’s missing/incomplete/corrupt. I added that feature last year, when I was helping a friend image lots of PC-DOS 1.0/1.1 disks, because having an appropriate BPB made it easy to mount them from a modern operating system; without a BPB you just get an error (for example, macOS will complain that there is “no mountable file systems”).
From an archival perspective, I agree that it’s best to preserve the original image, and that’s what your traditional download/archive sites do. http://www.pcjs.org offers a slightly different experience; for example, when you download a disk image from a machine at http://www.pcjs.org, you’re downloading the disk as it exists at that moment, including any edits, deletions, etc, you may have made to the disk.
That said, I’ll add a note to the page that highlights the BPB bytes that are different between the pcjs.org image and the original image. Thanks.
First, thank you Jeff for your clarification reply! It was very helpful.
And for Michal: Where did the file name “0.90” come from? Did whomever ‘leaked’ this call it that, or did you call it that?
Now, here’s some information about the first interesting Slack Space in the image; it begins at offset 0x3819 into the image (at the end of the COMMAND.COM file) [Oh, what I post here can stay here – no issues, but I retain the right to Copyright my words; Copyright(C)2017 by Daniel B. Sedory, especially this note, on my own web site.]: First we see the ASCII bytes for “TY OF IBM” 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 the HEX file line that precedes three clear lines of HEX file code that can easily be deciphered using DEBUG:
:1A0AD7007972696768742049424D20436F727020313938310D0A244C4943BC
:1A0AF100454E534544204D4154455249414C202D2050524F4752414D205018
:0E0B0B00524F5045525459204F462049424DFA
:0000000000
The first two bytes after the “:” is line length, the next 4 is the line’s location in Memory followed by the “0x00” marker. Then it’s all ASCII until the last 2 bytes of any HEX line which are a Checksum. Oh, the very end of a file is almost always a “:” and ten 0x30 bytes. These details are important for piecing together any incomplete lines! So, loading that into DEBUG, you will 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
This is rather good confirmation that what we have here (this “0.90” image file) is not something someone faked; unless they spent a huge amount of time absorbing all of this material and even more time making it all fit together! 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. Well, that bit of HEX code above ends at 0xB18 in Memory, but they always begin at 0x100, so it would have a length of 0xA19 bytes… And if you made changes which made that file 9 bytes shorter, what would you see in the Slack Space at the end? Yes, that’s right, exactly the 9 ASCII bytes we see here: “TY OF IBM”! So that’s what I mean in just this one piece of “good confirmation”. If we look harder, I’d assume there will be more.
The fragments of HEX files continue in a few more places throughout the disk, just as they do with the official 1.00 release. It looks like the raw HEX files were overwritten by the COM files, leaving those fragments behind in the slack space.
Here are some more fragments from the image and the (human-readable) ASCII from them:
*******
5434F5038
:1A089E0059E4040650415553451D0600A30A014155544F4558454342415475
:1A08CD00000000000000000000000000000000000000000000000000018090
:0208E700010D01
:1A0AA3000D0A5468652049424D20506572736F6E616C20436F6D70757465A8
:1A0ABD007220444F530D0A5665727369
PAUSE
AUTOEXECBATu
The IBM Personal Computer DOS
Versi
*******
4F6E48BC8E852
:1A01680022008AC4B40003C8B42BCD210AC0750BCD20AC3C2F741D3C2D7405
:1A01820019BABF01B409CD21CD20E80E0072F28AE0E807007204D50A8AE0C6
:1A019C00C38A042C3072F93C0AF572F446C3D40A86C40D3030E802008AC4BA
:1A01B6009250B402CD215892C30D0A496E76616C6964206461746524
Invalid date
*******
:1A0920001AB PRN 9F80CE019EE89FFD 2DD3C3A7505E862D5
:1A093A00F9EB0B0AC0D1DEF6C601D1D674C9A00D1B0AC07403E97FFDE81B29
:1A095400FFB10B75188B168C1AC6070
The image I got had 0.90 in the name but I don’t know where the number came from. As far as I can tell there’s absolutely nothing in the image itself that would identify the contents as PC DOS version 0.90. For all I know that kind of pre-release versioning wasn’t even used back in 1981.
Nice analysis of the HEX fragments. I agree that this is extremely unlikely to be a fake because producing it would be a major effort (modifying all the bits, adding new BASIC demos) without a lot of payoff 🙂 It also matches the known timeline, for example the NUL device is missing.
Actually the list of reserved names in the pre-release IBMDOS.COM is “PRN LST AUX CON” which is almost like the “non-IBM” build of MS-DOS 1.25, only ‘NUL’ is missing. Actual PC DOS 1.0 had “PRN LPT1 AUX COM1 CON NUL”. If someone faked it they might remove NUL, but using the non-IBM reserved name list instead seems a bit too random.
I also found it surprising that the BASIC samples on the pre-release disk are completely different from what came with PC DOS 1.0.
The non-ROM BASIC is another thing that I would not expect in a fake, but it makes sense for a real development disk. I haven’t been able to track down a dump of a really old IBM PC BASIC ROM so I don’t know if the BASIC image is identical to what IBM shipped or not.
Michal,
When you wrote: “I haven’t been able to track down a dump of a really old IBM PC BASIC ROM”, did you mean a ROM prior to the original IBM PC sold with DOS 1.00; the one that had the math error in it? Because , if that’s the one you’re looking for, it’s readily available. Or, reading that again, maybe you’re looking for a disassembly of the code? Anyway, if you click on my name, look at the bottom of my DOS 1.00 page where I discussed the BASIC ROM math error, and take the link to Hampa Hug’s “PCE” page to get the original BASIC ROM along with other goodies.
Ugh, I read your page a while ago and then completely forgot about the BASIC ROM reference. Thanks for the reminder.
And no, the pre-release DOS 1.0 BASIC ROM is not identical (RBAS.COM vs. ibm-basic-1.00.rom), despite the same version number and date stamp. 9 bytes are different, I’m unsure of the significance. But it does make me wonder how the BASIC ROM was developed/maintained.
Not surprisingly, BAS18.COM + RBAS.COM, when asked to do ‘? .1# / 10’, prints ‘.001’ instead of ‘.01’.
I wonder if an option to use 64K DRAM chips in the IBM 5150 for up to 256K of RAM was ever considered.
Michal,
RE: The BASIC ROM, that’s still a very good piece of evidence showing it’s almost the same, yet not quite the same as the final production release placed in the ROM chips of the machine! I’d say this is fantastic, because the 9 bytes that are different are in various locations throughout the code; these changes were likely made for certain programming reasons; it’s not like someone only changed a copyright or date string.
OK, now for some shocking news: I should have reviewed my own web page!
This “0.90” image file you have is probably one that I already had way back in 2006. I am trying to find it now in order to confirm that… having gone through a number of moves, job changes, etc. since then, and not knowing how IBM would have reacted to something not already in the public, all caused me to forget about it years ago. It may be that even the “0.90” name was due to me!
I was told in Jan 2006: “I have a bootable 3.5-inch floppy containing a pre-release copy of DOS, something like ‘PC-DOS 0.8’ ” and was then mailed a diskette. It had “20HAL.COM” on it and also .MAC files; also MOVBAS.COM. I wrote back: “As soon as I saw it in the box today, I… [made] 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, because I can already see that all of the sectors are from an original diskette written at that time in 1981.”
Now I need to find that image file! I also need to see if the person who gave it to me is OK with me naming him as the source… BTW, can you please tell us exactly how you got your copy? Was it snail mailed to you? Is there somewhere people can upload files anonymously? If you have a name to email me, I’ll confirm if it’s the same person.
# how the BASIC ROM was developed/maintained.
I remember a comment from someone that worked many years for Tandy Radio Shack that the first versions of Microsoft Basic was from the same code with defines for the different machines in a mini computer and assembling for different processors, I don’t know if at the time of the PC they still had this way of working, if it’s interesting I could look for the comment.
The only version of early MS BASIC source that is available is for the 6502 which includes switches* for the various computers it can run on including being emulated on a PDP-10 but does not include information regarding the 8080/Z-80 implementations.
*Okay, a variable called REALIO which triggers machine specific variations.
I do find it amusing that the disk presumably used to test new potential ROM and BASIC versions has the Kilobaud Magazine benchmarking suite on it. Someone must have been very concerned about performance regression.
Okay, that’s what the “KILO” refers to. Thanks for clearing that up!
Using some kind of benchmark seems entirely reasonable, and if nothing else, I expect IBM would have tried to keep Microsoft on target.
The thing about the BASIC ROMs that I find slightly puzzling is that the various revisions are to a large extent binary identical, with smaller or larger chunks changed here and there. Basically it looks like someone patched the existing binary rather than recompiling/reassembling source code.
Yes, the funny thing about the BASIC ROM is that the version string and date are completely unchanged, yet the ROM isn’t identical. It if were a fake, there would be a strong incentive to change at least the date.
I’ve sent you an e-mail separately with more detail.
Maybe they tried to make the different parts of BASIC to stick to the same adresses even when some stuff were changed, so that if you burned it onto eproms you wouldn’t have to change all eproms but just the ones with an actual change.
Perhaps it was in preparation for the possible disaster of having to replace mask programmed ROM:s due to some fatal bug? If there is some slack space in each block then it would more likely be possible to correct some bug with only replacing one rom.
Or maybe they decided to have all stuff at fixed locations so the disk based basics could easier be used together with the rom basic code regardless of versions of rom and disk basic. Of course they could have used a jump table but that would had affected perfarmance without much gain.
OK, here’s part of the story about where this image file came from; it’s both rather sad and funny at the same time:
Michal told me where it came from, and it was from someone whom I myself had given a copy many years ago! Today, I finally found that email online with its “Ibm_pcdos_090” attachment; that was in 2008 and I’d forgotten about after getting a new job and moving (and too many things are still in storage, since moving again)! The name was ‘made up’ simply to show the image file was prior to the official release of 1.00. I would like to talk to my source before naming him, but I’m running into many difficulties doing that. I’ll say this: It was from someone who was very much a part of the teams working on the debut of PC DOS 1.00 in 1981. Don Estridge died in the crash of Delta Flight 191 on 8/2/1985 and David Litton died earlier than that. Who’s left today?
Fernando, that would be Frank Durda IV, who had a lot of cynical stories from the Radio Shack days on the old comp.sys.tandy newsgroup. Here’s a link:
https://groups.google.com/d/msg/comp.sys.tandy/0UohCKTwz10/QcCmHIhT1vIJ
with a relevant quote:
“Anyway, having seen the old BASIC interpreter source code, the majority of the
original code was really written by Paul Allen, although he freely credits
(in the source code comments) the books he obtained various algorithms from.
The command parser/editor/tokenizer appears to be mainly Bills work, and also
appears to be based partly on algorithms already published, such as some
items from Knuth, although those modules don’t credit their sources. All
math and string functions were done by Paul according to the comments in the
source code. Later features were the work of additional programmers.
By 1976, there were at least three other people touching that code.
After the original implementation, it was a largely a port product, since
the code by then was assembled using MACRO on a DECsystem-20. MACRO was a
very powerful assembler/pre-processor for the DECsystem platforms. Using the
appropriate conditionals and macro include files, the same set of source code
files could emit binary code for a 8080, 6502 and other processors, meaning
vendor “A” frequently unexpectedly picked-up fixes and feature-changes
ordered by vendor “B”, or the new bugs introduced by the changes made for some
other vendor. The last big development on that code was done in the early
1980s when it was made somewhat compliant with the ANSI Minimal BASIC Language standard, and that work was clearly done by other people.”
Anyway, on the 8080 side of Basic, Microsoft had made 4K, 8K, Extended, and Disk Basic versions of Altair/CPM/8080 Basic. IBM’s (like the earlier SCP 8086 Stand-Alone Basic) was a simple 8086 translation of the 8080 code. Someone’s posted the earliest 4K 8080 source code that can be found online, and you can still see parts of it buried in the later TRS-80 version (in Z80 form), which has been disassembled many times.
(The TRS-80 version was a 12K hybrid of 8K and Extended–it had single and double precision, but not long variable names or WHILE/WEND. Frank Durda notes that Microsoft scrupulously avoided any Z80-specific code, even though it would have made it about 20% faster. Oh, and Bill Gates has mentioned that IBM Basic’s graphics commands were based on the ones written for the 6809-based TRS-80 Color Computer.)
@JD
That was the quote, thanks.
@MiaM
In the Commodore days the subroutines in ROM have fixed memory locations and usually accessed from BASIC with PEEK/POKES or from assembly language, also some programs accessed the data structures directly.
Presumably, this particular 86/MS-DOS version [PC-DOS 1.00 beta/86-DOS 1.05?] – PC-DOS 1.0 is actually 86-DOS 1.1, or 1.1something, I’m not sure, would be the earliest to boot properly on a (non-prototype) IBM PC, simply because of the different disk format (Maybe the IBMPC prototypes looked for a boot sector differently) It wouldn’t be readable by 86-DOS 1.05 [this version] or any version of PC/MS/DR/Novell/OpenDOS, at least.
My web page all about the history of this ‘leaked version’ is complete! It is here:
http://thestarman.pcministry.com/DOS/ibm090/ or here:
http://thestarman.narod.ru/DOS/ibm090/
If you don’t have time to read it, the source was: Dick Conklin ; whom OS/2 fans should already know about.
To: winnt32, If you haven’t seen Michal Necasek’s article on the history of DOS 1.0 and 1.1, you might want to read that _and_ also look down in the replies where there were a few posts about the different version numbers between Microsoft and IBM, etc.
@winnt32, 86-DOS could support those formats. One just needs to reassemble the OS to use the different format. That is after all why source was provided. Each drive capacity takes about 20 bytes to define and an additional format structure would need several KB to implement. That starts combining into a fairly hefty drain on a 64kB system.
The expectation was that most users would have a multiple units of a single type of drive at a standardized capacity and would do all work in a format specifically optimized for that system. Any data transfer would be handled by external programs which have full access to the floppy controller and therefore can deal with any format the controller plus drive can recognize. The world of 1980 is very different from the early 90s when PC-DOS needed to handle at least 8 distinct formats automatically.
Hi, I have been repairing computers since 1962, and I have every version of windows here from one through 10, including the Windows 95 on fifteen disks. I have a commercial customer that I installed MSDOS 6.2, Windows 3.11 for, to this day he is still using it, and I’m still maintaining his system, and the only one who can. I worked for a company in 1982, who was one of the original floppy disk manufacturers, had the first IBM here in the area from IBM for me to qualify our five inch disc’s on their PC machine, which came with two floppy drives ,and booted with the floppy’s.
Regarding this June, 1981, Pre-Release image file, I just finished a major revision of my web page on this; including a couple files (1 text, 1 binary) of the Slack Space data you can download. Also notes about EDLIN, the .BAK file, SYS and FORMAT. Go to either:
http://thestarman.pcministry.com/DOS/ibm090/ or:
http://thestarman.narod.ru/DOS/ibm090/ (but you can’t get binary file from here).
Thank you Richard Wells for your reply… forgot to look here for your name, sorry!
Richard left me a note about why he thought I’d ‘shortchanged’ the SYS.COM util, and almost as soon as I put myself in the shoes of an early developer, it became obvious as to why they needed this! SEE my recent revision on this and a few other notes/pictures:
http://thestarman.pcministry.com/DOS/ibm090/ or:
http://thestarman.narod.ru/DOS/ibm090/
A Russian translation of this article by Softdroid is now available at http://softdroid.net/pc-dos-10-no-ne-sovsem
About the stack: it seems that programs are started with a very tiny stack space in the DOS PSP at 3Eh so it’s not too hard to overflow. I have a program which ends up overwriting the saved INT 22h termination address at PSP:0Ah and crashes the system.
I checked 86-DOS 1.0 COMMAND.COM and as expected it does the same thing: it starts a program by setting SP = 40h and pushing 0 onto the stack (so that RET will return to 0 and issue INT 20h for CP/M compatibility).
Interesting history. Regarding files without timestamp – while playing around with original PC DOS 1.0, i noticed that if file is created by “copy con”, the created file had no
timestamp, at least dir doesn’t show it.
is it possible to patch stack size so it can run on QEMU (or others)?