Date: Tue, 13 Jun 89 06:05:04 EDT From: Wm E Davidsen Jr <386users@crdos1.crd.ge.com> To: 386users@TWG.COM Subject: 80386 mailing list, vol 4 #33 80386 User's mailing list vol 4 #33 Jun 13 1989 In this issue: Re: 386 disk utility / problems with Norton etc. Re: 386/ix and 386SX Question 386^MAX vs. SCSI Controllers (was Re: SCSI controlers) Re: 486 and 860 documentation Re: 80286, 80386 LOADALL instructions. [ 2 msgs ] Caching disk controllers and 386 multiprocessor Buyer Beware.... Gateway 2000 tape drive How does UNIX SVR3 use FPU's Re: Intel 80486... Re: 80386 versus 80387 [ 7 msgs ] The addresses for the list are now: 386users@TWG.COM - for contributions to the list or ...!uunet!TWG.COM!386users 386users-request@TWG.COM - for administrivia or ...!uunet!TWG.COM!386users-request P L E A S E N O T E If you want to get on or off the list, or change your address, please mail to the 386users-request address, or the message will be delayed by having to hand forward it (for your convenience, not mine). ---------------------------------------------------------------------- From: martin@ioc.unibe.ch Subject: Re: 386 disk utility / problems with Norton etc. Date: 18 May 89 10:38:56 GMT The problems with Norton and other unilities on the new Compaq 386/20e probably are not due to the disk controller but to the operation system. If your fried isusing DOS 4.xx or OS/2 V 1.1 from Compaq and used this OS to fromat his disk, then he can't u e old versions of Norton utils (before 4.5). Reason: DOS 4.xx usesthe new 32-bit FAT for large HD's (>32 MB). Old versions of disk utils don't support this but only the old 16-bit FAT. So get the new Norton utils 4.5 and retry. Greetins, Martin ------------------------------ From: madd@bu-it.bu.edu (Jim Frost) Software Tool & Die Subject: Re: 386/ix and 386SX Question Date: 13 May 89 17:13:37 GMT In article <518@dvnspc1.Dev.Unisys.COM> gary@dvnspc1.Dev.Unisys.COM (Gary Barrett) writes: | |Does anyone "out there" know if Interactive's 386/ix and VP/ix |(version 1.0.5) will work with an Intel 386sx-based PC/AT? While I haven't actually tried, I believe there should be no problem at all. The SX is supposed to be 100% software compatible with the 80386 and I haven't heard anything to the contrary. You might want to call Interactive and ask them about the particular machine you want to buy, though. jim frost madd@bu-it.bu.edu ------------------------------ From: keithe@tekgvs.LABS.TEK.COM (Keith Ericson) Tektronix, Inc., Beaverton, OR. Subject: 386^MAX vs. SCSI Controllers (was Re: SCSI controlers) Date: 16 May 89 02:59:44 GMT In article <1883@iesd.dk> sunesen@iesd.dk (Peter Sunesen) writes: >Do anybody have experiens with scsi harddisk controler to AT > >If you have information on the adaptech AHA-1542A god / bad please respond 386^MAX gets badly bent out of shape if you try to use it with either a WD 7000 ASC or an adaptec AHA 1540 (the one w/o the floppy controller on it) because these cards both "borrow" a bit of high DOS memory (for a buffer of some kind?) and 386^MAX can't handle it. I had to give up my SCS WREN IV (and it's > 1 Megabyte/sec transfer rate - SOB!) because 386^MAX was more important to my application (and you spell PC-NFS? YES: m-e-m-o-r-y h-o-g). kEITHe ------------------------------ From: mch@ukc.ac.uk (Martin Howe) Lan/Micro Group, Comp. Lab, Univ. of Kent, CANTERBURY, UK Subject: Re: 486 and 860 documentation Date: 13 May 89 12:50:37 GMT In article <1058@harrier.ukc.ac.uk> I wrote: > >486 data sheet: Order #240440 >486 reference manual: Order #240440 It has been ponted out to me that these order numbers are the same. Sorry, but this is the info that I got from various people. I've no idea which document 240440 belongs to, so if anyone knows the correct answer please post ! Regards, -- Martin Howe (This posting is private, and NOT on behalf of UKC) ------------------------------ From: peter@langlab1.hf.intel.com (Peter Plamondon) Intel Development Tools Operation, Hillsboro OR Subject: Re: 80286, 80386 LOADALL instructions. Date: 2 Jun 89 16:14:42 GMT In article <30105@conexch.UUCP> rob@conexch.UUCP (Robert Collins) writes: >What about the 80386 version of LOADALL (Opcode 0f07). Does anybody have >the document on that? >Is it appropriate to post this document? Although I don't speak for Intel and have no involvement with the chip designers, I've heard from a reliable source that future steppings of the Intel386(tm) will NOT recognize the LOADALL instruction. Intel is rewriting all 386 software which includes LOADALL; I suspect the gang in Redmond is doing the same, but that's pure speculation. I'd strongly encourage everyone to avoid using LOADALL on a 386. >Since I didn't get these documents by signing a non-disclosure agreement, >would I be breaking any law, or implicit contract by posting them? I'm specifically NOT responding to this question; I have no idea what restrictions, if any, were once or are now placed on the distribution of the LOADALL documentation. ------------------------------ From: brian@apt.UUCP (Brian Litzinger) APT Technology, Inc., San Jose, CA Subject: Re: 80286, 80386 LOADALL instructions. Date: 5 Jun 89 07:20:31 GMT In article <213@guardian.UUCP>, peter@guardian.UUCP (peter) writes: > In article <30105@conexch.UUCP> rob@conexch.UUCP (Robert Collins) writes: > >What about the 80386 version of LOADALL (Opcode 0f07). Does anybody have > >the document on that? > > I've heard from a reliable source that future steppings of the > Intel386(tm) will NOT recognize the LOADALL instruction. Intel is rewriting > all 386 software which includes LOADALL; I suspect the gang in Redmond is > doing the same, but that's pure speculation. I'd strongly encourage everyone > to avoid using LOADALL on a 386. While the LOADALL instruction is, in fact, gone from the Intel386(tm), it is definitely not dead. In fact, on many 386 machines you can execute the 286 LOADALL opcode and exactly the right things will happen. Not because the particular 386 processor happens to have the instruction, but because the system BIOS vendor choose to emulation the instruction in the BIOS. Some BIOSes catch the invalid opcode interrupt, check for the 286 LOADALL instruction, and then emulate it it software. I do, however, agree with peter...Avoid the LOADALL instruction on the 386! <> Brian Litzinger @ APT Technology Inc., San Jose, CA <> UUCP: {apple,sun,pyramid}!daver!apt!brian brian@apt.UUCP <> VOICE: 408 370 9077 FAX: 408 370 9291 ------------------------------ From: steveb@aostul.UUCP (Steve Bogner) AOS Network Solutions Subject: Caching disk controllers and 386 multiprocessor Date: 26 May 89 15:34:10 GMT I am trying to put together a very high performance SCO Xenix system and would like to know if anyone out there has had experience (good or bad) with the caching disk controllers made by DPT (Distributed Processing Technologies). They say you can have a hardware cache of up to 16 MB, reducing disk access to .6 ms. Also, a company called Corollary makes a 386 multiprocessing board for SCO Xenix called the 386/mp. Up to four 386's can be added to the server. Has anyone actually done this? I'm using the ALR 33/386 server with 16 MB of 80 ns RAM and Maxtor 4380E disks. Please reply by e-mail. Steve Bogner !uunet!romed!aostul!steveb ------------------------------ From: Laurence Bates Subject: Buyer Beware.... Date: Wed, 24 May 89 15:38:24 EDT In checking throught the PC Magazine evaluation of 386 machines, I problem has been highlighted that could result in people paying top $ for equipment that they think has been evaluated by PC Magazine. One vendor (Computer Products United) appears to have provided PC Magazine with a system containing an AMI 386/25 motherboard for testing but associated with it the price that they charge for a system that contains a completely different motherboard. On page 267 of the PC magazine article (May 30, 1989) the basic system price for the Computer Products United 386/25 computer is listed as $2,295. In the same magazine, Computer Products United advertize a 386/25 computer at $2,295. Same system - right. WRONG - the system that Computer Products United now sell at $2,295 contains a "Charter Engineer" motherboard. You can purchase the AMI system from them for a mear $1050 extra. I wonder how many other companies are selling equipment that has been evaluated in some previous evolutionary form. When you purchase a system based on a magazine evaluation, make sure that you are getting EXACTLY the product that was submitted for evaluation. Personal viewpoint only... Acknowledge-To: ------------------------------ From: PUCHRIK@tops20.dec.com Subject: Gateway 2000 tape drive Date: 17 May 1989 1807-EDT I've ordered a Gateway 2000 (386-25 MHz) so I don't have to ask what 386 system people recommend. I also ordered a CMS 150 Mb tape drive. The drive is somewhat new and I wouldn't expect many people to have seen them yet. What I want to know is what kind of tape drives do 386 users want? Do people expect to be using cartridge drives on their 386 systems? asp -------- ------------------------------ From: lars@iclswe.UUCP (Lars Tunkrans) ICL Data AB S-194 85 Upplands-Vasby SWEDEN Subject: How does UNIX SVR3 use FPU's Date: 1 Jun 89 13:07:41 GMT Does somebody in netland know to what extent the Unix SVR3 o/s and say standard non-CAD non-graphics software utilises floating-point processors, if at all. I have a choise between a 80386 cpu with either a 80287 FPU or 80387 FPU. Does the more powerfull 80387 FPU make any difference if one is not running applications like CAD and/or Graphics. -- // ///// /// | Lars Tunkrans Distributed Resource Systems support. // /// /// | UUCP: {uunet,mcvax,munnari,cernvax,diku,inria,prlb2,tut /// /// /// | ,ukc,unido} !sunic!iclswe!lars Phone +46 (0)76096368 /// ///// /////// | ( Standard Disclaimer ) ------------------------------ From: tneff@bfmny0.UUCP (Tom Neff) ^ Subject: Re: Intel 80486... Date: 23 May 89 16:56:03 GMT The i486 is really just an 80386 + FPU + MMU integrated on one chip. The larger scale integration allows for shorter paths and heavy pipelining and caching, which is where the improved performance comes from. Unoptimized code should run two to three times faster, optimized code much better. Intel will be upping the clock rate by 3Q90 or so they say. There are three new instructions (affectionately known as the "Sun," "IBM" and "Microsoft" instructions I hear! ) to help things like multiprocessing and endianism. From the programming architecture standpoint it is the same as the 386. The performance gains should entrench Intel hardware in the UNIX marketplace. -- Tom Neff UUCP: ...!uunet!bfmny0!tneff "Truisms aren't everything." Internet: tneff@bfmny0.UU.NET ------------------------------ From: dts@cloud9.Stratus.COM (Daniel Senie) Stratus Computer, Inc., Marlboro, MA Subject: Re: 80386 versus 80387 Date: 17 May 89 18:42:24 GMT In article <1427@uw-entropy.ms.washington.edu>, felsenst@uw-entropy.ms.washington.edu (Joe Felsenstein) writes: > > I have heard that there is a sporadic nasty interaction between 80386's > and 80387 numeric co-processors, owing to a design flaw in the 80386, > and that it is not cleared up yet. > > On a Zenith Z-386 I may be having this problem; when the 80387 is used > there are sporadic unpredictable crashes or operating system > paralysis (I happen to be using Unix, but if this is the problem that > may be irrelevant). This is a well known problem which Intel referred to as Errata 21. Go see your Zenith dealer. He will give you a new PAL for your CPU board which completely remedies the situation. It is a bug in the 386, but a very simple PAL change cures the problem. The DX step of the 386 has this problem fixed. This problem only occurs when running in 32 bit protected mode. Effectively the CPU and Co-Processor sit there waiting for each other forever. -- Daniel Senie UUCP: harvard!ulowell!cloud9!dts Stratus Computer, Inc. ARPA: anvil!cloud9!dts@harvard.harvard.edu 55 Fairbanks Blvd. CSRV: 74176,1347 Marlboro, MA 01752 TEL.: 508 - 460 - 2686 ------------------------------ From: walter@cat27.CS.WISC.EDU (Walter Stewart) U of Wisconsin CS Dept Subject: Re: 80386 versus 80387 Date: 13 May 89 02:17:41 GMT I've been using a 80287 on a Z-386 and I have never exprienced the hardware troubles that you have described. I'm using the 80287 because my pascal compiler doen't support the 80387. Will Turbo Pascal 5.0 support the 80287? ------------------------------ From: mcdonald@uxe.cso.uiuc.edu Subject: Re: 80386 versus 80387 Date: 14 May 89 14:47:00 GMT >I have heard that there is a sporadic nasty interaction between 80386's >and 80387 numeric co-processors, owing to a design flaw in the 80386, >and that it is not cleared up yet. This appears to be the straight poop on this - I got a FAX of a genuine Intel erratum sheet from the kind folks at Phar Lap or MicroWay, I forget which. There is a bug in the silicon of early 80386's that causes a total machine hang at random times if the following things all are true: 1) You have a 80386 and 80387. 2) The 80386 is earlier than DX step (DX step 386's say "DX" right on top. The 386's with the "double sigma" ARE sick. 3) You run in either 386 native 32-bit mode or virtual 8086 mode. 4) Paging is enabled. Note that Windows 386 and Desqview 386 meet conditions 3 and 4, as do most programs especially written for native 386 mode using a 386 runtime system on top of DOS. 5) Your motherboard is of an afflicted design. Certain boards seem to have timings that prevent the problem from occurring. IBM Model 80's are afflicted. 6) The phase of the moon is wrong. This is very important. It really doesn't happen often. My Model 80 was indeed afflicted. A new motherboard with a DX chip fixed the problem. IBM apparently didn't just want to replace the chip itself. Microway and Phar Lap claim that a DX chip alone will fix the problem, but I never tried this. Note that the symptom of this bug is not wrong results, but rather a totally hung machine. Doug McDonald ------------------------------ From: caromero@phoenix.Princeton.EDU (C. Antonio Romero) Princeton University, NJ Subject: Re: 80386 versus 80387 Date: 12 May 89 16:47:50 GMT In article <1427@uw-entropy.ms.washington.edu> joe%uw-evolution@entropy.ms.washington.edu writes: >I have heard that there is a sporadic nasty interaction between 80386's >and 80387 numeric co-processors, owing to a design flaw in the 80386, >and that it is not cleared up yet.... > (I happen to be using Unix, but if this is the problem that >may be irrelevant). I'm not 100% sure that the problem you're having is the one I'm thinking of, but as I recall there was a floating-point problem that plagued early 386 machines, which did show up when using unix. I believe operating system paralysis under Unix as you describe was the symptom. To my knowledge this has been corrected as of a couple of years ago. If you've had your machine that long, you may just need a new 386 chip. The new chip has a double-sigma stenciled on it somewhere; the old chip has, I think, just one sigma, or no markings at all. (I had to check my father's machine out under Xenix to make sure it had the newer chip-- he got one of the relatively early Compaq 386's, before 20MHz etc. was ready. It did have a new chip, so I never saw the problem actually occur; but the symptoms as described to me sound like what you're running into.) Who knows? Maybe you can badger Zenith into sending you a new 386 chip, if you're nasty-- err, insistent enough about it... ;) Also, a 287 won't just drop in unless the Zenith is designed to handle one... (having never popped the top on a Zenith I don't know if it is). >Question: are there 80287's fast enough to work with a 16 MHz 80386 >(I think the answer is yes)? Many machines early on (and even now, I think) can accomodate a 287. I believe the faster 287 part exists, but I don't think using it will solve your problem. -Antonio Romero romero@confidence.princeton.edu ------------------------------ From: toma@tekgvs.LABS.TEK.COM (Tom Almy) Tektronix, Inc., Beaverton, OR. Subject: Re: 80386 versus 80387 Date: 15 May 89 14:45:34 GMT In article <45900232@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: >There is a bug in the silicon of early 80386's that causes a total >machine hang at random times if the following things all are true: [ Lots of conditions ] >6) The phase of the moon is wrong. This is very important. It > really doesn't happen often. Actually, it can happen *very* often. The other failure requirement which you did not mention was 7) executing a floating point instruction when an interrupt occurs. All it takes is a heavily floating point intensive program. In my case, I have Spice compiled running under PharLap DOS/EXTENDER and one particular circuit simulation will crash an afflicted computer *every time*. I use it to check computers! > >My Model 80 was indeed afflicted. A new motherboard with a DX chip >fixed the problem. IBM apparently didn't just want to replace the >chip itself. Microway and Phar Lap claim that a DX chip alone will >fix the problem, but I never tried this. Also, ironically, seemingly all Intel motherboards (301, 301ATZ, and 302) are afflicted. Tom Almy toma@tekgvs.labs.tek.com Standard Disclaimers Apply ------------------------------ From: afg@cbnewsl.ATT.COM (andrew.goldberg) AT&T Bell Laboratories Subject: Re: 80386 versus 80387 Date: 15 May 89 14:02:11 GMT In article <45900232@uxe.cso.uiuc.edu>, mcdonald@uxe.cso.uiuc.edu writes: > > My Model 80 was indeed afflicted. A new motherboard with a DX chip > fixed the problem. IBM apparently didn't just want to replace the > chip itself. Microway and Phar Lap claim that a DX chip alone will > fix the problem, but I never tried this. > Who paid for the new motherboard - you or IBM? Andy Goldberg ------------------------------ End of 80386 M/L Vol 4 #33 **************************