

    ICTARI USER GROUP             ISSUE 13                     August 1994

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

                     *   m   a   g   a   z   i   n   e   *

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

                              INDEX FOR ISSUE 13
                              ==================

    ASSEMBLY        Setting up system timers.
                    Vertical Blanking List (VBL) notes.
                    Colour cycling on raster lines.
                    Nick Bates. Sprite tutorial Part 2.
                    Keyboard equates file.
                    Compare routine.
                    Disk formatting code.

    C               C Graphics extensions.
                    Various C functions for use with GEM dialogs.
                    GEM Tutorial by J White. Part 3.

    GFA             Anagram generating code and recursion techniques.
                    Sound sample play routines.

    STOS            STOS extra extensions.

    MISC            Atari Questions and Answers file No 2.
                    Discussion on drawing tangents on curves.
                    Current membership list.

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

    ASSEMBLY        STFM Overscan techniques.
                    Nick Bates, Sprite tutorial Part 3.
                    Code to calculate position of bouncing sprite.
                    Signed Integer fraction maths routines.
                    'Case' selection routine.

    C               'Tiny' picture file reader.
                    Othello game code.

    GFA             GFA Manual Part 2.
                    Dialog box designer program.

    STOS            STOS accessory.
                    Rebound game.
                    Plazma display code.

    MISC            Atari Questions and Answers file No 3.
                    STE hardware information.


    For future issues :-

    Polyline drawing routines in machine code.
    Bezier curve drawing routines.
    Picture decompression routines for IMG, Degas, Tiny, PCX, PAC, etc.
    Picture compression routine for IMG pictures.
    HP DeskJet/LaserJet compression routines (Mode 2 TIFF).
    Playing sound samples on non STE machines.
    Picture switching techniques.
    Printer driver code for printing mono/colour images.

    ----------------------------------------------------------------------
                                  EDITORIAL
                                  =========
    MEMBERSHIP
    
    We have had a few more members join this month, welcome to them.

    AUTO FOLDER
    
    Last month we included the DESKTOP.INF  file  in the root directory so
    that members without hard  disks  can  boot  up  in medium resolution.
    Unfortunately this does not work for some  STE owners because of a bug
    in some versions of the TOS so the AUTO folder runs a 'fix' program to
    overcome this problem.

    GFA MANUAL
    
    Unfortunately, due to lack of room on the disk, we cannot include part
    2 of the GFA manual or the  index  file but hopefully we can get these
    on next months disk.

    MICRO-MART ADVERTS
    
    A good number of members  have  joined  the  group  as a result of our
    adverts in the Computer Micro  Mart  magazine  so we are continuing to
    advertise in this magazine every  few  weeks.  If any member buys this
    magazine and does not need  to  advertise anything, perhaps they would
    send the advertisment page into us  so  that  we can use it for future
    ICTARI adverts.

    SAMPLED SOUNDS
    
    In the October issue we would like to publish a number of articles and
    source code on sampling  sound  and  replaying  sampled sounds. If any
    members have information or source  code  for playing sampled sound on
    STFM, STE or Falcons perhaps  they  could  send it in. We particularly
    need technical data on the various sound  formats that are used on the
    Atari machines, i.e. .AVR,  .SPL,  .SND,  .SAM,  STOS  MAESTRO and any
    others that may be used (note that  we already have the PD file 'Audio
    File Formats' by Guido van Rossum,  V2.10 although a later version may
    be of interest).
    ----------------------------------------------------------------------
                                CORRESPONDENCE
                                ==============
    To *.*
    From J. Levon

    When I set a dialogue to  colour  8  in  WERCS (the Falcon grey, as in
    WinRec), in 2-colour mode it  changes  to  black  (as it should). This
    makes the dial unreadable. In WinRec  and similar Falcon programs, the
    dial is white in 2-colour mode. How  do  I accomplish this ? Do I have
    to dig into the resource file and  change the colour to 0 (White) when
    my program detects a 2-colour mode ?

    Also, I can't get FLDLIB  (from  ICTARI  11)  to work in an accessory.
    Why not ?

    Lastly, when using FLDLIB in  conjunction  with Let-Em-Fly (with Dials
    to Mouse ON) the title bar of fld_do  can corrupt the menu bar (when a
    program is not using the menu bar). Is there any way to avoid this ?
    ----------------------------------------------------------------------
    To Nick Bates
    From Dick Teuber

    I can sympathise with you  about  learning  C  on an inferior compiler
    (although you don't say which one) but jumping up to Lattice C may not
    be the best solution.  Lattice  C  is  very  comprehensive but is also
    quite hard to set up and use for any beginners to C programming.

    I would suggest that you  try  and  get  hold of HiSofts C Interpreter
    (for about 40) which is  very  easy  to  understand and use. It works
    like a BASIC interpreter, you  just  write  the  code  and then run it
    without having to compile and  link  it  first. This makes the program
    writing time much shorter  especially  as  the  editor  does  a lot of
    syntax checking before you even  try  and  run  it.  Also any run time
    errors are flagged up and therefore  it  is  much less likely to crash
    when the  code  is  executed.  It  uses  the  standard  UNIX  and ANSI
    libraries with over 460 library  functions  as  well as good debugging
    facilities, trace mode,  variable  dump,  memory  dump, pointer tests,
    exception trapping and stack displays, etc  which  you do not get with
    Lattice C. There are also a  large  number of built in window commands
    which are much easier to use than the standard GEM window functions.

    The manual is also very  useful  with  a C language tutorial, function
    reference and GEM toolbox. The  main  disadvantages  are that the code
    will run slower compared with  a  compiled version (although GEM calls
    will not be noticeably slower), users will need the interpreter to run
    the program and it only works  in high and medium resolution. However,
    the source code is compatible  with  Lattice  C  so that when you have
    written and thoroughly  tested  a  program  it  can  be compiled using
    Lattice C to generate  a  stand-alone  .PRG  program.  As  I have both
    programs I would be happy to do the compiling for you (or anyone else)
    when you are happy with your source code.
    ----------------------------------------------------------------------
    To:    Martin Cubitt & Paul Laddie Aka BYTEMAN
    From:  Martyn Armitage

    Unfortunately it is not possible to format 11 sectors per track  using
    the  XBIOS  10 system call.  It's a problem that  I  encountered  when
    attempting to write a disk formatter some years ago.  The routine will
    attempt  to  do the format but fails miserably.  The  reason  for  the
    failure is related to the amount of track data that has to be  written
    and the time available to do it in.  A track, when formatted, consists
    of  not  only the sectors,  each consisting of  512  bytes,  but  also
    address marks,  track number, side number, sector number, sector size,
    CRC checksums, filler bytes, synchronisation bytes, and data marks - I
    don't think I've left anything out -, all of which take space and time
    to write.

    A  disk that is formatted to 9 sectors per track will have 6969  bytes
    of data written to each track.  Of these,  4608 (9*512) are  available
    for  the  storage of user data.  A disk formatted to 10  sectors  will
    consist of 7281 bytes,  and a track formatted at 11 sectors/track will
    result  in 7893 bytes being written.  It can be seen that each  sector
    consists of 612 bytes, of which 512 are user available.

    The  problem with formatting 11 sectors is that 7893 bytes have to  be
    written  in  the same time as would normally be used for  a  9  sector
    format,  ie. one disk revolution. The XBIOS call writes the 11 sectors
    but  can't do it in one disk revolution and so the start of the  track
    gets overwritten by the end of the track.

    The solution is to reduce,  to the absolute minimum,  the size of  the
    gaps  between  each sector,  and the bytes that fill the  end  of  the
    track.  This  can't be done using the XBIOS routine and so one has  to
    resort  to writing routines to create the formatted track data and  to
    control the WD1772 chip.

    With the help of 'ST Disk Drives:  Inside and Out', the 'BIOS' listing
    in 'Atari St Internals' and disassembling the ROM routines  myself,  I
    wrote  an  extended  formatter.  The  program  didn't  get  completely
    finished.  I  think that the routines for busying the FAT  entries  of
    damaged/unformatted sectors didn't get written,  and maybe some  small
    inconsequential pieces.  I do,  however, personally use the program as
    it is.

    In  order to save a lot of work on your part I've decided  to  release
    the  whole  of  the  source code - written using  DevPac2  -  for  the
    program.  This includes the GEM/VDI interface and routines as well  as
    the  resource file,  complete with headers,  which was  created  using
    'WERCS'.

    There  is  a fair amount of source code that may be of use  to  others
    reading  this,  particularly those interested in GEM/VDI  programming.
    The  source  includes  routines for  dealing  with  window  re-drawing
    (RDR_EVNT.S),  obtaining  the status,  flags and string  addresses  of
    objects within a resource tree (OBJCSTAT.S).

    The  code is old,  not the most elegant,  and could do with a  bit  of
    sprucing  up  here and there.  In fact,  I no longer use most  of  the
    routines  supplied,  having  modified  them  beyond  recognition,  and
    developed  new ones over the years.  For example the CLIP  routine  in
    RDR_EVNT.S was my first attempt at the code, and it shows. The routine
    I currently use is about a quarter of the size and much much faster.

    */ See ASSEMBLY\XFORMAT\ directory for code and program.  ICTARI /*

    To:       *.*
    From:     Martyn Armitage

    Can anybody help me with an algorithm?  I'm wanting to write a program
    to produce fixtures for a league.  The problem: The number of teams is
    variable  between 4 and 24,  but always an even number as one  of  the
    teams can be 'No Game'.  Each team has a fixture every week,  even  if
    they  are playing 'No game'.  Each team plays every other team  twice,
    once at home and once away. There should be the maximum amount of time
    between reverse fixtures (A vs B and B vs A);  the second half of  the
    season  can be a complete reverse of the first half ( 1st game of  1st
    half  =  1st  game  of 2nd half etc).  No team  plays  more  than  two
    consecutive games at home or away, and consideration needs to be given
    to  teams  that share the same ground/pitch (they both can't  play  at
    home at the same time).  The number of divisions is variable between 1
    and 4 but again consideration needs to be given to teams in  different
    divisions that share the same pitch/ground.

    The  teams are to be referenced  by  number  rather than name in order
    to comply with the League Update program that I have written.

    I've spent many hours trying to come up with an answer but just  can't
    get my head around it. I'm sure there must be a formula somewhere that
    describes the problem.  Any  help  gratefully  received. The algorithm
    will be  fine but if you just  happen  to have the source (I can  cope
    with  Assembler, Basic -any variant-, and C).
    ----------------------------------------------------------------------
    To ICTARI.
    From Leslie W. Dewhurst.

    Errata sheets for Atari Compendium: ICTARI 11.

    I was interested  to  see   that   Mark   Baker  has obtained official
    Errata for the first  edition.  How  does   one  get  this? I sent the
    registration card from the  back  of   the  book  off  to America (not
    very hopefully!) but have  had  no   reply.   I  bought  the book from
    Hisoft at an exhibition.

    Speedo GDOS function "vgt_get_table()".

    The Atari Compendium says  that  the   first  of  the  seven tables to
    which this  function  points,   contains   a   "Master  Mapping". Does
    anyone know what this  latter  contains,  what  it  means,  and how it
    is used?

    Speedo GDOS function "v_ftext16()".

    The Atari Compendium  shows  that   there  is  a  parameter "wstrlen",
    whereas Hisoft's book  "Modern  Atari  System  Software"  on  page 144
    omits it or  anything  like   it   from  the  binding for "v_wc_ftext"
    (which is apparently another name for the same function).

    Is this deliberate or  is  it   a   mistake?  If  deliberate, how does
    one specify the length  of   the   string?   What   is   the form of a
    "16-bit wide  string"  anyway?   An   array  of  word-length elements?
    If so, the last  element  of  the  array  must  presumably contain two
    null bytes, not one.  But  surely   this   could   be  taken to be the
    Bitstream  IDX  value   of   a   space   character,   and   could  not
    therefore be used as  a  string   delimiter?  I  am  interested in all
    the languages for which Hisoft give bindings.
    ----------------------------------------------------------------------
    To STOS programmers
    From George Hodgson

    I'm trying to write a pools predicting program and need all the help I
    can get with the  design  of  a  suitable  database  for recording the
    matches played, goals for and  against,  etc,  etc, these to be across
    the page and not like the usual  down  the page type of address thing,
    any help, suggestions, code, etc will be gratefully received.
    ----------------------------------------------------------------------
    To *.*
    From Diamond Software

    Does anyone have  the  Protracker  or  Noisetracker  replay  routine ?
    need urgently!

    Cheers...

    To Mic
    From Diamond Software

    We will send our  'new'  sprite  routines  into  Ictari  soon. I'm not
    sure what sprite routine Peter has of our ours, but I'm sure that it's
    very old  and  slow.  We'll  also  document  the  source  and  do some
    explanations on how the routines  work.  We  will  also tell you other
    methods.

    To *.*
    From Steven <Diamond Software>

    Does anyone have  any  type  of  compression  methods  for  picture or
    PRGs? I coded one about two  years  ago,  but  it took too long (about
    15 mins for a 50K file !!!!)

    Also, anyone know how to load GIF, BMP and SPU/SPC ?  Docs will do!

    To EVERYONE!
    From Diamond Software (again)

    We hope you like the source  codes  that  we have given away (see next
    month). Later we'll give you  a  lot  more  source  code and also some
    documentation to go with them.

    I have just been looking through old  Ictari  disks and I saw a notice
    asking for some more STOS, C  &  GFA  source  code. Well, we have been
    busy coding something in STOS  for  some  time  now and the project is
    nearly ready for release, so  we'll  send  that  in as well some other
    source code. We also have some full screen GFA overscan source that we
    can't get to work 'coz we only  have  the  GFA 2 compiler and it needs
    compiling with GFA 3 Compiler. Does anyone  want it though ????

    As for C, well, we have only  been  coding  in it for a few months and
    our programs are  pretty  crap  compared  to  others.  Maybe  in a few
    months.

    Quick hi to the Professor for  his  great  GFA sources !! Love to  see
    some more...

    */ We second that last comment.  ICTARI /*
    ----------------------------------------------------------------------
    To ICTARI
    From Geoff Smith

    I am particularly interested in  the forthcoming article about playing
    sound samples on non STEs, I need to  be able to do this from within C
    and everything I have found about it so far is in assembler.

    */ We suspect that C would be too slow for the interrupt driven sample
    playing code and that you will have  to link in a machine code routine
    to do this but if  any  C  coders  know  different, please send us the
    information. ICTARI /*
    ----------------------------------------------------------------------
    To *.*
    From John Hayward

    I need some information  on  rare  Atari  computers/consoles. So far I
    have got information and pictures on the following :-

    8 bit machines.
    400, 800, 600XL, 800XL, 1200XL, 65XE,  65XEM, 65XEGS, 130XE, 320XE and
    Portfolio.

    16 bit machines.
    520ST, 520STM, 520STF,  520STFM,  520STE,  1040STF, 1040STFM, 1040STE,
    4160STE, MEGA ST, MEGA STE, STACK,  ST  BOOK, STYLUS, ST PAD, OPTOFILE
    CDAR 504 and 505.

    32 bit machines.
    Falcon 0303, TT030 and Medusa.

    Consoles.
    Pony, 2600VCS Mark 1, Mark 2, 7800VCS, Lynx 1, Lynx 2 and Jaguar.

    The machines I still need information on are :-

    1400XL, 1400XLD, 1450XL, 1450XLD,  1600XL,  130  &  260ST (128K & 256K
    versions), 65XEP, Laptop XE, 5200VCS  and  entire  PC range. These are
    extremely rare or unreleased. The program I use is called Atari Museum
    and covers the machines listed. It  shows  when the machines came out,
    memory capacity, picture, etc. The program is only available on the ST
    at the moment with the XE version  in  October. What I would also like
    is someone with an 8  bit  system  and  an  ST  who can exchange files
    between machines as I have three 720Kb  disks full of Neochome files I
    want converted into GR7 or 8 pictures on the XE. My set up consists of
    a 1040STFM, SC1224  monitor,  SF354  drive,  IBM  printer,  65XE, 1050
    drive, 1020 plotter and XC12 tape deck.

    */ Since this is a bit specialised for ICTARI, if anyone can help John
    perhaps they would  contact  him  direct  at  42  Shelford Rd, Milton,
    Portsmouth, Hants, PO4 8NT.  ICTARI /*

    ------------------------------ END OF FILE ---------------------------
