
     ICTARI USER GROUP             ISSUE 25                    August 1995

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

                     *   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. 01425-474415
     =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

                              INDEX FOR ISSUE 25
                              ==================

     ASSEMBLY        Changing the mouse shape with 'A Line' calls.

     C               Tim Oren GEM Tutorial. Part 14. User interfaces.
                     Various C functions for MegaMax and Prospero.
                     Speech synthesizer for C and GFA.

     GFA             Weller Tools utilities.

     STOS            Print examples using M Cubitts STOS extension.

     MISC            Mrten Lindstrm, GEM Guide. Part 1.
                     Motorola DSP documents list.
                     Using the DMA port. 
                     Current membership list.
                     Index for issues 1-24.

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

     ASSEMBLY

     C               Tim Oren GEM Tutorial. Part 15. Coping with GEMDOS.

     GFA


     STOS            STOS loader program, etc for Missing Link Extn.

     MISC            How GDOS works.
                     Mrten Lindstrm, GEM Guide. Part 2.
                     AMCGDOS program.

     ----------------------------------------------------------------------
                                   EDITORIAL
                                   =========
     MEMBERSHIP
     ----------
     We have two more new members this month, welcome to them.

     GEM GUIDE
     ---------
     This month we are starting a  series  of  articles about GEM by Mrten
     Lindstrm which explains GEM calls with  special reference to a multi-
     tasking environment. Anyone writing programs which will be used on one
     of the new Operating Systems should  find  the series very useful. The
     articles are not  written  for  any  particular  language although the
     examples are shown in  Assembler  and  GFA  Basic.  If  anyone has any
     queries about the series  I'm  sure  Mrten  would  be happy to answer
     them.

     POSTAL PROBLEMS
     ---------------
     A couple of members have  had  problems  with  damage to packages that
     have been sent to us which  contain disks. We would strongly recommend
     that members write their name  and  address  on the disks when sending
     them to us. This way they stand a  good chance of getting them back if
     they become detached from the envelope.

     SPEECH SYNTHESIZER
     ------------------
     The speech synthesizer program in the C  folder also has a version for
     GFA Basic, whether this is the same speech program as the Naval Battle
     program in last months  issue,  I  don't  know.  Again,  if anyone can
     provide some Assembler code to  use  the  SPEECH  program, we would be
     interested to see it.

     ARTICLES
     --------
     As usual we are still very short  of articles to publish from members.
     If you can provide some source  code and/or programming article please
     send it in.
     ----------------------------------------------------------------------
                                 CORRESPONDENCE
                                 --------------
     To: *.*
     From: John Logan
     re Floating point number package

     I presume that most people  are  familiar  with decimal floating point
     numbers such as 0.123E2 (where E means "10 to the power"). This number
     translates to 0.123 x 10 to the  power  2  or 0.123 x 100 or 12.3. The
     first part (the 0.123) is called  the  mantissa and can be positive or
     negative. A positive mantissa means the  entire number is positive and
     a negative mantissa means the  entire  number  is negative. The second
     part (the 2) is  called  the  exponent  and  determines  the number of
     places the decimal place has to be  shifted  to get the final value of
     the number. The exponent can  also  be  positive  or negative but this
     affects the direction of shift and not the positivity or negativity of
     the number as a whole. Examples:-

       +0.123E+2 = +12.3
       -0.123E+2 = -12.3
       +0.123E-2 = +0.00123
       -0.123E-2 = -0.00123.

     Binary floating point numbers  are  similar  but  only contain 0's and
     1's. The binary number 0.0110E10 translates to 0.0110 x 2 to the power
     2 or 0.0110 x 4 or  1.100  or  1.5  in  decimal. There are a number of
     different formats used to  represent  the mantissa, exponent, mantissa
     sign and exponent sign. There are also differences in size and layout.

     I think the floating point number format discussed in the listing is:

     EXPONENT. The text states that  the  exponent  is  in the "excess 128"
     format. An excess 128 bit number  should  be  an eight bit binary "2's
     complement number with the sign bit inverted" and is used as follows:

     11111111 = +127 ie the mantissa is multiplied by 2 to the power +127
     10000000 =    0 ie the mantissa is multiplied by 2 to the power    0
     00000001 = -127 ie the mantissa is multiplied by 2 to the power -127

     00000000 might be expected to  represent  -128 but instead is reserved

     to indicate a zero mantissa. I  think  this is not being used properly
     in the programme. For instance the code:

     result  cmp.b   #$80,d2   if result exponent is 0, then use underflow
             beq     ufexit    to set Z and zeroise

     is incorrect if the exponent is truly  excess 128 as it is confusing a
     zero exponent (exponent = 10000000)  with  a zero mantissa (exponent =
     00000000). It is correct if the exponent is 2's complement.

     MANTISSA. The mantissa  is  probably  2's  complement  in  that  it is
     negated using the "neg"  instruction.  This  is  not the best mantissa
     format as the sign takes one bit so  leaving only 23 bits for the rest
     of the mantissa. It is better  to  use the "sign and magnitude" format
     with hiding of the 24th bit.

     What does this mean? We start  with  the simple rule that the mantissa
     is always justified (except when it is  being operated on). That is to
     say, at the end of an  operation,  the  mantissa is always shifted one
     way or the other (depending on the operation) until bit 24 is set. (Of
     course the exponent needs to be incremented or decremented at the same
     time). The binary point is  assumed  to  be  to  the  left of the most
     significant bit. If bit 24  is  always  a  "1" (except when the entire
     mantissa is zero), then it does not need  to be seen and can be hidden
     by the sign bit which is written over  the  top of it. Since bit 24 of
     the mantissa is hidden by the  sign  bit,  it  is not possible to tell
     from the mantissa alone  whether the mantissa 000000000000000000000000
     represents +zero or +1/2 (raised to  the  exponent of course). This is
     why an exponent of 00000000 is used to indicate a mantissa of zero. In
     other words the floating point number 00000000000000000000000000000000
     is equal to zero.

     Some  examples  of  hiding  the   most  significant  bit  follow.  For
     simplicity an eight  bit  mantissa  and  four  bit  exponent (excess 8
     format) are used. The binary point  is  assumed  to  be to the left of
     mantissa bit 7. We  will  not  be  concerned  with  the sign until the
     mantissa is justified and the signs are remembered somewhere else.

     positive number
     (.)00101000  1100  mantissa unjustified, exponent = 4
     (.)01010000  1011  mantissa shifted left and exponent decremented
     (.)10100000  1010  mantissa shifted left and exponent decremented
     (.)00100000  1010  bit 7 overwritten by the sign bit (0)

     negative number
     (.)00101000  1100  mantissa unjustified, exponent = 4
     (.)01010000  1011  mantissa shifted left and exponent decremented
     (.)10100000  1010  mantissa shifted left and exponent decremented
     (.)10100000  1010  bit 7 overwritten by the sign bit (1)

     The argument given  in  the  original  programme  for  using the least
     significant byte for  the  exponent  seems  sensible  as  it is easily
     separated from the rest of the number. However, I think this layout is
     not compatible with the IEEE standard as used in the Motorola hardware
     floating point units. The IEEE  standard for single precision floating
     point numbers probably uses bit 31  for  the mantissa sign, bits 23 to
     30 for the exponent and bits  0  to  22  for the mantissa. It does not
     matter particularly from the mathematics  point  of  view but would be
     important if you were writing a programme  which would use a FPU if it
     was present or software  if  it  was  not.  You  would want the number
     format to be the same.


            Outline floating point add and subtract routines


     They are taken  from  "Hashizume  B.  Floating  Point Arithmetic" (see
     below). These routines assume:

     - the floating point numbers have already been unpacked
     - the exponents are 8 bit signed "excess 128" binary numbers
     - the mantissae are 24 bit unsigned binary numbers
     - each mantissae sign is stored in an extra bit which, during
       these operations, has been copied elsewhere but which is written
       over the mantissa most significant bit on packing the number into 32
       bits
     - both mantissae most significant bits have been over-written by "1"
     - both exponents have been moved to separate registers
     - both mantissae occupy the upper 24 bits of a 32 bit register with
       the lower 8 bits initially clear
     - the second mantissa is being added to or subtracted from the first
       mantissa

     Note:

     - floating subtract leads directly into floating add
     - exponent underflow occurs with an exponent of 00000000 )but remember
       an exponent of zero is represented by 10000000)
     - the sign of the result mantissa depends on the signs of the original
       mantissae


     fsub    change sign of second mantissa;
     fadd    exponents equal?
             yes
               branch to signs;
             no
               determine which number is smaller;
               shift the mantissa of the smaller number right by one;
               mantissa equal to 0?
               yes
                 return with other number as answer;
               no
                 increment the exponent of the smaller number by one;
                 branch to fadd;

     signs   signs equal?
             yes
               signs positive?
               yes
                 set result mantissa sign positive;
               no
                 set result mantissa sign negative;
               add mantissae;
               was there a carry out?
               yes
                 rotate mantissa right by one;
                 increment exponent by one;
                 was there an exponent overflow?
                 yes
                   branch to over;
                 no
                   branch to round;
               no
                 branch to round;
             no
               first mantissa larger than second?
               yes
                 set result mantissa sign same as first mantissa sign;
               no
                 set result mantissa sign same as second mantissa sign;
               subtract mantissae;
               was there a carry out?
               yes
                 negate mantissa;
                 mantissa = 0?
                 yes
                   branch to zero;
                 no
                   branch to norm;
               no
                 mantissa = 0?
                 yes
                   branch to zero;
                 no
                   branch to norm;

     norm    most significant bit = 0?
             yes
               shift mantissa left by one;
               decrement exponent by one;
               exponent underflow?
               yes
                 branch to zero;
               no
                 branch to norm;
             no
               branch to round;

     round   mantissa bit 7 = 1?
             yes
               add $00000080 to mantissa;
               was there a carry out?
               yes
                 rotate mantissa right by one;
                 increment exponent by one;
                 exponent overflow?
                 yes
                   branch over;
                 no
                   return with result;
               no
                 return with result;
             no
               return with result;

     over    set overflow flag;
             return;

     zero    clear 32 bit register;
             set zero flag;
             return;

     The result mantissa, mantissa sign  bit  and  exponent will have to be
     repacked into a 32 bit number.

     Useful books
     Hashizume B. "Floating Point Arithmetic". In: Programming Techniques
     Volume 3. Numbers in Theory and Practice. Editor Blaise W Liffick.
     Byte Books 1979.

     Huggins E. "Microprocessors and Microcomputers - Their Use and
     Programming" The Macmillan Press Ltd 1979.
     ----------------------------------------------------------------------
     To: Peter Hibbs
     From: Mark Baker

     "The author does  not   give   enough   detailed  information  on  how
     the floating point numbers are represented  in  binary format and also
     does not provide any routines to   convert  from  normal  ASCII format
     to or  from  the  floating  point   format   which   would   also   be
     necessary in  a  practical  program.   If   anyone   can   get   these
     routines   working  and  perhaps   write  some   ASCII-FP   conversion
     routines,  we  would be very grateful."

     From the comments at the top:

     ;       bits 31-8 = 24 bit mantissa
     ;       bits 7-0  = 8 bit excess 128 exponent

     All that's missing is the  sign,  looking  through  the source I think
     that's just done by two's complementing (ie neg.l) the mantissa.

     Basically all that's done here is  to move.b the exponent into another
     register, sign extend it, then use the mantissa almost as is, treating
     it as a 32bit mantissa - the  extra zeroes are ignored as they're just
     like putting 1.0000 instead of 1.0

     I'm not going to volunteer to write the conversion routines as I'm not
     too good at assembler, and copyright  prevents me stealing the ones we
     use at work.

     To: Steve Gale

     "Does anyone  know  of  any  'legal'  way  to  stop  'overshoot'  when
     scrolling through a document,  i.e.   stopping  the scrolling sequence
     immediately when the up or  down  arrow   key  is released. Presumably
     this is caused by the  keyboard  buffer storing keypresses  even after
     the key has been released."

     It doesn't flush the  buffer  when  the  key  is  released for obvious
     reasons - the  program  may  not  have  responded  to  the ones you've
     already pressed, so people who press a  key twice to go down two lines
     for example may find  they  only  go  down  once.  If the program does
     respond quickly enough then obviously there isn't a problem.

     What might be nice would be for  it  to behave as normal on individual
     keystrokes but to change it's behaviour  as soon as the typematic came
     in, replacing it instead with a  single  key  down and key up message.
     Windows on the PC works like this, but there's no way it could be done
     on the ST (by the OS  it  could,  but  not in an application using the
     existing OS) I'm afraid.

     To: Terry King

     "Does anyone know much about  the   Falcon  hardware  ?  In particular
     I would like to know how to  use   the  sound,  I believe that the STE
     DMA sound commands are  not supported  on   the Falcon which means STE
     games run in  silence, is this true ?"

     Although the Falcon's sound hardware is  more capable it is compatible
     with that of the  STE.  Most  STE  programs  work well. What Backwards
     fixes is the sound chip used by ST programs, not the STE's DMA sound.

     If you  want  information  on  using  the  extra  capabilities  of the
     Falcon's sound system, look in The  Atari Compendium or Hisoft's book.
     I can give you a little  example  program  if you want (a d2d recorder
     written in C).

     "I  tried  out  a game   I   am   writing   on  a Falcon and  although
     the game played,  the   display    seemed   to  give  quadruple vision
     with messed  up colours. "

     That sounds like you're running in the wrong screen mode, if you run a
     program intended for ST low res in  a 640x400 or 640x480 mode (and the
     program uses direct screen writes) you  get  this effect. Do you still
     get it if you switch to ST low first ?

     "using   hardware  scrolling  and   writing    to  the  video  address
     registers. Should I put the  Falcon  in  some  specific mode for it to
     work ?"

     The Falcon has some extra video  registers  but  I think the ones that
     also exist in the STE are at the same address.

     "Also,  what's the  best  way   to   check   whether  the  machine the
     program is running  on  is a Falcon ?   Would it be something like the
     cookie jar variable _MCH containing the value 30 ? "

     If it's literally the Falcon  you  want  to  test  for, then yes. More
     likely you will want to  test  for  a  particular feature, such as the
     better graphics, better sound,  DSP,  TOS  4,  AES  3.4 etc. The first
     three of these are in the cookie jar (_VDO for video, the other two in
     different bits of _SND), for the  TOS  version use Sversion(), for the
     AES version (which I guess you won't want for a game) use AESglobal[0]

     To: Dick Teuber

     "Can anyone help me on how to  use   machine code in Lattice C. I want
     to include a small block of machine   code  within  the source code of
     a C program and not link in  with   an  Object  file.  I  also need to
     pass parameters from C   to   the   CPU   registers   and  stack.  The
     Lattice C manuals seem to be very unhelpful on how to do any of this."

     The reason they're unhelpful is  because  you  can't do it, it doesn't
     have an  inline  assembler.  If  you  want  to  use  assembly language
     routines you have to link them in (it isn't that difficult).

     How parameters are passed is  documented  in  the manuals, they are on
     the stack by default or if __stdargs is  used, or put in the first few
     registers (check the manual  for  exactly  which)  if you compile with
     register params or use  __regargs.  You  can  also declare the routine
     __asm to allow you to specify any registers you like for parameters.

     There is an example in the  manuals  somewhere  of how to support both
     register or stack arguments, remembering that one prefixes labels with
     @, one with _. It's something like :-

     _myfunc:  move.l  +(a7),d0      ;__stdargs entry point
               move.l  +(a7),a0
     @myfunc:  ;some code            ;__regargs entry point, first int
                                     ;argument in d0, first pointer in a0
               rts

     depending on how many parameters and what types.

     To: *.*
     From: Mark Baker

     Printer drivers
     ---------------
     I really can't see any point in doing  this to be honest. GDOS has its
     faults, yes, but  it's  well  supported,  and  these  days  is easy to
     install. More to the point it supports  vector fonts with a quality as
     good as anything you'll find on  any  other  platform (I believe it is
     supposed to be rather better than Truetype).

     Also, your system will /never/ be as easy to program as GDOS, whatever
     you do to it. In my programs I  use exactly the same code for printing
     as for displaying on the screen, which your system will never allow.

     Mrten suggested that we  wrote  our  own  GDOS,  since there wasn't a
     freeware one available. In fact there  is  the German AMCGDOS which is
     freeware. I did have a couple of  problems  with this but I know other
     people have used it successfully.

     In my opinion the main problem  with  GDOS  is that it is difficult to
     write drivers. Atari used to  give registered developers documentation
     on doing so,  and  source  to  the  fx80  driver  so  only the minimum
     necessary had  to  be  changed,  making  writing  a  new  one  not too
     difficult. Much better as a  project  for  ICTARI  would be a freeware
     driver skeleton in my opinion.

     If anyone does this, some  nice  true  colour printer drivers (current
     colour ones only allow primary  colours)  would  be  nice, and I would
     like to try writing a fax driver.

     I like Mrten's suggestion that we write a driver that allows the user
     to configure it  through  a  text  file,  so  allowing  use  with many
     printers - obviously it is limited  to  an extent. This is, in effect,
     what NVDI 3  does  -  it  comes  with  drivers  called PAGEPRN.SYS and
     PINPRN.SYS which the user configures  by  typing codes into a dialogue
     box.

     Whilst GDOS has never pretended to offer more than the bare minimum of
     support for text mode printing,  there  is  little  need for more than
     that, as most applications where any more than that is necessary would
     be better served by using  graphics  fonts  anyway.  However I can see
     some point in UPD if it is limited  to text, using a system similar to
     Idealist's but as a standard supported by many applications.

     Whilst I accept your comment  about  GDOS  only being suitable for GEM
     programs, most non-GEM programs are games,  and indeed I can't imagine
     anyone daring to publish  a  serious  application  that didn't use GEM
     these days.

     If, however, you go  ahead  with  the  project  as originally planned,
     can't we have longer,  lower  case  names  for  the functions, such as
     upd_output_bitmap() instead of UPD_SGM()? It makes code much easier to
     understand...
     ----------------------------------------------------------------------
     To: ICTARI
     From: Jim Taylor

     I think your idea of a universal  printer driver is excellent. I would
     love one for use with my  draughting  program  MULTICAD. So far I have
     managed to figure out how to print my  drawings  to a 9 & 24 pin Epson
     and an HP  Deskjet  520  inkjet  printers.  As  for  helping  with the
     specification of the UPD I think  it  is  more likely that I will need
     help to implement such a program. I'm  afraid I only have a vague idea
     of how printer drivers work but  would  be  most interested in any in-
     depth information/tutorials on them, eg.  how  are they structured and
     how are they implemented by the program etc.
     ----------------------------------------------------------------------
     To: *.*
     From: Mrten Lindstrm

     GIF is dead! Long live PNG!
     ---------------------------
     In Dr. Dobb's Journal, July 95  (an American non-Atari Magazine that I
     by unfortunate coincidence happened to look  into) there is an article
     about GIF and a new picture file format PNG to replace it.

     As you may have heard, the copyright  holders of GIF, a greedy company
     Unisys, recently decided  to  squeeze  money  out  of  this format, by
     demanding royalties  from  all  developers  of  'GIF  based software'.
     Actually it seems to be the GIF implementation of LZW compression that
     is copyrighted, which makes  me  suspect  (though  I  haven't seen any
     mention about that) that most TIFF  images  may be subject to the same
     problem, considering that TIFF  LZW  is  almost  identical to GIF LZW.
     Even if you may be clear  of  charges for writing a freeware GIF-using
     program, any CD  (or  magazine  cover  disk?)  producer  who  wants to
     include your program on his disk WILL have to pay.

     I assume that merely making  a  program  capable  of READING GIF isn't
     chargeable (?), as long as you  don't  supply  any GIFs with it, but I
     certainly never intend to  create  a  program  -  or  PICPAC routine -
     capable of WRITING GIF after this.  I  personally find all demands for
     money from developers for merely using  a data file format a revolting
     idea,  and  copyrights  in  this   area   to  be  purely  destructive,
     discouraging standardization.

     With GIF where people, tricked into believing it was free to use, have
     helped in making the  file  format  popular  and  then  are thanked by
     suddenly being charged  with  royalties  for  this,  many  people have
     reacted very strongly. And among these is the author of the Dr. Dobb's
     article - Lee  Daniel  Crocker  -  who  was  apparently  involved with
     defining both GIF89a and JFIF and now has taken part in defining a new
     picture file format PNG (Portable  Network Graphic format) intended to
     replace GIF.

     Unfortunately there is no  full  format  description  in the magazine,
     merely  some  addresses   where   this   could   be  found  (Internet:
     http://sunsite.unc.edu.boutell/ and Compuserve:  GO  GRAPHICS, if this
     makes any sense to net-trekers among you.)

     Some general qualities are however presented:

      1)     Most importantly, PNG is guaranteed  to  always remain free to
             use. (Which seems to prove that  royalty money isn't needed to
             encourage the development of useful file formats.)

      2)     A PNG file is started by the 8 bytes: 137,80,78,71,13,10,26,10
             and after this is built up  from sequential chunks (similar to
             IFF images). (The pointers within a  TIFF file, forcing a TIFF
             reader to jump back and  forth,  was  the reason that TIFF was
             'discarded'  as  successor  to  GIF  in  conveying  images  by
             electronic mail).

      3)     The  compression  used   is   the   Deflation   of  ZIP  (plus
             'prediction' methods for true  colour images). Non-lossy! (The
             need  for  lossless  compression  of   images  that  might  be
             repeatedly edited or cut, plus  the  fact that JPEG isn't good
             with palette  colour  images,  ruled  out  JFIF,  =  JPEG File
             Interchange Format, as successor to GIF.)

      4)     PNG, unlike GIF, is capable of dealing with true colour images
             as well as palette colour images.

      5)     Each PNG file  always  stores  only  one  image  (with  no GIF
             'logical screen' concept) though there might be a transparency
             mask (possibly graduated) for this image.

      6)     Words and longwords are always stored most significant byte(s)
             first (as by our  Motorola  processors),  which is contrary to
             how they are stored in GIF and by Intel processors.

     The general chunk format is:
             1 long:  length of chunk (data only, excluding the 12
                      extrabytes)
             4 bytes: ID of chunk
             ? bytes: data
             1 long : checksum

     There is, unfortunately, no requirement  mentioned  in the article for
     each chunk to start at an even address (as in the IFF standard).

     The ID is apparently to consist  of  four  ASCII LETTERS, the cases of
     which are used to encode general  properties of the chunk. The default
     is for all letters to be uppercase, but if letter

      #1 is lowercase => chunk is ancillary (non-critical)
      #2 is lowercase => chunk is application-specific (not in PNG spec).
      #4 is lowercase => chunk is safe to copy into edited file even if not
      recognized by editor program (i.e. not dependent on other data).
     (Lowercase of letter #3 is presently undefined)

     The first chunk is  always  IHDR,  the  last  one  always  IEND and in
     between there must always be one  or  more IDAT chunks (with the image
     data) plus possibly further chunks. A  palette  image must have a PLTE
     chunk before IDAT. A 'gAMA' chunk  might appear (before PLTE and IDAT)
     specifying a 'gamma  curve'  which  could  be  used  to  adjust colour
     intensity  values  to  the   specific   hardware  used.  (Compare  the
     ColorResponseCurves tag in the TIFF specification;  the PNG gamma is a
     less accurate but simpler way to achieve the same thing).

     Unfortunately the formats of specific chunks  are not described in the
     article, with the  exception  of  an  ancillary  'tEXt'  chunk, simply
     intended for short comments such  as  author's  name,  a title for the
     image etc.

             Considering some recent discussions here  in  Ictari it may be
             of interest that the character set  used in tEXt should be ISO
             8859-1, which I think is the  set  used by Amigas etc. Windows
             uses the same character set although with extensions (defining
             characters for numbers undefined in the ISO set).
             If more than one line is  used  in  a single tEXt chunk (which
             isn't recommended) a single LF  (ascii  10) should be used for
             newline (like in Unix etc).  (Atari  TOS and MS-DOS use CR-LF,
             and Macintosh uses a single CR.)

     There are also some C listings in the magazine from which some further
     info could perhaps be deduced (the  PLTE  data seems, for instance, to
     be a palette in the  familiar  old  format  of  GIF  and IFF ILBM) but
     without the full PNG specification won't do us much good.

     All in all, PNG seems to be  a  very nice and well thought out picture
     format, which I would  be  very  interested  to  include in the PICPAC
     library if I can get hold of the full PNG specification.

     But for most Atari purposes I still  think that IMG or IFF ILBM should
     be the  first  choice,  using  the  ST  (and  Amiga)  native bitplane-
     separated format and requiring much  less  time (and space) to unpack.
     (Although ZIP deflation is more effective than LZW, I suspect it to be
     slower too - judging from the time it takes to inflate a ZIP file with
     the excellent ST ZIP program.)

     */ We are sure that ICTARI members  would be interested in any further
     developments on this subject, if  anyone  has more details, please let
     us know. ICTARI  */

     To: Peter Hibbs

     Printer Drivers
     ---------------
     I feel I have to clarify some of my points :-

     UPD.PRG, as I envisaged it, would  be an AUTO-folder program just like
     GDOS.PRG, hence the PRG ending. As little as GDOS it would be intended
     to run separately from  the  Desktop.  If  you  don't  go for the GDOS
     option this wouldn't be as meaningful (the UPD file could then - as is
     your plan - be loaded by  each  program  when needed, instead of being
     loaded by the system at bootup),  but  my  idea was to expand UPD into
     'GDOS UPD', and for this to  work,  the  UPD routines would have to be
     already loaded and initialised when  VDI  output  is first sent to the
     printer.

     Also the end user  would,  with  this  system,  certainly  NOT have to
     program his own GDOS drivers.  The  whole  point of the universal GDOS
     driver would be that a single  GDOS  driver program (UPD.SYS) could be
     used for any printer, since  instead  of  sending actual output to the
     printer it would call the  previously  installed UPD routines to print
     bitmaps and characters.

     Multiple printers on the same system  IS a problem, but not unsolvable
     (The user must be  given  the  option  to  install  multiple copies of
     UPD.SYS as well as multiple printer text file specifications, and each
     UPD.SYS copy must  be  able  to  somehow  connect  to  its own printer
     specification).

     A more serious problem may be  to  make the UPD system compatible with
     SpeedoGDOS. Maybe I DID take too lightly  on this. The thing is that I
     don't have SpeedoGDOS (or  even  FONTGDOS)  and  have  no  idea of how
     SpeedoGDOS program interfaces with its  drivers.  But  it seemed to me
     that if I had  been  given  the  task  of  adding  the capabilities of
     outline fonts and Bezier curves  to  the  old  GDOS, then I would have
     built these capabilities into  the  GDOS  program  itself  and let the
     drivers remain essentially unchanged (if  nothing  else to save memory
     space - there is only one  GDOS program but potentially many drivers).
     I.e. the GDOS program  would  convert  any  bezier  curves and outline
     fonts into bitmaps before somehow sending these to the driver.

     My loose (and  maybe  too  bold)  idea  was  thus  for  us  to write a
     universal GDOS driver that perhaps  could  be  used both with old GDOS
     and with SpeedoGDOS (provided that  someone  has info on the interface
     between SpeedoGDOS and  its  drivers),  and  for  us  to possibly also
     supply a freeware replacement for the old GDOS.

     If on the  other  hand  the  GDOS  UPD  project  would  mean rewriting
     SpeedoGDOS, then I can only agree this to be beyond all reason.

     I finally want to say, again, that  whether or not you decide to adapt
     UPD to GDOS I think it a great and highly useful initiative.

     */ In view of  the  correspondence  over  the  past  two months on the
     viability of a free  Universal  Printer  Driver  system  as opposed to
     GDOS, it looks as though GDOS seems to be winning the argument. I must
     confess that in the past I have been against using GDOS in my programs
     for various reasons. I once had a very nasty experience when trying to
     install GDOS on my hard disk when  I nearly lost everything on it (OK,
     OK, it was almost certainly my  fault  but  you tend to remember these
     things). Also the original GDOS was  very  limited with bit map fonts,
     some bugs, etc and somewhat messy to set up. However, with the arrival
     of SpeedoGDOS, this has all changed and I  think it may be to my (our)
     advantage to look  at  it  for  future  programs.  Having  re-read the
     SpeedoGDOS review in ST Applications it does, as Mark Baker says, have
     facilities which my UPD system  could  never  emulate (not that I ever
     intended UPD to supersede GDOS of course) and especially the access to
     high quality vector fonts would be very useful.

     Several of my original arguments against GDOS still stand though, that
     is that it is not free and  that  it  cannot be used with STOS but, on
     the other hand, I suppose  if  one  is  writing a 'serious' PD program
     which requires high quality printing  with  vector fonts, colour, etc,
     it is  not  unreasonable  to  assume  that  the  end  user  will  have
     SpeedoGDOS already installed on  his  system.  At  least the user will
     only need it once so that it  can  be  used with a number of different
     programs. The same argument would also apply to STOS, that is STOS was
     mainly designed as  a  games  writing  language  and  not  for writing
     'serious' applications programs.

     The problem I have (and I'm sure a  lot of other members also) is that
     having never used GDOS in any of my  programs I am not sure how to use
     SpeedoGDOS in a practical  application.  When  one buys SpeedoGDOS, do
     you get any programming information, for  example Mark Baker says that
     he can output vector drawings  to  screen  and  use  the same code for
     printer output but how do you ensure  that  the size of the drawing on
     the print-out  is  the  required  size  with  the  screen  and printer
     resolutions being different (and  even  different printers resolutions
     being different). How do  you  print  bit  map images with SpeedoGDOS.
     Does the NDC system  have  to  be  used.  What  extra VDI commands are
     available under SpeedoGDOS. How do you print in colour and what colour
     facilities are available, i.e. primary colours only or dither patterns
     to give multiple colours (I have  just purchased a Canon BJC600 colour
     printer and I would like to write some code to print in colour). Since
     Mark is a strong advocate of GDOS/SpeedoGDOS, perhaps he would like to
     write  a  COMPREHENSIVE  article  on  how  to  use  SpeedoGDOS  in  an
     application program (preferably in  'GEM  pseudo-code' rather than any
     specific language).

     Having said all that I still think that the UPD system has some merit,
     perhaps (as Mark suggests) as  a  mainly  text output system with some
     limited graphics capabilities. I will  probably continue to develop it
     on those lines and publish it later so  that anyone can use it if they
     want to in an application  which  does  not need the sophistication of
     SpeedoGDOS. Any further comments would be welcome.

     Although I think  that  any  future  applications  programs should use
     SpeedoGDOS rather than GDOS where  applicable,  I  would still like to
     see more information on the old GDOS system since this could be of use
     in writing software for  new  applications.  For  example, how do GDOS
     printer drivers work, how does  GDOS  itself  work, what is the format
     for bit map GDOS fonts, etc. Mrten Lindstrm has provided some useful
     information on GDOS drivers which  we  will  publish in the next issue
     along with the AMCGDOS freeware program  that Mark Baker mentioned. If
     anyone has any other information on  GDOS or SpeedoGDOS please send it
     in.

     As I mentioned above, having now got  a colour printer I am interested
     in writing some software for colour  printing. The printer has control
     codes to output the colours  black,  magenta,  cyan, blue, yellow, red
     and green using the escape  code  ESC,  $72,  n  where n is the colour
     number 0-6. Presumably to make  the  output  image appear in any other
     colour, say orange, one  would  use  two  (or  more)  colours in a dot
     pattern which simulate the required  colour, i.e. dithering. I believe
     there are standard  dithering  systems  but  unfortunately the printer
     programming manual does not  give  any  information on this technique.
     Does anyone have any information on colour dithering techniques. Also,
     does anyone  have  information  on  how  the  Hewlett  Packard  colour
     printers process colour information since they seem to use a different
     system to Canon.  PDH /*
     ----------------------------------------------------------------------
     To: ICTARI
     From: Abdul Rahman, Singapore

     I would really like to write  games  and applications programs for the
     STE and  Falcon  since  I  have  bought  both  machines.  But  here in
     Singapore support for the ATARI  machine  is  dead. I bought both from
     Singapore suppliers and both have since  changed over to PC compatible
     machines and I am left stranded with no support, hardware and software
     is zero here. I believe in Singapore there are quite a number of users
     and that's the reason I  want  to  learn programming and start writing
     good software for the Atari machine. I  can write programs but only on
     a PC compatible machine.

     I'm wondering if there is a program  that can transfer the program the
     I wrote on the PC to the Atari maybe with a little modification in the
     original language that I wrote  it  with.  For  your info the language
     that I use is CLARION PROFESSIONAL DEVELOPER  on the PC and is written
     using the C language. I have  heard  the  C language is also common on
     the AMIGA machine which is why I am interested in it.

     I have PURE C and  LASER  C  but  the  manuals  have been lost. I have
     enclosed a disk with one  of  the  modules of the application software
     that I wrote using Clarion Professional on  the PC. I can load it into
     DevPac and also on PURE C and LASER  C and still see the whole routine
     as I wrote it on the PC but I  cannot compile and link the code on the
     1040 STE or Falcon 030.

     Please advise on the best possible  way  I  could  get around it. If I
     could write a program in my office  and  bring it home to transfer the
     code so that it can  run  on  the  Atari  machine that would be really
     wonderful. If no  such  program  or  ways  exist,  please  advise on a
     possible solution to the problem.   I'm  keen  to  write for the Atari
     machine and maybe show one or  two  here  what the Atari can do. Atari
     has been labelled  as  a  GAME  MACHINE  here,  people  have the wrong
     concept about it.

     */ We think it  is  very  unlikely  that  you  will find a programming
     language which will operate properly on a  PC and Atari (and Amiga ?).
     The nearest you might get is to  use  C  and keep to the ANSI standard
     commands  but  even  then  there  would  be  all  sorts  of  problems,
     especially if you wanted to use  GEM  (or  Windows  on the PC) and any
     hardware specific code. If  anyone  knows  of any programming language
     which will work on both platforms  or has any further comments, please
     let us know.  ICTARI /*
     ----------------------------------------------------------------------
     To: *.*
     From: Martyn Wells

     Hi there everyone. I have just got  an STE and was wondering if anyone
     knows if you can do hardware  scrolling  of  the screen from GFA BASIC
     3.5. Also does anybody have  any  info  on  the file format for EZ-ART
     professional picture files, i.e .EZA  files  and  does anyone have any
     info on how to use the  Videomaster  digitizer  from GFA BASIC. I know
     how to display the films, etc,  but  I  want  to  be able to grab from
     within a program that I'm  writing, i.e full screen grabs.
     ----------------------------------------------------------------------
     To: ICTARI
     From: Terry King

     Devpac 3 possible improvements:

     1. After compiling, the  messages  window  should  be  put to the back
     (after being displayed  for  around  one  second)  and  then  the last
     selected window should be brought to the front.

     2. After compiling I generally  always  save  the code before running,
     however if you forget  to  go  back  to  the  correct  window then the
     output to the messages window  ends  up  wiping  over your file ! This
     would be solved by having 1.

     3. You may have a  number  of  sub-routines  that you regularly go to,
     but putting their position in  the  bookmark doesn't tell you anything
     about the position  of  the  marker.  A  bookmark  should  contain the
     first line of the text for identification purposes.

     4. An advanced feature that I would  love  to  see in GENST would be a
     sub-routine fold feature as  seen  in  GFA  Basic  where any number of
     lines can be compressed to  a  single  line  just  by pressing HELP on
     the title. ie, something like ..

        SUB multiply_by_8
             move    d0,d1
             and.l   #$ffff,d1
             lsl.l   #3,d1
        ENDSUB

        after folding would become,

        > multiply_by_8

     For a huge program (like the one  I'm currently working on) this would
     be a great  feature  for  tracking  down  a  particular  piece of code
     without having to wade through thousands of lines.

     5. Another advanced feature to  save  precious  memory is for GENST to
     allocate just enough memory for  the  window  instead  of a fixed size
     which must be specified  in  the  preferences.  It  would be better if
     the size specified were treated  as  extra  memory  per window and not
     an absolute value.

     6. A bug which has crept into  version 3 is that GENST doesn't restore
     the resolution after cancelling MONST which  can result in an almighty
     mess that only a reset can fix.

     As HiSoft has stated that it will  continue to support the ST maybe we
     should get a conference going here that we can then send to them :-)

     */ We especially like  the  'sub-routine  fold'  idea  and it would be
     relatively easy to implement.  ICTARI  /*

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