Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!wuarchive!psuvax1!news From: melling@cs.psu.edu (Michael D Mellinger) Newsgroups: comp.sys.amiga.advocacy Subject: Re: Blitter vs. 040 (was: Computer Architecture question Message-ID: Date: 12 May 91 20:59:35 GMT References: <1991May10.180908.29565@convex.com> <6o6Hk!=@cs.psu.edu> <48817@ut-emx.uucp> <48829@ut-emx.uucp> Sender: news@cs.psu.edu (Usenet) Organization: Penn State Computer Science Lines: 41 In-Reply-To: greg@ccwf.cc.utexas.edu's message of 11 May 91 13:38:46 GMT Nntp-Posting-Host: sunws5.sys.cs.psu.edu In article <48829@ut-emx.uucp> greg@ccwf.cc.utexas.edu (Greg Harp) writes: Does the NeXT allow for more than one frame buffer, or is it fixed to a specific area of memory? Double-buffering is very important for clean animation. Without it, you have to synchronize the changes made to the display with the raster beam of the monitor. If you want an example of the difference it makes, compare animation on a 7Mhz A500 to that of a 25Mhz 030-based Mac. Sad... I don't think the NeXTstation has double-buffering. Someone mentioned that the reason graphics on the Mac are slow is because it only has a 10MHz NuBus. The new 040 Macs will have a 25MHz bus. NeXT claims to have a 25MHz NuBus, however a few days ago some in comp.arch mention that it is really only 12.5MHz and the 030(and 040?) burst mode was added into that. I'm not exactly sure of the details. The article should still be in comp.arch. Anyway, there probably at least needs to be a routine to write a rasterized image directly to the display. Interpreting PostScript would make for a real loser of an animation. There is a binary form for Postscript that needs little interpretation, and TIFFs can be included in your program to display on the screen. It seems to me that one should be able to have your interpreted image evaluated once so that you have a bitmap, then blast it to the screen. I'll be able to tell you more in the fall, my plan was to learn everything(as much as possible) about programming the NeXT this summer. It depends on the level of the interface provided to the programmer. Does NeXT have a spec or standard for writing to the frame buffer without using DPS? Or is that not guaranteed to remain the same in later revisions? I don't think writing to the frame buffer is documented. The guy who wrote the free version of X-windows for NeXTStep 1.0 claimed that NeXT wasn't very helpful in telling him how it worked. The free version X-windows for NeXTStep 2.0 takes over the screen, so someone must have figured out how to get to the frame buffer. -Mike