HDTenEightyP/NetNews huggingface dataset:
From: evan@telly.on.ca (Evan Leibovitch)
Subject: Re: Borland InterBase on Dell or UnixWare?
Organization: Somewhere just far enough out of Toronto
Date: Mon, 14 Dec 1992 05:50:22 GMT

In article <75463@apple.apple.COM> lenoil@catalogic.com (Robert Lenoil) writes:
>The only PC UNIX that InterBase runs on is SCO. How "binary compatible" are
>the SVR4's with SCO? Can I expect to be able to run InterBase on Dell or
>UnixWare? Has anyone done this? If not, what SQL databases do people run on
>Dell or UnixWare?

For what it's worth:

I have run piles of SCO-specific binaries under ESIX (4.0.4) without
problems. The only time I have encountered problems is when trying to
run ODT binaries under ESIX's X server (a problem which has apparently
been corrected in the XFree86 server).

I have seen Borland's dBASE product run under 4.0.4. I don't imagine
there would be any problems running InterBase on Dell or UnixWare.

Borland is *not* on Univel's list of software companies doing specific
ports of their products to UnixWare, but this does not necessarily
mean they're not doing so, or that a specific port for R4 is required.

As for other SQL databases running under R4, that means most of them. I
have personally run Progress, Informix and Empress under ESIX without
any problems at all, all of which have rather full implementations of SQL.

-- 
 Evan Leibovitch, Sound Software Ltd., located in beautiful Brampton, Ontario
         evan@telly.on.ca / uunet!utzoo!telly!evan / (416) 452-0504
         "IBM's three letters are probably EBCDIC for CYA" - Nik H.
From: shwake@nearside.UUCP (Raymond Shwake)
Newsgroups: comp.unix.pc-clone.32bit
Subject: Supporting *BIG* Drives <was: Adaptec 1742A on ISC-3.0>
Date: 17 Dec 92 04:51:25 GMT
Organization: A/C International

david@twg.com (David Herron) writes:

>- The Interactive install stuff is unable to talk to a 1742 in
>  its enhanced mode.  (The chart on page 113 doesn't list aha1740
>  as a possibility).

>- Therefore the card *must* be put in compatibility mode to do
>  the installation.

>- When it's in compat mode it must be accessed via the I/O addresses.
>  The only possible value for the addresses is listed in the chart.

	Could you post those settings? We've attempted to run ISC 3.0
	with an Adaptec 1740/42A with a humongo 2.1 GB Seagate. Installation
	goes fine, can even choose the SHELL option during initial setup.
	After rebooting, we see:

		Can't find Active Partition on HD.

	That, by the way, was the same problem after attempting to load
	USL's SVr4.2. Both attempts involved standard mode. Can standard
	mode simply not *handle* such a large drive? (Drive parameters show
	during installation that we are dealing with 2,030 logical cylinders,
	but since it also says we have 64 (sic) heads, we're probably dealing
	with logical mapping.)
-- 

uunet!media!irscscm!nearside!shwake			shwake@rsxtech
Newsgroups: comp.unix.pc-clone.32bit,comp.unix.misc,gnu.misc.discuss
From: keith@ksmith.uucp (Keith Smith)
Subject: Re: Bill Gates & Microsoft BASIC etc.
Organization: Keith's Computer, Hope Mills, NC
Date: Mon, 21 Dec 92 03:14:52 GMT

In article <9212060137.36@rmkhome.UUCP> rmk@rmkhome.UUCP (Rick Kelly) writes:
>
>And as I remember, the IBM PC required 128k for DOS, although it may have
>been 64k.

Uh, Yes, and yes.  As the proud maintainer of >20 IBM PC's (*NOT* XT's
PC's with Cassette ports).  The PC will run DOS 1.X (The broken version)
with 64K.  DOS 2.0 Seems to require 128K to do anything useful.  DOS 3.0
will not BOOT without 128K.

