[comp.graphics] PC2 Graphics beats Amiga

anc@camcon.co.uk (Adrian Cockcroft) (04/24/87)

NB This is a second  attempt at  posting news  and is  the first real
attempt at generating outgoing news from this site!

The new IBM PC2 range was described in the Guardian computer pages on
9/4/87.  Based on this information and other background  info the PC2
graphics will be substantially better than the Amiga.  They will also
be substantially more expensive!

All models use the Inmos  IMSG171 colour  lookup table,  this has 256
entries and 6 bit  DACs per  colour giving  18 bits  or 256K possible
colours.    Recent press  announced a  multi million  pound order for
these between IBM and Inmos.   This  supports 8  bits per  pixel or 8
bitplanes.

The low  end PC2's  seem to  have a  gate array  that generates video
timing to give noninterlaced 640  by 480  at 70  Hz refresh.   Due to
memory limitations this resolution is at most 4  bits per  pixel.  At
320 by 240 a full 8 bits per pixel can be  generated.   The memory is
encoded  as packed  pixels in  bytes rather  than multiple bitplanes.
All drawing is done in software.  Summary vs  Amiga:   better to look
at (no flicker, more colours) but much slower.

The high end PC2's have a plug in card  with 1  Meg of  video ram and
use  the intel  82786 graphics  chip.   These machines  are 80286 and
80386 based.

I am using the Intel 82786 on a 68010 based prototype  machine at the
moment (together with Inmos G170) and it is very fast.

It  supports  windowing  in  hardware  with  different windows having
different bits per pixel including zero (zero  BPP =  1 colour, takes
no ram).  This is done by fetching data for the  video shift register
from all over the place on the fly.

It  also  has  a  drawing  processor  that  includes  a  BITBLT  (2.5
MPixels/s) fill area (30 Mpixels/s)  lines, polylines  and circles (2
MPixels/s) and CHARBLT at 20000  characters/s (given  an ascii string
and a font up to 16*16 pixels per char defined per  character to give
proportional spacing and kerning in hardware).  The drawing processor
is given a program to execute of  graphics instructions  which can be
any  size  with   unconditional  jumps   and  subroutine  call/return
embedded.  The CPU is told when  the drawing  processor has finished.
All this is faster than the Amiga but the  price for  hires monitor +
extra graphics RAM card will be about $2000.

For those who want a 68010 (8MHz) + 82786 + G170  + (512K  or 2Meg) +
floppies + SCSI  winchester +  parallel &  serial ports  + Inmos C012
transputer link adapter that runs Tripos  or OS/9  the Micro Concepts
Image-10 is available.   The Tripos  is NOT  from Metacomco,  it is a
much  improved  Cambridge  University  version.     The  hardware  is
available, Tripos and OS/9 are  up and  running but  the Tripos 82786
windowing graphics drivers  are not  finished yet.   82786 configured
for 768 by 576 50Hz interlaced PAL compatible timings.  Cost is about
2000  pounds  for  twin floppy  (720K each)  or 2800  pounds for 20Mb
winny+floppy (512K RAM).  This doesnt include a  monitor or software.
A cheap  (500 pounds)  genlocking frame  grabber will  be ready soon.
Contact Micro Concepts 2 St Stephens Road, Cheltenham,
Gloucestershire, England.  (0242) 510525.

I spend my spare (!)   time working  on the  Tripos graphics software
for this machine and it has no involvement with Cambridge Consultants
Ltd.

hutch@sdcsvax.UUCP (04/29/87)

<Just the facts maam.>

In article <500@titan.camcon.co.uk> anc@camcon.co.uk (Adrian Cockcroft) writes:
>All models use the Inmos  IMSG171 colour  lookup table,  this has 256
>entries and 6 bit  DACs per  colour giving  18 bits  or 256K possible
>colours.

Yes, I like it.  Still, is 256 choices of 18 bits better than 256000
choices of 12 bits (640x480 resolution)?

>The low  end PC2's  seem to  have a  gate array  that generates video
>timing to give noninterlaced 640  by 480  at 70  Hz refresh.   Due to
>memory limitations this resolution is at most 4  bits per  pixel.  At
>320 by 240 a full 8 bits per pixel can be  generated.   The memory is
>encoded  as packed  pixels in  bytes rather  than multiple bitplanes.
>All drawing is done in software.  Summary vs  Amiga:   better to look
>at (no flicker, more colours) but much slower.

