
     ICTARI USER GROUP             ISSUE 34                       May 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 34
                              ==================

     ASSEMBLY        Assembly Language Tutorial. Part 2.
                     Dialog box code.

     C               Alert message function.
                     C Manship code Chap 23 (see correspondence section).

     GFA             Hi Rez scaling program demo.
                     Various mouse related routines.

     STOS            Generic STOS fix program.
                     STOS menu code.

     MISC            HTML information (compressed).
                     Rich Text format spec Part 1.
                     VDI Enhance program and documentation.
                     PC to Atari disk reader.
                     Current membership list.
                     Index for issues 1-33.

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

     ASSEMBLY        PICPAC update.
                     Assembly Language Tutorial. Part 3.

     C               Dynamic memory debug library.
                     File listing functions.
                     Progress bar.

     GFA             File selector routine.
                     GFA Time/date routines.

     STOS            STOS demo code.
                     Pie Chart maker.

     MISC            Rich Text format spec Part 2.
                     SCSI FAQs

     ----------------------------------------------------------------------
                                   EDITORIAL
                                   =========
     MEMBERSHIP
     ----------
     A couple of members have cancelled their membership this month and one
     new member has joined, welcome to him.

     READING ICTARI DISKS ON THE PC
     ------------------------------
     I know that some members read the  ICTARI disk text files on their PCs
     (at  work  or  wherever)  before   trying   them  out  on  the  Atari.
     Unfortunately disks which are formatted  in a non-standard mode cannot
     be read by the PC DOS,  the  program  in  the  PC_TO_ST folder is a PD
     program which should allow  non-standard  Atari  disks  to be read. We
     haven't tried it yet and we  do  not accept any responsibility for any
     problems it may cause on the PC system.

     HTML/RTF FILES
     --------------
     Note that  the  HTML  document  file  in  the  MISC  folder  has  been
     compressed and will need to be decompressed before use, a program like
     UNLZH172.PRG or equivalent can  be  used  to  decompress the file. The
     decompressed file requires about 367Kb  of  disk space. Note also that
     the RTF_SPEC.TXT file runs to about 90 pages when printed out.
     ----------------------------------------------------------------------
                                 CORRESPONDENCE
                                 ==============
     To: Peter Hibbs
     From: Lee Russell

     Peter, I haven't contributed anything for a while so I thought I would
     offer some source code from my latest project. What I am working on is
     a simple program to cut  rectangular  portions  out of .IMG files. The
     program is not  complete  but  I  have  enclosed  two  functions which
     display a 'creeper bar' on the screen while the data is being loaded.

     It's getting harder all the time to  resist buying a PC (photo quality
     graphics, etc) but I'm  managing  !  Does  anyone  think  that a small
     Encarta-like package would be possible on the ST ?

     */ I suppose anything is possible, the question is whether it would be
     worth the effort, I doubt it somehow.  ICTARI /*
     ----------------------------------------------------------------------
     To: Anyone
     From: Owen Rogers

     Please could anybody tell me how to  change  the text in a BOXTEXT etc
     in a resource file. I use GFA Basic 3.

     Atari World
     
     For people wanting a refund from  a  subscription to Atari World (like
     me!!) it is best  to  write  directly  to  Specialist Magazines. COMPO
     Software, who published Atari World,  has  also  gone out of business.
     Atari World closed because COMPO closed. The magazine itself was doing
     very well! Specialist Magazines can be contacted at -

                       Specialist Magazines,
                          Salisbury House,
                             Station Road,
                               Cambridge,
                                  CB1 2LA.

     If anyone has any success please write back to Ictari and tell us what
     action we should take to get our money back!!

     NB There is a small chance that  SYSTEM  SOLUTIONS may take it over. I
     am going to wait for a month or two just in case they do take it over.

     */ I subscribed to Atari World and this month I received a notice from
     my bank saying that  Specialist  Magazines  had  cancelled my standing
     order and refunded my last subscription  so  I  guess that they are no
     longer in business.  PDH /*
     ----------------------------------------------------------------------
     To: ANY STOS PROGRAMMERS
     From: George Hodgson

                             " HELP   HELP   HELP "

     Can anyone help me get my head around  the idea of loading data into a
     program from a file ?  I know  this  must sound daft "BUT" there is so
     little detailed information on the subject  that  it's hard to pick it
     up (for me that is ??).

     What I am trying to do is write some lottery programs that need a data
     file to store the lottery numbers in, and the file to be up-dated each
     week with the new numbers !

     I have the programs working,  but  at  present  am using the read data
     statement to get the data  required  into  the program and, of course,
     the data is in the listing !

        "HOW DO I USE A SEPARATE DATA FILE FROM DISK ?"

     Please try to help as I would like  to compile the programs to see how
     fast they are ?

     Any help, however small, would be  very  much appreciated ! So come-on
     lads, write explaining, send me a  disk with examples on, (I'll return
     and refund postage + send some  prgs  !)  or  give me a bell with your
     phone No and I'll ring you back !

     To: John Cove

     I have just read the Intro doc  by John Cove on the Assembly Tutorial,
     sounds good ! Just what us learners need.
     ----------------------------------------------------------------------
     To: Peter Hibbs
     From: Raymond Reid

     With regards to the Saucers source code  on Issue # 31 of Ictari, this
     is ** NOT** a game, but  a  sound and motion demonstration in assembly
     language, as the opening comment states.

     I  have included the source and DAT file again along with the compiled
     program which does run although  the  SAUCERS.DAT  file must be in the
     same directory. This source compiled and  ran  OK  on my STe which has
     4mb memory, hopefully this helps clarify its status as a 'game'.

     I have also included a source  file from C-Manship Complete by Clayton
     Walnum, CHAP_23.C (from chapter 23!!) which  I am having problems with
     trying to compile it using Prospero C.

     The error message I keep  getting  is:  'ptr-to-fn initializer is non-
     NULL integer' when it gets to  the  "TEDINFO  rs_tedinfo[] = {" etc. I
     have worked through most of the book but  I  am still at a loss on how
     to correct this although I  have  been  able  to adapt and alter other
     files from this book to run with Prospero - even some header files.
     Can anyone help???? please!!!!!

     Not being a competent programmer in C, I desperately would like advice
     on how to correct this - thanks in advance.

     */ See the C\C_MAN_SH.IP folder.  ICTARI /*
     ----------------------------------------------------------------------
     To: Tony Harris
     From: Jason J Railton

     Re:   Mouse Interrupt Priorities

     You said in ICTARI  #32  that  you  were  having  trouble with rasters
     wobbling as you use the mouse.  I can see myself coming up against the
     same problem in something I'm working on.  As  far as I know it is not
     possible to reduce the priority of  the  mouse interrupts to stop this
     happening.  Thomas Nilsen's mouse handler, also on ICTARI #32 would (I
     suppose) have the same  problem,  because  it  uses the same interrupt
     method for handling the mouse as  the system does. (So, thanks Thomas,
     but I don't think it'll work with rasters).

     The problem is  that  the  standard  mouse  reading  procedure, called
     RELATIVE mode, can  interrupt  at  any  time.   If  it  interrupted at
     regular intervals, it  could  be  controlled.   Since  it  doesn't, it
     interferes with the rasters by  a  varying  amount each frame, causing
     them to jump about.

     It actually interrupts when the mouse  is  moved in any direction by a
     certain threshold  distance.   It  forces  a  jump  to  a  pre-defined
     handler, which should note  the  relative  movement reported since the
     last event.

     The only solution I can think of is to put the mouse in ABSOLUTE mode,
     in this mode, the keyboard  chip  should  monitor the mouse, recording
     its position on a definable X/Y  grid.   You  actually have to ask for
     the mouse  position,  then  an  interrupt  occurs  to  report  the co-
     ordinates.

     Since you then have  to  request  a  mouse  report  (the interrupt and
     report sequence is called  a  'packet'),  you  can  control when these
     occur.  Then you can either do  this 'above' your rasters (immediately
     after your v_sync  interrupt  has  occurred);  or  check  something (a
     colour register for  example)  to  tell  when  the  rasters  have just
     finished, before calling.

     However, I haven't tried this myself.   Does  anyone out there have an
     ABSOLUTE mouse reader they can  demonstrate?   I  haven't got round to
     this yet - I'm working on 3-D graphics, a STOS game, etc...

     To: Peter Hibbs

     Re:   STOS Compatibility
     Interesting to hear that my 3D  demo  gives  you a blank screen.  I've
     got the same version of TOS as  you  - 1.04.  Still, I'll try and pre-
     fix it once you give out the fixer.

     I've written a short demo (although compiled  it gets to about 80k) to
     try out controls  in  a  STOS  compiled  program.   It  uses  the STOS
     joystick, one of  the  STE  Extension  joysticks,  and  the STOS mouse
     routine.  I'd be grateful if you  could  put  it on a later disk (I'll
     pre-fix it and send it in once  I  get  ICTARI #34) for people to test
     out the control methods.  I  use  the  STE  extension because it has a
     convenient twin-joystick routine.

     Anyway, on this demo you move  a  small light patch around the screen,
     which is chased  by  one  of  two  robots.   These  robots aren't just
     animated as they move around the screen;  they are actually made up of
     separately programmed moving  parts  and  walk  in  quite bizarre, but
     nevertheless realistic and convincing  movements.   Hence  the size of
     the demo.

     If you don't think you'll have  room  for  it,  I could just send in a
     short control tester, but it would be nowhere near as entertaining.

     To: Martin Milner

     Re:   STOS Compiler 2.7

     I've actually got STOS 3D,  but  I  didn't  realise  it had a Compiler
     update.  It doesn't mention this in  the  manual  and as I already had
     STOS 2.6 I never used  the  updater.   Anyway,  with Compiler 2.7, and
     that pre-fixer off this disk (I'm  going  to look pretty daft if Peter
     misses it off this one), my troubles should be solved.

     Thanks for the tip, anyway.

     To: David Preston & Peter Hibbs

     Re:   Total NBA
     The videogame with the basketball  players  you've  seen is Total NBA,
     from Sony, running on the  Playstation.   The players are actually all
     texture-mapped polygons, not sprites, and  the reflections are made by
     mirroring the players' lower legs  and  feet mathematically in 3-D, to
     just below the floor, and  drawing  them in semi-transparent polygons.
     Stadium hoardings and lights are done  in  the  same way, and it looks
     brilliant. (Mind you, if you  watch  real basketball, it's the players
     bright shirts and shorts  you  see  reflected,  not  their legs, but I
     suppose that's too many polygons).

     Still, I think Peter  was  asking  about  mirroring  a sprite left-to-
     right, so  his  sprite  can  face/walk/slither  in  either  direction,
     without having to store two sets of sprites.

     Peter - there is no  simple  mathematical  relationship between a word
     and its reflection.  Ideally, the  reflection  should be done to build
     up a library of images in memory, and use these for real-time display.
     A lookup table is possible  for  real-time  display, but still gives a
     significant drop in speed.  Remember that  to  mirror a word, you have
     65536 combinations, but need twice  this  to  store the results of the
     flip (131072 bytes).  You  have  to  double  the  word you're going to
     mirror, and use the offset as a  32  bit number.  You then pull a word
     (two bytes) from that address.

     If the mirroring is done in  preparation,  there is no need for speed,
     so the shifting method is simplest.

     Of course, you can  get  the  problem  seen  in  some games where your
     character changes from  being  right-handed  to  being left-handed, or
     other small details are reversed.   The  Ferrari  horse on the back of
     the car in OutRun is a good  example, across several formats (even the
     arcade game, so  I've  heard,  though  I've  never  noticed),  and the
     fighters in Super Street Fighter II  Turbo  X Alpha Pro-Plus Extra Ex-
     Lax Etc. (whatever they're on now).

     To: Peter Strath

     Re:   File Viewer
     It works on  my  520STFM,  TOS  1.04,  2.5Mb  contraption.  What's the
     betting my STOS stuff doesn't work  on  yours  though?  Is it meant to
     handle graphics, or just text?   Peter  mentioned .IMG files, but will
     it be able to do any others (e.g. .NEO)?

     To: Peter Hibbs

     Re:   STOS Games
     I have two STOS games I'd  like  people  to try, once I've re-compiled
     them.  One is a two-player TANKS game  - like VCS 'COMBAT', although I
     wouldn't know because I've never  played  'COMBAT'.  Anyway, steer one
     tank and shoot  the  other  one.   It  has  the  addition  of mortars,
     bonuses,   guided   missiles,   homing   missiles,   counter-measures,
     interactive scenery (fancy talk for  "you  can shoot things that don't
     move too")  and  a  countdown  timer  that  goes  'ping'.   The other,
     'Buzzsaw', still isn't quite  finished  but  should  be  very soon.  I
     think it's best described as Tetris  with the 'gore' option on.  (Best
     described by that particular phrase because you're even more confused,
     but intrigued at the same time).

     How can I get these around?  I'd  like  them tested before I send them
     to a PD library, but they're huge,  and together would probably fill a
     disk.  Could you dish out copies, if people sent you an extra disk, or
     shall I ask for  stamped-addressed  envelopes  and  disks from people?
     And what would everyone else like?  If  one of these programs were put
     on the ICTARI disk, the magazine would have  to be cut down by half to
     fit it on. Would folk  mind?  Don't  send  anything yet though anyone!
     I've still got some work to do before they'll be ready!

     */ We will have to think about that when the time comes.  ICTARI /*
     ----------------------------------------------------------------------
     To: Peter Hibbs & Marten Lindstrom
     From: Jim Taylor

     Yes Peter, I also thought of this idea of using logbase & physbase  in
     conjunction with malloc but like yourself  could not figure out how to
     alter the size and shape of the  screen.   As you say, there MUST be a
     way of doing  it.  When  you  think  about  it  the  VDI  must get its
     information from somewhere as to its drawing area limits and sizes - I
     can't imagine these will be embedded  into  the system code - or could
     they?

     In my ST Internals book it  describes  a  variables block which can be
     accessed with line-A $a000.  Here a few which seem relevant:

     Offset  Name            Size    Function
     ------  ----            ----    --------
     00              v_planes        word    number of planes
     02              v_lin_wr        word    bytes per scan line

     NB: No mention of numbers of scan lines

     also

     54      _CLIP           word    0=clipping  !0=no clipping
     56      _XMN_CLIP       word    upper LH corner of clipping area
     58      _YMN_CLIP       word    upper LH corner of clipping area
     60      _XMX_CLIP       word    lower RH corner of clipping area
     62      _YMX_CLIP       word    lower RH corner of clipping area

     Are any of these the ones you tried changing? Did you try altering the
     clipping values?

     I have also spotted a fragment of  code  in  the same book in the BIOS
     listing which is interesting.

     ************ Scrdmp, hardcopy ***********
     005a60  sub.l   a5,a5                   Clear a5
     005a62  move.l  $44e(a5),$654(a5)       v bs ad, screen output
     005a68  clr.w   $658(a5)                Offset to null
     005a6c  clr.w   d0
     005a6e  move.b  $44c(a5),d0             Sshiftmd, screen resolution
     005a72  move.w  d0,$662(a5)             Save
     005a76  add.w   d0,d0                   Times 2
-->  005a78  lea     $5ad4(pc),(a0)          Table for screen resolution
-->  005a7c  move.w  0(a0,d0.w),$65a(a5)     Get screen width
-->  005a82  move.w  6(a0,d0.w),$65c(a5)     Get screen height
     005a88  clr.w   $65e(a5)                Left
     005a8c  clr.w   $660(a5)                and right to zero
     005a90  move.l  #$ff8240,$666(a5)       address to colour pallette
     005a98  clr.w   $66e(a5)                Clear mask pointer
     005a9c  move.w  $a8c(a5),d1             Get printer configuration
     .
     .
     .
     .
     ************* Parameter table for hardcopy **********
     005ad4  dc.w    320,640,640             Screen widths
     005ad8  dc.w    200,200,400             Screen heights


     Lines $5a78, $5a7c and $5a82 certainly seem to suggest that the screen
     sizes are hard coded and that  this  piece  of code uses the values at
     locations $5ad4 - $5ad8.   It  does,  however  write  them to $65a and
     $65c. I don't know if  these  are  the  VDI  working locations for the
     screen parameters and if they are alterable.

     I have also noticed elsewhere  in  the  BIOS  listing, in a section to
     clear the screen, that it  uses  an  immediate  value of $8000 for the
     screen size - this is not good  news since it suggests that the screen
     area is not variable.  However I am  still not convinced that a screen
     configurable RAM (SCRAM) area is not  possible.  My reason for this is
     as follows:-

     A couple of weeks ago I received a phone call from a chap in Australia
     asking for info on my drawing program.   He also told me about a piece
     of PD software called MONSTER and  wondered if it could be implemented
     in my program to get  over  the  problem  of long screen refresh times
     with large drawings.  Apparently this piece  of software tricks the ST
     into thinking it has a monster screen area and allows the user to jump
     to any section  of  it  without  any  refresh  delay.   I've contacted
     Goodmans and they say they can supply me  with a copy.  If it works in
     the way I hope, I'll try and get some info' from the author.

     */ Jim has sent the programs mentioned but I think the next letter may
     solve the problem (thanks once again to Mrten).  ICTARI /*
     ----------------------------------------------------------------------
     To: Phil Hodgkins
     From: Mrten Lindstrm

     Thanks for the enlightenment on VDI  usage  in  the AUTO folder. I had
     heard before that this was  possible  but  don't  think I had realized
     that the physical, rather than a  virtual, workstation had to be used.
     Thinking about it, though, it  does  make  sense that the one physical
     screen workstation, to which all virtual ones relate, has to be opened
     first, whether by an AUTO-folder program or - later - by the AES.

     To: Jim Taylor and everybody else too
     From: Mrten Lindstrm

     ATTENTION, ATTENTION, ATTENTION!!!

     OFF-SCREEN BITMAPS AND OTHER NEW VDI CAPABILITIES
     -------------------------------------------------
     Just a few days ago  I  happened  to  stumble  across what must be the
     ideal solution to your problem, and doubtless to other problems too. I
     cannot understand that I (and seemingly all other Ictari members too?)
     have failed to discover  this  vital  info  until now. (Though Richard
     Evans did, in Ictari 27, mention news  on  an NVDI 3 users manual - in
     German - in the public domain; I tried  writing to 2B, but have so far
     not received any  answer.)  What  I  have  now  found,  was  in a file
     "ENHANCER" under "TOSFIXES" on a CD with Atari PD (Gemulator Gold CD).
     If ANYONE has found any newer material, e.g. the NVDI manual mentioned
     by Richard (maybe on one of the  many German Atari CD-ROMs, or in some
     German Internet site?), then DO send it in!
                                 --------------

     NVDI 2.5+ adds NEW VDI FUNCTIONS  for handling off-screen bitmaps (and
     also for returning more info on  the screen than the ordinary v_opnvwk
     and vq_extnd functions reveal). This  in  itself  may  not be so great
     since many Atari users don't have  NVDI.  But 2B have released a small
     stand-alone program that provides  these  functions  to EVERYBODY ELSE
     TOO. The program,  called  the  'VDI  Enhancer',  is  basically freely
     distributable as long as no profit is made from it. It should be OK to
     deliver with any freeware  or  shareware  program or budget commercial
     one up to a value of 50 DM  (ca  22 or 220 Swedish kronor); with more
     expensive programs the written consent of the Behnes may be required.

     With this message, I have sent  the  Enhancer PLUS a bug-fixed version
     (disassembled, bug-fixed and reassembled) that I think should be OK to
     distribute as long as the original  is included (otherwise I might (?)
     make a complete rewrite for which the source too could be published).

     You may be interested to hear  that  the  Enhancer uses just the ideas
     presented by Peter Hibbs last  month:  for  each  VDI call, related to
     off-screen bitmaps, it temporarily changes  the logical screen address
     and a number of Line-A variables (to  be precise: the words at offsets
     -4, -12, -666, -692, -690,  -2,  0,  2,  -346 and -598) and internally
     makes use of a separate virtual workstation.

     The advantage  of  the  VDI  Enhancer,  compared  to  program-internal
     solutions, is of course  that  its  functions  are forming an existing
     and,  it  now  appears,  well-documented   STANDARD,  since  they  are
     available with every version of NVDI (2.5+). While the Enhancer itself
     should work on  every  standard  Atari  computer  screen, its function
     calls will also work on any GRAPHICS  CARD (or MagicMac etc.), as long
     as an NVDI version (or anything  else that is VDI-Enhancer compatible)
     is available for it - and I  understand  there are NVDI versions for a
     wide range of cards.

     With Atari themselves apparently gone  from  the  scene of OS develop-
     ment, we will have to rely  on  companies  such  as 2B, C-Lab etc. and
     hope that they coordinate things  between  them,  or at least document
     own extensions and adopt those of others. We too can contribute to the
     harmonization by supporting good ideas, as I think this one is.

     All that the end user  has  to  do,  is  to  copy the ENHANCER.PRG (or
     ENHFIXED.PRG) into his  AUTO  folder  -  unless  he  has  NVDI when he
     doesn't  have  to  do  ANYTHING.   Should  he  have  SpeedoGDOS,  then
     ENHANCER.PRG must be placed  after  it  (a  message  will otherwise be
     written on screen).

     All that the application programmer has to  do, is to make sure that a
     cookie 'EdDI' is present - as  it  should  be  if the user has done as
     above. Then use the new VDI functions.

                                 --------------

      THE NEW VDI FUNCTIONS 

     VDI Enhancer v1.00 (or NVDI) makes available the functions :-

     v_opnbm       Open bitmap (as a VDI workstation)
     v_clsbm       Close bitmap
     vq_scrninfo   Inquire screen info ("extended vq_extnd")

     and  in  addition  claims  to  fix  a  faulty  behaviour  of  the  old
     V_GET_PIXEL on Falcon high-colour screens (?).

     The main OP code, and most of the parameters, of the new functions are
     the same as of  v_opnvwk,  v_clsvwk  and  vq_extnd respectively (which
     internally are called by the Enhancer).  But  each of them in addition
     require the SUB-OP code (contrl[5]) to be set =1.

      V_OPNBM 

     v_opnbm in addition differs from v_opnvwk  in taking a pointer, in the
     longword in contrl[7..8], to a  standard  20-byte MFDB (see VDI raster
     operations) for the bitmap, and in taking 9 extra intin (or work_in if
     you like) elements  for  a  total  of  20  intins;  make  sure  to set
     contrl[3]=20:

       intin[11]:      Width-1  (will be rounded up to 15, 31, 47, 63 etc)
       intin[12]:      Height-1
       intin[13]:      Width of a pixel in m  OR  =0 for screen resolution
       intin[14]:      Height of a pixel in m  OR =0 for screen rez
       intin[15..19]:  =0 (reserved)

     If you clear the contents  of  the  MFDB  before passing it to v_opnbm
     (actually only the first longword  +  the  word  at  offset 12 need be
     zeroed) then v_opnbm will allocate memory  for the bitmap, clear it (=
     make it WHITE, which on a  high-colour  bitmap means setting all bits)
     and fill in the MFDB. The bitmap  will have the same number of colours
     as the screen.
     Alternatively, you can always set  the  (bits/pixel) word at offset 12
     to =1, to open a MONOCHROME bitmap.
     And, finally, you have the option of setting the first longword in the
     MFDB to point to a  pre-allocated  bitmap,  in which case v_opnbm will
     NOT clear it. Instead the word at  offset 10 (the format flag) will be
     used to determine whether the bitmap  needs to be transformed from VDI
     standard format (whole bitplanes) to device specific format.

     IMPORTANT: All bitmaps  opened  with  v_opnbm  are  in device specific
     format. Meaning  that  100%  clean  programs  in  principle  shouldn't
     directly manipulate them, but rely  solely  on  VDI  calls to draw and
     copy to and from them - until they are transformed back with vr_trnfm.

      VQ_SCRNINFO 

     vq_scrninfo works like vq_extnd, except  when  called with mode 2 when
     it  returns  272   words   info   on   hardware   screen   and  colour
     representation.
     This is just the function that I have been looking for a long time!

     See further information with the Enhancer in the MISC folder.

     To: Falcon users
     From: Mrten Lindstrm

     V_GET_PIXEL ON HIGH-COLOUR SCREENS
     ----------------------------------
     According to the Atari compendium  this  function, on a 16-bit screen,
     returns
       as 1st output parameter (intout[0]):  The colour value of the pixel
       as 2nd output parameter (intout[1]):  0

     But the v_get_pixel implemented  in  the  VDI  Enhancer  by 2B returns
     (from what I can see during disassembly, not actual experiment):
       as 1st output parameter (intout[0]):  The colour value of the pixel
       as 2nd output parameter (intout[1]):  -1

     Could you perhaps test this  function  on  a  real Falcon, without the
     Enhancer (or NVDI?), and  see  what  is  returned  (2B in the Enhancer
     documentation says it doesn't work  on  high colour screens). Or maybe
     you have some information from elsewhere?

     (Even stranger is any 32-colour mode where  AC has the colour value be
     returned low-word - high-word, while 2B  - through their Enhancer - do
     the opposite: high-word - low-word, + writes a -1 as a third word.)


     ALSO: Could you, with  the  ENHFIXED  installed,  try  opening an off-
     screen bitmap and use v_get_pixel on it,  to  see  if  I - as I hope -
     have managed to fix this function (it was faulty in 2B's original).

     To: Thomas Nilsen
     From: Mrten Lindstrm

     CLIPPING THE DRAWING IN (PARTIALLY COVERED) WINDOWS
     ---------------------------------------------------
     No, the problem is not with  OBJC_DRAW.  This function clips and draws
     only a  single  rectangle,  but  you  would  be  in  exactly  the same
     situation if clipping and drawing with the VDI.

     Instead, what you have to do  whenever  drawing anything at all in any
     window, is to do it in a LOOP that finds, clips and draws each visible
     rectangle of the window, one at a time.

     The single "dirty rectangle"  that  you  get  with AES redraw messages
     (received with EVNT_MULTI) is, as you  have discovered, only a HINT as
     to what area needs to be  redrawn;  ensuring  that no time needs to be
     wasted on drawing OUTSIDE  the  dirty  rectangle,  but telling nothing
     about its INSIDE (which may cover other windows).

     WIND_GET with modes 11 and  12  returns  the visible rectangles (OK to
     draw within), and the full drawing routine would look something like:

     '~~ (Re)drawing contents of a window using OBJC_DRAW ~~
     '
     ~WIND_UPDATE(1)     ! Request permission from the AES to start drawing
     ~WIND_GET(wh,11,x,y,w,h)             ! Get first visible rectangle
     WHILE w OR h <> 0
     ' -> If the drawing is done in response to an AES Redraw message
     '    then calculate the intersection of visible rectangle with the
     '    "dirty rectangle" given with message.
     '    This step isn't functionally necessary (the full visible
     '    rectangle could be used and the dirty rectangle ignored) but
     '    saves time by reducing the area clipped and drawn.
       ~OBJC_DRAW(tree%,0,$7FFF,x,y,w,h)  ! Draw tree clipped to x,y,w,h
       WIND_GET(wh,12,x,y,w,h)            ! Get next visible rectangle
     WEND
     ~WIND_UPDATE(0)  ! Window contents drawn. Allow others to screen again
     '~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

     When instead VDI is used for drawing, the routine would be essentially
     the same, except that the mouse needs to be hidden:

     '~~~~~ (Re)drawing contents of a window using VDI ~~~~~
     '
     ~WIND_UPDATE(1)     ! Request permission from the AES to start drawing
     ~GRAF_MOUSE(256,0)       ! Hide mouse to avoid corrupting drawing
     ~WIND_GET(wh,11,x,y,w,h) ! Get first visible rectangle
     WHILE w OR h <> 0
     ' -> Do intersection calculation here.
     ' -> Clip here (In GFA Basic simply "CLIP x,y,w,h"
     '    In other languages x,y,w,h must be converted into VDI coordinates
     '    usable with VS_CLIP - i.e.:  "VS_CLIP(x,y,x+w-1,h+y-1)" .)
     ' -> Do the drawing here
       WIND_GET(wh,12,x,y,w,h) ! Get next visible rectangle
     WEND
     ~GRAF_MOUSE(257,0)  ! Show mouse
     ~WIND_UPDATE(0)  ! Window contents drawn. Allow others to screen again
     '~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

     To: All who use my PICPAC library (assembly, GFA Basic 3 and others)
     From: Mrten Lindstrm

     I only just  now  discovered  a  tiny  but  completely  disabling bug,
     introduced during my revision of  PICPAC  (Ictari  24), in the routine
     IMGPAC for packing images in IMG format. Luckily, no-one seems to have
     tried to use it, since I  haven't  heard anyone say anything about it.
     If you had tried it, then  it  would  have always exited, returning an
     error (LBMPAC, on the other hand, works fine).

     I cannot explain how such  an  obvious  bug  could slip by, without me
     noticing it, except that, as  you  might  deduce,  I haven't until now
     actually saved any IMG files  with  the  revised PICPAC (only IFF ILBM
     ones). I guess I thought the change (checking for memory overflow) was
     so small that I didn't  need  to  test  it  much, considering that the
     packing itself was solidly tested before.

     I send a corrected version of  the  file PICPAC2.S to Ictari with this
     message. (I also send a new PICPAC1.S with the only change being safer
     blitter handling, by GETFM and  PUTFM, according to Programmers' Forum
     in ST Application about a year ago).

     */ See next month for the  PICPAC  files.  The off-screen bit map info
     looks extremely interesting, I haven't had a chance to try it out yet,
     if Jim Taylor  does  get  it  working  in  his  program,  we  would be
     interested to hear about it.  ICTARI /*
     ----------------------------------------------------------------------
     To: Peter Strath
     From: Stephen Bruce

     Re: File viewer Beta test
     I've only given this a brief run  through,  but on the whole I'm happy
     with the program & WOULD  consider  changing  to  this from my current
     favourite once it's been completed. A small registration fee would not
     be offensive as I'd like to see more of your work. However...

     As with Peter Hibbs, I would like  to see the main file selection menu
     enlarged and/or made sizeable, both  to  increase  the number of files
     selectable and to allow longer EFIs.

     On the subject of  EFIs,  it  would  also  be  useful  if at least one
     default EFI list was loaded on entering the file viewer, as it's a bit
     of a pain having to load them  separately  each time it's run but they
     are a neat idea. To  keep  everyone  happy  this  option could be made
     selectable via an on/off option in the menu bar. Assuming you accept a
     default EFI list, it then becomes useful  to have a secondary EFI list
     for those  occasional  disk  accesses  i.e.  one  EFI  list  with your
     standard defaults and another specific to  the disk you are searching.
     One suggestion for working this would  be  for the program to read the
     second EFI list from the  root  (or  perhaps  an EFI) directory of the
     drive you are searching on the  initial  reading of the disk. This may
     be too unwieldy in  practice,  but  you  did  ask for ANY suggestions.
     (P.S. Since writing this I've  examined  the program further & suspect
     you've partially covered this with the FV.EFI file being loaded).

     Peter also suggested  that  there  was  no  reason  for  the re-read &
     previous directory options in the  file  selection menu. While I agree
     that the previous directory can be  accessed  by hitting the close box
     on the window, the re-read option IS useful when working with floppies
     (as I have  to  do).  For  example,  when  searching  for a particular
     listing or article from previous  issues  of  ICTARI,  I don't have to
     wade through the directory  tree  &  can  quickly  jump  to inside the
     relevant folder (A:\ASSEMBLY, A:\C, or  whatever), simply by inserting
     a new disk & selecting this  option.  So scrap previous directory, but
     retain re-read directory and I'll be more than happy.

     More useful than the  above  would  be  the  ability  to change drives
     without having to go all the way back to the very first menu entry. My
     suggestions would be to have the A:, B:, etc ALWAYS shown as the first
     option in the file list  regardless  of  the position in the directory
     tree, OR have a drive selection option on the menu bar.

     The only actual  bug  I've  found  was  that  the  program incorrectly
     identifies TOS 1.62  (later  STE  TOS)  as  TOS  1.98.  I've seen this
     problem (along with an explanation of why it happens) somewhere, so if
     you can't fix it I'll  rummage  through  my  old ST magazines for this
     info. Not a terrible shortcoming in the program I'll admit, but we can
     do without confusing less experienced users.

     Lastly, it would be useful to have some basic file editing facilities,
     as I'm personally more inclined  to  give  up  my  limited memory to a
     program that's more of an 'all rounder'.  Yes, a file viewer is handy,
     but I can also view files in a text editor, which is what I've done up
     till now, despite the  impressive  capabilities  of other viewers. I'm
     being picky here I know, but that's me all over.

     To: John Cove (or Tronic if you prefer)
     From: Stephen Bruce

     Re: Assembly tutorial

     As a relatively inexperienced assembly  programmer,  I found part 1 of
     the tutorial useful, as so far I've  been muddling along on my own. It
     was reassuring  to  know  that  I  haven't  been  making  (m)any fatal
     mistakes regarding my use of  supervisor  mode,  but  I tend to put my
     programs into this mode & leave them  there. Is this dangerous for the
     system, or am I safe  to  do  this?  I  only  ask  as  I can't see the
     benefits of using user mode. Maybe this is covered in later tutorials,
     but if not, can anyone help me?

     Also, the info on  the  DC.?  instruction  helped  clear  up a problem
     that's really annoyed me in the past,  as I always thought that a DC.W
     or DC.L could  have  lower  bytes  manipulated  by  .B  &  .W commands
     respectively. Clearly this is not  the  case,  but  how about the DS.?
     command? Can I use other operators to work on these, or must they also
     retain the same operator size as the definition?

     Finally, I just wanted to say  thanks  for putting me straight really,
     as the article has  given  me  a  renewed  enthusiasm for programming.
     So...   T H A N K  Y O U  (grovel, grovel).

     */ It is possible to  manipulate  any  part  of  a DS.L or DS.W memory
     store if you really need to although  it  should be used with care and
     only if you know what you are doing. For example, the longword store -

             store           ds.l            1

     could be loaded with some data, for example -

                             move.l          #'1234',store

     which is just four bytes holding the  value  1234 in ASCII. If you now
     want to change the '4'  (the fourth byte) into a '7' you would use -

                             move.b          #'7',store+3

     which would copy the value '7' into  the label address 'store' plus an
     offset of three. This can also  be  done  with  DC.? stores but is NOT
     recommended as this would be effectively self-modifying code which may
     not work on machines (such as  the  TT)  which have program code cache
     memory.  ICTARI /*
     ----------------------------------------------------------------------
     To: Anyone
     From: Richard Evans

     Could  anyone  provide  me  with   information  about  the  following,
     preferably from a 'C' viewpoint:

     1) How to install a clean  up  routine in the etv_term vector (0x408)?
     (MagiC documentation states that  each  process  has  its own etv_term
     vector - how does this work?).

     2) Is there a reliable way to install interrupt driven routines?
     ----------------------------------------------------------------------
     To: All
     From: Theo Ros

     Is there anyone who can  dive  into  the algorithms concerning picture
     dithering? I see wonderful programs like  IMAGECOPY  do it, but I keep
     wondering HOW...
     ----------------------------------------------------------------------
     To: Jonathan Leckie
     From: David Preston

     Re: UDO
     -------
     There was a version of UDO on  a recent ST Format coverdisk (which you
     may have got yourself by now) and having had a look at it, I think you
     might be disappointed. As I understand it,  UDO is a utility to enable
     e.g.  programmers   releasing   software   to   include   the  program
     documentation in a variety of formats (HTML, ST-Guide, ASCII etc). The
     way this works is that you  produce  your document in UDO's own script
     file format, and it generates the various  file types from this. I may
     have got hold of the wrong end  of  the  stick,  but this is a one way
     only process, it doesn't translate back from those various formats.

     To: Mrten Lindstrm and *.*

     PC Contemptibles
     ----------------
     Mrten, as always, talks a great  deal  of good sense (Ictari 33). One
     point that Mrten's comments reinforced to me as something I suspected
     all along was that home computers  are  getting  to be like cars. I'll
     explain. If you're a car enthusiast you might very well have a classic
     like a  Morris  Minor  (or  an  ageing  Saab  or  Volvo  if  you're in
     Scandinavia) to tinker with and  enjoy  in  your leisure time, but for
     day-to-day  transport  use  something   far   more   up  to  date  and
     technologically advanced, and far more complicated under the bonnet.

     ST's are the classic - just  like  a  classic car, you can tinker with
     them, understand every nuance of  what  they  are  doing and spend the
     weekend with your head under the bonnet if you want to. The PC is like
     your everyday transport - you don't mind  _how_  it does it so long as
     it does it, quickly and reliably  (er,  well ok perhaps it wasn't that
     great a comparison...).

     To: *.*

     STOS compiled program problems
     ------------------------------
     Has anyone experienced the situation  where a compiled program doesn't
     do exactly what the interpreted  version  did? I've been messing about
     with a little scrolling  message  demo  for  submission to Ictari, but
     it's driving me to distraction. The compiled version seems to be doing
     different things with the  palette  from  what the interpreted version
     was doing. Anyway,  it's  too  late  to  submit  the  damned thing now
     (sorry, Peter, if this disk reaches you  a bit late), but I'll work on
     it some more. In the interim I'd love  to hear from anyone who has had
     any similar experiences.
     ----------------------------------------------------------------------
     To: *.*
     From: Kevin Cooper

     My name is Kevin Cooper and I  am  wondering if anybody could help me,
     currently I need to find out  information  on emulators, how they work
     and what I need to do to make one.  Also  I have a friend who has a PC
     which runs GEM, if  I  program  in  C  do  I  have  to use any special
     compilers, etc, if I want to program  for Atari GEM and PC GEM without
     making any changes except recompiling  on  the  other system. I have a
     number of projects  under  development  which  help  the programmer by
     taking away  certain  problems  including  (what  I  will  most likely
     release as shareware) a Vector Speedo Font engine so it is in reach of
     more people.  So  now  everyone  should  support  GDOS  as  you  could
     distribute the shareware version along with your programs letting them
     test your programs to the full.  When finished, my  programs will make
     your programs more comprehensive  by  taking  away  some of the fiddly
     bits so you can concentrate on  more  important things (more when they
     are ready).

     To: *.*

     Looking at the current Atari programs many of them are good, they work
     well, some better than the  supposedly  superior  PC counterparts so I
     started to think, really as  programmers  we  can program anything but
     most of  the  time  we  don't  know  what  people  want  so  perhaps a
     questionnaire could be made asking  what  people want and what options
     would you want in that program.  For  instance,  they could say an art
     program with normal options  and  a  masking  tool, club members would
     print these questionnaires asking  people  what  they need, they would
     ask everyone, not just computer users, a technical drawer would want a
     computer program  that  lets  them  do  3D  modelling,  producing many
     different types of drawing,  colouring  them  correctly, he/she  would
     write down all the  different  views  that  are  needed e.g isometric,
     planometic, oblique,  etc,  whereas  a  programmer  may  only  make  a
     standard perspective drawing. By asking many  people who want the same
     thing we will get more information on what is needed and by looking at
     theses questionnaires it will increase productivity in the Atari world
     which is always for the better.   One  of  the questions would be if I
     gave you ten billion pound  budget  to  develop  a word processor what
     would  it  do,  list  everything,   we   would  then  brainstorm  this
     information. The questionnaires will  be  sent  back  to  ICTARI to be
     published in the MISC  folder,  this  way  we  can concentrate on what
     people want.

     To: Jason J Railton

     I liked your polydemo it  was  very  interesting, I have been thinking
     about making a STOS extension for a while now, and I think, using this
     code, a new 3D extension could be  made  as the old one was rubbish. I
     would be interested in doing  this  so  contact  me  if you want to go
     ahead. My address is in the membership list.

     To: *.*

     Has anyone else tried out the new  OMEn operating system, it is a full
     multitasking operating system with  full cross platform compatibility.
     It has been written in pure assembler  and  will run on a standard 520
     STFM  and still have room for  programs.  It  has the ability to share
     files between programs e.g an art  package  and a DTP sharing the same
     picture file, so the DTP's programmer  does  not  have to write a word
     processor if he doesn't want to as he can use other peoples.

     I recommend you try it, the  demo version is available from Floppyshop
     and a demo version  of  the  development  kit  is also available, full
     versions are also available but  I  haven't  decided whether to buy or
     not as yet.

     To: *.*

     Does anyone out there  know  any  good  books,  I  would like anything
     really but programming orientated  is  what  I  want  most, such as is
     there a book on  writing  HMTL  documents  as  it  may  be possible to
     reverse engineer it to make a  HMTL  viewer,  I would be interested in
     lots of things like that. Does anyone  know  where I can get a book on
     Image processing.

     To: *.*

     I am very worried about the state of the Atari Magazines. This month I
     haven't had either, I know Atari World has gone under along with Compo
     but what about ST Format, why hasn't it  come,  is it just me or is it
     everyone. You may or may  not  have  heard  but  Sam Tramiel is now in
     hospital, his father Jack Tramiel (from way back when the ST came out)
     took over the company and now they have merged with a disk drive firm,
     Atari now has a new  boss,  so  what  are  his  views  on the ST's and
     Jaguar? Also many Jaguar games  have  come  out  but they haven't been
     stocked by Special Reserve, what is going on ?

     */ The questionnaire idea sounds good in  theory but I suspect that it
     would not work so well  in  practice.  The  first  problem, as we have
     found in the past, is to get  people  to contribute ideas on what they
     want and also  you  will  find  that  most  end  users  (as opposed to
     programmers) don't really know what  they  want  a program to do until
     they actually start using it. The second problem is that ICTARI caters
     solely for programmers who probably don't know what artists, technical
     drawers, etc, etc, would want a  program  to do. One solution would be
     to find a user who  has  experience  on  the  type  of program you are
     writing and get him to offer  advice  and  do  any beta testing of the
     program as it is being  written.  Of  course,  there  may even be some
     ICTARI members who can  help  and  we  would  be  happy to publish any
     requests for advice on specific programming projects.

     The state of the Atari magazines does  give some cause for concern. As
     you say, Atari World has ceased and  I very much doubt whether it will
     be resurrected. ST Format magazine  is  still being published although
     not many newsagents  seem  to  stock  it  now.  Also  the subscription
     renewal forms for ST Format  (according  to  a  colleague of mine) are
     being  issued  for  six  months  only  now  which  I  think  could  be
     significant. When you consider the size,  price, content and number of
     advertisers using ST Format now I  would  not  be surprised to see the
     magazine go the same way  as  Atari  World  within six months although
     they have said publicly that they have  been allocated a budget for 12
     months. The  subscription  based  ST  Applications  magazine  is  also
     declining at a rapid rate and I  would  expect  that one to go at some
     time in the near future (that's just  my  opinion and not based on any
     inside information). If (or  perhaps  when)  ST  Format  does cease to
     exist, it will leave Atari users and programmers with a major problem,
     where  do  we  buy  new  software  (what  little  there  is)  and  for
     programmers, how do you market and  distribute new programs. I suspect
     that the Atari PD  Libraries  would  also  find  it  very difficult to
     continue with no Atari  magazines  to  advertise their software. Using
     and/or writing software on the  Atari  in these circumstances would be
     like working in a vacuum, i.e. not very practicable.

     I think the time is quickly  approaching when serious Atari users will
     have to consider  switching  to  another  platform,  which, I suppose,
     really means the IBM  PC.  From  a  serious  programmers point of view
     there are big advantages,  a  huge  potential  market for new software
     (although writing an application that hasn't already been done will be
     more difficult). There are  also  masses  of software orientated books
     and magazines available  and  the  InterNet  can  probably provide any
     further information required. Also the programming environment on a PC
     is  now  very  attractive,   high   resolution   256  colour  screens,
     sophisticated programming languages  such  as  Visual  Basic,  C++ and
     Delphi which are much better than anything  on the Atari and, at last,
     with Windows95, an  operating  system  which  is  now  better than the
     Atari's. The biggest disadvantage  of  changing  is probably financial
     depending on ones requirements. A  fast  Pentium  system with 16Mb RAM
     and CD ROM would cost over  1000  although  a lower spec '486' system
     will  cost  considerably  less   and   would   be  adequate  for  most
     programmers.

     I have to confess here that I am seriously considering purchasing a PC
     sometime in the next few months. I  have begun to notice recently when
     looking through ST Format in W H  Smiths that I am getting sympathetic
     looks from other PC  magazine  buyers.  The  main reason for changing,
     however, is, like most  programmers,  I  want  to  write software that
     other people can use (and  maybe  even  make  a little money from them
     too). Of the two utility programs  that  I have had published over the
     last two years there have  been  less  than six registrations (OK they
     may not be very good programs) but I think it is also an indication of
     the declining number of Atari users available.

     So what does all this mean  for  ICTARI.  Over  the last few months we
     have lost a number of members, some  of  whom I know have moved to the
     PC and we have also gained a  few  new members in the same period. The
     current membership stands at about 60  including myself. I am prepared
     to continue running  the  group  for  the  next  few  months  at least
     although when I do eventually get a  PC I think it will be impractical
     to run the two systems  together,  I  just  don't  have the room so if
     anyone is interested in taking  over  the  editors role, please let me
     know. In fact I would like to  have  some feedback from ALL members on
     how they see the future of  ICTARI.  Naturally  I will be reluctant to
     give up the Atari and  ICTARI  as  I  have  learnt  a lot from members
     contributions over the past two years  but  we  do have to live in the
     real world (which, as we all know, is now run by Bill Gates).  PDH /*

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