avery@puff.WISC.EDU (Aaron Avery) (03/17/87)
I have written a 68000 assembly language program that performs a certain
mathematical algorithm. I realized that there are certain portions of this
algorithm which the blitter can accomplish far more efficiently than the
68000 can. I'd like to modify my program to make use of the blitter, but
so far, I haven't had much luck getting it to do anything. Has anyone out
there used the blitter directly (using its registers)? Should I disable
interrupts, or will it even make a difference? Could someone please tell
me which direction (left, right) the blitter shifts bits? (I'll eventually
find out by trial and error, but it doesn't hurt to know beforehand)
If anyone can tell me if there are certain ways to make the blitter function
faster (performing the same operation), please let me know. I haven't even
been able to disable interrupts from assembly, either using the DISABLE
macro or otherwise. I think this may be my problem using the blitter, as
I think the copper uses it during the vertical retrace. Thanks.
Aaron Avery ({caip, allegra, seismo, harvard, ihnp4}!uwvax!puff!avery)
(avery@puff.wisc.edu)ali@rocky.STANFORD.EDU (Ali Ozer) (03/17/87)
[] Using the blitter directly (from C or assembly) is certainly possible. You should take a look at "blit.c" that appeared with Tom Rokicki's life source code in Fish disk 31. The code is nice and short, and shows you how to load the blitter registers and then start it up. Of course, you fist have to Own the blitter, and, before doing any subsequent blitter operations, you have to wait for the previous blitter operation to conclude... I don't remember the exact function names to do this stuff; take a look at the code. Also, there is a certain order in which you load the registers; loading one of the registers starts the blitter, so that one should be done last. And finally, I don't think you need to turn of interrupts or anything --- Just make sure the blitter is yours before you load the registers. Of course, I've heard people complain that the code in "blit.c" works only for Tom and no one else... BTW, Tom has a brand new version of Life --- No, it doesn't go any faster but it does let you specify, through a most cryptic programming language, the initial startup picture... He should post it SOON (hint hint, Tom). Ali Ozer, ali@rocky.stanford.edu
rokicki@rocky.STANFORD.EDU (Tomas Rokicki) (03/18/87)
In article <193@rocky.STANFORD.EDU>, ali@rocky.STANFORD.EDU (Ali Ozer) writes: > Using the blitter directly (from C or assembly) is certainly possible. > You should take a look at "blit.c" that appeared with Tom Rokicki's > life source code in Fish disk 31. The code is nice and short, and shows you > how to load the blitter registers and then start it up. Of course, you > fist have to Own the blitter, and, before doing any subsequent blitter > operations, you have to wait for the previous blitter operation to > conclude... I don't remember the exact function names to do this > stuff; take a look at the code. Also, there is a certain order in which > you load the registers; loading one of the registers starts the > blitter, so that one should be done last. And finally, I don't think > you need to turn of interrupts or anything --- Just make sure the > blitter is yours before you load the registers. Actually, the code in blit.c works for the application I needed it for, but is not as general as it claims to be. It is most certainly a starting place, though. Under 1.1, be careful, since WaitBlit() has a bug in it where it could return too early . . . 1.2 has this fixed. Using the blitter isn't that hard . . . maybe I'll update blit.c and post the final rendition. > BTW, Tom has a brand new version of Life --- No, it doesn't go any faster > but it does let you specify, through a most cryptic programming language, > the initial startup picture... He should post it SOON (hint hint, Tom). Cryptic? It's not that cryptic. Anymore. It's a derivative of Logo, with parameterless subroutines. Maybe I'll post it this week. The new LIFE also supports torus wrap and hi-resolution interlace . . . > Ali Ozer, ali@rocky.stanford.edu Tom Rokicki