
     ICTARI USER GROUP             ISSUE 38                 September 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 38
                              ==================

     ASSEMBLY        ST Assembly Language Workshop. Chapter 3.

     C               Richard Harvey. C Tutorial Part 2.
                     Window dialog system.

     GFA             More font routines.
                     Clipboard functions for GFA.

     STOS            Geometry demo program and code.

     MISC            Beta version of WordGrid game.
                     More Icon images.

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

     ASSEMBLY        ST Assembly Language Workshop. Chapter 4.

     C               Richard Harvey. C Tutorial Part 3.

     GFA             Accessory communication protocol.

     STOS

     MISC            Tanks game demo.

     ----------------------------------------------------------------------
                                   EDITORIAL
                                   =========
     WDIALOG
     -------
     The Window Dialog .LZH file  (in  the  C  folder)  will need to be de-
     compressed before use with a program such as UNLZH172.PRG. We would be
     interested to  hear  if  anyone  successfully  uses  this  code  in an
     application as it looks quite good.

     WORDGRID GAME
     -------------
     David Preston has sent in a  simple  Word  Grid game for beta testing.
     Please send in any  comments  when  you  have  tried  it  out. My only
     comments are that the grid  itself  (in  Hi  Rez anyway) could be made
     larger to make it easier to  line up the words, especially diagonally.
     Also, showing the selected words in  a  small  font size makes it even
     more difficult to pick out the other words, perhaps they could just be
     shaded or shown in inverse video instead. It might be nice to show the
     timer counting up all  the  time  (if  possible)  rather than when the
     puzzle has been completed  and  also  to  refresh  just the word being
     changed rather than the whole form to  stop the flash each time a word
     is selected.

     The only bug I came across  was  when  I  tried to print the data, the
     message - 'Device I/O error at line  491 on #256' was displayed. I was
     using Hi Rez with TOS 1.04.

     ----------------------------------------------------------------------
                                 CORRESPONDENCE
                                 ==============
     To: *.*
     From: Martin Milner

     Here's some more up-to-date info  on  the  demise  of the glossies and
     about the launch of the new magazine, Atari Computing.

     Apparently, Atari World went  down  because  of  cash flow problems. I
     believe that at the time they  had  around 8,000 subscribers. STF were
     axed by Future because of (among other reasons) pressure to reduce the
     number of titles from W H  Smith  and an effective advertising boycott
     from some Atari publishers. I  have  heard  that  at the time they had
     around 8-10,000 subscribers.

     There is obviously  quite a  lot  of  people  who  still want an Atari
     newstand magazine.  However,  you  are  right  about  the difficulties
     involved in running a newstand  magazine,  especially  a glossy one in
     full colour.

     It is for these reasons  that  Atari  Computing  is starting out as an
     initially bi-monthly mono subscriber only magazine. If things go well,
     and  circulation  gradually  increases   then   there  is  always  the
     possibility of colour and  monthly  issues  in  the future. We already
     have over a hundred people who  have sent in advance subscriptions for
     the first 3 issues, and more are  coming in all the time. The magazine
     will hopefully have the best  elements  from  both  Atari World and ST
     Format, and the first issue  will  include  a  survey form to find out
     what readers want from future issues of the magazine.

     The first issue will  be  available  at  either  of the upcoming Atari
     shows, or if you send in an advance payment (for either just the first
     issue or a subscription for the first  3  issues), then a copy will be
     posted to you soon after the shows have finished.

     Most of the  well  known  Atari  supporting  companies  are taking out
     advertising space, and international  distribution  is currently (mid-
     August) being sorted out. The   producers  of  the magazine, The Atari
     Computing Group, based on CIX (and  non-profit making) are also in the
     process of setting up a  web  site.  The subscription and single issue
     rates are shown below.

     ****** All prices in UK Sterling where  = British Pounds ********

       +----------------------------------------------------------------+
       |                   |         |         |              |         |
       | Evaluation Copy   | UK      | EUROPE  | USA/CANADA   | OTHER   |
       |----------------------------------------------------------------|
       | Magazine only     |  3.00  |  3.50  |  4.00       | 5.00   |
       | With Reader Disk  |  5.00  |  5.50  |  6.00       | 7.00   |
       +-------------------+---------+---------+------------------------+
       |                   |         |         |              |         |
       | Subscription      | UK      | EUROPE  | USA/CANADA   | OTHER   |
       |-------------------+---------+---------+------------------------|
       | Magazine only     |  9.00  | 11.50  | 12.00       | 13.00  |
       | With Reader Disk  | 15.00  | 17.50  | 18.00       | 19.00  |
       +----------------------------------------------------------------+

     If anyone would like to place an advanced subscription for the first 3
     issues, then either email me  at manifold@cix.compulink.co.uk or write
     to me at:-

     1 Portland Avenue, Burton on Trent, Staffs. DE14 3GD. England.

     and I'll send you a  subscriptions  form.  If  you  would just like to
     reserve a copy of the first  issue,  then send the appropriate payment
     to the above address and I'll pass  on your payment and details to the
     appropriate people to ensure that you receive your copies.
     ----------------------------------------------------------------------
     To: ICTARI
     From: Robert Manning

     It is good to see that you are  continuing with ICTARI and I hope that
     you will continue supporting the  Atari  platform.  Now that ST Format
     has ceased to be I thought those  of  us using Atari machines would be
     without any sources of information other  than  the internet.  As I am
     not an internet user then I thought I  was going to be forced onto the
     PC platform.  As a PC user  at  work  I  like  to come home and use my
     Atari 520STFM and my feature  rich  applications which cost a fraction
     of those I use on the PC.

     As a thought for future  disks  I  was wondering whether when somebody
     submits a program to go on  the  disk  whether  they could write a few
     words on what they used to develop  the program and any special tricks
     that  they  used.   Features  on  new  techniques  that  others  could
     incorporate into their own  programs  might  be  a  nice  idea and any
     libraries or add ins might be useful  so that others could utilise the
     same ideas.  This is something that gets done a lot on the PC platform
     under Windows where you buy add  ins  to programs like Visual Basic to
     save having to write the same  code  as other people.  With details of
     libraries used and handy subroutines it may be possible to get a whole
     range of modern applications that have a standard interface.

     Personally I would  be  interested  in  libraries  for  Lattice C5 and
     HiSoft Basic that  help  in  producing  Non-Modal  dialogues and menus
     within windows.

     I look  forward  to  the  first  issue  of  the  new  magazine,  Atari
     Computing.
     ----------------------------------------------------------------------
     To:     Everyone
     From:   Jason J Railton
     Re:     3-D maths

     The basic principle of my maze demo is that it's all done on a flat 2-
     D map, like Gauntlet or  any  other  maze  game.  It just uses vectors
     instead of graphical blocks.  This  2-D  approach  simplifies a lot of
     the maths.  Anyway, I've sent in a  demo of the maths required to work
     out co-ordinates in such a map relative  to the viewer.  Later on I'll
     give a demo of how to turn these into a proper 3-D display.

     Oh, and I haven't done  much  this  month  because  I've been too busy
     playing PlayStation 'Resident Evil'.  I'd  just  like to say to anyone
     who bought a PC, hoping to play good games: "BIG MISTAKE!"
     ----------------------------------------------------------------------
     To: Jim Taylor and C programmers  (Ref: Ictari 36 & 37)
     From: Mrten Lindstrm

     LOW-LEVEL VDI CALLS FROM LATTICE C
     ==================================
     I really hope there is a Lattice  C  expert among us to help you, Jim.
     "vdi()" is the function name,  for  low-level  VDI calls, suggested in
     the Atari Compendium and apparently used by Pure C, but other possibi-
     lities exist of course.  (Looking  into  the  DEVPAC ASSEMBLER library
     files I find the names "LowLevelVDI", "LOW_VDI" and "CALL_VDI".)

     COMBINING MACHINE CODE WITH C
     =============================
     On PCs there are C  compilers  with  some support for inline assembly,
     allowing you to write  simple  assembly  routines  directly  in your C
     source. I don't know if Lattice  C  supports  this, however (but see a
     general solution below). The customary  method  is otherwise indeed to
     write and assemble your  machine  code  routines  into separate object
     files, then linked with the object  files produced by your C compiler,
     but for the details, help from a Lattice C expert is again needed.

     "Inline" machine code in ANY C
     ------------------------------
     If you find no other way to  incorporate a small assembly routine into
     your C program, I think the  following general method should work with
     ANY C compiler:

     Define the function as a (global)  ARRAY of shorts or longs containing
     the HEX CODES for the  machine  instructions.  Then,  when you need to
     call the function, CAST the  array  name  into a function pointer. For
     instance:

       unsigned long vdicode[] =
       {
         0x7073223CL,             /* moveq #115,D0  ;  move.l #...,D1  */
         (unsigned long) _VDIpb,  /* longword for the preceding move.l */
         0x4E424E75L              /* trap #2        ;  rts             */
       };

       typedef  void (*PVOIDFN)();  /* In order to simplify later casts */

     Then whenever calling "vdi()" do it with:

       ((PVOIDFN) vdicode) ();

     Obviously, you could simplify even further with a preprocessor macro:
       #define  vdi  ((PVOIDFN) vdicode)
     after which you can make your low-level VDI calls with just:
       vdi();

                                    ---<>---

     The _VDIpb used above is, as in my example in Ictari 36, assumed to be
     the "VDI parameter block" i.e. an array of pointers to the VDI arrays.
     If this isn't defined either, in your libraries, it can be defined:

       short * _VDIpb[] =
       {
         _VDIcontrl,
         _VDIintin,
         _VDIptsin,
         _VDIintout,
         _VDIptsout,
       };
                                    ---<>---

     PS: If you wonder how  I  can  know  the  hex  code  of each and every
     assembly instruction, then I obviously  don't.  I simply assembled the
     routine  in  Devpac  and   studied   the   result   in  its  debugger.
     Alternatively, any disassembler should  be  able  to produce a listing
     containing both hex codes  and  corresponding assembly mnemonics. Just
     remember to give pointers to memory locations special treatment - like
     _VDIpb above - and don't merely copy their hexadecimal representation.

     To: All
     From: Mrten Lindstrm

     WDIALOG
     =======
     I send in the WDIALOG documentation,  that  I have now translated from
     German to English, and also a  WDIALOG.PRG file with some text strings
     translated through plain and unsophisticated file byte editing.

     I have however still not done much  in the way of actual experimenting
     with it, but it expands the AES with three libraries of functions:

       wdlg_xxx   for handling window (= non-modal) dialogs
       lbox_xxx   for handling list boxes
       fnts_xxx   for handling a font selector  (modal or non-modal)

     The belief I expressed last  month  that  it also could make available
     extended  object  types  was  apparently  a  misunderstanding  though.
     Instead there is a separate C  source file ADAPTRSC.C (included in the
     package), containing functions for this and other purposes.

     Before using the WDIALOG functions, from within your own applications,
     you must first call:

       appl_find( "?AGI" )

     If the return value  is  not  -1,  then  it's  safe (regardless of TOS
     version) to carry on and call:

       appl_get_info( 7, &ag1, &ag2, &ag3, &ag4 )

     Use bitwise AND on the returned ag1 parameter with 7; if the result =7
     then all WDIALOG functions are available.

     Callback procedures
     -------------------
     The bad news, for everybody who  uses a high-level language other than
     C, is  that  the  only  thing  that  you  will  probably  be  able  to
     conveniently use without C or assembly is the font selector.

     This is because both window dialogs  and list boxes, as implemented by
     the Behnes in  WDIALOG,  require  pointers  to  functions, within your
     program, to be passed to  the  system.  And  GFA Basic and other non-C
     languages don't unfortunately allow you  to  play around with function
     pointers (maybe in GFA Basic 4  -  ha  ha).  In MS Windows, where this
     concept is heavily used (yes, I  have  admittedly now started to learn
     PC programming) such functions are called "callback" procedures, since
     they allow the SYSTEM to call  (routines within) your PROGRAM whenever
     needed. In GEM, the only other case of callback procedures, that I can
     think of, are the routines associated with PROG_DEF objects and called
     by the AES whenever such an object needs to be (re)drawn. (Though in a
     way, every lowly, program-installed,  interrupt  routine could perhaps
     also be considered a kind of callback procedure.)
     ----------------------------------------------------------------------
     To: ICTARI
     From: John Noakes

     I am very much interested to know whether the rest of the members have
     had the same problem. Recently I ordered a product from HiSoft only to
     have it sent two weeks later,  the  same  with Gasteiner. True I could
     have paid extra for a faster service  but  when I phone using a credit
     card action only for them to state  two to three days delivery I think
     GREAT.

     Is it me, with my phone manners  of  please and thank-you on the order
     that puts them off, or is it  that the dwindling Atari market has them
     slacking in service. You probably  ask  "why  didn't I complain", well
     there's an old R.A.F. Supplier saying,  "Hide  your shame in file 13",
     that file is a rubbish bin.

     So I like to say "I LIKE YOUR PRODUCTS BUT YOUR SERVICE STINKS".
     ----------------------------------------------------------------------
     To: ICTARI
     From: Jim Macleod

     I am self taught in assembler  and  there  are many things you discuss
     that are beyond me as yet. To this end I cannot get the bitmap to work
     using vro_cptfm. It sets up  OK,  returns  a  handle, I can set screen
     colours without affecting the screen proper but any v_gtext appears on
     screen no matter what. I have  copied  screen  to bitmap and back to a
     new location but to no avail. If you have a working example any chance
     of it being on disk, even  a  mini-program can be dissasembled if it's
     easier.

     Thanks for all your effort in keeping Atari alive.
     ----------------------------------------------------------------------
     To: All
     From: Peter Hibbs

     Does anyone know if it is  possible  to  use an 'editable object' in a
     dialog form in small text. It  is  possible with WERCS to display text
     in Large or Small sizes  using  the  TEXT  object but editable objects
     seem to need the text set  to  large  even though WERCS will allow the
     editable text size to be set to  Small.  If this is done, however, the
     users entries are  scrambled  and  cannot  be  displayed  properly. If
     anyone has any ideas I would be interested to hear them.

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