ROKICKI@su-sushi.arpa (04/17/86)
From: Tomas G. Rokicki <ROKICKI@su-sushi.arpa> I have an application which requires extremely fast blitter operations. The 420 microsecond overhead for each call of BltTemplate() is too high by a factor of ten. Two questions: a) Is there a way around this with a C function? I have searched through all the manuals, and have come up with nothing . . . b) I currently plan to write a short assembly language function to write to the blitter registers directly. How can I prevent this from mucking with the operating system? How do I tell when the blitter is free, and how do I lock it for my use? Do I have to disable interrupts, or what? All I need is a simple blt operation from one bit plane to another. Any help on this would be greatly appreciated . . . -tom -------
dillon@CORY.BERKELEY.EDU (Matt Dillon) (04/20/86)
>From: Tomas G. Rokicki <ROKICKI@su-sushi.arpa> > >I have an application which requires extremely fast blitter operations. >The 420 microsecond overhead for each call of BltTemplate() is too high >by a factor of ten. Two questions: > a) Is there a way around this with a C function? I have searched >through all the manuals, and have come up with nothing . . . > b) I currently plan to write a short assembly language function >to write to the blitter registers directly. How can I prevent this from >mucking with the operating system? How do I tell when the blitter is free, >and how do I lock it for my use? Do I have to disable interrupts, or what? The only way to get around the overhead is to go to the blitter directly. I believe there is a call ... OwnBlitter() or something like that which gives you full control without worry over the rest of the system using it. You can write to the blitter registers directly from either assembly or C, your choice. If you have a Lattice C compiler, Assembly may be an improvement in terms of speed (unless the operations you are doing are REALLY simple...). Otherwise, if you have Manx or Aztec C, or a compiler which you know produces good code, then go ahead and write it in C..... simply create a char *, short * or long * pointer, and set it to the proper address, and off you go! (This avoids having to write any assembly at all!) -Matt
dale@amiga.UUCP (Dale Luck) (04/21/86)
> >From: Tomas G. Rokicki <ROKICKI@su-sushi.arpa> > >I have an application which requires extremely fast blitter operations. >The 420 microsecond overhead for each call of BltTemplate() is too high >by a factor of ten. Two questions: > a) Is there a way around this with a C function? I have searched >through all the manuals, and have come up with nothing . . . > b) I currently plan to write a short assembly language function >to write to the blitter registers directly. How can I prevent this from >mucking with the operating system? How do I tell when the blitter is free, >and how do I lock it for my use? Do I have to disable interrupts, or what? > If we had provided a way of doing this operation but with only 10% of the overhead, why would we have provided the slow function? :) So there is no magic 'faster' command as there appeared to be in the linker. There are different ways of making your graphics operations faster by reducing the amount of work and increasing the number of assumptions the graphics routines can make. Are you BltTemplateing into a window? If you open a custom screen and use the RastPort that exists in the Screen struct you can elliminate all the layer stuff it needs to do and speed up your graphics operation. This is true for all graphics operations. They are much faster in naked rastports than they are in layered rastports. Note that naked rastports also do not provide and clipping, so you have to know what you are doing before telling it to draw those 1000 pixel lines. Make sure it wont draw outside of the bitmap borders. If this is still not fast enough, and you feel that you can achieve better performance by talking to the blitter yourself then we also make that available in a 'system ok' fashion. There are two ways of doing this. You can use the blit queue which is interrupt driven and asynchronous. You set up a routine to be called by the blitq'er. It gets called when the blitter is free, you then stuff the registers and start the blit yourself, you need to obey proper protocal and return values so that you don't crash the machine here, consult your rkm. You can use OwnBlitter/DisownBlitter. These are synchronous routines. OwnBlitter returns when you logically own the blitter. The blitter however maybe be busy with a blit from the previous owner. After OwnBlitter you should call WaitBlit(). At this time you can stuff those blitter registers and start off a blit. When you are done with your last blit you MUST DisownBlitter or dire circumstances will result. The entire graphics/text/layers/windows/.... (even trackdisk) requires quick and efficient access to this one resource so please play ball with the rest of us. The game will go longer that way. :) Have fun with your new found speed toy. Dale Luck