
     ICTARI USER GROUP             ISSUE 30                    January 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 30
                              ==================

     ASSEMBLY        ReStart TSR program.
                     XBRA Protocol information.

     C               Disk catalogue program source code.

     GFA             Mrten Lindstrm: An introduction to GFA programming.

     BASIC           Lottery program.

     STOS            Seapest game source code.
                     Tiny picture format loader routine.

     MISC            Cookie Jar list.
                     Mark Baker, SpeedoGDOS example code.
                     Current membership list.

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


     ASSEMBLY        Saucers game.
                     Line drawing routines.

     C               SCSI Interface Library for C programmers.

     GFA             GFA Interface dialog utility program.

     STOS            Polygon demo program.

     MISC            SCSI Frequently Asked Questions.
                     Pexec function Cook-Book.

     ----------------------------------------------------------------------
                                   EDITORIAL
                                   =========
     MEMBERSHIP
     ----------
     Another new member has joined the group this month, welcome to him.

     ENVELOPES
     ---------
     As most of you will have noticed,  this month I have printed the names
     and addresses directly  onto  the  envelopes  instead  of using sticky
     labels which did not work very  well.  I  am using the K-Data database
     program to store the  info  (after  several  days  work)  and my Laser
     printer to print  the  envelopes.  As  I  have  had  to  enter all the
     information into the  data  base  again,  perhaps  everyone could just
     check that the addresses and  postcodes  are correct (that is assuming
     you have received this disk in the first place).

     DISK CATALOGUE PROGRAM
     ----------------------
     In this issue Lee Russell has provided his disk cataloguing program in
     C with a lot  of  useful  information  on  the  program structure. The
     document files were provided in Protext  format  and we have left them
     in this format to retain the  text  attributes, layout, etc. If anyone
     needs an ASCII version of the  files, just send a disk. (Incidentally,
     the program does work OK in High Rez).
     ----------------------------------------------------------------------
                                 CORRESPONDENCE
                                 ==============
     To: Anyone
     From: Owen Rogers

     About 3 weeks I decided to go  out  and  buy Gfa Basic 3 for myself. I
     knew how to program in STOS so I  just read through the manual and now
     I am on to displaying and using dialog boxes. I tried making a program
     and the buttons on the dialog worked  fine but I could not type things
     into the editable strings. I used the following bit of code :-

     form1%=0
     comline%=1  !  EDIT
     icon1%=2    !  ICON
     gar%=3      !  STRING
     oper%=4     !  STRING
     icon2%=5    !  ICON
     ru_ttp%=6   !  STRING
     okay%=7     !  BUTTON
     cancel%=8   !  BUTTON
     ~RSRC_FREE()
     ~RSRC_LOAD("F:\GFABASIC\RUN.RSC")
     ~RSRC_GADDR(0,0,tree%)
     ~FORM_CENTER(tree%,x%,y%,w%,h%)
     ~OBJC_DRAW(tree%,0,1,x%,y%,w%,h%)
     REPEAT
       ex%=FORM_DO(tree%,0)
     UNTIL ex%=okay% OR ex%=cancel
     ~RSRC_FREE()

     Can anybody tell me what  I'm  doing  wrong?  I  use the ORCS resource
     construction set.
     ----------------------------------------------------------------------
     To: ICTARI
     From: John Oakes

     Could you advise me on  which  book  I  can obtain for Assembly 680x0,
     with reference on how to construct or design a program.

     */ I have two books on Assembly, "68000 ASSEMBLY LANGUAGE PROGRAMMING"
     by Leventhal (ISBN 0-931988-62-4) and  "68000, 68010, 68020 Primer" by
     Kelly-Bootle and Fowler (ISBN 0-672-22405-4)  which are quite good but
     neither are Atari specific.  In  issue  8  we  reviewed 18 Atari books
     which may also be of interest. Do  you  want to know how to program in
     Machine Code from scratch or  are  you  familiar with machine code and
     want to know how to use it in the Atari environment, we may be able to
     provide some articles for future  issues  on  this subject if there is
     any interest.  ICTARI /*
     ----------------------------------------------------------------------
     To: *.*
     From: Mrten Lindstrm

     10 sectors per track on PC's
     ----------------------------
     I have always thought (and still do) that formatting standard DD disks
     with 10 - rather than 9 - sectors  per track is quite OK to do (giving
     you 800 rather than 720 K). The  data  will rest as safely on the 10th
     sector as on  the  9th  (unlike  using  more  than  80  tracks). As is
     exploited by some ST programs,  there  is  actually  even space for 11
     sectors per track but this IS to  push things a bit far, requiring you
     to reduce  the  inter-sector  space  below  recommended  minimums  and
     risking problems with drives  whose  rotation  speed deviates from the
     standard 300 RPM.

     However, trying to read the Ictari 27  disk  on  a PC gave me a shock!
     The root directory looked OK, but  when  trying to open sub-folders or
     reading the ICTARI.TXT file, it all  looked  like garbage. And all the
     PC programs that I consulted  told  me  it  WAS!  -  Some of them even
     helpfully offering to "repair" the  disk  by  deleting a few directory
     entries. (This  was  on  a  Windows  95  system  with  all  the latest
     Microsoft programs). But, hands  trembling,  inserting  the disk in my
     trusty old ST showed my everything was still OK. (Phew)

     THE SOLUTION:
     
     After clearing the first byte - $F9 - of the FAT (I did the same thing
     in both FAT copies) the PC too was smart enough to see what my ST knew
     all along: the disk was OK.

     (The FAT - File Allocation  Table  -  contains information on how each
     DOS data unit (called "cluster")  on  the  disk  is used for files and
     folders. There are, for safety, two identical FAT copies maintained).

     EXPLANATION:
     
     The first byte of the FAT is,  on  PC's, a media descriptor byte which
     is $F9 for a standard  9-sectors-per-track  DD disk. The following two
     bytes are filled with $FF  but  ignored.  On  ST's all three bytes are
     ignored and normally cleared (zeroed)  when  formatting, so the reason
     they were NOT cleared  on  the  Ictari  27  disk  must ironically be a
     misguided attempt by the program,  used  to  format this disk, to make
     the disk "PC compatible".

     When the PC finds a cleared media descriptor byte, but apparently only
     then, will it go back to  the  boot  sector information (which is what
     the ST always use) to find out how the disk is REALLY formatted.

     (It surprised me that the PC  was  too  stupid  to try the boot sector
     information even when realizing that the disk looked like a mess, read
     as 9-sectors-per-track).

     The theoretical problem would be  if  some  DOS version NEVER uses the
     boot sector information, but I think  most  or all DOS versions should
     be at least this smart. Anyone with other experiences?

     (An even better solution would have been a PC media descriptor for 10-
     sectors-per-track disks, but, while a  number of outdated disk formats
     - single-sided 8-sectors/track etc. -  are  catered for, there doesn't
     seem be any descriptor for  10 sectors/track. Atari evidently realised
     the idea of media descriptors to  be  obsolete  already at the time of
     the first ST, since they never made use of it).

     HOW TO DO IT
     
     The easiest solution is to avoid formatters that don't clear the first
     byte of the FAT's. (Programmers of  formatters: Always clear the first
     three bytes of each FAT, unless formatting with 2 sides, 9 sectors and
     80 tracks when F9,FF,FF could be used,  or with 18 sectors on HD disks
     F0,FF,FF). The second easiest solution,  if  you have an existing disk
     with this problem (e.g. Ictari 27), is  to use a disk editor (like the
     excellent Knife ST from Hisoft).

     If you don't have a disk editor  that  can  help you find and edit the
     correct sectors,  then  you  can  create  your  own  little correction
     program with the help of the BIOS function RWABS (BIOS 4).

     RWABS(0,bufaddr,1,0,0) - will read the  boot sector (logical sector 0)
     of drive A into the buffer starting at "bufaddr". Make it at least 512
     bytes (a full kilobyte won't hurt either).
     From this, you can find the start sector of the first and second FAT:

     First FAT: Read Intel word  (i.e.  read  word  and  swap its bytes) at
     offset 14. (In practice  this  will  always  be  =1,  but use the just
     mentioned formula to be sure).

     Second FAT: Read Intel word at offset at 22 and add to start sector of
     first FAT. (You could check that the number of FAT copies - in byte at
     offset 16 - really IS 2, which it should in practice always be).

     Then read, change and write the start sectors of both FATS:

     RWABS(0,bufaddr,1,sectnum,0) - to  read  specified  sector  on drive A
     into bufaddr. Clear first byte  (or  first  THREE  bytes) of FAT, then
     call:
     RWABS(1,bufaddr,1,sectnum,0) - to similarly  write the buffer contents
     back to the same sector.

     To: Thomas Nilsen
     From: Mrten Lindstrm

     Thank you for the ZIP deflate info!

     NON-MODAL DIALOGS (= that don't put other processes on hold):
     ------------------
     Regarding your question on how to  display  and use an AES object tree
     (dialog box) in a window:

     - Draw it with  OBJC_DRAW,  just  as  you  would an ordinary ("modal")
     dialog box, only you need  to  do  it  in  response to a window redraw
     event (after creating and opening the  window)  and in a loop, walking
     through the "visible rectangle list" of the window (adjusting the clip
     rectangle of each OBJC_DRAW call)  -  the  way  ANY clean drawing in a
     window has to be done,  in  order  to  avoid overwriting other windows
     that might be partially  covering  the  window.  The visible rectangle
     list is returned by WIND_GET with modes 11 and 12.

     - To handle it  you  cannot  use  FORM_DO,  since  this waits only for
     button and keyboard events related  to  the  dialog box itself and not
     for window (or other message) events.  Instead  you need to write your
     own FORM_DO replacement, centred on  an  EVNT_MULTI that DOES look for
     message events. Button and keyboard  events  can be dealt with through
     calls of OBJC_FIND, FORM_BUTTON,  FORM_KEYBD  and OBJC_EDIT (which are
     used as sub-routines by FORM_DO).

     See chapter 4 of my GEM GUIDE for an example of a FORM_DO replacement.
     (You need to expand the EVNT_MULTI  call  of  this to look for message
     events too). See chapter 3 for  how  to handle AES windows in general.
     (In Ictari 27 and 28).

     The technique for implementing panels,  tool-bars and -boxes and menus
     in windows would probably be similar.

     (Note: none of this requires anything  more  than the basic AES of any
     bog standard ST. The AES  of  Falcons  adds  further functions to deal

     with e.g. tool-bars in a  slightly  simpler  way,  but at the price of
     abandoning backwards compatibility with ST's).

     */ When I format a normal disk (80 tracks, 9 sectors) I use the normal
     Atari TOS (V1.04) which I believe formats  in IBM format. If I have to
     format a disk with  10  sectors  I  usually  use  ACopy which probably
     doesn't use IBM format. I have  also  got  FastCopy which I think does
     use IBM format so I will look into this and try and make the disks IBM
     compatible, are far as possible.  ICTARI /*
     ----------------------------------------------------------------------
     From: Jonathan Leckie
     To: All ICTARI readers

     Hello all, this  is my maiden  message (posting?)  hmmmghh. I  do some
     GFA, and C  and  even  less  assembler and I would  class myself  as a
     beginner so now you know about my frailties and  you have lowered your
     expectations I can start grovelling.

     Question 1: Can  anyone  submit  a set of  working, time-served double
     linked  list handling routines  written in C? I have written a set but
     they, for an  annoying and hidden  reason, refuse to work properly. My
     modules have the following mini. spec. :-

     #define KeyType int

     typedef struct {
       KeyType  key;
       /* program specific data */
     } StdElement;

     typedef struct {
       void       *Next;
       void       *Prev;
       StdElement Data;
     } Node;

     typedef struct {
       Node       *Head;
       Node       *Tail;
       short      NoInList;
     } DblList;

     BOOL DLFull (DblList *DList);
     BOOL DLEmpty (DblList *DList);
     void DLCreate (DblList *DList);
     BOOL DLAdd (DblList *DList, Node *Nod);
     BOOL DLDelete (DblList *DList, int ListPos);
     BOOL DLTerm (DblList *DList);
     StdElement *DLRetrieve (DblList *DList, KeyType Key);

     A set  conforming to  it  would  be  useful, though "beggars can't  be
     choosers" as my great aunt Nellie used to say.

     Question 2: I read a  while ago in Atari World  about a program called
     "UDO" that  converted  TeX, HTML and RTF  formats I haven't  heard any
     more of it, any ideas if it exists and where I can get it?

     Question 3: Is there  a HTML viewer  that views HTML files properly. I
     have HTML-Viewer  0.93  but it does  not cope  properly with some HTML
     ver. 2  commands or simple text effects (</B>bold<B>, </I>Italics<I>).
     I don't have even a  partial  'Net  connection   so programs that only
     work with one will be no use. Any further ideas?

     You can send stuff to me by E-mail but it will take at least 3 days to
     get more than a perfunctory reply because it is my friend's address.

     E-mail: com40020@diana1.paisley.ac.uk

     */ If you track down  the  text  file  conversion  program, I would be
     interested in having a copy. I  get  all  sorts of text files from the
     Public Domain which need to be translated into ASCII.

     Since the ST  Applications  magazine  transferred  to  disk  they have
     provided HTML V0.96 on each disk,  perhaps  this version does not have
     the problem of V0.93, I've had no problems with it myself.  ICTARI /*
     ----------------------------------------------------------------------
     To: Michael Harrop
     From: John Watson

     Thank you Michael for your generosity,  received  the GFA 2 Manual and
     disks, a letter is on its  way (if not already there !).

     To: Mrten Lindstrm

     I thank you for  your  informative  reply  in  issue  29 regarding the
     differences between versions 2 and  3.X  of  GFA Basic and your worthy
     comments on the Pro's and con's  of  Programming Languages in general.
     I started programming in Microsoft Basic on  a 64K MSX and have ported
     the same programs to ST Basic and on to GFA, gradually enhancing them,
     and learning as much as I  was  able  to,  of each variation as I went
     along. As I still have a  lot  to  learn,  I unfortunately do not feel
     like attempting another  language.  I  just  can't  seem  to grasp the
     syntax of C (all those Brackets !), though the structuring of programs
     necessary in C is a very good aspect.

     GFA is also very good on  structuring  i.e.  not allowing jumps out of
     Loops or Procedures with the dreaded GOTO......

     I try to keep to a style of Structured Programming that I learned from
     a book by Mr Peter Bishop published in 1984, his ideas termed Top Down
     Stepwise Refinement entails writing in plain English the objectives of
     the program. Then working up each part into more and more detail until
     the Code itself is written.

     To: *.*

     Does anyone have or is compiling  a GFA Function, Procedure library or
     a common Naming convention  for  program  Variables, Constants, Etc. I
     believe that the GFA User group  has  produced  one. There is also the
     GFAXPERT.LIB  by  Han Kempen (which I have).

     Over the years I have developed  (or  should I say plagiarised) my own
     very small collection, which is available to anyone interested.

     */ We also would be interested to hear about any specialised libraries
     for GFA (or any other language).  ICTARI /*
     ----------------------------------------------------------------------
     To: David Seaman
     From: Jason Railton

     Re: STOS Stock Controller listing

     I tried running your Stock Controller and it wouldn't work.  You use a
     STOS extension I don't have about 46 times.  When I list the program I
     get the words "extension  #M"  (The  MISTY  extension,  I presume?) in
     place of certain  commands.   Unfortunately,  all  I  have  is the STE
     extension - I don't have  an  STE,  but  I  occasionally use the twin-
     joystick reading functions.

     Sorry I can't test the program for  you.  In future though, could STOS
     users state what extensions they've used  in the documentation.  I try
     to avoid them whenever possible,  but  that's  because I like to write
     machine code routines and  load  them  into  STOS  to perform specific
     functions.

     To: Peter Hibbs & Everyone Else

     Re: STOS stuff

     Hopefully this disk should contain some STOS programs from me.  I sent
     them in last month, but  because  Mssr.  Hibbs  is so disarmingly well
     organised, last month's disk  was  already  prepared and chock-a-block
     full and I've had to wait  another  month  to see my name in phosphor.
     Anyway, they were a bit rushed,  so  here's  a bit more information in
     addition to what you'll find in the .DOCs.

     Sea Pest:  Sorry. One of the  symptoms of rushed code is dispiritingly
     poor titles.  Anyway, I read a letter  from David Seaman in Ictari #28
     asking for more STOS code,  so  I  wrote this Minesweeper variant over
     the next few evenings.  It's a  bit  slow  when run from BASIC, but is
     quite playable when compiled.  I don't know if you'll get the compiled
     version as well as the source code,  since  it is a fairly large .PRG.
     If you do, then you won't need  STOS  in  order to run this. I've only
     programmed in the basic  game  mechanics.   Feel  free to embellish it
     with titles and scoring, and send  it  back in to ICTARI.  The listing
     is heavily commented to explain what it does.

     Polydemo:  This  was  only  provided  as  a  compiled  program.  It'll
     probably appear in the STOS section, but  have  a look at it if you're
     into machine code.  It's only based in STOS because it's incomplete. I
     want to eventually get the routines  working in stand-alone code. Then
     again, I might stay  in  STOS  and  just  convert  more  and more into
     machine code as I need to. I've  since improved the routine to provide
     more stipples for  a  much  better  graduated  fill,  and improved the
     intersection and depth clipping functions. */  See next month for this
     one. ICTARI /*

     I intend to write a few  articles  on  how the fill routines work, but
     I'd like to know from Peter Hibbs what  he can fit on the disk.  These
     articles would be irregular, since I  don't  always have a lot of time
     to put things together.  Anyway, the graphics routines are of interest
     to the machine  code  programmer,  as  well  as  the  STOS programmer.
     Unfortunately, they are written as  m/c  subroutines  for use in STOS,
     not as runable .PRGs.  I can  provide  the assembly source code, and a
     STOS listing (containing the m/c in  a memory bank) to demonstrate the
     process, but  would  there  be  room  for  the  compiled (stand-alone)
     version of the STOS demonstration, for m/c programmers?  These can run
     to around 70 or 80K, as you can see from PolyDemo.

     To: Machine Code programmers

     Line-drawing routines
     ~~~~~~~~~~~~~~~~~~~~~
     I would be grateful  for  any  fast  line-drawing  source code you can
     provide me with, or tips on how to  write my own. I need to write some
     very fast, customised line-drawing routines to improve my 3D graphics.
     All my lines are clipped, and I have already written a routine to plot
     lines in the vertical-->45' range.  What I  need is a fast 45' through
     to horizontal line plotter.

     Reading the mouse
     ~~~~~~~~~~~~~~~~~
     Has anyone written a m/c program using  both rasters and the mouse? Or
     read the mouse in ABSOLUTE mode?  I presume I need to use this mode so
     that I can interrogate  the  mouse,  rather  than  having  it occur on
     interrupts (which disturb the rasters).   Incidentally, I don't want a
     pointer on screen.  It's  for  control  in  an  arcade-type game. What
     settings are appropriate for the  mouse  scaling factors in this mode?
     What is the normal scale setting, or  the one that best relates to the
     standard mouse movements?

     Running from STOS
     ~~~~~~~~~~~~~~~~~
     Has anyone tried running a machine  code program in STOS that disables
     STOS interrupts/keyboard/mouse handling, installs  its own, then later
     restores them and returns to STOS?  Or  am I being too ambitious?  I'd
     just prefer to keep my  games  running  from  within STOS because it's
     easier to write title/high score pages in  it than in machine code. Or
     can STOS programs be loaded/run/communicated  with from a machine code
     program?

     I gather from the manual that STOS establishes its own traps, but does
     not in any way affect the existing OS traps.

     Writing STOS extensions
     ~~~~~~~~~~~~~~~~~~~~~~~
     Anyone tried this?  How do you do it?  Or would anyone like to turn my
     3D graphics routines into an extension for me?

     */  I  agree  entirely  that   contributors  should  provide  as  much
     information as possible  about  any  supplied  source code, especially
     extensions used, library files used,  etc,  etc.  I know that this can
     sometimes be very time consuming and  boring  but it does save the end
     user a considerable amount of time  and frustration when trying to use
     the code. I would like to see  a  text file with the source code which
     explains what the code is supposed to  do  and how to use it with some
     simple examples, this would  help  me  when  compiling  these disks (I
     can't try all the code sent in) and  it would help anyone who wants to
     use the code.

     I would be very interested to publish your graphics fill routines (and
     any other stand-alone routines in any  language for that matter). What
     I would prefer (although I  appreciate  that it's not always possible)
     is  to  have  a  stand  alone  runable  program  also  supplied  which
     demonstrates  the  operation  of  the   routine.  This  allows  anyone
     interested in the code to try  the  program  first to see if it covers
     the area of programming in  which  they are interested. The programmer
     should make the program as  small  as  possible  (so  that it does not
     waste too much disk space)  and,  if  possible, should also supply the
     source code of the program itself so  that potential users can see how
     the relevant routines are integrated into a working program.

     I will try and include some line drawing routines on next months disk.
     These are not particularly  fast  but  could  be modified or improved,
     obviously the fastest way to  draw  a  line  is  to  use GEM with NVDI
     running but I guess that is not an option under STOS.

     To read the mouse information direct I  think you would have to access
     the keyboard CPU. There are  various  books  which cover this subject,
     has anyone written any code to do this?

     Writing STOS extensions is not  easy,  perhaps  Martin Cubitt (who has
     written some) can help!  ICTARI /*
     ----------------------------------------------------------------------
     To: David Seaman
     From: David Preston

     STOS Extensions Survey

     I'm intrigued by  your  disapproval  of  the  Squasher.  I've used the
     squasher quite a lot - mainly for screenbanks - without many problems.
     It seems to  work  ok  and  achieves  pretty  good compression ratios.
     Alright it takes an eternity to squash  a file in the first place, but
     once  squashed  it  usually  produces   a   very  compact  file  which
     uncompresses quickly and easily. It  has  run  riot once or twice when
     I've passed duff parameters to UNSQUASH,  but  other than that no real
     problems. Is there some  nastiness  I've  missed?  The Stars extension
     however crashes my compiler - is there anything I should know?

     Stock Controller

     I know I'm a bit dim, but I couldn't identify the problem to which you
     referred in  the  readme  file.  Could  you  perhaps  expand  upon the
     problem?

     To: Mrten Lindstrm

     Yes, thanks, I did  realise  you  meant  both  slider and 'track' were
     TOUCHEXIT objects. I was gobsmacked to  say  the  least when I got the
     slider to actually slide,  it's  small  things  like  that (I find, at
     least) that make programming the enormously rewarding hobby it is. But
     I digress. I now find I'm stuck on something else - I'd like to redraw
     part of a dialog - one  object  and  all its children. As I understand
     things, I do this by calling objc_draw, referencing the parent object,
     but I need to know its x  and  y  co-ords, and its width and height. I
     think I can use objc_offset to establish  its  x and y position, but I
     seem to recall reading somewhere that the  width and height have to be
     read direct from the object structure. Am I on the right track so far,
     and can you offer any advice? Thinking about it as I write, this would
     probably also be involved in the  process  of changing the size of the
     slider to reflect the proportion  of  the  items  displayed, say, in a
     file selector,  to  the  total  number  of  items  in  the  directory,
     probably...?
     ----------------------------------------------------------------------
     To: *.*
     From: Peter Hibbs

     Does anyone  know  anything  about  Terminate-and-Stay-Resident  (TSR)
     programs. In the near future I  want  to  write a program which can be
     called from within any GEM type program  (in the same way as ImageCopy
     or Mortimer do) with a  particular  key combination. The program would
     then need to be able to  display  a  GEM dialog box, load/save to disk
     and output data to the printer (parallel) port. As you can see, I have
     included some TSR source code in  the Assembly folder this month which
     is quite helpful  but  this  program  is  very  simple,  are there any
     problems which might appear in a more complex program. I haven't tried
     writing any code yet but if anyone has had any experience of writing a
     TSR program, I would be very interested to hear about it.

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