CpuBlit V1.00 -- Uses CPU to perform blitter functions
(c) Copyright Eddy Carroll, April 1991. Freely Distributable.
GETTING STARTED
In brief, CpuBlit makes your 68020/68030-equipped Amiga scroll text
about twice as fast as before. You can quickly try it out as follows.
Run CpuBlit (make sure you have the cache enabled). Now try Typing a
file in a CLI window. Look at the speed. Change the text colour to
colour 3. Type the file again. Look at the lack of flicker on the text
as it scrolls. Nice, eh?
If you have Workbench 2.0, you can install CpuBlit permanently by
simply dragging its icon into your WBStartup drawer. Otherwise, you
need to call CpuBlit from your Startup-Sequence. I recommend using the
-2 or -s options for general use, though you may like to experiment
with the others.
Now read on for a more detailed description.
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
You can start CpuBlit from either the CLI or the Workbench. There are
a number of parameters you can change, to alter CpuBlit's operation.
When you start CpuBlit, it automatically detaches itself from the CLI
window. Any combination of the following options can be given on the
command line or as Workbench ToolTypes. Note that each options has
two ways of specifying it. You can use whichever way you like best.
BLITMODE=ALWAYS
-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.
BLITMODE=ONE
-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.
BLITMODE=2
-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 system friendly as using -1. It should be more than adequate for
most people however.
BROKEN=[YES|NO]
-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.
SINGLE=[YES|NO]
-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!
MINTASKPRI=N
-pN
If you like to keep a program running in the background (like a
Mandelbrot generator) then you may find it counteracts the -1 and -2
options (since it is always ready to run). You can tell CpuBlit
to ignore all such tasks using this option; any task with a priority
less than N will not be considered ready to run.
Normally, CpuBlit will ignore any tasks with a priority less than
zero, which is perfectly adequate for most cases. You can override
this with a different setting if you like. For example, setting
MINTASKPRI=-5 will cause your Mandelbrot program at priority -1 to
be considered, but not your CPU monitor at priority -20.
BLITMODE=SHARE
-s
In this mode, CpuBlit attempts 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).
HELP
-h
Prints out a brief help message, listing the valid options. In fact,
giving any invalid option will cause this message to be printed.
QUIT
-q
This option asks any copy of CpuBlit already installed to remove
itself. If another program has patched BltBitMap since CpuBlit was
started, you'll get a message asking you to terminate that program
and then try again.
If you run CpuBlit with no options, it behaves as if you had typed:
CPUBLIT BLITMODE=ALWAYS SINGLE=NO BROKEN=NO MINTASKPRI=0
You can pick a different mode of operation at any time by simply running
CpuBlit again with new options; it's not necessary to remove the previous
copy first. You can use -a to cancel the effect of the -b and -o options.
Note that only one of -a, -1, -2 and -s can be in effect at a time. Also,
the BROKEN and SINGLE options default to YES if you use them without
specifying a YES/NO value.
WORKBENCH
As mentioned above, CpuBlit can be started from Workbench. It doesn't
return to Workbench until it quits, so if you are starting it from your
WBStartup drawer (under 2.0) one of the tooltypes must be DONOTWAIT.
in the icon.
When CpuBlit starts up, it parses all the ToolTypes in its own icon,
followed by the tooltypes in any project icons you specified. This
can be handy if you have several configurations of CpuBlit that you
like to switch between. Simply create a project icon for each one,
and set the appropriate tooltypes. Then set the default tool for each
icon to CpuBlit. Now, clicking on any of the icons will set the
corresponding CpuBlit options.
To remove CpuBlit from Workbench, you need to start it from an icon
which has a QUIT tooltype. The standard CpuBlit distribution includes
such an icon that you can use. If CpuBlit cannot remove itself (perhaps
because someone else has patched into the BltBitMap routine ahead of
CpuBlit) then the screen will flash. You can type CpuBlit QUIT in
a CLI window for a more detailed explanation.
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, Mike Meyer, Urban Mueller, Jamie Clark, Marc Jacobs and
Albert-Jan Brouwer. Their help is greatly appreciated.
AUTHOR
Eddy Carroll
Email: ecarroll@maths.tcd.ie
Phone: +353-1-287-4540
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 library.
