🚀 go-pugleaf

In article <1989Aug3.201227.18486@sj.ate.slb.com> greg@sj.ate.slb.com (Greg Wageman) writes:
>If QuickST is intercepting certain traps into TOS, and replacing the
>underlying routines with its own, it's possible that calls which would
>normally exercise the blitter never get there when QuickST is installed.
>
>Remember that no applications code has to change to make use of the
>blitter; "Blitter-TOS" uses the chip if it exists and otherwise performs
>the blits in software.  Now if QuickST replaces some (many?) of these
>routines, and doesn't itself use the blitter, then having a blitter
>won't help except on calls that QuickST doesn't trap that do use the
>blitter.  This seems to be the case with some GEM calls.
>
>Darek & Co. could probably get still better performance if they wrote
>a version of QuickST that uses the blitter...



this is something we have been grappling with quite a bit lately since we
are continuously looking for ways to increase GEM speed. the blitter is 
basically good for one thing: copying and clearing of large rectangular
areas. i believe, and correct me if i'm wrong, but most of the work that 
goes on in GEM based programs is usually the opening of windows, drawing
dialog boxes and alert boxes, or, getting down to the nitty gritty, simply
lots of text plotting and line drawing (ie: boxes, menus, dialog buttons).
the blitter does not do any of these things, simply the blitting (copying)
of one rectangular area to another, and clearing (or filling??) or rectangular
areas. thus, myself and darek chose to rewrite the text plotting and line
drawing algorithms used in the Atari ROMs so that those functions would run
at their peak performance. we have left the copying of bit blocks to the
operating system since this is NOT done as often as line drawing or text
plotting.

as for the scroll test, we did indeed write our own scroll routine, since
the majority of st owners do not have the (legendary??) blitter chip, and that
our 127% (or whatever the latest stats say) is much better than leaving the
operating system to do it. the blitter is about 3-5% better in this case, but
in reality, how often do you scroll complete screenfuls of VT-52 text??
therefore, rather than try to detect the presence of the stupid blitter, and
then set up all the idiotic parameters needed to do a blit, we call our much
simpler routine inside QuickST to do the screen blit for scrolling the screen.
sure, blitter owners may loose 5% for screen scrolls, but the savings in code
space by not worrying about the blitter i think more than justified not
using the blitter (remember, on every GEM call we would have to test for the
presence of the blitter, which would impair performance slightly over what
we have now, for very little gained. and since more people do NOT have a blitter
than vice versa, faster code was deemed more important than blitter 
compatibility.)

i hope that straigtens out the blitter controversy with Quick ST. now if
someone (like at atari) is willing to send me a blitter to put in my 1040ST,
then maybe, just maybe, we could re-consider ....    :-)  :-)  






-- 
=====Ignac A. Kolenko (The Ig)           watmath!watcgl!electro!ignac=====
     co-author of QuickST, and the entire line of Quick Shareware!!!!
       "I don't care if I don't win, 'cause I don't care if I fail"
             from 'Youth Of Today' by SUBURBAN DISTORTION