HDTenEightyP/NetNews huggingface dataset:
From: maziere1@husc9.harvard.edu (David Mazieres)
Newsgroups: comp.unix.pc-clone.32bit
Subject: Contaq 486DX50 =? DX2/50
Date: 10 Nov 92 04:26:46 GMT
Article-I.D.: husc3.1992Nov9.232647.17285
Distribution: world
Organization: Harvard University Science Center


I recently bought a 486DX/50 MHz motherboard, made by contaq.  Fortunately,
I haven't experienced any of the dreaded kernel panics people have reported
with DX50's.  However, in the BIOS setup, I must set the SRAM wait states as
follows:

     SRAM Wait States           1 W/S
     SRAM Read Burst Control    3222 Slow

If I understand correctly, other than the 1 clock cycle gained on the first
32 bits of a burst read, I might as well be using a 486DX2/50, since the
cache is effectively operating at 25 MHz.  Should this be acceptible from
a motherboard?  Do most people with 486DX50's have wait states in their cache?
The strange thing is that the manual insists that the cache should be populated
with 20 nsec SRAM for 50 MHz clocks, while 35 nsec will do for 25 MHz clocks.

Should I simply accept this motherboard, or should I try to complain and get
one with no wait states for the CACHE?  Thanks for any advice.
Newsgroups: comp.unix.pc-clone.32bit
From: fche@db.toronto.edu ("Frank Ch. Eigler")
Subject: Re: ISA Limitation?
cc: fche@db.toronto.edu
Organization: Department of Computer Science, University of Toronto
Distribution: na
Date: 5 Nov 92 21:46:56 GMT

kelsey@mdd.comm.mot.com (Joe Kelsey) writes:

> [...]
>I just got through a very trying experience going from 16MB to 32MB on
>my 486-33 ISA machine.  I ended up swapping out the original
>motherboard for a newer version.  The old motherboard did not have a
>large enough TAG CACHE to handle beyond 16M address range.  It did
>have 256kB of data cache, but the TAG CACHE couldn't handle more than
>16M address range.  My system booted and ran (Esix 4.0.4), but any
>programs which happened to get mapped into the upper 16M (common
>enough when you run a few large X Window programs (xv, emacs, etc.))
>had simply *horrible* performance, since the processor had to endure
>the full latency of every access to the 70ns rams!
> [...]


What happens if the cache indeed has only a few address bits in its tag
RAM, say 22 bits, but physical memory may extend above 2^22 bytes?  Are
there boards that *don't* at least *check* the rest of the bits of CPU
address lines, thus whose cache tag may falsely match an address above
2^22 with one below and return the wrong data?
-- 

