
     ICTARI USER GROUP             ISSUE 40                 November 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 40
                              ==================

     ASSEMBLY        ST Assembly Language Workshop. Chapter 5.

     C               Memory debug utility.

     GFA             Text manipulation/search routines.
                     GFA VDI functions.

     STOS            Line clipping techniques.
                     Lottery program.

     FORTRAN         FORTRAN on the Atari.

     MISC            Falcon register information.
                     Current membership list.

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

     ASSEMBLY

     C               Bezier curve routine.

     GFA             Functions for using ARGV arguments in command lines.
                     File recognition routine.
                     Using the Iconified window Server in GFA.

     STOS            Slideshow program and tutorial.

     FORTRAN         BC-FORTRAN 77 development system.
                     FORTRAN-C compiler.
                     Compiler-Driver for BC-FORTRAN 77.

     MISC            A quick guide to creating an HTML document.

     ----------------------------------------------------------------------
                                   EDITORIAL
                                   =========
     THE FUTURE OF ICTARI
     --------------------
     A few months ago I mentioned  that  I  was  planning to purchase a PC,
     well I have now built my own  system  around a 133MHz Pentium with the
     all the usual bits  and  pieces,  8  speed  CD-ROM,  32Mb RAM, 17 inch
     monitor, 1.6Gb HD, etc, etc. The problem,  as I said before, is that I
     do not have sufficient room to run both  the  PC and the Atari so I am
     going to have to dispose  of  the  Atari hardware, software, books and
     magazines eventually. This means, of course,  that I will be unable to
     continue with the editing  of  Ictari  after  this  year. Although the
     membership has fallen over the last  few  months from about 60 members
     down to about 30 at present,  I  believe the members that still remain
     are quite happy to continue programming  on the Atari and some members
     are still providing useful contributions to the magazine. I would hope
     that Ictari will continue  into  next  year  but  this  will depend on
     someone being prepared to take over my role as editor after Christmas.
     I have the next issue already prepared  which I will send out as usual
     in December but if no one has  volunteered  to take over by then, this
     could be the last issue.

     If you have found these magazines useful over the past three years and
     you would like  to  continue  receiving  them,  then  please seriously
     consider whether you could do the  job  of editor. It is not difficult
     although ideally you do need  a  hard  disk  as  well  as a colour and
     monochrome monitor. Naturally I will be  happy  to assist in any way I
     can and I can probably provide the necessary software and hardware, if
     required. You do not need to spend  a  LOT of time on editing the mag,
     most of the time is spent  just  deciding  what material to include on
     the next disk, preparing this text  file  and then making 30 copies of
     the master disk for despatch which  takes  about an hour. If anyone in
     the UK is interested (and I  sincerely  hope  there is) please ring me
     any time so that we can discuss it further.

     Naturally I am sorry that I have had  to step down as editor as I have
     enjoyed putting the  Ictari  magazines  together  over  the last three
     years but personal circumstances have meant  that  I need to have a PC
     to fulfil other commitments which I cannot do on the Atari. However, I
     do hope that this will not be the end of Ictari, but that is really up
     to you. I look forward to hearing from someone SOON.
     ----------------------------------------------------------------------
                                 CORRESPONDENCE
                                 ==============
     To: Everyone
     From: Jason J Railton
     Re: Stuff...

     I hope you liked  the  two-player  TANKS  game,  from  ICTARI #39.  It
     wasn't a demo.  That was the game.

     I'll try to get my BUZZSAW game  finished soon too.  It's difficult to
     set the difficulty levels just right,  and some of the special effects
     I'd planned for bonuses are proving a little complicated.  I just need
     to spend some time on it.  I  haven't  done  a thing on my 3D maze for
     ages though.

     I'm not really bothered that ST  Format  has finished, as there wasn't
     much in it worth reading over its  last year.  It is a shame, however,
     that the PD, repair and hardware companies have lost their advertising
     space.  Good luck to the new magazine, anyway.

     I won't be getting rid of my ST for a long time, I can assure you.

     Anyway, I've sent in a tutorial on  clipping lines to the screen edge.
     You can use the techniques  in  any  language  that has a line drawing
     command, and if you look on  ICTARI  #31 you'll find some machine code
     line drawing routines written by Peter Hibbs to use them with.

     Run either CLIPPING.PRG or  CLIPPING.BAS  (STOS)  with CLIPPING.TXT in
     the current directory, to read the tutorial.  Step through it with the
     SPACE key.  You can also  send  CLIPPING.TXT  to the printer, but then
     you won't get the diagrams or demos.

     I've already covered rotating lines, and I'll go on to describe 3D and
     perspective for future articles.   Finally,  I'll talk about functions
     such as SIN and COS in machine  code.   (For those who can't wait, you
     use a table of values of INT(16384*sin(r)) in your sums.)

     */ The CLIPPING.PRG program is very  good as it describes the clipping
     techniques used together  with  animated  graphics  of  the functions.
     Unfortunately it bombs out in  Monochrome  but is excellent in colour.
     It would be very useful if this  idea  could be used in other tutorial
     type articles.  ICTARI /*
     ----------------------------------------------------------------------
     To: ICTARI
     From: John Hayward

     I am trying to  write  a  program  that  can  produce touch tone beeps
     through the ST's monitor speaker (like a telephone) using STOS. I have
     tried doing this using sound samples  but  they were not of sufficient
     quality to dial correctly,  What  I  need  is  some  method of playing
     sounds using the Yamaha sound  chip  with  exact frequencies in Hertz.
     The values required are as follows :-

             Frequency       ---------digits---------

               697Hz         1       2       3       (A)

               770Hz         4       5       6       (B)

               852Hz         7       8       9       (C)

               941Hz         *       0       #       (D)

                           1209Hz  1336Hz  1477Hz  1633Hz

     For example, if button 8 is  pressed,  the  852Hz and 1336Hz tones are
     sent out to the exchange to signify digit 8.

     This shareware program is unusual,  I  am  using  it to create a crude
     form of  E-mailing  system  which  does  not  require  a  Modem  or  a
     subscription to an on-line service. If you have access to a television
     with Teletext you can advertise things on a notice board on channel 3,
     page 388/389 and there is  a  place  where  you  can sell computers on
     channel 4, page 435. To  place  ads  you  use  an unorthodox method of
     writing your message, you convert  each  individual  letter into a two
     digit code (A=11, Z=36, etc) and  you  then  call a premium line phone
     number and type in every single code which  takes  about 5 minutes and
     I estimate would  cost  about  2-2.50  per  advert.  My program will
     convert the text message into a series of tones and play them down the
     line at relatively high speeds which  results in cheaper bills with no
     errors. As well as selling hardware on  the ads you can also advertise
     PD libraries, BBSes or whatever so  you  might find the program useful
     to advertise ICTARI.

     */ I think it may be more  difficult  to implement than you imagine. I
     don't program in STOS so I  can't  tell  you  how  to do it using that
     language but I have written a  small  machine code program to test out
     the basic idea and it does not seem to work.

     I suspect there  could  be  several  reasons  that  it  fails  to work
     properly, the main one  being  the  frequencies  that the Programmable
     Sound Generator (PSG) can generate. As you probably know the tones are
     derived from a source oscillator of  125KHz which is then divided down
     by the PSG counters to produce a  range  of tones. The problem is that
     it is not possible to produce  ANY  tone, only an approximation of the
     tone. For example, to calculate the  division  factor for a given tone
     you would use the following formula :-

             divide_factor = 125000/f

     where f is the desired frequency. So  a frequency of 1633Hz would give
     a value of 76 which is  the  value  that  would be loaded into the PSG
     registers for channel A (or B or C). To calculate the actual frequency
     produced you would use the following formula :-

             f = 125000/divide_factor

     If you use the divide_factor value  mentioned above to find the actual
     frequency it calculates as 1644.73Hz  which  is  quite a bit different
     from the 1633Hz required. The other frequencies work out as follows :-

             Required        Divide          Actual
             Frequency       Factor          Frequency

             697             179             698.32
             770             162             771.60
             852             146             856.16
             941             132             946.96

             1209            103             1213.59
             1336            93              1344.08
             1477            84              1488.09
             1633            76              1644.73

     It may be possible  to  fiddle  about  with  the  divide_factor to get
     slightly nearer to the required frequency but I doubt whether it would
     still be reliable enough for general use.

     When I  worked  for  British  Telecom  I  designed  some  equipment to
     generate tone calls and I seem to  remember that the tone detectors in
     the exchange equipment have a tight  tolerance on the tone frequencies
     to avoid cross channel interference. Also the tones must be reasonably
     good sine  waves  with  very  little  distortion  to  ensure  reliable
     detection.  This  may  be  another   problem  with  your  scheme,  any
     distortion introduced into  the  sounds  will  make  it less reliable.
     Another factor is phase difference  between  the  two tones which also
     has to be within certain limits.

     It may be possible for other  computer  platforms  (such as the PC) to
     generate accurate tones but  I  don't  think  the  Atari is capable of
     doing this unless you  can  use  the  D-A  converter  in the STE using
     sampled sounds. You said that this  did  not  work but how exactly did
     you do it. Presumably you sampled the tone output from a telephone and
     played them back using the D-A converter chip in the STE.

     Probably the best way to achieve your  aim using the Atari would be to
     use the tone  generator  chip  which  is  used  in  telephones  and is
     available for a few  pounds.  The  chip  could  be controlled from the
     Atari parallel port to generate the required tone pairs but this will,
     of course, require some hardware building  on  your part. If you would
     like further details of the chip let me know.  ICTARI /*
     ----------------------------------------------------------------------
     To: ICTARI
     From: Mark Foot

     Can anyone suggest a method of  having  a library of SmartIcons as per
     Windows, whereby  a  user  can  select  those  he/she  wishes  to have
     available within a program. I am writing a 'programming language' in C
     for a robotics project  and  I  would  like  user selectable tools via
     icons.

     Has anyone managed to fit a second  serial  port to a 520ST? If so any
     hints and tips on hardware and software aspects would be appreciated.
     ----------------------------------------------------------------------
     To: ICTARI
     From: Charles Ayres

     In your last issue  of  ICTARI  there  was  a  request for information
     regarding PAGE 6 magazine for the Atari 8  bit. I am happy to tell you
     it is still going strong thanks to Les Ellingham and Sandy (his wife).
     It is now called Page 6 New Atari  User as Les took over the old ATARI
     USER magazine when  it  went  out  of  production.  Unfortunately this
     magazine is  now  printed  in  A5  format  and  is  only  available on
     subscription from :-

             PAGE 6
             PO BOX 54
             STAFFORD
             ST16 1DR

     Annual subscription rates are as follows :-

             UK MAGAZINE ONLY (6 ISSUES)      15.00
             UK MAGAZINE WITH DISK (6 ISSUES) 25.00
     ----------------------------------------------------------------------
     To: Peter Hibbs
     From: David Preston

     Thanks for your additional comments re  WordGrid.  I have to admit I'm
     no wiser (more puzzled if anything)  about the problem with Mortimer's
     print  spooler.  I  use  Hisoft's   spooler  (HSPOOLER.PRG)  from  the
     "Introduction to Programming Utilities"  pack,  and there doesn't seem
     to be a problem with  that  one.  I  don't  have Mortimer though, so I
     can't try that out. Is  Mortimer  usually  co-operative? (I suppose it
     must be or you'd use something else!)

     To: *.*

     What about everyone else  -  any  other  problems  with WordGrid, with
     print spoolers or w.h.y.? Or any similar problems with your own Hisoft
     Basic progs?

     To: STOS programmers

     What a swiz! (Is  swiz  a  real  word?)  Anyway,  I was fiddling about
     converting a GFA listing of a fractal (Mandelbrot set) generating prog
     from an ancient coverdisk,  into  STOS.  It  worked  ok but slowly (no
     surprises there, then!) so I set  about  optimising it a bit. I'd used
     nice structures (repeat...until etc.) originally, but found that nasty
     goto's and stuff were significantly quicker. It's all very well trying
     to write decent looking code,  but  if the language doesn't co-operate
     you're spragged. (Now that _is_ a real word.)

     One thing that did emerge  however  is  that  it's much quicker if you
     have to use floats in  your  maths  to  use  _all_ floats. Or at least
     don't have a mixture of  ints  and  floats in individual calculations.
     Even for...next loops should count  in  floats  if the counter is used
     with floats in a  calculation  within  the  loop.  I  think the manual
     suggests that mixing number types  in calculations is inefficient, but
     sometimes you need to discover the truth of these things for yourself!

     To: Kevin Cooper
     Re - Subject DLL's

     I'm not sure what you mean by "the standard graphic format will be the
     standard device independent format"  -  surely  something like the PNG
     format as described in Ictari recently  would  be an ideal choice? RTF
     would seem right for WP, but  spreadsheets  are a more complex matter,
     as different applications  have  different  features/functions etc. It
     depends if you want to  just  transfer  data  (where  a DIF file might
     suffice) or have a common (standard) data file format to save formulae
     etc. And bear in mind  that  some  software producers (eg. Lotus) have
     been  known  to  be  less  than   chuffed  about  people  using  their
     standards...

     To: UK members

     With this new Channel 5 in the offing, and the need to retune VCR's to
     avoid a clash with the new channel,  does anyone know if/how this will
     affect those of us using our ST's on a telly?

     */ I find Mortimer very useful actually  although  it needs to be on a
     hard disk to be practicable.  It  provides  a reasonably good and very
     fast text editor as well  as  a  number  of  other handy facilities. I
     would be happy to send you my copy  with  manual if you want to try it
     out with your program, let me  know  if you want it. Alternatively you
     could just mention the problem in  the document file with your program
     and let the end user disable the spooler.  PDH /*
     ----------------------------------------------------------------------
     To: Kevin Cooper and everybody else
     From: Mrten Lindstrm

     VRML
     ----
     If you do implement a VRML browser, I  think you will be really in the
     forefront of things. I had personally never even heard of VRML until I
     read your message. However, with  the  help  of  Alta Vista, I quickly
     found the specification for VRML 1.0 (in HTML format) on the net - and
     I have now sent it to  Ictari.  It  sounds  like  a very nice idea but
     probably a lot of work to implement.

     To others who also didn't know what VRML is, and still don't:

     VRML (Virtual Reality Modelling Language) is a language for describing
     a "world" of 3D objects (and light  sources etc.) of which some may be
     possible for the user to  manipulate  (presently  only  in the form of
     clickable links - to other VRML worlds or  to HTML texts - but this is
     intended to be developed in the future).

     VRML has got absolutely  nothing  to  do  with  HTML (HyperText Markup
     Language) or SGML (Standard  Generalized  Markup  Language  - of which
     HTML is an application), except that  its name was originally inspired
     from them. VRML doesn't compete  with  them.  HTML  and SGML deal with
     TEXT documents, VRML with 3D worlds.

     To: Ictari Editor, Article Writers and Readers
     From: Mrten Lindstrm
     __________________
      HTML FOR ICTARI?
     
     It seems to me that things are definitely moving towards more and more
     HTML. And I am not just speaking  of the Internet where new specifica-
     tions etc. seem to be often  provided  ONLY in HTML format. Even else-
     where, such as on  software  distribution  disks  - where README files
     etc. used to be only in plain  text ("ascii"), you will now often find
     alternative HTML versions.

     HTML (with a good browser)  not  only  allows documents to LOOK better
     but can sometimes even  add  to  the  information contents. Where, for
     instance, programming syntax  is  described  in  printed books, ITALIC
     style is often used to  denote  a  VARIABLE;  this  can be very easily
     translated into HTML markup but will be lost in plain text.

     Being able to use  different  HEADING  LEVELS  (displayed in different
     font sizes) can also be very helpful to make a presentation clearer.

     And, of course, HTML allows PICTURES to  augment the text. Back in the
     distant past (Ictari 10) our  Dear  Editor  did  raise the question of
     whether Ictari should  change  from  plain  text  to  something richer
     allowing pictures (apparently without much  positive response though I
     am not to blame 'cause  I  hadn't  yet  joined),  but, of course, HTML
     wasn't an option back then (before the Atari HTML-Browser).

     In addition to all this, HTML has some further advantages:

            It is non-proprietary. Bound to neither a software company nor
             a specific platform. (And, again, its support is only rising.)

            Good HTML browsers come as _FREEWARE_ (both on Atari and PC).

            It is viewable as plain text too (no control characters used).
             Admittedly not quite as neat-looking as a dedicated plain text
             file could be. But since  both  newlines and extra spaces will
             be ignored by the HTML  browser,  they  can  be freely used to
             adorn the layout  of  the  text  when  viewed as uninterpreted
             "ascii".

            It is  very  SIMPLE  TO  WRITE  HTML  documents  with  no more
             software than a plain text editor. REALLY, it IS!!!

             I have written a brief "quick and dirty" guide to converting a
             plain "ascii" text to HTML, and could perhaps write a more in-
             depth article on  HTML  too,  if  there  is  interest  for it.
             Perhaps making that article in HTML format :-)

             I have also sent in  the  specification documents for HTML 2.0
             and 3.2, the latter actually  being  a  bit more accessible, I
             would   say,   though    lacking    some    explanations   and
             recommendations of the HTML 2.0  docs. (See some further notes
             below.)

            HTML is per definition  highly  adaptable  to  any display (or
             even to speaking machines)  or  user  preferences. If you have
             ever used CAB or HTML-Browser you can  see how it, on the fly,
             reformats the text to  fit  whatever  window width you choose,
             and this is how any browser  should work. (Thus, you SHOULD be
             able to browse even on an ST low-resolution screen - 320x200.)
             You sometimes hear that  you  need  an  800x600  display to go
             browsing the Web. This is CRAPTALK!!! It may be true that some
             lousy authors  use  unnecessary  large  pictures,  as  well as
             various effects created with unsound  or even outright illegal
             HTML constructs, to cover up poor text contents. But good HTML
             should be written to be  enjoyable  even on very small screens
             (there ARE Macintosh Classic  users  out  there who browse the
             Web with apparently not more  than 460 monochrome pixels width
             available).  And  it  should  (as  far  as  possible)  provide
             alternative meaningful  text  for  those  who  -  for whatever
             reason - cannot see the graphics.

     In fairness, the last of these advantages may also be seen as a disad-
     vantage: HTML is NOT a page  description  language. It is used to mark
     up the PURPOSE and MEANING of various parts of the text, and leave the
     display for the browsing software  and  human  to decide on. Thus HTML
     lacks a legal and sound method for  such a simple thing as indenting a
     text section (though self-brewed  solutions  abound, one more horrible
     than the other). And so  you  may  perhaps prefer something like Post-
     Script, Acrobat or maybe even  RTF  for  a printed document with well-
     defined layout, page breaks & numbering etc.


                                ''~``
                               ( o o )
                     ,-----ooO---(_)---Ooo-----.
                    /                           \
                   /   SO, WHAT DOES EVERYBODY   \
                  (       THINK ABOUT USING       )
                   \    MORE HTML IN ICTARI ?    /
                    \                           /
                     `-------------------------'

                      Some follow-up questions:
                      
            Does everybody have a copy of CAB or HTML-Browser?
             (It IS freeware you know.)

            Are you HAPPY with CAB /HTML-Browser?
             I find CAB to compare amazingly well with the PC's MS Internet
             Explorer (which  I  must  admit  is  what  I  use  for  online
             browsing) and Netscape, though there are a few weak spots:
             - For one thing, CAB seems strangely unable to make proper use
             of the ordinary ST  low  resolution  (320x200  in 16 colours).
             Outline font sizes don't  match  the  system  bitmap font size
             well (though to some extent explainable by how GDOS/NVDI deals
             with it) and, very oddly, CAB doesn't  seem to make use of the
             COLOUR!!! A REALLY GOOD  browser  should  work equally well in
             any resolution, taking advantage of what colours there are.
             - CAB also doesn't  seem  to  keep  more  than one document in
             memory at a time. Caching pages in RAM could save considerable
             time when jumping back and  forth  -  e.g.  between a table of
             contents and the "contents" (sub-documents).

             I  am  (possibly)  considering  writing  an  alternative  HTML
             browser with the following specifications:
             +       Small(er than CAB) - possibly  so  small that it could
                     even fit on each and every Ictari disk (?).
             +       Fast(er than CAB (?) )
             +       Taking full advantage of ST  low resolution as well as
                     any other resolution.
             -       Simple. Bare minimum  of  functionality (definitely no
                     support for online Web browsing) and perhaps initially
                     not supporting some more  advanced  HTML features such
                     as the tables of HTML 3.
             Would there at all be any need for such a program?

     To: All
     From: Mrten Lindstrm

     HTML versions (again)
     -------------
     Since last month I have found out some more on this topic and it seems
     that the real reason that HTML 3.0. was abandoned was that

      a)     - Producers of HTML browsers were too lazy to implement it and
             instead thought  it  more  fun  to  implement  their  own non-
             standard extensions.

      b)     - Illiterate  people,  knowing  nothing  about  the  HTML  3.0
             specification  but  styling  themselves   "web  designers"  or
             something similar, took on  the  habit  of calling their sites
             "HTML 3.0 enhanced" when in reality  they had just jammed some
             non-standard extension  into  their  HTML,  supported  only by
             their personal favourite browser.

     From another (and kindlier)  perspective,  one  could perhaps just say
     that the HTML 3.0 specification was too big and ambitious.

     HTML 3.2 is thus much smaller  than  3.0  and is furthermore largely a
     result  of  "reverse  engineering"   of  existing  extensions  (though
     adapting these for coherence  among  browsers  and compliance with the
     SGML foundation of HTML where this was  violated). Most of HTML 3.2 is
     therefore already now supported by the newest browsers - including the
     Atari CAB - AND there is  also  validation software (for PCs at least)
     and services available to certify HTML 3.2 compliance of documents.

     Non-ascii characters in HTML
     ----------------------------
     Last month I said that the British  pound sterling symbol () could be
     represented as  &pound;  in  HTML.  It  seems  however that this isn't
     strictly in the HTML specification (neither  2.0 nor 3.2) though it is
     RECOMMENDED in the HTML 2.0  document.  In  practice  it seems that at
     least the browsers I have tried DO understand  &pound;

     Generally, a character can in HTML  (and  SGML) be expressed in one of
     THREE ways:

            directly as a character (byte)   e.g.   
            as a "numeric reference"         e.g.   &#163;
        as an "entity reference"         e.g.   &pound;

     Since the CHARACTER  ""  IS  in  the  HTML  character  set  - at code
     position 163 - the first two  methods  should always work. I.e. &#163;
     will unambiguously be interpreted as a pound symbol by ANY truly HTML-
     compliant browser on any  platform,  and  so  will  the character with
     number 163 (that appears as ""  in  the Atari character set, so Atari
     browsers need to translate it before display).
     The third  method  however  formally  requires  that  the  "entity" be
     defined in the so-called DTD for  HTML (DTD = Document Type Definition
     - an SGML term for what  essentially constitutes the definition of the
     HTML language, or at  least  a  significant  part  of it). And "pound"
     isn't (yet?).

     The  same  thing  applies   for   most  other  "extended"  (non-ascii)
     characters (including overline " ")  EXCEPT  the modified LETTERS, all
     of which have entities defined  for  them ("M&aring;rten" is in strict
     conformance with HTML :-)).

     Of course the most  compact  and  perhaps  simplest  method  is to use
     direct characters - remembering to use  the "ANSI" (aka ISO 8859-1 aka
     Latin-1) character set.
     The major reason not to do that  is if one fears that 8-bit characters
     might be  corrupted  during  electronic  transmission.  This  isn't  a
     problem if documents are distributed by disk of course, but it is also
     not a problem if the document  is  placed  on a typical WWW site using
     the HTTP protocol,  since  this  protocol  preserves 8-bit characters.
     Other protocols can cause  problems  though,  and conversions by local
     networks between different character sets  might possibly also corrupt
     8-bit characters.

     To: Kevin Cooper
     From Mrten Lindstrm

     ATARI STANDARDS FOR DATA FORMATS
     ================================
     The only data types for which  there  is  any standard - AS DEFINED BY
     BUILT-IN TOS SUPPORT - are, I'm afraid, pictures.

     Apart from bitmap images, supported  via  VDI  call vr_trnfm (and then
     the other raster  functions)  as  well  as  -  on  printers and memory
     devices only - v_bit_image, TOS  can,  of course, handle VECTOR images
     supplied as GEM metafiles (.GEM) files - i.e. a series of recorded VDI
     commands, to be replayed on screen or printer.

     There actually isn't any one function that simply can take a .GEM file
     as input and play it. (Maybe such a function would be a useful project
     for a DLL?) Instead  each  VDI  command  of  the  .GEM  file has to be
     interpreted and played individually.

     For text, the only  real  standard  is  plain  "ascii"  text - without
     formatting controls. There is no built-in  TOS support neither for any
     richer text format nor for a spreadsheet or database format.

     When  exchanging  data  via  the  clipboard  or  -  with  MultiTOS  or
     compatible - the  drag-and-drop  protocol,  the  exporting application
     generally has to offer the same data  in  a variety of formats for the
     importer to choose from. In the case of text, a plain text file should
     definitely be one of the  offered  formats,  but  for richer text .1WP
     (1st Word Plus), RTF  (Rich  Text  Format)  and  nowadays perhaps most
     important  .HTM(L)  would   be   among   the   most  widely  supported
     alternatives.

     When creating "DLL" import functions, on the other hand, each function
     could of course be defined to  convert only to one, especially useful,
     format. (Again, possibly HTML for text (?)).

     One useful project would, I think,  be  routines that try to translate
     between .GEM metafiles and PostScript. I  have personally not seen the
     specifications for PostScript and I am  too  mean to buy a book. Maybe
     someone would write an article on PostScript?

     To: Pete Bailey
     From: Mrten Lindstrm

     I don't know the answer to your main question, as to what method would
     be best to change the  Atari  drop-down  menus into pull-down menus. I
     have got something called ST Control  (which  I haven't used much) and
     which came with a utility that  I  think  did  just that - and working
     fine on my ST as I recall it. So I guess it SHOULD be possible somehow
     (maybe I shall have a look at that program again).

     Your desperation is an echo of  mine  when  I was trying to coerce TOS
     into changing the system font  (the  result  of  which was my PC_LINES
     program, published in  an  earlier  Ictari).  This  change  too  has a
     tendency to be inexplicably reset.  I  guess this is almost inevitable
     with any such type  of  "unforeseen" system configuration, unsupported
     by solid high-level functions and requiring semi-clean means.

     As to some of your secondary questions:

      Q:     Is XBRA worth losing sleep over?

      A:     XBRA probably won't provide any help  in  this. As long as all
             programs adhere to it,  it  makes  it  possible  to simply and
             cleanly uninstall vectors as  well  as  to  detect  all of the
             previously installed programs. But when  TOS (at least all the
             older versions) install  vectors  it  will  probably disregard
             XBRA completely.

      Q:     Does Katherine Peel mean  that  interrupts  should be disabled
             during installation only or for  the  full duration of the new
             vector?

      A:     Definitely  during  the  installation   only.   If  you  leave
             interrupts disabled almost nothing  will  work - including the
             keyboard and certainly the GEM mouse.

     To: Peter Hibbs

     STYLE OF ASSEMBLY LISTINGS
     ==========================

     Oh dear, and I have always thought that my way of writing was the most
     readable that could possibly ever be  :-).  It goes to show that taste
     is a very personal thing. Or as we like to put it here in Sweden:

                                Smaken
                             r som baken
                               - delad.

             ( In English:        Taste
                          is like the behind
                              - divided.      )

         (Sorry about this piece of poetry, but I couldn't resist it.)

     I am quite certain that my  habit  of  writing register names in upper
     case did not originate in my own  twisted  mind, but I am less sure of
     from where I got it. The disassembled  BIOS listing in the Abacus book
     "ST Internals" is written in the same style though.

     Back when, trembling and insecure, I  wrote my first lines of assembly
     code I found some comfort  in  this  way  of marking register names as
     something quite different from mere  memory  labels etc. This was back
     when I was still confused that "a7" could also be written as "sp".

     Since then the habit has stuck, and I even often (as a kind of therapy
     while collecting my thoughts) convert imported  pieces of code to this
     style, more familiar to me. I suppose  you are right of course that it
     must slow down my typing,  but  I  have  never reflected much on that.
     Maybe it only  slows  down  the  speed  of  my  typing  to  that of my
     thoughts. I feel a need to put  some  thought in just about every line
     of assembly code to ensure it's OK.

     It had honestly never occurred to me that anyone could find this style
     DETRIMENTAL to readability. Though -  when  thinking  about it - it is
     only natural of course for everyone  to  prefer  what one is most used
     to. So  from  now  on  I  will  start  making  sure  that  my assembly
     contributions conform with the predominant style of all lowercase.

     */ Mrten, I didn't mean to  imply  any  criticism  at all, as you say
     ones style of writing code is usually  a matter of taste, I was merely
     interested in your reason for using  caps.  I also use capital letters
     for some parts of my code, i.e. assembler directives (MACRO, ENDM, IF,
     ENDIF, etc) and object names (FORM_LIST,  etc) mainly so that they are
     easy to find when scanning through a listing.

     You mentioned the PostScript language,  I  have  bought a book on this
     language with the same  idea  in  mind  but  I  soon  found that it is
     unbelievably complicated and I didn't understand much of it at all. It
     is basically a language built into the file, for example, a PostScript
     font is not like  a  Calamus  font  which  just  defines  a set of co-
     ordinates and simple commands, a  PostScript  font  seems to be a mini
     source code that tells the PS interpreter how to process the font data
     to draw the character image. Any  code  you  would need to write would
     have to be an interpreter  (like  a  BASIC  interpreter) with about as
     many commands and functions, no mean feat. If you would REALLY like to
     see the book I would be prepared  to  lend  it to you provided you are
     willing to pay the postage charges to  and from Sweden and it is quite
     a heavy book, over 700 pages.   PDH /*
     ----------------------------------------------------------------------
     To: All
     From: Peter Hibbs

     In Ictari issue 9 I published a  set of TOS Macros (TOSMACRO.S) and it
     has just come to my  notice  that  there  is  an error in the f_datime
     MACRO that reads the date/time stamp  on  a disk file. The code should
     be amended so that it reads as follows :-

     f_datime        MACRO                   1\mode,2\fhandle,3\buffer
                     move    \1,-(sp)
                     move    \2,-(sp)
                     move.l  \3,-(sp)
                     gemdos  #87,#10
                     ENDM

     I should point out that this was  not entirely my fault, the source of
     my information was the  Atari  Internals  book which incorrectly shows
     the second and third arguments reversed  in the example code, hence my
     error. I then checked the Compute! book volume 3, The Atari TOS, which
     shows the arguments correctly but then  states  that the first word of
     the buffer holds the date and the  second  word holds the time when it
     is, in fact,  the  other  way  round.  Next  I  looked  at the Concise
     Programmers Guide by K Peel (Aug 86) which also shows the wrong buffer
     allocation and in addition  has  the  flag  settings reversed as well,
     i.e. it shows 0 for set and  1  for  read which is the opposite of the
     correct  values.  The  Atari  Compendium,  however,  shows  everything
     correctly  although  it  does  not  give  any  help  to  machine  code
     programmers. I think the moral  of  this  sorry  tale is DON'T BELIEVE
     ANYTHING YOU READ IN A BOOK UNTIL YOU HAVE CHECKED IT YOURSELF.
     ----------------------------------------------------------------------
     To: ICTARI
     From: Theo Ros

     Is there anyone who can explain how picture dithering is performed.

     */ I think this question has  been  asked  before and nobody knew then
     but if anyone does, write in soon. ICTARI /*
     ----------------------------------------------------------------------
     To: Everyone
     From: Owen Rogers

     I'm afraid I've finally decided to hang up my mouse and move to the PC.
     I like my programs to be used, not  sit around in a PD Library so I've
     bought MS Visual Basic for my PC. This is just a thank you to everyone
     at Ictari  for  helping  me  finally  release  my  first  GEM  program
     MUSICBASE and really everyone I've talked   to  and who have helped me
     (Including LAPD, Floppyshop and those great  people  who sent me those
     STOS manuals).  I don't think   I've   met such  friendly  and helpful
     people than in  the  Atari   community.  Thanks again to everyone I've
     known and met and especially to LAPD who were the only people who took
     a 13 year  old  boy  (me!)  from  the  Welsh  valleys  seriously about
     programming!  If there  is  anyone  out  there   who   has  one  of my
     programs that  needs  registering, don't bother!

     So now in the words of Sooty I'll say..

     BYE, BYE EVERYBODY
     BYE, BYE

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