Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!ut-emx!ccwf.cc.utexas.edu From: greg@ccwf.cc.utexas.edu (Greg Harp) Newsgroups: comp.sys.amiga.advocacy Subject: Re: Blitter vs. 040 (was: Computer Architecture question Message-ID: <48829@ut-emx.uucp> Date: 11 May 91 13:38:46 GMT References: <1991May10.180908.29565@convex.com> <6o6Hk!=@cs.psu.edu> <48817@ut-emx.uucp> Sender: news@ut-emx.uucp Reply-To: greg@ccwf.cc.utexas.edu (Greg Harp) Organization: The University of Texas at Austin Lines: 65 In article melling@cs.psu.edu (Michael D Mellinger) writes: >In article <48817@ut-emx.uucp> greg@ccwf.cc.utexas.edu (Greg Harp) writes: > Well, we all know the 040 can do it. In fact, Steve said (and I of course > deleted it before I thought I might refer to it (: ) that he wasn't > interested in how much the 040 can do, but what can be done on the NeXT > with its architecture and OS. > >I think Mach + NeXTStep is a pretty powerful combo. It should have >some longevity. It's probably one of the reasons NeXT has Word >Perfect and Improv; they were relatively easy to write on the NeXT. >Think we will see a Windows version of Improv anytime soon? >Hopefully, by making it easier on developers, a few more will port >their products. That's not really related to the discussion at hand (animation on the NeXT). What I said above basically was me wondering how well animation can be done on a NeXT. The merits of NeXTStep are not on trial (here :). > That's the question Steve asked, I believe. I'm wondering the same thing > myself. Also, would you have to do anything "funny" to directly access the > display memory? You know, Mach/BSD might have something to say about > a program hitting the memory in a place not assigned to it. > >Memory is swapped to disk, or more appropriately removed from memory, >when you run out of memory on the NeXT to make room for whatever you >are doing at the time. Also, on the NeXT most drawing is done(all >that I can think of) by called library routines. I have serious doubts as to whether the memory for the display ever gets swapped out. :) Of course, I guess you could do it if the NeXT allows for multiple virtual screens. You'd only need to have the currently displayed screen in memory at a given time. 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... 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. > Also, hitting the hardware directly kills all that nice device > independance, you know. :) (I _had_ to say it...) > >And it screws you when the NeXT generation of machine is released. In >fact, I doubt if developers write to the display buffer on the NeXT. >The Color NeXT and the NeXTDimension board would surely have broken >any software that did this. Call those highly optimized library >routines. They know what to do when you've got awesome graphics >hardware on your computer(or don't have...). 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? Greg -- Greg Harp |"I was there to match my intellect on national TV, | against a plumber and an architect, both with a PhD." greg@ccwf.cc.utexas.edu| -- "I Lost on Jeopardy," Weird Al Yankovic