[comp.unix.microport] Controller/driver combo... will it work?

ajohnson@killer.UUCP (Andy Johnson) (03/05/88)

I received an Omti 8627 controller and am using it on a Miniscribe
3650 40 meg hard drive in a "unknown clone" 286 AT (with Phoenix
Bios).

What's nifty neat about this is that with the OMTI RLL controller, I
can effectively get 60 megs out of my 40 meg drive.

I have this working just find under MS - DOS.  

When the drive is configured, you tell the bios that there are 0
hard drives installed.  It works. Just fine.

My question is:  will this work under Mport unix?

I know that "Northgate" has been selling this same combo for a while
on their "AT".  Has anyone had any experience with this?

Either leave mail or post answers here.

Andy Johnson
-------------------------
{inhp4!codas}!killer!ajohnson

james@bigtex.uucp (James Van Artsdalen) (03/07/88)

In article <3575@killer.UUCP>, ajohnson@killer.UUCP (Andy Johnson) writes:
> When the drive is configured, you tell the bios that there are 0
> hard drives installed.  It works. Just fine.

That's because DOS uses the BIOS disk parameter table, like you're supposed
to.  uPort uses the drive type number, like you're *NOT* supposed to do.
Since the OMTI builds the correct disk parameter table during
POST/initialization but can't change the ROM, nothing that uses the drive type
number is going to work.

> My question is:  will this work under Mport unix?

No.  uPort thinks there's no drive present, and I've been unable to convince
it otherwise.

> I know that "Northgate" has been selling this same combo for a while
> on their "AT".  Has anyone had any experience with this?

Yes.  Good DOS controller.  SCO has Xenix at least booting under the OMTI,
but I've heard reports of truly abysmal throughput (ie, much slower than
ordinary ST-506).

Once you get past the simply drive type problem, you next have to deal with
the fact that apparently the uPort drivers can't work with any with anything
but 17 sectors/track.  Say goodbye to all of your high capacity disks...

When I asked uPort, I was told that they were working on the OMTI, and even
got the address of the contractor, but never followed up on it.
-- 
James R. Van Artsdalen    ...!uunet!utastro!bigtex!james     "Live Free or Die"
Home: 512-346-2444 Work: 328-0282; 110 Wild Basin Rd. Ste #230, Austin TX 78746

johnk@ihlpl.ATT.COM (John Kennedy) (03/08/88)

In article <3575@killer.UUCP>, ajohnson@killer.UUCP (Andy Johnson) writes:
> I received an Omti 8627 controller and am using it on a Miniscribe
> 3650 40 meg hard drive in a "unknown clone" 286 AT (with Phoenix
> Bios).
> 
> What's nifty neat about this is that with the OMTI RLL controller, I
> can effectively get 60 megs out of my 40 meg drive.
> 
> My question is:  will this work under Mport unix?

Nope. I learned it the hard way, and ended up having to return an
RLL drive and controller.  Microport said they don't support RLL and don't
have any plans to in the near future.  The drivers count on the
hard disk having 17 sectors per cylinder, and the RLL concept uses
26 per.



-- 

john@bby-bc.UUCP (john) (03/09/88)

> > What's nifty neat about this is that with the OMTI RLL controller, I
> > can effectively get 60 megs out of my 40 meg drive.
> > 
> > My question is:  will this work under Mport unix?
> 
> Nope. I learned it the hard way, and ended up having to return an
> RLL drive and controller.  Microport said they don't support RLL and don't
> have any plans to in the near future.  The drivers count on the
> hard disk having 17 sectors per cylinder, and the RLL concept uses
> 26 per.

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.  My understanding of the RLL
and ERLL controllers is that from the software's view of the hardware
they are basically identical to the normal (mfm?) AT controller (aside
from being able to accept larger sector numbers in the appropriate
register).  If this is wrong can someone explain it?  If it's right
then how hard could it be for microport to make an RLL supporting
kernel available?

If microport doesn't plan to do something about it it is very dissapointing.
It raises the price of a system considerably - I need to double the disk
storage on my system (from 105 -> 210 mb) to really be able to work
comfortably. If RLL/ERLL was supported I could do so for an additional
$200-$400 but as it stands now I will have to spend more like $1200 to
achieve the same end.  As far as I'm concerned this basically raises the
price of Microport unix by another $800 or so (up to SCO levels but they
also seem to support a much wider variety of peripherals).

