4 Oct
2000
4 Oct
'00
2:54 p.m.
From: Richard Erlacher <richard(a)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
5 Oct
5 Oct
2:54 a.m.
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
----- Original Message -----
From: ajp166 <ajp166(a)bellatlantic.net>
To: <classiccmp(a)classiccmp.org>
Sent: Wednesday, October 04, 2000 8:54 PM
Subject: Re: CP/M BIOS setup
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?
From: Richard Erlacher <richard(a)idcomm.com>
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.
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
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.
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.
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.
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.
Allison
8:31 a.m.
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(a)bellatlantic.net>
To: <classiccmp(a)classiccmp.org>
Sent: Wednesday, October 04, 2000 8:54 PM
Subject: Re: CP/M BIOS setup
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?
From: Richard Erlacher
<richard(a)idcomm.com>
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.
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
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.
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.
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.
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.
Allison
9:22 a.m.
On the SWP ATR8000/ATR8500 there is a program called "Diskdef II" that has
80 or more disk formats you can select from. The only limitation is it
will not format these, only read/write. It will read a peice of paper.
Lists everything from Amp?? to Zorba.
v/r
jeff
--
-----------------------------------------------------------
Jeffrey S. Worley
President
Complete Computer Services, Inc.
30 Greenwood Rd.
Asheville, NC 28803
828-277-5959
THETechnoid(a)home.com
-----------------------------------------------------------
12:03 p.m.
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.
Format selection assistance is not new.
Howard Fulmer of Morrow was attempting to add that in to the multiple
format capability of the Morrow machines.
XenoCopy-PC has/had an undocumented capability: in the format selection
menu, it could be asked to look at the alien disk. It would then
"gray-out" physically different formats. Specifically, it would look at
number of sides, bytes per sector, and sectors per track. It remained
undocumented because it was OFTEN unacceptably wrong. There were a
surprisingly large number of diskettes that were FORMATTED both sides but
only used one side, or had more formatted sectors than were used! (8
sectors per track, but 9 sectors per track formatted!)
There are a number of other parameters that are not feasable (although not
necessarily impossible) to automatically sense, including side-PATTERN,
skew/interleave, number of reserved tracks, records per block, etc.
There were also a few problems with unreasonable expectations - there were
a few customers who expected the format selection assistance to render
possible formats that were otherwise physically impossible for the PC
hardware to do. There were even some folk who were ADAMENT that Apple ][
diskettes could be read by the PC, since they were the same diameter and
turned at 300RPM, and that therefore we were part of some sort of
CONSPIRACY to prevent the conversion.
--
Fred Cisin cisin(a)xenosoft.com
XenoSoft http://www.xenosoft.com
PO Box 1236 (510) 558-9366
Berkeley, CA 94701-1236
8844
days inactive
8845
days old
5 comments
6 participants
participants (6)
-
ajp166＠bellatlantic.net -
cisin＠xenosoft.com -
donm＠cts.com -
richard＠idcomm.com -
rigdonj＠intellistar.net -
THETechnoid＠home.com