Please see my remarks embedded in the quoted post below: Dick ----- Original Message ----- From: Fred Cisin (XenoSoft) <cisin(a)xenosoft.com> To: <classiccmp(a)classiccmp.org> Sent: Saturday, October 07, 2000 10:45 AM Subject: Re: CP/M BIOS setup 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. 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. I'm not certain this one needs any attention. If there's nothing there, it doesn't need to be read. 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. 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. I'm not chasing the same rabbit as you, here, so I don't know where a format name comes in. 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. half-a-worm is not a pleasant thing to work with. 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.