[comp.sys.amiga] 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