Mail Archives: opendos/1997/02/04/12:06:41
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
- Raw text -