P.S. And we are finally replacing them with 486/33's <SIGH>.  From the
ridiculous to the sublime.
-- 
Keith Smith          uunet!ksmith!keith            5719 Archer Rd.
Digital Designs      BBS 1-919-423-4216            Hope Mills, NC 28348-2201
Somewhere in the Styx of North Carolina ...
Newsgroups: comp.unix.pc-clone.32bit,comp.unix.sysv386,comp.unix.bsd,comp.os.linux
From: roell@informatik.tu-muenchen.de (Thomas Roell)
Subject: Re: ET4000/W32 and VESA VL-Bus
	<1992Dec17.190542.2662@utagraph.uta.edu>
	<1992Dec18.095906.3950@Informatik.TU-Muenchen.DE>
	<1992Dec18.185612.10836@netcom.com>
Organization: Inst. fuer Informatik, Technische Univ. Muenchen, Germany
Date: Sun, 20 Dec 1992 14:30:35 GMT

>All XS3 published benchmarks are run at 1024x768 clocked at higher
>than 60 Hz. I obtained the results from netters because I don't
>own a high resolution monitor. During candid, e-mail exchange I do
>state my own benchmarks. In the future I will state the clock 
>frequency and the resolution.

In fact nobody accused you that you posted illegaly tuned benchmarks
by using the lowest possible resolution. As it happens this wasn't the
question. 

Normally what you get as benchmarks is material published by the
vendors (how have no interest of showing any weakness of their own
product) or magazines, which are largely DOS/Windows based, and hence
try to find the least common resolution between boards. Until recently
this was either 640x480 or 800x600. And in these lower resolutions you
simply cannot see this problem described with DRAM vs. VRAM that
clearly. If you then think about the fact that most people using X do
1024x768 in the highest possible refresh rates, these benchmarks are
pretty much meaningless (besides the fact that they are mostly measure
with drivers that were tuned especially for MS-Windows and some
benchmarks, who are very easy to fool). As far as I know up to now no
HW vendor yet publicates the XS3 xstones rating for his board ... They
are mostly not intrested in X-Windows as much as they are interested
in MS-Windows.

And one thing people shoudln't forget this that there are two new
developements in the market:

	a) people are starting to use 1280x1024 (110MB/sec)
	b) chips using 64 DRAM buses start to appear

But still VRAM will have a speed advantage over DRAM. And if the price
difference is that inferior as $50, one should really think about it.

- Thomas


--
-------------------------------------------------------------------------------
Das Reh springt hoch, 				e-mail: roell@sgcs.com
das Reh springt weit,				#include <sys/pizza.h>
was soll es tun, es hat ja Zeit ...
Newsgroups: comp.unix.pc-clone.32bit
From: wayne@backbone.uucp (Wayne Schlitt)
Subject: Re: idea for non-cached mem above 16M (was Which motherboard?)
Organization: The Backbone Cabal
	<WAYNE.92Dec16112648@backbone.uucp>
	<1992Dec16.215109.27531@klaava.Helsinki.FI>
Date: Fri, 18 Dec 1992 15:11:52 GMT

In article <1992Dec16.215109.27531@klaava.Helsinki.FI> torvalds@klaava.Helsinki.FI (Linus Torvalds) writes:
> 
>                                                                (thus you
> automatically get the best performance if you do the "swapon"s by how
> fast the device is: first ramdisk, then disk partition and then
> swapfile).

maybe I am confused, and I am _sure_ you know the details of linux
better than I do, but will this really get you the best performance?

the performance depend greatly on which device your program ends up on
and wouldn't that just depend on when your program was created, not
how frequently it is used?


The reason why you need a second level of "VM" is to migrate
frequently referenced pages to the fastest swap device.

> 
>                            I'd still rather not [ use a ram disk ], as it's
> pretty stupid to start swapping before you really run out of memory. 

well that depends on how much that page is referenced before it is
paged back to the ram disk swap file.  Each reference to an uncached
page is going to be real slow.  (it may even prevent 486's from
caching it in internal cache too, I am not sure.)  If have a loop or the
top of stack in this uncachable region, your system is going to run
much slower than if you spent the time to paged it into the fast
memory.


