Actually, the ACB4070 is a SCSI<=>RLL bridge. It operates in a way which
translates what is on the disk to cyl/hd/sector. However, it talks to the
host in SCSI. In any case, I've seen implementations (back when they were
all over the place) which worked very well, and I've seen others which
worked very poorly. Insofar as the bridge controllers were the same, I have
to assume that it was because of the BIOS code. I should have informed
myself about that back then, but it didn't seem important enough.
Take a look at additional comments below, plz.
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: Sunday, November 28, 1999 10:45 AM
Subject: Re: CP/M-80 drivers for WD33C93 ???
><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 does things to make that into CHS for it's internal use.
Many ESDI drives work on a logical block basis just like the SCSI's. They
have in many cases, in fact, dedicated processors on the drive logic to
handle the individual tasks. I've got some old Miniscribe 9380's on which I
can put either an ESDI or a SCSI logic board. If you compare the two
boards, they seem to have most of the same logic. Only the host interface
is different. There's a dedicated MPU to run the head carriage, one to
manage the raw data flow into the drive-resident buffer memory, one to
handle correction/detection of errors, (in the case of the SCSI only) and
one to shuffle the data between the host and drive. The thing that makes
SCSI outperform ESDI in most cases is that the SCSI leaves the host adapter
alone except when it's transferring corrected data. The ESDI relies on the
controller to handle all the correction, etc. In an environment, e.g. DEC's
MSCP, where there are enough smarts to utilize command queueing and
overlapped seeks, etc, SCSI outperforms the fastest ESDI by quite a little
bit. I participated in a MicroVax implementation using two ESDI drives from
Maxtor for a JPL-run Army/Air Force project. When Maxtor released their
SCSI drive equivalent to the very famous 4380E, which they called the 3380,
we took out the Emulex ESDI controller and replaced it with someone's SCSI
adapter, half the size of the ESDI one, perhaps it was from Emulex as well,
and put in two of the 3380's where the 4380's had been, and got WAY better
() performance. The adapter cost less than half what the ESDI one cost, the
3380 drives were $1k lower in price, at $3375, while the 4380's cost, (get
this!) $4380. It wasn't a tough choice. The JPL guys didn't like the
report I had written about the performance gain which went along with the
price cut. I was fired (briefly) from the project, and the switch to SCSI
was made a few months later.
><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).
It seems that if the BDOS is willing to call out both the track and the
sector numbers in a range from 0..FFFFH, that means you only need to specify
one sector per track if all you want is a logical block (physical sector)
number. You then right-shift to scale for the physical sector size and then
let the deblocking code wade through undoing that. FFFFH sectors is the 8MB
max allowable capacity, is it not? The bridge controller translates from
logical block numbers to cyl/hd/sec in some way they don't choose to tell us
mere mortals.
OTOH, using the BDOS to do more of the work, sorta, you can map tracks into
logical blocks, and use the sector number to point into the logical block at
the appropriate 128-byte portion. What I'd like to know is what works best.
It's particularly important that this be small, since it's for CP/M 2.2.
>
>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 have 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.
What do you find this does to your directory allocation scheme? I've never
quite figured out how to optimize the block size so you don't either run out
of directory entries or disk space far too soon.
><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.
Yes, this is what I meant, above.
>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).
Actually, it's a 99.25 MB disk. It's a miniscribe 3085 used with RLL.
Since I have one of these lying about, and since the 4070 is an RLL bridge,
I thought I'd use those numbers.
>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
>
Received on Sun Nov 28 1999 - 13:42:16 GMT