dyer@spdcc.COM (Steve Dyer) (03/10/88)

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.

sl@van-bc.UUCP (pri=-10 Stuart Lynne) (03/10/88)

In article <257@bby-bc.UUCP> john@bby-bc.UUCP (john) writes:
>> > My question is:  will this work under Mport unix?
>> 
>> Nope. I learned it the hard way, and ended up having to return an
>> RLL drive and controller.  Microport said they don't support RLL and don't
>> have any plans to in the near future.  The drivers count on the
>> hard disk having 17 sectors per cylinder, and the RLL concept uses
>> 26 per.
>
>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.  My understanding of the RLL
>and ERLL controllers is that from the software's view of the hardware

I'm told by the good people at Bell Tech that they *DO* support RLL
controllers with their (very inexpensive) version of System V/386.

Caveat: Your BIOS ROM's must have a suitable entry for the RLL drive. I.E.
it must say that there the proper number of heads/cylinders/sectors - in
this case 26 sectors. 

The cylinders may not be as important, the diskconfig script does have some
questions about the *actual* number of cylinders on the drive. My impression
is that you can use a ROM entry that has less cylinders specified and
have diskconfig compensate. But you must have the correct number of heads
and sectors in the ROM entry.

N.B. I have not tried this as we havn't got an RLL controller yet (still
waiting for the WD-1006 RA2).

Bell Tech uses this as a selling point, the drives they sell are rated for
RLL. So if you have an RLL controller and good ROM's this is a *very* cost
effective way to increase your storage.

Rumour also has that Interactive supports RLL as well, and I vaguely
remember something about SCO doing something with Xenix /386.


-- 
{ihnp4!alberta!ubc-vision,uunet}!van-bc!Stuart.Lynne Vancouver,BC,604-937-7532

ewv@violet.berkeley.edu (Eric Varsanyi) (03/11/88)

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
----------------------------------------------------------------------------

det@hawkmoon.MN.ORG (Derek E. Terveer) (03/12/88)

There has been a fair amount of discussion about adding different types of
drives to uPort systems lately, along with whether they will or will not work
with different controllers.  The term RLL has been bandied about a lot, but the
discussion is somewhat crepuscular to me since i don't know the basics about
RLL stuff.  Anyone care to indulge me?
-- 
Derek Terveer	det@hawkmoon.MN.ORG	uunet!rosevax!elric!hawkmoon!det

wes@wsccs.UUCP (Barnacle Wes) (03/23/88)

In article <119@hawkmoon.MN.ORG>, det@hawkmoon.MN.ORG (Derek E. Terveer) writes:
> The term RLL has been bandied about a lot, but the
> discussion is somewhat crepuscular to me since i don't know the basics about
> RLL stuff.  Anyone care to indulge me?

Yah, it's simple: RLL stands for Run-Length Limited.  It is a different way
of formatting and storing the bits on the disk surface (the "standard" way,
at least with ST506-type winchester disks, is Modified Frequency Modulation,
or MFM, which also stands for Mother F***ing Magic).  The gist of it is that
you can store more bits in the same space, usually resulting in approxi-
mately 27 sectors per track, rather than the "standard" 17 sectors/track.

	Wes Peters
-- 
    /\              - " Against Stupidity,  -    {backbones}!
   /\/\  .    /\    -  The Gods Themselves  -  utah-cs!utah-gr!
  /    \/ \/\/  \   -   Contend in Vain."   -  uplherc!sp7040!
 / U i n T e c h \  -        Schiller       -     obie!wes

chad@anasaz.UUCP (Chad R. Larson) (04/03/88)

In article <257@bby-bc.UUCP> john@bby-bc.UUCP (john) writes:
>> ...  Microport said they don't support RLL and don't
>> have any plans to in the near future.  The drivers count on the
>> hard disk having 17 sectors per cylinder, and the RLL concept uses
>> 26 per.

