Well, it seems everybody keyed on the same, unfortunately wrong, end of the problem I'm trying to address. Yes, it's true that there are countless utilities to allow using foreign formats by phantoming or whatever, but those basically wanted the user to assign a format and then try to use it. What I'm after is a utility that examines a boot diskette, which, by definition contains the OS' 3 constituents, the CCP, the BDOS, and the BIOS, among other things, and, by comparing the portion that would ostensibly contain the BDOS with an internal copy of the BDOS, find and map out in sequence those sectors containing the BDOS, and deducing from that the sector skew between tracks, the sector interleave within a track, and then loading the OS into the TPA to examine the BIOS to get whatever information it has to offer. Allison suggests that the disk parameters are obscure and hard to locate, but CORTESI's book on CP/M, among others, provides a bit of software that quickly and reliably extracts any disk-related parameters one would need BIOS, it's unlikely one would be unable to do that just as automatically itself. It's quite well-defined where everything is to be found. In those cases, among which one finds the CCS example, wherein a simple, "dumb" BIOS is loaded into a 20-K CP/M requiring a 32K memory in which to run, and subseqeuently used to run a "smarter" and more fully developed version of the BIOS together with the OS loaded into whatever memory it finds available thereby making a 64K(actually 61K) CP/M quite attainable, one would have to examine the autocommand that's loaded in the "dumb" system in order to find the image that's going to contain the "real McCoy" with the full-featured BIOS from which the parameters relating to the directory and data areas of the diskette can be extracted. This strategy is particularly important in those rare cases where one has actually done what the CCS folks recommend and format the first two tracks of an 8" diskette single-density and the remainder at double density. Likewise, the remainder of the diskette can be two-sided. The reason THEIR loader doesn't handle the DD formats in their "dumb" BIOS is that it is written in 8080 code rather than Z80, but their double-density handler uses Z80 code to move the data. It even does something wierd with that, i.e. loading an opcode as data in a buffer so it can later be modified to accomplish a complementary operation to what it normally does. The "other" approach they recommend is rewriting the BOOT code in the EPROM and the loader in Z80 code. but one must also be able to extract what's needed from a non-bootable diskette, since one might just want to read data from a diskette used in a system that can only boot DD. I know of several such systems so it's not unheard-of. If a known file of more than 8K length is used as a target, one can use that file to extract the same information from the diskette, at least as far as sector skew between tracks, sector interleave within a track, and the BIOS-related disk parameters are concerned. What puzzles me is that, if this information is so readily available, why hasn't the entire process been automated already? I know there are lots of folks who hack away at these problems, but most of the time, they quit when their immediate problem is solved. What I'm trying to find out is whether there might be an easy, or at least rigorous, way to characterize and ultimately program this task. As I wrote earlier, even the authors who've written about this tend to equivocate somewhat about exactly how some things should be done. There is always a bit of a guess as to whether 4K or 8K allocation blocks should be used when hooking up a hard disk. That's not an issue with floppies, however. Generally, when one's trying to read what's on a diskette, it's necessary to know little more than how big the floppy is, allowing the computer to figure out what the modulation, data rate, and associated formats and track layout are. The computer can tell whether it's two-sided, simply by looking to see whether it can read data from both heads. It can tell whether the diskette is written in FM or MFM by attempting to read it. It can tell how long a sector is by reading one and looking at it, and it can deduce the track to track sector skew by doing a track-read and looking at the order of the sector numbers on each successive track until the pattern repeats itself. It can also tell how large an allocation bock is by examining directory entries. I've embedded a couple of context-sensitive remarks in the quoted post below, if you'd like to read them. Dick ----- Original Message ----- From: ajp166 <ajp166(a)bellatlantic.net> To: <classiccmp(a)classiccmp.org> Sent: Thursday, October 05, 2000 6:13 PM Subject: Re: CP/M BIOS setup be about True enough, but it's compatible with a front-panel and the software's written for an 8080 so you can use their FDC with an 8080 or 8085 as well as a Z80. Moreover, it's rock-solid. The fact that it uses a nearly vanilla-flavored CP/M doesn't detract either. I've run into absolutely no CP/M programs that won't run on it, while there are numerous utilities that won't work properly on the more modern MPM-targeted boards I got from Systems Group. What you refer to as skew is what I call the interleave, while a sector skew is a difference in sector numbering from idex, used by some systems (mostly early DEC actually, but some truly random-access systems as well) to minimize delays imposed by rotational latency during track-to adjacent-track seeks. I'm aware that sector numbering varies from one system to another. That's exactly why I think an automatic tool to construct the system parameters and install them in a dummy drive parameter block to It's difficult to pass it parameters you don't already know. If you don't know them, you've got to do some work and that's what I'm trying to automate. skew, If it's not the stuff from DRI, it's not relevant, since it's not CP/M. I'll admit that's a weakness, but for now, I'm happy to deal with CP/M only. AFAIK, DRI didn't issue any patches to v2.2. There were several enhanced systems patterned after and purported to be compatible with CP/M 2.2, but for now, I'm wanting to deal with the plain-vanilla CP/M. That's true, BUT, when you have a two-stage boot, you can examine the second layer boot system, and, in fact, have to in order to avoid getting tangled up in discrepancies between the boot tracks and the directory and data area. bios data variable In fact, I don't believe they have to be "figured out" at all. After all the diskette is in the drive. You just have to look at it. hard more that. IDE All I've seen of Multidisk is about half a dozen different formats, used by a dozen or more different system vendors. Maybe there were later versions, but since it required I know what its variables are, and I want to determine what they are by an autmatic process, I figure it's solving a different problem. True enough, but however the data gets there, we always know where it is, and, by virtue of where, what it is as well. they for just optimal. what reliable. It does get much more messy when you try to squeeze speed out of the system in ways the ultra-slow CPU doesn't let you appreciate, but when I said optimal, I meant for the technology of the time, which meant, at least to me, getting the most hard disk space to fit into the parameters the system would allow, without overly restricting either effective space utilization or directory space. That seems to have been the key tradeoff of the time ... allocation block size versus number of directory entries. One other factor was swtiching heads rather than moving the head stack. The heads take at least 3 ms to move from track to track, plus 8 ms on the average, to rotate half a rev, while switching heads took about 40-50 microseconds on the early Seagate ST506's. The trick, to me, was always finding a way to computer head, cylinder and sector from the CP/M sector number you were given by the BDOS without having to swallow up half a KByte in lookup tables.