CP/M BIOS setup

From: ajp166 <ajp166_at_bellatlantic.net>
Date: Wed Oct 4 21:54:49 2000

From: Richard Erlacher <richard_at_idcomm.com>


>For some time, I've pondered what it might take to divine the various
format
>features from a CP/M boot disk. It seems to me that if one has a
bootable
>disk, it has to have sufficient information on the boot tracks to allow
one
>to find a copy of the BDOS, which, so long as it's the right version of
>CP/M, should disclose the details of what formatting has been used for
those


The bdos can't tell you much other than it's version.

>tracks. What's more, given that one can find the BDOS, byte for byte,
one
>should also be able to find enough of a BIOS to make it possible to
extract
>the necessary disk parameters used to boot the system. If a second-tier
>system is loade, one should be able to find that by examining the
autcmd.
>That should then yield the data necessary to read the diskette in its
>entirety.

the key parameters are the DPH, DPB and SKEW... also you need to know
how big the sector is and if there is embedded skew within the sector.
Then you need to know the disk layout, things like what side/sector
numbering was used. For example I've seen two sided media where
sector one occured on both sides and where identically formatted, also
I've seen side one as 1 thru 9 and side two as 10 through 17...

It is possible to devine all that from a bootable disk (I have a few that
would never give you that as the core bios is not on the disk at all)
but it's a lot of processing and at last count there were some 80 formats
for 5.25media alone.

>Have you ever run into a utility that handles this? I'd think someone
would
>have done this by now.


Yes, Media Master, Uniform, Multidisk, Eset are a few I use and they all
work from tables and have expectations of a bios having a standard
configureation so they can "drive" the bios.

I also use a modular bios that runs on a slave cpu for the S100 crate
and dropping in different drive parameters is straightforward. I tend to
treat
devices as interchangeable peices by using a abstraction layer. To me
the
BDOS calls the BIOS and the BIOS if it needs to calls a device driver.
One
common misconception is the BDOS calls a FDC (simplification). It doesnt
and that why the BDOS called the jump table at the start of the BIOS.

>Another item I've wanted for some time to automate is the setup of a
hard
>disk BIOS. Since it's dependent not so much on CP/M quirks but often
more
>on decisions made on the basis of folklore, I thought it might be
>interesting to examine the process as a candidate for automation.


The answer is yes it;s doable and it's not worth it from where I sit.
One
reason, I have the tools needed and there are plenty of freeware
out there if I dont.

Me, I use my kaypro and my s100 crate (3.5, 5.25 and 8") for this and a
copy of multidisk (table driven) and a version of Eset, used to hand
feed parameters to the parameters for oddballs. In the general scale
of things these do the job well and are more than enough. Some things
deserve a simple solution.

Allison
Received on Wed Oct 04 2000 - 21:54:49 BST