Fujiology Archive/fujiology_archive_v1_0.iso/!MAGS/ICTARI/ICTARI24.ZIP/ICTARI.TXT

Text File | 1995-07-14 | 37KB | 656 lines

     ICTARI USER GROUP             ISSUE 24                     July 1995

         ___   ______     ___       _________   _________   ___
         \__\  \   __\    \  \__    \______  \  \   _____\  \__\
           ___  \  \       \  __\     _____\  \  \  \         ___
           \  \  \  \       \  \      \  ____  \  \  \        \  \
            \  \  \  \_____  \  \____  \  \__\  \  \  \        \  \
             \  \  \       \  \      \  \        \  \  \        \  \
              \__\  \_______\  \______\  \________\  \__\        \__\

                     *   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. [phone]
     =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

                              INDEX FOR ISSUE 24
                              ==================

     ASSEMBLY        Floating Point routines (needs fixing, see below).
                     Picture conversion package (PICPAC) update.

     C               Bouncing Ball demo program.
                     Tim Oren GEM Tutorial. Part 13. A new form manager.

     GFA             Naval Battle Game program.

     STOS            Variable to string converter code.

     MISC            Chain program.
                     Using the Atari clipboard.
                     Current membership list.
                     Index for issues 1-23.

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

     ASSEMBLY

     C               Tim Oren GEM Tutorial. Part 14. User interfaces.

     GFA             Weller Tools utilities.

     STOS            Print examples using M Cubitts STOS extension.
                     STOS loader program, etc for Missing Link Extn.

     MISC            Mårten Lindström, GEM Guide. Part 1.
                     How GDOS works.

     ----------------------------------------------------------------------
                                   EDITORIAL
                                   =========
     TEAM GAME
     ---------
     Congratulations to Ralph Lovesy  on  the  good  reviews  that his Team
     football game is getting in the  glossy magazines, perhaps he will now
     write a decent cricket game for  the  ST, the existing ones are pretty
     pathetic. It would also be interesting to know the problems of getting
     a program on the  market,  perhaps  Ralph  would  write an article for
     ICTARI  about  the  processes  involved,  i.e.  programming,  artwork,
     advertising, packaging, etc, etc.

     PUBLICITY
     ---------
     This month we have been in contact  with Atari World magazine who have

     promised to publish  an  article  about  ICTARI,  probably  in issue 5
     (August 95). Hopefully this will bring in a few more members.

     Thanks also to a couple of  members  who have sent in MicroMart advert
     pages. We send one advert  to  MicroMart  each month when the magazine
     disks are sent out. If you buy the MicroMart magazine, please save the
     advert pages for us and send them in when you have a few.

     PICPAC UPDATE
     -------------
     In ICTARI issue 16  we  published  a  set of picture packing/unpacking
     routines by Mårten Lindström. Mårten  has  now  sent  in an update for
     these routines which now includes  code  for  GIF  and TIFF formats as
     well as GFA routines and  advice  on  using them with other languages.
     All the articles and source code can  be found in the ASSEMBLY folder.
     We would also like to  hear  from  anyone  who  uses these routines in
     another language such as C, Pascal, etc. Also in the same folder is an
     article and code  for  converting  GEM  colour  palettes  when loading
     picture files.

     NAVAL GAME
     ----------
     In the GFA folder is a PD  Naval Game program which has an interesting
     speech synthesis option. Since I  don't  know  much about GFA Basic it
     would be useful if a  GFA  expert  could  provide some example code in
     another language (C or Assembler perhaps) on using the speech program.
     The speech generator itself appears to  be a separate .TOS program and
     so could presumably be used  from  any  language  and even as a stand-
     alone program.

     FOR ASSEMBLER PROGRAMMERS
     -------------------------
     In the ASSEMBLY folder is some  source  code  of a package of floating
     point arithmetic routines  which  were  taken  from  the November 1985
     issue of Personal Computer  World  magazine.  Unfortunately I have not
     been able to get them to work and  I hope that someone will be able to
     do this for us as they could be quite useful. The code has been copied
     exactly as it appeared in the magazine with all the comments that were
     published and it has  been  checked  over  for mistakes several times.
     Also, as far as I know, there were no subsequent articles published in
     later magazines to correct any errors.

     The author does  not  give  enough  detailed  information  on  how the
     floating point numbers are represented in  binary format and also does
     not provide any routines to  convert  from  normal  ASCII format to or
     from the floating point  format  which  would  also  be necessary in a
     practical program.  If  anyone  can  get  these  routines  working and
     perhaps write some  ASCII-FP  conversion  routines,  we  would be very
     grateful.
     ----------------------------------------------------------------------
                                CORRESPONDENCE
                                ==============
     To: ICTARI
     From: Steve Gale

     Does anyone know of any 'legal' way to stop 'overshoot' when scrolling
     through a document, i.e.  stopping  the scrolling sequence immediately
     when the up or down arrow  key  is released. Presumably this is caused
     by the keyboard buffer storing keypresses  even after the key has been
     released.
     ----------------------------------------------------------------------
     To: *.*
     From: Terry King

     Does anyone know much about  the  Falcon  hardware  ?  In particular I
     would like to know how to use  the  sound,  I believe that the STE DMA
     sound commands are  not supported on  the Falcon which means STE games
     run in  silence, is this true ?

     I  tried  out  a game  I  am  writing  on  a Falcon and  although  the
     game played,  the   display   seemed  to  give  quadruple vision  with
     messed  up colours.  I  was   using  an  STE  to  write it and it  was
     using  hardware scrolling and writing  to the video address registers.
     Should I put the Falcon in some specific mode for it to work ? (Please
     no "use backward"  answers  as  I  want  the  game  to  work directly,
     without the need for  any patch programs).

     Also,  what's the best way  to  check  whether the machine the program
     is running  on  is a Falcon ?   Would it be something like the  cookie
     jar variable _MCH containing the value 30 ?

     */ The Falcon has the same DMA sound  chip  as the STE (as well as the
     DSP) and the hardware  addresses  are  the  same.  I  suspect that the
     Falcon has to have  additional  initialisation  before  it can be used
     (which  is  probably  what   'Backward'   does.   Perhaps  our  Falcon
     programmers can give us more  info.  In  ICTARI  issue 15 Paul Brookes
     published some code using the DSP in C which may also be of interest.

     In ICTARI issue 5 Simon  Rigby  published  an assembler routine called
     WHATTOS2 which detects which TOS is  being used, what type of computer
     the program is running on  as  well  as  a number of other parameters.
     Perhaps you could modify  this  routine  to  do  what  you want, if it
     doesn't do the job, let us know.  ICTARI /*
     ----------------------------------------------------------------------
     To: *.*
     From: Dick Teuber

     Can anyone help me on how to use  machine code in Lattice C. I want to
     include a small block of machine  code  within  the source code of a C
     program and not link in  with  an  Object  file.  I  also need to pass
     parameters from C  to  the  CPU  registers  and  stack.  The Lattice C
     manuals seem to be very unhelpful on how to do any of this.
     ----------------------------------------------------------------------
     To: Ictari
     From: Mårten Lindström

     PRINTER DRIVERS
     ===============
     Like Simon Rigby I think  that  any  printer  driver  system has to be
     viewed in relation to  GDOS,  since  GDOS  (allowing  standard GEM VDI
     operations to work on the printer  as  well  as on the screen) already
     constitutes a 'universal  printer  driver'  system  for TOS computers,
     conveniently usable by the application programmer.

     I think standards  should  be  stuck  to  unless  there  are very good
     reasons against it, but GDOS  does  have  a  number of drawbacks which
     might motivate an alternative system. On the other hand I can see some
     solutions too.

     The drawbacks to GDOS first :-
     ------------------------------
      1)     No GDOS version is freeware,  as  far  as  I know, which means
             that  some  licensing  agreement  with   Atari  is  needed  to
             distribute programs with GDOS included.  Many or most ST users
             probably  already  have   some   GDOS   version  lying  around
             somewhere, got with a magazine  cover  disk  or with a program
             bundled with the computer.  But  you  would  of course like to
             guarantee some basic printing capabilities to any user, and if
             your own program is  shareware  or  even freeware you wouldn't
             want to pay Atari much or anything for distributing the stone-
             age old GDOS 1. On the other hand Atari may be reasonable with
             this (The $500 mentioned by D N  Wheeler in his text from 1988
             must be history long since).  Does  anyone have any experience
             or knowledge?

      2)     I have found no documentation  on  writing GDOS drivers in TOS
             books of mine (though  gained  some insight from disassembly),
             and writing a GDOS driver  from  scratch  is probably no small
             task in any case.

      3)     The VDI/GDOS  offers  rather  limited  support  for  character
             oriented "alphanumeric" output.  Graphic  output  is of course
             much more flexible,  but  simple  character  output  is  a lot
             faster and potentially could give  as good-looking results for
             plain text. On the other hand  there  DOES exist a VDI command
             V_ALPHA_TEXT, unknown to me until I read the Compendium, which
             allows character output to a  printer including the setting of
             all common printer styles and  densities, though most of these
             features are apparently unsupported  by current drivers. There
             are no definitions for  font  changes  or support of justified
             text, however.

     And some solutions :-
     ---------------------
      1)     In worst case, it may not  be  an insurmountable task to write
             our own GDOS replacement. The basic  GDOS release 1.1 is not a
             very big program (and  not particularly effectively programmed
             either). I have disassembled it  and think I understand almost
             completely everything done by this program.

      2)     Regarding the programming of the GDOS  driver itself I think I
             have deduced, from the disassembly  of GDOS, what rules should
             apply (see below) though, official documentation would be most
             helpful.

             While the complete programming from  scratch  of a GDOS driver
             isn't a days work I think  that  it might be possible to split
             it  up  in  stages.  I  haven't  disassembled  (at  least  not
             completely) a GDOS driver yet, but I would imagine its various
             VDI graphic routines draw their  output  on an internal bitmap
             (this may be done in 'strips'  to  save memory), which is then
             sent to the printer,  translated  into the appropriate printer
             codes.

             It thus may be possible to  write  the core code for sending a
             bitmap (and character output) to printers in one step, and add
             the complete  GDOS  'driver  shell'  later.  Furthermore  this
             shell, once written, may conceivably  be used with any printer
             driver.

      3)     A solution to the  limited  support for alphanumeric character
             output, is  of  course  to  introduce  our  own  extensions to
             V_ALPHA_TEXT (extra escape  codes)  or  possibly  even add new
             calls. This would not be ideal  but better than not supporting
             GDOS at all.

             If needed, a driver could  perhaps  also make some information
             on  e.g.  accessible  fonts,   character   width  tables  etc.
             available to the program  outside  of  the  VDI  system (via a
             cookie in the jar).

     The UPD system of Peter Hibbs in relation to this :-
     ----------------------------------------------------
      1)     Until we have a freeware  GDOS (replacement) this is obviously
             a strong point in favour of UPD as a separate system.

      2)     Likewise the simple configuration  commands  envisaged in your
             UPD specification, would be a vast improvement to the gruesome
             task of writing a complete  GDOS  driver for each new printer.
             If, on the  other  hand,  this  flexibility  was  built into a
             'Universal _GDOS_ Printer Driver'  it  might  possibly be even
             better.

      3)     Had UPD been  aiming  at  making  universal  the advanced non-
             graphic capabilities of  e.g.  Protext  printer  drivers (font
             changes and justified  text),  this  would  have  been another
             argument for UPD as a separate  alternative to GDOS. As it is,
             many or most of  the  UPD  style  commands  seem to have their
             counterpart in escape codes defined  with the VDI/GDOS command
             V_ALPHA_TEXT. Which instead speaks  in  favour of adapting UPD
             to support GDOS.

             The ability with UPD to select a lower-than-maximum resolution
             for graphics output is a nice (speed-gaining) feature that may
             be difficult  to  make  general  use  of  within  the VDI/GDOS
             context where  each  workstation  is  supposed  to  have fixed
             resolution and dimensions. On  the  other  hand  it would with
             some commands - for instance with  V_BIT_IMAGE to print an IMG
             file (scaled) - be possible  to  let  a GDOS driver internally
             decide on a lower resolution.


                 ≈≈≈≈≈≈≈≈≈≈≈ PROPOSITION: GDOS UPD ≈≈≈≈≈≈≈≈≈≈≈

     - To everybody: How  about  expanding  the  UPD  into the joint Ictari
     project of creating a 'universal _GDOS_  printer driver' ?  I would be
     prepared to help with writing a  freeware GDOS replacement (if needed)
     or with the GDOS driver itself. Regarding the driver I think it may be
     possible to split this up  in  one  part responsible for outputting to
     the printer (essentially the UPD  of  Peter Hibbs), and other routines
     converting the VDI commands  into  drawing  on  a bitmap, though there
     must of course be some main routines  too, keeping it all together. If
     anyone has any documentation on GDOS  driver programming this would be
     most welcome. I will continue to  disassemble an existing GDOS printer
     driver to see what I can find out.

     - To Peter Hibbs: Would you be willing to adapt UPD to support GDOS?
     I do think this would  increase  its potential usability even further,
     though I appreciate the amount of  work you have already invested into
     UPD (and, regarded on their own or  in  relation to BIOS, I found your
     function definitions  and  calling  interface  very  well  thought out
     indeed).

     Adaptation to GDOS would partly mean making UPD mimic VDI/GDOS calling
     procedures  more  closely   (to   simplify   things   for  application
     programmers changing between 'non-GEM UPD' and GDOS). But the ultimate
     aim would be to prepare it to  execute  VDI commands as part of a GDOS
     driver.

                 ≈≈≈≈≈≈≈≈≈≈≈≈≈≈≈≈≈≈≈≈≈≈≈≈≈≈≈≈≈≈≈≈≈≈≈≈≈≈≈≈≈≈≈≈≈

     If you are at all interested, this would lead to the following remarks
     on the specific UPD functions described in Ictari 23 :-

     UPD_INIT
     This is the trickiest one and you may  possibly let it remain as it is
     for the time being. If  and  when  UPD  is  to  become  part of a GDOS
     driver, however, it  must  already  be  initialized  when anyone first
     sends VDI output to the printer or  else  be able to initialize at the
     first call of V_OPNWK.

     I would then envisage UPD as a separate program, UPD.PRG, to rest side
     by side with GDOS on the disk,  reading and converting into tables the
     ascii text driver file  during  bootup,  exactly  like GDOS is reading
     ASSIGN.SYS (from the current drive  and  path  =  the root of the boot
     disk). Like GDOS the UPD  program  would afterwards copy the extracted
     data down  over  the  now  redundant  ascii  text,  shrink  its memory
     accordingly  and  terminate  with  PTERMRES   to  make  itself  memory
     resident. Before this it  would  however  install  a  cookie, with the
     address to a routine or parameter block within itself, in the jar.

     The GDOS 'driver shell' - UPD.SYS  -  would, at the first V_OPNWK call
     it gets, seek contact with the - UPD.PRG - core via the cookie jar.

     UPD_TEXT
     Let this command deal  with  a  whole  string  (like V_ALPHA_TEXT) and
     internally take care  of  the  error  checking  after  each character.
     Furthermore, instead of your attribute  word  with each character, use
     the escapes defined with  V_ALPHA_TEXT  for  styles  changes as far as
     possible. Though for attributes not  defined with V_ALPHA_TEXT I guess
     you will have to define  your  own.  I  would  suggest that you try to
     support ALL of the DEFINED codes (in the Atari Compendium) AS defined,
     which I'm afraid would,  as  neat  as  they  are,  require you to skip
     explicit definitions of 5, 6,  17  and  20  CPI (the results of 2-mode
     combinations). Remember that both  widened  and condensed printing are
     also possible to combine with  proportional  printing (on my NEC P2200
     anyway).

     NOTE: Multiple copies on lasers  is  set  with  a separate VDI command
     V_PGCOUNT.
     Also, the reset  printer  and  clear  printer  buffer attributes would
     perhaps be  better  replaced  by  internal  handling  in  the  V_OPNWK
     routine.

     GRAPHICS
     Analogically to the character  output,  I  would  suggest the graphics
     output routine print the whole bitmap  in  one go, and internally take
     care of error checking after each  line. Thus merging UPD_SGM, UPD_SGD
     and UPD_EGM into a single  bitmap  output command. This would simplify
     things for the application  programmer  and  is  how  it  must be done
     within a GDOS driver anyway.

     To make the UPD command completely mimic the VDI raster copy functions
     would perhaps not be worth the trouble (and not necessary once working
     within the GDOS driver), but I think  it  should be prepared to take a
     width specification IN PIXELS, not necessarily divisible by 16 or even
     8 (any unused end bits to be cleared or whatever by the UPD function).
     Each new line should on the other hand  be required to begin on a word
     boundary.

     UPD_DELAY
     I would suggest this  command  be  replaced  with  a definition in the
     ASCII text file for the driver. I  also think that VSYNC calls for the
     measurement of time  would  be  better  replaced  with  polling of the
     _HZ_200 count (example routine  given  below) or alternatively polling
     of the GEMDOS time with TGETTIME. These methods would make delay times
     independent of the monitor hardware.

     Dimensions  of  the  workstation  (paper  sheet),  as  well  as  pixel
     dimensions (in microns),  and  any  colour  capacity,  should  also be
     possible to define  within  the  driver  text  file,  in  some form or
     another. (Since they need to be written  by the driver into the output
     arrays during calls of V_OPNWK.)

     One final suggestion, and not related to GDOS in any way:

     Allowing characters to be  redefined  into  any  byte sequences before
     output to the  printer,  would  be  worth  a  lot  to many non-English
     speaking people, I think. All Swedish letters should in principle come
     out right if the printer  is  set  to  IBM  mode,  but there are (old)
     printers lacking this mode (Is  the  British pound sign really printed
     correctly by all printers  without  re-definition?). And other letters
     (the O slash of Danish/Norwegian  and  the German double s) definitely
     need to be redefined before being sent to the printer.

     Programming a GDOS driver
     -------------------------
     Regarding the workings of a  GDOS  driver  I think the following rules
     apply (deduced purely from disassembly  - official documentation would
     be most helpful) :-

     A GDOS driver is,  as  Simon  Rigby  said,  basically  a program file,
     complete with program file header and  a relocation table. (I actually
     discovered a bug, when disassembling  GDOS  release  1.1, that I think
     will make a driver crash if there is NOT any relocation data - i.e. if
     the driver is written to be completely PC-relative.)

     The driver  should  not  shrink  its  memory,  since  GDOS  will  have
     allocated space only for its TEXT,  DATA  and BSS segments, and should
     not terminate with  a  GEMDOS  call  (PTERM)  but  simply  with an RTS
     instruction (it is called as a subroutine from GDOS).

     The driver will be called for each  and every VDI call directed to the
     device with which it is associated. And the sole input is a pointer in
     register D1 to the VDI  parameter  block  (as  with  any low level VDI
     call).

     The driver is apparently supposed to  return  a value in D0: seemingly
     just a flag determining whether or  not  the Y-axis should be reversed
     by GDOS in the case that NDC coordinates are being used. (The driver I
     studied seemed to always return a 1 - preventing GDOS interfering with
     the Y axis direction in any case.)

     All other registers are saved on the stack by the driver I have looked
     into. The stack itself is a  system  stack,  so should probably not be
     too heavily used.

     Apart from this, I think  that  the  GDOS  driver is free to implement
     each  VDI  call  in  whatever  fashion   it   likes  as  long  as  the
     specifications for the call are met with. Input and output are handled
     via the standard VDI arrays: contrl, intin, intout, ptsin and ptsout.

     The driver is apparently free to  pick  any number for the V_HANDLE to
     return when opening a workstation  (except  that  0 indicates error as
     usual). GDOS will store this handle and  use it in future calls to the
     driver, translating between this 'internal' handle and the handle used
     in communication with calling programs.

     GDOS will take care of  any  font  loading,  as  well as sorting fonts
     according to ID and point size (lowest font ID's - and within fonts of
     same ID, smallest sizes - first).  Or  at  least GDOS release 1.1 will
     have done this sorting, though older GDOS versions perhaps never did.

     But GDOS after this also passes the VST_LOAD_FONTS call to the driver,
     like with any other VDI call,  only  this  time with some extra values
     supplied in the CONTRL array:-

     contrl[7-8]  : Pointer to a buffer for character manipulations.
     contrl[9]    : Length of this buffer
     contrl[10-11]: Pointer to the (header of the) first font

     The driver should save these for  future  use. It is apparently solely
     the responsibility of the driver to manage text output from these data
     given. No further help will be offered by the GDOS program.


     (Note: The above applies to the  basic  GDOS 1.1. I suppose that later
     GDOS versions - FontGDOS, FSM and  SpeedoGDOS - will do more, possibly
     even take fully  care  of  any  Bezier  curves  and  outline fonts and
     somehow send them to  the  driver  as  bitmaps  (perhaps  via calls of
     raster copy operations or  via  fill  pattern operations). Can someone
     tell?)


     * ASSEMBLER ROUTINE TO WAIT A GIVEN NUMBER OF HUNDREDTHS OF SECONDS:-
     * -------------------------
     * Number of hundredths of seconds given on stack as a LONGWORD.
     * E.g.  pea    100.W  ;to wait 1 second
     *       bsr    delay
     *       addq.l #4,SP

     delay    movem.l D0-D3/A0-A2,-(SP)
              move.l  32(SP),D3
              add.l   D3,D3     ;Convert hundredths of s into 200Hz ticks
              bsr.s   gethz200
              add.l   D0,D3
     .delay   bsr.s   gethz200
              cmp.l   D3,D0
              bls.s   .delay
              movem.l (SP)+,D0-D3/A0-A2
              rts

     gethz200 bsr.s   .supexec  ;Push next address on stack and jump
              move.l  $4BA.W,D0
              rts

     .supexec move.w  #38,-(SP)
              trap    #14
              addq.l  #6,SP
              rts

     */ In response to Mårtens letter  above  and  Simon Rigby last month I
     have to disagree  with  their  suggestion  that  a  new Printer Driver
     program should try and emulate or tie into the existing GDOS system. I
     have several reasons for this view -

     Firstly, while I accept that  a  'serious'  program should use the GEM
     system for maximum compatibility  with  all  ST  versions, I know that
     there are some programmers  who  prefer  not  to  use  GEM for various
     reasons (games programs, for example)  and  also some languages do not
     allow the use of GEM (STOS being one example). The proposed UPD system
     would allow ANY programmer to use a printer whether under GEM or not.

     Secondly, any GDOS equivalent program  would  have to cater for vector
     fonts  (as  I  cannot  see  a  bit  mapped  font  version  having  any
     credibility among Atari programmers) and  this  would  be a huge task.
     Look how long SPEEDO-GDOS has taken to arrive along with all the other
     aborted versions on the way. And, in any case, what would be the point
     in copying a program that has already been written, not to mention the
     legal aspects of copyright.

     Thirdly, GDOS is essentially a graphics system and would not cater for
     sending text data and text attributes  to  the printer. While this may
     be a relatively trivial problem  for  a  program  to overcome, the UPD
     system still has the advantage of  rationalising the printer output so
     that the programmer does not  have  to  worry  about all the different
     control code sequences for the various attribute functions. Admittedly
     the available attribute codes have  to  be  limited  to those that are
     available on most printers but this  is  still better than having none
     at all.


     Fourthly, using the GDOS system, a (machine code) printer driver would
     have to be written for  each  printer  to  print graphics images. This
     would make it very difficult, if  not  impossible, for the end user to
     write a printer  driver  for  his/her  printer  if  there  was not one
     already available. With the UPD  system,  writing  a printer driver is
     relatively easy with the help  of  the  printer  manual and a suitable
     test program. Of course, the  graphics  printing  code must already be
     built into the UPD program itself but as Simon pointed out last month,
     there are only a small  number  of different graphics printing methods
     used in most printers. I have identified a number of methods, most use
     the Epson system (ESC, K, No_of_bytes, data) while the Canon system is
     slightly different (ESC, [, g, No_of_bytes,  mode, data). HP Laser and
     DeskJet are basically the same and 9  pin,  16  pin, 24 pin and 48 pin
     modes are virtually  the  same  except  for  the  number  of bytes per
     vertical slice. If any  other  methods  of  printing graphics data are
     discovered, then these can be added  later,  the code has been written
     in such a way  as  to  facilitate  additional graphics drivers easily.
     Colour printing will have to wait until  someone tells me how it works
     but hopefully that can be incorporated later.

     Regarding some of the specific points raised in the letter above :-

     I agree that the UPD program is  best  stored as a separate program on
     disk and loaded in by the application although I don't think it should
     be defined as a .PRG program since  it  cannot be run as a stand alone
     program which the .PRG extension implies. Using the title UPD_V100.BIN
     indicates that it is a  binary  file  (version  1.00 in this case) and
     implies that it has to be loaded into an application at run time.

     Creating an  entry  in  the  'cookie  jar'  is  an  option  I  had not
     considered. As I understand this  system,  it  is for situations where
     one program can determine  whether  another  program (or some hardware
     device) has been installed and could  be used by accessory programs or
     other applications programs in  a  multi-tasking environment. The only
     reason I can see for the UPD to install a cookie jar entry would be to
     allow several programs to use  the  same  program.  In other words, an
     application loads in the UPD program and then stores its start address
     in the 'cookie jar' so that  a second application (or accessory) could
     use the same program without  having  to  load the program code again.
     This would save some memory (although  the  code is only about 4K long
     anyway) but I think  it  could  cause  other  problems. The programmer
     would have to assume the same printer  was being used by both programs
     (probable but not absolutely definite)  since  the printer driver will
     also be loaded by the original program. Another major problem would be
     that, since printing can take some time, the variable stores set up by
     the first program could be  corrupted  by  the second if both programs
     try to print at the  same  time.  We  would  need  some form of memory
     allocation and print spooling to  allow  stacking  of printer calls. I
     will have to think about this one but  I suspect it would not be worth
     the extra complications !

     Sending text characters as a  complete  string instead of individually
     would be possible, I suppose, but  I  think  it would be less flexible
     since the program would need another control code to define the end of
     the string and the  UPD  would  need  more  buffer  space to store the
     string before sending it on  to  the  printer.  The proposed system is
     easy enough to use  and  the  programmer  can  always implement such a
     system if he wants to. It would be possible to use just the attributes
     defined by the v_alpha_text function  but  since  we don't want to use
     GEM anyway we may as  well  use  the  extra codes. The attribute codes
     that I have defined ($0200, $0400, etc) were designed to make the code
     simple and run as quickly as possible.

     I had considered sending a complete  bit  map to the printer using one
     command but decided against  it  because  the  command itself would be
     rather involved as it  would  have  to  incorporate image width, image
     length, graphics mode, image address  and possibly colour information.
     Also sending one  raster  line  at  a  time  allows  the programmer to
     provide a method of aborting the printout with a keypress at any time.
     The current system is very easy  to  implement  with a simple loop and
     image address pointer.  I  suppose  the  width  specification could be
     defined in pixels rather than bytes if there is any advantage in this.

     Regarding the delay period, I did consider using the 200Hz counter but
     this would mean going  into  Supervisor  mode  within  the UPD program
     which causes complications on  return.  However,  using the 'Tgettime'
     GEMDOS function to generate the delay is  a good idea which I have now
     implemented although  the  delay  does  not  really  need  to  be very
     accurate. I am not sure about including  the delay period value in the
     Printer Driver file itself since the  reason  for the delay could vary
     even in the same printer depending on  the size of the printer buffer,
     whether single sheets or fanfold is being used, etc. In fact, I am not
     even sure if a delay is needed anyway, my own experience with printers
     has not shown any problems. I  only  included  the option just in case
     someone somewhere needed it, perhaps  some  other members could let me
     know if it is really required.

     I don't think the paper size should  be included in the Printer Driver
     text file since that  could  vary  for  each  print-out but the colour
     options will certainly need to be defined, I will sort that out when I
     have more information on colour printing.

     Allowing a character to be redefined into  a series of byte codes is a
     lot more  complicated  than  it  first  seems,  however,  changing one
     character into another one is  relatively  simple  and  that is what I
     propose to implement first. However,  even  this  opens up a whole new
     can of worms. The  character  set  from  $20  to  $7F  seems to be (in
     English anyway) fairly standard, assuming,  that  is, that code $23 is
     defined as the #  character  (and  not  the  English  pound sign). The
     problem is that some printers can  be  configured to print a different
     character for some codes  (i.e.  $,  #,  £,  etc) and the applications
     program or the UPD program cannot know  what is being printed for each
     character code. For  the  codes  from  $80  to  $FF  it  is  even more
     difficult. Again, depending on  how  the  printer is configured, these
     codes can print  as  IBM  graphics  characters,  italics, or sometimes
     nothing at all. My  HP  Laser  printer  prints  a completely different
     character set from my 24  pin  Panasonic,  most  of the characters are
     there but in different positions. It  would probably be useful to have
     the IBM ProPrinter character set as standard since these have the line
     drawing characters available  but  some  printers  cannot emulate this
     mode. Perhaps we  need  a  complete  character  set  defined which all
     printers can print and  which  could  then  be  defined in the Printer
     Driver text file. The problem  is  that,  apart from the English pound
     sign at code $9C (usually), all  the other characters are non-English.
     Perhaps our European members  could  advise  us  on  the characters or
     symbols required.

     I think it would be very  useful  to  know more about how GDOS drivers
     work as we may be able to  use  some  of  the ideas. I would also like
     more information on colour printing, if  anyone can provide this info,
     please let me know.

     I would also like to hear more comments on the UPD from other members,
     especially any that are writing programs that use print-outs.  PDH /*

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