Correction, *fewer* colors & no flicker.  Why 70 Hz, 65 would be very
stable, and they could use the rest of the bandwidth for something useful
like blitting.

The plug in frame buffer does sounds very nice though...

I still lust after the Amiga 2000 with the 68020/68881 co-processor,
and a darker side likes the 8088 and its PC slave slots.

-- 
    Jim Hutchison   		UUCP:	{dcdwest,ucbvax}!sdcsvax!hutch
		    		ARPA:	Hutch@sdcsvax.ucsd.edu
Disklame'r:
    One greater than the greatest signature representable with 184 symbols.

page@ulowell.UUCP (04/29/87)

anc@camcon.co.uk (Adrian Cockcroft) wrote in article <500@titan.camcon.co.uk>:
>Summary vs  Amiga:   better to look at (no flicker, more colours)
>but much slower.

...and more expensive.

How easy is it to upgrade the low-end PS/2's to take advantage of
faster video processors, or better (you define it) video?  Can I get
NTSC/PAL/SECAM output cheaply?  How about chromakey, genlock or
other neat effects?

It seems that for generating stills/slides or using the machine as
a color terminal, the PS/2 wins over the Amiga, if you forget about
the price difference.  I can't imagine doing animation, imageing,
or video production work on a PS/2.

..Bob
-- 
Bob Page, U of Lowell CS Dept.   page@ulowell.{uucp,edu,csnet} 

grr@cbmvax.cbm.UUCP (George Robbins) (04/30/87)

In article <3062@sdcsvax.UCSD.EDU> hutch@sdcsvax.UCSD.EDU (Jim Hutchison) writes:
>
>Correction, *fewer* colors & no flicker.  Why 70 Hz, 65 would be very
>stable, and they could use the rest of the bandwidth for something useful
>like blitting.

	Uh, they use shift-register "video" rams which means bandwidth is
	not a real issue.  This is pretty easy on the simplistic display
	model that IBM implements.
>
>I still lust after the Amiga 2000 with the 68020/68881 co-processor,
>and a darker side likes the 8088 and its PC slave slots.

	These sound like healthy impulses to me.  8-)

-- 
George Robbins - now working for,	uucp: {ihnp4|seismo|rutgers}!cbmvax!grr
but no way officially representing	arpa: cbmvax!grr@seismo.css.GOV
Commodore, Engineering Department	fone: 215-431-9255 (only by moonlite)

grr@cbmvax.cbm.UUCP (George Robbins) (05/03/87)

In article <3073@sdcsvax.UCSD.EDU> hutch@sdcsvax.UCSD.EDU (Jim Hutchison) writes:
>In article <1794@cbmvax.cbm.UUCP> grr@cbmvax.UUCP (George Robbins) writes (<)
>
><	Uh, they use shift-register "video" rams which means bandwidth is
><	not a real issue.  This is pretty easy on the simplistic display
><	model that IBM implements.
>
>You can still do processing on the contents of the shift-register.  Not
>permanent block transfers, more like inserted block transfers.  Just insert
>the little devil into the output stream.  Is this a silly way to handle such
>things?  Sounds like a fine way to do live video overlay, but I could be
>quite confused.

Oops, I should have less cryptic.  What I meant by "simplistic" is that the
IBM displays have a small chunk of display memory, which is mapped in a
pretty much one-for-one way to the display.  This is easy to do with video
rams.

The Amiga, on the other hand, can display a fairly random assortment of
bitplanes and sprites from arbitrary regions in display memory.  This is not
so easy to do with video rams.

For the uninitated, video or "shift-register" DRAMs have both the normal
processor interface and an extra high-speed serial data path.  The two
accesses only conflict when a new page of data needs to be transfered to
the serial output section.  This is obviously a considerable improvment
over having the display and the processor try to share the same data path.

The tradeoff with respect to the Amiga is that, unless you want to make
things a lot more complicated than otherwise neccessary, bitplanes would
need to be aligned to conform with the underlying hardware.  Also, horizontal
scrolling becomes less pleasant.