I mentioned implementing a second level of VM, because it sounds like
it would be useful to you immediately, and after you get it done, it
would still be useful for migrating pages to faster/less active disks.
(i.e., in the long run, your time wouldn't be wasted...)



-wayne
Newsgroups: comp.unix.pc-clone.32bit,comp.unix.sysv386
From: someone@Texaco.com (Larry D. Pyeatt)
Subject: Re: PC-Clone UNIX Hardware Buyer's Guide
Organization: Texaco
Date: Sun, 20 Dec 1992 22:34:22 GMT

In article <id.5DYV.RM8@ferranti.com>, peter@ferranti.com (peter da silva) writes:
|> In article <1992Dec17.203324.1227@texhrc.uucp> pyeatt@Texaco.com (Larry D. Pyeatt) writes:
|> > In article <id.D5VV.O87@ferranti.com>, peter@ferranti.com (peter da silva) writes:
|> > |> I'd take a system with 16M and no FPU over 8M and an FPU any day.
|> 
|> > I think I would go the other way around, ( 8M and an FPU over 16M without
|> > one ) but that is because I need the 1000% speedup that the FPU will give
|> > me.
|> 
|> Let me guess... seismic analysis?

Not on a Puny Computer, but I do run some neural network simulations,
LaTeX, simulated annealing, and other FPU pigs.  A PC with an FPU does
reasonably well for these types of tasks, as long as you are not in
a big hurry. ;^)

|> 
|> You need to check out your news configuration. Your address comes out as
|> "someone@texaco.com".

I know, I've been chasing a bug in xrn.  Thought it was related to that 
piece of code.  I'm still looking. 8^{

p.s. I liked your previous signature.  I was amazed that it actually 
drew something.

-- 
Larry D. Pyeatt                 The views expressed here are not
Internet : pyeatt@texaco.com    those of my employer or of anyone
Voice    : (713) 975-4056       that I know of with the possible
                                exception of myself.
Newsgroups: comp.unix.pc-clone.32bit
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Subject: Re: idea for non-cached mem above 16M (was Which motherboard?)
Organization: University of Helsinki
Date: Wed, 16 Dec 1992 21:51:09 GMT

In article <WAYNE.92Dec16112648@backbone.uucp> wayne@backbone.uucp (Wayne Schlitt) writes:
>
>well, it really shouldn't be toooo hard or kludgy to implement.  "just"
>create a RAM disk driver, and fix it so that it allocates the
>uncacheable memory.  Then, put the swap drive on the RAM disk.
>
>(I don't know Linux well enough to know how easy this would be to do,
>what restrictions there are on the swap drive, etc...  just an
>idea...)

Several people have mentioned the RAM-disk idea, and yes, it would be
very simple indeed, as linux already has a ramdisk option - right now it
gets its memory from the low end of the 1M+ area, but changing it to use
the high addresses would be very easy indeed.  I never use it, though,
as I find ramdisks generally silly (but it's useful at installation-time
when you don't have a ready-made filesystem etc, and some people seem to
perfer to have a ramdisk). 

After you've created the ramdisk, swapping to it is as easy as saying
"mkswap /dev/ram <size> ; swapon /dev/ram".  And the linux swapping
routines can already handle multiple devices (or multiple swapfiles, or
any combination of these), so after one device (the ramdisk) fills up,
the swapping algorithms automatically use the next swap-device (thus you
automatically get the best performance if you do the "swapon"s by how
fast the device is: first ramdisk, then disk partition and then
swapfile). 

