
     ICTARI USER GROUP             ISSUE 39                 October 1996

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

                     *   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 39
                              ==================

     ASSEMBLY        ST Assembly Language Workshop. Chapter 4.
                     Example of constructing a dialog box by hand.

     C               A mousetrap accessory (Squonk).

     GFA             Accessory communication protocol.

     MISC            Tanks game demo.
                     ANSI code text converter program.

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

     ASSEMBLY        ST Assembly Language Workshop. Chapter 5.

     C

     GFA             Text manipulation/search routines.
                     GFA VDI functions.

     STOS

     MISC            Hypertext Markup Text Language - 2.0 Information.

     ----------------------------------------------------------------------
                                   EDITORIAL
                                   =========
     C TUTORIAL
     ----------
     This months installment has not turned up yet, hopefully next month.

     ARTICLES
     --------
     We have got  very  little  for  next  months  disk  so  if  anyone can
     contribute something it would be a great help.
     ----------------------------------------------------------------------
                                 CORRESPONDENCE
                                 ==============
     To: *.*
     From: Pete Bailey

     I  present here a small piece of  code (see C folder) which,  over the
     course  of the last  few  nights,   has  slowly  but  surely driven me
     barking mad (although  there  are those  who  will claim that this  is
     nothing new).  Now, the reason for its existence is this: last weekend
     I spent a pleasant afternoon tidying  up  the  hard drive on my Falcon
     and  trawling through  old  coverdisks  looking  for  useful bits  and
     pieces.  In the course of this  exercise  I found, sitting disabled in
     the  auto folder,  a program called SAFEMENU (sorry  but  the author's
     name escapes me for the  moment;   my  apologies to him). I remembered
     immediately that this was a menu-trapping  routine  (i.e. it makes the
     menus pull-down rather than drop down),  and since I have often felt a
     pressing need for such a thing,  I wondered why I'd  stuck  it  in the
     auto folder of the  hard  drive   and   then disabled  it.  Having re-
     enabled the thing and rebooted,  it  all came flooding back to me. The
     thing works for a  few  minutes,  then  deactivates.   Going  into the
     relevant CPX in the  control  panel  switches  it back on,  but having
     to do that every two  or  three minutes  soon wears thin.  The problem
     may be caused by a bug   in  the   program,   or   it may be caused by
     interference  from   other  programs,   or   it  may  be  a  shareware
     restriction for all  I   know  and  since   I   can't  track  down the
     original,  I can't even  find   out  whether  SAFEMENU *is* shareware,
     but since I'm not using  it  I don't feel guilty.

     Anyway,  I decided on  the  spur  of  the  moment  to  have a  shot at
     writing something similar myself.   Now,  I've  tried this before some
     years  ago.  On that occasion,  I tried to sneak  into  the system  at
     packet-handler  level and my efforts   were   a  dismal failure.  This
     time, I decided to take the  simplest,  most obvious approach  I could
     think of;  I would attempt to use the  vex_butv and vex_motv VDI calls
     to hook into the necessary vectors. I  also decided  to make the thing
     an accessory (my previous  attempt   was  an   auto-folder program) so
     that it could be switched on  and   off  easily,   and  also so that I
     could build into it the   recommended  fix  for  the  double-scrolling
     bug  which  afflicts  later  TOS versions.

     So, what we have is  a  small  C  routine (compiled by SOZOBONX) which
     does the outer-level stuff (initialisation,  event  loop etc) and  two
     small assembler routines which are installed  into  the mouse-movement
     and button-change vectors via the VDI  calls.  Since I  have no useful
     documentation on these calls,  I had  to  figure out  empirically what
     to do to achieve the desired  result  (where "empirically"  means,  of
     course,  by trial  and   error).   To   my  astonishment,  I  actually
     managed to write the thing and  get   it  working in a single evening.
     Furthermore, it works the way  I  feel  comfortable  with:  click on a
     menu title and down pops the   menu,  click  an entry or click outside
     the menu and away  it  goes.   Or  click  and hold to select the entry
     that's under the mouse  pointer  when  you  release  the button - both
     methods work.  Of  course,  if  you  examine  the code you'll probably
     realise that this will cause  problems   for   programs  which use the
     whole  screen  -  painting  programs   etc   -   but  since  it can be
     switched  off   easily   when  necessary,   that  isn't  too  great  a
     problem.  The real fly in   the  ointment   is  this:  it works like a
     charm on the Falcon (where  I developed it), but confuses the hell out
     of my STFM!

     On the face of it,  it seems to me that the two TOSes  (4.04 and  1.02
     respectively) are  handling  their  mouse-clicks   in   very different
     ways. The Falcon seems to  respond  as  soon  as the button goes down,
     whereas on the STFM nothing happens   until  the button goes up again.
     I have tried every strategy I  can  think  of, but I simply can't find
     one which works reliably  on  the  STFM,  let  alone  one  which works
     consistently on both machines.  Can anyone   shed any light on this? I
     only code assembler occasionally (to keep my hand in),  but there must
     be some experienced vector-snatcher out there  who  knows  how to make
     this   work.   I   would   also    value  opinions  on  the  following
     questions:

     *    Is this a sensible,   safe  method  of  tackling  the job,  or is
     there some nasty, lurking problem  which  simply hasn't occurred to me
     yet?

     *    Having played around  with  the  program  for  a few nights, I've
     found  that  it,  too,   suffers  from  the  same  problem  of  sudden
     disablement  as SAFEMENU  (worse  still,   it  refuses   to  re-enable
     without  a reboot).  It  seems  to  be  caused  by running  particular
     programs  which,  presumably,   pinch  the  vectors  back   and  don't
     bother  to restore mine.  Or perhaps something is  provoking  Gem into
     resetting the vectors.  In  any  event,   is  this  approach  to menu-
     trapping ever likely to work reliably,  or is it as  totally misguided
     as I'm beginning to believe it to be?

     *    I  know that,   in  an  ideal  world,   I should  be  considering
     XBRA'ing  my  vectored routines,   but  this  is  still  a  quick  and
     dirty piece of code at the moment. Is it worth losing sleep over?

     *    In Katherine  Peel's  book,   (under  vex_motv  and vex_butv) she
     mentions disabling interrupts.  Does  she  mean  while  installing the
     vectors,  or for the duration of  the  vectored routines,  or both? At
     the moment,  the program doesn't explicitly disable interrupts at all,
     and so far it hasn't caused any  problems (probably would if I jiggled
     the mouse enough at a crucial moment).

     *    Ms Peel also  suggests  saving  and  restoring  registers in  the
     vectored  routines.   My   program   does   this   for   safety,   but
     experiments have shown that the Falcon,  at least,  really  isn't that
     fussy. Maybe I was just lucky.

     I've  included  separate  notes  on  program   functioning   with  the
     source.   Incidentally,    I    have    noted   the    recent   Ictari
     correspondence   concerning  mixed   C/Assembler   programming.   This
     program is such a program,  and  with  SOZOBON C in-line  assembler is
     also possible (with care). If anyone  wants  to know more I'd be happy
     to  oblige,   but  what's  possible  with  SOZOBON   ain't necessarily
     possible with Lattice or  whatever,   so   it   probably wouldn't help
     much.

                                     -=*=-

     To: *.*
     From: Pete Bailey (again)

     Sorry  to  go on at  such  length,   but  this  is  something  I  feel
     strongly about.  Please,  PLEASE, ***PLEASE***,  let's all support the
     new Atari Computing magazine  and  help  to  make  it a  success. I've
     already placed my subscription  -  I  hope  that  most,   if  not all,
     Ictari members will do the same.   No,   I'm not Joe Connor's mum, and
     I'm not Frank Charlton's hairdresser -  it's  just that if I  have  to
     face the rest of my life without the  prospect  of  a proper,  printed
     Atari magazine to look forward to  then I  really will  go  incurably,
     terminally,   barking  mad  (see  previous  section). We wouldn't want
     that now, would we? The  last  time  they  tried   to   put  me  in an
     asylum,  I got  thrown  out  for  weird behaviour.
     ----------------------------------------------------------------------
     To: *.*
     From: Kevin Cooper

     Subject DLL's
     -------------
     DLL's, I think they are a  great  idea,  after looking at Picpac I had
     come across a similar  idea  and  set  up  some  research, could I get
     information on file formats and  the  answer  is  yes. I have gained a
     number of books from the library on file formats detailing 80 (yes 80)
     different types which could  be  used  as  DLL  modules.  These are of
     various types which consist of Database, spreadsheet, word processing,
     graphic, sound, movie  and page description.  This I think is an ideal
     starting point for the file format side of DLL's as a programmer never
     need worry again. Now the  question,  the standard graphic format will
     be the standard device  independent  format  but  what is the standard
     spreadsheet format, or word processor format, the DLL must convert the
     input file into a standard but what will it be ?

     To: *.*
     From: Kevin Cooper

     Subject: Internet HTML/VRML

     HTML is a known language, the  Atari  platform  like most others has a
     HTML browser but  the  new  standard  VRML,  a  fully  3D internet has
     arrived and only a few  systems  have  browsers,  I have come across a
     book from the library on  this  new  world  and  I am very interested,
     what's more there is a  CD  on  the  back containing example files and
     source code to different parts of  a  VRML browser.  What do you think
     of a VRML browser, would it  be  worth  me implementing ? It took ages
     for the Atari platform to get a HTML  browser, do we want to be in the
     same situation for a VRML browser.

     To: Stos users
     From: Kevin Cooper

     Subject : Extensions

     I am planning on making an extension which would mainly revolve around
     graphics. For example  I  have  made  a  texture  mapping  routine but
     currently it is in pure STOS  and  slow  but will be in assembly soon.
     Are there any graphic orientated commands you would like, if so say in
     Ictari.

     To: *.*
     From: Kevin Cooper

     Looking at CD rom compilations and seeing the amount stored is amazing
     and I would like to make my own CD but prices are 500 and upwards for
     a CD writer and I am already  thinking of getting a syquest removable,
     then I thought why not  combine  the  two,   would anyone out there be
     interested in 135MB of data for around  20  ?  In the same way as you
     would buy a CD ROM.   On  one  cartridge  you  could get all issues of
     Ictari with all  programs  compiled  so  there's  no  need  to run the
     interpreter/assembler and  with all  issues  of  Stosser, AEO, etc. Or
     just 135MB of  themed  PD.  I  could  easily  do  this  if  enough are
     interested.

     To: *.*
     From: Kevin Cooper

     While browsing the Internet I came  across an unofficial Jaguar server
     kit, it enables you to program  the Jaguar, I'm thinking of getting it
     myself, I'll give you more information  if  I  do. Maybe now some real
     programmers can produce for it.

     */ What do other members feel  about  a  VRML browser for the Atari, I
     personally think it would be  an  awful  lot  of  work for very little
     reward considering the dwindling number  of  Atari platforms using the
     InterNet, I suspect that the PC has  cornered the market in this area.
     What do other members think ?  ICTARI /*
     ----------------------------------------------------------------------
     To: All
     From: Mrten Lindstrm

     INTERNET
     ========

     I too have now got Internet access. For the next few months you should
     be able to reach me on

             marten.lindstrom@skelleftea.mail.telia.com

     I will however probably soon change  to another Internet provider (and
     another e-mail address), since there is a healthy price war now raging
     in Sweden, and my current provider doesn't seem to keep up.

     You may already be fed up with  all the talk about Internet, showering
     over you from everywhere. But it really IS fun. I found a childish joy
     just from clicking myself from  Web  page  to  Web page, linked into a
     seemingly endless tree or ...  well,  hmm, WEB, and physically located
     on servers all over the world.  One  moment  in Sweden, then one mouse
     click and I am in Australia or somewhere else. And all of this for the
     cost of a local telephone call (plus a fixed monthly fee of course).

     If you can't find any more interesting links to click on, then turn to
     a search engine. I tried feeding the word "ictari" into the Alta Vista
     search engine and a blink later it had searched its memory (physically
     located in the USA) and up on my screen here in Sweden come 8 links to
     the pages it could find in the  world, that contain the word "ictari".
     As it turns out, 5  of  them  were  actually  the Ictari pages of John
     Levon, but there were three others - one in the UK, one in the Nether-
     lands and one in Germany - with links to John's pages.

     To: John Levon and everybody else

     THE CHARACTER SET OF HTML
     =========================
     Viewing the Ictari web pages, with my MS Windows browser, I found that
     some characters didn't look right. As  you  might guess these were the
     characters in the second, non-ascii, half of the Atari character set -
     including British pound signs and  the  ''  and  ''  I use in my own
     name. When viewing the same  pages  with  the  Atari browser CAB under
     Gemulator, however, pound signs and my Swedish name looked OK.

     So is there no standard for these characters in a HTML text?

             Yes, there is:
             The character set of HTML is the "ANSI" (ISO 8859-1) set!!!
             (I.e. the character set used by, among others, MS Windows)

     But is the Atari browser then  bugged, since it shows non-ANSI, Atari-
     specific, characters OK?

             No, CAB (and its old version, HTML Browser) correctly converts
             all defined  ANSI  characters  into  Atari  equivalents before
             displaying them. The thing is  that characters 128-159 - among
             which Atari ,  and  happen  to  be - are NOT defined in the
             ANSI set, and CAB chooses to simply display them untranslated.
             Since this  is  what  the  Windows  browser  does  too,  these
             characters will look different  under  Windows than under TOS.
             (I personally would  have  preferred  them  to  be interpreted
             according to the almost-standard,  Microsoft Windows extension
             to ANSI, but there isn't much to  say about how CAB deals with
             them.)

     On closer  inspection  I  did  find  other  characters  that  were  as
     corrupted in CAB as they were in  my Windows browser; - e.g. the over-
     line character "" (Atari number 255) displayed as "" in both.

                            ____ THE SOLUTION: ____

     Simply convert any and all Atari characters to ANSI equivalents before
     placing the HTML page on the Web.
     I have sent in a simple  conversion  program  -  ANSIFIER - to do just
     this.

     (Actually there is one  other  solution,  namely  to use the character
     "entities" of SGML and HTML: e.g.

        &pound;    for    
        &macr;     for    
        &aring;    for    
        &ouml;     for    
        &Ouml;     for    

     Observe the letter case. See further in HTML documentation.)

     To: All

     HTML versions
     =============
     Trekking the web I found  out  that  the HTML 3.0 draft specification,
     published in  Ictari34,  has  been  DROPPED  by  the  World  Wide  Web
     Consortium. Apparently it  was  too  incompatible  with  HTML 2.0 (?).
     Instead there  is  now  a  HTML  3.2,  which  isn't  final  either but
     presumably much more so than HTML 3.0  was. If, on the other hand, you
     want to be 100.0%  certain  of  no  changes,  then you should probably
     stick with HTML 2.0 which is still the only official standard.

     I send in the reference documentation  of  HTML  2.0 and HTML 3.2 as I
     found them on the Web. Note however that the HTML 3.2 spec. is in HTML
     format.

     For more info, go to the World Wide Web Consortium at -

                     http://www.w3.org/pub/WWW/

     To: Jim Macleod
     From: Mrten Lindstrm

     OFF-SCREEN BITMAPS
     ==================
     Are you referring  to  the  off-screen  bitmaps  provided  by the "VDI
     Enhancer" (that came with Ictari 34)?

     These are opened in much  the  same  way  as  a normal, on-screen, VDI
     virtual workstation, but there are some differences in how you fill in
     the VDI arrays before making the trap #2 call.
     In particular contrl[5] must be set =1 for v_opnbm as opposed to 0 for
     v_opnvwk, and contrl[3]  must  be  set  =20,  since  v_opnbm  takes 20
     intins. (I.e. in Devpac assembly:
          move.w #1,contrl+10  ,
     and  move.w #20,contrl+6  .)

     Also, as with ANY use of  multiple  VDI workstation, you must remember
     to always set the correct  workstation  handle, when switching the VDI
     output between them. (To  the  extent  that  you  use  the Devpac pre-
     fabricated  VDI  macros,  just  make  sure  that  the  WORD  at  label
     current_handle always contains the, well, current handle.)

     If you still haven't  been  able  to  make  off-screen bitmaps work, I
     could send in a fuller description for assembly programmers.
     GFA Basic and C programmers  have  hopefully  no further problems with
     what has already been said regarding these languages?
     ----------------------------------------------------------------------
     To: ICTARI
     From: Giles Greenway

     I'm just writing to tell you that  a  basic  ICTARI Web page is up and
     running. The URL to my page is :-

             http://www.elis.demon.co.uk/

     The ICTARI specific stuff is all at :-

             http://www.elis.demon.co.uk/ictari/ictari.htm

     which avoids all the other stuff on my page, including my odd sense of
     humour ! The page starts with a  nice scanned ICTARI logo along with a
     picture of an ST. After that there's a brief introduction and links to
     the e-mail facility and the download section. Next I just included the
     passage from the disks about how the postal subscription is organised.
     The download section follows with all the  issues for 34 to 38 in .ZIP
     format. They come with the contents section  of each issue in a nicely
     tabulated form. The section starts  with  the  most recent issue, then
     works backwards. The top of the section  also has links to go directly
     to the earlier issues further down. I've  still got 4Mb free, but if I
     start to run out of space I'll probably cull some earlier issues. Some
     more general links might be a  nice  idea,  perhaps to the Sozobon and
     GCC binaries,  and  programming  tutorials  on  the  'net.  I'll  also
     investigate    a    way     of     linking     directly      to    the
     comp.sys.atari.programmer group.

     Even with 'net access, ICTARI still has  a  role to play. With all the
     example files and tutorials it would  be  too unwieldy to get the same
     effect by e-mail or newsgroups alone. 250Kb binaries are a bit big for
     alt.binaries.atari ! ICTARI seems  a  good  compromise between a 'zine
     and a discussion group. Perhaps  the  site  will allow everyone to cut
     down on postage  and  disks.  It  should  certainly  draw  in a larger
     membership. Has no one suggested this  idea  before ? How many current
     subscribers have net-access ? To  date,  I  have announced the site on
     the comp.sys.atari.st and  comp.sys.atari.programmer  newsgroups. Some
     of the people with pages containing links will also give it a mention,
     maybe it will be featured  in  "Atari  Computing" and "Current Notes".
     One day I will get round  to  registering  with some search engines. I
     haven't even put in a web  counter  yet.  Tell me if there is anything
     about the page you would like to change.

     */ Thanks for the information and the work you have put into this. Yes
     the idea of a Web page has  been  suggested before but as I don't have
     access to the Net and no one else at the time volunteered to provide a
     page, it did not progress further.  The  only thing that concerns me a
     bit is that programmers may  download  the  magazines and use the info
     without sending anything  back  to  ICTARI  for  future  issues. As we
     depend almost entirely on members  contributions  we would (and are in
     fact) run very short of material for  the  mag if no one provides any.
     It might be useful to include a  BOLD  message  on the Web page to the
     effect that anyone who downloads  ICTARI  data should also return some
     letters,  programming  queries,  source  code  or  even  just  general
     programming information that can  be  used  for publication. I presume
     that if this happens you would be good enough to send it on to me on a
     disk.

     The membership numbers have  dropped  considerably  over  the last few
     months but of the  remaining  members,  about  6  have provided e-mail
     numbers although I suspect  a  few  more  probably  have access to the
     Internet at work or University.  ICTARI /*
     ----------------------------------------------------------------------
     To: Peter Hibbs
     From: David Preston

     WordGrid game

     Thanks for your comments  regarding  WordGrid.  Hmmm...  It's all very
     well asking for feedback and  bug  reports  and stuff, but then you've
     got to set about sorting them out!  So  far as the main dialog goes, I
     think it's all down to me  using  'form_do'. This is because my skills
     with the AES are limited to say the least, and don't yet stretch to my
     own dialog-handling routines. I'm going to  have to figure out partial
     redraws and the like!

     The printing problem is a bit more  of  a mystery however. It works ok
     on my system (STe, TOS 1.62)  and  your  problem  comes  as a bit of a
     surprise. It's probably down to  extreme  laziness on my part. Printed
     output was only added  as  an  experiment,  using 'lprint' statements,
     (no, I didn't bother opening a channel to the printer) and was left in
     because it seemed to work. I'll rewrite  that  bit and see if it fixes
     the bug you've identified.


     To: Robert Manning

     I share  your  interest  (Ictari  38)  in  background  info  about the
     development of progs. I wasn't particularly specific about what I used
     for WordGrid (see  above),  but  it  was  written  in  Power Basic and
     compiled (I think) using Hisoft Basic 1.  Why? Well, I had Power Basic
     and then found the coverdisk  version  of  Hisoft  Basic at a car boot
     sale, and since they are compatible  I  used the Hisoft Basic compiler
     to compile it.  The  resource  file  was  constructed using K-Resource
     (another coverdisk). I prefer K-Resource  to WERCS but that's probably
     just me. The resource was a bit  of  a b*st*rd to get right because it
     contains so many separate objects  -  each  letter  in  the grid is an
     object, 144 of them, for example.

     Although that isn't the complete history  - the program started out in
     Turbo Basic on the 800XL. (By the way, just in case anyone didn't know
     (and is interested), Turbo  Basic  was  GFA Basic's grandfather. Frank
     Ostrowski wrote Turbo Basic as a  (very major) improvement over the 8-
     bit's built-in Atari Basic while remaining completely compatible and a
     direct replacement, and released  it  as  freeware.  That impressed so
     much that he was invited to write  a  Basic for the new 16-bit Atari -
     the ST - and GFA Basic was the result. And here's something that not a
     lot of people know (you'll  have  to  fill  in  your own Michael Caine
     impression) - Turbo Basic added  procedures, which the original didn't
     have, and used 'ENDPROC' to  terminate  each  one. Now then, GFA Basic
     uses 'RETURN' to end procedures, but if you enter 'ENDPROC' (yes, into
     GFA Basic), it will be interpreted  as  'RETURN'! And no, I don't know
     _why_ because  surely  porting  a  program  written  in  6502 assembly
     language wouldn't have  been  much  help  in  developing  one in 68000
     code!)

     Then there was a version in  STOS,  which still exists if anyone would
     like a look. When I have a programming idea I stick with it! If I ever
     get past the stage of having a head full of cotton wool as far as C is
     concerned there will probably be a version  written in C as well, some
     time in the future...

     To: *.*

     On the current thread of magazines, I have to admit that when I bought
     the STe I stopped getting Page  6's  New Atari User. Whatever happened
     to that one, anyone know?

     */ In the light of your comments  I  have  done a bit more research on
     your WordGrid program printing problem. When  I click on the 'Printer'
     button the first dialog  box  appears,  ("Please  ensure printer is on
     line") but when I click on 'OK'  the  "Device I/O error at Line 491 on
     #256" appears at the bottom of  the  screen.  It would appear that the
     problem only occurs when the AUTO folder MORTIMER program is resident.
     On further investigation I found that  if I switch the printer spooler
     facility off within MORTIMER, your  program  then  prints OK. Why this
     should make a difference I  have  no  idea.  Anyway, hope that helps a
     bit.  PDH /*
     ----------------------------------------------------------------------
     To: Mrten Lindstrm
     From: Peter Hibbs

     I noticed in the  source  code  for  your  assembler programs that you
     write the  register  names,  A0-A6/D0-D7/SP,  etc  in  capital letters
     rather than lower case  while  the labels, comments, instructions, etc
     are all in lower case letters.  I  am  just curious to know the reason
     for this since  using  upper  case  means  using  the  shift key quite
     frequently which slows  down  the  typing  and  I  can't  see  that it
     improves readability of the code at all,  just the reverse in fact (in
     my opinion). I know it  makes  no  difference  to the operation of the
     program but if there is any other logical reason I would be interested
     to hear it.

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