Web page last updated Jan 9 2015. Portions of this page written in 2006. All content (c) Herb Johnson 2015 except for extended quotes as noted. To contact me, follow this link to my sales Web page. - Herb Johnson
The document below covers a 2006 discussion in comp.os.cpm about the history of IMSAI's IMDOS, which was developed from a very early version of CP/M. I'll not edit that discussion further, but I'll add comments and new information in this preface.
A related discussion occurred in 2007, about IMDOS and BASIC. Here's a link to my summary and review of that discussion.. It refers to my list of IMSAI documents I have available, on another Web page.
An early IMSAI ad from June 1976, several months after the IMSAI was in production, mentions "a floppy controller...with microprocessor and DOS". This at least establishes an early reference for that controller's development. IMSAI's role in CP/M, and some of its products, are referenced in an outline of CP/M history I developed during 2007, which is on this Web page. A Web page on IMSAI documents and products is part of my S-100 Web page at this link.
In late 2006, programmer Udo Munk revived his Unix Z80 emulator Z80PACK and updated it for current Linux and Unix. He then proceeded to gather 8080 based operating systems - ISIS, IMDOS, the various CP/M and MP/M sources - to compile and assemble them, and/or to run them under his emulator. Late in 2007, Udo announced he modified his code to run under Cygwin, a POSIX (Linux) application layer for Windows to run Linux programs. SInce then, he's added other packages and other hardware emulations. Note: in 2010-11 unix4fun.org has been offline. Thanks to Tilmann Reh in 2011, a copy of Udo's Unix4fun Web site is avaialable on the linked Web site.
Another archive for CP/M and IMDOS is on Gaby's "unofficial CP/M Web site". As part of the SIMH series of vintage computer emulators is a MITS Altair 8800 emulator. Peter Schorn has adapted a version of SIMH for the Altair to run many CP/M and related OS's, including IMDOS.
In June 2010 Udo Munk had this to say about IMDOS:
"I had a look at the IMDOS stuff a while ago. The bits we have left nowadays are difficult to port to any different machine, because not enough tools are left, to replace the IMDOS BIOS with your own. SIMH includes an emulation of the IMSAI IFF floppy controller, so that's why it can run the IMDOS disks left. There seems to be no technical manual available for the IFF, so once I added some debugging code to z80pack to figure, what kind of commands IMDOS send to this controller. So far I never found the time to finish a working IFF [IMSAI floppy controller hardware] emulation, maybe sometime... " - Udo Munk
By 2014, I found that Udo's Z80PACK supports the IMSAI FIF floppy controller, which was supported by IMDOS V2.05. Udo's Web site for Z80PACK also has considerable IMDOS resources, look around in his IMSAI FTP area for specifics.
In Dec 2014 I had discussions with Larry Greene, who was working on understanding and operating IMDOS. I provided him with a full IMDOS 2.05 manual (check my IMSAI Web page for specifics).
Later, I provided him with a set of IMDOS files (not the boot tracks) from an IMDOS 2.02 diskette originally imaged by Barry Watzman. Larry was able to execute the system generation program and produce a "bootable" IMDOS disk and system from those files. He provided me with both the 64K memory image of the running 2.02 IMDOS, and the binary of the generated 2.02 system. "The system track image is relocated for 16k memory and booted into this memory as a 16k system so: ccp = 2700h; bdos=3000h; bios=3D00h; monitor rom = D800h." Follow the links, to obtain those ZIPped files.
My other DRI Web pages have links to other CP/M archives and CP/M oriented sites. This and other pages and documents about CP/M, Digital Research, and Digital Systems now have a root or home page at this Web page. The root Web page for S-100 systems and documents at this page
-- Herb Johnson, Jan 2015
On June 4th of 2006, Howard Harte posted in Usenet newsgroup comp.os.cpm that he had performed some source-code comparisions between CP/M-80 2.0 and 2.2 and 3.0, and found some interesting "evolutionary" changes. He speculated on what might be interesting about the earlier 1.4 version for which there was no readily available source code. The subject title of his post was "Tracing the Evolution of CP/M-80", and it became a thread on early CP/M.
Newsgroup regulars responded with posts about a history of CP/M 1.X and and how CP/M was incorporated into IMSAI's IMDOS. Correspondents include Howard Harte, Allison Parent, Steve Dubrovich, Herb Johnson, Barry Watzman, and "French Luser" (Emmanuel Roche). I've collected and edited these comments about CP/M and IMDOS (with permission) onto this Web page. Any edits by me are in []'s.
The discussion uncovered the early history of CP/M 1.3, which apparently was a release to individual computer companies and possibly to individuals. The discussion moved to IMSAI as an early purchaser of CP/M from DRI. Related infomation from the IMSAI.NET Web site, and a post from IMSAI employee and current IMSAI trademark owner Todd Fischer, says that Gary Kildall and associates became associated with IMSAI during 1976 and 1977. Information from disks and manuals of the period also show that IMSAI provided an IMSAI version of CP/M 1.3x licenced from Kildall/DRI for the first IMSAI floppy controller. IMSAI later implemented IMDOS 2.0x, a licensed version of CP/M created sometime after CP/M version 1.3, in order to accomodate the format flexibility of their next floppy controller. Other computer vendors of the period also needed fixes to CP/M 1.4 or 1.3 BDOS to accomodate their floppy controllers and formats. But the need to accomodate multiple diskette formats per controller in later FDC hardware, and to enhance floppy disk support, apparently obliged DRI to move more disk features to the BIOS in CP/M version 2.0.
Digital Research's CP/M was essential for the microcomputer revolution of the 1970's.
The seperation of I/O from the OS was a striking feature of CP/M. It allowed anyone to buy CP/M *without the sources* and move it to their own hardware, without changing the operating system. DRI aided this ability to "port" by providing an assembler, text editor, debugger, and a "sysgen" system object code relocater. These were also tools for general program development, the other reason to buy CP/M. In the S-100 world these tools and this seperation of I/O from OS were particularly important, because any system could have any number of I/O cards from any number of manufacturers, past and present.
The isolation of I/O is also important for program development and support. Any program written for CP/M need only be compatible with the operating system - not with every single I/O device and card past and future, a support nightmare. And even those programs which were tied to specific hardware, could access it in a generic way via the uniform I/O call table at the beginning of CP/M's BIOS. Again, the BIOS was custom for each system, written either by the system manufacturer or by the guy in the basement who assembled his own system.
Today it's taken for granted that a program written for one OS - Mac OS X or Windows or Linux - will run on any machine which supports that OS. But in the 1970's standards were neither available nor POSSIBLE. Everything was NEW, and changing! If software was to become universal, an operating system had to be both consistent and flexible. So CP/M, because it could accomodate both these conditions, became the standard software platform. That allowed software vendors to flourish and hardware vendors to innovate. And DRI's low price for a single-use license allowed individuals to create their own software, and hardware, and for some to become vendors themselves. (I might add that the S-100 bus provided a similar framework for hardware development, in the same timeframe.)
I find it interesting to read about these developments, from people with either first or second-hand knowledge of events, or from people with access to original code, sources, hardware and documentation. Also, I feel it's important to seperate speculations from fact, and to verify and date statements against physical documents. This is why I posted in the thread using original documents, and why I've compiled this discussion from comp.os.cpm posts onto a document on my Web site.
Herb Johnson
Howard Harte initially posted:
Recently, I was wondering how different the various released versions of CP/M were, relative to each other. I was wondering if CP/M evolved in an organized fashion, or if each release was put together in a haphazard way. I've looked at various parts of CP/M source code from The Unofficial CP/M Web Site and I got the feeling, from looking at the contents of each archive, at separate times, that these were "snapshots" of someone's development directory.
In order to trace the evolution of CP/M-80, I started with the CP/M-80 2.0 sources, and checked them into a fresh Subversion repository. Next, I made a Tag for the CP/M 2.0 sources, so that I could easily return back to those files in the future. Then, I put the CP/M 2.2 sources in my Subversion workspace, and did a file-by-file 'diff' comparison using the TortoiseSVN client for Windows. Then, on files that matched between CP/M 2.0 and 2.2, I reverted the workspace copy back to the CP/M 2.0 copy, so that when I checked the CP/M 2.2 files in, I would only update the changed files. I repeated this process for the CP/M 3.0, and for the CP/M 3.0 with Y2K fixes and DRI patches applied. What I ended up with was a history of CP/M-80 from v2.0 through 3.0 (Y2K), and it is interesting to trace the history of CP/M this way, and see how the operating system evolved. [The] download links are on my BLOG here.
For your hacking enjoyment, I'm providing a ZIP'd copy of the CP/M Subversion Repository (1.25MB) as well as the version of the Subversion for Windows that I used (3.18MB) to create this Repository, and the TortoiseSVN for Windows (7.43MB) that I used.
If you install TortoiseSVN and Subversion (may require a reboot,) and then download and un-ZIP the CP/M Subversion Repository (1.25MB) , and then use the TortoiseSVN extensions to Windows Explorer to browse the repository, this makes seeing the difference between versions of CP/M much easier. In addition, tags are provided for each release of CP/M from 2.0 to 3.0 (Y2K).
I was not able to find much in the way of source for CP/M 1.4, but it would be very interesting to see how CP/M evolved from 1.4 to 2.0. It appears that from 2.0 to 2.2, the primary changes were bugfixes. From 2.2 to 3.0, many new utilities were added. I did do a binary comparison between some of the .COM files provided with CP/M 1.4 and CP/M 2.2, and it appears that a lot changed.
I will leave it as an exercise to the reader, and a challenge to CP/M enthusiasts, to dig up the 1.4 code (or disassemble it based on the binaries, and use the code from 2.0 to try to reconstruct the source as closely as possible.) If more of the CP/M 1.4 source is found, I'd greatly appreciate if this code would be made public, and posted on the The Unofficial CP/M Web Site.
Another interesting exercise would be to try and see where MP/M-I and MP/M-II branched from CP/M, and what files are common between them.
-Howard
Allison Parent posted:
Briefely:
CP/M 1.x was really the beginning but from 1.2 though 1.4 the were some significant internal work. V1.4 was the common and first really wide ranging version. It was coded in PL/M though you can find asm sources (by disassembly or compiled PLM source). The BIOS lacked the ease of disk reconfiguration that later versions had. The assumptions of disk structure were in the BDOS and they were sectors 128bytes, tracks 77 and sectors per track being 26 (standard 241kb SSSD 8" floppy). To fit 1.4 to another smaller disk system like NS* (5.25" 82kb) required getting inside the bdos, find and alter the internal disk size constants.
CP/M 2.x 2.0 was first release new version, 2.2 is the common version and was only bugfixes. It was PL/M source but I suspect the ASM result was hand tuned. Big change was moving the disk interface out of the BDOS into the BIOS. That changed the BIOS both in data structures and call list. The calls added were sectran, and liststat but the data provided to the diskIO calls also signaled the needed inforamtion for easier disk deblocking. The bios changes allow for disk easier configuration and adds the data tables DPH/DPB so any disk can be interfaced. The result was that 2.x was easily ported to any 8080/8085/z80 hardware.
CP/M 3.0 is a new release. Extends the 2.0 to includes some of the MPM bank features. 3.0 also breaks the 8mb logical disk barrier increasing it to 32Mb. Adds a number of system calls of the MPM flavor. - Allison
Steve Dubrovich replies to Harte:
>> [Harte:] I've looked at various parts of CP/M source code from >> The Unofficial CP/M Web Site and I got the feeling... >> that these were >> "snapshots" of someone's development directory. >>
I've the same feeling, not only of cp/m-80 but cp/m-86 as well. One point is that all of the sources should be taken in aggregate. From a version of source collections of MP/M-86 [compupro], for example, was the source for the BDOS portion of the _Loader_ program, meaning the secondary bootstrap found on the system tracks, and at that time, those loader programs were a lite version of the OS itself, [ex. read functions, but not the writes]. In the source file, LDBDOS.A86, are the comments, " 5 september, 1980 smaller version of BDOS for CP/M-86 Loader". Reviewing the BDOS entry module, LBDOSENT.A86, it starts out identically to cp/m-80 with the 6 byte s/n, the a jmp instruction which jumps over the next 4 error subroutine addresses. As an exercise, I've taken the cp/m-80 v2.2 code and run it thru the 8080->8086 translator XLT-86, and what you get is something very close and recognizable to the cp/m-86 source, such as it is, in the stripped down _Loader_ source. The same module's comments delineate between the 'old' 8080 bdos calls and the 'new' 8086 functions.
>>[harte says].. If more of the CP/M 1.4 source is found, I'd >> greatly appreciate if this code would be made public, and posted on the >> The Unofficial CP/M Web Site. >>
I'm presuming the v1.4 is the June 1975 version? If so, the pl/m source is already there.
It has the separate BIOS and BDOS refered to as the FDOS in the same BDOS.PLM file, and a separate CCP.PLM file.
I don't know what dialect of pl/m that source is, I can't get very far with the DRI pl/m nor the intel-86 pl/m. But it fits Allison's description for 8" diskettes & v1.4.- Steve
Harte replies to Steve:
Interesting that CP/M 1.4 has the BDOS and CCP written in PL/M. The later CP/M versions have these as assembly language files. Do you think the CP/M 1.4 .ASM files generated by the PL/M compiler were used to create the foundation of the later CP/M 2.0, 2.2, ... BDOS and CCP? Maybe DRI felt that hand optimizing the PL/M-generated assembly, and extending that yielded better results than moving forward with PL/M as the source for those critical parts of the OS.
What about the 1.4 utilities? Is the PL/M for those available somewhere? Doing a binary comparison between the 1.4 and 2.0 utilities indicates that the 2.0 utilities were extended quite a bit, not just patched with bugfixes. -Howard
Allison posted in response to Harte:
>> [harte:] It seems that CP/M is similar to some of the DEC PDP operating systems,
PiP goes back to PDP10 and OS/8. PDP11 and RT11 were never associated with CP/M. The Command line language is very similar for all DEC OSs.
The CP/M 3 help is decidely VMS and even RT-11 aquired that from VMS.
The early CP/M were cross compiled on a PDP10 timeshare system. Later indicators suggest a INTEL MDS running PL/M was used. VAX (Actually a VAX 11/750 running VMS) wasnt until around 81 or 82 maybe later as the 11/750 didnt exist before that.
One of the oddities from a historical perspective is managing the time compression thats perceived when looking back. There is a long window of nearly 7+ years from first versions of CP/M (1975) to CP/M 3.
The other oddity is that CP/M was most commonly purchased (not stolen) and also most frequently disassembled (for mods and understanding). As a result there are more preserved copies of the disassembly than the originating sources. Added to this the archives are often impure as they may contained patched (publicly known improvements) or even back/forward copied utilities.
The best archives are those that Gaby has and likely the most complete. Those were started as the Tim Olmstead "unofficial CP/M Archive" under the agreement with Lineo (heirs to DRI). That torch was later passed to Gaby by prior arrangement when Tim passed. I know much if this as I have a copy (on CD) of Tim's original as part of his effort to insure it stayed on the net "unofficial CP/M archive" and had helped him with others contributing to build and assemble it. This is documented on Gaby's site.
It doesnt hurt that I was an early adoptor and continued with it from there on. Also from '75 through '79 there were a number of east coast (NJ and Philly) computer shows (PCC and TCF) I'd made a point to attend and hit the various OS seminars at. I was able to watch CP/M develop and hear about it from Gary Killdal and other developers they made the shows. - Allison
Allison later posted in reply to Harte:
>> [Harte:] Interesting that CP/M 1.4 has the BDOS and CCP written in PL/M. The >>later CP/M versions have these as assembly language files. Do you >>think the CP/M 1.4 .ASM files generated by the PL/M compiler were used >>to create the foundation of the later CP/M 2.0, 2.2, ... BDOS and CCP?Yes, though from what I can tell the 2.x sources are originally pl/m.
>Maybe DRI felt that hand optimizing the PL/M-generated assembly, and >>extending that yielded better results than moving forward with PL/M as >>the source for those critical parts of the OS.
PL/M is pretty optimal for 8080. However it does do redundant pushes and pops as part of it's parameter passing.
>>What about the 1.4 utilities? Is the PL/M for those available >>somewhere?
Yes.
>> Doing a binary comparison between the 1.4 and 2.0 utilities >>indicates that the 2.0 utilities were extended quite a bit, not just >>patched with bugfixes.
Yes, the OS had a richer set of calls and the utilities had to do things like USR. - Allison
Steve also replies to Harte:
Well, Gary wrote PL/M for Intel. And CP/M was the demonstration of PL/M's use. As the story goes, Intel wanted the PL/M for its development system and wasn't interested in CP/M so it ended up back in Gary's lap and henceforth DRI [perhaps it is more correct to say the Disk Monitor rather than call it CP/M at that point in time]. PL/M was a very good optimizing compiler. IIRC, according to the French Luser, some 300 code generation patterns are optimized. Gary wrote a thesis on code optimization technique and, more amazing to me, a mathematical proof of its correctness!
>> [Harte:] The >> later CP/M versions have these as assembly language files. Do you >> think the CP/M 1.4 .ASM files generated by the PL/M compiler were used >> to create the foundation of the later CP/M 2.0, 2.2, ... BDOS and CCP?
I thought the output of the PL/M was intel .HEX, although the later intel product, PL/M-86 has a directive to generate pseudo assembly in the listing file. Frankly, I'm not too familiar with those tools.
But nonetheless, CP/M 1.4 is the foundation for 2.0 & 2.2, instead of the static 8" IBM Standard diskette layout, 2.0 opened up the Tables to other formats. But the basic form of separate logical BDOS and physical BIOS was already established. It's just that v2.0 added USER numbers and a flexible method for diskette media variety. Was it then that PRL support was added?
>> [Harte:] Maybe DRI felt that hand optimizing the PL/M-generated assembly, and >> extending that yielded better results than moving forward with PL/M as >> the source for those critical parts of the OS. >>
Perhaps, but there are public comments by Gary for the preference of PL/M over assembly. And, on into CP/M-86, some of the utilities are written in PL/M. But perhaps more to the point, is it that block structured languages, such as PL/M, are more suited to applications, than OS parts which don't tend to be block structured?? IMO, strictly speaking, CP/M isn't block structured because on program termination it resets state when it reloads the CCP.
>> [Harte:] What about the 1.4 utilities? Is the PL/M for those available >> somewhere? Doing a binary comparison between the 1.4 and 2.0 utilities >> indicates that the 2.0 utilities were extended quite a bit, not just >> patched with bugfixes. >>
Well, there is LOAD.PLM, a utility to load from paper tape connected to the aux port, in with the CCP.PLM and BDOS.PLM, but ED.PLM and PIP.PLM are not there. But in the cpm80 v2.0 source there is ED.PLM, STAT.PLM, SUBMIT.PLM and PIP.PLM modified for v2.0. - Steve Dubrovich
The "french luser" adds to Steve's comments:
Ho, boy! Steve, how can you mix so many things? Haven't read all my posts over the years?
(Sigh!) Ok. Let us try to set straight a few things.
- "Gary wrote PL/M for Intel". Yes.
- "And CP/M was the demonstration of PL/M's use." According to Gary Kildall in his DDJ article, once he had PL/M running on Mainframes, he wanted to have it on the Intellec 8, so that turnaround times would be smaller. But, to run a compiler, you need some sort of cassette tape Operating System or Disk Operating System. At the time, 8" floppy diskettes were the great novelty, and he was using them on his IBM S/360 at the NPS... so, why not try to fit a floppy disk drive to his Intellec 8? As he wrote, he was unable to make the electronic card, and the hardware project was stopped one year, during which he improved and improved PL/M and CP/M so much that he was convinced that it was working correctly, as he could see on his simulator. Then he met John Torode... and the rest is history!
- "As the story goes... point in time." The 8080 CPU was so successful that Intel decided to put all his resources to production of the hardware, and jettisoned the "Intel Software Group" made of 3 persons (whose names are given in an old issue of DDJ, one of the 3 being, of course, Gary Kildall).
- "PL/M was a very good optimizing compiler." AAArrrggghhh!!! Steve! You! NO!!! Not PL/M (my disassemblies of old PL/M programs show that PL/M was surrounding procedures with jumps), but PL/I-80!
- "IIRC, according to the French Luser, some 300 code generation patterns are optimized." NO: in several articles explaining PL/I-80, Gary Kildall spen[t] a lot of time explaining to the people using CP/M at this time that PL/I-80 was the only one optimizing compiler ever written for CP/M (since it was to become the official PL used by DRI over its family of DOSes). In several of his articles, Gary explains what PL/I does to produce such a good code and, in one of those articles, he mentions that more than 300 patterns are optimized by the 3rd pass.
- " Gary wrote a thesis on code optimization technique and, more amazing to me, a mathematical proof of its correctness!" Yes. If you have any interest in compilers, the standard text is nicknamed the "dragon book". Every compiler writer under Unix has read it. The reference of this book lists several papers by Gary Kildall on the subject of code optimisation, for which he got a Ph.D.
>> [Steve:] (...) It's just that v2.0 added USER >> numbers and a flexible method for diskette media variety. Was it then >> that PRL support was added?
PRL are used by MP/M to relocate programs in memory.
>> Perhaps, but there are public comments by Gary for the preference of >> PL/M over assembly. And, on into CP/M-86, some of the utilities are >> written in PL/M.
In CP/M-86 Plus, only 3 programs are written in 8086 assembly language: everything else is in PL/M. - Yours Sincerely, "French Luser"
Herb posted:
1) "French Luser" is posting about the history of Gary Kildall as regards the development of CP/M. There are a number of Web sites which provide either that history directly, or have copies of articles written by Kildall. To my knowledge they will confirm all of what "Luser" has posted. I think it's informative to know that history in any review of CP/M before V2.2. It's interesting in any case, at least to me.
2) A history of early CP/M should include the release of IMDOS by IMSAI, as that represents one of the earliest versions of what became CP/M. This statement is confirmed by accounts at [the IMSAI.NET site interview] where IMSAI staffer Todd Fischer states outright that he worked with Kildall on "various permutations of [CP/M] rev. 1.2 and 1.3 on the IMSAI FDC and DIO floppy systems". According to information posted by Todd from IMSAI staffer Joe Killian, Glenn Ewing (a colleague of Kildall at the Naval school) worked closely with Kildall to develop IMDOS. The discussion posted at imsai.net dovetails nicely with the history posted in this thread by "Luser".
3) An early version of IMDOS should be available at the "unofficial" CP/M Web site as "early CP/M" under "CP/M 1.x". Text inspection of the object files suggest dates of 1976 and 1977 and 1978, consistent with the info referenced on Fischer's site. A Web search for IMDOS may also be informative and find other files.
Note: I've used the word "staffer" or "colleague" to establish a strong association between persons or with an organization; not to argue about the specifics of that linkage. Refer to sources referenced for specifics. - Herb Johnson
Barry posted:
Herb, IMDOS, at least as a public release, came after CP/M 1.3 and very close to 1.4, but well before 2.x. In fact, I have a copy of IMSAI CP/M 1.33 here, which predated IMDOS. - barry
from Herb:
Thanks for this info. Certainly the first IMDOS was before CP/M 2.2. I assumed that IMSAI's earliest Kildall-based OS's were called IMDOS and not called CP/M. [Not so. - Herb] But they may have been casual about what they called it, when. I don't recall at the moment any non-IMSAI distributions or uses of a version 1.3. Version 1.4 became a general distribution of CP/M and it became much more well-known about that time because it was easily ported and it provided all the tools and docs needed to do so. That, and the modest price, was Kildall's great achivement.
Fischer's site has some date info for IMDOS and CP/M development. I don't know what version of IMDOS is on the "unofficial CP/M Web site". [It's apparently IMDOS 2.05, with DRI utilities and code, from file dumps I subsequently reviewed.- Herb]
Barry, it would be informative if you did the courtesy of (hex/text dump) comparison of those [IMDOS] files on [the unofficial CP/M] Web site versus whatever files you can pull from your original labled (or copy?) IMDOS disks. (Reading old IMDOS disks may not be trivial as the earliest IMSAI drive controller was not built around a single chip FDC. Also some early floppy drives were notorious for alignment problems.) - Herb Johnson
From Barry:
... no, Imsai was not casual about naming the OS' at all. When IMSAI did their first disk system (I had several of them at the time), it was the FDC2-2 dual 8" system with the white dual Calcomp drives (140's initially, then later 142's). The original disk controller was the IFM/FIB 2-board set (the IFM was a full 8080 system in and of itself with ROM and RAM and a separate 8080 CPU on board). This system came out with CP/M (NOT IMDOS) version 1.3. They worked up through 1.33, I believe. I still have those original diskettes (IMSAI CP/M 1.33 ... it was generic CP/M although there were some IMSAI proprietary utilities shipped on the disk as well). I also have an IMDOS 2.02 diskette.
At this point, my recollection gets a bit fuzzy, but I'm thinking that IMSAI came out with IMDOS about the same time as -- and I think instead of -- CP/M 1.4. When IMSAI introduced the VDP series of products (the VDP-80 was first), they also introduced the DIO/PDS 2-card disk controller set. This was the first IMSAI disk controller that could do anything other than single density 8", and IMDOS was introduced with it, or perhaps slightly before it, to support double density and also 5" diskettes.
By the way, both of these controllers (the IFM/FIB and the DIO/PDS) and all of the IMSAI 8" single density media were fully IBM compatible and also CP/M compatible, so reading the media was not (would not be) a problem.
However, IMDOS was IMDOS and CP/M was CP/M. There was no confusion at the time, although it was acknowledged that IMDOS was an IMSAI development derived from CP/M (and IMSAI had a CP/M license to cover them legally).
I do believe that there was limited non-Imsai use of CP/M 1.3. I went to high school with Dale Heatherington (a partner in and the technical brains of DC Hayes, the modem maker, and the namesake of the "Heatherington patents"), and when Dale and I both lived in Atlanta in 1975 (?), Dale bought a copy of CP/M directly from Digital Research for $70 and got it working on an early 8-inch floppy. It was the first disk system that I ever saw other than an actual IBM floppy disk based data entry station. - Barry
from Herb;
Thanks for the informative reply. It's good to work this history out on comp.os.cpm, so others can add their accounts and refer to any original documents or disks. Barry, with your permission and other posters in this thread, I'll add our remarks to my Web site on my DRI Web page.
I did not use the earliest IMSAI equipment at the time but I have some of it around now, and some docs. From those, I've determined that IMSAI offered or intended to offer IMDOS as early as Nov 1977. The earliest IMDOS manuals and disks I have are Version 2.02 from late 1977 or early 1978. in one of those, IMSAI clearly states that IMDOS is an "enhanced version" of CP/M from Digital Research. The following details these conclusions.
1) In my hands right now, I have 5.25" diskettes labled "IMDOS VERSION 2.05 (c)1978 IMSAI MFG CORP". The lables are pasted on but they have serial numbers so I assume these are original IMSAI diskettes or copied from same. I also have one IMDOS V2.02 (c)1977 labled diskette.All these appear to have been associated with a VDP-40. I also have some manuals for IMDOS which state "IMDOS...is CP/M compatible." One IMDOS document I'm looking at now is from May 1978; in brief the IMDOS it describes seems by features and programs to be a superset of CP/M.
2) In my hands is an original IMDOS User Manual for IMDOS 2.01 / 2.02 dated 2/14/78, the earliest one I may have. It has the following preface:
"The IMSAI IMDOS floppy Disk Operating System is an ehnanced version of the Control Program Monitor (CP/M) originally developed by the Digital Research Corporation. IMDOS contains extensive enhancements regarding number and variety of floppy disk drives supported, user control of diskette date format, and additional features in system calls available to user programs. IMDOS is program compatible and file compatible with CP/M; IMDOS's Console Commands contain several additions and variations. CP/M is a trademark of Digital Research" The page is dated 1/8/78.
3) I have a manual for IMDOS - II version 1.0 dated 1979. I did not examine it further.
4) My original "DIO Conroller user manual" is dated Nov 1977. It refers to the 2-card controller set Barry described. It supported Shugart SA800's, GSI 110's and Persci 270's (single or double density 8-inch) and also SA400 (single density only 5.25").Barry, I mentioned readability problems because the Persci's were notrorious for alignment and cross compatibility problems. Also, some floppy controller manufacturers did not properly implement the IBM 3740 format in that era. In any event, this manual refers only in passing to operating systems, and then only the "IMSAI IMDOS System diskette" with a PCS-80 or VDP-80.
5) The IMSAI "Diskette System Reference Manual" for Nov 1978 is a hardware reference, and refers to the "IMDOS User's Manual" for operating system software. the hardware described in this manual is the FIF controller (the IFM and the FIB card set), the MDIO controller (one board with a 1771 chip), and the DIO controller (two board set as previously described).
Again speaking of formats, the brief description of the DIO says the DIO-A original version supported IBM 3740 AND "format V, a 128 byte/sector double density format". continues to say the DIO-B supports these and also supports a different head step rate; and the DIO-C which replaced the previous versions and other formats
6) My "IMSAI Floppy Disk System User Manual" copyright 1976 (erata page 4/77). Test code is dated 10/7[6]; This manual only covers the IFM (rev 6) and FIB (rev 3) floppy controller card set, with Oct 1976 firmware listings. This is the earliest IMSAI controller.It's all hardware and firmware for those two cards and associated floppy drives. It has a few references to operating systems, but ALL of those references are to CP/M - no mention of "IMDOS". Phrases are "...now configured as required for ...CP/M operation"; "..bring up IMSAI CP/M, refer to the IMSAI CP/M USER MANUAL". The 1977 section on "System User Guide" mentions "IMSAI CP/M documentation".
[Note: after this post I found an IMSAI PCS 80/30 Reference Manual which specifically referred to "CP/M 1.33". So for some period in late 1976 through early 1977, IMSAI apparently offered some version of CP/M and not "IMDOS" by name. - Herb Johnson]
[Note: In March 2008, Jeff Shook offered this confirmation as follows: "I have a photocopy of part of an IMSAI CP/M 1.31 Rev. 1 manual dated 1/27/77 but it has only the "VI. Major Enhancements and Differences" and "VII. Notes on the Digital Research User Guides" sections. The CP/M manuals and code listings are not there." Here's the dated title page Jeff provided. - Herb Johnson
Barry replies:
IMSAI's motivation for IMDOS was largely a consequence of the fact that CP/M 1.3 and even (equally) 1.4 only supported one single format .... IBM 3740 eight-inch single density (77 tracks of 26 sectors of 128 bytes per sector). That was, also, all that the IFM/FIB controller set supported. However, the DIO/PDS set could support many (almost an arbitrary number of) formats, including 5.25" and double density eight-inch. But CP/M (until 2.x) could not, so I believe that was the primary motivation for IMDOS.
(I think that a secondary motivation was that they could offer product like Microsoft Fortran and lock it to what was then an IMSAI operating system, thus preventing use of a copy of Microsoft Fortran bought from IMSAI on non-IMSAI systems.)
The Persci drives were, when used with a soft-sector configuration, totally standard eight-inch floppy disk drives. Of course any given drive could be out of radial alignment, but that is true of any model of any brand of drive, and has little to do with anything else.
Allison added:
Make that [CP/M 1.3 or 1.4] easily supports only one format. I have CP/M V1.4 for NS* MDS (single density) both the Lifeboat version and NS* versions.
So everyone knows/remember the single density NS* MDS was 35 tracks, 10 sectors of 256 bytes single sided and only 3 drives possible. Around 82k useable space (cpm formatted).
CP/M 1.4 was the first commercially useful version and while it was difficult to set up for other than SSSD 8" it was doable if you were willing to dig inside the BDOS. Apparently DRI was willing to help major vendors do it. - Allison
In reply Barry added:
Yes, CP/M could be modified for other disk formats, but it meant changes in the BDOS in versions 1.3 and 1.4, rather than in the BIOS. I worked with Larry Alkoff (Lifeboat) on such a modification for the Lifeboat CP/M on the Heathkit [H89? H8?]systems (hard sector 5.25" single density).
However, that still misses the point regarding IMSAI's implementation for IMDOS.
The Imsai systems that were the motivation for IMDOS needed to support multiple formats concurrently in the same system .... single and double density / sided eight-inch AND 5.25" media, all intermixed concurrently. And THAT was simply not reasonably possible with CP/M 1.3 or 1.4, even IF you had source code and were willing to patch the BDOS. It was simply a too-radical departure from what those versions of CP/M were intended to support. It wasn't until CP/M 2.x became available that such versatility would be possible, but IMSAI needed those capabilities more than 2 years before CP/M 2 would appear.
Herb responded:
Barry's comments about the shift to multiple floppy formats are consistent with my brief read of IMSAI manuals I described. The earliest IMSAI floppy controller supported only one format and were supported by some version of CP/M; later controllers supported multiple formats as supported by IMDOS. IMSAI moved from a controller with its own processor (and code) to a single chip FDC; each new controller provided more format options. Likewise, outside of IMSAI (as Barry pointed out), other S-100 manufacturers were developing their own floppy disk hardware and following similar hardware trends. Their OS's likely have similar relationships to early DRI's CP/M.
This IMSAI discussion dovetails nicely with the interview notes of "Chief IMSAI Engineer" Joe Killian on the IMSAI Web site which discuss the strong collaboration between IMSAI and DRI in 1977. Killian says there that Glenn Ewing, who was then Gary Kildall's colleague at the Naval school and who later became an IMSAI engineer, "talked Gary into just separating the I/O from the rest of [CP/M], with Glenn promising to re-write the I/O module for the IMSAI 8080 (which he did)".
Let's bring this back to Howard Harte's original posts on tracing the evolution of CP/M.
It's clear from IMSAI documents of the era, and from first and second-person accounts, that IMSAI developers worked with Gary Kildall on CP/M before or during version 1.3, to create IMDOS (probably version 2.0) as licensed from Digital Research. Therefore, a code review of IMDOS will likely show common code with CP/M 1.4 and with the earlier and much rarer CP/M 1.3. In addition, a likely and major code change from CP/M 1.3 to 1.4 (and IMDOS) to 2.0 should be an increased isolation of floppy I/O from the operating system code.
The isolation of I/O from the OS provided multiple dividends to developers and to users, to say the least. The flexible CP/M operating system, and the flexible S-100 hardware bus, were in my opinion essential to growth and development during the 1970's of what we now call personal computing. (Other computing OS's and hardware architectures were also important of course.)
I hope those with original OS disks for CP/M 1.3 and IMDOS 2.X will make the files available as appropriate. I'll see what I can do with mine. Of course I've made IMSAI documents available via my Web site for many many years. - Herb Johnson
Reply from Barry:
Herb, Imsai really never moved to a single disk FDC using a WD chip. They ultimately did offer such a product, but not until very close the end of IMSAI, and I've never seen that board. The primary move was from the IFM/FIB 2-board set to the DIO/PDS 2-board set. The former was 8-inch SSSD only, the latter was quite versatile in terms of formats.
Regarding CP/M 1.3 and 1.4, there is less difference than you seem to think, and it's not where you think. The BIOS/BDOS architecture was virtually unchanged. The big difference was that CP/M 1.3 was very, very bad about trashing your diskettes if you changed them without doing a warm start (control-C). In CP/M 1.4, DR began checksumming the directory to detect that the disk had been changed. This greatly reduced (but did not totally eliminate in all cases) the incidence of a diskette's contents (actually the directory) being destroyed if the user changed disks at an inappropriate time and did not do a control-C. That was the largest single difference between 1.3 and 1.4, as I recall (in 2.0, the checksum vector area was moved to the bios, along with the other disk parameters). - Barry
Herb posted:
[Regarding the IMSAI single-chip FDC board,] A FDC board was mentioned, with a 1771 controller, in the manual noted. I guess they did not produce it. And the manual went on at length about formats for the DIO/PDS set., as you've said. It was a stretch on my part to include a 1771 based board in my IMSAI remarks. But other companies went on to use such chips on their boards. The fact that CP/M could be supportted on boards with that and other FDC chips is notible overall.
[Regarding CP/M 1.3 vs. 1.4,] Actually I'm just quoting the IMSAI interview. I've not looked at the IMSAI code myself or the IMSAI docs in any detail this week beyond what I've reported. Don't think I've ever seen CP/M 1.3 as such. I may have poked at IMDOS in my lifetime, on some PDS system decades ago.
But it's possible the collaberation described between "IMSAI" and Kildall occurred before CP/M 1.3. That email interview did not mention specific versions, nor did the IMSAI docs I have reviewed mention CP/M versions. The interview did give dates, although they are from memory and even Todd Fischer suggests those dates may be inconsistent. The dates I gave are printed in the IMSAI docs I referenced. What dates can you glean, Barry, from your IMSAI CP/M 1.3 and any related docs for it?
My point was to make a case as to why a review of early CP/M code should include IMDOS code. Along the way, I've confirmed most or all of Barry's remarks from memory - that's pretty good for 30-year-old recollections! Between you, Barry, myself (from the IMSAI docs) and Todd's interview notes I think the case is made.
The next step is to look at some code, seems to me, and dig up some more docs and disk of the period. - Herb Johnson
Barry repiled:
I think [the FDC board] was produced in very low volume for only a few months at the very end of Imsai's existence. The 1771 was VERY popular and Imsai should have gone with it much earlier. However, Imsai and Processor Technology both had a penchant for doing things in their own proprietary way, very much to their own detriment. Very bad cases of "not invented here" syndrome. Tarbell, Cromemco, Vector Grahics and many other firms used the 1771, and ended up with better, faster, more reliable and lower cost products as a result.
Todd Fischer of IMSAI posted:
Herb and Barry have many of the "facts" correctly interpreted or assumed, but we (IMSAI) DID have a 1771-based controller; the IMSAI MDIO, that was a single-board solution to a 5.25", 35-track controller intended for the lower end market. We offered the Shugart 35-track 5.25" drives as standard for this system which could support up to four of same.
The (sub)systems which featured the MDIO included the PCS (Personal Computer System) line and VDP-40 (Video Data Processor) system. We sold quite a few i.e. perhaps a few thousand between their introduction during IMSAI's second phase (early 1977), and 1979 when the original company closed down in October of that year. Most serious business and educational users opted for the higher capacity DIO/PDS board set which relied on an software supported 8085-based controller with a very temperamental analog data separator board (the Programmable Data Separator). Late 1977 brought out a much more stable PDS board that really tightened up reliability in the form of the IMSAI PDS-II; developed by a very gifted engineer who worked under Glen Ewing (who was now our new Chief Engineer, having replace Jan Vath). This same engineer also designed the equally improved RAM-III memory boards that added much improved reliability and helped ease the burden of our overworked and underpaid Customer Support Department.
IMSAI never entertained the thought of a hard-sectored disk format, aiming instead for the greater data storage capacity of soft-sector ala IBM 3740, even though we strayed from the original single sided/single density 8" spec when we went for double and even quad density toward the end with variants of the DIO/PDS disc controller board set.
As for CP/M 1.3 and IMDOS, we offered CP/M 1.3 with the original IMSAI IFM/FIB controller from very late 1976 until around the middle of 1977 when Rob Barnaby (our Chief Programmer) created the much enhanced IMDOS; a direct variant of the original CP/M 1.2/1.3. I still have the original hard copy source code initialed and serial numbered by Gary Kildall. We had license number 3 and were the first and only entity to have unlimited rights to source code and distribution at that time.
All of the module listings in my listing copy are in assembly language, and it is my understanding that all development work in version 1.2 and 1.3 was done on an Intel MDS system, which both Gary and IMSAI had at their respective facilities. Gary would cruise up to our offices in San Leandro in his white 1975 Corvette coupe, bring in an armload of greenbar listing dumps and a box of Dysan 8" disks, then proceed to the programmer's office to work his magic with our hardware, seldom spending even a full day at our location.
In contrast, when Rob Barnaby joined us in 1977, he'd lock himself in his office for two or three days at a stretch, programming like a demon and sometimes ranting about "some flakiness with his computer", at which point myself or my counterpart, John Coons, would work our own brand of magic to get him back online and in a better mood. He was difficult to work with and understand, but his brilliance and talent outweighed his shortcomings. This was the guy who later brought you WordStar, a direct descendent of IMSAI's NED (New Editor), and John Coon's "DAISY" and "JUSTINE" proportional print drivers that formed the first successful document entry and formatting environment, and was used starting in 1977 for in-house document and manual preparation.
But that's another long intrigue, better suited for a later discussion.
Regards to all, Thomas "Todd" Fischer ----------------------
Note: Steve Dubrovich and "French Luser" also had a discussion of PL/M in the comp.os.cpm thread, which I've not included in this summary. Steve Dubrovich later posted:
In looking around, besides Gaby's, for the CP/M PLM code, I find this in DRIPAK.ZIP [at http://www.retroarchive.org]
Volume5.doc : *** " This is the original .doc file on the cpm user's group Volume 5 - this originally contained the source of the public domain version of CPM, and the tape was later ERASED...... ------------- start of original ---------- BASIC-E THIS DISKETTE CONTAINS 2 VERSIONS OF THE BASIC-E COMPILER BAS2-0 AND BAS2-1, AND THREE VERSIONS OF THE RUN-TIME INTERPRETER RUNK2-0, RUN2-2 AND RUN2-3. THE BUGS AND RELATIVE MERITS ARE UNKNOWN. TRY THEM. NOTE THAT IN THESE VERSIONS, THE COMPILE TIME OPTIONS ARE PLACED IN THE COMMAND NOT IN THE FILE - EG "BAS2-1 WUMPUS $B" OTHELLO IS OVERFLOW BASIC-E PROGRAM FROM VOLUME 5 MICROSOFT BASIC (AND SIMILAR) THE FILES ???????.ASC ARE ASCII SOURCES OF PROGRAMS WRITTEN IN MICROSOFT - TYPE BASIC. PROBABLY NEEDS LITTLE PATCHING FOR DEC PDP11 EXTENDED BASIC, TDL AND OTHERS. THE SUFFIX ASC IS USED TO DISTINGUISH THEM FROM THE TOKEN FILES WITH BINARY LINE NUMBERS, WHICH HAVE .BAS SUFFICES. CP/M SOURCE FILES THE JUNE 1975 RELEASE OF CP/M IS IN PUBLIC DOMAIN. THE PLM AND ASSEMBLY FILES HERE ARE PART OF THAT RELEASE. THE FULL RELEASE WAS: CCP.PLM BDOS.PLM PIP.PLM LOAD.PLM DUMP.ASM IOLIB.PLM THESE ARE CERTIFIED BY GARY KILDALL TO BE AVAILABLE FOR PUBLIC DISTRIBUTION FOR ANY PURPOSE WITHOUT RESTRICTION " *** However only CCP.PLM, BDOS.PLM and LOAD.PLM are found on Gaby's site and also in the DRIPAK.ZIP, the others in the above list are absent. A noteworthy thing about the DRIPAK.ZIP is that those PLM files are listed in cpm_v1-3 Directory, so perhaps those are that version? http://www.retroarchive.org has the DRIPAK.ZIP ; http://www.retroarchive.org/cpm/os/os.htm There is also a \cpm_v1-4\ and in it a file: IO4OS32.ASM which reads in part: " ; CP/M BASIC INPUT/OUTPUT OPERATING SYSTEM (BIOS) ;( TARBELL ELECTRONICS) CVE MOD OF 9-5-81 ; 1.4 VERSION OF 7-20-79 ; THIS BIOS CAN ALSO BE USED WITH 1.3 VERSIONS BY ; CHANGING BDOS EQU FROM CBASE+3106H TO CBASE+3206H. ; (NOTE THAT CP/M VERSION 1.3 ONLY SUPPORTS 2 DRIVES, ; WHILE CP/M VERSION 1.4 WILL SUPPORT 4 DRIVES.) ; " This indicates a V1.4 date of 7-20-79, although this is a quote from the BIOS source, so is it accurate also for the BDOS version date? It seems like a long streatch of time from v1.3 of 06/1975 to v1.4 of 7/1979. The v2.2 source typically carries the date: title 'Bdos Interface, Bdos, Version 2.2 Feb, 1980'
Copyright © 2015 Herb Johnson