So it would be pretty simple, actually, to do a reasonable 2-level VM
thing under linux to handle this, but I'd still rather not, as it's
pretty stupid to start swapping before you really run out of memory. 
SO, to the questions at last: does anybody have any info on the 82C591 /
82C592 chipsets (called Contaq1 and Contaq2 in the MB manual, which
isn't exactly technical)? It would be appreciated. 

		Linus
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.unix.pc-clone.32bit
Subject: Re: idea for non-cached mem above 16M (was Which motherboard?)
Date: 17 Dec 92 21:04:03 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY


  It seems to me that if an area of memory is not able to do io as
quickly as other areas of memory, that the shared libraries and sharable
code segments are the obvious first things which should go into those
areas. After that data segements can be mapped.

  There is a tiny one-time penalty to move the shared library to the
slow io region, none for using it there. This is also true of code
segments, and of course they are deallocated rather than swapped out.

  Since the machines which have limited ability to DMA memory are also
the systems which are most likely to use disk controllers which don't do
bus master access, and file io is usually done through the system
buffers anyway, the penalty is not nearly as severe as might be
expected, *providing* that the os doesn't do stupid things like placing
io buffers in those regions.

  I would certainly hope that any os which runs on systems which allow
that type of memory organization should put ramdisk high, then shared
libraries, then code, and load the data segments of programs into the
areas which are always fast. This results in a very low penalty compared
to allocating memory in some LRU or bottom up algorithm.

  This certainly applies to Linux, since it has been very responsive to
easy improvements in the past, but also to other operating systems.

  Note: if you have a commercial UNIX, an EISA bus, and >16MB, do check
that you have told the os the high memory will do io (usually in
/etc/default/boot as I recall).
-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
    Keyboard controller has been disabled, press F1 to continue.
From: shwake@nearside.UUCP (Raymond Shwake)
Newsgroups: comp.unix.pc-clone.32bit
Subject: Re: Dell support?
Date: 16 Dec 92 13:51:20 GMT
Organization: A/C International

richard@pegasus.com (Richard Foulk) writes:

>Some time back there was a rumor that a number of the more important
>Dell support folks were let go or something.  I don't remember hearing
>anything more about this and was wondering what actually happened, if
>anything.

	According to my sources, some of the Dell UN*X crowd have gone
	over to Information Foundation in Denver, CO.

>What's the current status of support and development for Dell Unix?

	Don't know, except that Dell seems to be moving toward Solaris,
	rather than SVr4.2.
-- 

uunet!media!ka3ovk!nearside!shwake			shwake@rsxtech
Newsgroups: comp.unix.pc-clone.32bit
Subject: Re: idea for non-cached mem above 16M (was Which motherboard?)
From: clem1040@nova (clemens jeffrey )
Newsgroups: comp.unix.pc-clone.32bit
Subject: 386bsd and i860
Date: 13 Dec 92 20:01:37 GMT
Organization: University of Michigan EECS Dept., Ann Arbor, MI
X-Newsreader: Tin 1.1 PL3

i was wondering if anyone knows of a c compiler which works under 386bsd and
supports the intel i860 risc processor.  i was looking into a hauppage 4860
pc or a 486 with an i860 coprocessor card....and was wondering about that...
i figure, if you recompile the kernel and all the apps with the a compiler
that supports the 860, you could get workstation or better performance out
of this type of system..... any general comments??
-Jeff
Newsgroups: comp.unix.pc-clone.32bit
From: someone@Texaco.com (Larry D. Pyeatt)
Subject: Re: idea for non-cached mem above 16M (was Which motherboard?)
Organization: Texaco
Date: Tue, 15 Dec 1992 16:47:26 GMT

In article <1992Dec14.231244.22459@klaava.Helsinki.FI>, torvalds@klaava.Helsinki.FI (Linus Torvalds) writes:
|> In article <17543@umd5.umd.edu> mark@roissy.umd.edu (Mark Sienkiewicz) writes:
|> >In article <1992Dec11.150512.21282@texhrc.uucp> someone@Texaco.com (Larry D. Pyeatt) writes:
|> >>I recently saw an IBM clone with 32M RAM and 256K cache running OS2.  We
|> >>ran several benchmarks and it was blazingly fast whenever the program was
|> >>loaded in the lower 16M.  However, when the program was loaded in the 
|> >>uncacheable upper 16M, performance dropped to about 25% of what it was.
|> >>This had nothing to do with DMA.  We finally took out the upper 16M and
|> >>the machine now provides better average performance than when it had 32M.
|> 
|> First off, I can verify that this is true at least with some
|> motherboards: I've had reports of similar things happening, and when I
|> upgraded to 20MB I saw it myself.  The performance drop was more than an
|> order of magintude in the worst case (ie when a process got only pages
|> in the 16MB+ area, it slowed down *a lot*: dhrystone went from 12 secs
|> to two minutes). 
|> 
|> The problem seems to be caching: the 16MB+ area doesn't get cached at
|> all for some reason.  I've had reports of it being cahce-size dependent,
|> and that some motherboards need more than 64kB cache to handle the upper
|> memory areas.  I'm waiting for my 256kB cache to find out. 

I think ( but am not sure ) that the problem is in the cache controller
chip.  I think that some of the cache controllers out there only have
24 address lines going to them, just like the ISA bus only has 24 address
lines.  This would make it impossible for the cache to access any memory 
above 16M. Using one of those controllers, the memory could be set up 
like this:

-----            -------            ----------------
|   |----------->|     |----------->|              |
|   |  A0 - A23  |CACHE|  A0 - A23  |              |
|   |            |     |            |              |
|   |<---------->|     |<---------->|    Memory    |
|CPU|  D0 - D32  -------  D0 - D32  |              |
|   |                ^              |              |
|   |             -----------       |              |
|   |------------>|TTL Glue |------>|              |
|   | A24 - A25   -----------       |              |
-----                               ----------------

This would give you a maximum of 64M, but only the first 16M would
be cacheable.

Please let me know what happens when you put in the 256K cache.
Thanks.

-- 
Larry D. Pyeatt                 The views expressed here are not
Internet : pyeatt@texaco.com    those of my employer or of anyone
Voice    : (713) 975-4056       that I know of with the possible
                                exception of myself.
Newsgroups: comp.unix.pc-clone.32bit,comp.unix.sysv386
From: someone@Texaco.com (Larry D. Pyeatt)
Subject: Re: PC-Clone UNIX Hardware Buyer's Guide
Organization: Texaco
Date: Thu, 17 Dec 1992 20:33:24 GMT

In article <id.D5VV.O87@ferranti.com>, peter@ferranti.com (peter da silva) writes:
|> There's this thing called a "budget". If you have X dollars to spend on a
|> system, it's a lot more cost effective to put those dollars into RAM and
|> disk than an FPU until X gets pretty big. I'd take a system with 16M and
|> no FPU over 8M and an FPU any day. Hell, dumping the FPU saves most of the
|> cost of a tape drive... another line item I'd put in before an FPU. Unless
|> you do a LOT of floating point, the FPU is about as useful as string of
|> christmas lights.

I think I would go the other way around, ( 8M and an FPU over 16M without one )
but that is because I need the 1000% speedup that the FPU will give me.  I have
a hard time waiting for 9 hours for a program to finish.  I would hate to have
to wait for 90 hours.  Mileage may vary.

|> It's like buying a caching disk controller... until you run out of slots
|> on the motherboard, you're better off buying a dumb controller and adding
|> RAM.

I can't argue with that!

-- 
Larry D. Pyeatt                 The views expressed here are not
Internet : pyeatt@texaco.com    those of my employer or of anyone
Voice    : (713) 975-4056       that I know of with the possible
                                exception of myself.
Newsgroups: comp.unix.pc-clone.32bit,comp.os.linux,comp.unix.bsd,comp.windows.x
From: vagarwal@dis9002.shearson.com (Virendra Agarwal)
Subject: Re: Will Linux/386BSD/XFree86 run on my Gateway 2000 4DX2-66V?
Reply-To: vagarwal@tardis.shearson.com
Organization: Lehman Brothers
Date: Fri, 18 Dec 1992 16:43:52 GMT

In article <1992Dec8.045541.28069@starbase.trincoll.edu> friedman@starbase.trincoll.edu (Mark A. Friedman) writes:

   Xref: shearson.com comp.unix.pc-clone.32bit:684 comp.os.linux:18826 comp.unix.bsd:9518 comp.windows.x:59335
   Newsgroups: comp.unix.pc-clone.32bit,comp.os.linux,comp.unix.bsd,comp.windows.x
Path: shearson.com!uunet!spool.mu.edu!yale.edu!news.yale.edu!yar.trincoll.edu!friedman
   From: friedman@starbase.trincoll.edu (Mark A. Friedman)
   Sender: usenet@starbase.trincoll.edu (SACM Usenet News)
   Organization: Trinity College, Hartford, CT.
   Date: Tue, 8 Dec 1992 04:55:41 GMT
   Lines: 56


   I am considering the purchase of a Gateway 2000 4DX2-66V system
 
>>   (Micronics motherboard, 8MB RAM to be expanded to 16MB, VESA VL-Bus,

   I thought that it was expandable to 64MB on motherboard !!!
-----------------------------------------------------------------------
By the way I was also considering to buy the same system from Gateway but have 
not made decision. Also, do you know if Seagate ST225 Hard drive can be added to
this system. I would like to take ST225 from my PC/XT and use it if possible.
------------------------------------------------------------------------------


   -- Mark

   Mark A. Friedman		 	 mark.friedman@mail.trincoll.edu
   Engineering and Computer Science	 (or friedman@starbase.trincoll.edu)
   Trinity College				 Phone: (203) 297-2519
   Hartford, Connecticut   06106		 Fax: (203) 297-2569

----------------------------------------------------------------------------

-- Virendra Agarwal

--
---------------------------------------------------------------
Virendra Agarwal
vagarwal@shearson.com
212-464-2151
Lehman Brothers
388 Greenwich st.(9th Flr.)
NewYork, NY 10013
---------------------------------------------------------------
Newsgroups: comp.unix.pc-clone.32bit
From: zbig@wariat.org (Zbigniew J. Tyrlik)
Subject: Re: Need SCO XENIX and PC Hardware help
Followup-To: comp.unix.pc-clone.32bit
Reply-To: zbig@wariat.org (Zbigniew J. Tyrlik)
Organization: Akademia Pana Kleksa, Public Access Uni* Site
Date: Mon, 14 Dec 1992 22:47:49 GMT

As quoted from <1992Dec12.233700@aminet.uucp> by barrett@aminet.uucp (Keith Barrett):

+---------------
> I recently bought a complete XENIX V2.3.2 kit from a friend. This is the
> 386AT kit, but I currently have a 286AT, so I'm planning to
> upgrade my system and have some questions.

Why ??? :)



> I guess I'm basically asking for configuration help in running this older
> package on more modern equipment. My end-goal is to buy a 25-66mhz 386/486
> system with 300+meg disk, SCSI tape and CD, ethernet, and be able to
> run SCO XENIX, MS-DOS/Windows, and Windows-NT.


You can get free Linux of BSD386, nad have a heck lot more of fun
with both packages - X windows, TCP/IP, NFS ( with bsd386 ), etc,
not to mention sources... Great learning tool. 

If you want NT, Unix, Dos on one HD - get biger one, especially if
you will start playing with sources or news....


> 
> 
> -- 
> -kgb
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> UUCP: nuconvex.com!aminet!barrett             Keep circulating the tapes - MST3k
> DDN: barrett%aminet.uucp@decwrl.dec.com    // My life is my own - the prisoner
> Alternate: barrett@pamsrc.enet.dec.com   \X/  Amiga 3000UX - The Next Generation
> --------------------------------------------------------------------------------


_zjt
-- 
********************************************************************
Zbigniew J. Tyrlik       DoD# 0759   VF700C '84      zbig@wariat.org
IBM PC SIG Sysop - Cleveland Free-Net    aa609@cleveland.freenet.edu
APK	       Public Access UNI* Cleveland,          (216)-481-9436
Feeds, shell, FTP & telnet access        Uniboard distribution point 
********************************************************************
Newsgroups: comp.unix.pc-clone.32bit