
     ICTARI USER GROUP             ISSUE 22                      May 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 22
                              ==================

     ASSEMBLY        Graphics image outliner routine.
                     Intro demo program code.
                     Mouse position test routine.
                     Upper/lower case conversion routines.
                     Mouse movement limiting technique.

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

     BASIC           Demo program on disabling menu items.

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

     STOS            Bank display program code.
                     Chaos engine.

     MISC            Using the system clipboard.
                     Terry King's GFA Extension kit demos.
                     Current membership list.
                     Index for issues 1-21.

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

     ASSEMBLY        Overscan routines.
                     STE 8 way hardware scrolling routines.
                     Blitter routines using A line $0007 call.

     C               Tim Oren GEM Tutorial. Part 12. GEM Events.
                     Replacement standard library functions with Alcyon C.

     GFA             Hi Rez format program.
                     Library Creator for GFA programmers.

     STOS            Menu Shell code.
                     Screen saver code.
                     STOS Extension selector.

     MISC            GDOS information file.
                     Character conversion tables.

     ---------------------------------------------------------------------
                                   EDITORIAL
                                   =========
     MEMBERSHIP
     ----------
     We have three more new members  this  month,  welcome to them. Also a
     few seem to have dropped out, at least they haven't sent any money or
     disks for the last or this months issue. If you decide that you don't
     want to receive any further issues, please  let me know and if you do
     want further issues, please send a disk  or money as soon as possible
     after receiving the current disk. If  you  do  send in a disk, please
     put something on it. If you can't manage an article, a letter for the
     correspondence section below  will  do,  I  just  hate  getting blank
     disks.

     GFA EXTENSION KIT
     -----------------
     This month Terry King has sent  an  advert  for his extension kit for
     GFA programmers as well as a number of demos and games that have been
     written with the kit (see the end of this file for more details). For
     any GFA programmer interested  in  graphics  and  sound programming I
     think this package would be invaluable,  the demo games are extremely
     well done although I am generally  not a games player, I particularly
     like the Bomber game. The two demo programs are included on this disk
     (in the MISC folder) and run  in  low  rez, the source code and other
     games can be obtained from Terry.  It still surprises me how powerful
     GFA Basic is, I was amazed  to  learn  from an article in Atari World
     magazine that the all singing, all dancing word processor Papyrus was
     written in GFA Basic.

     UNIVERSAL PRINT DRIVER
     ----------------------
     It has always been a problem when writing software that needs to send
     graphics images to a printer, to  be  able  to  cater for any type of
     printer that the end user  may  wish  to  use.  I  have come across a
     number of PD programs  (some  by  ICTARI  members including me) which
     work with only one type of printer which can be very annoying for the
     end user.

     Commercial software  houses  get  around  the  problem  by  writing a
     'printer driver' for  their  own  software  that  outputs text and/or
     graphics, with a suitable printer driver  file for each printer type.
     I believe that it would  be  very  useful  for  the  group to write a
     Public Domain printer driver system which  would then be available to
     all non-commercial programmers. This would allow any PD programmer to
     write a program  which  can  output  standard  text attributes (bold,
     underline, etc) and graphics images to  any  type of printer and know
     that it will print correctly without having  to try it out on lots of
     different printers.

     The question is then, is this  possible  and if so, how. Firstly, how
     do  printer  drivers  work  anyway.   Having  examined  several  from
     different programs there seems to be a number of different approaches
     to the problem. Protext, for example,  uses  a purely ASCII text file
     which has various groups of  letter  sequences  to define the printer
     control code sequences and even command structures such as if...else,
     etc. By contrast, First Word Plus,  Calamus and other printer drivers
     just have a sequence of binary values.

     It  would  probably  be  relatively   straightforward  to  cater  for
     different text attributes such as bold, underline, italics, etc. If a
     specific byte or word  size  value  was  allocated  to each attribute
     (i.e. 128 for bold, 129 for underline,  etc) which was then passed to
     the printer driver code which, via a look up table in the appropriate
     printer driver file, converted  the  code  into  the required printer
     control codes which would then be sent on to the printer.

     A more difficult  problem  is  printing  graphics  images.  How can a
     printer driver control routine know how bit image data is sent to the
     printer. The German drawing program  MegaPaint allows four basic bit-
     image printing modes, i.e.  9  pin,  24  pin, HP DeskJet/LaserJet and
     Atari Laser Printer SLM 804. The  method of printing graphics data is
     different on each type of printer and any individual printer may have
     different control code sequences  to  initiate  bit-image mode. These
     control code sequences are  entered  into  the  printer driver by the
     user from within  the  program.  If  these  are  the  only methods of
     printing bit-image data then it  would  be  fairly  simple to write a
     standard routine which can send a data stream to the printer with the
     appropriate printer driver file  defining  which  type  of printer is
     being used. The printer driver  file  would also provide the required
     control codes to start up bit-image mode  and  in the case of the dot
     matrix printers, the number of micro-line  steps required to move the
     print head after each raster line.

     Another  consideration  would   be   graphics   resolution.  The  dot
     resolution of each printer obviously  varies considerably and even on
     the same printer there  are  usually different resolutions available.
     Could our printer  driver  routine  automatically  adjust  the output
     resolution so that each printer prints  an image at the correct size.
     This sounds a bit too difficult to do  in practice and in any case it
     may be better for the application  program  to have full control over
     the output resolution, any ideas?

     On modern printers  there  are  also  colour  printing  facilities, a
     comprehensive printer driver would probably  have to include controls
     for this. How does colour work on different printers?

     On HP DeskJet  and  Laser  printers  (and  maybe  on  some dot matrix
     printers) the data stream to the  printer  can be compressed in order
     to speed up the print operation.  I  have written routines for the HP
     printers to do this which could  also be incorporated into the driver
     code. Is this a standard protocol  or  are there different systems in
     use on other printers ?

     How would a flexible printer driver system  work. It would need to be
     available for any computer language so it would probably be stored as
     an  object  file  and  linked   into   the  program  source  code  at
     assembly/compilation time. Another  alternative  may  be  to  run the
     driver routines as an executable program module from the user program
     using the  p_exec  function,  any  parameters  being  passed  to  the
     routines at execution time. A  third  alternative  (and the method we
     favour) is to include the object code as a binary file and call it as
     a function, procedure  or  sub-routine.  Obviously, at initialisation
     time, the absolute addresses would have  to  be relocated in the same
     way as a .PRG program is  processed  after  loading and this could be
     done automatically during the printer initialisation sequence.

     The driver code would probably consist of three separate routines, an
     initialisation routine, a routine to handle  text codes and a routine
     to handle graphics data. It  would  probably  be  easiest to have one
     entry point and use a system  of  command  codes passed to the driver
     routine (via the stack) to select  the  required function in much the
     same way as the AES functions do.

     When the application program is first run, the initialisation routine
     would need to access the selected  printer driver file which has been
     loaded from disk into RAM by the  applications program and set up any
     RAM buffers, look  up  tables,  etc.  The  printer  driver file would
     probably be best constructed as  an  ASCII file (perhaps something on
     the lines of a GDOS assign file)  which  then makes it easier for the
     user to generate new driver files with any text editor. An ASCII text
     file would also make the  file  easier  to  read and easier to expand
     with further control codes  later.  The  text  handling routine would
     receive all text data for the  printer  and when an attribute control
     code was detected (say in the  range $80-$FF or whatever) the routine
     would substitute  the  appropriate  printer  control  codes  from the
     driver file and pass them on to the printer.

     The graphics data handling is a  bit trickier. A special control code
     in the printer driver file could define  which graphics mode is to be
     used, i.e. 9 pin, 24 pin,  DeskJet/LaserJet  or Atari Laser (it might
     be better to ignore the last one  since  it is very limited). To send
     graphics images the applications program  could  first generate a bit
     map image in a  memory  buffer  and  then  call the graphics handling
     routine. The width of the image  (in  bytes) and the resolution could
     be passed to the routine together with the address of one raster line
     of data. The driver routine  can  then  store  or process that raster
     line depending on the  printer  graphics  mode required. For example,
     for a Laser printer the data could  be  sent immediately, for a 9 pin
     printer the routine will need 8 lines  of  data before it can be sent
     to the printer and for a 24  pin  printer it would need 24 lines. The
     sequence would then  be  repeated  for  all  raster  lines. A typical
     printer driver might look something like :-


     ;Printer driver for HP Laser Jet printer

     PN="HP Laser Jet"       ;Define printer name
     GM=3                    ;Graphics Mode 3 (LaserJet/DeskJet)
     RZ=300x300,150x150      ;Resolutions available =300 and 150 dpi
     TC=1                    ;Text compression mode 1 on

     $80=27,40,115,51,66     ;Bold text
     $81=27,38,100,48,68     ;Underline
     $82=27,40,115,49,83     ;Italics
     etc...
     etc...

     END                     ;No more data

     The above example is, of course,  somewhat over simplified. There are
     numerous other  problems  which  would  have  to  be  addressed.  For
     example, the embedded control codes  used  here  are byte size and in
     the range $80-$FF which implies  that  ASCII characters in that range
     (i.e. the  sign and other foreign characters, etc) cannot be sent to
     the printer direct. Is 128  codes  sufficient anyway, looking through
     the Laser Printer manual  there  are  many  more printer options than
     that available, but then would we  need  all of those anyway, Protext
     uses quite a small number of  text attributes codes. The applications
     program could send  more  specialized  codes  direct  to  the printer
     itself, if required although  this  would  defeat  the  object of the
     exercise to a certain extent.

     What other facilities should be built  into the printer driver code ?
     What about a facility to  swap  an  ASCII character code with another
     one, what about designing new characters within the driver file, what
     about plotters and, most importantly, how can we make the driver code
     future proof as far as possible. With new printers coming out all the
     time it would be nice, if not essential,  to be able to cater for new
     advanced printer designs.

     All of the above, at this  stage,  is  just a discussion document. No
     code has been written yet (unless  some  member has done something on
     these lines already). Looking  through  the membership questionnaires
     it appears that most members have  a  printer of some kind with about
     12 different types of printers  represented although not everyone put
     down which particular printer  they  have.  I  would, therefore, like
     every member who has a  printer,  and especially our more experienced
     programmers, to let me know whether  (a)  this project is feasible or
     even desirable and (b) what features  would  need to be included, how
     this could be done in the  various different computer languages, etc.
     Providing I get sufficient feedback  on  this  project  (and I hope I
     will) I will publish more details and  ideas  in the next issue. If I
     get a poor response I will have  to  assume that no one is interested
     in the project.

     If we can come up with a  good  system  between us which works well I
     will then present it to the  Atari  community at large via the glossy
     magazines for the benefit of everyone.

     ---------------------------------------------------------------------
                                CORRESPONDENCE
                                ==============
     To: All
     From: Tony Harris

     I have heard some horror  stories  that  the line_A functions are not
     supported by the Falcon and are not  even guaranteed to work on other
     FM/STE's !! Is this true or have I been the butt of a bad programmers
     joke ?

     Does anyone have  any  code  to  replace  the  normal  desktop with a
     picture which adjusts the picture depending on the resolution ?

     I have been using  the  palette  switching  trick  using  Timer B but
     whilst it is stable when  the  mouse  doesn't  move, it bounces a few
     lines when the mouse is moved. This is very annoying and I don't know
     how to stop this without losing the mouse which I need.

     Which is better, HiSoft's Video Master or Vidi-ST ?
     ---------------------------------------------------------------------
     To: Tony Harris
     From: Peter Hibbs

     In issue 20 you asked if it  was possible to prevent the mouse moving
     into a specified part of the screen. In the ASSEMBLY\MS_CHECK\ folder
     you will find some source  code  and  demo  program on this which may
     help.
     ---------------------------------------------------------------------
     To: *.*
     From: Terry King

     What's the correct use for FORM_DIAL  ? I've had this working before,
     but in my latest program  (Library  Creator)  I  just couldn't get it
     working. Each time I called FORM_DIAL(3, ...) to erase the dialog box
     it just drew a green box ! Even  though the system had plenty of free
     memory and  no  other  dialog  box  had  already  used  FORM_DIAL and
     FORM_DIAL(0,..) returned no error it  still  seemed not to work. What
     could be going wrong ?

     Are there any  standard  methods  of  calculating  the  position of a
     slider ? In GFA Basic  3  this  is  the  code  that  I am using for a
     vertical slider :

        back_slider is the object number of the slider
        fore_slider is the object number of the slider button
        height is the maximum of lines in total
        lines is the maximum of lines visible
        line is the current position

        ~OBJC_OFFSET(tree%,back_slider,bx&,by&)
        bh&=OB_H(tree%,back_slider)
        per#=100*height/lines
        fh&=bh&*per#/100
        OB_Y(tree%,fore_slider)=bh&*line/lines
        OB_H(tree%,fore_slider)=MIN(fh&,bh&)

     Although this code works fine  it  results  in  a  tiny error so that
     sometimes the bottom of the slider leaves a gap or overshoots.

     Is the EnhancedGEM interface available  in  England  and will it work
     with GFA or Sozobon C ?

     There's a program called WINLUPE which I think is written by the same
     guy who wrote EnhancedGEM which  displays  a magnified section of the
     screen in a window. This  window  is  updated  (very quickly) even if
     it's behind many other windows with only  a small part of it showing.
     How is this done ? My own  theory  is  that the program creates a one
     bit plane mask the size of the screen and draws the dimensions of all
     the windows on it and then uses  this as a mask before BITBLK copying
     the result to the screen. How does this sound ?

     Finally, is it possible to free a memory resident program ?

     To: Peter Hibbs

     I'm fairly new  to  GEM  programming  but  I  was  interested in your
     problem regarding information in a window  being printed on even when
     the menus have been accessed. I think that all you need to do is call
     WIND_UPDATE with a value of 1 at the start of any window printing and
     then call WIND_UPDATE with a  value  of  0  at  the end of any window
     printing.

     The value of 1  means  that  as  soon  as  the  menu is accessed that
     program freezes on the  WIND_UPDATE  command  and  stops any printing
     occurring. If however you  activate  an  accessory  the printing will
     start again so you need  a  further  check  to  see if your window is
     active with a call to WIND_GET with  a  value of 10 which returns the
     current topped window.
     ---------------------------------------------------------------------
     To: Peter Hibbs
     From: Mrten Lindstrm

     PREVENTING CLASHES ON SCREEN BETWEEN PROGRAMS AND THE SCREEN MANAGER
     --------------------------------------------------------------------
     In answer to your problem  with  clashes  between cursor flashing and
     menu:

     Yes, there is a simpler - and cleaner - way to prevent this. Its name
     is WIND_UPDATE. (Quoting Laurenz  Prner  of ST Magazin, WIND_UPDATE
     is "the most misunderstood of all GEM calls". Possibly partly because
     of its name - don't be fooled by it into believing it is something to
     do with windows only  -  but  mainly  because  it  has  been so badly
     described in most TOS books and documentation.)

     To ensure that never more than  one  process at a time (including the
     AES screen  manager)  is  drawing  on  screen,  all  well-behaved GEM
     programs are REQUIRED to ask  permission  from  the AES before making
     any changes whatsoever to the screen. And this is done with a call of
     WIND_UPDATE(BEG_UPDATE) (where BEG_UPDATE is an OP-code = #1):

       WIND_UPDATE(BEG_UPDATE) = Request permission to draw on screen!

     If any other processes are currently  drawing  on the screen, the AES
     will put your program on hold  until  all  processes before it in the
     queue are done with their  output  (=  have issued END_UPDATEs = #0).
     (For instance will the AES  screen  manager  issue its own BEG_UPDATE
     before letting down a menu box and will not issue an END_UPDATE until
     the box has been  removed  again.)  So  after  the BEG_UPDATE you can
     confidently make any output you  like,  such as inverting the cursor,
     without interference from others. When done you must call:

     WIND_UPDATE(END_UPDATE) = Output done; Screen free for others to use

     ... until it's time for next  "cursor flash" or whatever other screen
     output operation you might want to perform.

     NOTE:  The  rule  is  to   call  WIND_UPDATE(BEG_UPDATE)  before  any
     operation that (whether by VDI calls, AES  calls or - in a less clean
     program -  by  other  means),  explicitly  or  implicitly,  may cause
     changes to the screen  display.  I.e.  even  before  such  a thing as
     turning  off  the  mouse  pointer.  Some  AES  calls  have  built  in
     BEG_UPDATEs/END_UPDATEs, but it never does any  harm to make your own
     explicit calls, since  BEG_UPDATEs  can  be  nested  (each END_UPDATE
     cancels only the latest BEG_UPDATE).

     NOTE 2: BEG_UPDATE/END_UPDATE could be  used  even  by a program that
     doesn't intend to  draw  anything,  just  to  detain  others that do.
     Specifically they SHOULD be used by accessories needing to load files
     (including RSC files) or reserve  memory (including opening VDI work-
     stations) at bootup time (the only  time  it is safe for an accessory
     to reserve memory). A BEG_UPDATE will  hold the GEM Desktop while the
     accessory undisturbed can go  about  its  business.  (There were some
     bugged versions of TT-TOS  drawing  the  Desktop  without issuing any
     BEG_UPDATE, but for all other TOS versions it should hopefully work.)

     NOTE 3: The OP-codes given  in  the  Atari  Compendium are wrong. The
     correct codes  are  #1=BEG_UPDATE,  #0=END_UPDATE  (and #3=BEG_MCTRL,
     #2=END_MCTRL).

     By the way: BEG_MCTRL effectively  does  on  the INPUT side (it takes
     over all mouse AND keyboard input) what BEG_UPDATE does on the output
     side. It is however much  less  often  needed since input clashes are
     much less of a problem. (E.g. any  program owning the top window will
     get all keyboard input anyway.) It  must  be used in some situations,
     normally together with BEG_UPDATE, in  particular before sending up a
     dialogue box  (to  avoid  "click-through"  when  not  owning  the top
     window). Another example is if  you  temporarily  want to make use of
     the full screen area, overwriting even the menu bar, when use of both
     BEG_UPDATE and BEG_MCTRL will  again  completely  shut out all others
     from both output and input (though you  must then make sure of course
     that the screen is restored afterwards).

     PROGRAMMING FOR BIG SCREENS, GRAPHIC CARDS ETC.
     -----------------------------------------------
     As far as I know there are only  two rules to consider if you want to
     make your program work with any  TOS computer screen, with or without
     graphic card or other screen  enhancer.  Including all resolutions of
     Falcons, (Magic)Macs, PCs (with Gemulator 4) etc.

     1)      Never assume anything about  screen  dimensions  or number of
             colours or bitplanes (but  get  this  information either from
             WORK_OUT array after VDI calls  V_OPNVWK and VQ_EXTND or from
             Line-A variables). The  call  GETREZ  is  just  about useless
             except for one thing:  To  select  an appropriate screen font
             size when  using  GDOS.  (When  calling  V_OPNVWK,  with GDOS
             present, word  0  of  the  WORK_IN  array  could  be  set  to
             GETREZ+2.)

     2)      Never assume anything about the organization of screen memory
             or in other words NEVER  ACCESS  SCREEN MEMORY DIRECTLY. (The
             screen is  not  even  guaranteed  to  reside  contiguously in
             memory.) Either (in a GEM program) use VDI/AES for all screen
             output, or  else  (in  a  non-GEM  program)  use  GEMDOS/BIOS
             character output only. And  when  you  are dealing with image
             blocks in device specific format,  copied to/from screen with
             VRO_CPYFM (or  VRT_CPYFM),  you  should  of  course  make  no
             assumptions regarding these either. If you need to manipulate
             such an image block in any way - or save it as a picture file
             - you should always transform it first with VR_TRNFM into the
             device-independent format.

     (Since any graphic  card  must  come  with  a  'screen  driver' which
     replaces the respective  VDI  calls  as  well  as  DOS/BIOS character
     output and Line-A variables appropriately,  I think everything should
     be taken care of if you just rely on the above rules.)

     Needless to say this places some  limitations on the SPEED with which
     things can be written to screen (it  would  be hard to make a sprite-
     bouncing, joystick-wiggling game not appear  a  bit jerky), but as to
     WHAT is displayed anything  would  still  be  possible  by copying it
     (after  transformation)   as   image   blocks   to   screen.  Logical
     combinations of e.g. sprites  and  backgrounds  could  be done either
     within the context of the VRO_CPYFM  call  or you could use any hand-
     crafted routines of your own design  on  the image block - in device-
     independent form - before transformation and copy.

     Only if you want to break the  rules  to gain extra speed do you need
     any extra information particular to the screen-driving hardware used.
     E.g. most of the  native  Atari  screen-modes are stored sequentially
     and word-interleaved (an overscan  unit  should presumably not change
     that (?) ) and this information  may allow you to directly manipulate
     device-specific image  blocks  or  possibly  even  the  screen memory
     itself.

     This does definitely not mean that I would be uninterested in info on
     cookies or other  identifiers  of  graphic  cards  and  other screen-
     enhancers and some details on  how  they  organize screen memory. Did
     you get information on this, for your Autoswitch Overscan unit, which
     you would like to share?

     */ I have now got the AutoSwitch  OverScan unit working now and it is
     very good. It has shown up one problem on my Mono monitor though, the
     normal area of the screen is  grey  compared with the edges which are
     very white. Moral, make sure you  use  those screen saver programs to
     save the  screen  being  damaged  (I  now  use  the  Harlekin saver).
     Unfortunately the programming information that  came with the unit is
     very poor.  However  I  am  converting  my  existing  (badly written)
     programs  to  work  with  the  large  screen  and  I  may  report  on
     programming techniques at a later date.  PDH /*

     To: Mark Baker

     "There should be no need for  a  programmer to know the keyboard map"
     you say. No, sure, AS LONG AS ALL  RULES ARE FOLLOWED, and yet, a few
     lines later, you say that, in defiance of the Atari style guides, you
     like to use Alt shortcuts. Well, SO DO I, which is precisely one good
     reason why I think  keyboard  maps  could  be  of use. (The expressed
     argument for Atari's dissuasion from use  of Alt shortcuts is the use
     of the Alternate key to access characters on non-English keyboards.)
     E.g. one thing that can be  seen  from  the maps is that although the
     key positions  vary  between  nationalities  for  letters  A-Z, these
     letters seem never (?) to share keys with "Alternated characters", so
     that at least Alt-A to  Alt-Z  always  are unproblematical to use for
     commands. For many programs you only need a few commands which can be
     easily assigned keys without breaking  any  rules  at all, but when a
     program is as crowded  with  functions  as  e.g.  Protext, where just
     about every key is used for  one  or  more commands, I honestly can't
     see how you could do  without  keyboard  maps,  if  you want your key
     assignments   to   be   reasonably   compatible   between   different
     nationalities.

     You could also  have  said  that  "there  should  be  no  need  for a
     programmer to know hardware addresses". This  would be even more true
     (since a clean  program  shouldn't  access  hardware  addresses), but
     extra knowledge never hurts and is  even useful when you want/need to
     bend the rules a bit in as neat and harmless a way as possible.

     And no, we Swedes too would  understand  a  date expressed as '24 Mar
     95', we could even write it as  '24/3  1995'. My note, and the Atari-
     defined _IDT cookie, only applies  to 6-digit date expressions xx-xx-
     xx, as most often used for instance to present file dates. With these
     the Swedish practice - and  e.g.  in  letterheads  or for birth dates
     ("birth numbers" which form part  of  each  Swede's "person number" =
     civic registration number) - is to put year first and day last - i.e.
     95-03-24 (most significant numbers  first).  You  do  have a point in
     that using name instead of number  for  the month would eliminate any
     risk of confusion, though you would  then  of course have to vary the
     spelling of month names  slightly  between different languages. (With
     names reduced to three leading  letters  the differences will be very
     few between western languages, but there are of course some.)

     Finally, I have to thank you  for  your  notes about ISO and ANSI and
     for pointing out that the normal  character  set under Windows is the
     ISO set and not the IBM set (used  under DOS). I must admit that when
     writing my notes I was only aware that  the ISO set was used by Amiga
     and Archimedes. (There must still  exist  some  easy ways for Windows
     users and programmers to get at the old IBM/DOS set too, doesn't it?)

     To *.*

     Complementing my notes on "multinational programming" in Ictari 20, I
     send in character conversion tables (Atari  -  IBM - ISO - Macintosh)
     to give a more detailed  idea  of  which  Atari characters are usable
     with IBM and which ones are convertible to ISO/ANSI (=Windows/Amiga/-
     Archimedes) and Macintosh (without changing the character sets).

     To: other non-British Ictari members

     Am I the only  non-British  member  to  write  anything to Ictari? It
     isn't the English  language  that's  holding  anyone  back,  is it? I
     cannot believe my own  English  is  that  magnificent, and you should
     also know that Ictari has  a  very  kind and understanding Editor who
     has corrected many stupid mistakes of mine.

     I think it would be interesting to  hear your views, and info, on the
     "multinational programming" subject. (E.g. just  a  short note on the
     preferred date format in your country.)

     */ We would also like to hear  from members in other countries (or in
     this country for that matter). We  have just four members in European
     countries, two in Sweden,  one  in  Finland  and  one in Belgium. How
     about a letter guys.  ICTARI /*
     ---------------------------------------------------------------------
     To: Ictari and in fact everyone!
     From: David Seaman

     Firstly,  I must  thank   J  Davidson   for  his STOS text-displaying
     routine, which I have now   modified   slightly   to become the basis
     for the shell program for my  new  diskzine,  "E's Got It!"  (Blatant
     plug #1)  It is the  world's  first  (well,   second actually but the
     other one only  lasted  one  issue)   STe-only  diskmag.   (AVAILABLE
     DIRECT FROM ME FOR JUST 1.50  ON  THE  15TH  OF  EACH MONTH FROM MAY
     1995!   Blatant  plug  #2)   By   the   way,  what  happened  to  the
     "MEMBERS.TXT" last issue ?  */ Not enough room on the disk. ICTARI /*

     My STOS-hard drive  problem  is  still  there,  so can someone please
     help!  As I said  two  issues   ago,   it  causes  an  error AFTER it
     successfully performs the operation, so I   think  it must be getting
     a wrong address somewhere.  Otherwise,  STOS   itself saves and loads
     from the  drive  no   problem.    STock   Controller   v.1.5,   which
     threatens to become a legend in its own  lifetime  even if it doesn't
     actually get released (because I keep  going on  about  it) will only
     be released if -

     1)  This problem gets sorted out or
     2)  I make the program   less   powerful   and   flexible in terms of
     disk access (which I don't want  to   do...  i.e.  it loads and saves
     all files from the same directory the program itself is in).

     */ Perhaps you ought to  send  in  a code fragment which demonstrates
     the problem, this would be easier to  check than trying to guess what
     you have done wrong,  if  you  have  done  anything wrong. Also don't
     forget to send  details  of  your  set  up,  i.e.  TOS  version, STOS
     version, RAM size, Hard disk type & size, etc.  ICTARI */

     For all you budding STOSers out  there,  here's a quick list of every
     extension available that I know of...  (in no particular order).

     Compact   (comes   with   STOS...    compact   Degas   and  Neochrome
     screens- useful)

     Compiler  (turns  your  basic  files   into  executable machine code-
     this is the extension you MUST have)

     STE   (hardware  scrolling,  DMA   sound,  extended  colour  palette,
     joystick ports- and excellent extension)

     Blitter  (various blitter  commands,   but   unfortunately very slow-
     if it was faster,  this  would   be  and  essential addition for STE-
     owners)

     512  (show Spectrum 512 pictures)

     Cyber  (play cyber sculpt animations)

     GBP  (various commands and  STE   commands-   not  a bad extension at
     all)

     Missing Link  (super-fast  sprite  routines,  play  (SAD) chip music,
     various screen routines- can be a   little  tricky to get used to the
     commands, but many STOS  users   would   swear   by this extension it
     gives them so much more power!)

     Misty  (suicidally fast   and   versatile   screencopy routines, turn
     the mouse off and  other   routines-  an  excellent extension that no
     self respecting STOS user should be without)

     Control   (fast  sprite   routines   with   more   flexibility,  font
     routines and more- I find  this   a   little  easier than The Missing
     Link to get to  grips   with,   although   it's  a  tiny  bit  slower
     in some commands; highly recommended)

     Ninja  (tracker module player for STE, still in early stages I think,
     so I won't pass judgement on it yet)

     Tracker  (ye olde version, not  bad   sound  quality  but you have to
     convert the MOD  files  before  it   can   play  them- still, not bad
     really (have you heard the intro music for Grandad 2?!))

     3D  (use 3D objects, not bad if you like that sort of thing- I don't,
     so I can't really say much  about  it, although I know some use it)

     Stars  (display starfields like  Elite   without   taking up too much
     processor time- again, if you  like  that  sort  of thing it would be
     useful (is anyone trying to write an Elite 2 beater, for instance?))

     MIDI  (use the MIDI ports...  possibly to connect two ST's for multi-
     player games?- it has   been   done,   and   the   results where very
     good)

     Extra  (assorted  printer,  disk   and   other   commands-  a  superb
     extension, in fact priceless  for   just   the   disk format and disk
     copy commands!  The printer  commands  have  been emulated elsewhere,
     but this just goes to show how useful they were in the first place!)

     There are   others,   including   Maestro,   Maestro   Plus,   and  a
     blitter extension by GBP (which is   NOT   PD,   you  can get it when
     you register the  GBP  extension).   If  there   are  any  that  I've
     missed, and you would  like  them  to  be  included  in my exhaustive
     round-up in issue 2 of "E's  Got  It!",  then please send them to me!
     (Blatant plug #3)

     In answer to your question about the  STOS file selector, there is no
     way of  accessing   drives   I-P   without   writing  your own custom
     routine.  (If I get time,  I'll   write   one   and   send it in).  I
     found this out the  hard  way,   by   copying   my  STOS and COMPILER
     folders, etc onto drive M of my  new  hard drive, only to find that I
     couldn't access anything with the file selector!

     I'm also sorry to hear that you're running short of "stuff" to put on
     future issues, so I've  sent  in  some  more  code  for you.  And, of
     course, you could publish what I've already sent you...

     By the way, if anyone has any   STe  specific code, could you be kind
     enough to send it to  me  for  inclusion  in "E's Got It!"?  (Blatant
     plug #4, the last one so don't worry...)

     Anyway, happy  coding   to   one   and   all,   and   come   on, keep
     bringing out new software for the good old ST!

     */ Thanks for the code, we hope  you will also mention ICTARI in your
     new magazine.  ICTARI /*
     --------------------------- ADVERTISEMENTS --------------------------
     From: Peter Hibbs

     If anyone would like to  buy  some  books  the following ones are for
     sale from me :-

     Tricks & Tips of Atari ST (Data Becker)                 5 inc P&P
     The concise Atari ST 68000 Programmers Reference Guide  4 inc P&P
     Atari ST Internals (Data Becker)                        8 inc P&P
     Atari ST GEM Programmers Reference (Data Becker)        8 inc P&P
     Peeks and Pokes (Data Becker)                           3 inc P&P
     The Atari ST Companion (Sunshine)                       3 inc P&P

     Contact me at ICTARI if you are interested in any of these.
     ---------------------------------------------------------------------
                               SPRITE WORKS

     What is Sprite Works ?
     ----------------------

     Sprite  Works is a  development  package  specifically for  use  with
     GFA  Basic programmers who want  to  produce  games  or  demos.  With
     over 111 dedicated machine code  commands  that  can be added to  GFA
     it will out-perform anything written  in  STOS  even with all of  its
     available extensions.

     But  it's not just for  GFA  programmers,   it's also  invaluable  to
     assembly programmers as the full  assembly  code  to the commands are
     also included.

     Also  in the Sprite Works  package  is  a fully fledged art  package,
     two  map  designers  and  a  sample  editor   so  no  other  external
     programs are needed.  Extensive  documentation  is  given on disk and
     an  optional printed manual  is  also  available,  every  command  is
     given  an example for you to  run  and  it even comes with  the  full
     source  for  one demo,   two  semi-complete  games and  two  complete
     games, including a dynablaster type game.

     Here's a full list of the commands :

             Command          Use

             animate_block    Set a map block for animation
             animate_clear    Clear animation entries
             animate_map      Animate map blocks
             backdrop         Fast one bit plane tile printer
             blit_clip        Clip window for blitter chip (BLITTER)
             blit_copy        Copy block using blitter chip (BLITTER)
             blit_get         Get block using blitter chip (BLITTER)
             blit_put         Put block using blitter chip (BLITTER)
             box              Replacement pbox command
             borders_on       Turn on top/bottom border removal
             borders_off      Turns off border removal
             box_hit          Box collision detection
             change_flag      Changes map location flags
             change_map       Changes map location sprite
             chip_fx          Plays one of 75 sound chip effects
             chip_playing     Returns whether a chip sound is playing
             clip_draw        Set up clipping window for draw commands
             clip_explosion   Set up clipping window for explosions
             clip_kopy        Set up clipping window for kopy command
             clip_on          Turn on drawing clipping
             clip_off         Turn off drawing clipping
             clip_sprites     Set up clipping window for sprites
             clr_lines        Clear screen lines
             clr_planes       Clear selected screen bit planes
             cls              Fast clear screen
             compress         Degas Elite screen compressor
             copy_line        Copies screen lines
             copy_screen      Fast screen copy
             counter_on       Installs frame counter
             counter_off      Removes frame counter
             decompress       Degas Elite decompressor
             depack           Depacks ICE & AUTOMATION packers
             erase_sprites    Erase all sprites printed with print_sprites
             explode          Creates pixel explosion from screen graphics
             fade_to          Fades from current palette to new palette
             fade_to_black    Fades current palette to black
             fade_to_white    Fades current palette to white
             fast_invmask     Print preshifted inverted mask of sprite
             fast_mask        Print preshifted mask of sprite
             fast_sprite      Print preshifted sprite
             fuzz             Produces out-of-tune fuzzy TV effect
             get_flags        Gets the map location flags
             get_map          Gets the map location sprite
             h_wipe           Horizontal screen wipe
             install_rasters  Create raster colour bars
             joystick_on      Turns on new joystick controller
             joystick_off     Turns off joystick controller
             kopy             General purpose copy
             line             Replacement line command
             locate           Locates map address, use with print_map
             locate_flag      Locates map flag address
             mapper           Print multi-directional scrolling maps
             mem_fill         Fills memory will bytes
             mouse_on         Installs new mouse controller
             mouse_off        Removes new mouse controller
             move_parallax    Move parallax star field
             move_stars       Move 3D starfield
             music_off        Turns off soundchip music
             path_calc        Calculates bullet path
             path_kill        Kill bullet path
             path_state       Returns bullet status
             path_update      Update bullet position
             path_xy          Retrieve bullet x/y coordinate
             pixel_hit        Pixel collision detection
             play_bigalec     Play Big Alec soundchip music
             play_countzero   Play Count Zero soundchip music
             play_madmax      Play Mad Max soundchip music
             play_megatizer   Play Megatizer format music
             play_sentry      Play Sentry format music
             plot             Replacement plot command
             plot_explosion   Plot selected time frame of explosion
             plot_parallax    Plot parallax star field
             plot_stars       Plot 3D starfield
             print_invmask    Print sprites inverse mask
             print_map        Print a map screen
             print_mask       Print sprites mask
             print_sprite     Print single 16x or 32x sprite
             print_sprites    Sprite handler, print sprites in one go
             protracker       Play Protracker module music
             reset_palettes   Removes palette switching
             reset_rasters    Remove raster effects
             reverse_lines    Copies screen lines in reverse
             sam_convert      Converts between signed/unsigned samples
             sam_play         Play sample using soundchip
             sam_playing      Returns whether a sample is playing
             sam_stop         Stops sample player
             sam_wait         Waits for sample to end
             scroll_banner    Updates the banner scroll
             set_banner       Sets up banner scroll
             set_mouse        Sets new mouse x,y and max x,y
             set_palettes     Installs palette switching
             set_rasters      Sets raster offset
             setup_parallax   Sets up 3 layer parallax stars
             setup_stars      Sets up 3D starfield
             shrink           Shrink sprites in real time
             split_screen     Dual screen hardware scroller/splitter (STE)
             ste_mapper       Fast multi-directional mapper command (STE)
             ste_playing      Check if DMA is playing sample (STE)
             ste_sample       Play a sample using DMA (STE)
             ste_sound        Set sound parameters on DMA (STE)
             store_kopy       Save block in kopy format
             store_sprite     Save block in sprite format
             swap_sync        Waits a number of frames and swap screens
             text             Print 40 column font
             text_pro         Proportional font text printer
             turn_onc         Turns on interrupt C - 200 Hz timer
             turn_offc        Turns off interrupt C
             unpack_spc       Unpack Spectrum 512 SPC format
             view_512         Displays spectrum 512 pictures
             v_mapper         Prints vertical scrolling maps
             v_wipe           Vertical screen wipe
             wait             Waits a number of frames

     Some  of  these commands haven't  been  seen  in  any  language,  let
     alone BASIC.  ie,  pixel  explosions,   top  & bottom border  removal
     with  compatibility with samples  !,   sprite  scaling and STE  split
     screen hardware scrolling and more ...

     Don't take my word for it ...
     -----------------------------
     'You  will  not  believe  the  quality  of  the  games  that  can  be
     produced  with Sprite Works ...   Sprite  Works  is one of  the  best
     things  that's  happened  to   GFA   BASIC   ...   genuinely   useful
     documentation' FIVE STARS - ST Review Issue 23

     That  was  a  review of  version  1.22  and  now  the  much  improved
     version 2.0 is available,just how much better can FIVE STARS get ?

     What's needed ?
     ---------------
     A  colour  system with double  sided  drive  and  preferably  1Mb  or
     more  memory,  although the package  does  work  on 1/2 Mb  machines,
     and, of course, a version of GFA Basic 3.xx.

     How much ?
     ----------
     Just 7.00 for the two disk package.

     Where can I find out more ?
     ---------------------------
     Send a blank disk with return postage to:

          Mr T.King
          Ninth Wave Software
          172 Spencers Croft
          Harlow
          Essex CM18 6JR
     ------------------------------ End of file --------------------------
