Amiga Elysian Archive/AmigaElysianArchive.iso/comm/term33in.lha/Documentation/Tools/CpuBlit.doc

Text File | 1992-08-23 | 14KB | 288 lines

              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:     [e-mail]
    Phone:     [phone]
    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.