larry@focsys.UUCP (Larry Williamson) (07/26/88)
This is a review of my experience with the Bell Tech Unix.
Our system configuration is as follows:
Intel 386 16Mhz Motherboard comes with
512K memory on board
1 serial port
1 parellel port
2 Meg memory on the 32 bit bus
60 Meg Priam drive
1 RA2 Western Digital RLL controller card
8 port smart serial card (Intellicon-8)
1 dumb serial port (8250 based)
1 BLIT express graphics processor
1 Monochrome display adapter (system console)
1 monochrome monitor (console)
1 Sony multisync monitor
Bell Tech's Unix with X10.4
This is a summary of some of my experiences over the past 4-6 weeks that
I've been working with this system.
First let me say that I am comparing this to Microport's 286 based system
V/AT. This 286 system I've been using since last November.
What BTU does not have:
. no nroff/troff
. no man pages
. no doscp, dosdir, etc
. no virtual consoles (you get this in X10.4, but that is not the same)
. no ksh
. no fortran (not that i'd use it if it were there :-)
although you do get the fortran libraries (3F)
. no kermit (C-Kermit (4D 061) ported pretty easy, only a few
syntax errors to clear up)
. no cmos ram update commands (ie. setup in uport)
if you want to modify the realtime clock or other
cmos ram parameters, you must write your own program. It's not very
difficult. The first thing I did after installing the system was to
write just such a tool.)
. no key remapping functions (ie. keyset, setkey in uport)
cannot modify the keycodes for the function/cursor keys. If you like
emacs, you will not be able to use the cursor keys.
. So far our Everex Streamer (QIC36 interface card, long card) does not
work. The tape driver is 'just a little different'. I don't know yet
for sure if it is a bt problem
Weaknesses:
. floppy access is SLOW. cpio & tar are 3-4 times slower than uport/286
. system seems slow in some ways
. always swapping
. lots of disk access
. I have 2.5 meg memory 60 Meg disk
. does not support RLL
. Oh yea, they say that they support RLL, but it's a farce. I've got the
industry standard Western Digital RA2 controller board that BT says
they support. I've got the Intel 386 16Mhz mother board that BT says
they support. This is the SAME combination that BT ships if you buy
their hardware! Unix does not recoginize that there are 26 sectors/track
on the disk. I'm stuck with 17. BT says I need a special rom that will
define a drive type that has 26 sectors per track. I should by this from
intel, they say. Intel says, "a what? never heard of it!".
Other problems
. documentation is backordered (>6weeks so far)
. they will give you a credit on the manuals if you can buy
them locally, but the credit is a lot less that what the manuals
will actually cost you.
. These manuals are essentially the same AT&T Unix SystemV/386 manuals
printed by Prentice Hall. BT has some additional detail added to the
manuals.
. They are not the usual loose leaf, 3 ring binder in a box type manuals.
. You cannot leave a manual open on the desk at your reference page. It
will flip shut on you.
Positives
---------
What you do get.
. an interesting online help system. (good if you have some new unix users
at your site)
. X10.4 (not quite as nice as X11, but a good start)
. Full BNU system. I had no idea how much easier uucp could be to manage
using BNU. (this is basically Honey DanBer uucp).
Other items.
. So far, everything that i've ported from our uport 286 system to this
system has ported easily. usually just a recompile.
. any commands that i've brought from the 286 system has run without
a recompile. Very nice if you've bought something and can't recompile it.
. Our favourite smart serial card works like a charm in this machine
(the Intellicon-8 from Connect Tech)
. the onboard serial port and a dumb 8250 based serial port both work with
the default serial drivers. This seeems to be a trouble spot for some.
. Sales support and Tech support have so far been very good. Sales support
is a shining example (but of course they want more of our money!) Tech
support is good too, even though my biggest tech problem has been trying
to get my industry standard Western Digital RA2 RLL controller to work
with this system.
Other items:
. With 2.5Meg ram, this system is SLOW. It runs any given program nice
and fast, compress, cc, whatever. But there is not enough ram for the
system and a few other processes, so it is always swapping something.
To be fair, I must admit that I am running X-windows all the time, and
X is BIG.
If I leave emacs running in one window, and switch to another window to
do a make or test my application, then there is a lot of disk activity
even before I get a prompt in the next window.
I would suggest that BTU + X-Windows REQUIRES at least 4 Meg memory.
Disk utilization is quite high. The 60Meg disk is nearly full (about
80% in / and 70% in /usr). This is with the entire distribution
including the 10 floppies of X-windows stuff.
The documentation that comes with X is minimal. It is no way to learn how
to use X. I ordered the X-windows manuals from O'Reilly & Assoc. These are
great. Unfortunately, these manuals are for X11, not the X10 you get from BT.
(BT, if you are listening. I hear you are thinking about shipping X11. If
this is true, get the O'Reilly manuals and ship them with your system!!)
At $60.00 for the pair, these manuals are expensive. But they are very
thorough, about two and a half inches in total thickness (makes you feel
you are getting something for your money).
We bought the BLIT express card with the system. We needed a display
system that would display 256 level (64 for now is enough) grey scale.
The ads for the BLIT card implied that it would do this.
It does not. It can not.
The very best it can do with out any additional hardware is 4 grey
levels. Actually it can only display 64 colours with the current
hardware and software configuration. The blit card puts out 2 bits of
video for each of the red, green and blue channels. Therefore, you get
only 4 levels of each of these colours.
Our application is a network of a number of unix machines each with
a high res grey scale display. We are displaying grey scale images from
a central high capacity archive. We require a minimum of 64 levels of grey
and would like to claim 256 levels (even if this is beyond human eye
perception).
RLL support and grey scale support are both essential to the viability of
our application. I suspect that the blit express will not do the job for
us. Too bad because it does look very good.
Larry
--
Larry Williamson Focus Automation Systems
UUCP: watmath!focsys!larry 608 Weber St. N, Waterloo, Ontario N2V 1K4
+1 519 746 4918dar@belltec.UUCP (Dimitri Rotow) (07/30/88)
In article <195@focsys.UUCP>, larry@focsys.UUCP (Larry Williamson) writes: > > This is a review of my experience with the Bell Tech Unix. > [Larry writes a balanced review where a few points need updates ...] > . no cmos ram update commands (ie. setup in uport) > if you want to modify the realtime clock or other > cmos ram parameters, you must write your own program. It's not very ***** Well, not really ... most of us PC jocks just use the "SETUP" program every PC on earth comes with, either on floppy or in ROM. > . So far our Everex Streamer (QIC36 interface card, long card) does not > work. The tape driver is 'just a little different'. I don't know yet > for sure if it is a bt problem ***** You're right ... We don't sell a driver for Everex's product: that's why it doesn't work. > . floppy access is SLOW. cpio & tar are 3-4 times slower than uport/286 ***** Man are you right! We dump on Intel and AT&T about three times a week on this one. It's *much* faster in Release 3.1 and Release 3.2, thank God. > . system seems slow in some ways > . always swapping > . lots of disk access > . I have 2.5 meg memory 60 Meg disk That's because you have too little RAM. Remember, X (together with all of the networking extras, like RFS) takes RAM. That you *can* run the system in as little as 2MB doesn't mean it is sensible to do so. > . does not support RLL > . Oh yea, they say that they support RLL, but it's a farce. I've got the ... > on the disk. I'm stuck with 17. BT says I need a special rom that will > define a drive type that has 26 sectors per track. I should by this from > intel, they say. Intel says, "a what? never heard of it!". Larry, surely you know that virtually the entire PC AT world lives and dies by the contents of the disk table in the BIOS ROM. For three years now disk drive support for DOS and a host of other operating systems has expected an accurate list of disk drives in the BIOS ROM ... it's a way of life in the AT world. Yes, I know that it's neat to have an O/S that doesn't care about the contents of the ROM (within limits), but part of the value of buying the *right* clone is getting a well rounded disk drive table in the BIOS. Lots of clones these days have RLL and ESDI type sectors per track in their BIOS ROMS. > > Other problems > . documentation is backordered (>6weeks so far) ***** You're right. The Prentice Hall volume sales people are impossible to deal with. We reprinted the System Administration Guide and the Sys Adm Reference, and they are always in stock, but for the rest of the stuff we have gotten held up (for up to *7* weeks at a time) from PH. For Release 3.2 we're reprinting the whole set and keeping a few thousand on hand at any given time. > I would suggest that BTU + X-Windows REQUIRES at least 4 Meg memory. ***** Me too. It runs like a bat out of h*ll in 4MB, and probably would do just fine with 3MB to 3.5MB. There are people who run in 2.5MB and say they like it just fine, but I don't know how they do it. > The documentation that comes with X is minimal. It is no way to learn how > to use X. I ordered the X-windows manuals from O'Reilly & Assoc. These are > great. Unfortunately, these manuals are for X11, not the X10 you get from BT. > (BT, if you are listening. I hear you are thinking about shipping X11. If > this is true, get the O'Reilly manuals and ship them with your system!!) ***** I wouldn't say it is "minimal:" we provide a complete reprint of the MIT X Window documentation. This documentation was not intended to be used as an X tutorial, although we do provide a very thin tutorial introduction to X. The O'Reilly stuff is great and we do refer a lot of people to it. We won't be shipping it with the 11 distribution because a lot of people already have it, and we don't want to force anybody to buy it who doesn't need it. > > We bought the BLIT express card with the system. We needed a display > system that would display 256 level (64 for now is enough) grey scale. > The ads for the BLIT card implied that it would do this. ****** Larry, I've just read all of our ads three times and it says nothing about 256 level grey scale. In fact, the words "grey scale" don't even appear in any of our literature or advertising. Believe me, given the recent net traffic on our ads, we *really* scrutinize everything we publish for possible misinterpretations. The ads say the Blit does 1660 x 1200 in monochrome and 640 x 480 x 8 in color. It really does bring out all eight bits from the 82786. The limitation to 6 bits is an artifact of usinig Multi Sync monitors, which can only accept two bits per gun. There are more expensive monitors and interfaces available which can utilize all 8 bits, which some of our customers are using. We'd be glad to show you how, but I suspect what you want is 1660 x 1200 in 256 levels of grey scale which we cannot do. For more than one bit we can only do 640 x 480. You might want to consider the new Univision card: we support the Univision card and the Microfield card in our X Window distribution bundled with UNIX System V Release 3.1. Despite the comments, thank you for your (mostly) positive review! - Dimitri Rotow
james@bigtex.uucp (James Van Artsdalen) (08/01/88)
In article <250@belltec.UUCP>, dar@belltec.UUCP (Dimitri Rotow) wrote: > Larry, surely you know that virtually the entire PC AT world lives and > dies by the contents of the disk table in the BIOS ROM. Everything except MS-DOS, which cares not a whit what's in ROM. > For three > years now disk drive support for DOS and a host of other operating > systems has expected an accurate list of disk drives in the BIOS ROM Except for MS-DOS, which doesn't care what's in ROM. > ... it's a way of life in the AT world. Yes, I know that it's neat to > have an O/S that doesn't care about the contents of the ROM (within > limits), Such as MS-DOS, which doesn't care what's in ROM (anyone notice a pattern?) > but part of the value of buying the *right* clone is getting > a well rounded disk drive table in the BIOS. Lots of clones these > days have RLL and ESDI type sectors per track in their BIOS ROMS. I don't mean to flame Bell Technologies, because Microport and SCO also appear to have this same problem, along with Novell and who knows what else. I've never been able to determine what lead all of them to do things wrong - IBM's AT technical reference manual clearly shows that using the ROM is the wrong way to do things. The INT 41h and INT 46h vectors (addresses 0:0104 and 0:0118) point to BIOS Disk Parameter Tables. These tables define the geometry of the drive. These tables do not necessarily reside in ROM, and in fact often do NOT do so with modern disk controllers. The correct way for unix to boot and configured its drivers is to have the boot sector copy the two table entries to a safe place (since loading unix may overwrite them). These values should then be used by the boot sector to read the kernel loader, and should be used initialize the hard disk driver. At no point is there ever any cause to directly read the ROM for disk geometry! In particular, there IS NO CAUSE to to pay attention to the drive type number - that number is considered a private BIOS value whose ONLY use is to build the Disk Parameter Tables. Many modern disk controllers are designed to overcome deficiencies in the BIOS ROM tables. Western Digital, OMTI and Adaptec have several controllers that do this. They correctly build accurate Disk Parameter Tables in RAM at POST time. BIOS and DOS then proceed to use these values. Were the various unix vendors to (1) use the Disk Parameter Table values instead of digging in ROM and (2) to allow enough table space inside the driver (what a novel thought - dynamically allocate the track buffer based on the geometry of the drive instead of using a statically allocated array!), we wouldn't have the situation now where DOS can easily use the latest ESDI, RLL and SCSI technology, while unix almost seems to be stuck with the old 17 sec/trk drives... -- James R. Van Artsdalen ...!ut-sally!utastro!bigtex!james "Live Free or Die" Home: 512-346-2444 Work: 328-0282; 110 Wild Basin Rd. Ste #230, Austin TX 78746
karl@ddsw1.UUCP (Karl Denninger) (08/02/88)
In article <250@belltec.UUCP> dar@belltec.UUCP (Dimitri Rotow) writes: >... >> on the disk. I'm stuck with 17. BT says I need a special rom that will >> define a drive type that has 26 sectors per track. I should by this from >> intel, they say. Intel says, "a what? never heard of it!". > >Larry, surely you know that virtually the entire PC AT world lives and dies by >the contents of the disk table in the BIOS ROM. For three years now disk >drive support for DOS and a host of other operating systems has expected an >accurate list of disk drives in the BIOS ROM ... it's a way of life in the AT >world. Yes, I know that it's neat to have an O/S that doesn't care about the >contents of the ROM (within limits), but part of the value of buying the >*right* clone is getting a well rounded disk drive table in the BIOS. Lots >of clones these days have RLL and ESDI type sectors per track in their BIOS >ROMS. Me thinks you are incorrect. First, *most* clones and Real Blue IBM Machines DO NOT have entries for RLL drives. This is because everyone and their brother does it a little differently. Some use 25 sectors per track, Adaptec uses 26, and I have also seen 27. Having ROM entries for all possibilities would exhaust the ROMs storage capacity -- and STILL be far too limited. There are new drives (and controllers) being introduced all the time. Should we have to update our ROMs every time another drive or controller hits the market? Of course not! Better machines DO know about ESDI drives -- but I've yet to run into a "mainstream" clone with RLL drives in the ROM tables. (There undoubtably are some, but none that I have seen). Even in these cases, the ESDI support I've seen does not cover the range of drives available -- you STILL need to be able to override drive types even in these machines. MSDOS uses (and always has) the (correct) BIOS calls to get disk geometry. The *ONLY* time anything should interrogate CMOS directly for drive types is on the initial POST-initiated boot sequence (ie: no code in the machine yet; this comes from the boot loader in ROM). If you're doing a direct interrogation of the CMOS, you're doing it wrong. The POST builds a disk parameter block -- which can be (and is) intercepted by controllers like the Adaptec. If you get your parameters from this RAM-based location, it is ALWAYS RIGHT providing your controller is reasonably intelligent. This is why MSDOS can run on an XT, where it still needs to know disk geometry but has not a byte of CMOS ram anywhere in the system..... SCO Xenix, MSDOS, and many others are well versed in the proper way to access disk parameters. It is *NOT* done by going through the BIOS ROM tables. These were specifically designed to be overridden if necessary. In fact, the only correct purpose of the disk type tables in ROM is to allow the system to find the boot sector on the fixed disk! Are you telling the world at large that your OS cannot deal with a drive that is not in the ROM tables? I would find that limitation immediately disqualifying for your version of UNIX (tm) -- our needs are too diverse to live with such a limitation. Of course, it does make a very good case for purchasing your hardware, doesn't it? Don't blame the hardware for what is an obvious software flaw. Fix the geometry read routine.... -- Karl Denninger (ddsw1!karl) Data: (312) 566-8912, Voice: (312) 566-8910 Macro Computer Solutions, Inc. "Quality solutions at a fair price"
mike@cimcor.mn.org (Michael Grenier) (08/02/88)
From article <5076@bigtex.uucp>, by james@bigtex.uucp (James Van Artsdalen): > I don't mean to flame Bell Technologies, because Microport and SCO > also appear to have this same problem, along with Novell and who knows > what else. I've never been able to determine what lead all of them to > do things wrong - IBM's AT technical reference manual clearly shows > that using the ROM is the wrong way to do things. Perhaps I'm confused. Microport doesn not have this problem as their UNIX drivers read information on the disk that contains the disk geometry. During install (actually during format of the hard drive) you can go into a menu that allows you to configured the number of heads, tracks, etc. independent of the ROM (or RAM table) settings. This was a very nice feature giving my Maxtor drive an extra 10 or more megabytes of standard ROM type 9. Now if Microport would only support more than 1024 tracks and RLL on their 286 product....Oh Well, I can wait. They have a good product. -Mike Grenier mike@cimcor.mn.org {rutgers, amdahl}!bungia!cimcor!mike
larry@focsys.UUCP (Larry Williamson) (08/02/88)
In article <250@belltec.UUCP> dar@belltec.UUCP (Dimitri Rotow) writes: >In article <195@focsys.UUCP>, larry@focsys.UUCP (Larry Williamson) writes: >> >> This is a review of my experience with the Bell Tech Unix. >> >[Larry writes a balanced review where a few points need updates ...] > >> . no cmos ram update commands (ie. setup in uport) >> if you want to modify the realtime clock or other >> cmos ram parameters, you must write your own program. It's not very >***** Well, not really ... most of us PC jocks just use the "SETUP" program >every PC on earth comes with, either on floppy or in ROM. But I want to do it from unix, I'd rather not boot dos if I don't have to. It's a small complaint. I don't really mind, personally. But it is something that I had gotten used to on the uport 286 product. > >> . So far our Everex Streamer (QIC36 interface card, long card) does not >> work. The tape driver is 'just a little different'. I don't know yet >> for sure if it is a bt problem >***** You're right ... >We don't sell a driver for Everex's product: that's why it doesn't >work. We spent some time getting a tape drive that would work with our Microport software. Much of the problems were our fault. We finally settled on this Everex drive. Before we bought the BTUnix, I asked our marketing contact at BT if the QIC36 tape driver (I'm pretty sure I mentioned it was an everex drive) would work. "I think so. The tech sheet I have here says that our software works with these tape drives" Now I have a tape drive that I can use to backup our uport systems, but I can't backup our BT systems (except on a VERY slow floppy drive). We even went to the trouble to by an external tape drive so that we would be able to use it on all our unix systems and the dos systems in house. Just by an extra interface card for every system, and move the tape drive around. Dimitri, Is there a special interface card that I can buy from you that will work with this external everex Excel60 tape drive? I want to buy one. Please tell Renee if there is, I will talk to here and order one. > >> . does not support RLL >> on the disk. I'm stuck with 17. BT says I need a special rom that will >> define a drive type that has 26 sectors per track. I should by this from >> intel, they say. Intel says, "a what? never heard of it!". > >Larry, surely you know that virtually the entire PC AT world lives and dies by > [...] >contents of the ROM (within limits), but part of the value of buying the >*right* clone is getting a well rounded disk drive table in the BIOS. Lots Our system uses the Intel motherboard! This is the SAME motherboard that is in the system you sell! The difference is that you ask intel to replace this rom with a special one. Unfortunately, I can't convince the Intel people here that there is such a rom and I want one. All I want is one of these roms. Your Tech support people have told me that they will not sell me one. Intel says they don't know what on earth I'm talking about. Please, give me a name and a phone number so that I can get one. We would liked to have bought your computer. We did not because we felt that if we had any hardware problems, it would be easier to get the system fixed by the local distributor rather than shipping it back and forth across the border. The border between our countries is quite open, it is still a hassle. Since your system uses the Intel mother board, I made a point of getting a system that used the Intel mother board too. I figured I would have no compatiblity problems this way. We won't buy through your canadian distributor because their markup is out of this world. >> >> We bought the BLIT express card with the system. We needed a display >> system that would display 256 level (64 for now is enough) grey scale. >> The ads for the BLIT card implied that it would do this. >****** Larry, I've just read all of our ads three times and it says nothing >about 256 level grey scale. In fact, the words "grey scale" don't even >appear in any of our literature or advertising. Believe me, given the Yes you are right. I attributed to your ads, converstations I had with your marketing people. It was when we were deciding to buy your system that I asked some questions about grey scale. The person I was asking could not answer me for sure, but said that it seemed likely that the board would support many levels of grey. I went out on a limb and decided to get the board. Princeton makes a monitor, the PCM-03 that from their ad looks like it might help me out here. I've got to get hold of them to know for sure. >Despite the comments, thank you for your (mostly) positive review! > >- Dimitri Rotow You're welcome. We are mostly happy with the product. Probably the only complaint that I have that I should point at BT for is the RLL support. The product that we are developing will not be bothered by any of the complaints that I've leveled here. We will use what ever backup system is available, and it will be an internal unit. The RLL support will not be a big issue either. The problem is mostly the development environment. We are developing quite a large system. We NEED more that 60 Meg of hard disk. Even now it is about 80% full and I still want to install an nroff package. I think I'm going to have to install a second hard disk. Our company is small. I cannot just go and buy another tape drive for every system we bring in the door. I want to be able to use the same one on all our systems. Larry -- Larry Williamson Focus Automation Systems Inc. uucp: watmath!focsys!larry (519) 576-8558 (519) 746-4918
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (08/03/88)
| I don't mean to flame Bell Technologies, because Microport and SCO | also appear to have this same problem, along with Novell and who knows | what else. I've never been able to determine what lead all of them to | do things wrong - IBM's AT technical reference manual clearly shows | that using the ROM is the wrong way to do things. A person reading this could assume that UNIX for the AT clone doesn't do this. That person could also assume that you don't know it does this... Xenix, at least, allows you to set the HD params as part of installation, and works just fine with anything the controller will handle. You just enter the # sectore, heads, and tracks. I believe that V/386 has this as well, since a friend runs some bizarre disk for a 2nd drive, but I don't know if they support this or he hacked it in. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
karl@ficc.UUCP (karl lehenbauer#) (08/03/88)
I bought the Bell Tech QIC-36 tape controller for use with my 386/AT and its Everex Excel Stream 60 external tape drive, because using the Everex one (that Microport's 286 stuff worked with) resulted in an "Invalid controller or firmware" message at startup time and, more to the point, wouldn't work. Anyway, I visually compared the two boards and was suprised to find them to be absolutely identical, including switch settings, except that the "Bell Tech" board had a Bell Tech label on its EPROM and the one I bought from Everex (for a good deal less money, I might add) had an Everex label. I may have a look at their contents, just for yucks. There had better be some substantial differences, not just a couple magic characters like "BT" in the last two bytes, or it might be construed to validate another vendor's remarks asserting that BT intentionally incompatibilized their Unix to sell more hardware and that, even though the drivers were used in the system running the validation suite, they were running with a tricked-up board when an ordinary one would have been better. -- -- +1 713 274 5184, karl@sugar.uu.net (uunet!sugar!karl) -- Ferranti International Controls, 12808 W. Airport Blvd., Sugar Land, TX 77478
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (08/04/88)
In article <161@focsys.UUCP> larry@focsys.UUCP (Larry Williamson) writes: | We spent some time getting a tape drive that would work with our | Microport software. Much of the problems were our fault. We finally | settled on this Everex drive. Before we bought the BTUnix, I asked | our marketing contact at BT if the QIC36 tape driver (I'm pretty | sure I mentioned it was an everex drive) would work. "I think so. The | tech sheet I have here says that our software works with these tape | drives" | | Now I have a tape drive that I can use to backup our uport systems, | but I can't backup our BT systems (except on a VERY slow floppy drive). | | We even went to the trouble to by an external tape drive so that we | would be able to use it on all our unix systems and the dos systems | in house. Just by an extra interface card for every system, and move | the tape drive around. I bought a tape external tape drive and several controllers, for xenix/286, and 386. It seems that BT modifies the controller to keep their software from being used with other controllers (so I was told). They supply a set of software to use the tape, which works fine, if a bit slowly. Now when I want to run on Xenix/386, I can't use the BT drivers because the shell scripts I have use the standard Xenix drivers and commands (why supply a whole new set of commands for a system which has its own?). I can't use the Xenix drivers because the controller (it may actually be the drive) won't work. No one will steal the BT tape software, but I won't be quick to buy another BT product. The usefulness of an external drive is pretty well lost on this. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
zeeff@b-tech.UUCP (Jon Zeeff) (08/04/88)
In article <1198@ficc.UUCP> karl@ficc.UUCP (karl lehenbauer#) writes: >I bought the Bell Tech QIC-36 tape controller for use with my 386/AT and its >Everex Excel Stream 60 external tape drive, because using the Everex one >Anyway, I visually compared the two boards and was suprised to find them to be >absolutely identical, including switch settings, except that the "Bell Tech" >board had a Bell Tech label on its EPROM and the one I bought from Everex >(for a good deal less money, I might add) had an Everex label. I may have a If the differences are minor, you might as well post them so we can all get out our prom burners and fix things. -- Jon Zeeff Branch Technology, uunet!umix!b-tech!zeeff zeeff%b-tech.uucp@umix.cc.umich.edu
stacy@mcl.UUCP (Stacy L. Millions) (08/08/88)
In article <5076@bigtex.uucp>, james@bigtex.uucp (James Van Artsdalen) writes: > ... > I don't mean to flame Bell Technologies, because Microport and SCO > also appear to have this same problem, along with Novell and who knows But SCO does not have this problem (2.2 and up). > ... > Many modern disk controllers are designed to overcome deficiencies in > the BIOS ROM tables. Western Digital, OMTI and Adaptec have several > controllers that do this. They correctly build accurate Disk I have used the Adaptec ESDI and RLL with SCO Xenix, they work great. I have also installed several hard disk into SCO sytems and never set the drive type to any thing other than 1. At installation time you can override the default drive parameters and they will be written to a safe place and used at boot time. Note: the only RLL istallations I have done have been with the adaptec controllers, so if this information does not work with other RLL controllers you have my sincerest apologies. - stacy -- "He to whom the early bird runs best learns wisdom and patience! ... I can never remember proverbs" - Charlie Brown S. L. Millions ..!uunet!mcl!stacy