melling@cs.psu.edu (Michael D Mellinger) (05/10/91)
In article <3496.tnews@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes:
Speedwise, it's going to be better to have part of a system on one
fast chip and another on another faster chip, than it is to just
have the faster chip. Like the 68030 + Blitter is better than just
a 68030, even though the 68030 can outperfrom the Blitter in most
(all?) cases.
Hmmm. So, how well can the NeXT perform animation? The 68040 is
definitely faster than 2 68030s. In an 040 A3000 does the blitter
become a bottleneck. Meaning could things be done faster if the CPU
was used instead? The blitter must offer some functionality that a
"normal" CPU doesn't.
-Mikeswarren@convex.com (Steve Warren) (05/11/91)
In article <vbcH!4p@cs.psu.edu> melling@cs.psu.edu (Michael D Mellinger) writes: [...] >Hmmm. So, how well can the NeXT perform animation? The 68040 is >definitely faster than 2 68030s. In an 040 A3000 does the blitter >become a bottleneck. Meaning could things be done faster if the CPU >was used instead? The blitter must offer some functionality that a >"normal" CPU doesn't. In the A3000, the 68030 can update display memory faster than the blitter can. This does not mean that there is no advantage to using the blitter (and the blitter does not loose by *that* much). The fact is, if the blitter is used to manage the display and the '030 is able to stay out of display memory, then the '030 will be able to "multiprocess" in parallel with the blitter. So if you have calculations that need to be performed then, it is advantageous to use the blitter to offload graphic manipulations from the CPU. What is the avg. available bandwidth from the NeXT '040 directly into display memory? The performance of the CPU chip is not as important as the availability of the display memory bus to the CPU. -- _. --Steve ._||__ Warren v\ *| V
melling@cs.psu.edu (Michael D Mellinger) (05/11/91)
In article <1991May10.180908.29565@convex.com> swarren@convex.com (Steve Warren) writes:
In the A3000, the 68030 can update display memory faster than the blitter can.
This does not mean that there is no advantage to using the blitter (and the
blitter does not loose by *that* much). The fact is, if the blitter is used
to manage the display and the '030 is able to stay out of display memory, then
the '030 will be able to "multiprocess" in parallel with the blitter. So if
you have calculations that need to be performed then, it is advantageous to use
the blitter to offload graphic manipulations from the CPU.
What is the avg. available bandwidth from the NeXT '040 directly into display
memory? The performance of the CPU chip is not as important as the
availability of the display memory bus to the CPU.
The 040 is equal to at least 3 68030's. One would think that decent
animation could be done on the NeXT. It might just be a matter of
being able to interrupt the OS on a regular enough basis to get smooth
animation, which might be a problem at the current time because the
Mach kernal cannnot be interrupted.
Does anyone know the bandwidth from the NeXT 040 to memory?
-Mikegreg@ccwf.cc.utexas.edu (Greg Harp) (05/11/91)
In article <6o6Hk!=@cs.psu.edu> melling@cs.psu.edu (Michael D Mellinger) writes: > >In article <1991May10.180908.29565@convex.com> swarren@convex.com (Steve Warren) writes: > > What is the avg. available bandwidth from the NeXT '040 directly into display > memory? The performance of the CPU chip is not as important as the > availability of the display memory bus to the CPU. > >The 040 is equal to at least 3 68030's. One would think that decent >animation could be done on the NeXT. It might just be a matter of >being able to interrupt the OS on a regular enough basis to get smooth >animation, which might be a problem at the current time because the >Mach kernal cannnot be interrupted. 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. If Mach can't be interrupted directly that could be a problem. However, with nothing else really running on the machine you should be able to get the CPU time to do a decent job. >Does anyone know the bandwidth from the NeXT 040 to memory? 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. Also, hitting the hardware directly kills all that nice device independance, you know. :) (I _had_ to say it...) 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
jbickers@templar.actrix.gen.nz (John Bickers) (05/11/91)
Quoted from <vbcH!4p@cs.psu.edu> by melling@cs.psu.edu (Michael D Mellinger): > Hmmm. So, how well can the NeXT perform animation? The 68040 is Who knows, who cares. If you're going to do native animations, do them in color, etc. > definitely faster than 2 68030s. In an 040 A3000 does the blitter Really? Faster than 2 68030s at this sort of memory intensive operation? > become a bottleneck. Meaning could things be done faster if the CPU As kdarling points out quite often, things are _already_ done faster if the CPU is used instead. It depends on the kind of animation involved, and for the delta animations (or whatever they are called) the Blitter is next to useless. For some block and line operations too, the Blitter is not useless, but it is slower. Depending on the CPU one happens to have. > was used instead? The blitter must offer some functionality that a > "normal" CPU doesn't. What it offers is limited co-processing. So while on an Amiga 3000, say, the CPU might be able to zap an image to the screen faster than the Blitter, the application should perhaps use the Blitter and let the CPU do other important things alongside it. This doesn't seem to be applicable to delta animations, but it is important when you want to run a line drawing demo alongside a ray tracer, for example. The same thing applies to all the things that can be offloaded onto coprocessors. A 68040 CPU might process a Postscript file a tad faster than a 68020 laser printer, and the same CPU might pump data through a sound thingo (DAC?) faster than a DMA-driven sound chip, and the same CPU might pump data to/from disk faster than a DMA-driven disk IO chip, and the same CPU might draw to the display faster than a drawing chip, but put them all together... ...and you have a giant PClone! :) > -Mike -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Endless variations, make it all seem new" - Devo. ***
melling@cs.psu.edu (Michael D Mellinger) (05/11/91)
In article <3602.tnews@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes: > Hmmm. So, how well can the NeXT perform animation? The 68040 is Who knows, who cares. If you're going to do native animations, do them in color, etc. I would be interested in hearing the results for both the color and monochrome machines. The monochrome NeXT does contain 2-bit gray scale, a million pixels, and alpha channels, so some neat things can be done with it. > definitely faster than 2 68030s. In an 040 A3000 does the blitter Really? Faster than 2 68030s at this sort of memory intensive operation? I'm not sure. Anyone have an 030 and 040 manual handy? There are other factors that come into play though, as someone has already pointed out. The A500 only has a Blitter and the < 1 mip 68000, and it performs great animation. > become a bottleneck. Meaning could things be done faster if the CPU As kdarling points out quite often, things are _already_ done faster if the CPU is used instead. It depends on the kind of animation involved, and for the delta animations (or whatever they are called) the Blitter is next to useless. For some block and line operations too, the Blitter is not useless, but it is slower. Depending on the CPU one happens to have. Let's say the 030. An 040 should be > than the 68000 + blitter. No? What it offers is limited co-processing. So while on an Amiga 3000, say, the CPU might be able to zap an image to the screen faster than the Blitter, the application should perhaps use the Blitter and let the CPU do other important things alongside it. How much does coprocessing matter. Let's say that you can get 10 mips b/w the two of them. A 15 mip 68040 is still going to give you more horsepower(33% more). Some of that might be lost in context switching and for other overhead. How well does the A3000 do animation in its million pixel display mode? That might give us some indication of what the NeXT can do. This doesn't seem to be applicable to delta animations, but it is important when you want to run a line drawing demo alongside a ray tracer, for example. Context switching just needs to be handled properly. Ray tracing for example isn't going to require a lot of blitter time. So, in fact you lose because it can't donate its extra cycles to the ray tracer. I would think the 040 would smoke the blitter/030 combo because you aren't utilizing both Amiga chips to their fullest potential. The 040 Amiga will gain from the blitter that extra time it takes to display a pixel to the screen, but that is small in comparision to the time the actual calculation takes. The same thing applies to all the things that can be offloaded onto coprocessors. A 68040 CPU might process a Postscript file a tad faster than a 68020 laser printer, and the same CPU might pump data through a sound thingo (DAC?) faster than a DMA-driven sound chip, and the same CPU might pump data to/from disk faster than a DMA-driven disk IO chip, and the same CPU might draw to the display faster than a drawing chip, but put them all together... Yes, but if in the next generation machine the power of the CPU is greater than the cumulative power of all the chips in the older machine then you could throw out all of the old chips and replace them by the one chip and get a computer that is just as fast(of course keeping all the chips plus the new CPU would make it even faster). On the NeXT the the I/O and sound are offloaded. The graphics are not of course. -Mike
melling@cs.psu.edu (Michael D Mellinger) (05/11/91)
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.
If Mach can't be interrupted directly that could be a problem. However,
with nothing else really running on the machine you should be able to get
the CPU time to do a decent job.
You can't interrupt Mach. NeXT might be addressing this problem.
They did mention it in NeXTAnswers, but if it's a lot of work(it might
be), who knows how long it will take.
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.
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...).
-Mikegreg@ccwf.cc.utexas.edu (Greg Harp) (05/11/91)
In article <l3eHbse1@cs.psu.edu> 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
es1@cunixb.cc.columbia.edu (Ethan Solomita) (05/12/91)
In article <6o6Hk!=@cs.psu.edu> melling@cs.psu.edu (Michael D Mellinger) writes: > >The 040 is equal to at least 3 68030's. Ah, one second here. Motorola is claiming 20 mips for the 25MHz 040. NeXT claims 15 mips. Well, my A3000 running an 030 is doing 7.6. It seems like 2 68030s to me, not at least 3. > >-Mike > -- Ethan GEORGE BUSH MURDER ASSASSINATE PENTAGON CAPITOL WHITE HOUSE Greetings to the loyal Americans working at the NSA! Enjoy.
melling@cs.psu.edu (Michael D Mellinger) (05/12/91)
In article <1991May11.191434.3615@cunixf.cc.columbia.edu> es1@cunixb.cc.columbia.edu (Ethan Solomita) writes: >The 040 is equal to at least 3 68030's. Ah, one second here. Motorola is claiming 20 mips for the 25MHz 040. NeXT claims 15 mips. Well, my A3000 running an 030 is doing 7.6. It seems like 2 68030s to me, not at least 3. > Ok, we're playing with different #'s here. The 030 NeXT was only 5 mips. Anyway, even if you take an A500 which is less than 1 mip and the blitter you still get awesome graphics animation. If the blitter is approximately equal to an 030, where does the blitter start to lose its advantage? On the 40Mhz Mac IIfx, the 10MHz NuBus is suppose to be a bottleneck. By the way, I though that the IIfx was only around an 8 mip machine. How is Commmodore getting 7.6 out of a 25MHz 030? So, the question again is a 68040 > 68030 + blitter? For example, on a 68040 A3000 is the blitter now the bottle neck? -Mike
elg@elgamy.RAIDERNET.COM (Eric Lee Green) (05/12/91)
From article <vbcH!4p@cs.psu.edu>, by melling@cs.psu.edu (Michael D Mellinger): > In article <3496.tnews@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes: > Hmmm. So, how well can the NeXT perform animation? The 68040 is > definitely faster than 2 68030s. In an 040 A3000 does the blitter > become a bottleneck. Meaning could things be done faster if the CPU > was used instead? The blitter must offer some functionality that a > "normal" CPU doesn't. Just out of curiousity, where is a color card located in the NeXT? On a 10mhz I/O expansion bus? That's the primary failing of most computers... they don't have a fast I/O bus. E.g. these "fast" '386 machines are most often cramming bytes into their super-hi-res VGA cards 16 bits at a time over a 8mhz (or 10mhz) bus... with bank switching, no less, to deal with the fact that you can't fit that much memory into a MS-DOS memory space. What a performance nightmare. From what I understand, the Mac folks have a similar problem with their NuBUS implementation... i.e., the processor can't jam bytes into the framebuffer at anywhere near the processor's top speed. For that matter, neither can the Amiga, in its current incarnations... but the A3000 still has twice the bandwidth into video memory, compared to the typical '386-based PC. The blitter's functionality mostly applies to multitasking environments when you're talking 68040's. Even a 68040 isn't an unlimited resource. Note that there exists software patches for the A3000 to patch the OS's BlitBitMap etc. calls to use the CPU instead of the blitter... but most people still don't do it, because other processes slow down drastically when so much CPU is being used to shove bytes around on the screen. (Even though it DOES speed up the screen scrolling and such). n -- Eric Lee Green (318) 984-1820 P.O. Box 92191 Lafayette, LA 70509 elg@elgamy.RAIDERNET.COM uunet!mjbtn!raider!elgamy!elg
mykes@amiga0.SF-Bay.ORG (Mike Schwartz) (05/12/91)
In article <vbcH!4p@cs.psu.edu> melling@cs.psu.edu (Michael D Mellinger) writes: > >In article <3496.tnews@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes: > > > Speedwise, it's going to be better to have part of a system on one > fast chip and another on another faster chip, than it is to just > have the faster chip. Like the 68030 + Blitter is better than just > a 68030, even though the 68030 can outperfrom the Blitter in most > (all?) cases. > >Hmmm. So, how well can the NeXT perform animation? The 68040 is >definitely faster than 2 68030s. In an 040 A3000 does the blitter >become a bottleneck. Meaning could things be done faster if the CPU >was used instead? The blitter must offer some functionality that a >"normal" CPU doesn't. > >-Mike > The blitter provides parallel computing power. You can decide whether to use the 68040's cycles to render graphics or to do heavy calcuations, whichever the application requires. Another way to describe how this works: The blitter has a shared bus with the CPU. The CPU has 3 buses (at least on an A2500) - CHIP (shared with blitter), ZORRO (slots), and FAST memory bus. While the Blitter blits, the CPU can be accessing either of the other 2 buses to its heart's content. -- **************************************************** * I want games that look like Shadow of the Beast * * but play like Leisure Suit Larry. * ****************************************************
jbickers@templar.actrix.gen.nz (John Bickers) (05/12/91)
Quoted from <g=dHf+d1@cs.psu.edu> by melling@cs.psu.edu (Michael D Mellinger): > I would be interested in hearing the results for both the color and > monochrome machines. The monochrome NeXT does contain 2-bit gray Then go to comp*next* and find out. > Really? Faster than 2 68030s at this sort of memory intensive > operation? > other factors that come into play though, as someone has already Yes, these "other factors" are that it's a memory intensive operation, into an area of memory that is traditionally relatively slow. If the 2 68030s have two independent places to draw in, they'll whomp the 68040 which has one. > Let's say the 030. An 040 should be > than the 68000 + blitter. No? On a machine with the kind of CHIP bus an Amiga 500 has, for example, I believe the Blitter can clear the screen faster than any CPU. If it can't do it faster, it can certainly do it in about the same time. If we make a little diagram... Blit 040 | XX <- off the scale | XX | XX | XX | XX xx -+- XX <- maximum throughput on CHIP bus XX | XX XX | XX XX | XX XX | XX XX | XX ------+------ The 040 is faster, but the Blitter is as fast as it needs to be. What makes the A3000 CPU faster than the blitter is that the maximum throughput on the CHIP bus has been increased (doubled?). And what makes a 030 CPU on previous models better for certain cases is "effective throughput". For example, the blitter may be maxing out, but perhaps 10% of the data it is moving is superfluous, and is avoided by the CPU which is driven by more customised code. > How much does coprocessing matter. Let's say that you can get 10 mips It matters a lot when you have differences like this in what you're dealing with. For example, suppose (and these figures are pure imagination on my part, it's amazing how many people aren't EEs in this thread :) a 68040 can do 100 things on the slow device in 1 second, and 1000 things on the fast device in 1 second. If you swap it between the two devices, in the .01 of a second that it takes to do a slow operation, you could have had it doing 10 fast operations. If you have two jobs getting equal time, and one takes 1000 slow operations, the other takes 10000 fast operations, and you swap every .01 of a second, then your slow job will take 20 seconds instead of the optimal 10, and your fast job will take 20 seconds instead of the optimal 10. Now if you add a coprocessor that takes 1 slow operation to trigger, and can do the rest itself... If you move the figures around (how often you swap, etc), you'll see how the relative performance balances, and you'll also see that the coprocessor system should win most of the time, until it starts taking as many operations to set it up as it does to do the slow job oneself. > and for other overhead. How well does the A3000 do animation in its > million pixel display mode? That might give us some indication of > what the NeXT can do. Why? Isn't the Amiga 3000 a better design? > Context switching just needs to be handled properly. Ray tracing for > example isn't going to require a lot of blitter time. So, in fact you It's not going to require any blitter time. The line drawing is the blitter intensive task, and you can keep it going full bore at that. > -Mike -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Endless variations, make it all seem new" - Devo. ***
melling@cs.psu.edu (Michael D Mellinger) (05/13/91)
In article <mykes.2510@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes:
The blitter provides parallel computing power. You can decide whether to
use the 68040's cycles to render graphics or to do heavy calcuations, whichever
the application requires. Another way to describe how this works:
The blitter has a shared bus with the CPU. The CPU has 3 buses (at least on
an A2500) - CHIP (shared with blitter), ZORRO (slots), and FAST memory bus.
While the Blitter blits, the CPU can be accessing either of the other 2 buses
to its heart's content.
How fast are the Amiga buses? If you use the 040 to render graphics,
it must access the chip RAM correct? So there will be bus contention?
Wouldn't it be better to let the 68040 just have the bus? How much
memory does video RAM take up in the 680x400(4096 colors) graphics
mode or a better graphics mode. When you fill up chip RAM you have a
problem. Do all the current Amiga's ship with the 2MB RAM chip set?
-Mikefarren@well.sf.ca.us (Mike Farren) (05/13/91)
melling@cs.psu.edu (Michael D Mellinger) writes: > As kdarling points out quite often, things are _already_ done > faster if the CPU is used instead. It depends on the kind of > animation involved, and for the delta animations (or whatever they > are called) the Blitter is next to useless. For some block and line > operations too, the Blitter is not useless, but it is slower. > Depending on the CPU one happens to have. >Let's say the 030. An 040 should be > than the 68000 + blitter. No? Not necessarily. There are other limitations. Memory bandwidth is the biggest one - if you have one processor, you are absolutely limited by the memory bandwidth for ALL operations, whereas if you have two, even though they might individually be less than half the speed of the faster single processor, they can multiplex their memory accesses - just like the Amiga blitter already does. What is better, a 68040 trying to run two separate tasks at 25MHz, or a 68000 plus a blitter both driving the memory full out? Answer - probably the 68040, but you cannot guarantee that. It depends on the design of the whole system. >How much does coprocessing matter. Let's say that you can get 10 mips >b/w the two of them. A 15 mip 68040 is still going to give you more >horsepower(33% more). Again, NOT necessarily. A MIP rating of the individual processor presumes that it has full access to all resources, and commonly is not a real-world measure of a system as it actually manifests in the real world, complete with limited memory speed, and, as you say, context switching and other overhead. >How well does the A3000 do animation in its million pixel display mode? A bit of a quandry, here, as the A3000 does not currently have a common megapixel display mode. However, if the Mpixel display is designed correctly, the animation should be no slower than animation at 320X200, provided, of course, that you're only changing the same number of pixels from frame to frame. In fact, I would expect a newly-designed Mpixel display to actually go faster, as the lessons learned in designing the Amiga custom chips are applied, and the slow CHIP memory speed is gotten around. (A lesson, BTW, which IBM seems to have learned, except that they are about two generations behind :-) >Yes, but if in the next generation machine the power of the CPU is >greater than the cumulative power of all the chips in the older >machine then you could throw out all of the old chips and replace them >by the one chip and get a computer that is just as fast(of course >keeping all the chips plus the new CPU would make it even faster). If this were so, then the only technical challenge to EEs would be to make chips as fast as possible, and all the computers we use would be some fancy variant of ECL, running at 500MHz, and requiring Niagara Falls for cooling :-) Seriously - it ain't anywhere NEAR that simple. I've personally designed systems using 8085's (an eight-bit chip) which were comparable in speed to most Intel 286 systems. I've also worked on systems so limited by memory access and I/O speeds that you could have hooked a Cray CPU up to 'em and still gone no faster than an Apple II. -- Mike Farren farren@well.sf.ca.us
melling@cs.psu.edu (Michael D Mellinger) (05/13/91)
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.
-Mikewaynekn@techbook.com (Wayne Knapp) (05/13/91)
swarren@convex.com (Steve Warren) writes: >In the A3000, the 68030 can update display memory faster than the blitter can. >This does not mean that there is no advantage to using the blitter (and the >blitter does not loose by *that* much). The fact is, if the blitter is used >to manage the display and the '030 is able to stay out of display memory, then >the '030 will be able to "multiprocess" in parallel with the blitter. So if >you have calculations that need to be performed then, it is advantageous to use >the blitter to offload graphic manipulations from the CPU. Two three things wrong with this. 1) The blitter is seldom used for animation. ANIM players use the CPU, always. The blitter is often used for brush moving, but not for real animation. 2) Even the a 68000 can scream past the blitter, depending on the blit. For simple large blits, the blitter is much faster. For very complex smaller blits a 68000 routine can be written that is much faster than the blitter. I done it many times in my code. There is a common trade off that can be made between memory used, nature of the code and speed of the code. The blitter is very general and do to that nature can be hard pressed to complete with specail purpose code. By using all the 68000 registers and extra banks of memory it is possible to reduce the number of memory accesses required in a very complex blit. (like, restoring the background from a cookie cut blit) Now there are some real constraints, if you are working on something that requires a LOT of barrel shifting, there is no way a 68000 can keep up with a blitter. Maybe a 68030, but not a 68000. 3) Everyone is always shouting about how the CPU and Blitter can run at the same time. But in real life, it rarely happens. There are several reasons for this. a) The blitter requires CPU to adjust it's registers between bitplanes. b) Most blits are short in time, too short for the operations system to allow the CPU much chance to run. c) It is very hard and complex to pull off. Now, it can be done, and I'm sure someone has some has. But not as a general rule, and certainly not something you get for free. Now I realize the need to have a blitter in the Amiga, but not for speed in the higher-end Amigas, but for BACKWARD compatibility. As for speed, es. in 68020+ Amigas I think the blitter is VASTLY overrated. Anyway that is MHO. Since I make my living from writing real-time graphics/ animation software, I suppect I used the blitter about 10,000 more than most people. Wayne Knapp Consultanting Assoc. Hash Enterprises -- waynekn@techbook.COM ...!{tektronix!nosun,uunet}techbook!waynekn Public Access UNIX at (503) 644-8135 (1200/2400) Voice: +1 503 646-8257 Public Access User --- Not affiliated with TECHbooks
dvljhg@cs.umu.se (J|rgen Holmberg) (05/13/91)
In article <a29H2#n2@cs.psu.edu> melling@cs.psu.edu (Michael D Mellinger) writes: > >In article <mykes.2510@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: > > The blitter provides parallel computing power. You can decide whether to > use the 68040's cycles to render graphics or to do heavy calcuations, whichever > the application requires. Another way to describe how this works: > > The blitter has a shared bus with the CPU. The CPU has 3 buses (at least on > an A2500) - CHIP (shared with blitter), ZORRO (slots), and FAST memory bus. > While the Blitter blits, the CPU can be accessing either of the other 2 buses > to its heart's content. > >How fast are the Amiga buses? If you use the 040 to render graphics, >it must access the chip RAM correct? So there will be bus contention? >Wouldn't it be better to let the 68040 just have the bus? Yes, of course it would be better. If you want to do some serious calculations at the same time you could have the CPU working in fast RAM and the blitter could do the actual display without loosing any CPU power whatsoever. >How much >memory does video RAM take up in the 680x400(4096 colors) graphics >mode or a better graphics mode. 680? 640x400x6/8 bytes I would think. >When you fill up chip RAM you have a >problem. Do all the current Amiga's ship with the 2MB RAM chip set? > >-Mike Nope, most amigas have only 1MB chip ram. The only amiga to ship with the 2MB chip set is the A3000(T) at the moment. A wild guess is that the other amigas soon will have the new chip set, unless they want to wait to include the new custom chips as well :-) /Jorgen -- email dvljhg@cs.umu.se | DUMII: Sentinel of the scales Everything I say is always true, just apply it to the right reality. "Credo, quia absurdum est." Credo (dei) in absurdum est?
jbickers@templar.actrix.gen.nz (John Bickers) (05/13/91)
Quoted from <a29H2#n2@cs.psu.edu> by melling@cs.psu.edu (Michael D Mellinger): > How fast are the Amiga buses? If you use the 040 to render graphics, Weren't you going to go away and find out how fast the NeXT's one is? > -Mike -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Endless variations, make it all seem new" - Devo. ***
jbickers@templar.actrix.gen.nz (John Bickers) (05/13/91)
Quoted from <bs9Hi=o2@cs.psu.edu> by melling@cs.psu.edu (Michael D Mellinger): > 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 Why not locate this free version of X-Windows, and the free X-Windows .GL player, and go find out how well the animations play back? Don't you have animation software floating around for the NeXT in the PD or shareware departments? The widget has been around for years now, so surely someone has done something along these lines. > -Mike -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Endless variations, make it all seem new" - Devo. ***
mykes@amiga0.SF-Bay.ORG (Mike Schwartz) (05/14/91)
In article <a29H2#n2@cs.psu.edu> melling@cs.psu.edu (Michael D Mellinger) writes: > >In article <mykes.2510@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: > > The blitter provides parallel computing power. You can decide whether to > use the 68040's cycles to render graphics or to do heavy calcuations, whichever > the application requires. Another way to describe how this works: > > The blitter has a shared bus with the CPU. The CPU has 3 buses (at least on > an A2500) - CHIP (shared with blitter), ZORRO (slots), and FAST memory bus. > While the Blitter blits, the CPU can be accessing either of the other 2 buses > to its heart's content. > >How fast are the Amiga buses? If you use the 040 to render graphics, >it must access the chip RAM correct? So there will be bus contention? >Wouldn't it be better to let the 68040 just have the bus? How much >memory does video RAM take up in the 680x400(4096 colors) graphics >mode or a better graphics mode. When you fill up chip RAM you have a >problem. Do all the current Amiga's ship with the 2MB RAM chip set? > >-Mike Again, if you use the 040 to do graphics instead of a blitter, you lose the ability to do things in PARALLEL with the CPU. The 040 has a limited number of Cycles (yes gobs of them), and using them for rendering ovbiously gives you less of them for doing what work your applications do (or your multitasking OS...). You really should go and get the Amiga Hardware Reference Manual (Addison-Wesley publishing Company, blue cover) and educate yourself a little more... The custom chips in the Amiga can and often do cause the CPU to wait when it accessis CHIP RAM. If the blitter is running in NASTY mode, for example, it will steal every possible cycle from the CPU (on the CHIP BUS only). If you are using some of the higher resolution graphics modes (like 640x400x16 colors), the display hardware steals 100% of the CPU (and blitter) cycles except for horizontal and vertical retrace. The Amiga workbench is 640x200/400 x 2 planes, because it steals no cycles in this mode. Your question about graphics modes shows that you haven't learned much at all about the Amiga (RTFM, please). To get 640x400x4096 colors, you can use a single bitplane of 32,000 bytes, but your graphics mode is seriously limited (you have to do EVERYTHING with the copper). In HAM mode, you can't go 680 horizontal, but you can open 10 (96K each) 4096 (6 plane) 320x400 screens in 1Meg of CHIP RAM. The Amiga does support overscan, so you can get hirhger resolutions (I'm using 704x484). The Amiga 500 doesn't even ship with 1Meg of RAM (the 500P does), and it is fully able to run the entire Amiga OS (multitasking and all), and virtually all applications for the Amiga (except the very few that require 1+ memory). -- **************************************************** * I want games that look like Shadow of the Beast * * but play like Leisure Suit Larry. * ****************************************************
melling@cs.psu.edu (Michael D Mellinger) (05/14/91)
In article <mykes.2568@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes:
Again, if you use the 040 to do graphics instead of a blitter, you lose the ability
to do things in PARALLEL with the CPU. The 040 has a limited number of Cycles (yes
gobs of them), and using them for rendering ovbiously gives you less of them for
doing what work your applications do (or your multitasking OS...).
What am I missing here? You have 15 mips in 1 second or you get 12
mips the 030 + blitter. Does it really matter if they are running in
parallel as long as the bus isn't limiting you?
The custom chips in the Amiga can and often do cause the CPU to wait when it
accessis CHIP RAM. If the blitter is running in NASTY mode, for example, it will
steal every possible cycle from the CPU (on the CHIP BUS only). If you are using
some of the higher resolution graphics modes (like 640x400x16 colors), the display
hardware steals 100% of the CPU (and blitter) cycles except for horizontal and
vertical retrace. The Amiga workbench is 640x200/400 x 2 planes, because it
steals no cycles in this mode.
So, the blitter is stealing from the faster chip, the 68030?
Your question about graphics modes shows that you haven't learned much at all
about the Amiga (RTFM, please). To get 640x400x4096 colors, you can use a single
bitplane of 32,000 bytes, but your graphics mode is seriously limited (you have to
do EVERYTHING with the copper). In HAM mode, you can't go 680 horizontal, but you
can open 10 (96K each) 4096 (6 plane) 320x400 screens in 1Meg of CHIP RAM. The Amiga
does support overscan, so you can get hirhger resolutions (I'm using 704x484).
Yeah, the Amiga has a dozen different graphics modes. That's nice.
It will probably have a dozen more before the Amiga dies. In the mean
time, the blitter is on its way to becoming the bottleneck in the
system, if it already hasn't.
The Amiga 500 doesn't even ship with 1Meg of RAM (the 500P does), and it is fully
able to run the entire Amiga OS (multitasking and all), and virtually all applications
for the Amiga (except the very few that require 1+ memory).
Yes, so what! Are we bragging about how few paper clips we wasted?
Memory is cheap. We just bought 16MB of memory for $650 for our NeXT.
Functionality is more important. On the NeXT we have an OS that
supports 24 bit color, has memory protection, virtual memory, and does
much more.
-Mikemykes@amiga0.SF-Bay.ORG (Mike Schwartz) (05/15/91)
In article <viaHiuz3@cs.psu.edu> melling@cs.psu.edu (Michael D Mellinger) writes: > >In article <mykes.2568@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: > > Again, if you use the 040 to do graphics instead of a blitter, you lose the ability > to do things in PARALLEL with the CPU. The 040 has a limited number of Cycles (yes > gobs of them), and using them for rendering ovbiously gives you less of them for > doing what work your applications do (or your multitasking OS...). > >What am I missing here? You have 15 mips in 1 second or you get 12 >mips the 030 + blitter. Does it really matter if they are running in >parallel as long as the bus isn't limiting you? > The 040 is just as much an option for the Amiga as it is for the NeXt. What you are missing is 15Mips in 1 second PLUS THE BLITTER. Take a course in parallel processing. > The custom chips in the Amiga can and often do cause the CPU to wait when it > accessis CHIP RAM. If the blitter is running in NASTY mode, for example, it will > steal every possible cycle from the CPU (on the CHIP BUS only). If you are using > some of the higher resolution graphics modes (like 640x400x16 colors), the display > hardware steals 100% of the CPU (and blitter) cycles except for horizontal and > vertical retrace. The Amiga workbench is 640x200/400 x 2 planes, because it > steals no cycles in this mode. > >So, the blitter is stealing from the faster chip, the 68030? ONLY if you are stupid enough to deliberately cause this contention. The blitter can have ALL the cycles it wants while your CPU does work not related to graphics. Unlike your NeXt's DSP, the blitter is actually useful a LOT of the time (and both run in parallel). > > Your question about graphics modes shows that you haven't learned much at all > about the Amiga (RTFM, please). To get 640x400x4096 colors, you can use a single > bitplane of 32,000 bytes, but your graphics mode is seriously limited (you have to > do EVERYTHING with the copper). In HAM mode, you can't go 680 horizontal, but you > can open 10 (96K each) 4096 (6 plane) 320x400 screens in 1Meg of CHIP RAM. The Amiga > does support overscan, so you can get hirhger resolutions (I'm using 704x484). > >Yeah, the Amiga has a dozen different graphics modes. That's nice. >It will probably have a dozen more before the Amiga dies. In the mean >time, the blitter is on its way to becoming the bottleneck in the >system, if it already hasn't. > The only bottleneck here is your opinion and not anything to do with reality. You just made my kill file. > The Amiga 500 doesn't even ship with 1Meg of RAM (the 500P does), and it is fully > able to run the entire Amiga OS (multitasking and all), and virtually all applications > for the Amiga (except the very few that require 1+ memory). > >Yes, so what! Are we bragging about how few paper clips we wasted? >Memory is cheap. We just bought 16MB of memory for $650 for our NeXT. >Functionality is more important. On the NeXT we have an OS that >supports 24 bit color, has memory protection, virtual memory, and does >much more. > The only thing wasted is the money you'd spend on a NeXt. If I wanted one, I'd go and buy one, but it isn't even in the least interesting to me. >-Mike -- **************************************************** * I want games that look like Shadow of the Beast * * but play like Leisure Suit Larry. * ****************************************************
lindblad@cc.helsinki.fi (05/15/91)
> when you're talking 68040's. Even a 68040 isn't an unlimited resource. Note > that there exists software patches for the A3000 to patch the OS's > BlitBitMap etc. calls to use the CPU instead of the blitter... but most Where can I find such beasts? -- Jarkko Lindblad lindblad@cc.helsinki.fi
caw@miroc.Chi.IL.US (Christopher A. Wichura) (05/15/91)
In article <viaHiuz3@cs.psu.edu> melling@cs.psu.edu (Michael D Mellinger) writes: > >In article <mykes.2568@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: > >> Again, if you use the 040 to do graphics instead of a blitter, you lose the ability >> to do things in PARALLEL with the CPU. The 040 has a limited number of Cycles (yes >> gobs of them), and using them for rendering ovbiously gives you less of them for >> doing what work your applications do (or your multitasking OS...). > >What am I missing here? You have 15 mips in 1 second or you get 12 >mips the 030 + blitter. Does it really matter if they are running in >parallel as long as the bus isn't limiting you? Talking about dense! You just don't get it, do you? Using the blitter in parallel, even if it might be a bit slower than an 040 running balls out doing all your graphical work, does not necessarily make the 040 faster. You could start the blitter on a job and then have the 030 calculate the next job while the blitter is working. When the blitter is done the next job can be started instantly. With the 040 you would finish the job and then have to prepare the next in a synchronous manner. The other thing to consider is that the Amiga is a multitasking machine. Yes, the 040 might be able to render stuff faster than the blitter (this is a point which I feel really depends on the application), it has to stop doing other things and actually do the graphics. Consider what would happen if all the screen updates on the Amiga's workbench were done by CPU and not the blitter. Say I'm running a ray tracer in the background. If I move a window, or a cli window scrolls, updating the screen is going to steal CPU time from the ray tracer. Using the blitter, the display might not be updated as fast as it possibly could, but the CPU cost to do it is near nil because the blitter is doing the grunt work and thus the ray tracer doesn't get locked out as long. >So, the blitter is stealing from the faster chip, the 68030? Only in CHIP memory, of which there is a relatively small amount compared to FAST memory. Outside of things that HAVE to be in CHIP, the Amiga will use FAST memory first by default. Thus, most program code is loaded into FAST memory, and any number crunching type program (such as a ray tracer or spread sheet) will have its data storage in FAST memory as well. So it doesn't matter if the blitter is stealing cycles from the CPU's access to CHIP memory. >It will probably have a dozen more before the Amiga dies. In the mean >time, the blitter is on its way to becoming the bottleneck in the >system, if it already hasn't. Again, this depends on the application. For general usage, I'd much rather have the blitter used as it is now. It helps the system AS A WHOLE run faster. Now, I'm no multimedia guy, but for some apps I can see you would want to run an 040 balls out for extra rendering speed. That's a choice the designed of the software will have to make. -=> CAW Christopher A. Wichura Multitasking. Just DO it. caw@miroc.chi.il.us (my amiga) ...the Amiga way... u12401@uicvm.uic.edu (school account)
melling@cs.psu.edu (Michael D Mellinger) (05/15/91)
Keep it to 80 columns please.
In article <mykes.2600@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes:
The 040 is just as much an option for the Amiga as it is for the NeXt. What you are
missing is 15Mips in 1 second PLUS THE BLITTER. Take a course in parallel processing.
Yes, but you could be doing graphics faster if you let the 040 do the
work, since it is much faster than the the blitter. Another point
that I wanted to make is that the NeXT currently has as much
horsepower as the A3000. Amiga users have in the past bashed the NeXT
because they felt that it was incapable of doing animation. One of
their complaints was "no games."
ONLY if you are stupid enough to deliberately cause this contention. The blitter can
have ALL the cycles it wants while your CPU does work not related to graphics. Unlike
your NeXt's DSP, the blitter is actually useful a LOT of the time (and both run in
parallel).
Someone in a previous post mentioned that very rarely does the blitter
get to operate w/o the aid of the CPU. I could look up the post. He
said something about the CPU being necessary for changing registers.
Tell me more about the DSP needing the CPU. One of the demos that
comes with the NeXT runs a Mandelbrot program using the DSP and CPU
concurrently.
The only bottleneck here is your opinion and not anything to do with reality. You
just made my kill file.
Then why is there a public domain program to allow an Amiga user to
use CPU instead of the blitter for graphic's operations? Closing your
eyes and ears isn't going to change anything.
The only thing wasted is the money you'd spend on a NeXt. If I wanted one, I'd
go and buy one, but it isn't even in the least interesting to me.
"Amiga or die!" Is this your battle cry?
-MikeMBS110@psuvm.psu.edu (That neat guy, Mark Sachs) (05/15/91)
In article <0r6Hnxt1@cs.psu.edu>, melling@cs.psu.edu (Michael D Mellinger) says: > >In article <1991May11.191434.3615@cunixf.cc.columbia.edu> >es1@cunixb.cc.columbia.edu (Ethan Solomita) writes: > > >The 040 is equal to at least 3 68030's. > > Ah, one second here. Motorola is claiming 20 mips for the > 25MHz 040. NeXT claims 15 mips. Well, my A3000 running an 030 is > doing 7.6. It seems like 2 68030s to me, not at least 3. > > > >Ok, we're playing with different #'s here. The 030 NeXT was only 5 >mips. Anyway, even if you take an A500 which is less than 1 mip and >the blitter you still get awesome graphics animation. If the blitter >is approximately equal to an 030, where does the blitter start to lose >its advantage? On the 40Mhz Mac IIfx, the 10MHz NuBus is suppose to >be a bottleneck. By the way, I though that the IIfx was only around >an 8 mip machine. How is Commmodore getting 7.6 out of a 25MHz 030? > >So, the question again is a 68040 > 68030 + blitter? For example, on >a 68040 A3000 is the blitter now the bottle neck? Sigh... I don't know why I'm even bothering to say this, but... 1. NO. IT IS NOT A BOTTLENECK. IT ISN'T, ISN'T, ISN'T. If you really want to you can feed all the graphics stuff through the 68030 and ignore the blitter completely. Pretend it doesn't exist. However, you can take advantage of its being a coprocessor and let it do graphics/memory-move stuff while the 68030 does the important CPU stuff. Multiprocessing, get it? Pretty neat. And 68030 + Blitter running flat out WILL ALWAYS be faster than 68030 running flat out. Period. Maybe this easy to understand diagram will help you. What Mike Thinks Reality _________ ____________ \ \_________ _________ <- 68030 / Blitter _________/ ____________ 68030 ____________ <- Blitter Got it? 2. Now if 68030 + Blitter > 68030... doesn't this mean: 68040 + Blitter > 68040? Drop a 68040 into an Amiga, and whatever miniscule speed advantage the NeXT may or may not have will be stomped, once again. Now can we please declare this thread closed? /Mark "Remixed for Common Household Appliances" Sachs IS: MBS110@psuvm.psu.edu\ | STEVEVAX Administration HQ, World Domination & Bake Sales Ltd. || //AMIGA|| | DISCLAIMER: It's NOT MY FAULT. Kei and Yuri forced me to say it.||\X/ Power|| \== "I think this calls for some diabolical laughter! RAAH HA HA HA HA HA!" ==/
jbickers@templar.actrix.gen.nz (John Bickers) (05/15/91)
Quoted from <viaHiuz3@cs.psu.edu> by melling@cs.psu.edu (Michael D Mellinger): > mips the 030 + blitter. Does it really matter if they are running in > parallel as long as the bus isn't limiting you? The bus IS limiting <insert appropriate thingo here>. Someone went to a lot of trouble to draw up a little diagram for you a while back - take another look. > Functionality is more important. On the NeXT we have an OS that > supports 24 bit color, has memory protection, virtual memory, and does So have you got any animation software yet? > -Mike -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Endless variations, make it all seem new" - Devo. ***
melling@cs.psu.edu (Michael D Mellinger) (05/15/91)
In article <caw.0521@miroc.Chi.IL.US> caw@miroc.Chi.IL.US (Christopher A. Wichura) writes: Talking about dense! You just don't get it, do you? Using the blitter in parallel, even if it might be a bit slower than an 040 running balls out doing all your graphical work, does not necessarily make the 040 faster. You could start the blitter on a job and then have the 030 calculate the next job while the blitter is working. When the blitter is done the next job can be started instantly. With the 040 you would finish the job and then have to prepare the next in a synchronous manner. Hmmm. 1+1 != 3. You could have the 68040 do the graphical work then do the calculations then do the graphical work all in the same time that it took the blitter to do the the graphical work and the 68030 to do the calculations. In other words, the 68040 gets more work done in the same period of time. The other thing to consider is that the Amiga is a multitasking machine. Yes, the 040 might be able to render stuff faster than the blitter (this is a point which I feel really depends on the application), it has to stop doing other things and actually do the graphics. Consider what would happen if all the screen updates on the Amiga's workbench were done by CPU and not the blitter. Say I'm running a ray tracer in the background. If I move a window, or a cli window scrolls, updating the screen is going to steal CPU time from the ray tracer. Using the blitter, the display might not be updated as fast as it possibly could, but the CPU cost to do it is near nil because the blitter is doing the grunt work and thus the ray tracer doesn't get locked out as long. So the CPU has to stop and update the screen. What's the big deal? You have 2*N mips in your machine and N of those mips are only capable of bit manipulation, while the other N mips can be used for your ray tracer. Drop an 040 in the A3000 and you now have 3*N mips for calculations and you still only have have N mips for bit manipulations. N = 68030, of course. >So, the blitter is stealing from the faster chip, the 68030? Only in CHIP memory, of which there is a relatively small amount compared to FAST memory. Outside of things that HAVE to be in CHIP, the Amiga will use FAST memory first by default. Thus, most program code is loaded into FAST memory, and any number crunching type program (such as a ray tracer or spread sheet) will have its data storage in FAST memory as well. So it doesn't matter if the blitter is stealing cycles from the CPU's access to CHIP memory. Assuming you have 1 meg. Amiga. When you exand the Amiga to 1 meg. is 512K chip RAM and 512 FAST ram? Again, this depends on the application. For general usage, I'd much rather have the blitter used as it is now. It helps the system AS A WHOLE run faster. Now, I'm no multimedia guy, but for some apps I can see you would want to run an 040 balls out for extra rendering speed. That's a choice the designed of the software will have to make. Are people still writing directly to the hardware on the Amiga? Dedicated graphics hardware is nice but if all your software depends on specific hardware then you are not going to be able to take advantage of future advances. If you think the 68040 is fast wait until MIPS/Compaq/Microsoft drop their R4000 bomb(looks like next year). It's going to be almost three times faster than the 68040. On the Amiga that's N mips dedicated to graphics and 9*N mips dedicated to calculations. -Mike
davewt@NCoast.ORG (David Wright) (05/15/91)
In article <?iaHpry4@cs.psu.edu> melling@cs.psu.edu (Michael D Mellinger) writes: >Hmmm. 1+1 != 3. You could have the 68040 do the graphical work then >do the calculations then do the graphical work all in the same time >that it took the blitter to do the the graphical work and the 68030 to >do the calculations. In other words, the 68040 gets more work done in >the same period of time. Can you REALLY be this dumb? The point people have been trying to make is that if a 68030+blitter is faster than just a 68030, then a 68040+blitter will be faster than just a 68040. Of course a 68040 will be able to update screens faster than the blitter in many cases, but in doing so it will be stealing time that could have been handling OTHER programs, just to update the display. Gee, this sounds just like the nExt. No wonder you can't understand it. Where will your argument stand with a 3000 with an 040 in it? You are still trying to compare a 68030 machine to a 68040 machine, like you were 3 months ago. Don't you notice how SLOW the nExt updates it's windows and displays (not what is happening within them, but move a window around and see how long it takes to redraw the display (especially with 5 or 6 windows open)) when compared even to an Amiga 500, a 16-bit machine running at 7Mhz. > >So the CPU has to stop and update the screen. What's the big deal? >You have 2*N mips in your machine and N of those mips are only capable >of bit manipulation, while the other N mips can be used for your ray >tracer. Drop an 040 in the A3000 and you now have 3*N mips for >calculations and you still only have have N mips for bit >manipulations. The point is, what if you have SOMETHING ELSE running as WELL AS the ray tracer. Why should EVERY program, EVERYWHERE have to slow down just to make the screen update MAYBE 1/10th of a seccond faster? >Assuming you have 1 meg. Amiga. When you exand the Amiga to 1 meg. is >512K chip RAM and 512 FAST ram? Don't you mean "assuming you have at least 1 meg Amiga"? In fact, under some A500's the first meg is 512k of CHIP, and 512k of "slow fast" RAM. On other Amiga's it is 512k CHIP and 512k "true" FAST RAM. Anything you add beyond that is always "fast" RAM. So my 3000 has 2 megs of CHIP RAM, and 16 megs of FAST RAM. >Are people still writing directly to the hardware on the Amiga? What is this? The old "oops I'm getting my butt kicked here, lets quick change the subject to something else" trick? We were talking about whether a 68030+blitter is faster than just a 68030, and therefore whether a 68040+blitter is faster than just a 68040. You just don't seem to understand that: 1) Using the blitter is NOT mandatory 2) There are ways to even disable it at the system call level 3) Having two CPUs is ALWAYS faster than just 1, as long as you pick the jobs that each does correctly Dave
ecarroll@maths.tcd.ie (Eddy Carroll) (05/15/91)
In article <00674001103@elgamy.RAIDERNET.COM> elg@elgamy.RAIDERNET.COM (Eric Lee Green) writes: > but the A3000 still has twice the bandwidth into video >memory, compared to the typical '386-based PC. Probably closer to five times in the low-resolution modes and ten times for (four-colour) hires, since standard VGA only gives either 1 or 3 out of every 5 cycles to the CPU (the rest are needed for screen refresh), and the A3000 has a 32 bit path to chip ram as opposed to VGA's 16 bit (or even 8 bit!) >Note that there exists software patches for the A3000 to patch the OS's >BltBitMap etc. calls to use the CPU instead of the blitter... but most >people still don't do it, because other processes slow down drastically >when so much CPU is being used to shove bytes around on the screen. (Even >though it DOES speed up the screen scrolling and such). n As author of one such program (CpuBlit), I'd like to make a small correction. CpuBlit has a variety of options that let you configure it to only use the CPU for blitting if there are no other processes waiting to run. This way, you get the increased speed when available without paying the penalty in system performance. (Check comp.sources.amiga for the latest version.) Even using the 68030, you don't get much better than a doubling in speed, and this can be attributed to the 32-bit access the 68030 has to CHIP ram. Note that this is also only for the simplest possible blit: copying memory without changing the bit alignment. CpuBlit doesn't even attempt to handle blits that are more complicated than this, since it works out much slower than letting the blitter do the work. If you get the chance (I don't mean Eric specifically) have a look at the source code for a Windows 3 display driver, and look at how much work is needed to do a general three-operand blit in software; it's HUGE (Yes, I know the Amiga's blitter doesn't handle all the cases that Windows does). As someone pointed out already, the limiting factor is the speed of the custom chip bus, and the blitter already utilises that pretty fully (albeit at 16 bits). Other than the 32 bit vs 16 bit speedup, there's not much scope for improvement (except for a new, faster custom chipset of course :-) Eddy -- Eddy Carroll ----* Genuine MUD Wizard | "You haven't lived until ADSPnet: cbmuk!cbmuka!quartz!ecarroll | you've died in MUD!" Internet: ecarroll@maths.tcd.ie | -- Richard Bartle
chucks@pnet51.orb.mn.org (Erik Funkenbusch) (05/16/91)
elg@elgamy.RAIDERNET.COM (Eric Lee Green) writes: >Just out of curiousity, where is a color card located in the NeXT? On a >10mhz I/O expansion bus? That's the primary failing of most computers... >they don't have a fast I/O bus. E.g. these "fast" '386 machines are most >often cramming bytes into their super-hi-res VGA cards 16 bits at a time >over a 8mhz (or 10mhz) bus... with bank switching, no less, to deal with >the fact that you can't fit that much memory into a MS-DOS memory space. >What a performance nightmare. From what I understand, the Mac folks have a >similar problem with their NuBUS implementation... i.e., the processor >can't jam bytes into the framebuffer at anywhere near the processor's top >speed. For that matter, neither can the Amiga, in its current >incarnations... but the A3000 still has twice the bandwidth into video >memory, compared to the typical '386-based PC. No, the 3000 has an Asynchronous bus, which means that the bus is as fast as you want it to be. and many 386's come with an EISA or Micro Channel bus that is fully 32 bits and possibly asynchronous as well. course these machines are also MUCH more expensive than standard ISA buses. > >The blitter's functionality mostly applies to multitasking environments >when you're talking 68040's. Even a 68040 isn't an unlimited resource. Note >that there exists software patches for the A3000 to patch the OS's >BlitBitMap etc. calls to use the CPU instead of the blitter... but most >people still don't do it, because other processes slow down drastically >when so much CPU is being used to shove bytes around on the screen. (Even >though it DOES speed up the screen scrolling and such). n > >-- >Eric Lee Green (318) 984-1820 P.O. Box 92191 Lafayette, LA 70509 >elg@elgamy.RAIDERNET.COM uunet!mjbtn!raider!elgamy!elg .--------------------------------------------------------------------------. | UUCP: {amdahl!tcnet, crash}!orbit!pnet51!chucks | "I know he's come back | | ARPA: crash!orbit!pnet51!chucks@nosc.mil | from the dead, but do | | INET: chucks@pnet51.orb.mn.org | you really think he's | |-------------------------------------------------| moved back in?" | | Amiga programmer at large, employment options | Lou Diamond Philips in | | welcome, inquire within. | "The First Power". | `--------------------------------------------------------------------------'
daveh@cbmvax.commodore.com (Dave Haynie) (05/16/91)
In article <bs9Hi=o2@cs.psu.edu> melling@cs.psu.edu (Michael D Mellinger) writes: >I don't think the NeXTstation has double-buffering. The NeXTs very likely use VRAM for their display. This has the advantage of spilling off alot of video fetch overhead from that memory, so the CPU can get at it reasonably fast. On the downside, it makes the display memory a very specific thing, architecturally constrained to a small chunk of RAM. Double buffering can be designed in, but it's nearly impossible to get the kind of N-buffering that can be done on an Amiga. >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. That's the reason for most Mac graphics being slow. NuBus uses a 10MHz clock, and a minimal NuBus cycle is two clocks long, so the fastest access to NuBus based resources is 200ns. That's really not all that bad, most DRAM systems on 25MHz 68030s run in 200ns (effectively faster with burst, though). The real problem is one of synchronization. A 68030 cycle must "synch up" to the 10MHz NuBus clock, then "synch down" again to complete the cycle. So in reality, the 68030 may take two or three extra cycles spent synchronizing to the NuBus. And yeah, according to the press I've seen, Apple is leading an effort to support some new, faster, and upward compatible transfer modes on NuBus. This is different that NeXT, which uses NuBus protocols but maintains no compatibility. I haven't seen any technical specs on what Apple is doing with this faster NuBus, but it should be interesting. >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 had previously read that the NeXT bus was 12.5MHz. The main advantage of a 12.5MHz NuBus to a 25MHz 68030/40 computer is that there should be no need to waste time in synchronization delays, since both CPU and bus clock can be based on the same oscillator. Apple may be doing the same thing on their 20MHz IIsi and 20/40MHz IIfx. In any case, you can't run 68030/40 burst cycles on NuBus. NuBus burst cycles are what you call "block transfers". They start on an even multi-word boundary, and require that entire multi-word to be transfereed. So you can burst a quad-word (NuBus word == 68030 longword, of course) in five NuBus cycles, or a 16-word block in 17 NuBus cycles. But the word must be aligned. 68030 bursts are always quad-word transfers, but they start on any word boundary and wrap around to the beginning if necessary. Strangely enough, the Amiga's Zorro III burst mode does support conversion to 68030 or 68040 burst cycles. -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "That's me in the corner, that's me in the spotlight" -R.E.M.
daglem@idt.unit.no (Dag Lem) (05/16/91)
In article <1991May15.125954.1993@NCoast.ORG>, davewt@NCoast.ORG (David Wright) writes: |> Don't you notice how SLOW the nExt updates it's windows and displays |> (not what is happening within them, but move a window around and see how long |> it takes to redraw the display (especially with 5 or 6 windows open)) when |> compared even to an Amiga 500, a 16-bit machine running at 7Mhz. OK, you're right, on the A500 the blitter is a real winner. But what is the screen resolution you usually use on the 500? What's the number of colors? Have you ever seen an A3000 running Workbench in interlaced hires, 16 colors? Give it a try! zzzzzzzzzz..... Personally, I really do like the blitter consept, but the blitter hasn't got enough horsepower! Right now, I'm thinking of making some nifty 3D animations on my 3000. Having worked a *lot* with the blitter on an A500, I realize I can get the drawing done faster with the 68030. My guess (yes, just a guess - enlightenment welcome) is that it's best done by doing the drawing in FAST RAM, copying the image into the bitplanes afterwards (yes, more than one bitplane, stupido :-) Using double buffering, the blitter could perhaps be used to clear the bitplanes in one buffer while the 030 is drawing/copying. Anyway, this can't be the intention of the blitter? To do next to nothing? Wow it's got line drawing, polygon filling etc., but it's not doing its job fast enough! You state that the NeXT is slow on display updating. Just wait till you try the above mentioned Workbench setup. Try moving windows around. Try listing some lengthy directories in a Shell window. Gawd I really wish they'd speed up that Boring old Lazy Incapable Tiny Two cent poor Excuse for a Real graphics coprocessor. I'm truly sorry if I hurt anyones feelings here, this is just how I feel. I love my Amiga, I really do, that's why I'm concerned. And please don't give me that "The 68030+Blitter is still better than just a 68030". Sure, but the blitter isn't doing its intended job fast enough, get it? If you can't even use the blitter to shuffle windows around (ought to be an ideal job for the blitter) because it's too goddamned slow, you use the 68030 instead (CPUBlit). Now how shall we put the blitter to use? Hmmm well maybe we could get it to run our applications instead? :-) I just keep rambling on and on. |> Dave -- __ / |> Shorter of breath / \ __ __ / ___ _ _ |> and one day closer to death. / |/ / / / / /__/ / / / |> -Roger Waters, Time /____/ \_/|/\_/ /____\___/ / \__________ |> (Dark Side of The Moon) ______________/
melling@cs.psu.edu (Michael D Mellinger) (05/16/91)
In article <1991May15.125954.1993@NCoast.ORG> davewt@NCoast.ORG (David Wright) writes:
Can you REALLY be this dumb? The point people have been trying to make
is that if a 68030+blitter is faster than just a 68030, then a 68040+blitter
will be faster than just a 68040. Of course a 68040 will be able to update
screens faster than the blitter in many cases, but in doing so it will be
stealing time that could have been handling OTHER programs, just to update the
display. Gee, this sounds just like the nExt. No wonder you can't understand
it. Where will your argument stand with a 3000 with an 040 in it? You are still
trying to compare a 68030 machine to a 68040 machine, like you were 3 months
ago.
Well, where are the 040 boards for the Amiga? NeXT has shipped at
least 8,000 68040 boards, and there isn't even one 040 board for the
Amiga shipping. -- Just felt like taking a shot.
Yes, an 040 + blitter will be better than just an 040. I was trying
to get the point acrossed that animation is possible on the NeXT, not
as good as the Amiga, but it seems like 20 to 30fps is possible,
unless something else has been overlooked.
Don't you notice how SLOW the nExt updates it's windows and displays
(not what is happening within them, but move a window around and see how long
it takes to redraw the display (especially with 5 or 6 windows open)) when
compared even to an Amiga 500, a 16-bit machine running at 7Mhz.
Are you running an 030 NeXT with 8MB of memory. The problem isn't the
CPU, it the paging to and from disk. We have been through this
before. Thanks for joining us late!
The point is, what if you have SOMETHING ELSE running as WELL AS the
ray tracer. Why should EVERY program, EVERYWHERE have to slow down just to
make the screen update MAYBE 1/10th of a seccond faster?
Dedicated hardware is nice, but it can become a problem if people
write directly to it. Microprocessors are improving at an incredible
rate. NeXT year people aren't going to be asking if they should buy a
486 instead of an Amiga, it's going to be SPEC 30+ Compaq machine. As
I was trying to demonstrate with my 030 + blitter < 040 argument.
There are extra cycles to burn, it doesn't matter if you have to
context switch, you still win.
What is this? The old "oops I'm getting my butt kicked here, lets
quick change the subject to something else" trick? We were talking about
whether a 68030+blitter is faster than just a 68030, and therefore whether a
68040+blitter is faster than just a 68040.
Wrong. Amigoids were screaming that the NeXT is so slow at animation
and thought that NeXT users would be lucky to get 5pfs. Then someone
pointed out that the blitter is only as fast as a 68030. So, I
naturally realized that the 68040 was at least three times faster than
an 030, and then proceeded to point out that there is more horsepower
in the NeXT than the A3000.
You just don't seem to understand that:
[ 1 and 2 deleted]
3) Having two CPUs is ALWAYS faster than just 1, as long as you
pick the jobs that each does correctly
Not necessarily. Can I pick the 1 CPU? I would think that it depends
on how the system is designed. 1 fast CPU can definitely beat 1
dedicated CPU and another general purpose CPU. Not to mention the
fact that half of your hardware is being wasted when you aren't doing
graphics. A ray tracer would definitely win with the 1 fast CPU.
-Mikemelling@cs.psu.edu (Michael D Mellinger) (05/16/91)
In article <1991May15.213917.11992@ugle.unit.no> daglem@idt.unit.no (Dag Lem) writes:
You state that the NeXT is slow on display updating. Just wait till you try
the above mentioned Workbench setup. Try moving windows around. Try listing some
lengthy directories in a Shell window.
Whenever something is slow on the NeXT, like bringing a window to the
foreground, try repeating the action and see if it is still slow.
While your at it listen for the HD to start spinning.
A 100MHz 68050 + page swapping = 0 mips.
How is Commodre going to add VM to the Amiga? Some pages need to be
wired into memory, otherwise your animation is going to have problems.
Gawd I really wish they'd speed up that Boring old Lazy Incapable Tiny Two cent
poor Excuse for a Real graphics coprocessor.
I'm truly sorry if I hurt anyones feelings here, this is just how I feel.
I love my Amiga, I really do, that's why I'm concerned.
And please don't give me that
"The 68030+Blitter is still better than just a 68030".
Sure, but the blitter isn't doing its intended job fast enough, get it?
The blitter is the bottleneck? Maybe I'm not crazy :-). No e-mail
please.
If you can't even use the blitter to shuffle windows around (ought
to be an ideal job for the blitter) because it's too goddamned slow, you use the
68030 instead (CPUBlit). Now how shall we put the blitter to use?
Hmmm well maybe we could get it to run our applications instead? :-)
I just keep rambling on and on.
How about replacing the blitter with one of Motorola's new cheap
68030s(minus MMU) or 020s? It will help reduce Commodore's R&D
budget, which gets chopped on a regular basis anyway.
-Mikesschaem@starnet.uucp (Stephan Schaem) (05/16/91)
Yes. and Wait untill SGI use those R4000 in paralelle like they do know with IP7 using 33mhz R3000 (2/cpu board * 4, or more?). But they still have their graphics processor running in parallel! The word is PARALELLE processing... The 68040 cant access 2 bus at the same time, so you will automaticly loose by only using it. Also Blitter internal calculation are done while accesing the bus, so they are absorbed. And accesing video mem with your main processor is crazy! The solution would be to have not 1 but 2 68040, one use instead of the blitter:-) (would be nive to have a 32bit programble blitter). Also the overhead for the processor to use the blitter is infinity small! You can clear your screen in 2 instruction, will the blitter is clearing the screen you start to 'draw' in the screen by creating a blitter list that is going to be use in paralelle. That will also enable you to do beam syncronization, using the amiga coprocessor. (I dont think you want to do that with your main processor)... ETC... Anyway, whats the use to say all that? Stephan.
davewt@NCoast.ORG (David Wright) (05/16/91)
In article <1991May15.213917.11992@ugle.unit.no> daglem@idt.unit.no (Dag Lem) writes: >OK, you're right, on the A500 the blitter is a real winner. But what is the >screen resolution you usually use on the 500? What's the number of colors? >Have you ever seen an A3000 running Workbench in interlaced hires, >16 colors? Give it a try! zzzzzzzzzz..... Ahhh, so you are comparing a 4-color system (the nExt) to a 16-color system, and are suprised that it takes longer to redraw the 16 color screen. I will pit my 25 Mhz 3000 against a 25 Mhz nExt in a REALISTIC window redrawing contest anyday, using a 4 color display, which just happens to be what I use all the time. Besides, the SIZE of the display has nothing (or at least, SHOULD NOT have anything to do with how long it takes to redraw, when you aren't talking about windows covering the entire display. What I am talking about is things like running a couple of clocks on the display, maybe an "Xeyes" kind of thing, and a few XTerm-type windows. All of these are available on both machines. See which of the two start to slow down more significantly more quickly. >Personally, I really do like the blitter consept, but the blitter hasn't got >enough horsepower! Depends on what you want it to do. A 50 Hp engine might just barely push a Yugo, but wouldn't work for a Motor Coach. But I sure wouldn't mind having a 50hp generator on the motor coach to drive my electric system so the main engine wasn't loaded down or required. >Having worked a *lot* with the blitter on an A500, I realize I can get the >drawing done faster with the 68030. My guess (yes, just a guess - enlightenment So do it. You aren't EVER forced to use the Blitter. You use things like the Blitter and Copper when they are apropriate. You don't make excuses to use them, just because they are there. >Anyway, this can't be the intention of the blitter? To do next to nothing? >Wow it's got line drawing, polygon filling etc., but it's not doing its job >fast enough! Sure it is. Even a stock A500 refreshes it's screen faster than almost ANY other system you can buy, including Sun's, Intel-based Unix boxes, PC-Clones running Windows, and certainly the nExt. >You state that the NeXT is slow on display updating. Just wait till you try >the above mentioned Workbench setup. Try moving windows around. Try listing some >lengthy directories in a Shell window. I have. Try doing it on a nExt and then do the same on the 3000. "Listing things in a shell window" reflects more on the disk drive and CPU than the display. What were you using? An A500 running from floppies and a file lister that reads the whole directory and sorts it before listing? In terms of actually LOADING data from the disk, I still have not yet found any other computer that does it faster. MS-DOS "tricks" you into thinking it is faster, because it keeps all the critical info in one certain spot on the disk, which is basically primitive. The Amiga method is more flexible, but can be slower depending on what you are trying to do. But actually LOADING the data, once you have found it, the Amiga's floppies are still among the best. Ever try using the floppies under Unix on a PC-based machine? Yuch. > >Gawd I really wish they'd speed up that Boring old Lazy Incapable Tiny Two cent >poor Excuse for a Real graphics coprocessor. Yeah, that would be great. They should just go ahead and add that TI 34010, forcing the base price machine up by at least $300, and making every graphic-related piece of software there is cease to function. THAT will sure sell more Amigas. > "The 68030+Blitter is still better than just a 68030". >Sure, but the blitter isn't doing its intended job fast enough, get it? Yes it is. Perhaps you are asking too much of it. >If you can't even use the blitter to shuffle windows around (ought >to be an ideal job for the blitter) because it's too goddamned slow, you use the >68030 instead (CPUBlit). Now how shall we put the blitter to use? Of course you can. If *you* choose to waste your CPU time "shuffling" windows around, instead of running the tasks INSIDE the windows, that's your choice. But one of the BEST things about the Amiga is that it doesn't steal any CPU time from user programs that isn't required. If you really want to gain maybe 1 sec faster redraws (on a screen with maybe 25-30 windows or more, at that) at the cost of basically 25% or more of your CPU power, go right ahead. Just don't stick the rest of us with it. Dave
davewt@NCoast.ORG (David Wright) (05/16/91)
In article <lv2H#zg5@cs.psu.edu> melling@cs.psu.edu (Michael D Mellinger) writes: >Yes, an 040 + blitter will be better than just an 040. I was trying At last......... >to get the point acrossed that animation is possible on the NeXT, not >as good as the Amiga, but it seems like 20 to 30fps is possible, >unless something else has been overlooked. Who ever said it COULDN'T. I sure didn't. You don't have to tell ME that. Say that in a reply to someone who might have claimed otherwise. >Are you running an 030 NeXT with 8MB of memory. The problem isn't the >CPU, it the paging to and from disk. We have been through this >before. Thanks for joining us late! No, this is on a machine which WAS an '030 machine (so I know both the "before" and "after" times), but which was upgraded to the '040, and has 16 meg of RAM. This is NOT due to swapping. The fact is, that like EVERY X-type display, it is just plain SLOWER than a bitmapped display like the Amiga uses (not to argue that a more device independant display doesn't have other benefits, but for any given CPU, a more abstracted display system will ALWAYS run slower than one optimized specifically for certain hardware features etc.). >rate. NeXT year people aren't going to be asking if they should buy a >486 instead of an Amiga, it's going to be SPEC 30+ Compaq machine. As Oh please, what planet do YOU live on. nExt year people will STILL be using DOS, nExt year people will STILL be debating which VGA board to use (or is XGA worth your while? Inside 3 brand-new(TM) reports!). As it is the 2nd largest population of PC clones owned for the home STILL have EGA or less graphics, and '286 machines are still selling well. And you actually believe people will move to an INCOMPATIBLE chip, with ZERO support or software, when the whole Windows/OS-2/PM slop is still being fought? Get real. >I was trying to demonstrate with my 030 + blitter < 040 argument. I would never argue otherwise. What I WOULD argue is that 68030+blitter>68030, and 68040+blitter>68040, which is obvious to anyone with a brain bigger than that of a stegasaurus. >There are extra cycles to burn, it doesn't matter if you have to >context switch, you still win. Really??? Where are you getting these magical "extra cycles"? When I have something to do there are NEVER enough cycles, even if I was using a Cray! Is this like having too much clean air (Heck, there's enough of it, let's just keep using flourocarbons to propell our hairspray). >Not necessarily. Can I pick the 1 CPU? I would think that it depends Sure, but unless you missed the point, whatever you pick I also get, PLUS I get another CPU as well. >on how the system is designed. 1 fast CPU can definitely beat 1 >dedicated CPU and another general purpose CPU. Not to mention the >fact that half of your hardware is being wasted when you aren't doing >graphics. A ray tracer would definitely win with the 1 fast CPU. Hmm.. "half" my hardware, huh? I guess that blitter really does outway the Amiga's superior bus, superior expandability, and larger RAM support. Must just leave enough for the "cool games" to balance it out, right? Dave
melling@cs.psu.edu (Michael D Mellinger) (05/16/91)
In article <1991May16.045252.7706@NCoast.ORG> davewt@NCoast.ORG (David Wright) writes: Who ever said it COULDN'T. I sure didn't. You don't have to tell ME that. Say that in a reply to someone who might have claimed otherwise. Well, NCW was following the converstation a while back. Did he go home for the summer? >rate. NeXT year people aren't going to be asking if they should buy a >486 instead of an Amiga, it's going to be SPEC 30+ Compaq machine. As Oh please, what planet do YOU live on. nExt year people will STILL be using DOS, nExt year people will STILL be debating which VGA board to use (or is XGA worth your while? Inside 3 brand-new(TM) reports!). As it is the 2nd largest population of PC clones owned for the home STILL have EGA or less graphics, and '286 machines are still selling well. And you actually believe people will move to an INCOMPATIBLE chip, with ZERO support or software, when the whole Windows/OS-2/PM slop is still being fought? Get real. A lot depends on when MS gets OS/2 3.0 written. At any rate, an 040 NeXT will emulate a 10MHz 286 in software. Insignia seems to think they can get SoftPC to emulate a 386 VGA PC by the end of the year. The little old NeXT SPECs at 12 or 13(at best). Now if you drop an R4000 in a machine and it SPECs at 36(makes the division easy for you!), what can we conclude? A DOS emulator that Peter da Silva would appreciate? And of course, NeXT should have their SPEC 30+ machine NeXT year too. I imagine most developers will find porting their software to it a breeze. >I was trying to demonstrate with my 030 + blitter < 040 argument. I would never argue otherwise. What I WOULD argue is that 68030+blitter>68030, and 68040+blitter>68040, which is obvious to anyone with a brain bigger than that of a stegasaurus. Right, but adding N to N doubles your performance, while adding N to 3N gives you 33% more power(going from a 25MHz 040 to 33MHz one will do this). Of course, we just can't add the mips, because the blitter is dedicate to graphics. So, which chip do you let do the graphics? The one that does N mips or 3N mips? >There are extra cycles to burn, it doesn't matter if you have to >context switch, you still win. Really??? Where are you getting these magical "extra cycles"? When I have something to do there are NEVER enough cycles, even if I was using a Cray! Is this like having too much clean air (Heck, there's enough of it, let's just keep using flourocarbons to propell our hairspray). You removed part of my posting. I was talking about the extra cycles that an 040 would have over a blitter + 030, which is an extra 030 for context switching. >Not necessarily. Can I pick the 1 CPU? I would think that it depends Sure, but unless you missed the point, whatever you pick I also get, PLUS I get another CPU as well. The value of the blitter diminishes as you add it to a faster CPU. Adding it to HP's 57 mip Snake($12K) isn't going to do shit. Well, to be fair, it will probably get in the way. >on how the system is designed. 1 fast CPU can definitely beat 1 >dedicated CPU and another general purpose CPU. Not to mention the >fact that half of your hardware is being wasted when you aren't doing >graphics. A ray tracer would definitely win with the 1 fast CPU. Hmm.. "half" my hardware, huh? I guess that blitter really does outway the Amiga's superior bus, superior expandability, and larger RAM support. Must just leave enough for the "cool games" to balance it out, right? Let me know how well the 88K or R4000 fits into the current Amiga when it comes time to make a bigger and better Amiga. Or is Commodore going to wait for the 050? -Mike
nwickham@triton.unm.edu (Neal C. Wickham) (05/16/91)
In article <7haHkcs5@cs.psu.edu> melling@cs.psu.edu (Michael D Mellinger) writes: > > >Well, NCW was following the converstation a while back. Did he go >home for the summer? > > >-Mike I didn't say anything about NeXT not being able to do animation. I know very little aboutcomputers and have kept most of my post in the area of psychology and marketing ...'m a civil engineeri majo I did make some comments that animation wa beingwritten abo an advertise a lot in my engineering magazine I think you, when talking about DPS said, t said that the only problem with it was that it wouldn't do animation very NCW w
daveh@cbmvax.commodore.com (Dave Haynie) (05/16/91)
In article <lv2H#zg5@cs.psu.edu> melling@cs.psu.edu (Michael D Mellinger) writes: >Yes, an 040 + blitter will be better than just an 040. I was trying >to get the point acrossed that animation is possible on the NeXT, not >as good as the Amiga, but it seems like 20 to 30fps is possible, >unless something else has been overlooked. Actually, one of the most important things for good looking animation is the capability to synchronize with your display frame. Double or N-Buffering makes this a no-brainer on Amiga, but technically, double buffering isn't a requirement for smooth animation. What is required, however, is a way to insure that the frame being displayed is never changed in the middle of a frame. This is much harder to coordinate if you don't have buffering capability, since it means the CPU must be otherwise kept out of the part of the frame that hasn't been displayed yet. Since the CPU can outrun the display in many systems, something as simple as a vertical retrace interrupt may work, assuming interrupt response latency is short enough. Bottom line, though, is that you need some hardware support for runtime animation, regardless of who's "doing" the animation in a system. And without good hardware support, the animation is going to be ugly (updates crossing the displayed raster are very noticable), less than optimal (fewer FPS than the hardware could support in ugly mode), or both. CPU speed is only a real minor factor in many cases; a C64 can do simple, smooth animation. BTW, I really know nothing about the NeXT display hardware and what's possible with it. Could be they're set up for the possibility of good animation, could be they're not. -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "That's me in the corner, that's me in the spotlight" -R.E.M.
kls30@duts.ccc.amdahl.com (Kent L Shephard) (05/17/91)
In article <lv2H#zg5@cs.psu.edu> melling@cs.psu.edu (Michael D Mellinger) writes: > >In article <1991May15.125954.1993@NCoast.ORG> davewt@NCoast.ORG (David Wright) writes: > > You just don't seem to understand that: > [ 1 and 2 deleted] > 3) Having two CPUs is ALWAYS faster than just 1, as long as you > pick the jobs that each does correctly > >Not necessarily. Can I pick the 1 CPU? I would think that it depends >on how the system is designed. 1 fast CPU can definitely beat 1 >dedicated CPU and another general purpose CPU. Not to mention the >fact that half of your hardware is being wasted when you aren't doing >graphics. A ray tracer would definitely win with the 1 fast CPU. > >-Mike I agree this ios not the case. If I connect 5 i486 or 5 '040 chips together in a system will that be faster than lets say 1 cpu that runs a 100 mips?? The answer to that is: Depends on the system design. You lose processing power when you add cpu's it is not linear. 20 mip cpu + 20 mip cpu + 20 mip cpu + 20 mip cpu + 20 mip cpu != 100 mips. You lose because of scheduling overhead and you must also realize that you have to have an OS that can do effcient scheduling. Are you going to do static or dynamic scheduling? Symetric or asymetric multiprocessing? Is your cache coherency protocol efficient? How good is I/O performance. Is memory dual ported? Who has priority over data in shared memory? I'll take 1 fast cpu ('040) vs a good one and a dedicated specialized cpu ('030 and blitter). You see unless they can access memory at the same time (dual ported) then one will have to wait for the other eventually. Also the '040 does lots of things in 1-3 cycles (remember it is very fast) so how many cycles will the blitter be able to steal? I'd say not many. Or what happens when the blitter is accessing memory during a cycle steal, how long will it hold the shared memory bus, will the '040 have to wait for it to finish. Smooth animation is possible on the NeXT dont be fooled. Screen updates aren't as slow as some would like you to believe. I recently played around on a NeXTstation color for a while (1-2 hours) the performance is not noticably different from my monochrome machine. Animation is smooth and it is >30fps. One thing you all must remember even the animation on an Amiga or any machine for that matter will slow down when you start running a lot of processes. When the A3000 is runnig Unix how is animation on it? Kent -- /* -The opinions expressed are my own, not my employers. */ /* For I can only express my own opinions. */ /* */ /* Kent L. Shephard : email - kls30@DUTS.ccc.amdahl.com */
daglem@idt.unit.no (Dag Lem) (05/17/91)
In article <1991May16.043705.6698@NCoast.ORG>, davewt@NCoast.ORG (David Wright) writes: >OK, you're right, on the A500 the blitter is a real winner. But what is the >screen resolution you usually use on the 500? What's the number of colors? >Have you ever seen an A3000 running Workbench in interlaced hires, >16 colors? Give it a try! zzzzzzzzzz..... Ahhh, so you are comparing a 4-color system (the nExt) to a 16-color system, and are suprised that it takes longer to redraw the 16 color screen. I will pit my 25 Mhz 3000 against a 25 Mhz nExt in a REALISTIC window redrawing contest anyday, using a 4 color display, which just happens to be what I use all the time. Don't get me wrong. I'm not saying the NeXT is a wonderful machine. In fact, I haven't even seen one. I'm saying that the Amiga blitter is not very useful on a big display with colors (and I want to use a big display with colors). |> Besides, the SIZE of the display has nothing (or at least, SHOULD NOT |> have anything to do with how long it takes to redraw, when you aren't talking |> about windows covering the entire display. What I am talking about is things What? The resolution of the display determines the size of my windows. Of course I want to display as much information as possible (e.g. in Shell windows). |> >Personally, I really do like the blitter consept, but the blitter hasn't got |> >enough horsepower! |> Depends on what you want it to do. A 50 Hp engine might just barely |> push a Yugo, but wouldn't work for a Motor Coach. But I sure wouldn't mind |> having a 50hp generator on the motor coach to drive my electric system so |> the main engine wasn't loaded down or required. |> >Having worked a *lot* with the blitter on an A500, I realize I can get the |> >drawing done faster with the 68030. My guess (yes, just a guess - enlightenment |> So do it. You aren't EVER forced to use the Blitter. You use things |> like the Blitter and Copper when they are apropriate. You don't make |> excuses to use them, just because they are there. As far as I can tell, using the blitter on a large colorful display is never appropriate. The blitter WAS very useful in the A500. I quote from the Amiga Hardware Reference Manual: "When copying memeory, it is approximately twice as fast as the 68000, ..." "The blitter is particularly well suited to graphics operations." We don't use a 68000 anymore. We use a 68030. The blitter is still the same, and is doing its specialized tasks less efficiently than the general 68030. |> >Anyway, this can't be the intention of the blitter? To do next to nothing? |> >Wow it's got line drawing, polygon filling etc., but it's not doing its job |> >fast enough! |> Sure it is. Even a stock A500 refreshes it's screen faster than |> almost ANY other system you can buy, including Sun's, Intel-based Unix |> boxes, PC-Clones running Windows, and certainly the nExt. These systems use higher resolution displays. Even an old Sun 3/60 (1152*900, 256 colors) running twm under X is faster on refresh than an A3000 running Workbench in hires-interlace, 16 colors (assuming the 3/60 has enough memory to keep it from swapping). |> >You state that the NeXT is slow on display updating. Just wait till you try |> >the above mentioned Workbench setup. Try moving windows around. Try listing some |> >lengthy directories in a Shell window. |> I have. Try doing it on a nExt and then do the same on the 3000. |> "Listing things in a shell window" reflects more on the disk drive and CPU |> than the display. What were you using? An A500 running from floppies and a |> file lister that reads the whole directory and sorts it before listing? |> In terms of actually LOADING data from the disk, I still have not yet found |> any other computer that does it faster. MS-DOS "tricks" you into thinking it |> is faster, because it keeps all the critical info in one certain spot on |> the disk, which is basically primitive. The Amiga method is more flexible, |> but can be slower depending on what you are trying to do. But actually LOADING |> the data, once you have found it, the Amiga's floppies are still among the |> best. Ever try using the floppies under Unix on a PC-based machine? Yuch. |> > You don't get it! Listing lengthy directories in a shell window initiates scrolling of the text. Who is responsible for the scrolling? I'll give you a hint: It's not the 68030. zzzzzzzzzz.... This has NOTHING to do with floppies, sorting or anything else you mention. I seriously doubt you have ever tried running 16 color hires-interlaced Workbench. By the way, I'm using an A3000/25 too, not "An A500 running from floppies...". |> Dave -- __ / |> Shorter of breath / \ __ __ / ___ _ _ |> and one day closer to death. / |/ / / / / /__/ / / / |> -Roger Waters, Time /____/ \_/|/\_/ /____\___/ / \__________ |> (Dark Side of The Moon) ______________/
MBS110@psuvm.psu.edu (That neat guy, Mark Sachs) (05/17/91)
In article <7haHkcs5@cs.psu.edu>, melling@cs.psu.edu (Michael D Mellinger) says: > >In article <1991May16.045252.7706@NCoast.ORG> davewt@NCoast.ORG (David Wright) >writes: > > >rate. NeXT year people aren't going to be asking if they should buy a > >486 instead of an Amiga, it's going to be SPEC 30+ Compaq machine. As > Oh please, what planet do YOU live on. nExt year people will STILL > be using DOS, nExt year people will STILL be debating which VGA board to > use (or is XGA worth your while? Inside 3 brand-new(TM) reports!). > As it is the 2nd largest population of PC clones owned for the home STILL > have EGA or less graphics, and '286 machines are still selling well. > And you actually believe people will move to an INCOMPATIBLE chip, with > ZERO support or software, when the whole Windows/OS-2/PM slop is still > being fought? Get real. > >[irrelevant handwaving about NeXT's PC emulation and SPECmarks deleted] And you think this is going to change people's minds? The NeXT emulating a PC costs scads more than a PC. Result: Businesses buy PC's rather than move to an expensive, untested, incompatible platform made by a shaky company with no name recognition. (And please, don't start blathering about "it's not untested, etc. etc..." Right or wrong, that's how the suits perceive NeXT. The only way they'll buy NeXT is if it offers some smashingly super new application IBM can't provide. Macintosh does desktop publishing; Amiga does video and multimedia. What does NeXT do? Well, uh...) > >I was trying to demonstrate with my 030 + blitter < 040 argument. > I would never argue otherwise. What I WOULD argue is that > 68030+blitter>68030, and 68040+blitter>68040, which is obvious to anyone > with a brain bigger than that of a stegasaurus. > >Right, but adding N to N doubles your performance, while adding N to >3N gives you 33% more power(going from a 25MHz 040 to 33MHz one will >do this). Of course, we just can't add the mips, because the blitter >is dedicate to graphics. So, which chip do you let do the graphics? >The one that does N mips or 3N mips? That's it; you've out-weirded me. I don't see the point of your first statement at all. Where in the world are you getting N + N in a NeXT? Is there another 68040 hidden in there that Jobs isn't telling us about? Quite simply, the 68040 NeXT has N. The 68040 Amiga has N + 1/3 N. Period. (Actually it's more like N + 1/2 N, but for the sake of argument...) You are desperately trying to make it look like having an extra coprocessor chip to do the graphics is a liability. That is ludicrous. To answer your question: The timewasting graphics tasks are offloaded to the N mips processor (blitter), while the 3N mips processor (68040) gets on with all the difficult CPU-type calculations. Together, the two finish long before the NeXT's lone 68040, which is desperately switching between graphics and calculations and as a result is left in the dust, thanks to the tragic lack of any coprocessor at all. > >Not necessarily. Can I pick the 1 CPU? I would think that it depends > Sure, but unless you missed the point, whatever you pick I also > get, PLUS I get another CPU as well. > >The value of the blitter diminishes as you add it to a faster CPU. >Adding it to HP's 57 mip Snake($12K) isn't going to do shit. Well, to >be fair, it will probably get in the way. Non sequitor. We are NOT adding it to HP's 57 mip Snake. If it ever gets to the point that the Amiga CPU is running at 57 mips, presumably the old blitter will have been ditched long ago in favor of a new, much faster one. What say we resume this discussion in 2005 and see what happened. Today, in 1991, the blitter still adds a lot of speed and functionality to the Amiga, which the NeXT does NOT have. >Let me know how well the 88K or R4000 fits into the current Amiga when >it comes time to make a bigger and better Amiga. Or is Commodore >going to wait for the 050? Let me know how well the 88K or R4000 (I love these magic numbers Mike keeps throwing around) fits into your current NeXT when it comes time to make a bigger and better NeXT. Oh, you can't fit them into your current NeXT, because it's unexpandable. Sorry. (Yes, it's a cheap shot but I think I deserve one after trying to reason with this guy.) /Mark "Remixed for Common Household Appliances" Sachs IS: MBS110@psuvm.psu.edu\ | STEVEVAX Administration HQ, World Domination & Bake Sales Ltd. || //AMIGA|| | DISCLAIMER: It's NOT MY FAULT. Kei and Yuri forced me to say it.||\X/ Power|| \== "I think this calls for some diabolical laughter! RAAH HA HA HA HA HA!" ==/
peter@sugar.hackercorp.com (Peter da Silva) (05/17/91)
In article <?iaHpry4@cs.psu.edu> melling@cs.psu.edu (Michael D Mellinger) writes: > Hmmm. 1+1 != 3. You could have the 68040 do the graphical work then > do the calculations then do the graphical work all in the same time > that it took the blitter to do the the graphical work and the 68030 to > do the calculations. In other words, the 68040 gets more work done in > the same period of time. And then, and then, and then...? Haven't you heard of multitasking? Lightweight processes? Threads? I know you know about them: you have a NeXT. You can have one task doing calculations with the 68040 while another task is waiting on a blit. And both tasks can be part of the same program. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
melling@cs.psu.edu (Michael D Mellinger) (05/17/91)
In article <91136.174737MBS110@psuvm.psu.edu> MBS110@psuvm.psu.edu (That neat guy, Mark Sachs) writes: And you think this is going to change people's minds? The NeXT emulating a PC costs scads more than a PC. Result: Businesses buy PC's rather than move to an expensive, untested, incompatible platform made by a shaky company with no name recognition. (And please, don't start blathering about "it's not untested, etc. etc..." Right or wrong, that's how the suits perceive NeXT. The only way they'll buy NeXT is if it offers some smashingly super new application IBM can't provide. Macintosh does desktop publishing; Amiga does video and multimedia. What does NeXT do? Well, uh...) Like Improv? And you have to pay a lot more money to get an equivalent Macintosh DTP machine. You emulate the PC in software, so you don't have to buy the piece of junk. The native NeXT apps are what you really want the machine for. >Right, but adding N to N doubles your performance, while adding N to >3N gives you 33% more power(going from a 25MHz 040 to 33MHz one will >do this). Of course, we just can't add the mips, because the blitter >is dedicate to graphics. So, which chip do you let do the graphics? >The one that does N mips or 3N mips? That's it; you've out-weirded me. I don't see the point of your first statement at all. Where in the world are you getting N + N in a NeXT? Is there another N + N is in the A3000 at this moment. The blitter(==030) + 030. The NeXT currently has 3N mips. 68040 hidden in there that Jobs isn't telling us about? Quite simply, the 68040 NeXT has N. The 68040 Amiga has N + 1/3 N. Period. (Actually it's more like N + 1/2 N, but for the sake of argument...) No, you were right the first time. An 040 Amiga *will* have 4*N mips, with N of those mips dedicated to graphics. The system seems like it will be a little unbalanced to me. You are desperately trying to make it look like having an extra coprocessor chip to do the graphics is a liability. That is ludicrous. No, you missed where I said was N=68030, and you are assuming the A3000 currently has a 68040 in it. To answer your question: The timewasting graphics tasks are offloaded to the N mips processor (blitter), while the 3N mips processor (68040) gets on with all the difficult CPU-type calculations. Together, the two finish long before the NeXT's lone 68040, which is desperately switching between graphics and calculations and as a result is left in the dust, thanks to the tragic lack of any coprocessor at all. You will have 33% more power than the NeXT. Not exactly an earth shattering amount, but you still won't have memory protection, virtual memory, OS support for 24 bit color, Display Postscript, a 17" 92 dpi monitor or a decent word processor. Need I go on? > >Not necessarily. Can I pick the 1 CPU? I would think that it depends > Sure, but unless you missed the point, whatever you pick I also > get, PLUS I get another CPU as well. > >The value of the blitter diminishes as you add it to a faster CPU. >Adding it to HP's 57 mip Snake($12K) isn't going to do shit. Well, to >be fair, it will probably get in the way. Non sequitor. We are NOT adding it to HP's 57 mip Snake. If it ever gets to the point that the Amiga CPU is running at 57 mips, presumably the old blitter will have been ditched long ago in favor of a new, much faster one. What say we resume this discussion in 2005 and see what happened. That's 57mips for $12K. It's not going to be 2005, it's going to be in two years. Hell, expect at least 30 mips NeXT year from several vendors in < $10K computers. Today, in 1991, the blitter still adds a lot of speed and functionality to the Amiga, which the NeXT does NOT have. Speed for what? Most of the work people do doesn't require dedicate graphics hardware. As for functionality, how about getting some Postscript fonts? Apple and MS Windows have Adobe Type manager and they will have True Type. The NeXT, of course, has 100% Postscript. Let me know how well the 88K or R4000 (I love these magic numbers Mike keeps throwing around) fits into your current NeXT when it comes time to make a bigger and better NeXT. They won't drop right in. That's a point that I've been trying to make. Save your pennies, because you aren't going to be able to take a current generation computer, and easily move it to the NeXT generation. Therefore buy a NeXTstation if you don't need video. The money you save doing that will almost buy a NeXT generation NeXTstation. Oh, you can't fit them into your current NeXT, because it's unexpandable. Sorry. (Yes, it's a cheap shot but I think I deserve one after trying to reason with this guy.) Can I pull out the logic board and drop in another? Isn't everything in the NeXT on one board. What NeXT will do about upgrades is unknown. Is putting in another logic board out of the question? Basically what they did for the 040 upgrades in the Cube. -Mike
mykes@amiga0.SF-Bay.ORG (Mike Schwartz) (05/17/91)
In article <1991May13.004217.23406@techbook.com> waynekn@techbook.com (Wayne Knapp) writes: >swarren@convex.com (Steve Warren) writes: > > >>In the A3000, the 68030 can update display memory faster than the blitter can. >>This does not mean that there is no advantage to using the blitter (and the >>blitter does not loose by *that* much). The fact is, if the blitter is used >>to manage the display and the '030 is able to stay out of display memory, then >>the '030 will be able to "multiprocess" in parallel with the blitter. So if >>you have calculations that need to be performed then, it is advantageous to use >>the blitter to offload graphic manipulations from the CPU. > > >Two three things wrong with this. > > 1) The blitter is seldom used for animation. ANIM players use the CPU, > always. The blitter is often used for brush moving, but not for real > animation. > Brush moving is also animation. > 2) Even the a 68000 can scream past the blitter, depending on the blit. > For simple large blits, the blitter is much faster. For very complex > smaller blits a 68000 routine can be written that is much faster than > the blitter. I done it many times in my code. > True, for example, fast text can be done with 8 byte stores (on byte boundries) while the blitter requires up to 14 word registers for setup. > There is a common trade off that can be made between memory used, nature > of the code and speed of the code. The blitter is very general and do to > that nature can be hard pressed to complete with specail purpose code. > By using all the 68000 registers and extra banks of memory it is possible > to reduce the number of memory accesses required in a very complex blit. > (like, restoring the background from a cookie cut blit) > The 68000 still has to use cycles to fetch its instructions, while the blitter doesn't. A simple rectangle copy as you describe above is still faster with the blitter unless you have real small restorations to do. > Now there are some real constraints, if you are working on something that > requires a LOT of barrel shifting, there is no way a 68000 can keep up > with a blitter. Maybe a 68030, but not a 68000. > Shifting costs 6+2n (word) or 8+2n (long) clocks where n = number of shifts (this is for 68000). This is for register shifts. Memory shifts are even slower. The blitter shifts n bits in 1 clock. > 3) Everyone is always shouting about how the CPU and Blitter can run at the > same time. But in real life, it rarely happens. There are several > reasons for this. > a) The blitter requires CPU to adjust it's registers between bitplanes. > b) Most blits are short in time, too short for the operations system to > allow the CPU much chance to run. > c) It is very hard and complex to pull off. > Now, it can be done, and I'm sure someone has some has. But not as a > general rule, and certainly not something you get for free. > I disagree. The blitter does require the CPU to adjust its registers between bitplanes, but this can be as few as 3 to 6 instructions if it is done right. Also, there is a custom display format which allows "row" blits which requires ONE blit operation to blit to as many planes as you want. The blitter can generate an interrupt when a blit operation is completed, and it is trivial to use these interrupts and it is almost totally free. At the very least, if you aren't using interrupts, you should not wait for the blitter to finish after the last plane (wait before doing the next "first" plane blit), so you can go and do all the calculations you need for setup while the last plane is blitted. And lastly, if you really want smooth animation at high frame rates, the operating system should be disabled because it steals too many cycles. >Now I realize the need to have a blitter in the Amiga, but not for speed in >the higher-end Amigas, but for BACKWARD compatibility. As for speed, es. in >68020+ Amigas I think the blitter is VASTLY overrated. > Ever use blitter nasty? It goes at least 2x faster that way. I know, I've proven it with experimentation. >Anyway that is MHO. Since I make my living from writing real-time graphics/ >animation software, I suppect I used the blitter about 10,000 more than most >people. > Hope this helps you do even better! > Wayne Knapp > Consultanting Assoc. > Hash Enterprises > >-- >waynekn@techbook.COM ...!{tektronix!nosun,uunet}techbook!waynekn >Public Access UNIX at (503) 644-8135 (1200/2400) Voice: +1 503 646-8257 >Public Access User --- Not affiliated with TECHbooks -- **************************************************** * I want games that look like Shadow of the Beast * * but play like Leisure Suit Larry. * ****************************************************
mykes@amiga0.SF-Bay.ORG (Mike Schwartz) (05/17/91)
In article <1991May13.004217.23406@techbook.com> waynekn@techbook.com (Wayne Knapp) writes: >swarren@convex.com (Steve Warren) writes: > > >>In the A3000, the 68030 can update display memory faster than the blitter can. >>This does not mean that there is no advantage to using the blitter (and the >>blitter does not loose by *that* much). The fact is, if the blitter is used >>to manage the display and the '030 is able to stay out of display memory, then >>the '030 will be able to "multiprocess" in parallel with the blitter. So if >>you have calculations that need to be performed then, it is advantageous to use >>the blitter to offload graphic manipulations from the CPU. > > >Two three things wrong with this. > Oops, I forgot to mention something... > 3) Everyone is always shouting about how the CPU and Blitter can run at the > same time. But in real life, it rarely happens. There are several > reasons for this. > a) The blitter requires CPU to adjust it's registers between bitplanes. > b) Most blits are short in time, too short for the operations system to > allow the CPU much chance to run. > c) It is very hard and complex to pull off. > Now, it can be done, and I'm sure someone has some has. But not as a > general rule, and certainly not something you get for free. > The blitter is used for a LOT more than just simple animation on the AMiga. It is used to do quite large operations all the time, especially when dealing with windows and the rest of the interface. The CPU can't do proportional fonts as fast as the blitter, or refresh a window, or do layers, etc. This is the most obvious use of offloading graphics operations from the CPU to the blitter done by the Amiga. > Wayne Knapp > Consultanting Assoc. > Hash Enterprises > >-- >waynekn@techbook.COM ...!{tektronix!nosun,uunet}techbook!waynekn >Public Access UNIX at (503) 644-8135 (1200/2400) Voice: +1 503 646-8257 >Public Access User --- Not affiliated with TECHbooks -- **************************************************** * I want games that look like Shadow of the Beast * * but play like Leisure Suit Larry. * ****************************************************
sschaem@starnet.uucp (Stephan Schaem) (05/18/91)
This is crazy! 'twice faster has a 68000' do people know why? Because CBM took timing from a loop with instruction fect... Again the Blitter is like a 68020, and do its internal calculation WHILE accesing the bus! So you CANT squeze more out of the bus, and if you can go faster with a 680x0 than the blitter the bus usage is the 'same' (With cache on cpu to do logical op on data while accesing the bus). The blitter curent problem in a A3000, its not 32bit etc...
sschaem@starnet.uucp (Stephan Schaem) (05/18/91)
And again! When you have 16 color the machine dont go 2 time slower than with 2 bitplane... You have twice has mutch data to work with AND you bus access during display is reduce to ZERO! 'No wonder its slow'.And doing it with the processor is a major error (In that case). Because You will defenectly NOT init a scroll during any display time. ( because the CPU will be monopolize by bus wait in betwen HBG). So you have to syncronize your 68030 with the BOF, and do the work then. The Blitter will take 'ALL' the cycle available during the display time! AND you can do you calculation with the 68030 whenever!... Scrolling with the main (And only:-) CPU in that case is a MAJOR error. And you only have 64 instruction in your cache (No 68040 in my A3000 yet:-) to fit your blit function. Already now the Blitter is a BIG+ and if it goes 32bit or faster ther NO question to ask about its usage in a multi bus system! Stephan.
sschaem@starnet.uucp (Stephan Schaem) (05/18/91)
I wonder how the Next will compare to SGI computer this year :-) Lets go back to the discution in a few month and see... Stephan.
peter@sugar.hackercorp.com (Peter da Silva) (05/18/91)
In article <7haHkcs5@cs.psu.edu> melling@cs.psu.edu (Michael D Mellinger) writes: > what can we conclude? A DOS emulator that Peter da Silva would > appreciate? Watch it, dude. You're skating on thin ice here. > Of course, we just can't add the mips, because the blitter > is dedicate to graphics. So, which chip do you let do the graphics? > The one that does N mips or 3N mips? Depends on the graphics. No point in using the 68040 to scroll console windows if the blitter is already doing it as fast as you can go. I use the chip that's doing it fast enough. The CHIP bus is already full anyway, remember. Might as well tow it with the pickup as the ferrari. > Let me know how well the 88K or R4000 fits into the current Amiga when > it comes time to make a bigger and better Amiga. Or is Commodore > going to wait for the 050? Probably gonna work on a $1000 030 or 040 machine first. Remember, the Amiga has an entry-level machine as well. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peter@sugar.hackercorp.com (Peter da Silva) (05/18/91)
> No, you were right the first time. An 040 Amiga *will* have 4*N mips, > with N of those mips dedicated to graphics. The system seems like it > will be a little unbalanced to me. I know Steve Jobs said that a computer should use 75% of its CPU for the user interface, but that doesn't mean we all believe that. The Amiga has always provided more CPU for real applications than any machine in its class, simply because it has a blitter. Yes, it's a little unbalanced. Not as badly as the NeXT, but some. > That's 57mips for $12K. It's not going to be 2005, it's going to be > in two years. Hell, expect at least 30 mips NeXT year from several > vendors in < $10K computers. Fine. But what will be available in < $2K computers? -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
mitroo@magnus.acs.ohio-state.edu (Varun Mitroo) (05/18/91)
In article <1991May18.104457.28023@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: > >Depends on the graphics. No point in using the 68040 to scroll console windows >if the blitter is already doing it as fast as you can go. I use the chip that's >doing it fast enough. The CHIP bus is already full anyway, remember. Might as >well tow it with the pickup as the ferrari. > Personally, I would vote for using the '040 (or even the 030). I use an Amiga 3000 daily at work and the graphics feel very slow. All the work we do is in high resolution, interlaced 16 color mode, though. The rest of the comuter is realy fast, but moving winows, drawing lines, an refreshing the display feels very slow - especially when compared to the speed of the display of some other nameless computer... The blitter is great for low res 320x200 screens, but for really high-res displays, the '030 would be much better. Besides, I'm not running a ray tracer in the background all the time - it would be nice to use some of that idle computing power to speed up the display. Varun Mitroo mitroo@magnus.acs.ohio-state.edu -- You are young, they are old Control is all they've got to give Just live how you want to live Tiny things that make you slave Like a chain, an anchor to the bed of the sea
melling@cs.psu.edu (Michael D Mellinger) (05/19/91)
In article <1991May18.104457.28023@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: > what can we conclude? A DOS emulator that Peter da Silva would > appreciate? Watch it, dude. You're skating on thin ice here. I was just refering to your disdain for DOS emulators. You seem to think that they are completely useless. > Of course, we just can't add the mips, because the blitter > is dedicate to graphics. So, which chip do you let do the graphics? > The one that does N mips or 3N mips? Depends on the graphics. No point in using the 68040 to scroll console windows if the blitter is already doing it as fast as you can go. I use the chip that's doing it fast enough. The CHIP bus is already full anyway, remember. Might as well tow it with the pickup as the ferrari. Would a blitter in the NeXT be scrolling as fast as it can? It can only move data 16 bits at a time, correct? > Let me know how well the 88K or R4000 fits into the current Amiga when > it comes time to make a bigger and better Amiga. Or is Commodore > going to wait for the 050? Probably gonna work on a $1000 030 or 040 machine first. Remember, the Amiga has an entry-level machine as well. So, does the NeXT, it just costs $5000. :-) A $999 030(32 bit bus) Amiga with a flicker fixer would be nice, but how long do you think it will be before you see one? Perhaps if Commodore used one of Motos new 030's without an MMU. -Mike
peter@sugar.hackercorp.com (Peter da Silva) (05/19/91)
In article <d-9H6q$7@cs.psu.edu> melling@cs.psu.edu (Michael D Mellinger) writes: > I was just refering to your disdain for DOS emulators. You seem to > think that they are completely useless. No, just vastly overrated. If you're buying a NeXT over an Amiga or Mac because of SoftPC, you should be buying an Amiga or a Mac and a cheap IBM clone as well. It'd be a better use of your resources. I have a PC clone here at home. It runs my BBS (Taronga Park, +1 713 568 0480). Oh, and in reference to Mike Schwartz, the BBS is written in an interpreted language. Under UNIX. I couldn't do that in an emulator, because it has to be up all the time. If you have an occasional need to run a DOS program, that's one thing, but that's not a reason to buy a more expensive machine. I'd say the same thing about AMAXX is if wasn't for the fact that you're buying a cheaper machine to do the job. If the NuTek MacOS clone actually comes out, I might buy AMAXX. The NuTek software sound better designed than what Apple has found themselves with after 7 years of patches to a toaster. > Would a blitter in the NeXT be scrolling as fast as it can? It can > only move data 16 bits at a time, correct? My blitter moves 32 bits at a time. I have a 3000. In reference to the Amiga having an entry-level machine... > So, does the NeXT, it just costs $5000. :-) Smiley indeed. An "entry level" machine refers to one that an average man on the street could afford. Not the privileged elite who can get daddy to plunk down $3000 for a NeXT, or for whom $5000 just means they'll have to take this season's skiing vacation in Vail instead of St. Moritz. If it lists for more than 1-2 grand it's not entry level (unless it's a car, or a house...). > A $999 030(32 bit bus) > Amiga with a flicker fixer would be nice, but how long do you think it > will be before you see one? Perhaps if Commodore used one of Motos > new 030's without an MMU. I've suggested that. An MMU is of marginal value in an Amiga. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
Alex_Topic@resbbs.UUCP (Alex Topic) (05/20/91)
Yeah Hi there I find this question about the Blitter and various CPUs
interesting. Well I only have a A500 and a blitter makes a mega difference
with my machine. But when the Blitter was made with the custom chips. That
was some time ago, about 7 or 8 years ago.
My question is why and the heck didn't CBM make a faster blitter? When
they designed the Super Agnus that all I can see has only afew advantages.
The main being able to access 2megs of chip.
I think the A3000 should of had a faster blitter, perhaps multiple
blitter channels. Now that would help alot in animation. Some people may
think
who and the heck cares about the blitter. Well I do! Think about it has alot
of important uses. Such as in a GUI enviroment! Let the blitter do all the
window updateing thus leaveing the CPU to work on more important things at
the moment.
Personally I love the way the Amigas custom chips are arranged. I
just wish CBM would continue to update them and get them out fast enough. If
they ever do they should make sure they are backward compatible as well. Of
course with a new blitter it would be really great for Simulation software.
I agree that a blitter takes a load of work off the CPU and is useful
if even slower than the CPU. But thats if you are in a multitasking
environment though and the CPU speed would changed alot all the time thus
being different. But if you made software that takes over the machine and
you wanted the fastes animation possible go with the CPU.. or combine the two
if possible.
Oh well Cya all later!
A.t.chucks@pnet51.orb.mn.org (Erik Funkenbusch) (05/20/91)
sschaem@starnet.uucp (Stephan Schaem) writes: > > > This is crazy! 'twice faster has a 68000' do people know why? > Because CBM took timing from a loop with instruction fect... > Again the Blitter is like a 68020, and do its internal calculation > WHILE accesing the bus! > So you CANT squeze more out of the bus, and if you can go faster with a > 680x0 than the blitter the bus usage is the 'same' (With cache on cpu > to do logical op on data while accesing the bus). > The blitter curent problem in a A3000, its not 32bit etc... let me say this loudly! THERE IS LITTLE REASON FOR THE CPU TO ACCESS THE SAME BUS AS THE BLITTER! there, most everything the cpu does (executing programs) is done in fast memory. fast memory is on a seperate bus than chip memory. therefore having 2 busses with 2 seperate processors on them means there should be little bus contention. the only time the cpu NEEDS to access chip memory is to program the blitter, and that's only for a few cycles. .--------------------------------------------------------------------------. | UUCP: {amdahl!tcnet, crash}!orbit!pnet51!chucks | "I know he's come back | | ARPA: crash!orbit!pnet51!chucks@nosc.mil | from the dead, but do | | INET: chucks@pnet51.orb.mn.org | you really think he's | |-------------------------------------------------| moved back in?" | | Amiga programmer at large, employment options | Lou Diamond Philips in | | welcome, inquire within. | "The First Power". | `--------------------------------------------------------------------------'
swarren@convex.com (Steve Warren) (05/20/91)
In article <1991May19.124802.19879@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <d-9H6q$7@cs.psu.edu> melling@cs.psu.edu (Michael D Mellinger) writes: >> Would a blitter in the NeXT be scrolling as fast as it can? It can >> only move data 16 bits at a time, correct? > >My blitter moves 32 bits at a time. I have a 3000. > Hey, Peter, the blitter still moves 16 bits at a time; it just has a 32-bit port for the '030. But to answer Mike's question, unless he can show otherwise I have to assume that a blitter would scroll faster than a 68040 could do it in the NeXT. Mike, you still have failed to recognize this simple fact which everyone has been trying to get through to you: that 68040 is not an advantage for graphic manipulation, because the limiting factor is the interface into the screen buffer. It doen't matter that your fire-hydrant can pump out a million gallons per minute, if it has to fill up your swimming pool through a garden hose. In that case you are just as well off to use the faucet in your back yard, since it can put just as much water through a garden hose as a fire hydrant can. The biggest advantage of a blitter is that the blitter is able to put all of the available bandwidth in your display to productive use, because it's design was tuned to access this bus the most efficiently. It has no other tasks to perform, so it is always available to do graphics manipulations. The blitter is able to weave in and out of other accesses in order to get its job done. This allows maximum utilization of available bandwidth. A general- purpose processor is not good at this. By the time you could get the attention of the 68040 (via an interrupt) the available access would have gone past, because screen updates cannot wait. The other alternative is to just force the 68040 to sit on the display bus and wait-state it until an available cycle comes open. In that case your 5-30 mips (whatever) 68040 is dropped down to the level of a .1-.5 mips blitter. It's capacity is totally limited by the capacity of the interface into the buffer. If it is wait-stating on the bus, then it is not doing anything at all *except* waiting. *And*it*will*do*a*lot*of*waiting*. No matter how fast your processor is, dedicated smart I/O devices with DMA are always more efficient. Your processor has to down-shift into granny-gear while it is doing I/O jobs that dedicated devices could do better. While in this mode, its performance is significantly lower than its "on-paper" capacity. The percentage of time that your processor spends doing tasks like this can be directly subtracted from the total performance capacity of the procesor. That is, a 20 mips processor that spends half its time doing I/O is really a 10 mips processor, as far as the user is concerned. The irony is that the I/O being done for 50% of its time is not really 10 mips worth of I/O; it is probably less than 1 mip worth of I/O. But because the processor can go no faster than the I/O it is talking to, it loses 50% of its wall-clock time while only doing a small part of its total work load. That is why this approach is so inefficient, and that is why a 68040 Amiga is going to significantly outperform the NeXT. The Amiga lets the main processor do what it does best, and off-loads the inefficient I/O jobs to simple dedicated processors. So with the Amiga all of your processor performance is available for the real work. -- _. --Steve ._||__ Warren v\ *| V
judge@alchemy.tcnet.ithaca.ny.us (rory toma) (05/21/91)
mitroo@magnus.acs.ohio-state.edu (Varun Mitroo) writes: > In article <1991May18.104457.28023@sugar.hackercorp.com> peter@sugar.hackerco > > > >Depends on the graphics. No point in using the 68040 to scroll console windo > >if the blitter is already doing it as fast as you can go. I use the chip tha > >doing it fast enough. The CHIP bus is already full anyway, remember. Might a > >well tow it with the pickup as the ferrari. > > > > Personally, I would vote for using the '040 (or even the 030). I use an > Amiga 3000 daily at work and the graphics feel very slow. All the work we do > is in high resolution, interlaced 16 color mode, though. The rest of the > comuter is realy fast, but moving winows, drawing lines, an refreshing the > display feels very slow - especially when compared to the speed of the displa > of some other nameless computer... > > The blitter is great for low res 320x200 screens, but for really high-res > displays, the '030 would be much better. Besides, I'm not running a ray > tracer in the background all the time - it would be nice to use some of that > idle computing power to speed up the display. > > Varun Mitroo > mitroo@magnus.acs.ohio-state.edu > -- > You are young, they are old Control is all they've got to give > Just live how you want to live Tiny things that make you slave > Like a chain, an anchor to the bed of the sea Then use the '030! There are a few PD programs out there that allow you to do just that. rory
sbeagle@kennels.actrix.gen.nz (Sleeping Beagle) (05/23/91)
judge@alchemy.tcnet.ithaca.ny.us (rory toma) writes: > mitroo@magnus.acs.ohio-state.edu (Varun Mitroo) writes: > > > In article <1991May18.104457.28023@sugar.hackercorp.com> peter@sugar.hacker > > > > > >Depends on the graphics. No point in using the 68040 to scroll console win > > >if the blitter is already doing it as fast as you can go. I use the chip t > > >doing it fast enough. The CHIP bus is already full anyway, remember. Might > > >well tow it with the pickup as the ferrari. > > > > > > > Personally, I would vote for using the '040 (or even the 030). I use an > > Amiga 3000 daily at work and the graphics feel very slow. All the work we > > is in high resolution, interlaced 16 color mode, though. The rest of the > > comuter is realy fast, but moving winows, drawing lines, an refreshing the > > display feels very slow - especially when compared to the speed of the disp > > of some other nameless computer... > > Then use the '030! There are a few PD programs out there that allow you > to do just that. You're right, I just installed a program called CPUBlit and it speeds up text scrolling in things like CLI windows by at least a factor of two. Yay! Sleeping Beagle (aka Thomas Farmer) sbeagle@kennels.actrix.gen.nz Ph. +64-4-796306 (voice) "You ain't nothin' but a Hound Dog." With this much posting, I must be a Post, Post Modern Man.
dvljrt@cs.umu.se (Joakim Rosqvist) (05/23/91)
> >let me say this loudly! > >THERE IS LITTLE REASON FOR THE CPU TO ACCESS THE SAME BUS AS THE BLITTER! > >there, most everything the cpu does (executing programs) is done in fast >memory. fast memory is on a seperate bus than chip memory. therefore having 2 >busses with 2 seperate processors on them means there should be little bus >contention. the only time the cpu NEEDS to access chip memory is to program >the blitter, and that's only for a few cycles. > It doesn't need to access chip ram even then. The blitter-control registers are in the $dff area, not in chip ram. /$DR.HEX$ -------------------------------------------- Email to: dvljrt@cs.umu.se 2 Windows on the screen? Oh no, not me. I just Logout & Go.
<LEEK@QUCDN.QueensU.CA> (05/23/91)
In article <1991May23.075950.4177@cs.umu.se>, dvljrt@cs.umu.se (Joakim Rosqvist) says: >>busses with 2 seperate processors on them means there should be little bus >>contention. the only time the cpu NEEDS to access chip memory is to program >>the blitter, and that's only for a few cycles. >> Unless you have a > 68000 processor, execbase (and exec ??) still have to sits down there in chip as are the interrupt/exception vectors among other stuff. I think you can move the vectors elsewhere with the 030 or above. (Not sure about the 020) Hopefully that is a small percentage of use. >It doesn't need to access chip ram even then. The blitter-control registers >are in the $dff area, not in chip ram. > >/DR. Hex >-------------------------------------------- >Email to: dvljrt@cs.umu.se >2 Windows on the screen? Oh no, not me. I just Logout & Go.
chucks@pnet51.orb.mn.org (Erik Funkenbusch) (05/24/91)
dvljrt@cs.umu.se (Joakim Rosqvist) writes: >> >>let me say this loudly! >> >>THERE IS LITTLE REASON FOR THE CPU TO ACCESS THE SAME BUS AS THE BLITTER! >> >>there, most everything the cpu does (executing programs) is done in fast >>memory. fast memory is on a seperate bus than chip memory. therefore having 2 >>busses with 2 seperate processors on them means there should be little bus >>contention. the only time the cpu NEEDS to access chip memory is to program >>the blitter, and that's only for a few cycles. >> > >It doesn't need to access chip ram even then. The blitter-control registers >are in the $dff area, not in chip ram. yes it is, the $dff area is in "psuedo" fast ram area, this area is on the chip bus. > > > >/$DR.HEX$ > >-------------------------------------------- >Email to: dvljrt@cs.umu.se >2 Windows on the screen? Oh no, not me. I just Logout & Go. .--------------------------------------------------------------------------. | UUCP: {amdahl!tcnet, crash}!orbit!pnet51!chucks | "I know he's come back | | ARPA: crash!orbit!pnet51!chucks@nosc.mil | from the dead, but do | | INET: chucks@pnet51.orb.mn.org | you really think he's | |-------------------------------------------------| moved back in?" | | Amiga programmer at large, employment options | Lou Diamond Philips in | | welcome, inquire within. | "The First Power". | `--------------------------------------------------------------------------'
swarren@convex.com (Steve Warren) (05/25/91)
In article <4987@orbit.cts.com> chucks@pnet51.orb.mn.org (Erik Funkenbusch) writes: >dvljrt@cs.umu.se (Joakim Rosqvist) writes: [...] >>It doesn't need to access chip ram even then. The blitter-control registers >>are in the $dff area, not in chip ram. >yes it is, the $dff area is in "psuedo" fast ram area, this area is on the >chip bus. [...] Then this would be a good candidate for improvements in a redesigned chip set, yes? If all coprocessor control registers were implemented in zero-wait-state static rams with non-blocking dual ports, that would allow a fast procesor to program all the co-processors on the chip bus at full speed without even slowing down. The only thing the processor would have to slow down for would be when it was copying blocks of data from fast ram into chip ram. If a new chip set were implemented in a more modern process technology then these static rams and all the dual-port circuitry could be rolled into the ASICs. -- _. --Steve ._||__ Warren v\ *| V
peterk@cbmger.UUCP (Peter Kittel GERMANY) (05/27/91)
In article <1991May24.174930.20090@convex.com> swarren@convex.com (Steve Warren) writes: > >>yes it is, the $dff area is in "psuedo" fast ram area, this area is on the >>chip bus. > [...] > >Then this would be a good candidate for improvements in a redesigned chip set, >yes? If all coprocessor control registers were implemented in zero-wait-state >static rams with non-blocking dual ports, that would allow a fast procesor to >program all the co-processors on the chip bus at full speed without even >slowing down. But you forget one *very important* Amiga feature: the Copper. This chip only can do its work on the chip bus, and it was created to change those registers on well defined moments via the chip bus. And it does a tremendous job. Unlike the blitter, no-one until now said that it would even be possible to emulate the copper through the CPU. So there's no way, the registers have to remain on the chip bus. -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
swarren@convex.com (Steve Warren) (05/28/91)
In article <1248@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: >In article <1991May24.174930.20090@convex.com> swarren@convex.com (Steve Warren) writes: [...] >>yes? If all coprocessor control registers were implemented in zero-wait-state >>static rams with non-blocking dual ports, that would allow a fast procesor to >>program all the co-processors on the chip bus at full speed without even >>slowing down. >But you forget one *very important* Amiga feature: the Copper. This chip >only can do its work on the chip bus, and it was created to change those >registers on well defined moments via the chip bus. And it does a >tremendous job. Unlike the blitter, no-one until now said that it would >even be possible to emulate the copper through the CPU. So there's no >way, the registers have to remain on the chip bus. Hello, Peter. Notice that I did not say to take all the registers off of the chip bus. I just said to implement them with a non-blocking dual port. The port that is not connected to the main processor of course must remain on the chip bus; that is the whole reason why you need two ports. There are ways to deal with issues like timing without forcing the main processor to synchronize with the chip bus. Shadow ram could be employed. The transfer from the shadow to the real registers would be controlled by an arbitrator that knows the timing rules for when the registers can change. This can be made transparent to the main processor. A non-blocking multi-port memory design can often present issues like this that would need to be resolved. So never say, "there's no way," because it is just a matter of expense versus payoff. Sometimes the way to do it proves too expensive when compared to the payoff. In this example the assumption is that the main processor looses a lot of time synchronizing with the chip bus and waiting for cycles, strictly for the purpose of updating control registers. If that is not true then there would not be much point in a scheme that only speeds up accesses to the registers (and not to chip memory proper). Regards, -- _. --Steve ._||__ Warren v\ *| V
daveh@cbmvax.commodore.com (Dave Haynie) (05/30/91)
In article <1991May24.174930.20090@convex.com> swarren@convex.com (Steve Warren) writes: >In article <4987@orbit.cts.com> chucks@pnet51.orb.mn.org (Erik Funkenbusch) writes: >>dvljrt@cs.umu.se (Joakim Rosqvist) writes: >>yes it is, the $dff area is in "psuedo" fast ram area, this area is on the >>chip bus. >Then this would be a good candidate for improvements in a redesigned chip set, >yes? If all coprocessor control registers were implemented in zero-wait-state >static rams with non-blocking dual ports, that would allow a fast procesor to >program all the co-processors on the chip bus at full speed without even >slowing down. The only thing the processor would have to slow down for would >be when it was copying blocks of data from fast ram into chip ram. Not quite. Registers aren't the same thing as static RAM at all, though they may look that way to the programmer. In most cases, Amiga chip registers are multiported. One of these ports is always on the RGA bus. The reason you get register slowdown during heavy bus activity is that, to access any Amiga chip register, you need to send out it's corresponding RGA code. Video fetches and blitter activity also have corresponding RGA codes, and there's only one RGA bus in the system. While its theoretically possible to have separate RGA buses for CPU and Chip operations far as I can tell, it's not a real big win. You would do just as well to keep the same single RGA bus architecture and find a way to keep down the number of video fetches happening at any given time. Of course, if I come up with a way to cut the video fetches in half, some joker will come along and find some neat new things we could do with full bus saturation now going twice as fast. >If a new chip set were implemented in a more modern process technology then >these static rams and all the dual-port circuitry could be rolled into the >ASICs. The Amiga chip registers are, in fact, all in the full custom chips. In fact, it's common to have one register show up in more than one chip, especially for write registers. Each chip may have several internal machines that need various settings from any one of the several hundered Amiga chip registers. -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "That's me in the corner, that's me in the spotlight" -R.E.M.