HDTenEightyP/NetNews huggingface dataset:
From: sl@wimsey.bc.ca (Stuart Lynne)
Subject: Re: Unix: Cacheing EISA SCSI vs. Non-cacheing EISA SCSI Controllers
Organization: BC News and Mail
Date: Tue, 13 Oct 1992 08:10:33 GMT

In article <BvwxGt.4q8@maxed.amg.com> ed@maxed.amg.com (Ed Whittemore) writes:
>In article <1992Oct10.095013.27560@cbnews.cb.att.com> memanuel@cbnews.cb.att.com (mark.emanuele) writes:
>>In article <Bvuqrw.AG@gator.rn.com> larry@gator.rn.com (Larry Snyder) writes:
>>
>>Am I missing something here? What about the ONBOARD CPU on the caching 
>>controller? Does it not releive the system CPU from the duties of managing the disk drives, leaving it free to do other work ?
>>
>Yes, you are missing something. :) The non-cacheing boards also have
>ONBOARD CPUs which relieve the system CPU. In fact, that's another point
>in favor ov the Adaptec and BusTek boards--LOWER OVERHEAD. The DPT board
>shows (using u386mon, et. al.) more rather than less overhead than the
>Adaptec or BusTek boards.

It is an axiom that unless you are already using the fastest CPU available
in your main system, the cheapest way to buy more CPU cycles is to buy a
faster processor for it. You will able to use the CPU cycles for more than 
just I/O as well. 

This does not hold true if you already have the fastest CPU available and
it's running at full speed *and* the I/O processor can do the job fast
enough. 

-- 
Stuart Lynne <sl@wimsey.bc.ca> ....................... UNIX Facsimile Software
Wimsey Information Technologies ................... moderator biz.sco.binaries
uucp login:nuucp passwd:nuucp .................. ftp.wimsey.bc.ca:~ftp/ls-lR.Z
PD Software for SCO UNIX .................. ftp.wimsey.bc.ca:~ftp/pub/wimseypd
Xref: sparky comp.unix.sysv386:15515 comp.unix.sys5.r4:221
From: jack@admin.mport.COM (Jack Craig)
Newsgroups: comp.unix.sysv386,comp.unix.sys5.r4
Subject: Re: Viper 2525S on SVR4.0.4?
Date: 12 Oct 92 19:49:46 GMT
Followup-To: comp.unix.sysv386
Organization: Microport Inc., Scotts Valley, CA 95066 US of A

just a thought, you might try using the tapectl cmd to examine/set
the block size. the stock usl drivers like their devices to be 512/b/blk
and choke if not. the original tapectl cmd used the -f switch to 
set the fixed block size to 512. my dat powers up to 1024b/blk so
i have to do this chore until i get the time to fix the driver.
it may or may not help you.

jack...
=============================================================================
 Jack Craig  Microport         SVR4 408-438-UNIX   uunet!mport.com!jack
             Software Horizons SVR3 408-684-1375   uunet!sco.com!blznrzn!jack
=============================================================================
From: marrevola@iris-dcp.es
Newsgroups: comp.unix.sysv386
Subject: Re: Colorado Jumbo250 tape drivers for SCO.
Date: 8 Oct 92 14:38:57 GMT
Organization: REDIRIS, Red Nacional de I+D

In article <1992Oct07.113848.9675@vpnet.chi.il.us>, lisbon@vpnet.chi.il.us (Gerry Swetsky) writes:
> In article <1992Oct5.135131.71@iris-dcp.es> marrevola@iris-dcp.es writes:
>>FTP site for Colorado Jumbo250 tape backup under SCO Unix System V?
> 
>     As I recall, they SELL those drivers - at least they used to!
> 
>     Be very careful before you post these to an ftp site!
> 
> --
> ============================================================================
> | Help stamp out stupid .signature files!           Gerry Swetsky  WB9EBO  |
> |                 vpnet - Public access Unix and Usenet                    |
> | Home (708)833-8122       vpnet (708)833-8126      lisbon@vpnet.chi.il.us |
> ============================================================================

Yes??????!!!!

Thanks a lot.
Next time I'll be very carefull but, do many people use a 250 MegaByte backup
system for DOS?
Xref: sparky comp.unix.sysv386:15649 comp.unix.sys5.r4:263
From: peter@ferranti.com (peter da silva)
Newsgroups: comp.unix.sysv386,comp.unix.sys5.r4
Subject: Re: xboard-2.0.tar has been uploaded to US4BINR
Date: 15 Oct 92 15:13:40 GMT
Organization: Xenix Support, FICC

