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 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 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 &lt;ajp166(a)bellatlantic.net&gt; To: &lt;classiccmp(a)classiccmp.org&gt; Sent: Saturday, October 07, 2000 3:42 PM Subject: Re: CP/M BIOS setup