CP/M BIOS setup

From: Don Maslin <donm_at_cts.com>
Date: Thu Oct 5 15:31:28 2000

On Thu, 5 Oct 2000, Richard Erlacher wrote:

> I must have screwed up an put this out on the list. I thought I had
> modified the destination address . . . <sigh> another "senior moment." It
> might not be bad to kick this around among those who know.
>
> Please see embedded remarks below.
>
> Dick

I am reminded that the Kaypro program MFDISK - a sort of mini-UniForm -
had a feature that took a 'guess' at what format the foreign disk in the
drive was. It wasn't always right, and its choices were somewhat
limited, but it would be interesting to see how they approached it.

                                                 - don

> ----- Original Message -----
> From: ajp166 <ajp166_at_bellatlantic.net>
> To: <classiccmp_at_classiccmp.org>
> Sent: Wednesday, October 04, 2000 8:54 PM
> Subject: Re: CP/M BIOS setup
>
>
> > 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.
> >
> I wasn't thinking so much about ASKING the BDOS as much as I was looking to
> examine the thing in order to get the sector interleaving and skew data.
> (skew being the relative position of the sector sequence from one track to
> the adjacent ones. The BDOS doesn't change, generally, though there may be
> changes in the BIOS. By finding each sector of the BDOS, one learns about
> the format of the boot tracks. My CCS system, for example, requires, at
> least for the distributed boot EPROM, that the boot tracks be SSSD. That
> said, the write-up accompanying the controller suggests that one could make
> a DD boot disk by formatting the boot tracks SD. The rest of the diskette
> could be formatted DD, whether single- or double-sided. Consequently, it's
> necessary to reexamine the disk to see what the interleave (which DRI and
> some people call skew), skew, sector size, modulation, and other parameters
> for the remainder of the diskette are. For that reason, it's necessary to
> find a known file e.g. PIP.COM, or some other standard facility, which can
> also be subjected to byte-by-byte comparison in order verify that the
> parameters extracted from the diskette are valid.
> >
> > >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
> autocmd.
> > >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...
> >
> These parameters are all there on a boot diskette. It's just necessary to
> find them.
> >
> > 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.
> >
> The Multidisk and Eset that I have are not for this purpose. They want to
> be passed the information that I'm suggesting could be extracted.
> >
> > 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.
> >
> That's exactly the problem I'm trying to circumvent. The interleave, skew,
> sector size, etc, are all accurately represented on the boot diskette. The
> BDOS is the BDOS, i.e. shouldn't be different on different boot diskettes,
> so long as the CP/M version is the same. Consequently, it should be
> possible, having once determined the sector size, to extract, automatically,
> the relative locations of sequential sectors of this known file. Since we
> KNOW and RECOGNIZE the BDOS, shouldn't it be possible to find its beginning,
> end, and intervening parts on the diskette? It may not be an instantaneous
> operation, but one should be able to conjure up a program to determine the
> sector size, map physical to logica sector layout, and determine the
> difference in sector numbering from one track to the next. It is certainly
> possible to compare what lies where the BDOS should lie with a valid copy of
> the BDOS. Likewise, having found the BDOS, extracting the various disk
> paramters from the system BIOS and verifying them against another known file
> e.g. PIP.COM, should provide the necessary information about the directory
> and data areas of the diskette. Isn't that so?
> >
> > >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.
> >
> Well, I don't see hand-feeding a set of parameters that one has to determine
> by guessing on the basis of lots of conflicting folklore as particularly
> easy. Authors who wrote about the process e.g. Laird and Cortesi seemed to
> equivocate considerably about this, and, while it's straightforward to come
> up with a set of parameters that work, it's not easy to come up with the
> optimal ones, at least where the HD is concerned. Both of the authors I
> mention published utilities that extract parameters from the existing BIOS
> once it's running, but neither discusses the whys and wherefores
> sufficiently to imply a rigorous method of establishing a single, optimal,
> layout for a HD. Likewise, they don't provide a rigorous method for finding
> the parameters in use on a system disk from a foreign system. Once the data
> is in hand, it's easy, certainly, but what should one do, given a known
> bootable but otherwise undefined boot diskette? The reality of the data
> present on a boot diskette defines all the parameters necessary to recreate
> it, doesn't it?
>
> I get emails from people all the time, asking about how to build a boot
> diskette for a system they can't boot because they don't have a BIOS on the
> diskette for the I/O ports they use. Likewise, I get frequent questions
> about how to formulate an optimal configuration for a hard disk. While it
> may not be a terrible thing, it is something many people, including myself,
> though I've done it several times, find daunting. In the absence of a
> rigorous method it's hard to find peace at the end of the task because so
> many less-than optimal solutions will work quite well. How's a person to
> determine what's best?
> >
> > Allison
> >
> >
>
>
Received on Thu Oct 05 2000 - 15:31:28 BST