In article <1992Oct14.160023.19214@SSD.intel.com> richardg@ssd.intel.com (Richard Griffiths) writes:
> In article <Bw438L.80x@gator.rn.com>, larry@gator.rn.com (Larry Snyder) writes:
> |> Aren't these postings getting rather old?
> No.

Well, I disagree. They're getting rather old. How about a simple periodic
posting every month or so (maybe every week at first) with everything that's
been posted so far.
-- 
Peter da Silva                                         `-_-'
Ferranti Intl. Ctls. Corp.                              'U` 
Sugar Land, TX  77487-5012           "Heeft u vandaag al uw wolf geknuffeld?"
+1 713 274 5180                       "Tjener, denne ret er stadig levende."
Newsgroups: comp.unix.sysv386
From: larry@gator.rn.com (Larry Snyder)
Subject: Re: Problems with Dell v2.2
Organization: The Gator Conferencing System 219-289-3745 
Date: Tue, 13 Oct 1992 18:31:29 GMT

kdenning@portal.hq.videocart.com (Karl Denninger) writes:

>Isn't "ttcompat" supposed to be pushed too on those streams?

yes -- here is what I have in /etc/ap/*

66	-1	0	ldterm
5     -1       0        char ansi ldterm ttcompat
3     0        131      ldterm ttcompat

-- 
Larry Snyder                                    internet: larry@gator.rn.com
keeper of the Gator                                  uucp: uunet!gator!larry
Newsgroups: comp.unix.sysv386
From: mark@mark-one.inet-uk.co.uk (Mark Powell)
Subject: Problems with Dell v2.2
Organization: Mark-One Public Access UNIX (+44 942 273926)
Date: Sun, 11 Oct 1992 21:37:51 GMT

Got a problem. Installed Dell v2.2 and the drivers for my Specialix SI-8
by hand (the pkgadd install disk didn't work.) Now ttymon complains that
it cannot allocate a controlling tty on any port on the card. Changing
this with uugetty allows a user to login, but ps -f shows that they have
no controlling tty. 
  I've gone back to the v2.1 kernel and drivers, but this makes no difference.
Where apart from the kernel could such a problem be?
Thanks in advance for any help.

BTW the permissions are correct on these files.
    When a user does login on v2.2 kernel the terminal is severely messed up.
    Seems like the problem when something such as icrnl has been turned off
    but it isn't. Changing back to the v2.1 kernel seemed to fix this???

Also, xdvi dies just after start-up with the message "IO signal" ?? Anyone
know why this is?
-- 
Mark Powell

mark@inet-uk.co.uk		v32bis news and mail feeds available
ibmpcug!jshark!mark-one!mark	email for details
From: sten@EINSTEIN.WD.ESTEC.ESA.NL (Sten Ekholm)
Newsgroups: comp.unix.sysv386
Subject: SLIP
Date: 7 Oct 92 09:33:37 GMT

Hi,

I am looking for advice on the following problem: I would like to use
SLIP between two Dell unix boxes. That in it self is of-course no problem as
SLIP is included with Dell Unix. The problem is that one of the modems are
connected to the computer via a local area terminal network. This network uses
XON XOFF for flow control and a few other control characters (^G^H) to get
to the network main menu. This means that every time one of these control 
characters are present in the data stream the connection hangs. Is there a
way to map these control characters to some other characters using the normal
SLIP? My understanding is that PPP has such a mapping facility, but I have not
yet been able to find a version that runs under SVr4.
-- 
Sten Ekholm              	Internet:	sten@einstein.wd.estec.esa.nl
European Space Agency		Span:		ESTCS1::SEKHOLM
Estec - The Netherlands		Voice:		+31 1719-83620
Newsgroups: comp.unix.sysv386
From: mat@mole-end.matawan.nj.us
Subject: DX2 Upgrades: Anyone try it?
Organization: :
Date: Wed, 7 Oct 1992 22:03:17 GMT

Has anyone upgraded an existing UNIX with a clock-doubled chip?  Did
it `plug-and-play' or were there problems?
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile

 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
Newsgroups: comp.unix.sysv386
From: shane@cs.sunysb.edu (Shane Bouslough)
Subject: Re: USL's SVR4.2, when?
Organization: Dept of Computer Science, State U of NY at Stony Brook
X-Newsreader: Tin 1.1 PL5
Distribution: comp.unix.sysv386
Date: Wed, 14 Oct 1992 17:27:34 GMT

Chin Fang (fangchin@leland.Stanford.EDU) wrote:

: In article <2ADAD15A.31A5@telly.on.ca> evan@telly.on.ca
:	(Evan Leibovitch) writes:
: 
: >Few people are going to have home machines which will have the
: >horsepower necessary to run OS/2 or UNIX or NT. If they truly want a
: >totally compatible system at work, they'll choose the lowest common
: >denominator and use DOS5 at work too.
: 
: There are lots engineers *DO* use MSDOS and Windoz.  However, IMHO,
: it's because they haven't educated 'emselves enough of the power of
: UNIX.  The price they pay for staying so ignorant is that they
: often have to gone thru all kinds of kludgy ways to accomplish their
: tasks. 

I think this is a little harsh. BTW, "the price *you* pay" for UNIX
is an order of magnitude more $$$ for software. I suppose you don't
care if your boss is paying for it, but as NT is MS' successor to DOS,
it's aimed at home machines too. Most people won't pay the price for
UNIX apps, that may be NT's biggest edge. Let's hope UNIX software
vendors wake up and smell the coffee.

: Chin Fang
: fangchin@leland.stanford.edu

-Shane

--
Shane Bouslough       | #include <stddisc.h>
shane@sbcs.sunysb.edu | #include <happy.rhodes>
Newsgroups: comp.unix.sysv386,comp.unix.sys5.r3
From: marcf@nexus.yorku.ca (Marc G Fournier)
Subject: marking bad blocks on ISC SVR3.2...URGENT HELP NEEDED
Organization: York University, CS Dept. Toronto
Date: Sun, 11 Oct 1992 23:46:35 GMT

Hi Folks...

	Just installed two ESDI hard drives onto my system,
they are used and there are prone to bad blocks...I expected
it, so that isn't the worry.

	The problem is marking these bad blocks so that the OS
doesn't try and repeatedly use them.  

	Looking through the manuals (after looking at the
sysadmin script), I *thought* that I could use mkpart -A <sector>
to mark it, but I get an error back on that...

	Warning: No root partition, no boot written

	The syntax I am using is 'mkpart -A <sector> disk1'

	Is there something that I am missing with this?  I take
it that the 'no boot written' refers to /etc/boot?  Should my
syntax be something like 'mkpart -A <sector> -B/etc/boot disk1'

	This is on a second harddrive, so why would it be looking
for a root partition?

Any help is greatly appreciated...

Marc
Xref: sparky comp.unix.sysv386:15561 comp.unix.sys5.r4:235
From: bad@flatlin.ka.sub.org (Christoph Badura)
Newsgroups: comp.unix.sysv386,comp.unix.sys5.r4
Subject: Re: New ESIX 4.0.3 User Questions
Date: 13 Oct 92 22:43:22 GMT
Organization: Guru Systems/Funware Department

In <1992Oct12.034407.1689@weyrich.UUCP> orville%weyrich@uunet.uu.net (Orville R. Weyrich) writes:

>1) FAS -- Is it useful for ESIX 4.0.3? I certainly liked it for Microport.

You must apply the fubyte patch for FAS to work. Either look in the
buglist of Eric Raymonds FAQ or get a fix from ESIX.

>	I have also heard something about  SAS. Is this useful for my ESIX?

SAS 2.0 is to be release real soon now. FAS is available from
ftp.fu-berlin.de


>2) File systems -- I have a choice of S5, S52K, and UFS.

Just use UFS. The S5 types have no advantages over UFS type file systems.

-- 
				Christoph Badura  ---  bad@flatlin.ka.sub.org

AIX is a better... is a better...  is a better... OpenSystem.
					IBM Rep at GUUG Symposium '92
Newsgroups: comp.unix.sysv386
From: ed@maxed.amg.com (Ed Whittemore)
Subject: Re: Unix: Cacheing EISA SCSI vs. Non-cacheing EISA SCSI Controllers
Organization: American Micro Group, Ft. Lee  NJ
Date: Fri, 16 Oct 1992 14:41:37 GMT

In article <1992Oct15.231111.28896@PacBell.COM> j4jbail@srv.PacBell.COM (Jack Bailey) writes:

...

>
>Getting back to cost, one could argue that the labor involved in
>fine-tuning a large system may be more expensive than dropping in
>hardware.  Figure the costs incurred if you were to hire yourself
>to bring the system to peak performance.  Now as you add more
>serial ports, more network connections, and more applications,
>consider the expense of retuning the system.  That cacheing
>controller may not be so expensive after all.
>
>-- 
>J.J.Bailey	j4jbail@srv.pacbell.com
>Contractor	510.823.6453

In many cases the cost of a cacheing controller is more than  or about
the same as the cost of a new motherboard that accommodates more
memory, especially now that boards using 16 MB simms are out, and the 
prices of these simms are level with 4 MB simms.

I can see some place for a cacheing controller ( not too much! ), but
far too often it is the lazy way of throwing dollars after better, but
not great performance.

Tuning a system, with a little experience, is simply the very quick
alteration of a few parameters, remaking the kernel, maybe adding a few
simms, and rebooting. That's it. It's not like it's some arcane, time-
consuming trial-and-error process.

It is true that the cacheing board off-loads the protocol of having to
think about what you're doing from your CPU! Maybe that's worth 
something! :)

-- 
Ed Whittemore   uunet!maxed!ed   ed@maxed.amg.com
American Micro Group, Inc.   201-944-3293
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.unix.sysv386
Subject: Re: Wangtek or Archive?? (and 60 MB tapes)
Date: 12 Oct 92 18:50:58 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <Bvssyz.L2y@virtech.uucp>, cpcahil@virtech.uucp (Conor P. Cahill) writes:

| If 3M thought it was enough of a problem to put a written warning on
| each and every tape that they sell, I would say that the problem is much
| more than a "rumor".

  Maybe. If they heard the rumor it's cheaper to add a disclamer than
see if the problem exists, and their lawyers probably like the idea
better. Note that I'm not saying there's a problem, it's just that in a
world where a burglar can sue because the skylight he fell though didn't
have a "do not crawl on this window" sign, even the slightest hint of a
problem will bring a disclamer.

-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
    Keyboard controller has been disabled, press F1 to continue.
Newsgroups: comp.unix.sysv386
From: dror@netcom.com (Oz Dror)
Subject:  Xfree86 (1.1) and ET4000 video board reset
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Thu, 8 Oct 1992 06:42:43 GMT

I was finally able to compile Xfree86 for SCO unix (ODT 1.1, UNIX 3.2.2)
But when I leave X386. The video board is getting out of sync.
This can only be fixed by rebooting the system.

I have a local video bus (H-Host4000, et4000 chip).

Does any one have any Idea. I thought that Xfree86 (1.1) was supposed to solve
this problem. The card works fine for X11R4 (When I use dot clocks that
are half the calculated ones).

Xfree86 was compiled with gcc 2.2.2 (-m486 -O2)


-- 
NAME   Oz Dror
SMAIL  dror@netcom.com
Newsgroups: comp.unix.sysv386
From: stuart@coral.cs.jcu.edu.au (Stuart Kemp)
Subject: WANTED: tcsh and GNU make binaries for SCO 3.2.4
Organization: James Cook University
Date: 17 Oct 92 02:30:57 GMT

Anyone know where I can get these binaries via anon-ftp?

Please reply via email; me-too's welcome.

-SRK

--
Dept of Computer Science        Internet: stuart@coral.cs.jcu.edu.au
James Cook University
Townsville                      Tel: +61 77 814992
Qld 4811 Australia              FAX: +61 77 814092
Newsgroups: comp.unix.sysv386,comp.unix.xenix.sco,comp.unix.sys5.r4
From: sarnila@tukki.jyu.fi (Pekka Sarnila)
Subject: Re: Problems with SCO Authentication System
Organization: Jyvaskyla University
Date: Thu, 8 Oct 1992 23:45:41 GMT

<Descriping problems with SCO security database, etc.>

Suggested sollutions:

1) Get an other UNIX (e.g. SunSoft INTERACTIVE)

2) If previous is impossible, Try coping /etc/login from other machines
   that work right or from the system diskets. In v4 there are several
   different version of /etc/login in different packages; some of them
   don't work right. You've now got the one loaded last. The one in the
   basic package should be OK. Again the problem might be somewhere else.
   Let me know if you find the sollution. Unfortunately for my bread I
   got to fight with SCO UNIX.


-- 
-------------------------------------------------------------------
Pekka Sarnila,  University of Jyvaskyla Finland
sarnila@tukki.jyu.fi
From: bmd@conexch.uucp (Business Mgmt. Data)
Newsgroups: comp.unix.sysv386
Subject: X11 R4 Binaries for SCO Unix 2.0
Date: 4 Oct 92 23:32:10 GMT
Organization: The Consultants' Exchange, Orange County, CA.  (714) 842-6348
X-Newsreader: TIN [version 1.1 PL6]


	Can someone please tell me how to obtain X11 R4 binaries for
SCO Unix 2.0 (esp. X Server for Paradise SVGA ).
	Thanks
	/Kumar
From: Frank@mindlink.bc.ca (Frank I. Reiter)
Newsgroups: comp.unix.sysv386
Subject: Re: Unix: Cacheing EISA SCSI vs. Non-cacheing EISA SCSI Cont
Date: 9 Oct 92 21:20:06 GMT
Organization: MIND LINK! - British Columbia, Canada
Distribution: world

> Larry Snyder writes:
>
> >Get a BusTek BT 747S or 742A or Adaptec 174(x). Realistically, you can
> >almost always add RAM to the motherboard.
>
> How about if your MB is an ISA and you currently have 16megs of RAM
> on it?

So what?  I'm posting from a system running on an ISA motherboard with 48
megs of RAM.  This capability is pretty common these days.

Frank.
--
___________________________________________________________________
Frank I. Reiter                 Internet: Frank@mindlink.bc.ca
MIND LINK! Communications Corp. Surrey, British Columbia, Canada
Newsgroups: comp.unix.sysv386
From: memanuel@cbnews.cb.att.com (mark.emanuele)
Subject: Re: Unix: Cacheing EISA SCSI vs. Non-cacheing EISA SCSI Controllers
Organization: AT&T
Date: Sat, 10 Oct 1992 09:50:13 GMT

In article <Bvuqrw.AG@gator.rn.com> larry@gator.rn.com (Larry Snyder) writes:
>ed@maxed.amg.com (Ed Whittemore) writes:
>
>>Get a BusTek BT 747S or 742A or Adaptec 174(x). Realistically, you can
>>almost always add RAM to the motherboard.
>
>How about if your MB is an ISA and you currently have 16megs of RAM
>on it?  
>



Am I missing something here? What about the ONBOARD CPU on the caching 
controller? Does it not releive the system CPU from the duties of managing the disk drives, leaving it free to do other work ?

-- 
Mark A. Emanuele			memanuele@attmail.com
Sr. Network Engineer			(201)331-4713
AT&T Easylink Services	400 Interpace Pkwy   Parsippany, NJ 07054
From: s900387@minyos.xx.rmit.oz.au (Craig Macbride)
Newsgroups: comp.unix.sysv386
Subject: Re: Unix: Cacheing EISA SCSI vs. Non-cacheing EISA SCSI Controllers
Date: 7 Oct 92 07:56:15 GMT
Organization: RMIT Computer Centre
NNTP-Posting-Host: minyos.xx.rmit.oz.au

chuckc@hpfcdc.fc.hp.com (Chuck Cairns) writes:

>/ hpfcdc:comp.unix.sysv386 / ed@maxed.amg.com (Ed Whittemore) /  9:37 am  Sep 25, 1992 /
>There have been some discussions about various EISA SCSI controllers
>in some of threads in this and other groups lately, but I'd like to
>specifically address the question of the performance of these disk
>controllers, to see if anyone can establish any advantage of the
>cacheing controller over the non-cacheing, in a UNIX environment.

>  Disk Read -> "N" Meg cache in UN*X OS -> 1 Meg cache on SCSI card.

>  So before the SCSI card even GETS A SHOT at the request, it has to have 
>  missed the in-memory UN*X cache. The improvement, if any, must be minmal 
>  unless the cache miss rate for the UN*X cache is poor and the cache hit rate 
>  for the SCSI card cache is much better. I doubt that it will be better.

How about when it's more like:

Disk Read -> "N" Meg cache in Unix OS -> 8 Meg cache on SCSI card.

I saw one configured that way recently. Basically, there was no point
having a Unix cache at all, as no reasonable (ie. available) size made any
significant difference to the system's performance.

Interestingly, that card (a Mylex) had excellent performance on writes,
but the read performance degraded massively when more than 1 user was
working it hard. By massively, I mean that it achieved 1000kB/sec for
a single user writing to a file >8MB long yet only about 250kB/sec for
2 users doing that simultaneously.

Admittedly, this is just with the one hard disk and there is the O/S
(SCO Unix) to take into account, but I have done similar tests on other
(non-cached) controllers with less degradation. My suspicion is that
the device drivers for the particular O/S are of more importance than
they are given credit for.

-- 
 _--_|\		Craig Macbride	<lhscmc@luxor.latrobe.edu.au>
/      \			<s900387@minyos.xx.rmit.oz.au>
\_.--.*/
      v
