CpuBlit V0.96 -- Uses CPU to perform blitter functions (C) Copyright Eddy Carroll, February 1991. Freely Distributable. NOTE This is a beta release. Please refrain from spreading it around until I release version 1.0. If you come across any bugs, send bixmail to dhanna or email to ecarroll@maths.tcd.ie. I'm hoping to make CpuBlit runnable from Workbench for the official release, so if anyone can come up with a good icon, I'd love to use it. Quick intro for those who don't like reading doc files: Run CpuBlit on your 68020/68030 Amiga (make sure you have the cache enabled). Now try Typing a file in a CLI window. Look at the speed. Change text colour to colour 3. Type the file again. Look at the lack of flicker on the text as it scrolls. Nice, eh? Read on for more details... INTRODUCTION After upgrading from an A1000 to an A3000 a while ago, I was in Amiga heaven. The display was great, the disk performance much improved, and the speed awesome (at least compared to the A1000). But there was one blemish on this otherwise perfect scene: the speed of text scrolling in CLI windows. On a 704 x 560 screen, a snail wouldn't have much trouble keeping up with a full size CLI window. Thus was born CpuBlit. It replaces the standard system BltBitMap routine with a version that uses the 68030 where practical. The 68030 can comfortably outrun the blitter for simple tasks like scrolling, although the blitter still wins out if the data has to be bit shifted as well (for example when scrolling sideways). Another benefit of using the CPU is that it isn't constrained to operating on one bitplane at a time; it can do them all simultaneously. So, the infamous "flicker" effect when coloured text is scrolling disappears. This is particularly useful when you're logged onto a bulletin board with colour ANSI menus. At this stage, I imagine some of you are getting ready to jump up and complain about system throughput suffering, and how overall, the blitter plus the CPU is faster than the CPU on its own. I certainly wouldn't argue with that. So, CpuBlit can be setup to only use the CPU if no other tasks are ready to use it. That way, you get improved performance when you are single tasking, yet multiple tasks operate at full efficiency. There is one caveat. CpuBlit will probably only be of use to you if you have at least a 68020 installed in your Amiga; using the standard 68000 doesn't give any noticeable speed increase. In fact, even a standard 68020 Amiga may not give much speed increase since it only has a 16 bit datapath into chip RAM. The A3000 on the other hand can access chip ram 32 bits at a time and CpuBlit takes advantage of this. The easiest way to find out is to give it a try and see if you notice any other difference. A3000 owners will certainly notice a difference -- an A3000-25 performs blits about 2.8 times faster than the blitter, which results in text scrolling at about twice the normal speed (actually displaying the text to be scrolled takes a constant amount of time, regardless of what method you use to scroll it). To get the best speed increase, use a non-overscanned screen of not more than four colours, and ensure you have the CPU cache enabled (it is disabled by default under Workbench 1.3 -- use SetCPU by Dave Haynie to enable it). Both overscan and 8 or 16 colour screens will decrease CpuBlit's efficiency, since the custom chips access CHIP ram more frequently, leaving less time available for the CPU. Even with these restrictions, you should still find CpuBlit about 50% faster than the blitter on the A3000. USAGE When you start CpuBlit, it automatically detaches itself from the CLI window. You can give one of several options to finetune how it works. Here's a list of each option, along with an explanation of how it affects CpuBlit's operation. You can specify more than one option, but note that only one of -a, -1, -2 and -s can be in effect at any one time. -a This is the default setting, so you normally don't need to give it specifically. In this mode, CpuBlit always use the CPU where possible. If you tend to only do one thing on your Amiga at a time, this is probably the best option to use. -1 In this mode, CpuBlit will only use the CPU for blits if there are no other tasks ready to run at that time. The blitter is used at all other times. Hence, you get fast blits whenever the CPU would be otherwise idle, and normal processing speed when running multiple tasks. There is one catch. When displaying text via the console device, the program displaying the text is considered to be still running, even though it's the console device that actually outputs the text. For those interested, this is because the console device runs at a higher priority than user applications and so preempts the task before it has a chance to go to sleep. Hence, CpuBlit will think the program is waiting to do work, and won't use the CPU for blitting. This means that the -1 option will only speed up scrolling when a task scrolls the text directly, rather than indirectly via the console device. Comms packages and text editors are the most likely candidates for this. Standard CLI windows won't show any improvement. -2 In this mode, CpuBlit will only use the CPU for blits if there is at most one other task waiting to run. This results in everything being speeded up (both applications and CLI output) but isn't quite as efficient as using -1. It should be more than adequate for most people however. -b Some programs don't initialise bitmap structures properly. By default, CpuBlit passes such bitmaps on to the blitter and doesn't attempt to handle them. Using this option tells CpuBlit to bypass the validation checks it normally performs on bitmaps, and so may allow broken programs like this to gain the benefits of faster blitting; it may also cause problems. If you have a program that you think should be sped up by CpuBlit and it seems to be showing no noticeable change, then give this option a try; else, leave it alone. -o This option tells CpuBlit to only handle blits where the source and destination bitmaps are the same. Typically, this only happens when a text window is scrolling. Normally you should not need to use this option as CpuBlit should co-exist happily with every program that uses the blitter. However, if CpuBlit seems to be incompatible with some particular application, specifying `-o' will allow you to continue using it. Don't forget to notify me about the problem, so that it can be fixed! -s In this mode, CpuBlit attemps to share blits between the CPU and the blitter. The CPU will be used for blits by default, but if a task tries to blit some data while another task is already using the CPU to blit data, the blitter is used for the former. The result is better overall throughput. If you try experimenting with two CLI windows to see this effect in action, you won't notice anything; this is because the console.device used for scrolling CLI windows is single threaded and waits for a blit in one window to finish before starting another. Hence, both windows are scrolled using the CPU. It works fine in the case of a CLI window and a program that bypasses the console device (such as a comms package). -h Prints out a brief help message, listing the valid options. In fact, any invalid option causes this message to be printed, not just -h. -q This option asks any copy of CpuBlit already installed to remove itself. If another program has patched BltBitMap since CpuBlit was run, you'll get a message asking you to terminate that program and then try -q again. You can pick a different mode of operation at any time by simply running CpuBlit again with the new option; it's not necessary to remove the previous copy first. You can use -a to cancel the effect of the -b and -o options. IMPLEMENTATION This section gives a brief description of how CpuBlit works. It's not necessary to read this to use CpuBlit, it's included merely for those interested. CpuBlit only handles blits with a very specific set of characteristics. First of all, the source and destination bitmaps must be aligned on the same bit boundary within a longword. For example, a blit from 0,0 to 128,100 would be okay whereas a blit from 0,0 to 100,100 would fail. In addition, only blitter functions of the form $Cx are supported (i.e. plain replace operation). Also, the source and destination rows must be different; if they are the same, a sideways blit is being performed, and this is not supported. Assuming the blit fulfills all these criteria, CpuBlit then checks system activity to see whether or not it is appropriate to use the CPU at all. Exactly what is checked depends on the option selected when CpuBlit was installed. Assuming everything is still okay, CpuBlit then works out how many bitplanes there are in the bitmap, and calls one of four routines to handle the actual scrolling. It also handles any bitplane pointers of $FFFFFFFF or $00000000 at this time (new for Workbench 2.0, these values are legal for bitplane pointers, and act as if they pointed to either a solid or empty bitplane). If there are more than four bitplanes, the blit is split into two operations; the first four planes are moved, followed by the remaining planes. While this results in a bit of colour flicker for deep bitmaps, it is still not as bad as when the bitplanes are moved separately. The actual bitmap copying is done using optimised 68000 code. The bulk of the data on each row is copied using a MOVE.L/DBF loop, and the uneven bits at the sides are copied separately. No non-68000 instructions are used (there wouldn't be any advantage to it anyway) so CpuBlit will still run on a 68000 Amiga (not that there's much point). Due to a lack of CPU registers (only 16 ... how DO people manage on Intel chips with a mere 8 registers? :-) the routines for copying three and four bitplanes aren't quite as efficient as those for copying one and two bitplanes. However, they are still quite a bit faster than the blitter itself, and the removal of colour flicker is more than worth the small loss in speed. ACKNOWLEDGEMENTS Thanks to Andy Mowatt for encouraging me to change CpuBlit from an idea into a program. Thanks also to the following people who provided useful feedback and bug reports for beta versions of CpuBlit: Steve Tibbett, David Joiner, Mike Sinz, Dan Ten Ton, Robert Jenks, LeRoy Hutzenbiler, Jim Biggs, and Mike Meyer. Their help is greatly appreciated. AUTHOR Eddy Carroll Email: ecarroll@maths.tcd.ie Bixmail: dhanna Phone: +353-1-874540 Snailmail: The Old Rectory, Delgany, Co. Wicklow, Ireland. DISTRIBUTION CpuBlit may be freely distributed, as long as no charge is made other than to cover time and copying costs. If you want to include CpuBlit as part of a commercial package, contact the author listed above. Fred Fish is specifically given permission to include CpuBlit in his fine disk collection.