Thanks, Eric, for pointing out what I feared everybody had missed.
Allison, what I have tried to put as clearly as I know how, is that the
objective is to read THIS diskette. I'm not trying to replicate the BIOS or
its functions, beyond the simple task of getting the data from THIS
diskette. While it's true, one might want to write diskettes of a format
compatible with a foreign system, that's not what I want to do.
Let me explain:
I have, in the past few years, discarded literally THOUSANDS of diskettes
from the "old days" because, (A) needed the space they occupied, (B) they
were not in the best of shape, (C) I had MANY more diskettes than I figured
I'd ever need, (D) I figured I already had several other copies of what was
on them, or the content was not of interest (e.g. someone else's mailing
list, accounts history backups, etc) and (E) I no longer had the controller
needed to read those specific diskettes, and didn't want to attempt to get
another.
I still (ask WIll Jennings . . . he's seen "the pit") have LOTS of
diskettes, of which most are written on controllers I no longer have, nor
want. Many of the diskettes I retained were copies of materials downloaded
from various RCPM sites in the early '80's, from the BDS CUG, and other
organizations whose work product was worthy of note, and a bunch of other
such materials. It's possible I might want some of that data at some time
in the future, since I have LOTS of blank 8" media, and probably won't be
using that material just for the media. It might be nice to be able to move
the data from the gradually deteriorating media where it now lives to a
somewhat more secure location on a hard disk. THAT's why I am stirring this
bed of coals.
My hope was that enough information would bubble to the surface in kicking
this subject around, that I could find or <cringe> write my own code to
process some of these diskettes, not clearly marked as to their
controller-of-origin. While some are clearly marked as to their content,
the format remains a mystery. My Systems Group machine won't read them.
Does that make my objective clear enough?
I'm not trying to automate out of existence the "black-art" of creating a
floppy disk BIOS for CP/M, since there are already enough of them out there,
all different because nobody seems to have gone beyond just "getting it to
work, sorta ..."
OTOH, I WOULD like to see an automatic procedure for generating the
parameters for a hard disk of a given configuration, striking a resonable
balance between efficient use of capacity and directory space. I've only
done this a time or two, otherwise having used information provided by
others, but have concluded that it's possible to do that automatically given
the geometry of the drive. The only issue is integrating the deblocking
code seamlesly so it can handle both floppy and fixed disks sharing the same
memory buffer. That introduces plent of opportunity for errors.
Dick
----- Original Message -----
From: ajp166 <ajp166_at_bellatlantic.net>
To: <classiccmp_at_classiccmp.org>
Sent: Saturday, October 07, 2000 3:42 PM
Subject: Re: CP/M BIOS setup
> From: Eric Smith <eric_at_brouhaha.com>
>
> >He's not proposing to figure out the parameters by looking at tables in
> >the BDOS. As you correctly point out, that stuff is in the BIOS.
>
>
> True the BIOS is the repository of the disk information but it's not all
> as I've repeatedly said in the "tables". It can be deeply embedded
> in the code.
>
> >Richard's point is that on a bootable disk, some set of sectors contain
> >the BDOS code, which has known contents (for any specific DRI CP/M
> release).
> >The point is that some of the disk parameters can be worked out by
> matching
> >what sectors on the media contain what pieces of the BDOS code.
>
>
> Sorry but the BDOS is usually in reserved tracks where things like skew
> (aka intereave) is not always there or even the same density.
>
> The BDOS other than being a known block of code contains none
> of the disk specific code or layout. Putting that in the bios is what
> made cpm portable to different platforms.
>
> >It may not tell you everything about the disk format, and it obviously
> >only works on bootable diskettes, but I think it is a good start.
>
>
> It's only a start. to me as an bystander to this it's a interesting
> exercize but one fraught with exceptions and limiations for it to
> work reliabily.
>
> Allison
>
>
Received on Sat Oct 07 2000 - 18:01:33 BST