Date: Tue, 04 Feb 1997 09:48:27 -0600 (MDT)
From: Roger Ivie <IVIE AT cc DOT usu DOT edu>
Subject: Re: [opendos] OpenDOS + Win95 w/FAT32?
To: OPENDOS AT MAIL DOT TACOMA DOT NET
Message-id: <01IF0HOBNOK68ZN3P7@cc.usu.edu>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Sender: owner-opendos AT mail DOT tacoma DOT net
Precedence: bulk

Being a really old fart, I had earlier composed a message on this subjec
describing how MP/M and CP/M 3.0 booted, but then decided it wasn't really
relevant, tossed it, then found this message:

Someone (I forget who) wrote:
>>Mark Habersack writes:
>>
>>> > And perhaps also go along the lines of Linux and have loadable =
>modules
>>> > (a bit like VLMs).
>>>
>>> Now, that's the way to go! But, once again, we have to develop a
>>> standard for these drivers.
>>
>>Hmm, there is an interesting question. If filesystem support is loaded
>>from CONFIG.SYS, and you want to have a 100% VFAT or even ext2fs
>>filesystem, how will DOS be able to read the filesystem to find
>>CONFIG.SYS so that it can load the file system driver that is required
>>to read things from the filesystem that CONFIG.SYS is held on....

Of course, there is no way I can recapture the elegance and wit of my 
earlier treatise :-) so you'll have to put up with this one.

The problem MP/M and CP/M 3.0 (aka CP/M+) were trying to solve was slightly 
different, but the solution is interesting and, I think, applicable.

In CP/M systems, the operating system is loaded from reserved tracks on a 
system disk. In the case of the standard 8" SSSD disk, two tracks are 
reserved to hold the operating system (26 sectors/track, 128 bytes/sector = 
6,656 bytes for the whole operating system). This was gobs of space in CP/M 
1.4 which a) was _really_ simple and b) only supported 8" SSSD floppies 
(i.e., the drive geometry was hard coded in the operating system).

When CP/M 2.0 came out, things started getting tight in the reserved 
tracks. CP/M 2.0 added a number of features (like random access files! 
(could be done under CP/M 1.4 but is really messy (if anyone is really 
interested, I can describe the theory behind it))) that took a lot more 
code. Still, your average CP/M 2.x system still fit in the reserved tracks 
set aside during the CP/M 1.4 days.

MP/M and CP/M 3.0 were a big problem. MP/M is a multiuser version of CP/M; 
it's larger than 6,656 bytes just for the parts distributed by Digital 
Research, let alone the customized BIOS needed to make it run on your 
hardware. CP/M 3.0 added disk caching, passwords, time stamps on files, and 
lots of other goodies to CP/M; it was also quite large. But the average 
customer still needed to be able to use his old disks, which only had the 
meager space set aside for CP/M 2.x. There was just no way to cram the 
new operating systems into the reserved space on the old disks.

To deal with this, Digital Research came up with a stripped-down read-only 
version of CP/M called MPMLDR (for loading MP/M) and CPMLDR (for loading 
CP/M 3.0). This was small enough to fit in the old reserved space and 
functional enough to find the _real_ operating system on disk and load it 
into memory.

Loading a really fancy DOS could be done the same way. You provide a small 
DOS system which is loaded in a normal DOS partition. It contains code and 
the tools needed to boot DOS from the fancy partition. When you boot the 
machine, it boots the stripped down DOS which finds and loads the _real_ 
copy of DOS in whatever filesystem it lives. Since the stripped down DOS is 
a special-purpose operating system, it doesn't need to be a fully funtional 
DOS; it just needs enough to be able to read the filesystems in which DOS 
might be stored and jump to it.

Configuring MP/M and CP/M 3.0 was also interesting. Since Digital Research 
didn't want to ship sources, they shipped linkable object modules. There 
was a front end program which configured the object modules and then you 
linked them together with your customized BIOS to build a system. System 
configuration could also be done this way for a DOS system; Joe Random User 
Who Doesn't Have the Tools to Recompile could be handed an object 
distribution with a configuration program and a linker. Joe Pseudorandom 
Coder could get the sources to build the object modules.

FWIW,

Roger "an old fart" Ivie
ivie AT cc DOT usu DOT edu