Please see my remarks embedded in the quoted post below:
Dick
----- Original Message -----
From: Fred Cisin (XenoSoft) <cisin_at_xenosoft.com>
To: <classiccmp_at_classiccmp.org>
Sent: Saturday, October 07, 2000 10:45 AM
Subject: Re: CP/M BIOS setup
> Earlier in this thread, Richard proposed gathering ALL the information
> form a bootable diskette by examining the BDOS. Unfortunately, that is
That's not what I meant at all. I said it has to be bootable using the
standard DRI BDOS not because I'd USE the BDOS to locate features, but
rather because the DRI BDOS for plain-vanilla CP/M 2.2 is a fixed block of
code that's long enough that I can compare it with a reference copy of that
code in order to determine which sector contains the next bit of code. That
will give me the sector interleave, skew, and track layout used on THAT
diskette's boot tracks. I then would want a reasonably long file, also
standard and also long enough to use for finding out the same information
about the directory/data regions of the diskette. At the point at which
I've located every successive 128-byte segment of, say, PIP or ASM, on the
data area, I should have enough information about THAT diskette to interpret
its directory, which, ostensibly, will lie in the area beyond the boot
tracks.
I leave the door open to examine the contents of the BIOS, simply because
the BDOS finds information there in order to return it via utilities such as
those written by several authors to demonstrate how monolithic the standard
CP/M interface to the hardware is. I said plain-vanilla versions of CP/M
because it's not reasonable to be able to skin all the cats with the first
knife that becomes available.
Naturally, it's necessary to rule out systems that carry significant
portions of their hardware-software interface in EPROM. What I'm after is a
way to read THIS (motioning to the one in the drive) diskette, making no
assumptions about any others. Subsequently, it might be interesting to try
to read other diskettes native to a given system just to see whether they
are similar to the boot diskette. Many systems have two different types,
arising simply from usage, i.e. one suitable for booting, and one suitable
for use as data diskettes. The latter type is completely unsupported by the
method I propose to explore.
However, the same avenue I propose to use on a bootable diskette can be
applied, though at a later stage, to a data diskette. Once one has a copy
of the boot diskette that has, by virtue of the limitations I've stated, the
complete BIOS on it as well as the portions necessary to to ascertain the
track and sector layout, the BIOS can be examined for whatever information
it contains that will help it to communicate with both the system hardware
and the BDOS. Since that data MUST be present on a bootable diskette, I'm
operating under the assumption (possibly a weak one, but the only available
assumption, AFAIK) that if it's there for the BDOS to use, it is there. It
doesn't have to be used on a system running the code. It merely needs to be
in locations known by virtue of the standard implementation.
I doubt that it will be likely one can derive the disk parameters from a
diskette without the presence of known files, just to allow confirmation
that the files are arranged as one expects. There have to be standard known
files present because one otherwise can't reach any conclusions about the
data region of the diskette.
> not quite feasible, since too much is done in the BIOS. To his credit, he
> NOW says that the disk must have a substantial file or two, such as PIP,
> ASM, or MOVCPM. That is correct.
>
I believe I pointed out the need for substantial (in length) files such as
PIP, that are easily recognizable by comparison, in my initial mention of
this proposal.
>
> Let's look at what is needed/desirable/useful for analyzing a disk format.
> Please bear with me for not always using DRIs terminology - there are a
> lot of alternate names for the same things.
>
> If there is access to a functioning machine, then the output of
> STAT DSK:
> provides a lot of what is needed.
>
> PHYSICAL FORMAT:
> Bytes per sector: physical read of diskette. Watch out for differences in
> format between reserved tracks v data area
> Sectors per track: physical read. Watch out for disk formats that include
> unused sectors (9 formatted sectors per track with 8 used!)
> Sides: physical read. Watch out for diskettes that have both sides
> formatted, but are only using one.
>
> Watch out for diskettes with 40 or 80 formatted tracks that use 35 or 77!
>
I'm not certain this one needs any attention. If there's nothing there, it
doesn't need to be read.
>
> Watch out for a few WEIRD systems that reformat sectors as they use them!
>
That's a new one on me! . . . I wonder why anyone would do that unless it's
part of a copy-protections scheme or maybe an error scrubbing scheme. After
all, reformatting isn't easy unless it's done a track at a time. I
personally have never managed it.
>
> Watch out for aftermarket mods, such as alternate BIOSes - the diskette
> that you receive for a given machine might not always be representative of
> that machine.
>
Since we're out only to read THIS (pointing to the one in the drive)
diskette, what the system does with other diskettes isn't of much interest
for now.
>
> Watch out for SPELLING! I once added in a format that I thought was
> spelled GROUPIL. By the time that I found out that I had misread sloppy
> handwriting, 4 competing programs had copied the "GROUPIL" format! There
> exists an INW format. But some LNW formats are misidentified in some
> programs as INW.
>
I'm not chasing the same rabbit as you, here, so I don't know where a format
name comes in.
>
> Number of reserved tracks: Look at sectors until you find something that
> LOOKS like a directory. That could be automated.
>
> Side pattern: (up side 0, down side 1/up 0 up 1/alternating/ etc)
> if not alternating, requires a disk that is over half full! In THEORY, it
> might be determinable through exhaustive study of the BIOS and BDOS. In
> reality, find a disk over half full.
>
> Records per block: although theoretically determinable from exhaustive
> study of BIOS and BDOS, the way to determine it is to look at the
> directory entry for a file larger than one block.
>
> Bytes/bits used for block number: look at directory entry for file
> larger than one block.
>
> Number of blocks represented in each directory entry: in the case of 8
> records per block, look at directory entry for a file larger than 8
> blocks.
>
> Interleave: need a file larger than a full track that is EITHER a known
> file (PIP, ASM, MOVCPM are good), OR one that is understandable (text
I don't go this far, since my propsed method requires only files the content
of which is known EXACTLY. OTOH, this method can be made to work with human
intervention. I'm looking for a way to exclude human intervention. I
believe that if the computer for which a diskette is intended can deduce how
to read a diskette based solely on information contained on the diskette,
then another computer can figure it out as well, given the proper decision
tree on which to base its choices. If the diskette doesn't contain all the
information, i.e. if some is in EPROM, or in some other way excluded from
the diskette itself, then it's likely all bets are off. There are things
one can resonably deduce from one's knowledge about the OS, but other than
that, the human operator should not come into play.
> file, or machine language of a processor/mnemonics of which you are
> familiar. If there is even a little text scattered in a file, you can
> "look for 1/2 a worm" by finding the beginning of a word at the end of a
> sector and the beginning at the beginning of another sector.
>
half-a-worm is not a pleasant thing to work with.
>
> With Richard's latest change to require a known file on the diskette, it
> is becoming more feasible. But you don't always get that! I always
> explain in detail what I need, and the critical importance of identifying
> the disk ("By the time that it arrives, I will have talked to a lot of
> other people, and forgotten the details, so please be SURE to label the
> disk with what format it is!") Then, when the disk arrives, it is
> unlabelled, with a note that says nothing but: "Here's the disk we talked
> about". It usually has no files on it, or one file of less than 100
> bytes. Sometimes it will have 4 copies of that file. Maybe there will
> be a printout of STAT (not STAT DSK:) from a different diskette.
>
I went back and looked at my first posts regarding this subject. I'm not
sure what you mean by change. The mention of a file, e.g. PIP, chosen
because it was pretty common to copy PIP to a diskette before copying
anything else to it, and because it is so commonly found on CP/M diskettes
in general, was certainly there. It's necessary to have a known file
because otherwise you have no information to help you discern what the
layout of the data area of the diskette is.
Now, I'm not for splitting hairs about the statements made, since my
objective is to find a rigorous method for reading foreign diskettes in a
CP/M system, based on informaton of which we all have SOME, but which I
believe is "in-there" someplace if one simply takes time to contemplate the
problem.
My fundamental assertion is that if one computer can find all the
information necessary to read a diskette on that diskette, then another one
can do so too. I don't see a shortage of information on the diskette, but
rather, I see something more on the order of a set of ten equations in eight
variables. The equations are not necessarily in conflict, but which ones
one chooses greatly will effect the ease with which a solution can be
reached.
>
> --
> Fred Cisin cisin_at_xenosoft.com
> XenoSoft http://www.xenosoft.com
> PO Box 1236 (510) 558-9366
> Berkeley, CA 94701-1236
>
>
>
Received on Sat Oct 07 2000 - 16:36:15 BST