A company here in Phoenix makes an RLL controller that will work with
almost any hard disk (special plated media and all not required).
They hired me to do custom drivers for SysV/AT to allow their system
be used for a Unix (they had been shipping for DOS only).  The offer we
made to Microport was to generalize the disk drivers and boot code
so the number of sectors would be stored in the same manner as the
number of tracks & cylinders and write pre-comp information is,
and give Microport back the changes for no charge, just so we would
be "supported" by SysV/AT.  I tried to get the stuff I needed from
Microport (sources to boot code, etc.) and in spite of my signing
Microport's non-disclosure agreements and calling them many times
on the phone they never sent me anything (other than the non-
disclosure forms).  I lost the contract, so I assume Microport
is serious in not supporting alternative mass storage devices.
The client went with SCO Xenix (and I understand, sold a lot of them).
---------------
"I read the news today, oh boy!"  --John Lennon
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
| DCF, Inc.               | UUCP: ...noao!mcdsun!nud!anasaz!dcfinc!chad |
| 14623 North 49th Place  | Ma Bell: (602) 953-1392                     |
| Scottsdale, AZ 85254    | Loran: N-33deg37min20sec W-111deg58min26sec |
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
|         Disclaimer: These ARE the opinions of my employer!            |
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

sjb@dalek.UUCP (Seth J. Bradley) (04/04/88)

In article <820@anasaz.UUCP>, chad@anasaz.UUCP (Chad R. Larson) writes:
> >> ...  Microport said they don't support RLL and don't
> >> have any plans to in the near future.  The drivers count on the
> >> hard disk having 17 sectors per cylinder, and the RLL concept uses
> >> 26 per.
> 

When I spoke to my Microport salesperson(can't recall her name)
a few weeks ago, she said Microport would support RLL controllers
within three months.  If any Company people are reading this,
what is the true story on this issue?



-- 
Seth J. Bradley     UUCP: uunet!ubvax!dalek!sjb

jmsully@uport.UUCP (John M. Sully) (04/06/88)

We will have support for non-17 sector per track drives in the next release
of the 386 system.  No date on availability in the 286 system.

karl@ddsw1.UUCP (Karl Denninger) (04/06/88)

In article <327@uport.UUCP> jmsully@uport.UUCP (John M. Sully) writes:
>We will have support for non-17 sector per track drives in the next release
>of the 386 system.  No date on availability in the 286 system.

Details please.  

Are you intending to support only that which is in the user's BIOS in the
sec/track area, or will it be completely configurable (ala Xenix).

Also; there are several parameters which are not accessible on your HD
driver to the user.  Do you intend to move these into the 'modifyable' arena
as well? (ie: CCB option byte, etc).

Thirdly, will this next release fix the ungodly partitioning scheme your
system V/386 uses, so I can have peaceful coexistance with other operating
systems and partitions without pulling my hair out?

And can we have the 'sar' disk activity code put back in please, so 'sar'
can report on disk I/O activity (on the '286, the '386 I haven't checked)?

----
Karl Denninger                 |  Data: +1 312 566-8912
Macro Computer Solutions, Inc. | Voice: +1 312 566-8910
...ihnp4!ddsw1!karl            | "Quality solutions for work or play"

blair@obdient.UUCP (Doug Blair) (04/09/88)

> Thirdly, will this next release fix the ungodly partitioning scheme your
> system V/386 uses, so I can have peaceful coexistance with other operating
> systems and partitions without pulling my hair out?
> 
[FLAME ON, low burn only :-)]

Karl, I know you've had some problems with the '286 uport.  Let the
company recover from their mistake - I'm sure they intend to.  If you
want to know if they'll support other operating systems and other
partitions, just ask.  I have precious little hair and don't like the
thought on anyone losing theirs.

[FLAME OFF]

> And can we have the 'sar' disk activity code put back in please, so 'sar'
> can report on disk I/O activity (on the '286, the '386 I haven't checked)?
> 

Like the spagetti sauce, "it's in there" on the 386 version.

Doug

  ___   _             _   _               _ 
 /   \ | |           | | |_|            _| |_  Doug Blair_______312-653-5527
|  |  || |_   ___   _| |  _   ___   __ |_   _| Obedient Software Corporation
|  |  || ==\ / ==\ /== | | | / ==\ |  \  | |   1007 Naperville Road_________
 \___/ |___/ \___/ \___| |_| \___/ |_|_| |_|   Wheaton, Illinois 60187______

karl@ddsw1.UUCP (Karl Denninger) (04/11/88)

In article <490@obdient.UUCP> blair@obdient.UUCP (Doug Blair) writes:
>> Thirdly, will this next release fix the ungodly partitioning scheme your
>> system V/386 uses, so I can have peaceful coexistance with other operating
>> systems and partitions without pulling my hair out?
>> 
>[FLAME ON, low burn only :-)]
>Karl, I know you've had some problems with the '286 uport.  Let the
>company recover from their mistake - I'm sure they intend to.  If you
>want to know if they'll support other operating systems and other
>partitions, just ask.  I have precious little hair and don't like the
>thought on anyone losing theirs.
>[FLAME OFF]

Yep; I have their '386 version as well, and went through a 16 hour fight
to get a second disk installed with both DOS and Unix partitions.  It *can*
be done, but the work involved is rediculous (or requires tearing apart
their installation and redoing it).   When I tried installing on a
Telenix-386 the installation failed with a hard disk prepped at 1:1 interleave
(bad tracking did not work correctly; the system tried to write to defective
sectors!).  Reformatting w/Microports formatter gives me a working system
with 50% of it's potential disk performance (the "reformat" option formats
at 1:2 interleave on the Televideo... argh!)

