Path: utzoo!utgpu!watmath!clyde!bellcore!rutgers!mcnc!rti!bcw
From: bcw@rti.UUCP (Bruce Wright)
Newsgroups: comp.sys.dec.micro
Subject: Re: TURBOW-286
Summary: Seems to work pretty well
Message-ID: <2625@rti.UUCP>
Date: 10 Dec 88 06:44:23 GMT
References: <798@cs.rit.edu>
Organization: Research Triangle Institute, RTP, NC
Lines: 49

In article <798@cs.rit.edu>, iav1917%ritcv@cs.rit.edu ((alan i. vymetalik)) writes:
> 
>    Rainbow folk:
> 
>    Well, as far as I can tell, Suitable Solutions has begun to ship
>    their 80826/80287 accelerator card for the Rainbow 100B/+.
> 
It is, in fact, shipping in _very_ limited quantities, due to the chip
shortage.  The on-board cache it uses is a variety of static RAM which
has been hard to get of late and may not be available in large quantity
until next year.

We have obtained one and have been testing it.  As you mentioned, it
contains a 12MHz 80286 (CMOS) and room for an 80287.  If the cache /
high speed clock are turned on (this can be done from software) it 
does indeed give a Norton SI of 8.3, which puts it squarely in the 
AT category.  You cannot install an 8088 or an 8087 with the Turbow -
the 80286/80287 take their place.  The software switch just turns on
high speed mode for the 80286.

In practice, we have found that very few programs have problems with
the Turbow board, and have not found ANY compatibility problems if the
accelerator switch is OFF.  Most of the problems are with graphics
programs - many graphics programs copy some code from the DEC graphics
board documentation which has some bugs in it, and there are also some
new timing problems with using the graphics board which never used to
be possible.

[Technobabble insert:  The problems all revolve around the fact that
it is possible to load the Graphics Display Controller (GDC) with
commands faster than it can execute them.  This is possible even on
the old 8088, but it is even more of a problem on the 80286.  Many
programs don't check the GDC for busy properly, and (even worse) even
if the GDC is not busy it is possible to execute certain register load
sequences too rapidly which throws it into a tizzy.  If you have access 
to the source the fix is usually pretty easy;  if you don't you can
always do a TURBOW OFF and we have yet to see a program which isn't
fixed by this.  I understand however that AUTOCAD and possibly a couple
of others may still have problems and that there is a special version
of the Turbow board which slows down the graphics board I/O just for 
AUTOCAD].

I have heard that there is a version of Windows that someone is working
on and is "close" but I don't know when/if it will be available.

All in all I would give it pretty high marks.  As usual, I think Jerry 
Miller has done his homework pretty well on this one.

					Bruce C. Wright