
     ICTARI USER GROUP             ISSUE 33                     April 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 33
                              ==================

     ASSEMBLY        Assembly Language Tutorial. Part 1.
                     Non-Modal dialog boxes source code.

     C               Window icon interface system.
                     File viewer program.

     GFA             Text adventure game.
                     Object change code.

     STOS            Using a large font in STOS.
                     STOS Falcon patch program.
                     STOS Compiler patch.

     MISC            Character Set Information and UNICODE standard.
                     SCSI FAQ file, part 1.
                     Programming considerations (INTERNET).
                     Current membership list.

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

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

     C               Alert message function.
                     Monochrome fade function.

     GFA             Scaling program demo.

     STOS            Generic STOS fix program.
                     Pie chart generator.

     MISC            HTML information.
                     Rich Text format spec.
                     SCSI FAQ file, part 2.

     ----------------------------------------------------------------------
                                   EDITORIAL
                                   =========
     ATARI WORLD
     -----------
     According to Goodmans PD Library, the  ATARI WORLD magazine has closed
     down although there  seems  to  be  a  very  small  chance that System
     Solutions may take it over  but  I  wouldn't part with an subscription
     money until the situation has been resolved. It would be a great shame
     if it does close since  Jon  Ellis's  contribution was the only decent
     programmers column (apart from ICTARI of course) around.

     BETA TEST PROGRAMS
     ------------------
     When any  new  program  is  written  I  think  it  is  useful,  if not
     essential, to get someone else to try it out before it is released for
     general use. This 'beta'  testing  can  often  show  up  minor bugs or
     deficiencies which can  be  corrected  before  thousands  (well dozens
     then) of users start using it. This  is where ICTARI can play a useful
     role since between all our  members  there is probably every different
     type of TOS version, RAM size, screen  types, etc on which the program
     can be tested.

     In this issue Peter Strath has sent  a File Viewer program for testing
     (in the C folder) which members might  like  to try out. I have listed
     some of my own  comments  below,  perhaps  other members could provide
     some more and also send in their own programs for testing.

     I actually found the program very  useful, I especially liked the fact
     that it works in all resolutions (on  my machine anyway) and also that
     .IMG images could be loaded  and  displayed  in all resolutions. I did
     find one small bug, if you have a folder called XXXXXXX.IMG (where the
     X is any  character)  the  program  freaks  out.  I  guess the program
     assumes it is an image file before checking to see if it is a folder.

     Some other facilities I would  like  to  see  are  the filenames to be
     sorted in order of  filename,  extension  type  and/or file size (like
     most fileselectors). I  think  also  the  main  window  could  be made
     bigger, or allow the user to resize  it, so that more filenames can be
     displayed. It would be useful to be  able to load more picture formats
     although I suppose colour images would be  a problem. It would also be
     useful when displaying the  drive  letters  to  also display the drive
     names (that normally appear underneath the icons on the desktop), this
     would save having to remember which drive is used for what, I know you
     can enter a name but if there is  one already there, one might as well
     use it. I'm not quite sure  why  the 'Re-read directory' and 'Previous
     directory' lines are shown  at  the  beginning  of  each window, these
     would seem a bit superfluous  since  the 'close window' gadget returns
     to the previous  window  and  re-reading  a  directory  is  not really
     needed. I would also like to  see  the total number of bytes displayed
     at the top of the window shown as the number of bytes the files use on
     the disk rather than  all  the  file  sizes  just added together. Most
     programs of this type make this mistake,  the actual size of a file is
     irrelevant for most purposes, it is  the  amount  of space it takes on
     the disk which is  usually  more  important,  which  is  the file size
     rounded up to the nearest 1K  (although  if the file blocks are larger
     on high capacity hard disks, this value will be higher). A very useful
     feature (for me anyway) would be  the  ability to display (and save as
     ASCII) any type of  text  file  as  well  as  just  ASCII, for example
     Protext, 1st Word, HTML, Rich Text  format  and one or two others (see
     next months issue for RTF and HTML info) although I suspect this would
     be rather a major project.

     If anyone would like to add any more constructive comments, please let
     us know.

     ----------------------------------------------------------------------
                                 CORRESPONDENCE
                                 ==============
     To: Peter Hibbs
     From: Phil Hodgkins.

     Re: GEM and AUTO programs.

     The VDI is initialised before any of the AUTO programs are executed on
     boot up, but the AES is  not initialised until afterwards (just before
     the accessories are loaded and initialised).

     The only odd thing  about  using  the  VDI  during  boot  up is that a
     physical workstation should be used  instead  of a virtual workstation
     which would cause a crash. This  is  the opposite of what happens when
     the AES is loaded!

     The following are fragments of code from Stoop, a Falcon boot manager,
     that I've written, but they should  work  on  a  ST. It was written in
     Lattice C.

     // Main code
     if(detect_aes()) aes=TRUE;

     if(aes) {
             // Normal start up if not running from the AUTO folder
             // (i.e. the AES is present)
             appl_init();
             handle=graf_handle(&junk, &junk, &junk, &junk);
             v_opnvwk(work_in,&handle,work_out);
     }
     else
             // Physical workstation opened if running from AUTO
             v_opnwk(work_in,&handle,work_out);

     // These commands enable the mouse
     vsin_mode(handle,1,2);
     vq_mouse(handle,&mb_state,&mx,&my);
     vsm_locator(handle,mx,my,&junk,&junk,&junk);

     do {
             interface(&mb_state,&mx,&my,&key,&code,&mod,UP);

             // Your code goes here
     }

     // Closedown
     v_clsvwk(handle);
     if(aes) appl_exit();

     The following are functions used by the above code.

     /* Returns the state of the  mouse (buttons and position) and keyboard
     (ascii code, scan code and modifier key  status). It loops until a key
     or mouse  button is pressed. */

     void interface(short *mb_state,short *x,short *y,unsigned char *key,
                                unsigned char *scan,long *mod,char release)
     {
     *key=-1;
     *mod=0;
     do {
             vq_mouse(handle, mb_state, x, y);
             if(iskbhit()) v_get_key(key,scan,mod);
     } while(!(*mb_state & 3) && *key==-1);

     // Wait until mouse buttons are up or not, as required
     waitmouse(release);
     }

     void get_key(unsigned char *key,unsigned char *scan,long *mod)
     {
     long x;

     Supexec(conset);  // Allow Bconin to read shift key status
                       // this would normally be in the initialisation code
     x=Bconin(2);
     *key=x & 0xff;
     *scan=(x>>16) & 0xff;
     *mod=Kbshift(-1);
     }

     long conset(void)
     {
     *(char *)0x484 |= 0x08;
     return 0;
     }

     /* Exits when the mouse buttons are up if release=UP and are down if
        release=DOWN
     */
     void waitmouse(char release)
     {
     short x,y, state;

     if(release==UP) {
             do vq_mouse(handle,&state,&x,&y);
             while(state!=0);
     }
     else {
             do vq_mouse(handle,&state,&x,&y);
             while(state==0);
     }
     }

     Asm code for detecting the presence  of  the AES (given as source code
     with NVDI 2.5)

     CSECT TEXT,0

     XDEF _detect_aes

     _detect_aes     move.w  #$C9,d0
             trap            #2
             tst.w           d0
             seq.b           d0
             ext.w           d0
             rts
     END

     This works fine with TOS 4 and should be OK with other earlier version
     as it is  all legal  code.  Problems  occur with AES replacements like
     Magic and VDI replacements like NVDI,  so the program should appear in
     front of them in the  AUTO folder.

     I have later versions  of  this  code  (particularly  interface) but I
     managed to kill my Falcon and  I  can't  get  at  the code until it is
     repaired.
     ----------------------------------------------------------------------
     To: Mrten Lindstrm
     From: Jonathan Leckie

     1) Atari World subscription prices - This  information  is taken  from
     the February issue of Atari world but I don't think the prices will be
     out-of-date  you  can  always  write  and  ask.  Atari  World  have an
     arrangement  with  "Sven Bornemark Musik"  to supply  subscriptions to
     readers in  Sweden, Norway, Denmark  and  Finland.  Since you  live in
     Sweden I will quote the prices for Swedish Kronor :-

     3  Issues without disc 140 Kr
     3  Issues with disc    190 Kr
     13 Issues without disc 560 Kr
     13 Issues with disc    760 Kr

     You  should pay  the correct  amount  by  Post  Giro to :-  23 59 59-4

     The address of Sven Bornemark Musik is :-
     Sven Bornemark Musik,
     Lergosv 79,
     238 40 OXIE {I don't know if it should be 0XIE - but you will know the
                  postcode conventions}
     Tel: 040 54 54 54

     I  think  it  would  be  sensible  to phone him  and  verify  all this
     information.  Atari  World also claims  that  you  get  an "additional
     Swedish supplement free with each issue".

     2) I have sent a DRAFT spec  for HTML 3 to Peter  but it  is quite big
     (approx. 420 Kb) so if it is put on the disc it will be compressed.

     To: Derek Warren

     You  said your  directory program  was written  mainly to learn C and
     that you  wanted feedback so here  is some (screeeeeaaach - funny eh).
     I am not anything of an expert in C coding but I liked your function
     definitions at the top (bell,  cur_posn,  etc)  but  I notice that you
     used 'Goto`s' shame, shame, shame.  I myself have  used goto`s in  the
     past (forgive  me)  but   in   the    current   climate  of  re-usable
     modular structured  programs   using  Gotos   is  a   definite  no-no.
     If  the programming police were to catch  you it would be 3 years hard
     COBOL in the AIX mines.  May  I  suggest  you  use (in the  case of C)
     functions instead. So this code :-

     rez_no = Getrez();
     if (k==0 && rez_no==0)
     {
          not_low();
          goto end;
     }
                               would be replaced by :-

     rez_no = Getrez();
     if (k==0 && rez_no==0)
     {
          not_low();
          end();
     } else {
       /* do code that can be done if in high or med res. */
     } /* end of main code */

                               where end is :-

     void end() /* commands to be done at end */
     {
       enbl_cur;
       mouse_on();
       keybd_repeat(15,-1);   /* '15' puts speed of first keypress response
                                                  approx. back to normal */
       cls;
       gem_off();
       exit(0);
     }

     You have used functions elsewhere  in the program so just extend their
     use to replace the Gotos.  Your program will obviously still work with
     gotos but it is better style to use functions and it makes the program
     easier to  read, debug and modify  (apparently).  The inclusion of the
     Goto command in C was really a concession to the early users that used
     rubbish BASICs  without functions or  procedures. Try and get a C book
     that helps with the  concepts  behind IF ELSE and using functions.  If
     I am completely mis-judging you, sorry,  but that was what occurred to
     me when I was looking through it.  The actual code looks O.K. though.

     To: All

     In  case  anyone is interested  UDO ver. 4 should  be  available  from
     FloppyShop, Goodman, LAPD, Merlin  and Power PD as we read.  For those
     that  don't  care or can't  remember I was  looking for it  because it
     converts ASCII, LaTeX, RTF, HTML formats (+ others).  I haven't got it
     yet but it  looks  funky and  is available  for  Atari, DOS and Linux.
     Registration costs 15 pounds.
     ----------------------------------------------------------------------
     To: *.*
     From: Martin Milner

     The recent notes about STOS/TOS incompatibility and STOS versions have
     finally spurred me to  write  with  some  recently  acquired info that
     should be useful to anyone programming in STOS.

     STOS/TOS independence
     ---------------------
     I have  for  several  years  now  achieved  TOS  independence  for the
     joystick  by  using  the  joystick  commands  from  the  missing  link
     extensions, which seem to work on  all versions of TOS, (including TOS
     4.nn), but the mouse has until  recently always been a problem without
     using STOSFIX. However, recently  I  have  come  into  possession of a
     generic STOS fixer, which can 'pre-fix'  a  compiled program for up to
     10 TOS versions, and it works brilliantly.

     The original fixing code was  produced  by Les Greenhalgh, and Anthony
     Jacques has now put a nice  GEM  interface  on  it (written in C), and
     sent me a copy. (Thanks Anthony).  As  it's freeware, I've sent a copy
     to Ictari to put on the  disk.  The  program  uses  a  set of up to 10
     DEFnnnn.DAT files produced by STOSFIX3 to  achieve the fixing, and no,
     don't ask me how it's done,  I've  no  idea!  I've included the set of
     DEFnnnn.DAT files with the  program,  they  should  enable you to make
     your programs able to run  on  most  current  versions  of TOS with no
     further treatment required. If you add more default files, the program
     will use  the  first  10  it  finds.  It  can  also  be  used  to  fix
     BASIC206.PRG, as I had to do before using STOS on the Falcon.

     STOS compiler versions
     ----------------------
     In Ictari 32, someone was  asking  about  whether compiler version 2.5
     was the latest. Well, I've been using version 2.6 for some time, which
     I believe was issued  when  the  STE  was  released, but I've recently
     found out that there is a  version  2.7 (from Anthony Hoskin), which I
     believe was issued with STOS 3D. I've sent a copy of that to Ictari as
     well. I've just found out  that  I  needed  this version to overcome a
     problem with using one  of  the  commands  from  the latest version of
     Anthony's Falcon extension, so it  would  probably  be a good idea for
     others to  use  it  too.  Note:-  You'll  need  to  have  the compiler
     extension already. As it  is  (was?)  a  commercial product, I haven't
     included the extension files, only the compiler program and accessory.

     Using the STOS Sprite Editor on the Falcon.
     ------------------------------------------
     Finally, using the  STOS  sprite  editor  on  the  Falcon is virtually
     impossible due to  many  of  the  graphics  commands,  (eg:- box, bar,
     circle,  etc)  not  working.  I've  now  produced  a  patch  file  for
     SPRITE.ACB, (SPRPATCH.ASC), which can be used  to update the editor so
     it will work on the Falcon. You'll  need the latest version of Anthony
     Hoskins Grafix II extension (3.6  upwards),  which has the replacement
     graphics commands in it. To patch the  editor just do the following in
     the program editor:-

     load "SPRITE.ACB"
     load "SPRPATCH.ASC"
     save "SPRITE.ACB"

     Then reload STOS or do an accload to reload the editor accessory.

     Hope the above info/programs/files  will  be  of  use  to some of you.
     Enjoy.

     */ See the STOS folder for the  patch  programs and next month for the
     Generic fix program.  ICTARI /*
     ----------------------------------------------------------------------
     To: Tony Harris
     From: David Preston

     Blitters - A minor correction.

     While STe's certainly do have that  particular bit of silicon wizardry
     on board, the blitter's first appearance in  an  ST was in the Mega ST
     (TOS 1.09). This was  followed  by  the first one-box blitter-equipped
     ST, STFM's fitted  with  TOS  1.4  (aka  1.04).  Since  then (I think)
     they've all had one as standard.

     To: Jason Railton

     SeaPest problems

     Erm, just a plain vanilla TOS 1.62  STe with 1mb on board, I'm afraid.
     I didn't post a message  last  time  cos  I  didn't want to labour the
     point, but  like  Stephen  Bruce  (ICTARI  32),  your  3D  demo didn't
     acknowledge the mouse either...

     To: Mrten Lindstrm

     UNICODE

     I see that NVDI 4 advertises UNICODE support.

     To: Peter Hibbs

     One way of compressing your sprite data  might be to use PackIce. Most
     instances of Ice 2.4 I've  come  across  on  coverdisks and PD library
     disks have  included  decompression  routines  in  assembler.  I  even
     compiled one using Devpac 2 from  a coverdisk (assembly language might
     as well be some obscure dialect of  Klingon  to me) and got it working
     within STOS on one occasion but  had  a clearout and haven't been able
     to duplicate the feat since...

     If you do  crack  the  compression  question  _really_ effectively you
     might even be able to store the 'reflections' along with the sprites.

     There was a report on the development  of  a basketball sim for one of
     the consoles on telly recently,  where  the  players looked as if they
     had reflections in the polished, varnished court floor. The result was
     very effective, looking almost as if  the scene was being raytraced or
     whatever on the fly. But  of  course  the programmers had included the
     'reflections' as part of the sprites, applying a softening mask to the
     reflection bit, so it didn't require  anywhere near as much processing
     as it appeared. Looked good, though...

     I'm not sure whether you mean  like  a  reflection in a floor or what,
     but the principle is pretty much the same.

     To: ICTARI

     Once you get to #100 you could use the extender for numbering purposes
     - eg. ICTARI.100! (That'll  fix  those  clever  dicks who use "Install
     application"!) ;-)

     To: David Seaman

     Sorry, but I can't see the  problem with Stock Controller. The version
     you submitted does seem to  be  the  one  without the disk commands to
     which you earlier referred as  problematical,  but  with regard to the
     sorting problem, all I can achieve is a listing in stock number order.
     Is this not what is supposed  to  happen?  I  know  I'm a bit dim, but
     you've really got me baffled with this!

     To: *.*

     Shuffling demo - ICTARI 32

     I think I forgot to  explain  what  you'd  actually _use_ that sort of
     routine for. Apart from  the  obvious  card  games, the same principle
     works for shuffling questions in a quiz game, random tile dissolves in
     a slide show etc etc.

     */ Looking through my hard  disk  I  find  that  I do have the PackIce
     source code, I will have to study them further.  PDH /*
     ----------------------------------------------------------------------
     To: Jim Taylor
     From: Peter Hibbs

     You say you want to generate an  image  in memory using all the normal
     VDI commands and then print out  the  whole image to a printer (Ictari
     27 and 32). I think  I  can  provide  half the answer, perhaps someone
     else can do the rest. I  have  used the technique described below very
     successfully on a program I am writing.

     The idea is to make  the  VDI  system  output  its  graphics data to a
     memory buffer rather than the  screen  which  can  then be dumped to a
     printer in the normal way.  First  allocate  a  memory buffer which is
     large enough for your image and store  the start address of the buffer
     (i.e. #buff_addr). As you probably know,  the GEM system maintains two
     'screen' addresses in  RAM,  the  'physical'  screen  address  and the
     'logical' screen address. The 'physical'  screen address is the actual
     address that the hardware uses when  displaying the screen image which
     can be anywhere in memory  but  is  usually  the  last 32K of RAM. The
     'logical' screen address is the  RAM  address  that  the VDI uses when
     outputting its images  and  is  usually  the  same  as  the 'physical'
     address so that when a VDI function  is used, the image appears on the
     screen. However, it is  possible  to  change  the 'logical' address to
     another location in RAM so  that  the  graphics  output will be stored
     there instead of in the screen RAM.

     The sequence below shows the  technique  using Assembler Macros (which
     should be easily convertible to another language) :-

     First we need to allocate a block of RAM to store the VDI output. This
     can be done with 'malloc' or just define a buffer in RAM, e.g.-

     buff_addr       ds.b            32000           32K buffer

     Next we need to find the current screen address with -

                     logbase                         fetch screen addr
                     move.l          d0,scrn_addr    save in (scrn_addr)

     This address is  saved  so  that  the  proper  screen  address  can be
     restored later (if we don't do this  we  won't be able to see anything
     on screen).

     Next we change the  'logical'  screen  address  to  the address of the
     output buffer -

                     setscreen       #-1,#-1,#buff_addr      change addr

     This command is the  BIOS  (TRAP  14/5)  call  which allows the screen
     resolution and screen addresses to  be  changed.  As  we don't want to
     change the resolution or 'physical'  screen  address, a negative value
     is placed in those positions.

     Now call the required VDI calls  to  generate  the image, note that as
     nothing will appear on screen during this operation, it would probably
     be wise to display suitable 'please  wait' message before the function
     is called.

                     vsf_interior    #2                      set attribute
                     vsf_style       #9                      set attribute
                     circle          #100,#200,#300          draw circle
                     etc
                     etc

     When the image has been drawn, the screen display can be restored with
     the same BIOS call but with  the  original  screen address used as the
     'logical' screen address -

                     setscreen       #-1,#-1,scrn_addr       restore addr

     Any further output to the  screen  will  appear  on the screen and the
     contents of the RAM buffer can now be sent to the printer.

     The one big flaw in the  above  is  that  the buffer is still the same
     size as  the  screen  which  is  not  much  good  for  larger  images.
     Unfortunately I have not  found  a  way  to  make the 'logical' screen
     larger during program execution. I  have  found  the two RAM addresses
     which store the x and y screen  sizes  (at the A_line data address -12
     and -4 respectively)  but  even  though  I  have  changed these before
     calling the above code,  the  VDI  still  does  not  recognize the new
     values. Maybe a new virtual workstation  needs  to be opened after the
     values have been changed for the VDI to recognize them, I did try this
     but it didn't work properly and I  don't  know enough about the VDI to
     know if this  should  work.  It  must  be  possible  somehow, I think,
     because the screen  expanders  (such  as  AutoSwitch  Overscan)  do it
     although they run in an Auto folder and affect the whole system.

     If anyone can  throw  any  more  light  on  the  subject,  we would be
     interested to hear about it.
     ----------------------------------------------------------------------
     To: Peter Hibbs
     From: Mrten Lindstrm

     Warm thanks for the issue of Atari  World,  I  will now try at least a
     three-month subscription for it.

     To: Ictari
     From: Mrten Lindstrm

     Apologies for using "strange" and  uncommon English words. This wasn't
     intended (I DO want my English  to  be as easily readable as possible)
     and merely something that  might  happen  when  writing by dictionary.
     Please continue to  point  out  any  other  "unusual"  features  of my
     English that you might spot;  I  promise  to  not  find you finicky or
     fastidious (or even finical).

     To: *.*
     From: Mrten Lindstrm

     Unicode
     -------
     Just when I had  posted  my  previous  message,  I  discovered that 2B
     apparently, according  to  "News"  in  ST  Application,  already  have
     included Unicode support in their new NVDI 4.

     It remains to be discovered exactly HOW. With the VDI call VST_CHARMAP
     (OP code 236 and taking a  single  intin)  you could, already with the
     first  SpeedoGDOS  version,  select  between  Atari  8-bit  characters
     (=mode 1) and Speedo 16-bit character  INDEXES (=mode 0). A fair guess
     would perhaps be that a new mode (=2 ?) has been added for Unicode.

     (I haven't yet upgraded my own copy of NVDI (3.02). But I guess I will
     have to now?)

     By the way, I  hope  I  didn't  cause  any  panic  with  my talk about
     Unicode. Of course, the old  8-bit  characters  will be with us still,
     for any foreseeable future. And  this  applies  to other computers too
     (Windows NT is the system that I think presently has gone the furthest
     in way of Unicode support, but Windows 95, although using some Unicode
     for instance in  its  extended  file  names,  still  mainly uses 8-bit
     characters).

     There are  alternatives  for  overcoming  the  dissimilarities between
     different 8-bit sets - e.g. RTF. For  instance, in order to transfer a
     file containing the text string "Mrten" (where "" is non-ASCII) from
     Atari (or from PC  DOS)  to  Windows  I  could  simply expand it thus:
     {\rtf\pc Mrten}, which  Windows  programs  should interpret correctly
     (see more in the texts on RTF that I have sent in).

     For the time being, Unicode will, I think, primarily be of interest to
     writers of  word  processors  and  the  like.  But  even  if  not used
     directly, Unicode is convenient just  for  reference purposes, I think
     (e.g. for conversion tables)  -  allowing  the specification of almost
     any commonly used character  or  symbol,  from  anywhere in the world,
     through a simple 16-bit number.

     To: Tony Harris
     From: Mrten Lindstrm

     The blitter chip was first included  in  the MEGA STs as standard. All
     Megas, all STEs and all Falcons should have one; other Atari computers
     (including TTs) normally not.

     But a program should, of course, not  rely  on a computer model or TOS
     version  to  determine  the  presence  of  a  blitter  chip,  but  use
     BLITMODE(-1) (XBIOS 64 with a word parameter = -1). Use bitwise AND on
     the result with 1 to see if  a  blitter is "on" (configured by user to
     be exploited by system) or with  2  to determine presence of a blitter
     regardless of system configuration. Result: 0=NO.
     (XBIOS 64 works with all  TOS  versions  -  even the "pre-blitter" TOS
     1.00  which will always return 0=NO when ANDed as above)

     To: Peter Hibbs
     From: Mrten Lindstrm

     Image compression with low decompression times
     ----------------------------------------------
     Yes, some sort of run length encoding  must indeed be the best choice.
     But I would recommend to  encode  words "vertically" (in 16-pixel wide
     columns). This technique is used in  TINY  images, and in Deluxe Paint
     IFF ILBM compression  type  2,  and  although  requiring slightly more
     programming  effort,  usually  gives   much  better  compression  than
     encoding words or bytes "horizontally" a scan line at a time.

     The reason for this is of course the  way each byte or word in itself,
     on the Atari, represents  a  horizontal  row  of  pixels; thus all the
     pixels of a word are adjacent to pixels of a vertically adjacent word,
     while only a single pixel  touches  a  horizontally adjacent word (and
     the chances  of  a  compressible  match  decreases  accordingly).  The
     difference disappears if working with  e.g. the 16-bit Falcon hardware
     screen, where each word represents only a single pixel.

     In any case should each plane be done separately of course.

     As for the speed of  the  decompression,  for  any  kind of run length
     encoding it should  be  possible  to  make  it  fast  enough  even for
     animations, I think.

     By the  way,  the  weak  point  of  the  Tiny  /Deluxe  Paint vertical
     compression scheme is with patterns.  If  your sprites contain much in
     the way of patterns, you might  want  to  reserve some code ranges for
     repeating patterns of 2 (or more?) words.

     References: Ictari  4: Picture formats by David Baggett and
                 Ictari 16: IFF ILBM (vertical word compression) by myself

     Mirroring (and other manipulations) of images
     ---------------------------------------------
     A lookup table is really the best  solution  as  far as I can see. You
     say you find lookup tables impractical  and  I agree that a 65536-word
     table would be, but a 256-byte table isn't so horrible do you think?

     Since there isn't a built in Motorola instruction for flipping a word,
     the only alternative to lookup tables, that  I can think of, is indeed
     the shifting of one bit at  a  time  via  the X bit, like you suggest.
     However, if you replace ROXL with ADDX

     ( example: LSR.W  #1,D0  ; 1 s on an ST
                ADDX.W D1,D1  ;  s  - " -  )

     then each bit will take  only  1.5  microseconds  on a standard ST, as
     compared to 2 microseconds if shift operations are used both ways.

     Still, with the  help  of  a  byte  lookup  table  you  should be able
     increase the speed, even further, by, at  the very least, a factor two
     - and maybe three or four.

     Lookup tables are also what I  would  recommend to anyone who wants to
     quickly shrink or enlarge an image (by a factor 2).

     To: Jim Taylor
     From: Mrten Lindstrm

     GDOS
     ----
     I do understand your hesitancy to  rely  on  GDOS; it would be so much
     nicer to be able to offer the user an inclusive package, not requiring
     him to involve himself in, or even buy, GDOS.
     But I am afraid there is no way  past  GDOS that I can see. Other than
     writing your own  replacement  VDI  driver  from  scratch,  capable of
     translating your VDI calls into drawing on a raster bitmap.

     Without GDOS, the system is  left  with  nothing  but the built-in VDI
     screen driver, which won't give you  the  memory bitmap image that you
     want. (Any call of v_opnvwk will  always  give you the same dimensions
     as the PHYSICAL screen workstation (of  the  AES), and in any case you
     cannot, in a clean way, directly control or access a memory bitmap for
     it - though you can copy between it and a raster image of your own.)

     With GDOS, and the VDI driver  MEMORY.SYS,  you can open a workstation
     (on device #61) that specifically does  what  you want; it allocates a
     memory bitmap, the shape of  which  you  can  determine on the call of
     V_OPNWK and the address of  which  you  will  receive on the return of
     V_OPNWK (See chapter 5 of my GEM Guide).

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

     If only Atari had included GDOS  and  more  VDI  drivers in ROM in the
     first place, or at least  distributed  them  with every sold computer,
     you wouldn't have been in this dilemma.

     There was some discussion on writing our own freeware GDOS replacement
     (including drivers), that any Ictari  member  or  anyone else would be
     able to freely distribute with  his  programs  (and among others Simon
     Rigby had looked into the  programming  of  drawing routines I think),
     but I think we ended up at finding it not worth it (?).

     To: Simon Rigby and anybody interested
     From: Mrten Lindstrm

     OUTLINE FONT FILE FORMATS
     -------------------------
     A long, long time  ago  you  asked  if  anyone  had information on the
     Speedo font file format. I still haven't got that (has anybody else?),
     but I HAVE now got some pretty detailed information on TRUETYPE files.
     Unfortunately it is not in ASCII  disk file format (and furthermore it
     is copyrighted by Apple and  Microsoft),  but  if you are interested I
     think I could make the effort and write an article about TrueType.

     To: *.*

     HOW AN OUTLINE FONT ENGINE WORKS
     --------------------------------
     Although neither the end user  nor  the application programmer, making
     his SpeedoGDOS function  calls,  needs  to  know  how  an outline font
     engine goes about is business  internally,  I  think  there might be a
     general interest in this subject,  so  here  is  an overview (there is
     also some info in the text "Joy of GDOS" from Germany):

     The main task of  an  outline  font  engine  is  of course to generate
     bitmap images from the outline  data  (from  then  on, there is little
     difference between an outline engine and a bitmap font engine).

     The basis of any  outline  font  data  is  arrays of coordinate pairs,
     describing the contours that form  characters (or "glyphs"). In Speedo
     fonts these coordinate  pairs  refer  to  points  for  drawing "BZIER
     curves" (= "CUBIC  B-splines");  TrueType  fonts,  on  the other hand,
     merely use "QUADRATIC B-splines".
     The difference between cubic and  quadratic  B-splines is, simply put,
     that cubic splines use  TWO  "control  points" (= off-curve "magnets")
     between each "anchor point" (=  on-curve point); quadratic splines use
     only ONE control point between each anchor point.

     /\
     If the above explanation isn't enough, at the risk of making it appear
     more complicated  than  it  really  is,  here  are  the  full B-spline
     equations.
     Note to Protext users: Characters  and   (253 and 254) below are, in

     the standard Atari set, superscript  2  and 3 ("squared" and "cubed").
     Replace with Protext commands   r !253 !t2!t c and r !254 !t3!t c

     Linear (simple line): x(t) = (1-t)x0 + t*x1  (This is a straight line
                           y(t) = (1-t)y0 + t*y1   from (x0,y0) to (x1,y1))

     Quadratic B-spline:   x(t) = (1-t)x0 + 2t(1-t)x1 + tx2
                           y(t) = (1-t)y0 + 2t(1-t)y1 + ty2

     Cubic (Bzier curve): x(t) = (1-t)x0 + 3t(1-t)x1 + 3t(1-t)x2 + tx3
                           y(t) = (1-t)y0 + 3t(1-t)y1 + 3t(1-t)y2 + ty3

     where t goes from 0  to  1,   (x0,y0)  is  the  first anchor point and
     (x1,y1) etc. are the following control and anchor points.

     (The actual algorithm for calculating  points  on a quadratic or cubic
     curve would use the  basic  linear  formula  (between  each anchor and
     control point), repeated in 2 or 3  steps for each t. The curve points
     calculated in one step would be used  as end points in the next, until
     only two end points remain in the  final step that produces the actual
     curve point for the t.)
     \____________________________________________________________________/

     The coordinates for anchor and control  points are given in some font-
     internal unit, called  ORUs  (Outline  Resolution  Units) in Bitstream
     terminology and FUnits (Font Units) in TrueType.

     In the simplest case, the curves are  used to generate bitmaps in only
     two steps:

     1)      Scale  them  -  i.e.   multiply   each   anchor/control  point
             coordinate by some scaling factor - to match the pixel grid of
             the current text  size  and  device  resolution.  (If rotation
             and/or skewing is applied,  each  coordinate  must actually be
             calculated as the sum of original  x  and y each multiplied by
             some signed factor.)

     2)      Draw them on the bitmap (i.e. calculate the exact curves using
             the B-spline equations above  and  then  determine what pixels
             are inside and should be  drawn).  This  step is called "scan-
             conversion".

     The simplest outline font  files  may  indeed  be  nothing more than a
     collection of poly-beziers with  a  header  on  it; Calamus fonts may,
     from what I have heard, be this simple (?).

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

     If the text size is big enough,  and the resolution high enough, there
     is no need for anything more, but in small text sizes /low resolutions
     you will start noticing that some  character parts (stems or bows) are
     visibly thinner  than  others,  or  deformed,  or  in  bad  cases even
     entirely missing, just  because  of  unfortunate  interaction with the
     pixel grid (if for instance a very thin part of a character happens to
     pass IN BETWEEN pixel centres, it  will "disappear" when the bitmap is
     drawn). These bad effects become visible already at a character height
     of about 60 pixels  and  get  worse  the  smaller  the characters get.
     (Though exact figures will vary  widely between different characters -
     e.g. the "@" character is in much more trouble than "-" or "|".)

     The remedy is called "hinting" or  "grid-fitting"  and is applied as a
     step in between scaling and scan-conversion:

     1)      Scale outline curves.
     2)      Grid-fit them.
     3)      Draw them. (= scan-conversion).

     Grid-fitting means distorting the  outline,  moving points and curves,
     to fit better onto the pixel grid.  Stems and bows can for instance be
     made relatively  thicker  in  small  text  sizes,  and  horizontal and
     vertical stems moved  to  be  aligned  with  pixel  rows  and columns,
     ensuring uniform thickness when converted into bitmap image.

     In TrueType, the  hinting/grid-fitting  is  achieved  through complete
     GRID-FITTING PROGRAMS, built from INSTRUCTIONS much like the processor
     instructions of Motorola or Intel. The difference is of course that no
     hardware processor (as far as  I  know)  has  been built to carry them
     out; this is left for a  soft-ware  interpreter  which must be part of
     any font engine dealing with TrueType fonts (thus one must be found in
     SpeedoGDOS and NVDI).
     At the heart are, of  course,  instructions  for moving the individual
     points or whole curve segments of the outline data, but there are also
     instructions for arithmetical and logical  operations, for moving data
     about, and for (conditional) jumps and sub-routine calls.
     Professional TrueType font designers  will  use  special assemblers or
     even high level compilers to create the hinting routines and programs.

     By the way: It seems that  hinting  is  normally shut off when text is
     rotated in non-right angles. The  reason  is,  from what I understand,
     that hinting programs simply  aren't  flexible  enough to successfully
     deal with such cases.

     BITMAP FONTS AND OUTLINE FONTS
     ------------------------------
     There exists a  strange  myth,  perhaps  even  among programmers, that
     outline fonts generally are  better-looking  than bitmap fonts. Anyone
     who has really  LOOKED  at  outline  text,  must  have  realized it is
     precisely the other way around. And if looking doesn't help, then just
     think about it; any font engine - whether outline or bitmap - will, of
     course, in the end work with BITMAPS, copied to the screen or whatever
     - the difference is, an outline  engine  is capable of generating NEW,
     reasonably good-looking, bitmap images for any new size or resolution.
     But the single set of character  images  in a bitmap font was designed
     by a HUMAN artist (well, in the  best  case  at least) and in the size
     and resolution IT WAS INTENDED FOR, no outline font can beat it.
     The best an outline font designer  can  hope  for, is to make machine-
     generated bitmaps as close  to  human-designed  ones  as possible, and
     this, indeed, is most of what outline font technology is about.

     In fact, Microsoft  has  apparently  just  recently  come  up with the
     ultimate solution (guess what): The  EMBEDDING  OF BITMAPS in TrueType
     fonts. Yes, really! The circle has closed it seems.
     Of course this feature will normally  be used only for some especially
     tricky characters and in  small  sizes/low  resolutions, but Microsoft
     does ALLOW even TrueType fonts with ONLY bitmaps and no outline data!

     To: *.*
     From: Mrten Lindstrm

     POINTLESS POINTS
     ----------------
     I little while ago, when  I  was  writing  my  Gem  Guide, I thought I
     understood the meaning of "font size" and typographical "pica points".
     A point is 1/72 of an inch ( 353 micrometres) and when text is set to
     for instance 12 points, it would  -  so  I thought - have a "character
     cell height" of 12 points (= 1/6 inch   4.23 mm), i.e. be suitable to
     print in lines this far apart (at  a minimum). If  you merely know the
     resolution of the device on which you  are printing (use 90x90 DPI for
     screen; see WORK_OUT array for other  devices),  you should be able to
     instantly figure out what point size  to  request  in order to match a
     given text line height in pixels.

     Practically all GEM BITMAP fonts are indeed designed this way, so when
     I found NVDI to return  character  cell  heights much larger than this
     for Speedo fonts, I at first thought it a bug in NVDI.

     But no. It appears that  existing  GEM  bitmap  fonts are just a happy
     exception, and that text point  size  more generally refers to nothing
     as tangible at all as  a  "cell height" or "recommended line-spacing".
     Instead, the point size merely refers to the "em" of the font.

      THE EM ? 

     'Em??? What the *%#@ is the  "em"?'  you  may rightfully ask. Well, it
     seems that the em originally WAS the height of the lead slugs on which
     characters were cast. The  widths  could  vary,  but traditionally the
     capital letter "M" was cast on a  square; hence the concept of the "em
     square" or simply the  "em"  of  a  font.  You  might  see a potential
     analogy between physical lead  slugs  and  the  cells  of a computer's
     character bitmaps, both describing bounding  boxes for the characters,
     but it seems that this  analogy  no  longer  holds very well. You will
     find that ascenders and descenders  of  many outline characters go way
     above and below any em defined for them.
     Neither is there, of  course,  any  requirement  for  the width of the
     letter "M" to equal the em; there  may  not  even BE a letter "M" in a
     font (remember symbol fonts and  various non-Latin alphabets), but the
     font will still always  have  an  em.  Similarly,  although many fonts
     contain so called "em-dash" and  "em-space"  characters, the widths of
     these need not be equal, neither to  each  other nor to the letter "M"
     nor the em of the font. The "em-dash" and "em-space" are simply "wide"
     dash and space characters  and  the  em  itself  totally devoid of any
     exact meaning (except to define the  internal coordinate system of the
     font).

      FICKLE LINE-SPACING 

     To some of you  -  with  experience  of  the  new Atari programs (like
     Papyrus etc.) that make use of  outline  fonts  -  it may already be a
     well-known phenomenon that a  change  of  type-face,  EVEN AT CONSTANT
     POINT SIZE, causes the number of  lines per page to automatically also
     change (it  may  vary  WILDLY  depending  on  the  whims  of  the font
     designers). Personally, I only recently  discovered  this with MS Word
     on a PC. The reason is,  of  course,  that  - although there may exist
     some option to use the set point  size  (= the em) as the line-spacing
     value (sometimes called "exact" or  "solid" line-spacing) - the result
     normally isn't usable, due  to  the  seemingly  routine  habit of font
     designers to under-dimension em relative to characters. Thus, the poor
     application  is  forced  to  try  and  figure  out  some  other,  more
     reasonable,  line-spacing  value  based   on   maximum  ascenders  and
     descenders (it seems that a TrueType  font can contain THREE different
     sets of ascender, descender and  line-gap  values - one for Macintosh,
     one for Windows and apparently one intended to unify all formats).
     Atari programmers may actually have a slight advantage in that GDOS is
     supposed to always deliver a  characters  CELL  height, that should be
     immediately  usable  as  a  line-spacing   value;  thus  it  left  for
     SpeedoGDOS or NVDI to sort out the mess in outline fonts.

      WHY ? 

     So why, oh why, couldn't the em  of  each and every font have been set
     to be that  line-spacing  value  that  applications  (or  GDOS) now so
     painfully have to deduce  from  other  sources  (that  also would have
     ensured  constant  line-spacing  between  different  type  faces).  Or
     alternatively - and perhaps even  better  -  why wasn't simply the old
     and obviously obsolete concepts of  em and typographical point dropped
     completely on modernizing and computerizing typography (the pica point
     WAS apparently redefined from 1/72.08246 inches in metal typography to
     exactly 1/72 inches in digital typography).

     I would have preferred font sizes  given in millimetres and referring,
     ALWAYS, to the useful line-spacing of the  font. (E.g. 4 mm text would
     correspond to an  EXACT  LINE-SPACING  of  11.34  points  or AROUND 10
     points FONT SIZE for most current fonts;  5 mm text would give a line-
     spacing of 14.17 points which might  correspond  to ca. 12 points text
     size.) I realize that metres  and  millimetres  may  perhaps not be as
     appreciated by Anglo-Saxons as by  the  rest  of  us who have grown up
     with them, but who can love POINTS?

     To: *.*
     From: Mrten Lindstrm

     PC CONTEMPTIBLES
     ----------------
     As you might have guessed from all  my  recent talk about PC things, I
     have now got myself such  a  device.  No,  please, I AM honestly sorry
     about this; I have  for  a  long  time  been  planning  to  buy a more
     powerful Atari computer than my  old  1  Mb  ST  (without an "E"), but
     didn't have the money until recently. But then I wanted the ability to
     run some  PC  stuff  too,  and  didn't  find  a  PC  emulator  a  very
     competitive alternative any more, and, well, sorry!

     Needless to say, my trusty old ST  is  still taking the seat of honour
     next to my PC on my desk (you  wouldn't SELL a friend would you?). And
     a very considerable part of the  time  I  spend  in  front of my PC is
     taken up by Gemulator sessions (in  spite  of Gemulator (4.05) not yet
     working too well with Windows 95).
     I still think it would be nice  to  have  a Falcon too, though I guess
     such dreams will, with my present  reduced assets, have to stay dreams
     for the foreseeable future.

     So, what do I think of the  PC?  Well,  compared  to my old ST it is a
     step up, in many ways (just the  wonder  of being able to use a super-
     VGA colour monitor, ah), though  I  guess  a  Falcon owner wouldn't be
     that impressed.
     Windows 95 offers,  all  in  all,  a  well-working fully multi-tasking
     environment, which I never had on my  1Mb  ST. But, on the other hand,
     it is only about how I imagine MultiTOS, Geneva or MagiC would work on
     an Atari (with enough RAM). Windows  95  may be the major breakthrough
     that Microsoft has made so much noise about, but only when compared to
     previous Windows versions (which  for  instance  didn't allow icons on
     the desktop as I understand  it).  The  general movement, I assume, is
     for modern systems to look more  and  more like each other, regardless
     of computer and despite Apple's frantic  efforts to claim copyright on
     the concept of user-friendliness  itself  (called  "the Apple look and
     feel" in Apple  terminology).  There  are  some  nice touches, windows
     being  resizable  in  all  directions,  and  task  switches  are  very
     conveniently accomplished e.g. through  the keyboard short-cut ALT-TAB
     (I hope the makers of Geneva, MagiC etc. will take after these ideas).
     There are minor  flaws  too,  such  as  the  dialog  box  shown before
     deleting a folder being very  uninstructive  compared to the one shown
     by any TOS version (even v1.0), but this was to be expected I guess.

     The PC itself is of course  a  less  inclusive and integrated piece of
     hardware than an Atari computer,  which  shows itself in various ways.
     For instance, the BIOS power saving  feature is unable to detect MOUSE
     activity, which means I must remember  to  at least press the shift or
     control key once in a  while  to  avoid  that the computer is suddenly
     shut down "in my face" (I  found  this very frustrating before getting
     used to it). On the other hand, it is, of course, precisely this - the
     open  architecture  (allowing  multiple   vendors   to  share  in  the
     development) - that is behind the  PC  success; with a foundation more
     primitive than any other  currently  used  personal  computer it seems
     nevertheless to be on its way to slowly crush all competition.

     The memory of my PC is 8 Mb internally, plus Windows comes with built-
     in virtual memory handling; my  hard  disk  is  "850 Mb" (actually 850
     million bytes = 811 Mb, falsely advertised  as 850 Mb by all retailers
     these days, though still 27 times the  size of my Atari Megafile). But
     as much as this would have been on my ST, it somehow doesn't seem that
     much at all on the PC; it  is  as  if everything took up ten times the
     space on the PC.

     The speed is breathtaking compared to  the  ST,  or at least should be
     when hardware specifications are studied. I  would be lying if denying
     to have actually experienced  this  speed  (e.g.  when ZIP compressing
     files or with various graphics  operations  or,  for that matter, with
     the necessarily very  processor-intensive  task  of  Gemulator), but I
     often find myself waiting for the  PC  and without really knowing why.
     The hard disk  -  in  itself  also  very  fast  -  seems  to be almost
     constantly reading/writing something and I haven't a clue as to what.

     This leads me to the overall sense of being at loss on my PC. On my ST
     I have a fair idea of the purpose of just about each and every file on
     my hard disk, and that of  every  disk  access  too. Not so on the PC.
     There may be many explanations of course including:

      1)     I really AM a rookie on the PC
      2)     Since the  PC  isn't  the  all-in-one  machine  that  an Atari
             computer is (and  the  hardware  and  OS  furthermore built in
             layers over a more primordial  core),  things simply ARE a bit
             more complicated.

     I however strongly suspect a  further  reason:  the tradition of over-
     protectiveness and patronizing attitude  on  the  PC and of Microsoft.
     Anything as complicated as files and  folders is supposed to be padded
     and hidden away from the mere  user. INSTALLATION PROGRAMS, objects of
     intense and unrestrained hatred  from  my  part  on  any computer, are
     immensely popular on  the  PC.  There  are  happy  exceptions, such as
     Gemulator, that come with  no  installation  program and instead allow
     the user full control over the  copying  of files and folders where he
     really wants them. But the ruling philosophy seems to be that the user
     shouldn't bother his little  head  with  what  an installation program
     does  to  his  precious  hard  disk,  and  if  (or  rather  WHEN)  the
     installation program fails, there  is  no  point  in offering a manual
     alternative, since the user is a complete moron anyway.
     PC installation programs have  left  me  with files missing (including
     the Windows 95 installation itself) or worse.

     To be fair to Microsoft, they have  now  taken some steps in the right
     direction; for one thing apparently  requiring  any program that wants
     to be  called  fully  Windows-95  compatible,  to  be  also  fully un-
     installable, ridding the hard disk  from  all  the garbage it may have
     littered it with (though I've  tried  a  few "uninstall programs" that
     didn't work too well). And  they've  also,  very nicely, implemented a
     number of features, that otherwise  would  be hidden in various system
     files and the like, as concrete  files and folders. For example: There
     is a folder for the desktop,  and  when  dragging a file icon onto the
     desktop, a special .LNK file (a kind of pointer to the source file) is
     created in this folder (better even than  on the Atari, where all info
     on the Desktop is hidden in  an  .INF  file). There are other folders,
     e.g. for a start menu (any sub-folders automatically become sub-menus)
     where commonly used programs can be represented in the same way.
     ----------------------------------------------------------------------
     To: Ictari
     From: Thomas Nilsen

     I have written a small example on how the object_change routine can be
     used from GFA. It is not a guideline on how to do RSC-programming, but
     merely an example on how to "de-select" selected buttons in RSC-forms.
     */ See GFA folder.  ICTARI /*

     To: All (Mrten Lindstrm)

     I need some help with a small problem regarding window-clipping.  I've
     written a routine just to figure out how to do non-modal dialog-boxes.
     But I'm having a  problem  getting  the clipping routine correct  when
     my window gets  a  redraw/moved  message  when  it  is behind  another
     window. It redraws the window fine in  most cases, but when part of my
     window is  seen on both side of  the  window topping my window it does
     not redraw correctly.  Sometimes both  the menubar and the dialog-part
     is drawn  over the  topped  window  and  sometimes just the dialog-box
     part. As far as  I  understand,  this  is  due  to  the   limit of the
     object_draw's clipping - as it only  clips  in one rectangular block -
     and  doesn't handle the redraw correctly  when there is more  than one
     block to clip. Or am I totally wrong here?

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