Path: utzoo!mnetor!uunet!husc6!cmcl2!nrl-cmf!ames!pasteur!agate!violet.berkeley.edu!ewv From: ewv@violet.berkeley.edu (Eric Varsanyi) Newsgroups: comp.unix.microport Subject: Re: Controller/driver combo... will it work? Message-ID: <7584@agate.BERKELEY.EDU> Date: 11 Mar 88 02:51:12 GMT References: <3575@killer.UUCP> <4144@ihlpl.ATT.COM> <257@bby-bc.UUCP> <713@spdcc.COM> Sender: usenet@agate.BERKELEY.EDU Reply-To: ewv@violet.berkeley.edu.UUCP (Eric Varsanyi) Organization: Cray Research, Inc. Lines: 43 Keywords: Microport In article <713@spdcc.COM> dyer@spdcc.COM (Steve Dyer) writes: >In article <257@bby-bc.UUCP>, john@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@violet.berkeley.edu !ucbvax!violet!ewv Any opinions expressed are mine and are not necessarily those of Cray ----------------------------------------------------------------------------