
    ICTARI USER GROUP              ISSUE 16                  November 1994

         ___   ______     ___       _________   _________   ___
         \__\  \   __\    \  \__    \______  \  \   _____\  \__\
           ___  \  \       \  __\     _____\  \  \  \         ___
           \  \  \  \       \  \      \  ____  \  \  \        \  \
            \  \  \  \_____  \  \____  \  \__\  \  \  \        \  \
             \  \  \       \  \      \  \        \  \  \        \  \
              \__\  \_______\  \______\  \________\  \__\        \__\

                     *   m   a   g   a   z   i   n   e   *

     =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
                       I C T A R I   U S E R   G R O U P
       63 Woolsbridge Road, Ringwood, Hants, BH24 2LX   Tel. 0425-474415
     =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

                              INDEX FOR ISSUE 16
                              ==================

    ASSEMBLY        IMG mono picture decoding routine.
                    Degas PI1-3/PC1-3 picture decoding routine.
                    Tiny TNY/TN1-3 picture decoding routine.
                    PC Paintbrush PCX picture decoding routine.
                    STAD PAC picture decoding routine.
                    Tiny low rez decoding routine.
                    IMG/IFF/DEGAS/NEO packing/unpacking routines.

    C               TNY picture decoding routine.
                    LZW TIFF compression definitions and algorithms.
                    Neochrome picture show program.
                    GEM Tutorial by J White. Part 6.
                    IMG picture loader code.

    GFA             CrackArt picture compression/decompression code.
                    Spectrum (SPU) picture format information and code.
                    Tiny picture decompression code.

    STOS            Using 80 column text in low rez.
                    VDU dump program.

    MISC            Algorithm Corner. Star Wars scroll & Huffman coding.
                    Video Master picture file format information.
                    Falcon screen resolution detection.
                    The IMG, IFF ILBM formats plus EDT sprite file info.
                    Atari Questions and Answers file No 5.
                    PCX picture format information.
                    TIFF/LZW technical memorandum.
                    Current membership list.
                    Index to Issues 1-15.

    In next months issue of ICTARI (this may change) :-

    ASSEMBLY        GEM Window redraw routine.
                    Sprite packer/unpacker routine.
                    Rectangle intersection detection code.

    C               Useful MagiC C functions.
                    GEM Tutorial.

    GFA             Mandelbrot generator.
                    ShadeBob, 4 bit real time shading.
                    GFA menu locating techniques.

    STOS            Factorial generator program.
                    Puzzle solving program.
                    STOS on the Falcon.

    PASCAL          Program to calculate shift bonuses, etc.

    MISC

    For future issues :-

    Polyline drawing routines in machine code.
    Bezier curve drawing routines.
    Picture compression routine for IMG pictures.
    HP DeskJet/LaserJet compression routines (Mode 2 TIFF).
    Picture switching techniques.
    Printer driver code for printing mono/colour images.
    Using Calamus fonts.
    Sorting algorithms.
    Using the BitBlit routines.
    Code for using the File Selector.
    Using multiple rasters in machine code.
    Overscan techniques.
    STOS sprites.
    ----------------------------------------------------------------------
                                  EDITORIAL
                                  =========
    MEMBERSHIP
    ----------
    We have had  four  new  members  join  this  month  including one from
    Denmark, welcome to them.

    IMAGE COMPRESSION/DECOMPRESSION
    -------------------------------
    As you can see, this month most of the code and articles are concerned
    with picture formats,  image  decompression  and  compression.  In the
    assembly folder I have provided a few of my own unpacking routines for
    various picture formats that I have been  using for some time. We have
    also received a comprehensive  file  of  similar  routines from Marten
    Lindstrom which, I have to  say,  are  considerably better, but I have
    left mine in anyway just in case anyone finds them useful.

    OMEGA BBS
    ---------
    We have had an offer to  advertise  ICTARI  on the OMEGA BBS system in
    Ewell, Surrey which we have  taken  up.  This  may  provide a few more
    members although I think  the  BBS  is  mainly  geared  towards the PC
    community. Perhaps anyone with a Modem  could check it out on 081-393-
    6226, 8.00pm to 2.00am (8-N-I to 14400bps).

    DISK COPYING
    ------------
    Does anyone have a program  that  can  make  FAST multiple copies of a
    disk. When I have to duplicate  the  ICTARI  disks it takes me about 3
    hours using Acopy and it would  be  nice  to  be  able  to do it a bit
    quicker. I have tried FastCopy  Pro  but  this takes four times longer
    when it has to format the  disk  as  well.  I  have got a demo copy of
    Kobold (which won't format) but I  don't  think this is any better for
    multiple copies. If anyone can  suggest  a  suitable program (or would
    like to write one) please let me know.

    ARTICLES
    --------
    We are now very short of articles  for next years issues of ICTARI. If
    you have any code or general  programming articles please send them in
    as soon as possible, especially  if  you  have not contributed before.
    If everybody just sits back  and  waits  for  someone  else to send in
    material for disks we will shortly run out altogether. If you have any
    ideas on what subjects you would like  to see covered in future issues
    please let us know and we might be able to help.
    ----------------------------------------------------------------------
                                CORRESPONDENCE
                                ==============
    To: *.*
    From: Peter Hibbs

    Since this issue is all  about  picture compression techniques I would
    like to ask if anyone has  any  thoughts  about text compression. I am
    writing a program in machine  code  which  requires  access to a large
    number of words in the  form  of  a dictionary. Obviously the simplest
    way would be to store all the words  as an ASCII file with a non ASCII
    separator between each one and there is a PD file available which does
    just this. The problem with this  approach  is  the size of the file/s
    which could run to 1-2 Mb. I really  need to compress the file in such
    a way that I can  still  access  individual  words  as  well as add or
    delete words from the file.

    The sort of options I would require  are  to  copy a word into a small
    buffer and then call a routine which  would tell me if the word exists
    in the dictionary file. Upper or  lower  case letters don't matter and
    the order of the words in  the  file  is  not important, the number of
    letters in each word could vary from 2 to whatever.

    I don't know how the dictionary  files  that come with word processors
    are made up but I would  guess  that  they  are compressed in some way
    using common letter  groups  found  in  English,  i.e. 'ing', 'ation',
    'ent', etc which could be encoded  as  single bytes and common endings
    like 's','ed','es', etc could be stored  as set/reset bits in a single
    'endings' byte.

    If anyone knows how dictionary files  are  stored  or has any ideas on
    the subject please let me know.
    ----------------------------------------------------------------------
    To: *.*
    From: Dick Teuber

    Does anyone have (or has anyone written) a program which can intercept
    the output from  a program to a  printer  and  write it to a disk file
    instead. The file on disk can then  be moved to another computer (i.e.
    a PC) and sent direct to the  printer  and  so be printed out like the
    original file. The program should  be  able  to  work with any program
    that outputs data to the parallel port.
    ----------------------------------------------------------------------
    To: ICTARI
    From: Iain Mcleod

    I think  I  should  have  explained  my  request  more  clearly  about
    bitmapping a sprite onto a polygon!!!!

    What I was wanting to know is, well  I'll give an example.. You have a
    wall disappearing into the distance and  how  do  you give it a *wall*
    texture, i.e map a drawing of a wall on to the (distorted) rectangle.

    But of a higher priority... I want to  play tracker songs in my game -
    I can only get one channel  using  the XBIOS bufptr, etc.. calls. Does
    anyone know how or (even better) have  a copy of the tracker code they
    can give me.

    Keep up the *great* work on ICTARI. I will try to add more answers and
    less questions but then without  questions,  you wouldn't have answers
    (?!).

    I'm also a member of the  FALCON  FACT  FILE so I'll mention ICTARI to
    them.

    I also recommend any FALCON user to register :

            FFF,
            11 POUND MEADOW,
            THE GREEN,
            WHITCHURCH,
            HANTS,
            RG28 7LG

    Membership is free also except for postage.
    ----------------------------------------------------------------------
    To: Mark Baker
    From: Jim Ford

    Thanks for the info that  Gnu  C++  is  up  to 2.5.8. Does anyone know
    where it is available for the Atari ?
    ----------------------------------------------------------------------
    To: Peter Hibbs
    From: John Logan

    "Computer Arithmetic - Logic and Design" by Otto Spaniol. John Wiley &
    Sons 1981.

    I had forgotten how expensive this book was and now that I am reminded
    of the price, I doubt whether it  is  of interest to anyone other than
    mathematicians or computer engineers. It  offers "quick and economical
    algorithms for performing arithmetic  operations in digital computers"
    and "a comparative discussion of differing  concepts which can be used
    when  designing  computers".  The  book  considers  representation  of
    numbers, the logic of adders,  methods  of multiplication and division
    and the calculation of special functions. The algorithms are described
    by microprograms. These are the hardwired programs used to control the
    CPUs  of  computers.  The  first  2  lines  of  a  restoring  division
    microprogram follow (DD, DE and DR  are  registers, n is the number of
    bits in a word, SHL is  shift  left,  Z  is  the zero flag, V overflow
    flag):

    0: (DD,DE) := dividend;DR := divisor;Z := n;V := DD n-1 XOR DR n-1;
    1: if DR n-1 =  DR  n-2  then  [SHL(DD,DE);DE  0  := 0;SHL(DR);DR 0 :=
    0;goto 1];
    2: etc etc

    Such emphasis as there is, is  on the implementation of the algorithms
    in hardware although there is probably  no  reason why they should not
    be implemented  in  software.  I  was  interested  in  the  methods of
    speeding up division but I have to confess that I could not understand
    them. Not recommended for most programmers.

    "Microprocessors and Microcomputers"  by  Eric  Huggins. The Macmillan
    Press Ltd 1979.

    This a  much  friendlier  book.  It  describes  the  evolution  of the
    microprocessor and then considers in some  detail how a CPU works, the
    binary and other number  systems,  programming  elements, hardware and
    finally software. The latter was the  most  useful to me as both fixed
    and floating point algorithms  were  covered  and  methods of division
    were fully explained. (It is not uncommon  for an author to explain in
    detail the process of multiplication and then "leave it to the reader"
    to work out how to divide. I always  take that to mean that he/she did
    not know how do it.)  Special  functions (square roots, logs, antilogs
    and trig) are all covered. Not  only  are the basic principles set out
    but flow charts are given.

    Do not be put  off  by  the  beginning  of  the  book  where there are
    descriptions and pictures of  elffins  and  demure damsels! The former
    are "ELectronic Fetchers and  Filers  of  INformation"  and the latter
    "Direct the Elffin to the correct Memory location, Updating REgisters,
    Doing   Arithmetic   and   Monitoring    the    Status   record;   all
    ELectronically." They are used to illustrate how the basic CPU works.

    I am sorry to hear that  the  book  is  no longer available. Perhaps a
    second hand bookshop might be able to supply a copy.

    */ Thanks for  the  info  John,  perhaps  if  anyone  comes across the
    Huggins book in a bookshop anywhere they could let us know. ICTARI /*
    ----------------------------------------------------------------------
    To: Ictari and all assembler programmers
    From: Mrten Lindstrm

    I send you  (together  with  this  message)  an  assembler sub-routine
    library, for un/packing IMG and IFF  ILBM pictures. It has been fairly
    extensively  tested,  except  that  PUTFM  and  GETFM  (non-GEM  image
    copying) have only been briefly  tested  with  a blitter (I don't have
    one of my own so I had to  ask  my  brother to do the test for me) and
    that SETTRU (for non-GEM palette  setting  on a general Atari machine)
    may not work on a Falcon. I  hope  you  have  found room for it all on
    this disk.   */ See ASSEMBLY/PIC_PACS folder. ICTARI /*

    Has anyone complained  about  the  disk  format  (10 sectors/track)? I
    personally find nothing wrong with it  (it  is  what I use with all my
    personal disks), but if  anyone  should  have  problems  copying it, I
    think it  would  be  possible  to  include  a  small  (1-2  K)  simple
    format/copy program on  each  disk.  Maybe  you  should  also consider
    packing more of your material into self-extracting files?

    */ We have had  someone  'complain'  about  non-standard disk formats,
    primarily disks that were formatted  to  more  than 80 tracks. Also we
    have had problems formatting some disks with more than 80 tracks which
    is why we do not use this  option  any more. Formatting tracks with 10
    sectors is usually OK but we  normally  use 9 sectors unless we really
    need to squeeze more on a disk.  As  I  am sure everyone knows, if you
    copy a full disk that is  formatted  with 10 sectors/track onto a disk
    which is formatted with  9  sectors/track  using  the  normal desk top
    copying options, the TOS copies  what  it  can  to the target disk but
    leaves off anything it cannot copy  WITHOUT informing the user. If you
    don't happen to notice the missing  files  you  end up with some files
    missing on your copied disk.  We  could  provide  a small copying type
    program but we suspect that most members just take copies of the files
    that they are interested in  and,  in  any  case,  there are plenty of
    copying programs in the Public Domain. We  try NOT to pack files if we
    can avoid it because it is easier  for members to copy/read files when
    they are not packed. If anyone  has  any  views on this subject please
    let us know.  ICTARI /*

    As soon as I joined Ictari I,  of course, immediately ordered all back
    issues, so I have read  all  the  main  texts  at least. Regarding the
    discussion on the format for assembler sub-routines I'd like to say:

    1) I wholeheartedly support the view that routines intended to be used
    by others should normally  save  all  registers  that  aren't used for
    return values.

    2) I also would  like  to  suggest  that  low  ordered registers - and
    especially D0 - are used as preferred registers for return values.

    3) Finally, my own practice is to  always make sure that the processor
    condition flags on return from  a  sub-routine  are set according to a
    return value in D0  (when  applicable  -  e.g.  when  a negative value
    signals error). I know it may  be  a  bit  late, but how about it? The
    advantage is that it saves you a TST instruction in the main routine -
    which is where I think brevity and clarity should be maximised.

    To: PoshPaws - man with many names - or anyone else with a Falcon

    Could you please answer two Falcon questions  (that came up when I was
    writing the non-GEM complemental sub-routines  in the PICPAC.S library
    - for IMG/IFF pictures un/packing - hopefully on this disk):

    1) With the exception of  high  colour  resolutions, could you confirm
    that all other Falcon  screens  (especially  the  256 colour ones) are
    organized word-interleaved? I know that the Atari compendium says that
    each  and  every  Atari  resolution   (except  high  colour)  is  word
    interleaved, but the reason I doubt  this  is  an article in German ST
    Magazine indicating that TT low rez is BYTE interleaved.

    2) Does VSETRGB copy colours to  hardware  immediately or does it wait
    for a VBL (like SETPALETTE)?  (My  routine  SETTRU,  intended to set a
    palette on a general Atari  computer,  as  written  is counting on the
    former.)

    To: everybody

    I hope you gave my country  a  thought  this month. When you read this
    the Swedish people will  hopefully  have  decided  to  join the EU, in
    which case I intend to  order  some  things from 'Europe' (=UK mostly)
    this new year, first of which will  be  Devpack 3. I have, for fear of
    harassments by the Swedish customs,  for  a  long  time now lived with
    Devpack 2 (cover disk release) +  Easy Rider, a German assembler which
    is very good,  with  more  and  better  optimization  options and more
    powerful macro string handling than  Devpack  2,  but not as friendly.
    Long live the European Union!!!

    */ Just heard on the news that Sweden have voted to join the EU, just.
    Hope they know what they are doing.  ICTARI /*
    ----------------------------------------------------------------------
    To: ICTARI
    From: Tony Harris

    I have a couple of programming questions (in 68000).

    1) Any examples of using the  STE's  BLITTER  and H/W chips for sprite
    and screen manipulation.

    2) I need to know how to  redraw  windows  after a DA's been called or
    any disturbance of the windows ?

    */ We have published a comprehensive  document  on the Blitter chip in
    Issue 11 and various issues have  covered  sprite use (although not, I
    think, using the blitter). See next  month  for window redraw code and
    INDEX.TXT file in the MISC folder for back issue list. ICTARI /*
    ----------------------------------------------------------------------
    To: *.*
    From: Richard Evans
                                Some views on
      2B's MagiC 2.0 multitasking OS, running on an STFM with NVDI 2.51
      -----------------------------------------------------------------

    I'm sure that any feedback on  newish  software  such as MagiC must be
    useful, so I will give  you  my  impressions  so  far. Generally it is
    excellent, the whole system  is  much  faster,  and  with NVDI as well
    screen updates are no  longer  a  problem-  programs such as Kandinsky
    become useable. Whilst the mag reviews  didn't think much of MagXdesk,
    I have to say that for the majority  of users it should be fine, as it
    is  small and there are  many  useful  features hidden in the keyboard
    shortcuts for editing,  calling  cli's,  passing  parameters  etc. The
    system copes well with  minor  compatibility  problems  and is able to
    tidy corrupted screens, pass  control  away  from  locked programs and
    delete them from memory. Extended  system  routines mean that some GEM
    programs have  extra  features  similar  (but  less  comprehensive) to
    Let'em'fly, windows have a  backdrop  button  and  do  not  have to be
    topped to scroll, size, close,  etc  (some  older programs, and the LC
    5.52 editor don't respond however).  TOS  programs run in windows, can
    use GDOS fonts and have  clipboard  support etc. Software written with
    multitasking in mind run  perfectly  (obvious  I s'pose), though MagiC
    does not yet support some  more  advanced  MTOS features such as drag-
    and-drop. Badly written software such  as  Protext  and Prodata can be
    run in single  mode,  though  the  reliability  of  the  system may be
    compromised. In use, the system  is responsive even when multi-tasking
    and is absolutely brilliant for  those  endless hours of de-compacting
    files etc. If the system is slowing down too much, there are utilities
    to control the amount of  processor  given  to background tasks, which
    should greatly reduce any potential  problem  (I've only needed to use
    them once). The  manual  supplied  is  better  than  average, covering
    MagXdesk and listing new system calls  in some detail- it does however
    presume that readers have  knowledge  of  GEM/2  and  AES  4.x, and an
    appropriate reference  manual  would  be  required  for  inexperienced
    programmers  (me!)  trying  to  write   programs  for  these  enhanced
    environments; there also appears to be a few errors in the programmers
    section, just to keep you  on  your toes! Installation is refreshingly
    simple, and some utilities  such  as  a  CLI  and  routine library are
    supplied; unfortunately the utilities and  accompanying text files are
    in German, and the library is  for  Pure  C-  I hope 2B might consider
    translating these and supplying a Lattice library (unlikely !).

    Cons:

    There had to be some! A lot of my older GEM software, especially PD is
    not reliable enough to use safely;  though  most of it is junk anyway,
    it could be worth  checking  your  favourite  software before you buy.
    KnifeST goes very strange if you  try  to  swap to another program and
    Wercs (as supplied with LC 5.52)  crashes  all  the time- I have never
    liked this program  much,  and  it  apparently  crashes  on the Falcon
    anyway: come on HiSoft, it's  about  time WERCS was rewritten. Protext
    V4.37 and Prodata will only run in  single mode and the Protext config
    program locks if the mouse  is  used.  My  favourite CLI by far, Gulam
    (beta test version)  has  problems  running  because  the key bindings
    remap the keyboard and some (not all) other programs then produce junk
    when you  use  the  keyboard;  pressing  shift-help  when  in  use can
    sometimes limit the problem.  Cubase  Lite,  and  a borrowed Cubase V3
    crash on loading- this is a major  problem for me, so for the meantime
    it has to be back to  my  old  TOS for these; apparently Steinberg are
    checking this out. KCS Omega V1 is  out  as well, Tiger is better than
    KCS, but the screen still gets messed up, menus swap by themselves and
    so it's again back to the  old  TOS  (mind you, Omega isn't too stable
    under that either!). Lastly, and most  drastic  of  all in my case, X-
    Debug has become unusable; whilst it  appears  to  run OK, it locks up
    when running my GEM programs, I don't know where the problem lies, but
    I have set the assumptions flag  to  1,  and it makes no difference; I
    admit this may be because I  haven't  fully  got to grips with all the
    options available in X-Debug, but  as  my  programs run OK normally on
    MagiC, within MonST and within X-Debug  with  my  old ROM TOS, I don't
    think this is the case. I sincerely  hope that Andy Pennel will revise
    this, as I can't live without it.

    Here is a list of all the software  I  have been able to try out, with
    the results as follows:

    Software that runs OK under Magic & NVDI (may need memory limiting):

    Address                 V1.8 (unregistered)
    AIM                     V3.00
    Calligrapher            (STR  version):won't   switch   when  printing
    though
    Devpac                  V2
    Edith                   V1.0 (demo)
    Egale                   V1.52
    Everest                 3.3E (unregistered)
    Ghostscript             V?
    ST-Guide                V(27.5.94)
    Imagecopy Colour
    Kandinsky               (unregistered)
    Kobold                  (STR demo)
    Lizard                  V1.0
    Opus                    V2.2
    ORCS                    V1.0(unregistered)
    Lattice C               V5.52: won't switch when compiling from editor
    Selectric               V1.1
    Superbase Personal      V1.028
    TEX                     V2.9 & probably V3.1

    Programs that run with some problems: (* means not recommended):

    Arabesque               (STF version) ; single only
    Calamus                 V1.09n
    Easydraw                V2
    Gulam                   Beta test; problems with keyboard entry
    KCS Omega               V1 *
    KnifeST                 V1.1    ; don't switch tasks
    Megapaint               V2 *    ; single only, screen gets very messy
    Music DTP               V2.2c
    Prodata                 V1.18   ; single only
    Protext                 V4.37   ; single only, avoid config program
                                      if possible
    Tempus                  V2 *    ; As usual, this one is a real pain !

    Programs that fail miserably:

    Cubase Lite             V1.0
    Cubase                  V3      ; presumable all other V's as well
    DIPS                    V?
    Omen                    (demo version); What did you expect?
    TEXdraw                 V?
    Wercs                   V?
    X-Debug                 V1.01   ; unless I'm missing the point here?

    A lot of old PD doesn't work.

    Autoswitch Overscan software V3.00 is not compatible with MagiC, I was
    told it was when I bought mine,  so  ask for some proof before forking
    out good money!

    Summary:

    In general, the sooner MagiC becomes  officially recognised as the new
    Atari operating system the better, as  unlike MTOS, it offers a stable
    total replacement to TOS, and it works  !! There are also hints in the
    MagiC manual that suggest Mint/MTOS  features  will  be added in later
    releases. Despite problems, compatibility  is generally excellent, and
    lets face it, none of the  competition  is  going to be better in this
    department; many recent  German  shareware  programs  actively support
    MagiC, and the quality of this stuff is generally amazing. From what I
    read, Geneva  seems  less  reliable  than  Magic,  is  not  a complete
    replacement (it won't  run  on  pre  TOS  1.4  machines)  and does not
    support pre-emptive multitasking, - I'll  leave  you to make your mind
    up on that one!

    These are obviously only my views  and  I will not be held responsible
    for  any  errors  in   this   text   or   problems  arising  from  any
    interpretations or assumptions made from it.  I  hope this has been of
    some use, and please bear in mind that some compatibility problems may
    be caused by NVDI and not MagiC (I couldn't be bothered to check every
    program!). If anyone has similar problems,  or  has answers to some of
    mine, please write to me.  If  anyone  has software that needs testing
    under MagiC or/and NVDI (4 meg  STFM+HD+MM),  I will be happy to check
    it, but you must enclose a S.S.A.E. or I will not reply, you have been
    warned!

    By some freak happening (why do I get so many of these?!) NVDI did not
    get installed correctly on  my  system,  and  it  took  me  3 weeks to
    notice. The differences are  not  great,  but  the  system is now even
    faster, and slightly  more  compatible:-  If  run  singly,  the screen
    problems with KCS and  Tiger  are  less  problematic,  however the MPE
    crashes badly if you try to  run  Tiger  from within KCS. I was having
    screen redraw  problems  with  Megapaint,  but  these  are  fine  now.
    Arabesque (STF version) also runs  fine  in single mode. X-Debug seems
    slightly happier, but is still unstable under many weird and wonderful
    situations (i.e. who knows when it will crash next!).

    I have found that the  config  program  for Prodata behaves exactly as
    the one in Protext  i.e.  moving  the  mouse  within this program will
    crash the system:- don't do it!

    Apparently the latest version  of  Autoswitch  Overscan does work with
    MagiC, it is probably version 3.0  zi  (I  have 3.0 zg), and if anyone
    needs to get the upgrade, Compo  are  the new distributors, not System
    Solutions. As I haven't got it yet, I can't comment on this one.

    I have also included a  print  out  from the GEM_TEST program supplied
    with NVDI to give an idea  of  the speed increases. Remember that this
    is compared to a TOS1.0 STFM, users  of later TOS's will not get quite
    so good results,  and  that  since  GEM_TEST  was  written  by 2B, its
    probably optimised to give particularly  impressive results with MagiC
    & NVDI !!! Even so, not bad  eh?  I  haven't got a program to test the
    speed of  non-GEM  system  routines,  but  believe  me,  they  are all
    considerably faster. You can also throw away Pinhead, Poolfix, Foldxxx
    and all those other utilities that were an essential part of TOS based
    setups.

    I am sure that there are problems with this system, but the only one I
    have noticed is that the menu  bars occasionally don't switch when the
    window of another application  is  selected;  this is easily corrected
    however  by  selecting  the  application  required  from  the  program
    manager.

    *
    * NVDI GEM-Test V2.00  (c) 1991-1993 by Sven & Wilfried Behne
    *
    * Resolution      :  640 X, 400 Y
    * Planes          :  1
    * color pens      :  2
    * Palette         :  2 grades
    * Operating system:  Mag!X 2.01
    * Reference       :  TOS 1.00/ST-High
    * NVDI version    :  V2.51 installed
    * GDOS version    :  NVDI
    * Blitter         :  doesn't exist
    * CPU             :  M68000
    * FPU             :  doesn't exist
    * Machine         :  ATARI ST
    *
     Text output        : 952   %
     Lines              : 325   %
     Rectangles         : 498   %
     Polygons           : 220   %
     Circles/Ellipses   : 371   %
     Raster operations  : 315   %
     Attribute functions: 489   %
     Inquire functions  : 365   %
     ESCAPES            : 297   %
     BIOS output        : 225   %
     GEMDOS output      : 647   %
     AES object draw    : 1121  %

    v_gtext (8 chars, height 4, effect 0): 309781 P/s
    v_gtext (40 chars, height 4, effect 0): 366441 P/s
    v_gtext (8 chars, height 6, effect 0): 642509 P/s
    v_gtext (40 chars, height 6, effect 0): 1103299 P/s
    v_gtext (8 chars, height 13, effect 0): 794375 P/s
    v_gtext (40 chars, height 13, effect 0): 1255478 P/s
    v_gtext (8 chars, height 13, effect 1): 789590 P/s
    v_gtext (40 chars, height 13, effect 1): 1248304 P/s
    v_gtext (20 chars, height 13, effect 29): 131072 P/s
    v_justified (8 chars, height 13, effect 8): 775573 P/s
    v_justified (40 chars, height 13, effect 8): 1243567 P/s
    v_gtext (20 chars, height 26, effect 0): 1217010 P/s
    v_pline (horizontal): 3192019 P/s
    v_pline (vertical): 321027 P/s
    v_pline (arbitrary): 131850 P/s
    vr_recfl (48 * 20  points,  fillcolor  0,  fillstyle  0, fillindex 0):
              3130000 P/s
    vr_recfl (48 * 20  points,  fillcolor  1,  fillstyle  2, fillindex 3):
              1674000 P/s
    vr_recfl (100 * 100 points,  fillcolor  0,  fillstyle 0, fillindex 0):
              7792000 P/s
    vr_recfl (100 * 100 points,  fillcolor  1,  fillstyle 2, fillindex 3):
              3708000 P/s
    vr_recfl (638 * 400 points,  fillcolor  0,  fillstyle 0, fillindex 0):
              21096000 P/s
    vr_recfl (638 * 400 points,  fillcolor  1,  fillstyle 2, fillindex 3):
              12594000 P/s
    vrt_cpyfm (100 * 100 points, horizontal moved): 1624000 P/s
    vrt_cpyfm (640 * 200 points, horizontal moved): 2510000 P/s
    vrt_cpyfm (640 * 200 points, horizontal moved): 2512000 P/s
    vrt_cpyfm (320 * 200 points, vertical moved): 7327000 P/s
    vrt_cpyfm (640 * 200 points, vertical moved): 8894000 P/s
    vrt_cpyfm (640 * 200 points, vertical moved): 8914000 P/s
    vro_cpyfm (100 * 100 points, horizontal moved): 1624000 P/s
    vro_cpyfm (640 * 200 points, horizontal moved): 2511000 P/s
    vro_cpyfm (640 * 200 points, horizontal moved): 2512000 P/s
    vro_cpyfm (320 * 200 points, vertical moved): 7340000 P/s
    vro_cpyfm (640 * 200 points, vertical moved): 8904000 P/s
    vro_cpyfm (640 * 200 points, vertical moved): 8923000 P/s
    1000 calls of vst_height : 68 ms
    1000 calls of vst_point : 69 ms
    1000 calls of vst_color : 61 ms
    1000 calls of vst_effects : 59 ms
    1000 calls of vst_alignment : 67 ms
    1000 calls of vsl_color : 62 ms
    1000 calls of vsl_type : 60 ms
    1000 calls of vsl_udsty : 55 ms
    1000 calls of vsf_interior : 73 ms
    1000 calls of vsf_style : 78 ms
    1000 calls of vsf_color : 61 ms
    1000 calls of vswr_mode : 61 ms
    1000 calls of vql_attributes : 68 ms
    1000 calls of vqf_attributes : 64 ms
    1000 calls of vqt_attributes : 85 ms
    1000 calls of vqt_extent : 226 ms
    1000 calls of von vqt_width : 85 ms
    1000 calls of vqt_name : 146 ms
    1000 calls of vqt_fontinfo : 104 ms
    1000 calls of vqin_mode : 63 ms
    1000 calls of vq_color : 91 ms
    v_curtext (without scrolling) : 2308000 P/s
    v_curtext (scrolling) : 462000 P/s
    Bconout (without scrolling) : 1106000 P/s
    Bconout (scrolling) : 379000 P/s
    Cconws (without scrolling) : 2496000 P/s
    Cconws (scrolling) : 469000 P/s

    --------------------------- End of file ------------------------------
