davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (12/19/90)
In article <1990Dec19.115110.15070@ncsuvx.ncsu.edu> kdarling@hobbes.ncsu.edu (Kevin Darling) writes: | After all this time, | I had figured the chip had never come out, but then I saw an ad for a | terminal using it, a few weeks ago. best - kev <kdarling@catt.ncsu.edu> I thought the chip was dead, too. Someone contacted me looking for a job about a year ago, saying that their company had bet on the Intel vs. TI for a board, and Intel had decided not to make it. Can someone shed light on this? Was the chip cancelled and then reinstated, or what? -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) VMS is a text-only adventure game. If you win you can use unix.
mcdonald@aries.scs.uiuc.edu (Doug McDonald) (12/19/90)
In article <3070@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.com (bill davidsen) writes: >In article <1990Dec19.115110.15070@ncsuvx.ncsu.edu> kdarling@hobbes.ncsu.edu (Kevin Darling) writes: > >| After all this time, >| I had figured the chip had never come out, but then I saw an ad for a >| terminal using it, a few weeks ago. best - kev <kdarling@catt.ncsu.edu> > > I thought the chip was dead, too. Someone contacted me looking for a >job about a year ago, saying that their company had bet on the Intel vs. >TI for a board, and Intel had decided not to make it. > > Can someone shed light on this? Was the chip cancelled and then >reinstated, or what? >-- I may be -- probably am -- all wet, but I thought that the Intel and TI graphics chips were enitrely different bests: the TI chip was a programmable device for drawing graphics primitives onto a frame bufffer while the Intel one was, as has been described earlier in this thread, a device for manipulating "windows" from asveral parts of a frame buffer onto an actual screen. Anybody really know? Can you layer one onto the other? Doug McDonald
kdarling@hobbes.ncsu.edu (Kevin Darling) (12/20/90)
>> I had figured the chip had never come out, but then I saw an ad for a >> terminal using it, a few weeks ago. <kdarling@catt.ncsu.edu> >> > I thought the chip was dead, too. > Can someone shed light on this? Was the chip cancelled and then > reinstated, or what? <davidsen@crdos1.crd.ge.COM> Bill - I can't seem to find that terminal ad, but I did just run across this quote from Computer Graphics Review, Oct '89: "The Intel 82786 is positioned as a companion to Intel's 80286 and 80386 processors and accompanying numeric processors. Used by such graphics board vendors as Western Digital Imaging, Bell Technologies, Vermont Microsystems and Number Nine (the latter of which uses both the 82786 and 34010 on a single board), it is the second best-selling graphics coprocessor." ^^^^^^^^^^^^^^^^^^^ (At the time, of course) But this means it (was) really out there. I admit to being astonished, too! best - kevin <kdarling@catt.ncsu.edu>
foo@titan.rice.edu (Mark Hall) (12/21/90)
In article <1990Dec19.154145.10137@ux1.cso.uiuc.edu> mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes:
)I may be -- probably am -- all wet, but I thought that the Intel and TI
)graphics chips were enitrely different bests: the TI chip was a programmable
)device for drawing graphics primitives onto a frame bufffer while the Intel
)one was, as has been described earlier in this thread, a device for
)manipulating "windows" from asveral parts of a frame buffer onto an
)actual screen.
)
)Anybody really know? Can you layer one onto the other?
)
I should probably sit quietly by, but that would be out of character 8^)
I wrote a large chunk of the demo software for the initial trade show
showing the Intel 82786 (Comdex in Las Vegas, 1987? memory is failing).
I have not looked at the chip since then. It does do some graphics
drawing, like drawing lines. It also, as has been noted here, manage
windows in hardware.
IMHO, the 82786 is severely limited in that it is not programmable.
For instance, it did not do polygon filling. To fill polygons, I wrote
a routine to find the interior of a polygon on a scanline by scanline
basis (on the x86). The 82786 would draw the horizontal lines. The
overhead of passing the filling info to the 82786 made polygon-filling
less than spectacular.
I WAS very inpressed with the windowing support, though.
- markzik@bruce.cs.monash.OZ.AU (Michael Saleeba) (12/21/90)
In <1990Dec20.194956.21974@rice.edu> foo@titan.rice.edu (Mark Hall) writes: ]In article <1990Dec19.154145.10137@ux1.cso.uiuc.edu> mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes: ])I may be -- probably am -- all wet, but I thought that the Intel and TI ])graphics chips were enitrely different bests: the TI chip was a programmable ])... ]... ] I have not looked at the chip since then. It does do some graphics ] drawing, like drawing lines. It also, as has been noted here, manage ] windows in hardware. ]... Is it possible to construct a system combining both the 34020 and the Intel chip to combine the fast rendering abilities of the 34020 with the fast window operations of the 82786? This, it seems, could provide a means of speeding the window scrolling bottleneck while still allowing the powerful rendering of the TI chip. - Michael Saleeba
maslen@eng.sun.com (Thomas Maslen) (12/21/90)
[ I assume we're all talking about the same chip, the 82786. So far only Kevin Darling and Mark Hall have referred to it by name. ] foo@titan.rice.edu (Mark Hall) writes: >In article <1990Dec19.154145.10137@ux1.cso.uiuc.edu> mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes: >)I may be -- probably am -- all wet, but I thought that the Intel and TI >)graphics chips were enitrely different bests: the TI chip was a programmable >)device for drawing graphics primitives onto a frame bufffer while the Intel >)one was, as has been described earlier in this thread, a device for >)manipulating "windows" from asveral parts of a frame buffer onto an >)actual screen. >) >)Anybody really know? Can you layer one onto the other? The 82786 does, or attempts to do, all sorts of things, including the "windows" bit and a fair number of drawing primitives as well. Given this, among other things, I would have thought it odd to combine it with a 34010, but Kevin Darling says that a company called Number Nine has done it. I've never looked at a 34010, so I'll hypothesize wildly that it does a better job on the drawing primitives and maybe on programmability. > I should probably sit quietly by, but that would be out of character 8^) Likewise. I bit my tongue for the first few messages, but now I'm going to be rude about this chip. > I wrote a large chunk of the demo software for the initial trade show > showing the Intel 82786 (Comdex in Las Vegas, 1987? memory is failing). > I have not looked at the chip since then. It does do some graphics > drawing, like drawing lines. It also, as has been noted here, manage > windows in hardware. > IMHO, the 82786 is severely limited in that it is not programmable. Clarification: you can give it lists of commands, DMA'ed out of the memory it manages. I think there is even a stack and call/return commands (can anyone confirm this? It's six months since I saw the manual, and I've been trying to forget it), but I don't remember any conditional transfer instructions -- it could hardly be accused of having a general instruction set. Given that the command lists and stack may live in the same memory space that it manipulates, I occasionally fantasized about using bitblt operations on the code or stack to implement a Turing machine or otherwise construct a more general, if hopelessly inefficient, instruction set. If this part of memory were displayed on the screen it'd be even more fun. > For instance, it did not do polygon filling. To fill polygons, I wrote > a routine to find the interior of a polygon on a scanline by scanline > basis (on the x86). The 82786 would draw the horizontal lines. The > overhead of passing the filling info to the 82786 made polygon-filling > less than spectacular. The handshake for command lists between the 82786 and main-processor software is pretty poor. You write a command list (terminated by a halt instruction) into memory, write a pointer (really a jump instruction) into three of the 82786 registers, and away it goes. You find out when it's done either by polling a bit in an 82786 register or, presumably, by fielding an interrupt (not useful to me; I was meant to be writing user-level Unix code). While it's running you can write more command lists somewhere else in memory, but there's no way of saying "when you're done with that one, start on this one" and there's no way (or maybe it just wasn't documented) to determine how far it's progressed through the commands you gave it. Consequently the main processor spends a lot of time synchronizing with the 786, and for short drawing operations you're better off doing them yourself. I've seen much better (i.e. more efficient for software) implementations of what I think of as ring-buffer protocols in some ethernet controllers and in the display controller that DEC SRC built for their Firefly machines. > I WAS very inpressed with the windowing support, though. Each to his own. One's impression of the chip probably depends a lot on the use to which one is trying to put it (duh), and Mark's application may have suited it better than mine. Me, I was trying to do an X11R4 port to a 386 box running Mach 2.5 (i.e. Berkeley Unix, as far as I was concerned) and the Bell Technologies Blit card, which contains the 82786 and some amount (1MB? 4MB?) of RAM, and the server was meant to run as a user process with minimal driver code in the kernel. The "windowing support" is a list-of-lists. Each entry in the top-level list specifies: - the number of rows (scanlines) to which it applies, - a second-level list, - sundry other stuff I've forgotten. Each entry in the second-level list specifies: - the number of horizontal pixels to which it applies, - the starting address, stride (address offset between adjacent rows), pixel depth (1 to 8 bits) and sundry other properties of the bitmap that should be displayed in this block. The degenerate case, of course, is a single entry at both levels with nrows and ncols defined so that the whole screen uses one bitmap. As I believe someone noted, each second-level list is limited to 16 entries. The ability to mix bitmaps of different depths is cute, but has all sorts of restrictions if you're using VRAMS or one of the hi-res modes on the chip. Somewhere in there is a notion of zooming selected windows, but I don't remember much about it. The chip also provides cursor support, with X-Y coordinates specified in a pair of 82786 registers, but the choices are - cross-hairs which extend over the whole screen, or - a 16x16 (I believe), single-colour pattern. Both the windowing support and the cursor support are probably good for something, but they're a poor match for X11. By the time you're done calculating window overlaps and worrying about the n > 16 case (eight windows properly aranged on one row should be enough to trigger this), not to mention doing memory-allocation in the 82786 memory for all these windows, it's not clear to me how much the windowing support helps. X11 is most happy with an arbitrary-size, two-colour cursor (i.e. within the bounding rectangle of the cursor each pixel may be black, white, or whatever is underneath the cursor). It can live with 16x16, and it can live with a single colour, and it does both on the DEC QVSS display, but it's not pretty (the QVSS cursor changes from black to white as you drag it around. I believe DEC fixed this in the SM framebuffer). I ended up using the machine-independent cursor code in the X11R4 distribution, which is amazingly clean and general and so not amazingly efficient. Another irritation... the chip thinks in 16-bit words, and its display bit-order within a word is big-endian. This doesn't sit too well with a 386 processor which is little-endian. In fact the only reason that I didn't end up completely losing my mind was that the X11 folks had done a great job of ifdef'ing their code for various bit-orders and word-sizes, and the IBM X11 folks had added an extra level of support that they needed for the VGA (8-bit big-endian, I believe?). Still found a few holes in the X11R4 sources, but not many. I would have thought that, given that everything else on the chip was meant to be programmable, it would have been ridiculously easy to make the bit-order programmable, but then I'm ignorant of the hardware complexities. Incidentally, what's the bit-order of the 34010? I thought I'd heard that it is big-endian, but may be deluded. More griping... there are at least three sorts of 82786 "registers". Some are accessed directly by main-processor writes to specific addresses. I believe, but may be misremembering, that some are written indirectly, i.e. the main processor writes a number into a "register selector" register, then writes the data in a "register value" register. Some pretty fancy parameter blocks are read and written by DMA. Finally, some registers are read and written by 82786 instructions. Overall, the chip felt like something I might have designed if I'd been let loose on an unsuspecting hardware world. Basically good ideas, but implemented sufficiently badly that you couldn't really use them. At least one obscure and annoying bug, too (a bit in the top-level window list that I shouldn't have had to set, but if I didn't then the display was comprehensively curdled). One could be forgiven for thinking that the chip was done by an isolated group who had never heard of the term "design review", or maybe even the term "design". If Intel has delusions of putting windowing support in the 586, they should use the 82786 as a counterexample rather than as a paradigm. There, I feel better now. Check your Mercury News tomorrow to see whether it says "Sun employee beaten up while riding home". Seriously, if you're interested in the chip, get a copy of the programmer's manual, read it thoroughly, and decide whether it's right for your application. The obligatory disclaimers: These opinions are quite definitely mine, not those of Sun Microsystems. My experience with the 82786 occurred in a previous job at another company. Thomas Maslen maslen@eng.sun.com
kdarling@hobbes.ncsu.edu (Kevin Darling) (12/21/90)
Just a note of thanks to those who took the time (and risk ;-) to post their experiences on the 82786 gfx chip. The original reason for bringing it up at all, was the desire someone mentioned of not having to handle window redraws/moves, I believe. I'm in the same situation... I don't mind doing drawing operations myself (in the window manager/driver), but the idea is that applications themselves under this system should not have to worry about redraws (it's a multitasking system, and I've always thought that if the idea was to let each program think it was running alone, then that concept should extend to the virtual terminals on the screen, also :). That pretty much leaves me no choice: covered windows require some backing store, and the drawing routines have to handle (un)covered regions. I've done this before, and never liked the speed results. So having the display hardware combine the separate windows on the visible screen would be great for me. Anyway... Much thanks again! As I mentioned, I'd not seen the chip beyond one or two articles yet. Always good to hear opinions first. cheers - kevin
ckp@grebyn.com (Checkpoint Technologies) (12/22/90)
With this talk of hardware windows and the Intel 82786, I've been
racking my brain for the last few days to remember this and I just
recalled it.
I read an article in Computer Design magazine sometime in the last year
about a chip from Standard Microsystems, called the VIEW chip. This was
a "refresh processor" that would also do windows in hardware. It has no
drawing functions, but rather is dedicated to the task of refresh. It
has a microprogrammed processor which constructs the window overlap/etc
lists from simple rectangle/priority descriptions, so therefore is much
easier to program than the 82786 (so the article said). At the time I
remember thinking that this chip plus a 340x0 would make agreat display
card.
I'm going to spend some time and try to find the article, if anyone's
interested. This was all from memory and so may be very inaccurate.
--
First comes the logo: C H E C K P O I N T T E C H N O L O G I E S / /
\\ / /
Then, the disclaimer: All expressed opinions are, indeed, opinions. \ / o
Now for the witty part: I'm pink, therefore, I'm spam! \/