Yes, that part of the task is quite clear. However, if you have an ACB4070
with, say, a 60 MB drive attached to its other side with some very specific
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 layout
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
code (DEBLOCK.ASM) will handle the selection of the right 128-byte block
easily enough.
Barry Watzman was kind enough to root through his BDOS listings to assure me
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,
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.
Dick
-----Original Message-----
From: Allison J Parent <allisonp_at_world.std.com>
To: Discussion re-collecting of classic computers
<classiccmp_at_u.washington.edu>
Date: Saturday, November 27, 1999 9:40 PM
Subject: Re: CP/M-80 drivers for WD33C93 ???
>
><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
>
Received on Sat Nov 27 1999 - 23:37:56 GMT