-- Frank Ch. Eigler -- Comp Eng -- <eigler@ecf.toronto.edu> -- (I'm Brian!)
From: magus@drktowr.chi.il.us (Louis Giliberto)
Newsgroups: comp.unix.pc-clone.32bit
Subject: Re: ISA Limitation?
Date: 9 Nov 92 10:11:41 GMT
Distribution: na
Organization: DarkTower Software
X-Newsreader: TIN [version 1.1 PL6]

Joe Kelsey (kelsey@mdd.comm.mot.com) wrote:
: Remember that a cache consists of two parts: the actual cached data
: (corresponding to the much-touted cache sizes referenced above) and
: what people usually call the TAG, or address part of the cache which
: stores the actual virtual address of the corresponding cache data lines. 

I understand what you are saying, but how does one tell the size of the
TAG cache?  I'm running a 386/40 with 4 megs (soon to be 20 I hope) of
memory, and a 64K cache.  How can I tell if the cache can hold the
address space, or do I generally only need to worry in the
upper reaches (like say 32 megs and up)?

Thanks-
Louis
--
---------------------------------------------------------
 Louis J. Giliberto, Jr.   ! magus@drktowr.chi.il.us
   -sysadmin drktowr       ! lgilibe@orion.it.luc.edu
  Chicago, IL  USA         ! 
---------------------------------------------------------
Newsgroups: comp.unix.pc-clone.32bit
From: kdenning@portal.hq.videocart.com (Karl Denninger)
Subject: Re: ISA Limitation?
Organization: VideOcart Inc.
Date: Thu, 5 Nov 1992 17:49:46 GMT

In article <913@felix.Sublink.Org> eb@felix.Sublink.Org (Enrico Badella) writes:
>In article <BwqMxn.26p@portal.hq.videocart.com> kdenning@portal.hq.videocart.com (Karl Denninger) writes:
>>
>>MAKE CERTAIN that your secondary cache scheme is set up to go beyond 16MB.
>
>How do you verify?

Check the manual.  That's the only reliable way I have found.  Your other
choice is to put in 20MB of RAM and see if the system seems to be slower
than it was with 16MB.  If so you probably have this problem.

>>If you have 64KB of cache on a '486 this is almost certain to be a problem.
>>If you have 256KB cache it is probably not.
>
>What are the reasons for such behavour?

Most direct-mapped schemes aren't set up to work beyond 16MB.  Most
set-associative schemes requires 256KB of cache to work reasonably-well, and
thus the cache controllers aren't designed to do set-associative mapping
with less cache RAM.

Its more of a design issue than anything else; I can't think of a technical
reason why it couldn't be made to work even with the smaller cache, but in
my experience most 64kb cache boards aren't set up that way.

--
Karl Denninger 		Inet:  kdenning@hq.videocart.com
VideOcart Inc.		Voice: (312) 987-5022
Xref: sparky comp.unix.pc-clone.32bit:434 comp.unix.sysv386:16284
From: wjk@Phonogenic.COM (Bill Keenan)
Newsgroups: comp.unix.pc-clone.32bit,comp.unix.sysv386
Subject: Q: EISA SCSI II controllers for ISC 3.0.1
Date: 5 Nov 92 20:42:44 GMT
Reply-To: wjk@Phonogenic.COM (Bill Keenan)
Organization: Phonogenic Systems Corporation
X-Mailer: uAccess - Macintosh Release: 1.6v1

I am trying to find EISA SCSI 2 controllers that ship with driver
support for Interactive (now from SunSoft) UNIX version 3.0.x. In other
words, I am looking for fast (10 MB/s) and/or wide (20 MB/s) SCSI. (I
will summarize if there are any controllers to summarize.)

________________________________________________________________________
Bill Keenan
Internet:	wjk@phonogenic.com -or- phngnc!wjk
AppleLink:	wjk@phonogenic.com@INTERNET#
CompuServe:	>INTERNET:wjk@phonogenic.com
Phonogenic Systems Corporation - Phone 415/365-1083 - FAX 415/365-1083
PO Box 3535, Redwood City CA 94064

This country borrows about $4.25 per day per US resident (that is $17/day
for a family of 4) with little hope of paying any of the principal!
Newsgroups: comp.unix.pc-clone.32bit
From: johnb@sage.cc.purdue.edu (John Brainerd)
Subject: 486 SX vs. DX
Organization: Purdue University Computing Center
Date: Thu, 5 Nov 1992 16:52:02 GMT

     While on this SX-DX battle, I have a couple questions.
What would happen if you bought a motherboard with coprocessor
socket(Weitek?) and then bought a 487 coprocessor, and left the 
main CPU socket empty?  My dealer said this would work, only
this was about a year ago and I wonder if they changed that.
The theory was the 487 disables the 486SX completely, so it 
ends up just being a lot of $$$ sitting on the board keeping
its socket company.

Another question, I currently have a 486DX-25.  Is the DX2 
upgrade worth it?  I not running any kind of u**x but have
thought about buying a new HDD and getting Linux up.

just my 2 bits.

Newsgroups: comp.unix.pc-clone.32bit,comp.os.linux,comp.sys.ibm.pc.hardware
From: beaulieu@bose.com (Larry Beaulieu)
Subject: Re: 486SXs as Unix Iron?
Organization: Bose Corporation
Date: Sun, 8 Nov 1992 22:10:20 GMT

In article <1992Nov6.010525.3647@fasttech.com> zeke@fasttech.com (Bohdan Tashchuk) writes:

   Xref: bose comp.unix.pc-clone.32bit:418 comp.os.linux:521 comp.sys.ibm.pc.hardware:11996
Path: bose!uunet!charon.amdahl.com!pacbell.com!ames!saimiri.primate.wisc.edu!sdd.hp.com!usc!sol.ctr.columbia.edu!emory!ogicse!verdix!islabs!fasttech!zeke
   From: zeke@fasttech.com (Bohdan Tashchuk)
   Newsgroups: comp.unix.pc-clone.32bit,comp.os.linux,comp.sys.ibm.pc.hardware
   Date: 6 Nov 92 01:05:25 GMT
   Article-I.D.: fasttech.1992Nov6.010525.3647
   References: <1992Nov4.223834.9454@mksol.dseg.ti.com>
   Organization: Fast Technology
   Lines: 29

   In <1992Nov4.223834.9454@mksol.dseg.ti.com> mccall@mksol.dseg.ti.com (fred j mccall 575-3539) writes:

>   Even more despicable has been Intel's lack of ethics in other areas.
>   For example, in their dealings with AMD on second sourcing the 386.

 	I remember when several years ago they spent *tens* of millions of dollars to buy 
	Japanese capital equipment and then went crying to Congress because other US companies 
	purchased chips from Japan instead of from them.

		What's good for the goose is good for the gander...




--
Larry Beaulieu			beaulieu@bose.com
Bose Corporation		Phone: 508-879-1916 x6479
Framingham, MA 01701-9168	FAX:   508-820-4865	

		All flames gleefully ignored.
Newsgroups: comp.unix.pc-clone.32bit,comp.os.linux,comp.sys.ibm.pc.hardware
From: twpierce@unix.amherst.edu (Tim Pierce)
Subject: Re: 486SXs as Unix Iron?
Organization: Homosexual Fascist Lobby, Rampant Paranoia Division
Date: Fri, 6 Nov 1992 07:07:05 GMT

In article <1992Nov5.180649.3718@mksol.dseg.ti.com> mccall@mksol.dseg.ti.com (fred j mccall 575-3539) writes:
>In <Bx8DBp.CMu@unix.amherst.edu> twpierce@unix.amherst.edu (Tim Pierce) writes:
>
>>I'm not complaining; it sounds like I'm getting all of the DX power I
>>need from a machine that costs several hundred dollars less.
>
>Well, you get all that machine until you find you need a math
>coprocessor and have no good way to add one cheaply.

Assuming that I will find I need one.

>You'd have been
>better off (as would we all) if they had simply dropped the price of
>the DX parts.

But they didn't.  C'est la vie.

>>What do
>>you think the price difference is the result of -- general silicon
>>shoddiness?
>
>Arbitrary marketing decision, with no justification in cost.

Except on general ethical grounds, I don't see any reason to complain.

-- 
____ Tim Pierce                / 
\  / twpierce@unix.amherst.edu / I use antlers in all of my decorating.
 \/ (BITnet: TWPIERCE@AMHERST) / 
Newsgroups: comp.unix.pc-clone.32bit
From: kelsey@mdd.comm.mot.com (Joe Kelsey)
Subject: Re: Cacheable address range on ISA 486's
Organization: Motorola, Mobile Data Division - Seattle, WA
Distribution: na
Date: Fri, 6 Nov 1992 18:29:02 GMT

In <92Nov5.164644est.42003@ois.db.toronto.edu> fche@db.toronto.edu ("Frank Ch. Eigler") writes:
>What happens if the cache indeed has only a few address bits in its tag
>RAM, say 22 bits, but physical memory may extend above 2^22 bytes?  Are
>there boards that *don't* at least *check* the rest of the bits of CPU
>address lines, thus whose cache tag may falsely match an address above
>2^22 with one below and return the wrong data?

I don't know if I completely understand your question, but I think I
can respond by describing my situation in more detail.

Most BIOS setup programs for boards with EXTERNAL caches have some
sort of option under the ADVANCED CHIPSET SETUP menu that has
something vaguely to do with how much of the physical board address
space the EXTERNAL cache can map.  Remember, with all 486 machines,
the chip has an internal cache, so the external cache supplements
this, allowing you to buy, say, 70ns SIMM's instead of 40ns or 50ns.
The board designers have to decide how much physical memory they plan
to allow someone to use.  Early designers seem to have believed that
no one in their right mind can ever effectively use more than 16M of
physical memory.  (I encounter this attitude every time I talk to the
DOS-centric people who sell PC's.)

Thus, the first motherboard I had had 8 SIMM sockets.  I populated
bank 0 with 4M SIMM's initially.  Then, a friend offered me another
set of SIMM's at a great price, so I figured, what the heck, now I can
set up for fast page mode and run some really big X Window programs.
Unfortunately, the motherboard designers didn't fully implement the
external cache.  However, they left tantalizing traces, including an
ADVANCED CHIPSET SETUP menu option labelled MEMORY ABOVE 16M
CACHEABLE.  If you turn this option on *without* installing the extra
TAG RAM chip mentioned in the manual, when UNIX boots, it hangs almost
immediately due to getting bad data returned from incorrect cache
hits.  So a naive answer to your question:  Yes, if you go to the
trouble of setting the incorrect BIOS options, then, indeed, the cache
returns the incorrect data.

However, even with an extra TAG RAM chip installed, the system did not
work.  It turned out that I got one of the last borads in that
production run.  The new boards have a completely new layout,
including the ability to put 64M of physical memory on board (8 SIMM
sockets plus two special 16M sockets (the so-called 32-bit sockets?)).
The cache configuration options allow you to install a 64K cache which
only covers 16M address space or a 256K cache which covers up to 64M
address space (it instructs you to put different chips in the TAG
sockets for each configuration.)  The ADVANCED CHIPSET SETUP now
allows me to explicitly set any cacheable address range from 4M to 64M
in 4M increments.

Whew!  Maybe an overly long-winded answer to a seemingly simple
question?

/Joe
Newsgroups: comp.unix.pc-clone.32bit,comp.os.linux,comp.sys.ibm.pc.hardware
From: twpierce@unix.amherst.edu (Tim Pierce)
Subject: Re: 486SXs as Unix Iron?
Organization: Homosexual Fascist Lobby, Rampant Paranoia Division
Date: Thu, 5 Nov 1992 06:43:00 GMT

In article <1992Nov4.223834.9454@mksol.dseg.ti.com> mccall@mksol.dseg.ti.com (fred j mccall 575-3539) writes:

>The only way to keep
>companies from doing silly marketing cruft like this is if people let
>them eat all those chips.

I'm not complaining; it sounds like I'm getting all of the DX power I
need from a machine that costs several hundred dollars less.  That's
extra money that can go toward memory -- and you remember the problem
with memory these days, don'tcha? :-)

>There is no way
>I'm going to believe that the price difference between the 486SX and
>the 486DX can be explained by the cost of testing the math unit in the
>latter.

Maybe also the cost of junking flaky math units?  Maybe it's the money
they're losing on marketing SX chips that no one is buying?  What do
you think the price difference is the result of -- general silicon
shoddiness?

-- 
____ Tim Pierce                / 
\  / twpierce@unix.amherst.edu / I use antlers in all of my decorating.
 \/ (BITnet: TWPIERCE@AMHERST) / 
Newsgroups: comp.unix.pc-clone.32bit
From: mchen@groucho.cs.psu.edu (Michael Chen)
Subject: A few questions before I try Linux
Distribution: comp
Date: Wed, 11 Nov 1992 08:36:47 GMT

   Okay, here's the deal.  I have a 386SX/25, 4 MB RAM, a 40MB and 100MB HD,
both floppies, a Trident SVGA board, and a SB Pro.  From what I have been
reading, I should be able to run Linux just fine, but not X.  Right?
   So then, where do I get  Linux from?  (at 2400 baud?)
   Also, if I wanted to pump up the CPU power, is there any reason to choose
a 486-based motherboard over a nice, cheap 386-40?  I can't afford a 486DX-33
board, and I'm not sure at all that the 486SX is better for the amount of
money you have to pay.
   Replies by e-mail are preferred, since this group sees so much traffic that
half the time I just flush it.
--
_____________________________________________________________________________
| Michael Chen			| From the depths of our most lucid horrors |
|				| spring our fond hopes and pure desires... |
| mchen@groucho.cs.psu.edu	| except what comes from HELL! :-) 7/23/92  |
\_______________________________\___________________________________________|
Newsgroups: comp.unix.pc-clone.32bit
From: st1g9@rosie.uh.edu (Lee Preimesberger)
Subject: Re: Voice-Mail systems for SVR4 Unix
News-Software: VAX/VMS VNEWS 1.41    
Organization: University of Houston
Date: Wed, 11 Nov 1992 15:09:00 GMT

In article <1992Nov11.053103.28396@ttank.ttank.com>, karl@ttank.ttank.com (Karl Bunch) writes...
#Are there any (affordable) Voice-mail systems that will work on
#a 386/486 box running SVR4?  I would like to off my Answering service
#(Hey and even my personal Answering machine) if I could.  Something
#with one or two line capability etc. would be nice.

	Let me second that.  I know that there are relatively cheap cards for
under DOS - but has anyone made them work under their favorite U*ix?

			  Lee Preimesberger
st1g9@jetson.uh.edu ----- Undergraduate Scum ----- University of Houston, USA
         All models over 18.  Copyright (C) 1992 LP Productions.
From: eb@felix.Sublink.Org (Enrico Badella)
Newsgroups: comp.unix.pc-clone.32bit
Subject: Re: ISA Limitation?
Date: 3 Nov 92 06:53:11 GMT
Organization: Soft*Star s.r.l, Torino, Italy

In article <BwqMxn.26p@portal.hq.videocart.com> kdenning@portal.hq.videocart.com (Karl Denninger) writes:
>
>MAKE CERTAIN that your secondary cache scheme is set up to go beyond 16MB.

How do you verify?

>If you have 64KB of cache on a '486 this is almost certain to be a problem.
>If you have 256KB cache it is probably not.

What are the reasons for such behavour?

-- 
Enrico Badella				Internet: eb@felix.sublink.org
Soft*Star s.r.l.			          eb@icnucevx.cnuce.cnr.it
Via Camburzano 9			Phone:    +39-11-746092
10143 Torino, ITALY			Fax:      +39-11-746487
Newsgroups: comp.unix.pc-clone.32bit
From: kelsey@mdd.comm.mot.com (Joe Kelsey)
Subject: Re: ISA Limitation?
Organization: Motorola, Mobile Data Division - Seattle, WA
Distribution: na
Date: Thu, 5 Nov 1992 20:01:08 GMT

In <913@felix.Sublink.Org> eb@felix.Sublink.Org (Enrico Badella) writes:
>In article <BwqMxn.26p@portal.hq.videocart.com> kdenning@portal.hq.videocart.com (Karl Denninger) writes:
>>
>>MAKE CERTAIN that your secondary cache scheme is set up to go beyond 16MB.

>>If you have 64KB of cache on a '486 this is almost certain to be a problem.
>>If you have 256KB cache it is probably not.

>What are the reasons for such behavour?

The problem really doesn't have anything *directly* to do with the
size of the cache.  A smaller cache generally means fewer cache hits
and slower memory accesses.  However, the important ``cacheable
address range'' does have quite a bit to do with performance.
Remember that a cache consists of two parts: the actual cached data
(corresponding to the much-touted cache sizes referenced above) and
what people usually call the TAG, or address part of the cache which
stores the actual virtual address of the corresponding cache data lines. 

I just got through a very trying experience going from 16MB to 32MB on
my 486-33 ISA machine.  I ended up swapping out the original
motherboard for a newer version.  The old motherboard did not have a
large enough TAG CACHE to handle beyond 16M address range.  It did
have 256kB of data cache, but the TAG CACHE couldn't handle more than
16M address range.  My system booted and ran (Esix 4.0.4), but any
programs which happened to get mapped into the upper 16M (common
enough when you run a few large X Window programs (xv, emacs, etc.))
had simply *horrible* performance, since the processor had to endure
the full latency of every access to the 70ns rams!

Now, I have a new motherboard with enough TAG RAM to cache the entire
64M address range of the board and the I can really *feel* the
difference.  XV simply screams along, when it used to crawl, the mouse
responds much better, everything just runs better.

/Joe
From: shwake@nearside.UUCP (Raymond Shwake)
Newsgroups: comp.unix.pc-clone.32bit
Subject: Re: Dell SVR4 on 486DX2/50 motherboard: request for help
Date: 4 Nov 92 21:36:32 GMT
Organization: A/C International

zeke@fasttech.com (Bohdan Tashchuk) writes:

>Finally, there are a lot of semiconductor manufacturers in places like Korea
>and Taiwan, whose sole claim to fame is price. I have no problem believing
>that they sell inferior products.

	A story was related years ago (a Cringeley article in InfoWorld,
	I believe) that IBM, in the midst of a memory shortage, bought a
	few million chips or SIMMs from one of the Korean vendors just
	then entering the market. They were so dissatisfied with the
	quality, they chose not to use them, and just gave them away.
	That was the story, anyway. 

>If only U.S. logic suppliers, such as Lattice, TI, and AMD, could produce
>products that are anywhere NEAR the quality of the Japanese memory vendors.

	There are quite a number of US vendors (Motorola and Micron Tech,
	for example) who I'd stack up against the better Japanese
	vendors. Those who presume the Japanese do it right and we do it
	wrong do themselves and the quality US vendors a disservice.
-- 

uunet!media!ka3ovk!nearside!shwake			shwake@rsxtech
From: mccann@alioth.cc.nps.navy.mil (Mike McCann)
Newsgroups: comp.unix.cray
Subject: comp.graphics.avs
Summary: Cost of AVS for 8 processor Cray YMP-EL
Date: 11 Nov 92 01:12:12 GMT
Distribution: na
Organization: Naval Postgraduate School

Does anyone know the cost of AVS for an 8 processor Cray YMP-EL ?


-- 
Mike McCann                                 | Q. Why do programmers confuse
Computer Center Vis Lab, Code 51  (In-102a) |    Halloween and Christmas?
Naval Postgraduate School                   |
Monterey, CA 93943           (408) 646-2752 | A. oct31 == dec25
Newsgroups: comp.unix.questions
From: rwhelan@gmuvax2.gmu.edu (Ryan A. Whelan)
Subject: Re: Talk?
Organization: George Mason University, Fairfax, Va.
Date: Fri, 6 Nov 1992 06:02:34 GMT

In article <1992Oct30.033851.1@eagle.wesleyan.edu> triemer@eagle.wesleyan.edu writes:
>I have a very specific request:
>
>I am looking for a program that works on a unix machine that allows more than
>4 users to simultaneously type characters, having them show up at the same time
>on the other screens.  The program must also produce a line by line log file 
>of the dialogue, each line delineated by a return
>
>Has anybody out there ever modified talk to allow more than two users... that
>would be enough of a start.  I could write in the logging easily enough myself, 
>given a talk allowing more than two users.
>
>-Thomas Riemer

Use ircII.  I would set ap a very small IRC NETWORK. (One node, one ircd
running one our local machine)




-- 
Ryan A. Whelan                      "Repetition does not establish validity."
rwhelan@gmuvax2.gmu.edu                                         - Souder's Law
Newsgroups: comp.unix.questions
From: bhat@cs.columbia.edu (Dinkar Bhat)
Subject: Re: Postscript in Latex
Organization: Columbia University Department of Computer Science
Date: Tue, 10 Nov 1992 20:47:44 GMT

Sorry for the wrong posting (will post to comp.text.tex). 
But I got a lot of very helpful replies.  Thanks to one and all.

Dinkar.
Xref: sparky comp.unix.questions:13346 alt.folklore.computers:16188
From: jlowrey@skat.usc.edu (John 'Fritz' Lowrey)
Newsgroups: comp.unix.questions,alt.folklore.computers
Subject: Re: Whence Unix? (was Re: IS UNIX DEAD?) (New Thread?)
Date: 12 Nov 1992 23:36:13 -0800
Organization: University of Southern California, Los Angeles, CA
NNTP-Posting-Host: skat.usc.edu

	Folks,
	Since it is now fairly clear that text processing and/or game
playing became important uses for Unix early on.  I also seem to recall
that curses(3) was developed in part so that HACK could be made terminal
independent.
	So, a new thread perhaps: what other now-major (or was-major)
tools, operating systems, or hardware were developed for use in a 
sub-mission critical or downright frivilous application, and later
became standards far removed from the initial intent?

	My seed:
	Microsoft DOS	->	Intended as a stepping stone while DR 
				wrapped up CP/M-86, and now the program
				loader of choice for countless millions. 


-- 
        "...now it is my karmic burden         | J. "Fritz" Lowrey
         to stack cat food..."                 | Internet: jlowrey@usc.edu
Newsgroups: comp.unix.questions