Controller/driver combo... will it work?

Eric Varsanyi ewv at violet.berkeley.edu
Fri Mar 11 12:51:12 AEST 1988


In article <713 at spdcc.COM> dyer at spdcc.COM (Steve Dyer) writes:
>In article <257 at bby-bc.UUCP>, john at bby-bc.UUCP (john) writes:
>> I don't understand the problem here (I'm not disputing the correctness
>> of your claim re microport).  It can't be *that* hard to make the system
>> work with 26 sectors/track instead of 17.
>
>SCO XENIX v2.2 and above supports RLL controllers quite well.  SCO's disk driver
>reads in the disk geometry (including sectors/track) from a sector on the
>front of the disk, and configures itself appropriately.  It need not rely on
>the BIOS tables.  There is no technical reason why Microport cannot do the
>same; like many such problems, it is a marketing and support issue which they
>will have to address one day.

You CAN rely on the BIOS tables for this info with some controllers. DTC's
RLL controller writes a magic sector to cyl0 trk0 (64 byte sector, some
off the wall ID) with drive info. During bootstrap the DTC BIOS reads this
mini sector and creates a correct 'BIOS' drive table entry in the RAM on
its board, then it points the appropriate disk table vector (x104 or x108 
or somesuch) at this new freshly contructed entry. The CMOS gets set up as
drive type 1, but the disk sector has the real info.

This scheme works with V386 fine, although it is only used during installation.
The installation process formats the disk and blows away the 'special' sector,
however, at this point it doesn't matter since a VTOC has been created with
all the disk info in it. The VTOC is the final authority (the driver first
goes to the BIOS table, then to the VTOC). The only danger here is if you
re-install the system, you have to run DTC low level diags to put the
special sector back on the disk or you end up with whatever drive type
1 in your BIOS table points to (some wimpy drive).

The number 17 is magic to the driver, I happen to know it *cannot* possibly
work properly with any number of sectors (smaller or larger) then 17. This
is due to the size of a local track cache and a few other dependencies.
I have reason to believe that uport may soon be supporting other numbers
of sectors/track in the (reasonably) near future. This will allow use of
ESDI and RLL (and any other MFM style interface) controllers with a number
of sectors per track other than 17.

----------------------------------------------------------------------------
Eric Varsanyi                                        ewv at violet.berkeley.edu
                                                     !ucbvax!violet!ewv
   Any opinions expressed are mine and are not necessarily those of Cray
----------------------------------------------------------------------------



More information about the Comp.unix.microport mailing list