From: dwex@cbnewsj.cb.att.com (david.e.wexelblat)
Newsgroups: comp.unix.sysv386
Subject: Re: Xfree86 (1.1) and ET4000 video board reset
Date: 8 Oct 92 20:03:51 GMT
Organization: AT&T

In article <1992Oct8.064243.9436@netcom.com> dror@netcom.com (Oz Dror) writes:
> I was finally able to compile Xfree86 for SCO unix (ODT 1.1, UNIX 3.2.2)
> But when I leave X386. The video board is getting out of sync.
> This can only be fixed by rebooting the system.
> 
> I have a local video bus (H-Host4000, et4000 chip).
> 
> Does any one have any Idea. I thought that Xfree86 (1.1) was supposed to solve
> this problem. The card works fine for X11R4 (When I use dot clocks that
> are half the calculated ones).
> 
> Xfree86 was compiled with gcc 2.2.2 (-m486 -O2)
> 
> 
> -- 
> NAME   Oz Dror
> SMAIL  dror@netcom.com

Take a look at the SAVE_TEXT and SAVE_CMAP stuff in vgaHW.c.  This is by
default disabled for SVR3 and SVR4 (it's slow and not necessary).  It
may be required for SCO.  It is required for Mach, 386BSD, and Linux

We don't support SCO; when you get it working, let us know (i.e.
send us patches).  xfree86@physics.su.oz.au is tha appropropriate
address.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
David Wexelblat             | dwex@mtgzfs3.att.com  | Somebody get me a
AT&T Bell Laboratories      | ...!att!mtgzfs3!dwex  |   cheeseburger!
200 Laurel Ave - 4B-421     |                       |      
Middletown, NJ  07748       | (908) 957-5871        | --Steve Miller Band
Newsgroups: comp.unix.sysv386
From: shayne@runx.oz.au (Shayne Flint)
Subject: Re: Any Ada compiler for 386 unix?
Organization: RUNX Un*x Timeshare.  Sydney, Australia.
Date: Fri, 16 Oct 92 12:24:16 GMT

