bill@carpet.WLK.COM (Bill Kennedy) (08/28/88)
I have been a frequent promoter of AT&T's 386 UNIX and a vociferous
criticizer of Microport's System V/386. I have been asked (that's
why this is so widely cross posted) several times whether or not the
AT&T product will run on a '386 AT clone, where to get it, how much
it costs.
I found it in the latest Elek-Tek catalog, several part numbers but
the most likely is order # 482109, Part # ATT1331003. That's unlimited
run time and Development (both!) for $695.50. That's a few dollars
more than Microport Development alone and quite a few dollars less than
the Microport equivalent.
Elek-Tek
6557 North Lincoln Avenue
Chicago, IL 60645-3986 (800) 621-1269, IL 312-982-5765, CN (800)458-9133
Major credit cards welcome.
I was also asked, numerous times, why I felt the product was superior to
Microport V/386. I'll not do a numbered list because that might look like
a flame and I'm through with that. The documentation is better. Microport's
documentation opens with an apology for the crummy appearance and says it's
because they got such poor quality masters from AT&T. Perhaps that's exactly
right, but I can read AT&T, Microport is as bad as what they apologize for.
AT&T is shipping Vr3.1 which means streams and things that will be available
Real Soon Now. Microport (to their credit) has virtual consoles, i.e. with
a flick of a keyboard button you're on a different console. That's missing
from what you get from AT&T.
That covers the cosmetics, why do I think that AT&T is better? Their
compiler compiles C-Tree (an incredibly portable package) and the binary
that comes out works. Microport compiles it but breaks when sscanf is
called. AT&T's compiler doesn't write code that the assembler can't assemble.
AT&T's uugetty doesn't get into debates with an intelligent modem who wants
to talk about answering the phone. AT&T's terminfo for the AT console doesn't
get lost when you're in vi. AT&T ships unlimited users standard, not extra
$$. AT&T's VP/ix (DOS box) works. AT&T supports big disk drives. AT&T is
fewer dollars for the same components.
I'd like to repeat that this is not intended as a slam on Microport. I am
delighted with their '286 product (this is being posted with it). When I
was flaming Microport for their '386 effort I got a lot of email asking why
I was such a big AT&T booster. I'm not, but I am encouraged about a product
that works. I got mine via a VAR connection that wasn't generally available,
now Elek-Tek has it in their catalog. Admittedly $695.50 isn't pocket money,
but it's a lot fewer $$ than several alternatives and a lot more stable a
product. Some promise/excuse, some ship.
--
Bill Kennedy Internet: bill@ssbn.WLK.COM
Usenet: { killer | att | rutgers | uunet!bigtex }!ssbn!billjohn@banzai.UUCP (John Canning) (08/29/88)
In article <145@carpet.WLK.COM> bill@carpet.WLK.COM (Bill Kennedy) writes: >...Microport (to their credit) has virtual consoles, i.e. with >a flick of a keyboard button you're on a different console. That's missing >from what you get from AT&T. With the AT&T port of Unix Vr3.1, you get a program named shl, which offers you virtual consoles (up to 8) on the main console, as well as on remote terminals. >...AT&T's compiler doesn't write code that the assembler can't assemble. It has been my experience that the AT&T compiler will generate code which results in a syntax error from the assembler. This situation usually crops up on certain bit-field operations which could be considered non-standard. However, the C-compiler does not report an error, nor does lint.... >AT&T's uugetty doesn't get into debates with an intelligent modem who wants >to talk about answering the phone. However, uugetty is not smart enough to program the modem when you first turn the system on. You must first call a bogus number before the modem will be set to answer. Bill also mentioned that the VP/ix from AT&T works. The one experience I had with it resulted in a big mess in the free list. I'd hate to see what Microport's version does. That's all.
mike@cimcor.mn.org (Michael Grenier) (08/29/88)
From article <171@banzai.UUCP>, by john@banzai.UUCP (John Canning): > Bill also mentioned that the VP/ix from AT&T works. The one experience I > had with it resulted in a big mess in the free list. I'd hate to see > what Microport's version does. For whatever its worth, Microport doesn't use VP/ix perferring instead DosMerge from Locus. I'ved used the beta release on the 386 and was very happy with it which did a reasonable job of DOS on dumb terminals. Everything we tried worked well except for the Multimate print spooler and I never really looked into it...I'm sure there was a work around. The DosMerge product on the 286 works quite well also. -Mike Grenier mike@cimcor.mn.org
cdold@starfish.Convergent.COM (Clarence Dold) (08/29/88)
From article <171@banzai.UUCP>, by john@banzai.UUCP (John Canning): > In article <145@carpet.WLK.COM> bill@carpet.WLK.COM (Bill Kennedy) writes: >>AT&T's uugetty doesn't get into debates with an intelligent modem who wants >>to talk about answering the phone. > > However, uugetty is not smart enough to program the modem when you > first turn the system on. You must first call a bogus number before > the modem will be set to answer. You could always run a little script from *rc: cu -t -l tty001<<Q ~!sleep 1 AT ~!sleep 1 ATAA ~!sleep 1 ~. Q But even that is unnecessary if you have DTR driven by the system, and leave the modem set for auto-answer. The modem I've used won't answer if DTR is low. DTR shouldn't go high until uugetty is started. That way, the modem doesn't answer if the system isn't up, but always answers if the system is up.
keith@uport.UUCP (Keith Hankin) (08/30/88)
In article <145@carpet.WLK.COM> bill@carpet.WLK.COM (Bill Kennedy) writes: >I have been a frequent promoter of AT&T's 386 UNIX and a vociferous >criticizer of Microport's System V/386. > >I was also asked, numerous times, why I felt the product was superior to >Microport V/386. I'll not do a numbered list because that might look like >a flame and I'm through with that. >AT&T is shipping Vr3.1 which means streams and things that will be available >Real Soon Now. Microport is shipping Streams now. > >That covers the cosmetics, why do I think that AT&T is better? Their >compiler compiles C-Tree (an incredibly portable package) and the binary >that comes out works. Microport compiles it but breaks when sscanf is >called. AT&T's compiler doesn't write code that the assembler can't assemble. Microport's C compiler is THE SAME COMPILER that you get from AT&T. Any problems with Microport's compiler should be the same with AT&T. Perhaps you got a very new version of the AT&T C compiler, one which we do not yet have to ship. >AT&T's uugetty doesn't get into debates with an intelligent modem who wants >to talk about answering the phone. Microport's uugetty is THE SAME as AT&T's uugetty. Perhaps you were trying the uugetty on a ttyM device rather than tty device. Microport has not added any special hooks into uugetty for the ttyM devices (just the standard AT&T code). >AT&T's terminfo for the AT console doesn't get lost when you're in vi. What problems have you been having with vi? It should be okay. There was a new terminfo posted on our BBS, which was incorrect. Are you using this, perhaps? >AT&T ships unlimited users standard, not extra. And their price includes the unlimited user fee. If we just had one version, it would be the price of the unlimited version, but instead we chose to have another version to save users who did not need the unlimited capabilities some money. The extra cost, by the way is royalties and reflects our licensing agreement with AT&T. >AT&T supports big disk drives. Microport Version 3.0, shipping in two weeks, will have RLL and ESDI support. >Bill Kennedy Internet: bill@ssbn.WLK.COM > Usenet: { killer | att | rutgers | uunet!bigtex }!ssbn!bill -- Keith Hankin keith@uport Microport Systems
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (08/30/88)
In article <441@uport.UUCP> keith@uport.UUCP (Keith Hankin) writes: | In article <145@carpet.WLK.COM> bill@carpet.WLK.COM (Bill Kennedy) writes: | >That covers the cosmetics, why do I think that AT&T is better? Their | >compiler compiles C-Tree (an incredibly portable package) and the binary | >that comes out works. Microport compiles it but breaks when sscanf is | >called. AT&T's compiler doesn't write code that the assembler can't assemble. | | Microport's C compiler is THE SAME COMPILER that you get from AT&T. Any | problems with Microport's compiler should be the same with AT&T. | Perhaps you got a very new version of the AT&T C compiler, one which we | do not yet have to ship. I'm going to add some information on the 386UNIX C compiler. I have a benchmark suite which I have run on about 70 machines, without serious problems. In trying to run it under 386ix I noted that about 30% of the programs wouldn't compile, most of which caused the compiler to emit code the assembler couldn't use ("there is no register 25" messages) and a few "core dumped" cases. I have seen this on the 386ix, Microport, and Plexus versions. I have not had a chance to try it on AT&T or Bell Tech, but I assume there is a problem in the version used by all as a staring point. I reported the bug to INteractive and Microport, and have no idea if it's fixed. The Xenix compiler compiled everything, ran everything, and was faster for the things which ran on both. This was the basis of my personal decision to run Xenix, and is not a statement that Xenix would be best in all applications. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
rich@jpl-devvax.JPL.NASA.GOV (Richard Pettit) (08/30/88)
In article <171@banzai.UUCP> john@banzai.UUCP (John Canning) writes: >In article <145@carpet.WLK.COM> bill@carpet.WLK.COM (Bill Kennedy) writes: > >Bill also mentioned that the VP/ix from AT&T works. The one experience I >had with it resulted in a big mess in the free list. I'd hate to see >what Microport's version does. Hmmm. Strange, when I used VP/ix (second beta release) way back in July of 1987, I got Microport windows to work (with the mouse), Ventura desk top publishing (with the mouse), and all of the Microsoft paint, and viewgraph crap as well. In fact, SideKick even worked! And this was on a '386 box that I assembled from spare parts, complete with one of the first post-beta '386 chips and a 10MHz '287. I'm finding it REAL DIFFICULT TO BELIEVE that the production product does not function correctly on warrantied hardware. I'm a little more inclined to believe that the people using the systems don't function correctly. Any other VP/ix users want to tell me that I'm full of crap ? BTW: I have used the 386 DOSMERGE. It'll run 'hello world'. That's about it. Rich -- rich@jpl-devvax.Jpl.Nasa.Gov
samperi@djs.UUCP (Dominick Samperi) (08/31/88)
In article <441@uport.UUCP> keith@uport.UUCP (Keith Hankin) writes: |Microport's C compiler is THE SAME COMPILER that you get from AT&T. Any |problems with Microport's compiler should be the same with AT&T. |Perhaps you got a very new version of the AT&T C compiler, one which we |do not yet have to ship. I've used AT&T's C compiler under Sys V Rel. 2 on a 3B2/300 since before Microport existed, and it has NEVER caused the system to panic when I run trivial programs that do some floating point operations. -- Dominick Samperi samperi@acf8.nyu.edu uunet!hombre!samperi cmcl2!acf8!samperi rutgers!acf8.nyu.edu!samperi (^ ell)
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (08/31/88)
In article <2753@jpl-devvax.JPL.NASA.GOV> rich@jpl-devvax.JPL.NASA.GOV (Richard Pettit) writes: | Any other VP/ix users want to tell me that I'm full of crap ? If it makes you happy ;-) The production version seems good for most business use. I did find a game or two which didn't work, but no real problems. | | BTW: I have used the 386 DOSMERGE. It'll run 'hello world'. That's about it. It's not that bad as far as I can tell, but I wouldn't trade vpix for it. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
james@bigtex.uucp (James Van Artsdalen) (09/01/88)
In article <176@djs.UUCP>, samperi@djs.UUCP (Dominick Samperi) wrote: > I've used AT&T's C compiler under Sys V Rel. 2 on a 3B2/300 since before > Microport existed, and it has NEVER caused the system to panic when I run > trivial programs that do some floating point operations. Nor does the Microport compiler. Microport has been guilty of quality control lapses in the past, but this problem is solely Intel's. The latest step of the 80386 supposedly fixes this problem. The compiler has no control over it (well, I suppose you could do all x87 work in kernel mode to guarantee that no paging could occur, but that is more of an overall system design decision that a compiler issue). -- 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
keith@uport.UUCP (Keith Hankin) (09/01/88)
In article <176@djs.UUCP> samperi@djs.UUCP (Dominick Samperi) writes: |In article <441@uport.UUCP> keith@uport.UUCP (Keith Hankin) writes: ||Microport's C compiler is THE SAME COMPILER that you get from AT&T. Any ||problems with Microport's compiler should be the same with AT&T. ||Perhaps you got a very new version of the AT&T C compiler, one which we ||do not yet have to ship. | |I've used AT&T's C compiler under Sys V Rel. 2 on a 3B2/300 since before |Microport existed, and it has NEVER caused the system to panic when I run |trivial programs that do some floating point operations. |-- |Dominick Samperi | samperi@acf8.nyu.edu uunet!hombre!samperi | cmcl2!acf8!samperi rutgers!acf8.nyu.edu!samperi | (^ ell) 3B2 machines have been around a lot longer, and a compiler for a 3B2, with regard to floating point handling is completely different. AT&T has had a more difficult time (apparently) with the floating point in 80287 and 80387 environments. -- Keith Hankin keith@uport Microport Systems
tif@cpe.UUCP (09/01/88)
Written 3:40 pm Aug 30, 1988 by djs.UUCP!samperi in cpe:comp.sy.ibm.pc >I've used AT&T's C compiler under Sys V Rel. 2 on a 3B2/300 since before >Microport existed, and it has NEVER caused the system to panic when I run >trivial programs that do some floating point operations. *If* your referring (vaguely) to what I think you're referring to, that has nothing to do with the compiler and everything to do with the hardware. Paul Chamberlain Computer Product Engineering, Tandy Corp. {convex,killer}!ninja!cpe!tif
samperi@djs.UUCP (Dominick Samperi) (09/02/88)
In article <7339@bigtex.uucp> james@bigtex.UUCP (James Van Artsdalen) writes: |In article <176@djs.UUCP>, samperi@djs.UUCP (Dominick Samperi) wrote: | |> I've used AT&T's C compiler under Sys V Rel. 2 on a 3B2/300 since before |> Microport existed, and it has NEVER caused the system to panic when I run |> trivial programs that do some floating point operations. | |Nor does the Microport compiler. Microport has been guilty of quality |control lapses in the past, but this problem is solely Intel's. The |latest step of the 80386 supposedly fixes this problem. I should have made it clear that I was speaking about their 286 compiler, for which they have admitted that it is a compiler bug, and they have given the work-around: "buy another vendor's C compiler." -- Dominick Samperi samperi@acf8.nyu.edu uunet!hombre!samperi cmcl2!acf8!samperi rutgers!acf8.nyu.edu!samperi (^ ell)
samperi@djs.UUCP (Dominick Samperi) (09/02/88)
In article <446@uport.UUCP> keith@uport.UUCP (Keith Hankin) writes: |3B2 machines have been around a lot longer, and a compiler for a 3B2, |with regard to floating point handling is completely different. AT&T |has had a more difficult time (apparently) with the floating point in |80287 and 80387 environments. Actually, the system panics when "hello, world" class programs are run if certain simple floating point operations are done, if the program is compiled in the large model (under System V/286), and if an 80287 is NOT installed. If an 80287 is installed, you get away with a core dump. -- Dominick Samperi samperi@acf8.nyu.edu uunet!hombre!samperi cmcl2!acf8!samperi rutgers!acf8.nyu.edu!samperi (^ ell)
scotty@l5comp.UUCP (Scott Turner) (09/02/88)
This debate of "Pure" AT&T unix vs. Microport SystemV/386 was just too much, I just had to pop up and add my several thousand dollars worth. :) Why several thousand dollars? That's how much I've sunk into this '386 unix swamp... First let's get my "political" leaning stated up front, any unix system based on System V with no Berk 4.3 goodies tossed in is a continual migrane. I'm not as bad as the GNU "Death before System V" camp but I'm not real big on "pure" System V. Thus, everthing except the Roadrunner's OS is non-choice in my political view. But with Sun not licensing their OS for lowly 386AT machines one is forced to work with available materials. My first choice was Microport's System V/386 2.2 (those "extra" numbers are REAL important when discussing these things folks...) with every optional software package they had (upto and including getting the NSA restricted crypt package.) I also decided to take them up on their hotline support contract and their update contract. Total bill? In excess of $1800. Sounds like ALOT, but it's what I expected a REAL unix to cost. Problem is that this REAL unix doesn't come with REAL WORLD features... The text preparation option is a prime example. It comes ready to talk to a phototypesetter or an obsolete Imagen laser printer (and they don't supply the driver for the typesetter!) No support for Epson's, Laserjet's, or any other type of printer that one would expect to find hooked to a 386AT. I hope they've fixed this, but for some reason they haven't sent this package to me for beta testing along with the rest of the unix... (even though I have ALL sorts of printer hardware to test it with) The Network Services Extension is a sad joke. In a REAL WORLD where everyone speaks TELNET/FTP/NFS, NSE gives you CU/UUCP/RFS. Sure, CU/UUCP/RFS do everything TELNET/FTP/NFS do, but not with anything speaking TELNET/FTP/NFS! Which seems to be most of the REAL WORLD these days, sigh. The cruelest joke though is that TELNET/FTP are available as third party add-ons. $1500 and Excellan will fill the gap, but only after you buy the otherwise worthless NSE!!! The irony of this still rankles me. For $1500 you think they'd GIVE you the damn NSE... But alas the cruel REAL WORLD had even more blows... System V/386 2.2 had no support for ESDI, RLL, or SCSI. No tape drives other than what I THINK is a Televideo cartridge tape unit. The battle was joined and to their credit Microport didn't try to duck the battle. An ESDI capable kernel was delivered up and the real fun began... The REAL WORLD struck again. Big drives (in this case 320Mb FORMATTED) come with LONG defect lists. System V/386 2.2 (and 3.0e for that matter, sigh) only supports mapping out 62 defects. Worse still was that the early ESDI support was in the kernel ONLY. The defect scanning software still thought MFM when trying to map out the bad blocks. The hard drive scanning tool did fopen( "tty") rather than using stderr or stdout so you had to write real fast when copying down defect locations (so you could enter them into the defect list manually after running them through an algorithm on your handy HP16C.) The 320Mb drive became a 230Mb drive to lop off enough defects to get below the limit. Then it turned out the cursed hard drive scanner was only reporting the first bad block on a track. On ESDI drives the defects can be so large they span two sectors it seems... As if unix wasn't enough fun, DOSMerge 386 1.0 had all sorts of problems as well. My favorite was the bug report that DOSMerge didn't work with Maxtor hard drives. Didn't say which model, or for that matter how it could tell the drive was a Maxtor, just that it didn't work with them. :( DOSMerge would cause spontaneous system resets, you'd be watching a DIR listing and all of a sudden the screen would clear and you'd see the AMI BIOS take over. (or if on a serial tube the screen would freeze and the other users would scream for your blood) Good ol' fsck would randomly pick files to kill, /bin/sh, or the getty, or the /etc/passwd... But Microport stuck it out. I've got a PILE of disks with various "extra" numbers tacked on after the DOSMerge and System V/386 designations. System V/386 3.0e and DOSMerge 1.1-U still don't like my Northgate CT-101 (they have that fixed, but DOSMerge 1.1-U is still using the old System V/386 2.2H console driver, sigh) and I get the occasional "Drive not ready" on A:. They threw in an Everex tape driver but it and my controller have yet to talk to each other without locking the whole box up. On the bright side though the current beta stuff is what I would have wished to have had back when I first bought into this mess. Things are for the most part functional. (Although the Northgate CT-101 problem is REAL annoying, it "bounces" the key you typed before the last key entered ie ls<cr> gets you ls<cr>s or uucp will get you uucpc grrrrrr.) Now that I've aired my frustration with Microport what next? Well, I said I put THOUSANDS into this unix mess, the story ain't over yet. :) Bell Technologies. I don't know if I want to talk about these folks on the net or not. They seem real edgy about having customers talk about them. Screw 'em. :) Back in the really dark days with Microport I started wondering if I had picked the wrong unix. Bell Tech claimed ESDI, RLL, a COMPLETE networking setup and all for only $495. It sounded too good to be true. I held out on will power and fresh beta's from Microport. Then came the WGE. I asked Bell Tech to send me some info about their hardware fix for bug 21 in the '386. They sent this huge poster of the display from a WGE. It had me, customers, everyone drooling. Let's face it, 1660x1200 monochrome with coprocessor and X-windows for $1495 was (still is) red hot. It was red hot and SOLD. :) But alas Bell Tech claimed the drivers for the WGE would only work with their System V/386 3.0. Will power destroyed. They missed their initial ship date. They missed the next one, "We needed the boards for a show." I had told them to ship the unix without the WGE after they missed the first ship date, "Oh, I didn't think you'd want the unix without the WGE" even though I had told him I did... Oh well, he was under pressure, we're all human... The unix arrived, sans most of the manuals. When would the manuals arrive? Various "ummm, well, ahhhh" answers. Screw the manuals said I, I won't read 'em anyway. :) At this point I learned something VERY interesting. Bell Tech System V/386 3.0 and Microport System V/386 x.x look ALOT alike. Damn near identical in fact. Little thoughts start nibbling "Why won't the WGE drivers install on Microport?" "How many Microport problems are really AT&T problems and thus shared?"... Well the 62 defect problem is shared. (Damn!) Interestingly though, after claiming ESDI support, Bell Tech won't even boot from an Adaptec 2322 ESDI controller. "Does your controller have EPROMs or ROMs on it?" hmm "Yes, but it's 100% register compatible..." which evoked a line I will remember forever "Well, our driver sometimes gets confused by onboard EPROMs." She couldn't explain how EPROMs could confuse a driver that was using direct register I/O, but she remained convinced the fault was those pesky EPROMs on my 2322. She promised to call back. I decided to try some "gene" splicing experiments. I took the Microport ESDI- capable hd.o and stuffed it into the Bell Tech unix. The hybrid booted just fine. I breath a BIG sigh of relief (I wanted the WGE real bad, not to mention everyone else was clamoring to use it.) Next day she calls back, as promised (one of the two times), and informs me that I need to return the unix. The engineers had told her that they had had very little luck with my hardware: Mylex motherboard and Maxtor hard drive. I was real confused at this point, why it was that everyone keep fingering Maxtor hard drives I just couldn't fathom... I told her I needed the unix so I could use the WGE and got the offer to leave a message for my sales person to call me and give me an RMA to return the unix for a full refund. "But what about the WGE?!?" "I'm sure he'll refund that as well, sir." Sputter, argh, screams of utter contempt for lower life forms found eating ones dinner! I decided to bank on the fact I had it working. I also decided to buy some insurance and called the switch board at Bell Tech and got the name of their chief Unix guru. I have left several messages for this person, I have NEVER ever ever heard back from him/her/it. (It is now over 2 months later as I write this) The WGE arrives. The "ummm, well, ahhhh" manuals arrive with it. I grab the WGE readme manual, waste time reading it (one of those really thin installation guides that turned you off on reading the damn things in the first place!) Decide to screw the Bell Tech unix "I'll not be getting much but an RMA number from them for support" and proceed with installation under Microport's unix. The space.c files compiled, the kernel linked, mcs ran. Hooray! Then I booted it. Hooray! I fired up X and turned eager eyes to the dark (the WGE didn't have support for MDA, CGA, EGA emulation back then so you had to boot with another display installed) big beautiful 19" display. It turned grey, a nice CRISP grey, heart REALLY pounds with excitement and then the X server dies. Couldn't talk to the Intel co-processor... And yet it had, the damn screen turned on after all. Re-read the installation guide, the REGISTERS are MEMORY mapped into cached memory addresses... Kill the cache, and it runs! Like a kid at christmas I start running everything in sight and looking at all the pictures. I nearly die from the pile of people leaning over my shoulder... Running through the demos takes .5hr. awm refuses to work. Some of the listed demos aren't available... About then the thrill of victory turns a tad sour. Then gets REAL sour. I forgot, much like "pure" unix vs Berk 4.3, X10R4 doesn't hold a candle to X11R2... Oh well. About then the system crashes and fsck does another number on the hard drive during reboot. Then the system refuses to boot. splint errors appear, 2.2H release notes indicate this means no ram where the system is told to expect it. For example missing EGA ram, bingo! The card appears very very very DEAD. Bell Tech was willing to fix it, but they were much happier to give me a refund RMA rather than a repair RMA. They really didn't want to work with me on the caching issues either. They also had no answer for what they were going to do on other cached CPU's like the newer Compaq's... As for when the REAL X-Windows would show "We're hoping someone will develop X11 for us." Exit Bell Tech. But I didn't send anything back. :) Claims of X11R2 and MDA emulation dancing in the future I have held onto the WGE and the unix. I just ordered up the MDA emulation EPROM this week so maybe the WGE will fly again. (I now know the splint's to be from a bad kernel, got zonked by fsck...) At this point I got to sit back and think. Microport System V/386 2.2H had arrived, it had GreenHill's C-386, a Graphics driver that ate escape sequences to draw lines on the screen, Kernel debugger, adb, SysViz, Everex tape driver, keyboard key re-mapper, hot key remapper, the list went on and on... It made the Bell Tech unix look pretty weak, but Bell claimed that AT&T would be releasing 3.1 RSN and it would fix the 62 defect problem that Microport kept putting off (and is STILL putting off.) But I still couldn't get the system to run reliably for more than 4 days. (The WGE is on the shelf at this point to keep life simple) And I've installed the unix system about 18 times at this point. That gets old REAL quick (there are close to 20 disks to be loaded each and every time...) In this black hour PCDOS 4.0 shows up. Claims of big partitions, bigger than 32Mb(!), EMS support inside the DOS, and a EEMS emulator for '386 machines did me in. Down to Egghead, $130 gets me the last of 12 copies they got in that MORNING. PCDOS had grown. It now came on 5 disks. It had it's own install program. But it was still DOS. :) Formatting the drive didn't go too well. The old 2.x format problem of hitting a bad block past the 50% point seems to be back. At least for a 260Mb root partition. A 32mb root and a 230Mb extended partition worked though. The '386 EEMS simulator only works with PS/2's. (IBM doesn't make a 386AT after all...) And it uses code in the PS/2 BIOS as near as I can tell (I debug'd out the "Real IBM computer" check.) All the other creepy PCDOS 4.0 bugs showed up (format a disk, load it with software, and a 3.21 system thinks the disk is EMPTY!). The much vaunted DOS Shell wouldn't shell. Emitted crypt error messages rather than running. emacs *\Makefile wouldn't. I missed DOSMerge 386. Especially when the system would hang, with DOSMerge you could always login via a serial terminal and kill -9 the dos task if things got totally out of control. Then arrives Microport's System V/386 3.0e and DOSMerge 1.1-U. I was DOStired and DOSweary. Time to get beat up by unix again. :) But 'lo it installed no sweat. It had this cute new scanner that knew about ESDI drives and ran at a decent clip. Those duel bad sectors per track didn't fool it. It didn't cough when it found more than 62 defects, it didn't map the extras out but it didn't just abort like previous scanners. Life looked good. I'm happy to report that life still looks good. I'm still trying to convince fsdb to let me create a bad block file to map out the extra defects, the keyboard is still flakey, the A: drive is flakey. It's System V, but it beats PCDOS. Now, as for the DOSMerge can run "Hello world" and little else... Of this whole sad saga DOSMerge has been a real reason to keep on going. It's beyond terrific. It's the BEST PCDOS development environment I've run across. It beats the rest, like PCMOS or Concurrent DOS, because not only do you get DOS but you get unix commands. Why use ndmake when you can have the real thing? :) Rather than hacking programs to do what unix commands can already do, you get to do work. If the users can't hack ls, let them use DIR. Even from a unix shell! I've got two DOSMerge bugs at present: 1. The ROM BIOS machine ID is set to 0. Which is illegal and confuses some software, such as Codeview. But you can write a program to patch the byte and insert a call to the program into the autoexec.bat and this problem is fixed (and maybe someday Locus will fix it.) 2. The "virtual" 8259 seems to have a problem being used to poll for IRQ's by the too-smart-for-its-own-good Microsoft BUS Mouse driver. I always wondered why I didn't have to tell it which IRQ to use, well now I know. It finds the BUS chip, then goes into a loop of making the chip issue an IRQ and polling the 8259 to see if any came in. DOSMerge currently won't run Desqview 2.01. Gets some sort of math exception and then locks up tight. But Windows 2.1 does run, minus the mouse though. :) I've run NCSA's Telnet/FTP on a WD8003E under DOSMerge (using the /etc/dosdev to teach it about the WD8003E) and finally have REAL WORLD networking. :) I suspect PC-NFS would run as well so I could have NFS. Under DOSMerge I can run REAL WORLD nroff's that know about REAL WORLD printing devices. In short DOSMerge "fixes" alot of the problems with "pure" unix. It does a nice job of filling in for the missing Berk 4.3 enhancements. (To tip or procomm? Not a real difficult choice. :) Anyway, time to wrap up this rather long posting... Despite all the pain caused by Microport I'm sticking with them because they're sticking with me. This, more than anything else, is why I give Microport higher marks than Bell Tech. Bell is quicker to offer an RMA return than support in my experience. Of course what I could have here is a case of: here is beta-support from Micrport and none from Bell Tech and life would be even more confused if I had beta supprt from both (no pun intended ;). But one thing is for damn sure, I can get tech support from Microport via a 1-800 number which is active 24hrs a day 7 days a week. With Bell Tech you get a harried operator and no calls back except from yer sales person. He's always eager to call you back. :) But as for tech support you have to be scheduled for a call back and in my experience you often don't ever get called back. Or maybe it's "Ooops, phone is busy, take him off the list." :-) But support issues aside, you pay more but it looks like you will get more from Microport. Greenhills, Everex, SysViz, and various tools to make life easier (cmos ram config tool for example). They also give you some example files to work from. The Bell Tech $495 unix is pretty well stripped down for a unix. They don't even give you sample .profile's and .login's with the Bell Tech unix. No extra tools beyond what Microport provides. And no REAL WORLD ethernet support either, you get the same NSE CU/UUCP/RFS as with Microport. No extra ethernet drivers no extra support tools, the same exact bits. No Greenhills, no SysViz, no CMOS config tools... Oh yeah! One last response to a net item, shl doesn't come close to what Microport has with their virtual consoles... (or berk has with window) Scott Turner scotty@l5comp -or- uunet!l5comp!scotty Newsgroups: comp.sys.att,comp.unix.microport,comp.sys.ibm.pc Subject: Re: AT&T 386 UNIX Vr3.1 Summary: They all have weak points... References: <145@carpet.WLK.COM> <171@banzai.UUCP> <2753@jpl-devvax.JPL.NASA.GOV> <12031@steinmetz.ge.com> Reply-To: scotty@l5comp.UUCP (Scott Turner) Organization: L5 Computing, Edmonds, WA This debate of "Pure" AT&T unix vs. Microport SystemV/386 was just too much, I just had to pop up and add my several thousand dollars worth. :) Why several thousand dollars? That's how much I've sunk into this '386 unix swamp... First let's get my "political" leaning stated up front, any unix system based on System V with no Berk 4.3 goodies tossed in is a continual migrane. I'm not as bad as the GNU "Death before System V" camp but I'm not real big on "pure" System V. Thus, everthing except the Roadrunner's OS is non-choice in my political view. But with Sun not licensing their OS for lowly 386AT machines one is forced to work with available materials. My first choice was Microport's System V/386 2.2 (those "extra" numbers are REAL important when discussing these things folks...) with every optional software package they had (upto and including getting the NSA restricted crypt package.) I also decided to take them up on their hotline support contract and their update contract. Total bill? In excess of $1800. Sounds like ALOT, but it's what I expected a REAL unix to cost. Problem is that this REAL unix doesn't come with REAL WORLD features... The text preparation option is a prime example. It comes ready to talk to a phototypesetter or an obsolete Imagen laser printer (and they don't supply the driver for the typesetter!) No support for Epson's, Laserjet's, or any other type of printer that one would expect to find hooked to a 386AT. I hope they've fixed this, but for some reason they haven't sent this package to me for beta testing along with the rest of the unix... (even though I have ALL sorts of printer hardware to test it with) The Network Services Extension is a sad joke. In a REAL WORLD where everyone speaks TELNET/FTP/NFS, NSE gives you CU/UUCP/RFS. Sure, CU/UUCP/RFS do everything TELNET/FTP/NFS do, but not with anything speaking TELNET/FTP/NFS! Which seems to be most of the REAL WORLD these days, sigh. The cruelest joke though is that TELNET/FTP are available as third party add-ons. $1500 and Excellan will fill the gap, but only after you buy the otherwise worthless NSE!!! The irony of this still rankles me. For $1500 you think they'd GIVE you the damn NSE... But alas the cruel REAL WORLD had even more blows... System V/386 2.2 had no support for ESDI, RLL, or SCSI. No tape drives other than what I THINK is a Televideo cartridge tape unit. The battle was joined and to their credit Microport didn't try to duck the battle. An ESDI capable kernel was delivered up and the real fun began... The REAL WORLD struck again. Big drives (in this case 320Mb FORMATTED) come with LONG defect lists. System V/386 2.2 (and 3.0e for that matter, sigh) only supports mapping out 62 defects. Worse still was that the early ESDI support was in the kernel ONLY. The defect scanning software still thought MFM when trying to map out the bad blocks. The hard drive scanning tool did fopen( "tty") rather than using stderr or stdout so you had to write real fast when copying down defect locations (so you could enter them into the defect list manually after running them through an algorithm on your handy HP16C.) The 320Mb drive became a 230Mb drive to lop off enough defects to get below the limit. Then it turned out the cursed hard drive scanner was only reporting the first bad block on a track. On ESDI drives the defects can be so large they span two sectors it seems... As if unix wasn't enough fun, DOSMerge 386 1.0 had all sorts of problems as well. My favorite was the bug report that DOSMerge didn't work with Maxtor hard drives. Didn't say which model, or for that matter how it could tell the drive was a Maxtor, just that it didn't work with them. :( DOSMerge would cause spontaneous system resets, you'd be watching a DIR listing and all of a sudden the screen would clear and you'd see the AMI BIOS take over. (or if on a serial tube the screen would freeze and the other users would scream for your blood) Good ol' fsck would randomly pick files to kill, /bin/sh, or the getty, or the /etc/passwd... But Microport stuck it out. I've got a PILE of disks with various "extra" numbers tacked on after the DOSMerge and System V/386 designations. System V/386 3.0e and DOSMerge 1.1-U still don't like my Northgate CT-101 (they have that fixed, but DOSMerge 1.1-U is still using the old System V/386 2.2H console driver, sigh) and I get the occasional "Drive not ready" on A:. They threw in an Everex tape driver but it and my controller have yet to talk to each other without locking the whole box up. On the bright side though the current beta stuff is what I would have wished to have had back when I first bought into this mess. Things are for the most part functional. (Although the Northgate CT-101 problem is REAL annoying, it "bounces" the key you typed before the last key entered ie ls<cr> gets you ls<cr>s or uucp will get you uucpc grrrrrr.) Now that I've aired my frustration with Microport what next? Well, I said I put THOUSANDS into this unix mess, the story ain't over yet. :) Bell Technologies. I don't know if I want to talk about these folks on the net or not. They seem real edgy about having customers talk about them. Screw 'em. :) Back in the really dark days with Microport I started wondering if I had picked the wrong unix. Bell Tech claimed ESDI, RLL, a COMPLETE networking setup and all for only $495. It sounded too good to be true. I held out on will power and fresh beta's from Microport. Then came the WGE. I asked Bell Tech to send me some info about their hardware fix for bug 21 in the '386. They sent this huge poster of the display from a WGE. It had me, customers, everyone drooling. Let's face it, 1660x1200 monochrome with coprocessor and X-windows for $1495 was (still is) red hot. It was red hot and SOLD. :) But alas Bell Tech claimed the drivers for the WGE would only work with their System V/386 3.0. Will power destroyed. They missed their initial ship date. They missed the next one, "We needed the boards for a show." I had told them to ship the unix without the WGE after they missed the first ship date, "Oh, I didn't think you'd want the unix without the WGE" even though I had told him I did... Oh well, he was under pressure, we're all human... The unix arrived, sans most of the manuals. When would the manuals arrive? Various "ummm, well, ahhhh" answers. Screw the manuals said I, I won't read 'em anyway. :) At this point I learned something VERY interesting. Bell Tech System V/386 3.0 and Microport System V/386 x.x look ALOT alike. Damn near identical in fact. Little thoughts start nibbling "Why won't the WGE drivers install on Microport?" "How many Microport problems are really AT&T problems and thus shared?"... Well the 62 defect problem is shared. (Damn!) Interestingly though, after claiming ESDI support, Bell Tech won't even boot from an Adaptec 2322 ESDI controller. "Does your controller have EPROMs or ROMs on it?" hmm "Yes, but it's 100% register compatible..." which evoked a line I will remember forever "Well, our driver sometimes gets confused by onboard EPROMs." She couldn't explain how EPROMs could confuse a driver that was using direct register I/O, but she remained convinced the fault was those pesky EPROMs on my 2322. She promised to call back. I decided to try some "gene" splicing experiments. I took the Microport ESDI- capable hd.o and stuffed it into the Bell Tech unix. The hybrid booted just fine. I breath a BIG sigh of relief (I wanted the WGE real bad, not to mention everyone else was clamoring to use it.) Next day she calls back, as promised (one of the two times), and informs me that I need to return the unix. The engineers had told her that they had had very little luck with my hardware: Mylex motherboard and Maxtor hard drive. I was real confused at this point, why it was that everyone keep fingering Maxtor hard drives I just couldn't fathom... I told her I needed the unix so I could use the WGE and got the offer to leave a message for my sales person to call me and give me an RMA to return the unix for a full refund. "But what about the WGE?!?" "I'm sure he'll refund that as well, sir." Sputter, argh, screams of utter contempt for lower life forms found eating ones dinner! I decided to bank on the fact I had it working. I also decided to buy some insurance and called the switch board at Bell Tech and got the name of their chief Unix guru. I have left several messages for this person, I have NEVER ever ever heard back from him/her/it. (It is now over 2 months later as I write this) The WGE arrives. The "ummm, well, ahhhh" manuals arrive with it. I grab the WGE readme manual, waste time reading it (one of those really thin installation guides that turned you off on reading the damn things in the first place!) Decide to screw the Bell Tech unix "I'll not be getting much but an RMA number from them for support" and proceed with installation under Microport's unix. The space.c files compiled, the kernel linked, mcs ran. Hooray! Then I booted it. Hooray! I fired up X and turned eager eyes to the dark (the WGE didn't have support for MDA, CGA, EGA emulation back then so you had to boot with another display installed) big beautiful 19" display. It turned grey, a nice CRISP grey, heart REALLY pounds with excitement and then the X server dies. Couldn't talk to the Intel co-processor... And yet it had, the damn screen turned on after all. Re-read the installation guide, the REGISTERS are MEMORY mapped into cached memory addresses... Kill the cache, and it runs! Like a kid at christmas I start running everything in sight and looking at all the pictures. I nearly die from the pile of people leaning over my shoulder... Running through the demos takes .5hr. awm refuses to work. Some of the listed demos aren't available... About then the thrill of victory turns a tad sour. Then gets REAL sour. I forgot, much like "pure" unix vs Berk 4.3, X10R4 doesn't hold a candle to X11R2... Oh well. About then the system crashes and fsck does another number on the hard drive during reboot. Then the system refuses to boot. splint errors appear, 2.2H release notes indicate this means no ram where the system is told to expect it. For example missing EGA ram, bingo! The card appears very very very DEAD. Bell Tech was willing to fix it, but they were much happier to give me a refund RMA rather than a repair RMA. They really didn't want to work with me on the caching issues either. They also had no answer for what they were going to do on other cached CPU's like the newer Compaq's... As for when the REAL X-Windows would show "We're hoping someone will develop X11 for us." Exit Bell Tech. But I didn't send anything back. :) Claims of X11R2 and MDA emulation dancing in the future I have held onto the WGE and the unix. I just ordered up the MDA emulation EPROM this week so maybe the WGE will fly again. (I now know the splint's to be from a bad kernel, got zonked by fsck...) At this point I got to sit back and think. Microport System V/386 2.2H had arrived, it had GreenHill's C-386, a Graphics driver that ate escape sequences to draw lines on the screen, Kernel debugger, adb, SysViz, Everex tape driver, keyboard key re-mapper, hot key remapper, the list went on and on... It made the Bell Tech unix look pretty weak, but Bell claimed that AT&T would be releasing 3.1 RSN and it would fix the 62 defect problem that Microport kept putting off (and is STILL putting off.) But I still couldn't get the system to run reliably for more than 4 days. (The WGE is on the shelf at this point to keep life simple) And I've installed the unix system about 18 times at this point. That gets old REAL quick (there are close to 20 disks to be loaded each and every time...) In this black hour PCDOS 4.0 shows up. Claims of big partitions, bigger than 32Mb(!), EMS support inside the DOS, and a EEMS emulator for '386 machines did me in. Down to Egghead, $130 gets me the last of 12 copies they got in that MORNING. PCDOS had grown. It now came on 5 disks. It had it's own install program. But it was still DOS. :) Formatting the drive didn't go too well. The old 2.x format problem of hitting a bad block past the 50% point seems to be back. At least for a 260Mb root partition. A 32mb root and a 230Mb extended partition worked though. The '386 EEMS simulator only works with PS/2's. (IBM doesn't make a 386AT after all...) And it uses code in the PS/2 BIOS as near as I can tell (I debug'd out the "Real IBM computer" check.) All the other creepy PCDOS 4.0 bugs showed up (format a disk, load it with software, and a 3.21 system thinks the disk is EMPTY!). The much vaunted DOS Shell wouldn't shell. Emitted crypt error messages rather than running. emacs *\Makefile wouldn't. I missed DOSMerge 386. Especially when the system would hang, with DOSMerge you could always login via a serial terminal and kill -9 the dos task if things got totally out of control. Then arrives Microport's System V/386 3.0e and DOSMerge 1.1-U. I was DOStired and DOSweary. Time to get beat up by unix again. :) But 'lo it installed no sweat. It had this cute new scanner that knew about ESDI drives and ran at a decent clip. Those duel bad sectors per track didn't fool it. It didn't cough when it found more than 62 defects, it didn't map the extras out but it didn't just abort like previous scanners. Life looked good. I'm happy to report that life still looks good. I'm still trying to convince fsdb to let me create a bad block file to map out the extra defects, the keyboard is still flakey, the A: drive is flakey. It's System V, but it beats PCDOS. Now, as for the DOSMerge can run "Hello world" and little else... Of this whole sad saga DOSMerge has been a real reason to keep on going. It's beyond terrific. It's the BEST PCDOS development environment I've run across. It beats the rest, like PCMOS or Concurrent DOS, because not only do you get DOS but you get unix commands. Why use ndmake when you can have the real thing? :) Rather than hacking programs to do what unix commands can already do, you get to do work. If the users can't hack ls, let them use DIR. Even from a unix shell! I've got two DOSMerge bugs at present: 1. The ROM BIOS machine ID is set to 0. Which is illegal and confuses some software, such as Codeview. But you can write a program to patch the byte and insert a call to the program into the autoexec.bat and this problem is fixed (and maybe someday Locus will fix it.) 2. The "virtual" 8259 seems to have a problem being used to poll for IRQ's by the too-smart-for-its-own-good Microsoft BUS Mouse driver. I always wondered why I didn't have to tell it which IRQ to use, well now I know. It finds the BUS chip, then goes into a loop of making the chip issue an IRQ and polling the 8259 to see if any came in. DOSMerge currently won't run Desqview 2.01. Gets some sort of math exception and then locks up tight. But Windows 2.1 does run, minus the mouse though. :) I've run NCSA's Telnet/FTP on a WD8003E under DOSMerge (using the /etc/dosdev to teach it about the WD8003E) and finally have REAL WORLD networking. :) I suspect PC-NFS would run as well so I could have NFS. Under DOSMerge I can run REAL WORLD nroff's that know about REAL WORLD printing devices. In short DOSMerge "fixes" alot of the problems with "pure" unix. It does a nice job of filling in for the missing Berk 4.3 enhancements. (To tip or procomm? Not a real difficult choice. :) Anyway, time to wrap up this rather long posting... Despite all the pain caused by Microport I'm sticking with them because they're sticking with me. This, more than anything else, is why I give Microport higher marks than Bell Tech. Bell is quicker to offer an RMA return than support in my experience. Of course what I could have here is a case of: here is beta-support from Micrport and none from Bell Tech and life would be even more confused if I had beta supprt from both (no pun intended ;). But one thing is for damn sure, I can get tech support from Microport via a 1-800 number which is active 24hrs a day 7 days a week. With Bell Tech you get a harried operator and no calls back except from yer sales person. He's always eager to call you back. :) But as for tech support you have to be scheduled for a call back and in my experience you often don't ever get called back. Or maybe it's "Ooops, phone is busy, take him off the list." :-) But support issues aside, you pay more but it looks like you will get more from Microport. Greenhills, Everex, SysViz, and various tools to make life easier (cmos ram config tool for example). They also give you some example files to work from. The Bell Tech $495 unix is pretty well stripped down for a unix. They don't even give you sample .profile's and .login's with the Bell Tech unix. No extra tools beyond what Microport provides. And no REAL WORLD ethernet support either, you get the same NSE CU/UUCP/RFS as with Microport. No extra ethernet drivers no extra support tools, the same exact bits. No Greenhills, no SysViz, no CMOS config tools... Oh yeah! One last response to a net item, shl doesn't come close to what Microport has with their virtual consoles... (or berk has with window) Scott Turner scotty@l5comp -or- uunet!l5comp!scotty
wnp@dcs.UUCP (Wolf N. Paul) (09/02/88)
In article <178@djs.UUCP> samperi@djs.UUCP (Dominick Samperi) writes: >|> I've used AT&T's C compiler under Sys V Rel. 2 on a 3B2/300 since before >|> Microport existed, and it has NEVER caused the system to panic when I run >|> trivial programs that do some floating point operations. >|Nor does the Microport compiler. ... >I should have made it clear that I was speaking about their 286 compiler, for >which they have admitted that it is a compiler bug, and they have given the >work-around: "buy another vendor's C compiler." Well, it is hardly fair to compare Uport's 286 compiler with AT&T's 3B2 offerings, or with ANYONE's offerings on the 386. It is my understanding that System V/AT (including the C compiler, which is AT&T's PCC) is a port done by ISC and Intel for AT&T, and that AT&T certified it. Uport supposedly only added the drivers, just like for their 386 product. What I would be interested to know -- and am surprised that we don't hear more from them -- is what people's experiences are like with AT&T's PC6300 Plus, with UNIX -- this is a binary-compatible implementation of UNIX for AT&T's 286 machine, presumably derived from the same ISC/Intel port as Uport's System V/AT. What problems are there with it? With its floating point implementation? With it's compiler? With its disk drivers and serial port drivers? THAT would be comparing apples with apples! -- Wolf N. Paul * 3387 Sam Rayburn Run * Carrollton TX 75007 * (214) 306-9101 UUCP: killer!dcs!wnp ESL: 62832882 DOMAIN: dcs!wnp@killer.dallas.tx.us TLX: 910-380-0585 EES PLANO UD
cdold@starfish.Convergent.COM (Clarence Dold) (09/02/88)
From article <423@l5comp.UUCP>, by scotty@l5comp.UUCP (Scott Turner): > This debate of "Pure" AT&T unix vs. Microport SystemV/386 was just too much, > I just had to pop up and add my several thousand dollars worth. :) > > Why several thousand dollars? That's how much I've sunk into this '386 unix > swamp... > So, maybe you should have purchased a Unisys 6000/50. Three 325MB SCSI drives, 1.2 or 1.44MB diskettes, 60 or 150MB QIC, 64MB RAM, 20MHz 386, Weitek or 387, Custom Merge/386, Serial Console or PC Monitor, four virtual UNIX screens on the monitor + several MS-DOS sessions. Full UNIX sysV 3.0 Some Berkeley enhancements (only the good ones). NFS...RFS... (I forget which is out, which is 88Q4). 30 users. It works. Oh, excuse me, I can't advertise on the net, we build it. And have shipped it. And showed it in Intel's booth at COMDEX 87. -- Clarence A Dold - cdold@starfish.Convergent.COM (408) 435-5274 ...pyramid!ctnews!mitisft!professo!dold P.O.Box 6685, San Jose, CA 95150-6685
haugj@pigs.UUCP (The Beach Bum) (09/09/88)
In article <12400014@cpe>, tif@cpe.UUCP writes: > Written 3:40 pm Aug 30, 1988 by djs.UUCP!samperi in cpe:comp.sy.ibm.pc > >I've used AT&T's C compiler under Sys V Rel. 2 on a 3B2/300 since before > >Microport existed, and it has NEVER caused the system to panic when I run > >trivial programs that do some floating point operations. > > *If* your referring (vaguely) to what I think you're referring to, that > has nothing to do with the compiler and everything to do with the hardware. [ quick note to paul and others: ninja is going away. please edit your .signature files ... ] the `vague' problem regarding 386's, (the original hardware under discussion) involves page faulting during a floating point operation. i understand (from reading comp.sys.intel) that intel knows there is some problem with the 386 recovering from a page fault if a floating point instruction is the cause. you will have to drop in on c.s.intel for more details, but that is the gist of it. -- =-=-=-=-=-=-=-The Beach Bum at The Big "D" Home for Wayward Hackers-=-=-=-=-=-= Very Long Address: John.F.Haugh@rpp386.dallas.tx.us Very Short Address: jfh@rpp386 "ANSI C: Just say no" -- Me