-- 
George Robbins - now working for,	uucp: {ihnp4|seismo|rutgers}!cbmvax!grr
but no way officially representing	arpa: cbmvax!grr@seismo.css.GOV
Commodore, Engineering Department	fone: 215-431-9255 (only by moonlite)

hutch@sdcsvax.UCSD.EDU (Jim Hutchison) (05/04/87)

In article <1794@cbmvax.cbm.UUCP> grr@cbmvax.UUCP (George Robbins) writes (<)
In article <3062@sdcsvax.UCSD.EDU> I (Jim Hutchison) wrote (>):
>[On the PC2 displaying at 70Hz]  Why 70 Hz, 65 would be very
>stable, and they could use the rest of the bandwidth for something useful
>like blitting.

<	Uh, they use shift-register "video" rams which means bandwidth is
<	not a real issue.  This is pretty easy on the simplistic display
<	model that IBM implements.

You can still do processing on the contents of the shift-register.  Not
permanent block transfers, more like inserted block transfers.  Just insert
the little devil into the output stream.  Is this a silly way to handle such
things?  Sounds like a fine way to do live video overlay, but I could be
quite confused.

-- 
    Jim Hutchison   		UUCP:	{dcdwest,ucbvax}!sdcsvax!hutch
		    		ARPA:	Hutch@sdcsvax.ucsd.edu
Disklame'r:
    One greater than the greatest signature representable with 184 symbols.

geoffs@gssc.UUCP (Geoff Shapiro) (05/04/87)

In article <500@titan.camcon.co.uk> anc@camcon.co.uk (Adrian Cockcroft) writes:

>The high end PC2's have a plug in card  with 1  Meg of  video ram and
>use  the intel  82786 graphics  chip.   These machines  are 80286 and
>80386 based.

Are you talking about IBM's 1024x768x8 high resolution card ? If IBM is
using an 82786 on this card it is news to me! Last I heard, the silicon
on the board was custom-made at IBM's facility in Hursley, England. Please
tell me where you heard this tidbit of information...


Geoff Shapiro
Graphic Software Systems
Beaverton, Or.
(503) 641-2200

anc@camcon.co.uk (Adrian Cockcroft) (05/11/87)

>>The high end PC2's have a plug in card  with 1  Meg of  video ram and
>>use  the intel  82786 graphics  chip.   These machines  are 80286 and
>>80386 based.
>
> Are you talking about IBM's 1024x768x8 high resolution card ? ...
>
> Geoff Shapiro

No, I think there must be 3 levels of graphics on the PC2,

1) gate array with video RAMs 640*480 but not enough RAM for 8 bpp
        at this resolution.

2) 82786 based 640*480*8 bpp same display with enough RAM and 82786 for
        hardware windows & bitblt/line drawing. This may be mixed VRAM
        and page mode DRAM.

3) something else giving 1024*768*8 bpp. This won't be an 82786 since
the pixel clock on the 82786 has a max of 25 MHz.

Is 2) an 82786? Well the 82786 documentation goes on and on about
640*480*8 resolution and lists lots of IBM PC style software companies
doing things for it (e.g. DR GEM-786). I have heard that a UK company
is doing the IBM presentation manager software for the 82786 and I asked
a technical support guy from a UK Intel distributor and he said that it
was definitely in there somewhere but that he was not sure what was in
what!

Maybe someone has a hardware spec of the whole range and can settle this.
All the press so far is on the low end machines and the 82786 is only
just into production so I suspect that the software drivers aren't ready
and it will come along later.

I have just noticed that I said the PC2 plug in will have 1 Meg video RAM,
I meant graphics RAM since the 82786 only does hardware windowing if used
with page mode DRAMs (but it can support VRAMS as well).

I will restrict further discussion of the 82786 to comp.graphics but
it might be fun to put a PC 82786 plug-in into an A2000.... :-)

-- 
---- Adrian Cockcroft   anc@uk.co.camcon        (0223) 358855
---- Cambridge Consultants Ltd, Science Park, Cambridge CB4 4DW, England

shardy@teknowledge-vaxc.ARPA (Steve Hardy) (05/13/87)

