dillon@CORY.BERKELEY.EDU (Matt Dillon) (09/22/86)
>I just sat down last night and wrote a 68000 assembly language Life >routine which does 494,000 generations per second in the data-independent >mode, and averages about 600,000 generations per second in the >data-dependent mode. This is on the Amiga's 7.2 MHz processor. >Maybe I should post it so someone can move it to the Mac? I think you meant to say cells/sec. >I'm thinking of writing a general-purpose life program, complete >with cut-and-paste and library cells (like glider guns and various >flotillas), forward and back panning, true infinite plane (until >memory runs out; on a 2.5Meg Amiga, that shouldn't happen too soon.) Yah! Go for it (but it would be nice if it worked on a 512K amiga) If you want to really make it cool, how'bout using sparse matrices and implementing infinite space... and be able to zoom in or zoom out (allow zoomout to go beyond 1cell/pixel .. 16cells/pixel, etc...) on any particular section. >Oh, by the way. I suspect that my 68000 life program will actually >run faster than the blitter when run on a 68020 Amiga; anyone have >one out there? > With its cache, a 68020 doing simple blits would use most of bandwidth (100% for simple copies). Since a 68020 usually has a faster clock than a 68000, it would easily beat out the Amiga's blitter. Additionaly, you wouldn't need multiple blitter passes. Of course, the disadvantage is that it uses the processor... the system would basically stop while you're doing the blit. But hell, you only live once. -Matt
gnu@hoptoad.uucp (John Gilmore) (09/26/86)
In article <8609221813.AA04648@cory.Berkeley.EDU>, dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > With its cache, a 68020 doing simple blits would use most of bandwidth > (100% for simple copies). Since a 68020 usually has a faster clock than a > 68000, it would easily beat out the Amiga's blitter. Additionaly, you > wouldn't need multiple blitter passes. > Of course, the disadvantage is that it uses the processor... the system > would basically stop while you're doing the blit. But hell, you only live > once. It doesn't really matter whether the CPU is doing it or the blitter is doing it -- if ANYBODY is burning up 100% of the memory bandwidth, the system will "basically stop" -- or stop doing anything but the blit. I think the Amiga blitter can be configured to steal basically all the memory cycles (preempt the processor). The CPU could also do a "wait" instruction to pause until the next interrupt, test if the blitter is done, and jump back to the wait if not. While in a WAIT, the CPU does not use any bus bandwidth. I don't know if the memory arbitration on the Amiga is smart enough to notice, though. -- John Gilmore {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu jgilmore@lll-crg.arpa May the Source be with you!
dale@amiga.UUCP (Dale Luck) (09/28/86)
In article <1137@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: >In article <8609221813.AA04648@cory.Berkeley.EDU>, dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >> With its cache, a 68020 doing simple blits would use most of bandwidth >> (100% for simple copies). Since a 68020 usually has a faster clock than a >> 68000, it would easily beat out the Amiga's blitter. Additionaly, you >> wouldn't need multiple blitter passes. >> Of course, the disadvantage is that it uses the processor... the system >> would basically stop while you're doing the blit. But hell, you only live >> once. > >It doesn't really matter whether the CPU is doing it or the blitter is >doing it -- if ANYBODY is burning up 100% of the memory bandwidth, the >system will "basically stop" -- or stop doing anything but the blit. > >I think the Amiga blitter can be configured to steal basically all the >memory cycles (preempt the processor). The CPU could also do a "wait" >instruction to pause until the next interrupt, test if the blitter >is done, and jump back to the wait if not. While in a WAIT, the CPU >does not use any bus bandwidth. I don't know if the memory arbitration >on the Amiga is smart enough to notice, though. >-- Remember you guys and gals that the amiga has two seperate buses, the blitter/chip bus and the 68k bus. While the blitter is running the 68k is free to use all the bandwidth of the expansion bus/roms and the kickstart memory. The blitter does not slow anybody down. You can be getting ready for the next blit while the blitter is busy churning up the bits from the previous blit. This fact is used extensively in the graphics library. The access time of non-agnus dma devices (like the 68k) is 4 clock ticks, like the 68000. The blitter can get at the memory at twice that speed. Hope this clears it up, or maybe makes the discusion even more complex. Dale Luck Commodore-Amiga, Inc.
stever@videovax.UUCP (Steven E. Rice, P.E.) (10/01/86)
In article <1137@hoptoad.uucp>, John Gilmore (gnu@hoptoad.uucp) writes: > In article <8609221813.AA04648@cory.Berkeley.EDU>, dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >> With its cache, a 68020 doing simple blits would use most of bandwidth >> (100% for simple copies). Since a 68020 usually has a faster clock than a >> 68000, it would easily beat out the Amiga's blitter. Additionaly, you >> wouldn't need multiple blitter passes. >> Of course, the disadvantage is that it uses the processor... the system >> would basically stop while you're doing the blit. But hell, you only live >> once. > > It doesn't really matter whether the CPU is doing it or the blitter is > doing it -- if ANYBODY is burning up 100% of the memory bandwidth, the > system will "basically stop" -- or stop doing anything but the blit. The advantage of having the 68020 perform the data movement is that it can process the data as it streams through. Thus, if data is to be processed for display in a system with a blitter, the processor picks it up, massages it, and puts it into memory, from whence the blitter picks it up and moves it to its destination. Using the processor to process and blit, the data needs to be picked up and put down only once. Of course, the ideal system would have dual- (multi- ?) ported memory with a 68020 for processing and a 68020 for display control (drool, drool, drool. . .). Steve Rice ---------------------------------------------------------------------------- {decvax | hplabs | ihnp4 | uw-beaver}!tektronix!videovax!stever