All I'd like is to be able to create partitions in a way which is (1)
compatible or at least reasonable w/respect to DOS and other OSs, and (2)
have the system do what I ask.  This means formatting at 1:1 if I ask for
it, and doing the bad tracking properly *without* having to hand-edit the
parameter files.  Seems reasonable to me.

>> And can we have the 'sar' disk activity code put back in please, so 'sar'
>> can report on disk I/O activity (on the '286, the '386 I haven't checked)?
>> 
>Like the spagetti sauce, "it's in there" on the 386 version.

Great!  (As I said, haven't checked the 'sar' on the '386... although James
Van Artsdalen says its missing on the '386 version... so we have conflicting
reports!)

Please understand that we have worked with the SV/386 product to some
extent.  We simply don't have the time to fight problems like we encountered
with installation.  I can rip a drive out of our Xenix/386 system and be back 
in operation in under an hour.  The last time I tried this on Uport/386 it 
took a *lot* longer -- like 4-6 hours.  We gave up on splitting the second 
drive for both DOS and Unix after several aborted attempts.

SV/386 is FAR better than the '286 product in terms of reliability (I've
seen only one panic so far) but many installation and disaster-recovery issues 
remain unaddressed.  When you do heavy development on a system (as we do) you 
WILL have disasters, and you need to be able to reconfigure and even (in
some cases) reinstall easily.  Currently I cannot do this with SV/386.

(Remember, SV/286 could even *boot* dos from the 'Unix' boot prompt)

----
Karl Denninger                 |  Data: +1 312 566-8912
Macro Computer Solutions, Inc. | Voice: +1 312 566-8910
...ihnp4!ddsw1!karl            | "Quality solutions for work or play"

kjk@pbhyf.PacBell.COM (Ken Keirnan) (04/11/88)

In article <490@obdient.UUCP> blair@obdient.UUCP (Doug Blair) writes:
[ stuff deleted ]
>> And can we have the 'sar' disk activity code put back in please, so 'sar'
>> can report on disk I/O activity (on the '286, the '386 I haven't checked)?
>> 
>
>Like the spagetti sauce, "it's in there" on the 386 version.
>
>Doug

Well, Doug, I'm running System V/386 2.2U (this is, I believe, the latest
release) and typing "sar -d" yields an empty accounting report for me.  I
believe my system is doing the appropriate accounting data collection --
perhaps I'm missing an option somewhere.  Did disk accounting work for you
straight out of the wrapper?
-- 

Ken Keirnan -- Pacific Bell -- {ihnp4,sun,ames,pyramid}!pacbell!pbhyf!kjk
  San Ramon, California			kjk@pbhyf.PacBell.COM

pjh@mccc.UUCP (Peter J. Holsberg) (04/13/88)

Does anyone know if the DTC 5280 controller/Micropolis 85MB
(unformatted) drive will work with uport UNIX and DOSMerge?

-- 
Peter Holsberg                  UUCP: {rutgers!}princeton!mccc!pjh
Technology Division             CompuServe: 70240,334
Mercer College                  GEnie: PJHOLSBERG
Trenton, NJ 08690               Voice: 1-609-586-4800