

     ICTARI USER GROUP              ISSUE 21                   April 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 21
                              ==================

     ASSEMBLY        Various maths function routines.
                     RSC Macros and RSC routines.
                     Joystick routines.
                     RSC file inclusion in program plus demo program.

     C               Questions and Answers file.

     GFA             Football game code.

     STOS            Text display program code.
                     Fast sprite drawing routines.

     MISC            DXF format text file.
                     Resource file format information.
                     RSC to source file converter program.


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

     ASSEMBLY        Polyline drawing routines in machine code.
                     Bezier curve drawing routines.
                     Shape outliner routine.
                     Intro demo program code.
                     Mouse position test routine.
                     Upper/lower case conversion routines.

     C               Progress report function.
                     Tim Oren GEM tutorial. Part 11. GEM hooks & hacks.

     BASIC           Demo program on disabling menu items.

     GFA             Picture clipping code.
                     Bingo card number generator.
                     GFA Tool Kit book review.

     STOS            Bank display program code.
                     Chaos engine.

     MISC            Using the system clipboard.
                     GDOS information file.

     For future issues :-
     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.
     Sorting algorithms.
     Using the BitBlit routines.
     Code for using the File Selector.
     ----------------------------------------------------------------------
                                   EDITORIAL
                                   =========
     ARTICLES
     --------
     We still need some articles for the  June issue (and beyond) so if you
     can provide something,  please  do  or  we  will  have  to  rely on PD
     material for future issues. We would also like to see more programming
     questions asked (and answered, of course) so please send them in.

     GEM TUTORIALS
     -------------
     In issues 3 to 7 we published  the GEM tutorial series (parts 1-10) by
     Tim Oren (who wrote GEM). We have now got parts 11 to 17 which we will
     be starting to publish next month. In  part 17 there is a reference to
     a part 18 which we do  not  have.  If  anyone with Internet access can
     find this one or any later ones perhaps they could send them on to us.
     The filenames used are GMCL11.DOC to  GMCL17.DOC for the parts that we
     have already.
     ----------------------------------------------------------------------
                                CORRESPONDENCE
                                ==============
     To: Geoff Smith
     From: Mrten Lindstrm

     You got the  warning  "opcode  generated  for MC68020/MC68030/MC68040"
     regarding the assembler instruction:

             MOVE.B (A1,D1.W),D0

     Try changing this into

             MOVE.B 0(A1,D1.W),D0

     i.e. insert a '0' before the parenthesis.  To be honest I am surprised
     that Lattice C (which I don't  have  myself) complains about the first
     expression. It is true that this  assembler syntax is strictly correct
     only with 68020+ processors,  but  it  should assemble identically for
     them, I think, as the latter 68000  line.  And e.g. Devpac (both 2 and
     3) accepts the  former  line  without  complaining  even  when  set to
     generate pure 68000 code.

     For someone who doesn't know any  assembler: What the instruction does
     is to interpret the sum of register A1 (long) + lower word of D1 (+ 0)
     as an address in memory  from  which  a  byte  is read and copied into
     (lowest byte of) register D0.

     To: Steven Gale (and others)

     THE GEM CLIPBOARD AND OTHER WAYS TO TRANSFER DATA BETWEEN PROGRAMS
     ------------------------------------------------------------------

     The GEM clipboard became  official  Atari  standard  a long time after
     most of the  ST  documentation,  still  floating  around, was written.
     Which is probably why you haven't been able to find anything about it.

     The clipboard itself is really a folder on disk, the path of which can
     be found with the AES call SCRP_READ  or, if not already set, set with
     SCRP_WRITE. Applications supporting it  typically  do  this within the
     context of Macintosh style block  editing functions, 'Cut', 'Copy' and
     'Paste' (under an 'Edit' menu). The  presence of these functions is no
     guarantee of clipboard support however  (e.g.  Devpac  3 which uses an
     internal buffer instead).

     NOTE: A program that, like Devpac 3,  uses an internal buffer for Cut,
     Copy and Paste should ideally (though  Devpac doesn't) have some means
     - e.g. an extra,  checkable,  menu  item  'Use  Clipboard' - to toggle
     between GEM clipboard and the internal buffer.

     Standard keyboard short-cuts, according to both AC and German sources,
     are (sadly not adhered to by Devpac):

             Cut:   Ctrl-X
             Copy:  Ctrl-C
             Paste: Ctrl-V

     If the menu item 'Copy' is used then the marked block of text or image
     or whatever should simply be written to the clipboard. 'Cut' should in
     addition delete the block within the edited document in the program.

     'Paste' should cause the  contents  of  the  clipboard  to be read and
     inserted into the edited document  (at  the  position of the cursor or
     equivalent).

     When there isn't a  block  selected  in  the  program, then 'Copy' and
     'Cut' should ideally be disabled. You  might think that 'Paste' should
     be similarly disabled when the clipboard  is  empty, but alas there is
     no standard way, that I know  of,  to  tell when the clipboard becomes
     updated.

     (If for some reason you don't use a  menu in your program - e.g. in an
     accessory where this isn't easy to  implement  -  I think it should be
     quite alright to use the clipboard  anyway. E.g. accessed via dialogue
     buttons or just with the above keyboard short-cuts.)

     To write to the clipboard:

     1)      Call SCRP_READ to get the path to the clipboard.

             If the returned string is empty, no path has ever been defined
             since bootup. If so, create a directory \CLIPBRD - on drive C:
             if there is one, otherwise  on  drive  A:  (or you can ask the
             user). I suppose you  could  alternatively read _bootdev, i.e.
             the word at $446 (in  supervisor  mode)  to get the boot drive
             (0=A:, 2=C: etc.). Tell the  world  about the new clipboard by
             calling SCRP_WRITE; the path given with  this should be on the
             format 'C:\CLIPBRD\'.

     2)      Delete all files SCRAP.* within this folder.

     3)      Write one or more files named  SCRAP.*,  where * is a standard
             file name extension describing the file format (see below).

     IMPORTANT: If you  write  more  than  one  file,  each  of them should
     contain essentially the same information, though in different formats,
     since the idea is that an importing program should only have to choose
     one of them.

     To read from the clipboard:

     1)      Call SCRP_READ to  get  the  path  to  the  clipboard.  If the
             returned string is empty (null) there  is of course nothing to
             read.

     2)      Search  the  clipboard  path  for  files  named  SCRAP.*  with
             suitable extensions - corresponding to  file formats that your
             program supports. Pick the  one  of  your choice (probably the
             one of the richest format  that  your  program can digest) and
             load it.

     Note  that  the  correct  format   for   the   scrap  path  string  is
     'C:\CLIPBRD\' (with an ending \)  but  the Atari Compendium warns that
     some programs set it wrongly (probably either leaving out the ending \
     or else adding a filename 'SCRAP.*'), so some flexibility when parsing
     it may be an advantage.

     File extensions and  corresponding  formats  are  (according to Julian
     Reschke - ST Magazin 9/89 - the  personal efforts of whom probably did
     a great deal to make the clipboard into official Atari standard):

     TXT     ASCII text where  each  line  is  ended  with  CR/LF (though a
             reader should never count on the  CR, but be prepared for Unix
             style line ends with only LF).

     Any space at the end of a line is to be interpreted as a soft carriage
     return (i.e. reformatable). (Nothing is  said though, about hyphens at
     the end of lines.)

     ASC     ASCII text where only  paragraph  ends  are marked with CR/LF.
             (I.e. soft carriage returns aren't marked at all).

     1WP     First Word Plus
     WP      Word Perfect
     TEX     TeX
     RTF     Rich Text Format
     EPS     Encapsulated Postscript

     Others are, of course, possible.  Unfortunately there probably isn't a
     an extension  defined  for  Protext  format  files,  considering  that
     Protext isn't much of a GEM program, but maybe we could just ask Arnor
     to decide on one? (Perhaps 'PTX' would be suitable?)

     For picture files I think the extensions  are obvious, and the same is
     probably true for most other types of data.

     As a recommended minimum, exported text  should always be written to a
     SCRAP.TXT file at least and images probably always to a SCRAP.IMG file
     (and/or SCRAP.GEM for object graphics).

     Some may want a more  direct  data  exchange, memory to memory without
     going via  the  disk  based  clipboard.  Unfortunately  there  isn't a
     standard method defined for  this,  usable  with  all programs and OS-
     versions. Specifically there IS an official 'Drag&Drop' protocol which
     requires MultiTOS, and  there  are  a  number  of unofficial protocols
     defined for  specific  programs  (e.g.  Easy  Draw  and  Gemini) which
     however will probably NOT work with MultiTOS.

     The natural point to start from is  in  all cases with the AES message
     pipe. With APPL_WRITE you can send  16-byte  messages to any other GEM
     program, including accessories, which gets  them  the same way it gets
     messages from the system,  i.e.  waiting  for  them  through a call of
     EVNT_MULTI or EVNT_MESAG. 16 bytes isn't  much however and the first 6
     of these  are  in  addition  reserved  for  special  purposes; (word0:
     message type ID, word1: application ID of  sender, word2: 0 - or extra
     length of message).

     In theory you can send longer  messages  as  well, which could then be
     read by APPL_READ, but from what  I  have heard the AES message system
     is so bug-ridden that  APPL_READ  really  is  best  forgotten, and the
     message length at all times kept  to  16  bytes  to be received by the
     EVNT functions only. (As a proof of this Atari themselves chose to use

     MiNT pipes for their Drag&Drop  protocol  rather than fix the existing
     AES message system.)

     MEMORY POINTER PASSING:
     -----------------------
     The 16 (or effectively 10) bytes of an AES message may not be much but
     it IS more than enough to  pass  a  pointer to some memory block where
     more can be found, and this is how it is done I think by programs such
     as Easy Draw, Gemini etc. (possibly also by K-Word/K-Roget asked about
     by Peter Hibbs).

     It may even be possible  to  define  something similar to the MultiTOS
     Drag&Drop protocol, but  based  on  pointer  passing  instead  of MiNT
     pipes. There certainly would be  use  for  such  a protocol, e.g. as a
     backup when MiNT pipes aren't  available.  (Though one complication is
     admittedly that the basic AES of most  STs  and TTs lacks the means to
     conveniently determine application  IDs  for  window  owners  or other
     programs.)

     The first problem with the  protocols  of  these programs is that they
     aren't as widely known as they should be to become real standards. You
     need to know message type IDs and structures and whether a receiver is
     required to send some reply/acknowledgement etc. (I for one don't know
     any of these protocols and would be very grateful indeed for details.)

     IF ANYONE KNOWS OF A GOOD (AND  FAIRLY WIDESPREAD) PROTOCOL I THINK WE
     IN ICTARI COULD MAKE AN ACTIVE EFFORT TO SPREAD IT FURTHER! This is in
     my eyes the ideal kind of task for a programmers group such as Ictari.

     The second problem is  that  programs  under  MultiTOS are not usually
     meant to access each others memory  areas,  and the 68030 processor in
     Falcons and TTs can physically enforce  that this doesn't happen (e.g.
     'logical addresses' means that  different  programs  may see different
     things on the 'same' address).  Which  probably  means you HAVE to use
     the ordinary Drag&Drop protocol (below) when under MultiTOS.


     THE DRAG&DROP PROTOCOL OF MULTITOS
     ----------------------------------
     This, like the clipboard, is  official  standard  which I can describe
     fully (drawing on the Atari  Compendium  and  on  Julian Reschke of ST
     Magazin/ST Computer; I  haven't  been  able  to  test  it myself). The
     Drag&Drop protocol however requires the pipelining of MiNT (MultiTOS),
     which means it won't work on many present systems.

     Like with memory pointer passing, the  initial contact is made through
     a 16-byte AES message sent with APPL_WRITE. The rest of the communica-
     tion takes place in a MiNT pipe.

     From a user's point  of  view,  the  Drag&Drop  protocol allows him to
     select a piece of data within the  window of one program, drag it with
     the mouse to the window of another program and drop it there.

     The AP_DRAGDROP message:

     The structure of the AES message,  to  be  sent with APPL_WRITE to the
     program owning the destination window, is as follows:

              W: 63 (AP_DRAGDROP)
              W: application ID of sender
              W: 0 (No extra length of this message; just 16 bytes)
              W: Window handle of destination
              W: Mouse X position of drop (probably got from an EVNT call)
              W: Mouse Y position of drop            -  "  -
              W: Keyboard shift status at drop       -  "  -
             2B: The 2-character file extension of the MiNT pipe
              16 bytes in all.

     NOTE: -1 can be used in place of a window handle if the destination is
     a program in general and no  particular  window. The recipient is then
     usually expected to open a new window for the dropped data.

     Receiving:

     The 'recipient' should do the  following  as  soon as it gets (through
     EVNT_MULTI or EVNT_MESAG) an AES message of type 63 (AP_DRAGDROP):

     1)      Open the  'file'  (actually  MiNT  pipe) 'U:\PIPE\DRAGDROP.xx'
             where 'xx' are the  two  last  bytes  of the 16-byte Drag&Drop
             message.
             You open it as an ordinary file with FOPEN.

     2)      Write one byte to the pipe (with  FWRITE): =0 if you are ready
             to receive (in this window). =1 otherwise.
             Note that even a  program  that  doesn't otherwise support the
             Drag&Drop protocol could at least  write  a 1 byte, since that
             will spare the  user  having  to  wait  for  timeout  (3  or 4
             seconds).

             If you  write  a  1  then  immediately  close  the  pipe (with
             FCLOSE).

     3)      If you write a  0,  you  should  follow  this  with 32 further
             bytes. These should be 8  4-byte file extensions (e.g. '.IMG',
             '.TXT')  corresponding  to  file  formats  that  your  program
             recognizes and in order of  preference.  (Compare with the GEM
             clipboard above.) If you  recognize  less  than 8 formats then
             write null bytes for the ending ones.

     4)      Read (with FREAD) one word from  the pipe giving the length of
             a following header. Then  read  (again  with FREAD) the header
             itself:
               4B: Format of the data to be transferred (e.g. '.TXT')
                L: Length of the data
               ?B: Null-ended name of data chunk (to label an icon for it)
               ?B: Null-ended name for an associated file
               ?B: Possible extra info not yet defined (read it and ignore)
             Both data name and filename can  be  left out (= only one null
             byte each).

             NOTE: If the return value  from  FREAD  is 0 (zero bytes read)
             this means that the sender -  'originator'  - has given up and
             closed the pipe. You should then do the same at your end of it
             (use FCLOSE).

     5)      Write one byte =
             0: if OK, then read as many bytes as length of data and close.
             1: to abort instantly, then close.
             2: if format not acceptable, then go back to step 4 above.
             3: if data too long, then go back to step 4 above.
             4, 5 or 6 then close,  if  drop was on a 'trashcan', 'printer'
             or 'clipboard' respectively.


     Sending:

     Whenever the user has selected and dragged something, a program should
     of course 'keep an eye'  on  the  mouse.  (Waiting  for a mouse button
     release with EVNT_MULTI.)

     1)      When the user releases the mouse button, call WIND_FIND to get
             the handle of the window where the drop was made. Then convert
             this into the ID of the owning program via a call of WIND_GET,
             mode 20 (this wind_get mode doesn't  exist in the basic ST and
             TT AES versions but should be  there  in the AES of MultiTOS -
             and Falcon).  If  it's  the  window  of  another  program then
             proceed.

     2)      Use the MiNT call PSIGNAL  ('GEMDOS  number'  274) to make any
             SIGPIPE (13)  message  ignored.  I.e.  call Psignal(W:13,L:1).
             This is to avoid your poor  little program getting killed just
             because no-one is reading its pipe.

     3)      Create the 'file' (actually  MiNT pipe): 'U:\PIPE\DRAGDROP.xx'
             where 'xx' could be any  two  ASCII  characters usable in file
             names. (The  Atari  Compendium  proposes  that  you  try  your
             application ID in ASCII characters -  e.g.  '03' if your ID is
             3.) If you fail, you can  just  try two other ASCII characters
             until you succeed.

     You use the  ordinary  FCREATE  call  (GEMDOS  60)  AND  MAKE SURE THE
     'HIDDEN BIT' IS SET - i.e. the second parameter 'attribute' = 2. (With
     pipes this bit just causes  reads  to  return EndOfFile when the other
     end of the pipe has been closed.)

     4)      Now it is time to tell  the  recipient about the drop and pipe
             by  sending  the  type  63   (AP_DRAGDROP)  AES  message  with
             APPL_WRITE. See above.

     5)      Use the MiNT call FSELECT  (GEMDOS  285)  to wait for the pipe
             being ready  for  reading  (meaning  that  the  recipient  has
             written something) or a timeout of 3-4 seconds.
             The      call      should       look       something      like
             FSELECT(L:3500,L:rfds,L:0,L:0) for a  timeout  of 3.5 seconds,
             where rfds points to a longword with only the one bit set, the
             number of which = file handle of pipe.
             If FSELECT returns 0 then timeout  was reached (close the pipe
             and abort), otherwise contact has been made.

     6)      Read one byte  from  the  pipe  (with  FREAD).  This should be
             either 0 (= OK, carry on) or  1  (= Abort). In the latter case
             immediately close the pipe with FCLOSE.

     7)      If the byte read  was  0,  then  read  32  further bytes - the
             recipient's wish list of  formats described above (recipient's
             step 3).

     8)      Decide on a format to send.  This  doesn't HAVE to be a format
             favoured (or even mentioned) by  the recipient. The originator
             is free to have its views  too and should the recipient refuse
             to accept the decision, the originator can change it later.

             Write the following structure to the pipe:
                W: Length of the following header (not including this word)
               4B: Format of the data to be sent (e.g. '.TXT')
                L: Length of the data
               ?B: Null-ended name of data chunk (or just one null)
               ?B: Null-ended name for an associated file (or just one
                    null)

     9)      Read the one new reply byte from the recipient. If this is-
             0: Write the data to the pipe (FWRITE) and then close it
                (FCLOSE).
             1: Close the pipe instantly
             2: Try another format (repeat step 8) or close the pipe.
             3: (Too much data) Try smaller format or close.
             4: (Drop on trashcan) Close pipe and delete data within
                 program.
             5: (Drop on printer)  Close pipe and print data.
             6: (Drop on clipboard) Close and treat like 'Copy' to
                 clipboard.


     ARGS and PATH:

     In place of data  format  specifiers  ('.IMG',  '.TXT' etc.) 'ARGS' or
     'PATH' (no leading stop)  could  be  used.  Both  of  them  seem to be
     primarily  intended  for  communication  with  a  Desktop  or  similar
     program.

     ARGS is simply a command  line,  i.e.  one or more parameters (usually
     file specifications) separated  by  spaces.  Note  however that spaces
     within a parameter are allowed  by  enclosing it within single quotes.
     For an actual single quote character it has to be doubled (''). ARGS
     data are transferred exactly like  other  types  of data. (Sent by the
     Desktop to a program  into  whose  window  the  user  has dropped file
     icons.)

     PATH on the other hand REVERSES THE DATA TRANSFER. When the originator
     decides that 'PATH' data are to be  sent,  it is really a request that
     the recipient sends the path corresponding  to the receiving window. A
     recipient that accepts to that with a null byte, should make sure this
     is immediately followed by  the  path  -  null-ended.  The data length
     given by the originator should be interpreted merely as a maximum.

     NOTE: The last character of the path, before the null, should be a '\'
     if the window corresponds to a directory. Should the window correspond
     to a file then the filename should of course be included.
     (If the destination is a directory  I presume that the originator will
     follow the Drag&Drop PATH information exchange with a simple file copy
     operation to it.)

     To: Peter Hibbs
     Ictari proposals for Devpac improvements

     A very good initiative this is and here are my views:

     1)      Bug in Mon 3.10: The  Ctrl-O  option, to switch between colour
             resolutions, seems  to  usually  crash  the  ST  (except  when
             nothing has been loaded).

     2)      The DC directive: With e.g. DC.B Devpac lets all values in the
             range {-256:255} pass without error  messages. But only values
             in the range {-128:255}  could  of  course  possible have been
             intended.
             (A value of -256 is assembled by Devpac as 0, -255 as 1 etc.)
             The corresponding thing applies for word and long values.
             This bug annoyed me in Devpac2 and is still there in Devpac3.

             Also, Easy Rider (German assembler by Andreas Borchard) offers
             an additional directive DSC  (where  the  S stands for Signed)
             which is the same  as  DC  but  narrowing  further the allowed
             range of values.  E.g.  for  byte:  values  {-128:127} and for
             word: {-32768:32767}. This is  very  handy for address offsets
             and I would like to see it in Devpac too.

     3)      More options for STRING HANDLING please. To enable the writing
             of more powerful macros.
             a) In Easy Rider you can set a symbol to a string with SETSTR.
             b) Likewise in  Easy  Rider  there  are  operations to extract
             characters from strings, concatenate  strings and to determine
             string length and the  character  position  within a string of
             another string (1=begins  at  first  character,  0=not found).
             There  is  even  a  specialized  operation  to  determine  the
             parameter position  of  a  named  (macro)  parameter  within a
             parameter list - both given as strings.
             This all makes it  much  easier  to  write  powerful macros in
             general (intelligently analysing their input), and can also be
             used for special purposes  such  as  encryption macros, taking
             strings as input and producing -  at assembly time - something
             that is unreadable with a mere disk editor or similar.
             (Easy Rider uses $( ) to enclose strings in expressions - e.g.
             $(string). 1:$(string) extracts  the  first  character  of the
             string -  's'  in  the  example.  $(str):$(string)  finds  the
             position within 'string' where  'str'  is  found  -  =1 in the
             example.)

     4)      Please implement the BETTER OPTIMIZATION OPTIONS of Easy
             Rider:
             - Instead of  the  Devpac  O12+,  which  can  optimize "MOVE.L
             #x,An" to "MOVE.W #x,An", Easy  Rider offers the more powerful
             change to "LEA x,An"  which  can  then  immediately be further
             optimized to either short absolute OR PC-relative addressing.
             - Similarly Easy Rider can  change "MOVE.L #x,-(SP)" into "PEA
             x" to be possibly further optimized.
             - The E.R. optimization "MOVE #0,ea"  to  "CLR ea" may be less
             obviously useful; whoever  would  be  stupid  enough  to write
             'move #0,ea' rather than 'clr ea'? The answer is: a macro! And
             I think it is with macros that optimization is the most useful
             anyway.
             - Also, the E.R. MOVEQ  optimization  will  work not only on L
             sized MOVE instructions but on  W  sized  ones  as well, IF no
             explicit '.W' has been  used.  This  admittedly  may be more a
             matter of personal  taste,  though  I  find  it,  again, to be
             useful within macros.
             - Finally E.R. can, if you  want to, optimize branches forward
             as well as backwards to short  (though  it of course makes the
             assembly take a  longer  time  since  it  has  to  be redone -
             possibly several times).

     5)      Continue the  Devpac  integration  (of  assembler,  editor and
             debugger) by incorporating the LINKER  as  well. In Easy Rider
             (which otherwise lacks in integration) you can use the INCLUDE
             directive with object  files  just  as  easily  as with source
             files. As it is now I  doubt  that  I will ever use the Devpac
             linker  since  that  would   have   me  leave  the  integrated
             environment of Devpac.

     ----------------------------------------------------------------------
     To: Mrten Lindstrm
     From: Mark Baker

     " This  means  that  I  for   instance   can   write  my  name 'Mrten
     Lindstrm' with Swedish letters, and  feel  confident,  I  think, that
     it will come  up   right   not   just   on   any   Atari   computer  -
     regardless  of  its nationality - but  on any PC  compatible  too  (as
     long as the standard character set for these computers is used). "

     It works on a PC  running  DOS.  Windows  programs use an ISO standard
     character set (Americans seem to be  under the impression that ANSI is
     a world standards organisation and not simply a national member of the
     ISO, so they incorrectly refer to ANSI C and the ANSI character set)

     " The  double  s  character  of   German   is  another  problem. Atari
     computers reserve character  number  158   for  this,  but  still  use
     a  symbol identical to  Greek  beta  (#225).   On  PC:s (and printers)
     character 158 is  a  Pt  character  (Pesetas),   and   Protext  simply
     replaces Greek beta with German  double  s. (ST Protext translates any
     158 into 225.) "

     Many Germans seem  to  be  unaware  that  esszet  (sp?)  and  beta are
     different and assume the button on their keyboard is a beta character.
     This looks strange in  different  fonts  that do differentiate between
     them, and sometimes get automatically converted to ss in emails!

     " Yes, the keyboards ARE different between different nationalities!
     I send in a file (KBD_MAPS) with keyboard maps for some nationalities,
     which I hope could be extended  by  people  who know more. "

     There should be no need for a programmer to know the keyboard map.

     " 2) If you do place  commands  on   the main keypad, and you document
     the commands  as  bound  to  keys  with  certain  characters  on them,
     then you  normally  have   to   check   input   ASCII  NUMBERS  RATHER
     THAN SCAN CODES. "

     For alt shortcuts you need something like:

             keytable = Keytbl( (char *)-1, (char *)-1, (char *)-1 ) ;

             ascii = *(*keytable + scan ) ;

     Atari's style guides tell you not  to  use  alt shortcuts, but I, like
     most other people, do because  there  aren't enough ctrl shortcuts and
     most of them have defined meanings.

     " Should you put TWO functions on the same key, however, things become
     a bit more problematic. A bad example is in Devpac 3, Mon, where

         . and ,  are documented as 'Next/Previous View' while
         Shift-.  is said to 'Open View' and
         Shift-,  to 'Close View'.

     The key [I had to press] has the < and  >  on it, and is on my Swedish
     keyboard, as I said, different from the  ,  and . keys (but not on the
     British one, I know). Bad documentation/programming that is. (Even the
     masters aren't infallible.) So, how should Hisoft have done it? "

     Well, they could have just put < and  > in the menu. But in general it
     is not recommended to use shift and a punctuation symbol.

     " One simple solution would  have  been  to  not  use keys on the main
     keypad at all, but to use some   function  keys.  (I am surprised that
     none of these have been used in Mon.) "

     I prefer to have function keys set up by the user.

     " Another solution, of  course,  would   have   been to document 'Open
     View' as '>' and 'Close View'   as   '<'.  But  this  wouldn't perhaps
     look as neat. Apart from letters and  keys, I think this is what could
     cause the most confusion with the user. If your  program  prints dates
     for any reason .."

     I normally get and display dates in  the  form  24 Mar 95; this is the
     normal way for most Europeans and  using  the  name of the month means
     Americans aren't confused (where  they  would  be  by  24/03/95) but I
     believe  this  could  still  confuse  people  from  some  Scandinavian
     countries, who use year/month/day, is this true?

     To: Jonathan White

     "   0       No icon
         1       A diamond with an exclamation mark (Note only)
         2       Point down triangle with a question mark (warning)
         3       A Hexagon with 'STOP' inside it (are you sure???) "

     Apparently AES 4 adds a couple more,  an i for information and a disc.
     I don't suggest anyone uses them as on older AES versions you will get
     various bits of junk including the mouse pointers.

     " Note Icon 1 is usually  meant   for  note  messages  you simply have
     to acknowledge - this program won't run | in less than one meg {OK} "

     According to Atari's style  guide  this  is  for  errors or conditions
     requiring immediate action. I have  in  the  past  used it for program
     credits etc, but apparently you should use the i or no icon at all for
     this.

     " technically  against   Atari   user   interface   guidelines  (which
     state buttons should go OK CANCEL OTHERS) "

     Actually they state that it  should  be  OK   Cancel  Others ie. mixed
     case for all except OK.

     */ Actually we may have capitalized those words to make them stand out
     better but as we don't have the original  copy we can't be sure. If we
     did we apologise to Mrten.  ICTARI /*

     " The first step is  to  call  form_center()  to  set the point on the
     screen you wish a  particular  dialog  box   to  appear. Then you call
     form_dial() with the FMD_START parameter  to  tell  the system you are
     drawing on the screen and  not  to   do  anything  while  you  do  so.
     Then  you  use  objc_draw()  to  actually  display  the  dialog on the
     screen. "

     You also need wind_update() This  is  not  mentioned in the manual for
     Lattice C but apparently it has been documented by Atari all along; if
     you don't have it your dialogue  will  in some circumstances be messed
     up in a multitasking system.

     " Note  that  because    form_dial()    intercepts   all   inputs  via
     an evnt_multi() inside it, while you   have  a  dialog  on the screen,
     the rest of  your  application,  and   any  other  applications  in  a
     non-preemptive multitasking environment (errr.. Geneva is the only one
     for the Atari, as far  as  I  know)  will  be frozen. In MultiTOS, the
     programs continue running, but the screen  is not updated outside your
     dialog. "

     evnt_multi() does NOT stop the other  applications running. In fact it
     allows them to, you must have an  event library call if you want other
     apps to run under Geneva (have I said this before?). The wind_update()
     call stops other apps from displaying  or receiving input and there is
     one built in to form_do().

     " First off, define your  pointer  as  OBJECT *(something) Second, use
     rsrc_gaddr to point the pointer   at  the  root  object of the tree by
     using rsrc_gaddr(R_TREE, NAME_OF_ROOT_OBJECT, &(something)) "
                              ^^^^^^^^^^^^^^^^^^^
     It should be the name of the tree which is not necessarily the same as
     the name of the root object.

     To: Mrten Lindstrm

     " of it being too basic).  Here  is  one concerning a relatively basic
     and fundamental issue: - whether  or   not   MALLOC  (GEMDOS 72) could
     return memory blocks on  odd  addresses.  Have  I  missed an  official
     statement  about  this?  Was there ever an early TOS version returning
     odd memory block addresses, or  was  it  just  a  false alarm from the
     start (not unusual in old Atari documentation)? "

     I don't think it was specified either  way. Perhaps your book may have

     read this to mean  that  any  addresses  were  possible where actually
     Atari just forgot to document that it always returns even addresses.

     As old TOS versions return even  addresses and they couldn't change it
     now without breaking too much  code  -  and  why should they change it
     anyway? - I think you're safe assuming it to be even.

     To: Peter Hibbs

     " While on the subject of  HiSoft's  assembler  I think that, although
     it is very good at  assembling,  the   source code editor itself could
     still be improved. For example, I  would   like   to  see an option to
     export a highlighted block to the 'clipboard' so  that the marked text
     could be  copied  into  another  program   such   as   Harlekin,   for
     example. I would like to  see   the   first  few  characters  of  each
     'bookmark' location displayed in the information line of the window so
     that I can remember which 'bookmark' is which. I would like  to have a
     'move block' option  where  a  block  of  text  can  be  moved  in one
     operation rather than having  to  'copy'  and  then  'delete'. I could
     probably  think of a few more as well if pushed. "

     I'm sure I could add a few to that list. For example the project files
     used in Lattice C could  be  improved greatly, (although the otherwise
     almost identical editor supplied with  Devpac unfortunately lacks that
     facility altogether)

     " If anyone else  has  any  other  additions  they  would like to see,
     please send  them  in  and  perhaps  I  will  send them all to HiSoft.
     They might even implement them if  they come from a programmers group,
     well you never know ! "

     They've apparently stopped developing for the Atari (and for the Amiga
     as well???) although they're still selling stuff.

     To: Jim Taylor

     "  To  complement  the  Bezier  line   drawing   routines  in  my  CAD
     application I would  like  some  information/C  code  on  Spline curve
     generation. "

     I can explain exactly what  a  spline  is;  I've  got information in a
     textbook about how to calculate it. I  can send you a photocopy if you
     want but I warn you it is difficult  (I've got maths A levels at grade
     A and I can't understand it, if I could I'd have explained it here).

     A spline is a piecewise polynomial  interpolation,  that is there is a
     polynomial (normally a  cubic)  between  each  point.  Unlike  using a
     single polynomial for all points this method doesn't oscillate between
     points. The polynomials are chosen so that the spline is several times
     differentiable at the  nodes  (fixed  points).  That  is  there are no
     sudden jumps in the spline itself or in it's gradient.

     To: Steve Gale

     " I am writing a program in which   I  would  like to transfer data to
     or from other programs via the  system  'clipboard' but there does not
     seem to be any  information   available   about   this.  Is  there any
     standard format for this transfer, is  the  data  stored  in RAM or on
     disk, etc. "

     It's stored on disc, in any format  used  for disc files, eg. .IMG for
     bitmaps, .GEM for vector graphics, .TXT or  .RTF for text etc. You can
     have multiple formats so your own application can get more information
     from its own format while other apps can read the standard format.

     " Does anyone have any information on this subject ? "

     I might send an article to Ictari about this.  */ Please do. ICTARI /*

     To: Tony Harris

     "I know there are  ways  of   avoiding   some  of  the standard GEMDOS
     calls, that is by going directly to  the  hardware,  but  is there any
     way of doing this for the file calls, ie, f_open, f_read and f_close?"

     Not really. You can go directly to the disc hardware, but this differs
     depending on what device it  is  so  it is definitely not recommended.
     The bios  Rwabs()  call  avoids  using  GEMDOS  but  this  too  is not
     recommended as it doesn't understand file  systems and treats the disc
     as a series of sectors: if you  want  to  access files on the disc you
     need to use GEMDOS.  The  bios  call  is  useful  for writing a sector
     editor but that's about it.

     " Is there a way  of   preventing   the  mouse  from  entering part of
     the screen ? i.e.  to  prevent   corruption   when   redrawing. At the
     moment I turn off the mouse  if   it  strays  into  the  barred  area,
     but what I really want  is  the  effect  of  not  being able to go any
     further. "

     Not easily, without hooking into  a  timer interrupt and repositioning
     the mouse if necessary.  And  even  then  it  could  possibly move and
     destroy your image before your interrupt runs.

     To: Lee Russell

     " I am  part  way  through  writing  a   program  to  crop .IMG format
     pictures. Has anybody got some 'C' code  they  want  to donate to save
     a block of memory in that format? "

     I've got code for  uncompressed  .IMG  files;  if  anyone has code for
     writing compressed files I'd be interested in that myself.
     ----------------------------------------------------------------------
     To: ICTARI
     From: Iain Mcleod

     Is ICTARI going to be on  the  Internet?  (WWW). If it is/going to be,
     could you inform me of its address.

     */ We do not have an Internet  address at present although there would
     be some  obvious  advantages  if  we  did.  We  will  investigate  the
     possibility of joining although the  costs  of purchasing a high speed
     Modem and membership fees may  be  the  deciding  factor. We do have a
     number of members who have  access  to  the  Internet and we hope that
     they will look out  for  any  PD  articles/software  which would be of
     interest to programmers and send  it  on  to us. Perhaps these members
     could also let us know  how  to  join  the Internet, what software and
     hardware would be required and how much it all costs.  ICTARI /*
     ----------------------------------------------------------------------
     To: *.*
     From: Peter Hibbs

     Is there any 'legal' way to determine if a menu has been dropped down.
     In my current project I am using  'evnt_multi' with a zero timer event
     to flash a cursor, etc. When  the  user  moves the mouse into the menu
     bar I need to stop  the  cursor  flashing underneath the menu options.
     Unfortunately, even though the AES  is  displaying  the drop down menu
     items, the timer event is  still  active  and  the cursor continues to
     flash. To get round  this  I  have  defined  a  'rectangle evnt' which
     covers the area of the menu bar so  that when the mouse moves into the
     menu the rectangle event code switches  off  the cursor. I also had to
     add another test in the timer event  code  to  monitor the x and y co-
     ordinates of the mouse to do  the  same  test because if the mouse was
     moved too quickly into the menu bar, the rectangle event did not catch
     it. Fortunately the rectangle event  function  is  disabled by the AES
     when a menu is dropped down  so  that  even  though the mouse is moved
     down  into   the   main   screen   area   as   the   menu   items  are
     hilighted/unhighlighted, the rectangle event code does not signal that
     the mouse has moved outside  the  defined  rectangle (which would then
     re-enable the cursor). While this system  does seem to work quite well
     it does seem a bit messy. Is there a simpler way to do this?

     Does anyone know how the Canon  Bubble  Jet printers print out bit map
     graphics images? Any information would be very welcome.

     I have just purchased an Autoswitch Overscan unit for my STFM (but not
     fitted yet) to give me a larger screen area. Does anyone have any tips
     on how to write software which will still work properly on larger size
     screens. Obviously the screen width and  height  can be found from the
     v_opnwk VDI function but looking through  the manual there seems to be
     a  number  of  other  things  which   also   need  to  be  taken  into
     consideration. The manual does give  some guidance for programmers but
     it is very brief and written  in  broken English (and even lapses into
     German a couple of times). Has  anyone had any practical experience of
     writing software for larger screens, if  so perhaps they would like to
     let us know how to implement such code.

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