In article <9210051314.AA05790@einstein.wd.estec.esa.nl> sten@EINSTEIN.WD.ESTEC.ESA.NL (Sten Ekholm) writes:
>Does anybody know if there exists an Ada compiler which runs under (any)
>386 based unix system?

Try Alsys. They have compilers and tools on SCO Open Desktop, Interactive
and others.

Alsys have X/motif  bindings for ODT etc. and have just released an implementation
of X, written in Ada. They claim that this implementation is 30% faster
and 40% smaller than C implementations. They also have UIL support etc. 

Alsys can be found in the US, UK, France, Japan, Germany, Sweden and 
they have distributors in  other countries.


Shayne Flint...
Xref: sparky comp.unix.sysv386:15531 comp.os.linux:13293 comp.unix.bsd:7344
From: gg10@prism.gatech.EDU (GALLOWAY)
Newsgroups: comp.unix.sysv386,comp.os.linux,comp.unix.bsd
Subject: X386 config info for Diamond Speedstar+/Gateway CS1024ni
Date: 13 Oct 92 15:36:18 GMT
Followup-To: poster
Organization: Georgia Institute of Technology

Tried as I might, I can only get X to come up in 640x480 mode.
If anyone out there has a Diamond Speedstar Plus board and/or a
Gateway Crystal Scan CS1024ni (non-interlaced) monitor and has
been successful in getting X to come up in 1024x768 mode, pleease
be so kind as to mail me your Xconfig file.

I have read the XConfig.notes and CONFIG files but don't have enough
documentation on the board or monitor to roll my own.

Thanks
Greg Galloway
gg10@prism.gatech.edu
Newsgroups: comp.unix.sysv386