Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!mcsun!ukc!tcdcs!swift.cs.tcd.ie!vax1.tcd.ie!rwallace From: rwallace@vax1.tcd.ie Newsgroups: comp.sys.amiga Subject: Re: Transputer graphics board Message-ID: <5845.261cc9b7@vax1.tcd.ie> Date: 6 Apr 90 16:54:15 GMT References: <02602.AA02602@sosaria.imp.com> <8612@hubcap.clemson.edu> Organization: Computer Laboratory, Trinity College Dublin Lines: 35 In article , portuesi@tweezers.esd.sgi.com (Michael Portuesi) writes: >>>>>> On 4 Apr 90 01:04:14 GMT, chrise@hubcap.clemson.edu (Chris Everhart) said: >> In article <02602.AA02602@sosaria.imp.com>, wizard@sosaria.imp.com (Chris Brand) writes: >>> However, you have to be a programmer to use it, since there's NO software >>> around to support it (and I don't feel like re-writing DPaint III, even if >>> I could :-) > >> But would you REALLY have to rewrite the thing? After all, couldn't you >> just write a new graphics library, and have the thing recompiled? (Granted, >> this is a major undertaking because all software has to be recompiled, but > >> Better yet! Is the graphics library on disk? I don't think it gets compiled >> in...or does it. I forget. If it just resides on disk, no compilation should >> be necessary!! > > > It doesn't get compiled in. If you write a new graphics library, all > applications which use the Graphics Library will happily work without > modification or recompilation. The problem is that many programs > bypass the Graphics Library and twiddle with the system on their own. > They will break on a new video board. So will programs that depend on > copper tricks and other stuff which a foreign graphics board may not > be able to support. All graphics software that needs to do anything FAST (i.e. animation) accesses the video RAM and probably the blitter & copper directly because the graphics library routines are much too inefficient. In fact if you were to rewrite the graphics library routines for a Transputer board and you were to do as bad a job as Commodore/Amiga did for the 68000 versions, applications using them would probably be slower than applications just accessing the video RAM directly using the blitter & 68000 assembly language. "To summarize the summary of the summary: people are a problem" Russell Wallace, Trinity College, Dublin rwallace@vax1.tcd.ie