<Yes, that part of the task is quite clear. However, if you have an ACB407 <with, say, a 60 MB drive attached to its other side with some very specifi Ok thats a EDSI controller. The key question is do you talk to the bridge board in blocks or CHS? Most SCSI disks (like my RZ22s are blocks) and the drive logic dows things to make that into CHS for it's internal use. <number of cylinders, heads, and sectors, there's yet another task to handle <It would really be slick to figure out some combination of partitioning, <simple arithmetic, and some form of sleight of hand, to map the sector <number and track number you get from the BDOS into the physical drive layou <directly, then derive a parameter for the benefit of the SCSI side of the <controller to munch while fetching the appropriate block. The DR-supplied For current SCSI and IDE I just map SPT at something binary and that set tracks to a number I can easily work with. Since TRACK and SECTOR are both 16bit values (or can be) this makes it pretty easy. Watch out for track (one head) and cylinder (n many heads). For something like the old Xybec bridge you working with raw CHS so something like 16 physical (64 logical) sectors per track (what it formatted to on a ST225) and 4 heads can be sent to the bdos as 256spt (4h*16sectors*4logicalsectors per physcial block). That means there will be 615 tracks. Very straightforward. This gets a bit messy if there are say 17spt (512byte sectors) but then if there are 4 heads that makes 68 physical sectors times 4 (128 byte logical sectors) or 272 sectors per track... awkward but manageable (note the sector value is 9bits so the bios will ahve to capture the full 16 bits passed in DE from the BDOS). Myself unless I'm working with floppies I give the bios table (disk prarmeter block) numbers like 256spt and say 2047 blocks (8mb logical disk with 4k allocation size). That means the concatination of TRACK and SECTOR passed to the bios will be a pure binary number of the logical sector (0-65535) the BDOS wants. I can then in the BIOS translate that to what ever mapping I need. Generally for SCSI disks I add some number of blocks to that to get the track offest for partitioning or system tracks. <code (DEBLOCK.ASM) will handle the selection of the right 128-byte block <easily enough. You can do better than DEBLOCK. If you have space caching larger that physical blocks give a real performance boost. <Barry Watzman was kind enough to root through his BDOS listings to assure m <that while the sample BIOS's in every case use only a byte for the sector <number and track number, those are developed to 16-bits and passed as such <in and from the BDOS and to the BIOS. This means one has to make no <concessions to CP/M about contiguous block numbering. It gets ugly, though Barry's examples are practice VS what the BDOS actually does. The BDOS passes 16 bit values for both track and sector. If the SPT happens to be set to less that 257 then you can be assured the BIOS will recieve a 16 bit sector with the upper byte of 00. Why not take advantage of the BDOS doing this work? For all the BDOS cares SPT can be 1 or 65535! all it does is crank out a different "track" value for those cases. Hint in the past I've use 4 spt! that means the sector number is an index into a physical block for a 512byte sector (for deblocking). Track has the relative block (0-16384) for me to crack into physical head, sector, track. Or in the case of most SCSI disks the actual block I want from the drive. The one thing that is hard limit is there will be 65536 sectors MAXIMUM to a logical disk under cpm 2.2. If you have P2DOS, ZRdos, Novados, CPM3 those all increase by a minimum of 4 to 32mb and can be as large as 1gb for logical disks (if you can live with a allocation size of 32k and have the alloc table space). <if you want to fit those nice, neat numbers into a scheme supporting 7 <heads, 1117 cylinders, and 26 sectors of 512 bytes into it. It will not fit as that is a 1Gb disk! Reality is the BDOS (V2.2) can only deal with a 8mb partition of that (some 128 partitions would be needed and CPM is never going to do all of them <limit of 16>). Also while some of the CPM clones will address a disk this large the granularity is really bad as they want to use 32k allocation blocks. It can be done but you going to have to create a "different" bios that will allow ony of the 16 logical drive to be assigned to any physical drive (or a partition on one). I've done this enough times to know what the book says, what people have done (not all good either!) and what the BDOS really does (read the code!). What the BDOS sends back is reflective of the Disk Parameter Block and those numbers do not have to have any relationship to the physical device other than some consistancy on total device size. Keep in mind the BDOS has no concept of heads (you have to deal with that in the bios) and could care less about the geometry of the disk as that is something the bios writer has to decide. There are few hard rules for the CPM bios and a great deal of flexibility if you care to take advantage. Allison