It's true, I do believe that it's possible to create a procedure which will
rigorously extract the data necessary in order to define uniquely whatever
format is used on a pure CP/M 2.2 bootable soft-sectored diskette including
sector interleave and track-to-track skew. I do not assert that such a task
will be "easy" to implement in software, but, once done, like any other task
you don't have to do yourself, it will, indeed, be easy, as the computer
will ostensibly do all the work.
It will be necessary that the standard DRI-original BDOS distributed with
the original OS be used and that certain standard-distribution utilities,
e.g. PIP or maybe ASM or even MOVCPM be located on the diskette as a file
named in the standard way with a standard directory entry describing it. My
assertion that all the information with which to accomplish that is
contained on the diskette, and, since the computer has to be able to find it
there, another computer should be just as able to find that same
information. It's true, some FDC's can read but not reproduce the writing
of another. For that reason, I'll not claim that ANY FDC is capable of
this.
I didn't say it would be easy to create the software with which this would
be accomplished, but I do believe it possible, and, since the computer would
be doing the actual extraction of that information over a period of seconds,
minutes, hours, or years, it would, ultimately, be as easy as any other task
done by someone else. I'm not dead certain that I can do this, but I am
quite certain that if it can be done on most diskettes, there probably
exists at least one sort of CP/M boot diskette with which the process will
fail.
However, I do believe that it's possible to devise a methodology by which
the information used by CP/M to describe the layout of data on its diskettes
can be extracted from a CP/M boot disk automatically and recorded in a way
that will allow another system to use that data to reproduce compatible
media, and to read and correctly interpret the data on that diskette,
provided that all the information and code used to accomplish that task are
contained on the boot diskette as opposed to elsewhere in the system, e.g.
in ROM or other storage medium for which no conventional provision is made
by the DRI CP/M 2.2 OS.
I don't believe that this will be difficult, though I do belive it will be
dreary and tedious. I don't consider "staying in the chair" at a task hard
work, either, though that, too, is often dreary and tedious. My interest is
mainly in 8" FD's since they're the medium of choice for CP/M distribution,
though the later-popular 5-1/4" diskettes are not totally uninteresting in
this regard. I'd easily accept that, once one has a reasonably dependable
method for 8" diskettes, it's not a long reach to make it work for the
mini-floppies. The latter, however, known for their quirks and foibles. At
least a few system vendors allowed their designers to put parts of the CP/M
BIOS in EPROM, hence making an approach such as I propose impractical since
all the "pieces" would then not be available on the boot diskette.
This is not a high-priority item for me, but I am frequently asked about
matters relating to this, and believe that after 20 years of doing the job
by hand and wits, it might be possible if not beneficial, to do this.
Dick
----- Original Message -----
From: Fred Cisin (XenoSoft) <cisin_at_xenosoft.com>
To: <classiccmp_at_classiccmp.org>
Sent: Friday, October 06, 2000 10:15 PM
Subject: Re: CP/M BIOS setup
> Richard thinks that the process of analyzing disk formats can be
> automated.
>
> Allison and I say that it isn't quite that simple, and that possession of
> a program is not enough to EASILY analyze what data structures the program
> uses.
>
> I am NOT saying that it is impossible - it is definitely possible. But I
> am saying that the task of automating it would be significant. I have
> manually analyzed quite a few more formats than most people have:
> http://www.xenosoft.com/fmts.html
>
> I would LOVE to be proven wrong, and have somebody create an automatic
> format analysis that works. Therefore, Dick, since you have some time
> while you reboot [sorry, couldn't resist], may I suggest that you go ahead
> and write the code to do it, and prove us wrong. It would be an
> impressive accomplishment, worthy of admiration.
>
> --
> 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 - 03:09:48 BST