It is IBM Hursley (in Britain) who developed the high-end 8514
(1028x768x8) display and adapter.  Hursley does a lot of IBM's
graphics development work.  I think that the 8514 is completely IBM,
i.e. no Intel 82786.  The 8514 has hardware support for BITBLT. line
drawing, area fill, patterns, color mixing, and scissoring.  Also has
soft fonts.                   -- Steve Hardy, SHARDY@TEKNOWLEDGE.ARPA

mike@wsucshp.UUCP (Mike Kibler - CSB2056) (05/20/87)

/ wsucshp:comp.graphics / anc@camcon.co.uk (Adrian Cockcroft) / 10:38 am  May 11, 1987 /

IBM has gone to their own proprietary gate array chip with the
introduction of their Video Graphics Array (VGA) - standard on
all PS/2 systems (Built into mother board). The output of the VGA
is analog RGB. Sixteen colors may be displayed at a resolution
of 640 X 480. 256 may be displayed at a resolution of 320 by 200.
The palette is 256,000.

IBM has also announced two proprietary graphics coprocessors, the 8514
and the 8514/A. The 8514/A with optional memory will be capable
of displaying 1024 X 768 X 8.

It will be interesting to see some comparisons between the PS/2 with
the 8514A graphics coprocessor and Quadrams QuadHPG Series I (Intel 82786 based)
graphics card which also displays 256 colors but at 640 X 480. Although
Quadram has promised higher resolutions in their HPG Series II and III
cards due out later this year/next year.

Besides resolution is only half the story. I am interested in
bit planes. I am still looking for a commitment from ATT and
Number 9 (or anybody else for that matter) to produce one of 
their 32 bit plane graphics cards for the PS/2 system,  or better 
yet the MAC II.

 ---- Mike  ( Those who can do, do. Those who can't simulate! )

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 Michael K. Kibler        CSNET:  mike@cs1.wsu.edu
 Computer Science Dept.   UUCP:   ..!ucbvax!ucdavis!egg-id!ui3!wsucshp!mike
 Washington State Univ.   BITNET: kibler@wsuvm1.BITNET
 Pullman, WA. 99164-1210  PHONE:  509-335-2723 or 509-335-6636

ali@rocky.UUCP (05/23/87)

In article <80002@wsucshp.UUCP> Mike Kibler writes:
>Besides resolution is only half the story. I am interested in
>bit planes.

Considering the hardware to push many bit planes around in real time
is still pretty expensive, I think Amiga's method of providing 4096 colors
at once without the use of 12 bit planes is pretty clever. (This is
known as the "Hold-and-Modify" (HAM) mode, it was described in detail a
while back on this newsgroup.) The current Amigas have 32 color registers, and
can display 32 colors in lo res (upto 352x474) or 16 in hi (upto 704x474). 
This combination of resolution/colors is fine for text applications, 
cartoon-like animation, business graphics, or genlock applications
(where you merge video signals with titles or other images and record on VCR),
but, as I've found out, if you really want to digitize an object and have
it look right you need more colors. (Dithering helps, but only to a certain
degree...) That's where the Amiga's HAM mode comes in real handy --- Images
digitized in this mode look exceptionally real. It requires some extra 
computation (< 30 seconds with the "Digi-View" digitizer I have) to compute
(not display, displaying is fast) a 12-bit image to look well in HAM mode,
but, the results are worth it and are usually indistinguishable from real (ie,
12-bit plane) images. Only images with many sharp edges of many different 
colors won't come out right, due to the HAM tradeoffs. (You'll get "fuzzy"
edges because of the fringing effects.)

Anyway, the point is that I like the idea of more bit planes, but I also love
the idea of being able to play with 4096-color images on a $1k machine.
I've been experimenting with "animation" in HAM mode (mostly by flipping
through compressed digitized images), and it is easily possible. (And 
"juggler" also is a good example of this, although the images are ray-traced
rather than digitized.) What would be the cost of a Mac II or IBM system 
which allowed you to do >10 frame/second 4096-color animation?  (Juggler
runs faster than 20 frames/sec.)

Ali Ozer, ali@score.stanford.edu, ...decwrl!rocky.stanford.edu!ali