

    ICTARI USER GROUP             ISSUE 12                       July 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 12
                              ==================

    ASSEMBLY        Load file routines.
                    Colour palette fading routines for STFM & STE
                    User defined mouse shapes for GEM programs.
                    Sprite drawing routines.
                    Sprite tutorial Part 1. Beating the 16 pixel boundary.
                    Updates for Cookie find & Mouse routines.

    C               Fractal drawing code.
                    GEM Tutorial by J White. Part 2. Initialising GEM.

    GFA             GFA Manual Part 1 of 3.
                    GFA Alert box designer program.

    STOS            Bootview program code.
                    Pipe perfect game.

    MISC            Analyzer program to display info on system crashes.
                    Atari Questions and Answers file No 1.
                    Warning for DevPac 3 and Lattice C users.
                    Current membership list.
                    Index for issues 1-11.

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

    ASSEMBLY        Setting up system timers.
                    Vertical Blanking List (VBL) notes.
                    Colour cycling on raster lines.
                    Sprite tutorial Part 2.
                    Keyboard equate file.
                    Compare/Case routines.

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

    GFA             GFA Manual Part 2 of 3.
                    Sound sample play routines.

    STOS            STOS extra extensions.
                    STOS accessory.

    MISC            Atari Questions and Answers file No 2.

    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.
    Signed integer fraction maths routines.
    GFA Dialogue box designer.

    ----------------------------------------------------------------------
                                   EDITORIAL
                                   =========
    MEMBERSHIP
    
    As a result of recent publicity we have had five new members join this
    month, including one from Greece, welcome to them. To date we have had
    22 inquiries about joining the  group  and  15 have actually joined. I
    wonder why the others didn't, oh well.

    ARTICLES
    
    Earlier this month I started  to  upgrade  my  hard  disk from 65Mb to
    170Mb by swapping  the  bare  SCSI  drives.  Unfortunately, during the
    transfer of data from hard  disk  to  floppies  to  hard disk, I had a
    major problem with some disks which  resulted  in  the loss of some of
    the data from one partition. Most of  my own source code was backed up
    and I recovered this  OK,  unfortunately  some  of the ICTARI material
    which has been sent in was not  stored separately and some of this was
    lost. I do keep rough  records  of  who  has  sent  in what and I have
    contacted  those  members  who   sent   in  articles/source  code  for
    replacements. However, if you  sent  in  some  material  in the last 4
    months and I have not  contacted  you  about replacing it, perhaps you
    would send in another disk with the  same material. The only article I
    know I have lost and I cannot remember who sent it in is one about the
    STE hardware, could the  member  who  sent  it  please send me another
    copy.

    LANGUAGE CONVERSIONS
    
    We often publish source  code  for  various  functions in one language
    which would probably be of  use  to  other  members but in a different
    language. On this disk there are several routines and programs such as
    the GFA alert box designer,  mouse  shape  change routine, colour fade
    routine, etc which could be of  use to programmers in other languages.
    If any member who is clever enough  to  be  able to write in more than
    one language would like to  provide  alternative  versions of any code
    published in the ICTARI magazine I am  sure a lot of our members would
    be grateful.

    NEW ARTICLES
    
    We still  need  articles/source  code  for  future  magazines  in  all
    languages. We do have some Public Domain  material in hand but we want
    to keep the use of this to  a  minimum since some members will already
    have seen it. Out of the 50  or  so  members that we now have, just 16
    have sent in material that they have written themselves. So if you can
    send us any code (or  programming  queries)  over the next few months,
    please do.
    ----------------------------------------------------------------------
                                CORRESPONDENCE
                                ==============
    To *.*
    From Martin Cubitt

    I need your help  in  writing  three  separate  routines in assembler.
    Although it is really the algorithm  that  I require, the source would
    obviously save me a lot of time and hassle.

    Firstly, I need a routine which will  allow me to scroll a screen (32K
    block of data holding either  a  picture  or  more likely text) in the
    method used by the film Starwars. The illusion is that the text is not
    just running up the screen but is  fading into the background giving a
    three dimensional perspective of the  scrolling.  I want to write code
    in STOS but I am  sure  it  would  be  too slow and cumbersome (unless
    anyone can prove me wrong!). I can however write the code in assembler
    and call the routine from STOS. Any takers ?

    Secondly, I would like the source  to  a clearly written routine which
    allows me to format discs with  extended format options, such as extra
    tracks and sectors per track.

    Finally, in the STOS EXTRA extension (*/  see next month /*) I wrote a
    new command called PPSC,  Pixel  Perfect  Screen  Copy. The routine is
    fairly slow as it literally takes  every  bit  of every plane within a
    selected block on the screen and  copies  that bit to another block of
    the same size. A facility  exists  in  STOS  to do this, called screen
    copy, but it limits the user  to  a  word  boundary for the block. Has
    anyone an algorithm to allow sections  of  one  screen to be copied to
    another (in any of the standard  three  resolutions) ? An option would
    also be required to allow a selection  on the number of planes to copy
    so by selecting only the first plane  the whole operation is very fast
    but only a few colours will be  affected. The parameters passed to the
    routine would be the source address, destination address, source start
    x, source start y, source end  x,  source  end y, destination start x,
    destination start y and the number of planes. Oh, this is for STOS and
    as STOS does  not  use  GEM  please  do  not  suggest  or  use any GEM
    functions. I tried a series of loading  bytes and shifting them into a
    buffer and eventually placing  them  into  the  destination but I just
    could not get my head around it. One for the clever people I think !

    Any joy you can give  will  be  greatly  appreciated and any resulting
    code will be fully acknowledged as  being  yours. I will not profit in
    any way from using the proposed code so  I am afraid I can only credit
    you in the program and not financially.

    */ Can anyone help with  the  above.  It  sounds as though the BitBlit
    function which can be  used  via  the  ALine  calls  (and  so does not
    involve using GEM) would do the job  but we haven't used it ourselves.
    Does anyone have any code to do this. ICTARI /*
    ----------------------------------------------------------------------
    To *.*
    From Nick Bates

    I have decided I am not going  to  do  any  more C coding unless I get
    myself a decent C compiler, namely Lattice C. Unfortunately it's a bit
    expensive to buy new, therefore if there are any ex C coders out there
    with a copy to sell please  contact  me.  My address is in the members
    file.
    ----------------------------------------------------------------------
    To *.*
    From Carl Pattinson

    Has anybody got any info (or if  possible source code) for writing the
    compiler extensions for STOS in assembly  language. I already know how
    to write the basic extensions and would gladly exchange that knowledge
    in return for the info on the  compiler extension. It would help in an
    extension that I am hoping to produce.  My address and phone number is
    in the MEMBERS.TXT file for any correspondence, or even better forward
    the information to ICTARI so that  all  of the members can have access
    to it.
    ----------------------------------------------------------------------
    To:     ICTARI
    From:   Paul Laddie Aka BYTEMAN

    I have recently started  writing  a  disk  copier  & formatter, at the
    moment I  am writing the  basic  framework  to  copy & format disks, I
    will design the interface later, but  I have encountered a problem, is
    it possible to format a disk with 11 sectors per track using the XBIOS
    10 (flopfmt) routine, I cannot  get  it  to  do  this at the moment, I
    would appreciate anybody's help on this.
    ----------------------------------------------------------------------
    To      ICTARI
    From    PoshPaws

    RS232 Bugs:
    Most versions of TOS have a  problem  with Hardware Handshaking on the
    RS232 port. The RTS/CTS routine can be assumed not to work properly on
    almost all TOS versions. This is the only RS232 bug that I know of and
    has many AUTO fixes in PD. I think it caused a raising and lowering of
    RTS/CTS on every byte sent,  rather  than  at  high and low tide marks
    (buffer nearly full/nearly empty).

    Falcon Compatability:
    The main points to note about the  Falcon  are that LineA is not fully
    implemented for modes above 16 colours and that the "guarenteed not to
    change" variable for the memory configuration is not usable as a guide
    to memory fitted as it equates to  256K on 'all' Falcons. Use Memtop &
    Membot instead if you need to know what memory is fitted.

    Most other things work O.K.  although  the lowest frequency setting of
    STE DMA Sound will produce silence on  the Falcon. Use the next higher
    frequency.

    Exceptions use a larger stack  space  so  always  return using RTE and
    most importantly DON'T USE  SELF  MODIFYING  CODE (or Inline parameter
    passing!) as the 68030  has  separate  data  &  instruction caches, so
    won't know if instructions have been changed on the fly.
    From memory, that's it - send me a Beta test if it's any help.

    Sub-routines:
    I notice you say to save  and  restore  all registers used within sub-
    routines, but I have  found  it  better  to  write all sub-routines to
    follow Atari's own philosophy  -  Use  A0-A3/D0-D3  freely in any sub-
    routine (as TOS does this) and  make all library sub-routines save any
    registers they use above  this.  That  way  you  know,  no matter what
    library routine you pull in, you  only have to worry about A0-A3/D0-D3
    getting corrupted, anything else is safe!

    What I want:
    I want to know anything at  all  about  SPEEDOGDOS Fonts; how the font
    files are made up and what  the  new  commands actually do. I have the
    official Atari developers book, but it's written by a Techno Boffin in
    shorthand!  I  also  have  the   Hisoft   book,  but  that's  just  an
    programmer's translation from Techno Boffin into standard Font Jargon!
    I also want a SPEEDOGDOS driver for either a Canon BJC-600 or an Epson
    LQ2550, but I suppose I will just have  to wish. How about info on how
    to make *.SYS drivers (old and new)?

    Why don't we get the info  we  need  to  keep  to their rules. IS THIS
    REALLY TOO MUCH TO  ASK?  -  ATARI  SAY  YES  -  ALL  THE ABOVE IS NOT
    AVAILABLE!

    End of Whinge - End of Whinge - End of Whinge - End of Whinge

    ICTARI 11
    =========
    To:             Mic Barnard
    From:           Simon Rigby
    Subject:        SetScreen

    In answer to your question the BIOS  does NOT recognise the setting of
    either Physical or Logical Screens and  will  continue to write to the
    PHYSICAL Screen it started with. Only  GEM  &  LineA will write to the
    LOGICAL Screen! (Also you do not  need  to  wait for Vblank before the
    change as it will do that as part of the call).

    Now, to tell the BIOS that you  have changed screens, you need to pass
    the resolution as something other than  -1.  Even  if you use the same
    resolution as it's currently in, it  will update the BIOS. The problem
    with that is that it also  clears  the  (new) Physical Screen and will
    still only write to the Physical Screen.

    Subject:        Assembly.

    BSR xxx   always uses 18 cycles on the 68000.
    JSR (Ax)  takes 16 cycles but you have to load Ax.
    JSR xxx.W takes 18 cycles  but  the  address  is  in the bottom 64K of
    memory.
    JSR xxx.L takes 20 cycles and  is  the  only viable alternative to bsr
    for single sub-routine branches.

    Note: If you write a sub-routine, it  is because more than one part of
    a program is likely to use it.  This makes it potentially similar to a
    loop in large programs, as it may be used many times.

    Your comments on addq #x,Ay  are  correct  but  add.W #x,Ay is quicker
    than add.L #x,Ay.  Comments  on  clr.l  $xxxx  &  move.l  #0,$xxxx are
    correct. Sorry for any confusion!

    To:     All
    From:   Simon Rigby

    For those of you that use  graphics  routines with integers, here is a
    quick outline of how to do integer square roots.

    1]  Take a Long Number in d1 & d2
    2]  Put a one in d0
    3]  Test if d1>4
    4]  If yes, shift d1 right by two, shift d0 left by one, goto step 3
    5]  d0 now contains first guess (word size)
    6]  Put d0 in d3 for later comparison (d3 is last guess)
    6]  Put d2 in d1
    7]  divide d1 by d0
    8]  Add Answer.w from step 7 into d0
    9]  Shift d0 right by one (Average of two answers)
    10] if d0=d3 then goto step 13 answer is d0
    11] if d0=d3+1 or d0=d3-1 then goto step  13  - d0 is less than 1 from
    answer
    12] goto step 6
    13] STOP answer is in d0

    Hope this helps someone - its all I've got time to give right now!

    P.S. NewTwist still bombs if you leave it long enough, something to do
    with the text buffer overflowing I think?!.

    Si(gh).
    ----------------------------------------------------------------------
    To ICTARI
    From John Phillips

    WOOD LICE.   ICTARI 7

    This sending wood lice through the mail has got to stop. It is illegal
    to post any item  that  is  likely  to  alarm, discomfort or otherwise
    embarrass one of Her Majesty's mail carriers. A treasonable offence if
    I'm not mistaken.

    Tangents and Splines.  ICTARI 8

    Tangents are something I  wouldn't  want  to  touch  with a bargepole.
    There would appear  to  be  two  main  approaches  to  this, the first
    analytical, the second iterative.  The  method  will vary depending on
    what you are trying to do - draw a  tangent at a point ON the curve or
    draw a tangent  from  an  outside  point  TO  a  curve.  The following
    considers the first case only.

    The analytical approach  is  reasonably  straightforward  but  is only
    possible if  the  curve  has  been  generated  from  a  known function
    (ideally expressed as a power series).  If  it  is then it should be a
    simple matter to form enough of  the derived function to calculate the
    tangent accordingly. Any  basic  text  on  calculus  will  explain the
    method. Certain curves have  properties  that  mean  you won't need to
    resort to calculus. The normal to a curve passes through the centre of
    curvature for that point, so with any  curve  for  which the C of C is
    known, the slope of the  normal  can  be easily calculated. This would
    obviously be the preferred  method  for  circles  or  arcs of circles.
    Again any text on analytical geometry will give details.

    The iterative approach would require  only  the  set of defined points
    that make up the curve  and  a  good  guess  to  start things off. One
    approach might involve  progressively  adjusting  the  position of the
    guess line until the number of  pixels  both  to the right of the line
    and left of the curve is  zero  (or whatever). A second approach might
    be to draw a chord  through  the  starting point and some neighbouring
    point and then moving a line  parallel  to  this until it just touches
    the curve, this will then define a second point with which the process
    can be repeated to a limit.  Or  again  you  might like to try fitting
    circles to the curve in the  required  region  and using the centre of
    curvature properties.

    The core of any of these methods would involve developing a routine to
    find the intersection(s) of a line with a curve.

    All these processes  would  be  very  hit  and  miss  and  only really
    suitable for well behaved functions  (something  that is nicely convex
    would be ideal), The whole process  would  be fraught with danger, not
    the least because this  requires  floating  point arithmetic acting on
    sets of purely integer values. How  you would cope with singularities,
    assymtopes, points of inflection, and re-entrant curves will also take
    a lot of thought. As I say, not something I care to get involved in.

    I've seen some code for  generating  spline curves somewhere, I'll try
    and sort it out for next month if I can find it again.

    W_VDI109.GFA   ICTARI 10

    The whole of the VDI 109 routines in this program can be replaced with
    the single command RC_COPY.  GFA  supplies  this  command (designed to
    complement the RC_INTERSECT  function)  for  exactly  this  purpose of
    redrawing windows. Copying from screen  to  memory is even more easily
    accomplished in this example by dumping the whole lot with BMOVE. Note
    that RC_COPY only operates on screen  size blocks, for other sizes you
    could use  the  VDI  version  of  the  BITBLT  command  (the  one with
    s_mfdb(), d_mfdb(), p()) instead.

    The memory handling is very suspect  and  will  not operate in the way
    the author intended. In the real world   you could expect all sorts of
    trouble if window number  1  is  closed  and  there are other programs
    claiming memory in the system.

    Watch out for the typo in line 139.

    I've dug around for a big chunk of  code  to send you and have come up
    with the inevitable  Mandelbrot  thing  called  MANIBROT.GFA. This was
    written in pre TOS 1.4 days and  includes its own FSEL routine, I just
    couldn't take the ATARI mess of  a  file  selector any longer. This is
    less of a problem now  that  alternative  file selectors are available
    and  the  program  would  probably  be  better  without  it  nowadays.
    ('Selectric' looks as if it  will  be  good,  but it still has obvious
    bugs and I don't trust it at present - version 1.10).

    Same applies to the GEM Alert  boxes  which  are not very adaptable so
    I've provided my own version sfbox().  There should be plenty of other
    routines of  interest  to  GFA  users,  sorting,  directory  handling,
    formatting, the IFF format (Degas  .BL1)  etc. though I'm afraid there
    is not much in the way of  comments,  I  rely far too much on variable
    names and structure to  make  sense  of  my  work.  Anything you don't
    understand - ask. The code doesn't  really represent the way I program
    nowadays, I've moved much more towards  lower level routines to secure
    better GEM compatibility.

    This program benefits tremendously  if  it  is  compiled.  In fact the
    whole thing could do with a  good  going  over, it's been put together
    from bits and pieces so there are rather a lot of odd little fixes.

    What is the derivation of  the  mysterious  'foobar' so beloved of 'C'
    programmers ?

    */ Thanks for the code John,  we  shall  be publishing it later in the
    year. ICTARI /*
    ----------------------------------------------------------------------
    To: All
    From: Mark Baker

    Anyone who has read the  Compendium  will  have  realised that the key
    shortcuts in the  style  guide  differ  slightly  from  those  used by
    programs like Everest, Papyrus  etc.  These  are following a different
    style guide in  the  German  Profibuch.  A  number  of  people  on the
    Internet are discussing a  single  more  comprehensive style guide. If
    you want a say in this  and  have  an  Internet mail facility, send an
    email to :-
                            major-domo@world.std.com
    with message text
                            subscribe gem-list my_internet_address

    This will put you on a mailing list  so you will receive copies of all
    mail sent to the list.  To  post  mail  to  the  list and therefore to
    everyone on it, send an email to :-

                            gem-list@world.std.com

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