nick@hp-sdd.UUCP (Nick Flor) (02/24/86)
Computerland sponsored an Amigafest in San Diego February 21-22. Among the products shown were: * GenLock and Frame Grabber * CSA 68020 board * TecMar hard disks * EA games, Aegis application programs. Briefly -- The GenLock was very interesting. The background color (normally blue) was replaced by the David Letterman show. (Real Cute). Then they ran the bouncing ball on top of Dave and other demos. This is a must get product. The Frame grabber had really fuzzy pictures. I didn't notice any significant speed up (they were running the bouncing ball demo) while using the '020 board. The salesman says -- "Watch. I'll enable the cache. See (he enables the cache) the speed increase??". no. Didn't talk to the TecMar people. Of course all the games looked good. Nick ---------- "Nothing here has changed Just the Beat" -Costello
kim@mips.UUCP (Kim DeVaughn) (03/02/86)
[ ... ] >I didn't notice any significant speed up (they were running the bouncing ball >demo) while using the '020 board. The salesman says -- "Watch. I'll enable >the cache. See (he enables the cache) the speed increase??". no. Nick - Do you know if the 020 board had the on-board 256K of 32-bit memory or not? Also, I assume this was the 7+ MHz board, and not the 14+ MHz board CSA is supposed to R&D'ing ... is that correct? /kim -- UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!kim DDD: 408-720-1700 USPS: MIPS Computer Systems Inc, 930 Arques Av, Sunnyvale, CA 94086
eric@chronon.UUCP (Eric Black) (03/03/86)
>[ ... ] > >>I didn't notice any significant speed up (they were running the bouncing ball >>demo) while using the '020 board. The salesman says -- "Watch. I'll enable >>the cache. See (he enables the cache) the speed increase??". no. > >Nick - > >Do you know if the 020 board had the on-board 256K of 32-bit memory or not? >Also, I assume this was the 7+ MHz board, and not the 14+ MHz board CSA is >supposed to R&D'ing ... is that correct? > >/kim > That's not the point! As has been thoroughly described on the net, in BYTE magazine, and numerous other places, the bouncing ball demo is done by LOOKUP TABLE ANIMATION, i.e. the ball is made to appear to rotate by manipulating the color lookup tables. The ball moves by using the hardware scrolling capabilities of the Amiga graphics (independent bitplane pointers). The demo consists of the 68000 loading things up, waiting for a while, changing some pointers and registers, waiting a while, changing some pointers and registers, waiting a while, ... I guess the 68020 could wait faster. With the fast cache, even yet still more fasterer! :^) -- Eric Black "Garbage In, Gospel Out" UUCP: {sun,pyramid,hplabs,amdcad}!chronon!eric VOICE: (415) 941-0403 US SNAIL: Chronon Computer Corp. 2570 El Camino Real W. Suite 206 Mountain View, CA 94040
dale@amiga.UUCP (Dale Luck) (03/04/86)
In article <367@mips.UUCP> kim@mips.UUCP (Kim DeVaughn) writes: >>I didn't notice any significant speed up (they were running the bouncing ball >>demo) while using the '020 board. The salesman says -- "Watch. I'll enable >>the cache. See (he enables the cache) the speed increase??". no. >Nick - > >Do you know if the 020 board had the on-board 256K of 32-bit memory or not? >Also, I assume this was the 7+ MHz board, and not the 14+ MHz board CSA is >supposed to R&D'ing ... is that correct? >/kim :) kim and Nick, the bouncing ball demo would have sped up if the demo were cpu bound. Speeding up the cpu will not make a demo that already runs at frame rate any faster. The demo sync's istelf to the vertical retrace of the beam after changing the position of the ball spinning it to the next orientation. It spends up to 75% of it's time twiddling it's thumbs waiting to begin again. With the 68020 it was spending maybe 85% of its time now twiddling it's thumbs. Did you compare the speed of other demos to an unmodified amiga? like the lines demo? Dale Luck Amiga. he he :-)
nick@hp-sdd.UUCP (Nick Flor) (03/05/86)
> :) kim and Nick, the bouncing ball demo would have sped up if the > demo were cpu bound. Speeding up the cpu will not make a demo > that already runs at frame rate any faster. The demo sync's > istelf to the vertical retrace of the beam after changing the > position of the ball spinning it to the next orientation. It > spends up to 75% of it's time twiddling it's thumbs waiting > to begin again. With the 68020 it was spending maybe 85% of Gee, you should have told me that sooner. The salesman was really excited that the CSA board was "speeding up" the bouncing ball demo. > its time now twiddling it's thumbs. Did you compare the > speed of other demos to an unmodified amiga? like the lines > demo? > > Dale Luck > Amiga. > he he :-) No, when I was there the salesman was just showing the bouncing ball demo. Also, the blitter hardware draws the lines, not the 68000 ergo, there shouldn't be a significant speed increase. (Go to the head of the class Nicko for stating the obvious) So, what's the use of that board in the first place. Nick ---------- "Back off man. I'm a scientist." --Bill Murray "When they pull the shutters down and throw up in the dark they find that all the dogs outside bite much worse than they bark" --Elvis Costello Standard Disclaimer: These onions are obviously my own as HP is not in the vegetable business.
dale@amiga.UUCP (03/09/86)
In article <128@hp-sdd.UUCP> nick@hp-sdd.UUCP (Nick Flor) writes: >Gee, you should have told me that sooner. The salesman was really >excited that the CSA board was "speeding up" the bouncing ball >demo. Amiga engineering does not claim any responsibility for uninformed salesmen for anybodies machine. I do not want to state the obvious comparisons engineers make between themselves and salesmen. I hope it was just an uninformed but enthusiastic amigafile. >Also, the blitter hardware draws the lines, not the 68000 >ergo, there shouldn't be a significant speed increase. >(Go to the head of the class Nicko for stating the obvious) > >So, what's the use of that board in the first place. > The blitter does not magically realize that an application wants a line drawn. It needs a little coaxing. The graphics takes about 200usec setting everything up. Because we actually run the blitter async to the graphics routines we achieve some parrallism and can approach 4000-5000 vectors per second as long as the vectors are less the 200 pixel vectors. Greater than that and limiting factor is the blitter. Well when you have 68020 running at 14mhz this 68k overhead reduces to about (guessing here)100usec's and for vectors in the 100-200 pixel range we see an improvement in speed that is a function of the length of the vector. 100 pixel vectors may be almost twice as fast. For vectors <100 pixels the time is again dominated by overhead and setting up the blitter. But this time the overhead is halved and the result should be a near doubling in speed. The above discussion is true for all graphics operations. The throughput of the graphics is determined not by the blitter alone but also by the efficiency and speed of the code that drives the blitter and the program itself. Dale Luck Amiga