<It would be interesting to see SOMETHING for the 33C93, but what puzzles m <more than anything else is the question of how to cook up a quick and dirt <translation from the CP/M drive/track/sector specification to a logical <block structure as is used on SCSI/SASI devices. CP/M 2.2 is so much nice This is real easy, first remember you going to be limited to 8mb unless you used something like P2DOS or ZRdos. With that said and done... This means there will be 65536 sectors to a logical disk (CP/M-80 V2). SPT set that to some handy number like 64, that means tracks will be expressed as 64 sector chunks. That means there has to be 1024 tracks. This will be the bios passed numbers for track and sector. Of course thats logical sectors (128bytes) this will have to be grouped 2 or 4 per physical sector (256 or 512bytes). Deblocking will be done locally on the host and all reads and writes will be at the disk physical level. Offset (reserved tracks) is sized as logical tracks (what ever sector amount has been set up) of course there is more work but those are the clues. By using binary sizes for sectors, them math to concatenate tracks and sectors into "blocks" is a matter of a few right or left shifts. <if you have a maximal TPA which won't happen if one's using table lookups <and stuff in place of computations to determine which block contains what <the OS is in sector ss of track tt on drive x. You see, if this is <implemented on a bridge controller which talks SCSI to the system, but whos <drives are ST-506 interfaced, there are good ways and bad ways to allocate <blocks. It's simple enough to do one layer, but if you have to deal with <two, how you do one will have substantial impact on how the other works out This is hard to follow but the bios does not have to be large and the real space grabber is the ALLOC vector. If the system has banking even a 4k or 16k bank in low memory can easily swallow the various host buffers and Allocation storage which can be large. Allison