home *** CD-ROM | disk | FTP | other *** search
/ Fujiology Archive / fujiology_archive_v1_0.iso / !MAGS / ICTARI / ICTARI33.ZIP / ICTARI33.TXT < prev    next >
Text File  |  1996-04-13  |  58KB  |  1,134 lines
  1.  
  2.      ICTARI USER GROUP             ISSUE 33                     April 1996
  3.  
  4.          ___   ______     ___       _________   _________   ___
  5.          \__\  \   __\    \  \__    \______  \  \   _____\  \__\
  6.            ___  \  \       \  __\     _____\  \  \  \         ___
  7.            \  \  \  \       \  \      \  ____  \  \  \        \  \
  8.             \  \  \  \_____  \  \____  \  \__\  \  \  \        \  \
  9.              \  \  \       \  \      \  \        \  \  \        \  \
  10.               \__\  \_______\  \______\  \________\  \__\        \__\
  11.  
  12.                      *   m   a   g   a   z   i   n   e   *
  13.  
  14.      =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  15.                        I C T A R I   U S E R   G R O U P
  16.       63 Woolsbridge Road, Ringwood, Hants, BH24 2LX   Tel. 01425-474415
  17.      =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  18.  
  19.                               INDEX FOR ISSUE 33
  20.                               ==================
  21.  
  22.      ASSEMBLY        Assembly Language Tutorial. Part 1.
  23.                      Non-Modal dialog boxes source code.
  24.  
  25.      C               Window icon interface system.
  26.                      File viewer program.
  27.  
  28.      GFA             Text adventure game.
  29.                      Object change code.
  30.  
  31.      STOS            Using a large font in STOS.
  32.                      STOS Falcon patch program.
  33.                      STOS Compiler patch.
  34.  
  35.      MISC            Character Set Information and UNICODE standard.
  36.                      SCSI FAQ file, part 1.
  37.                      Programming considerations (INTERNET).
  38.                      Current membership list.
  39.  
  40.      In next months issue of ICTARI (this may change) :-
  41.  
  42.      ASSEMBLY        Assembly Language Tutorial. Part 2.
  43.                      Dialog box code.
  44.  
  45.      C               Alert message function.
  46.                      Monochrome fade function.
  47.  
  48.      GFA             Scaling program demo.
  49.  
  50.      STOS            Generic STOS fix program.
  51.                      Pie chart generator.
  52.  
  53.      MISC            HTML information.
  54.                      Rich Text format spec.
  55.                      SCSI FAQ file, part 2.
  56.  
  57.      ----------------------------------------------------------------------
  58.                                    EDITORIAL
  59.                                    =========
  60.      ATARI WORLD
  61.      -----------
  62.      According to Goodmans PD Library, the  ATARI WORLD magazine has closed
  63.      down although there  seems  to  be  a  very  small  chance that System
  64.      Solutions may take it over  but  I  wouldn't part with an subscription
  65.      money until the situation has been resolved. It would be a great shame
  66.      if it does close since  Jon  Ellis's  contribution was the only decent
  67.      programmers column (apart from ICTARI of course) around.
  68.  
  69.      BETA TEST PROGRAMS
  70.      ------------------
  71.      When any  new  program  is  written  I  think  it  is  useful,  if not
  72.      essential, to get someone else to try it out before it is released for
  73.      general use. This 'beta'  testing  can  often  show  up  minor bugs or
  74.      deficiencies which can  be  corrected  before  thousands  (well dozens
  75.      then) of users start using it. This  is where ICTARI can play a useful
  76.      role since between all our  members  there is probably every different
  77.      type of TOS version, RAM size, screen  types, etc on which the program
  78.      can be tested.
  79.  
  80.      In this issue Peter Strath has sent  a File Viewer program for testing
  81.      (in the C folder) which members might  like  to try out. I have listed
  82.      some of my own  comments  below,  perhaps  other members could provide
  83.      some more and also send in their own programs for testing.
  84.  
  85.      I actually found the program very  useful, I especially liked the fact
  86.      that it works in all resolutions (on  my machine anyway) and also that
  87.      .IMG images could be loaded  and  displayed  in all resolutions. I did
  88.      find one small bug, if you have a folder called XXXXXXX.IMG (where the
  89.      X is any  character)  the  program  freaks  out.  I  guess the program
  90.      assumes it is an image file before checking to see if it is a folder.
  91.  
  92.      Some other facilities I would  like  to  see  are  the filenames to be
  93.      sorted in order of  filename,  extension  type  and/or file size (like
  94.      most fileselectors). I  think  also  the  main  window  could  be made
  95.      bigger, or allow the user to resize  it, so that more filenames can be
  96.      displayed. It would be useful to be  able to load more picture formats
  97.      although I suppose colour images would be  a problem. It would also be
  98.      useful when displaying the  drive  letters  to  also display the drive
  99.      names (that normally appear underneath the icons on the desktop), this
  100.      would save having to remember which drive is used for what, I know you
  101.      can enter a name but if there is  one already there, one might as well
  102.      use it. I'm not quite sure  why  the 'Re-read directory' and 'Previous
  103.      directory' lines are shown  at  the  beginning  of  each window, these
  104.      would seem a bit superfluous  since  the 'close window' gadget returns
  105.      to the previous  window  and  re-reading  a  directory  is  not really
  106.      needed. I would also like to  see  the total number of bytes displayed
  107.      at the top of the window shown as the number of bytes the files use on
  108.      the disk rather than  all  the  file  sizes  just added together. Most
  109.      programs of this type make this mistake,  the actual size of a file is
  110.      irrelevant for most purposes, it is  the  amount  of space it takes on
  111.      the disk which is  usually  more  important,  which  is  the file size
  112.      rounded up to the nearest 1K  (although  if the file blocks are larger
  113.      on high capacity hard disks, this value will be higher). A very useful
  114.      feature (for me anyway) would be  the  ability to display (and save as
  115.      ASCII) any type of  text  file  as  well  as  just  ASCII, for example
  116.      Protext, 1st Word, HTML, Rich Text  format  and one or two others (see
  117.      next months issue for RTF and HTML info) although I suspect this would
  118.      be rather a major project.
  119.  
  120.      If anyone would like to add any more constructive comments, please let
  121.      us know.
  122.  
  123.      ----------------------------------------------------------------------
  124.                                  CORRESPONDENCE
  125.                                  ==============
  126.      To: Peter Hibbs
  127.      From: Phil Hodgkins.
  128.  
  129.      Re: GEM and AUTO programs.
  130.  
  131.      The VDI is initialised before any of the AUTO programs are executed on
  132.      boot up, but the AES is  not initialised until afterwards (just before
  133.      the accessories are loaded and initialised).
  134.  
  135.      The only odd thing  about  using  the  VDI  during  boot  up is that a
  136.      physical workstation should be used  instead  of a virtual workstation
  137.      which would cause a crash. This  is  the opposite of what happens when
  138.      the AES is loaded!
  139.  
  140.      The following are fragments of code from Stoop, a Falcon boot manager,
  141.      that I've written, but they should  work  on  a  ST. It was written in
  142.      Lattice C.
  143.  
  144.      // Main code
  145.      if(detect_aes()) aes=TRUE;
  146.  
  147.      if(aes) {
  148.              // Normal start up if not running from the AUTO folder
  149.              // (i.e. the AES is present)
  150.              appl_init();
  151.              handle=graf_handle(&junk, &junk, &junk, &junk);
  152.              v_opnvwk(work_in,&handle,work_out);
  153.      }
  154.      else
  155.              // Physical workstation opened if running from AUTO
  156.              v_opnwk(work_in,&handle,work_out);
  157.  
  158.      // These commands enable the mouse
  159.      vsin_mode(handle,1,2);
  160.      vq_mouse(handle,&mb_state,&mx,&my);
  161.      vsm_locator(handle,mx,my,&junk,&junk,&junk);
  162.  
  163.      do {
  164.              interface(&mb_state,&mx,&my,&key,&code,&mod,UP);
  165.  
  166.              // Your code goes here
  167.      }
  168.  
  169.      // Closedown
  170.      v_clsvwk(handle);
  171.      if(aes) appl_exit();
  172.  
  173.      The following are functions used by the above code.
  174.  
  175.      /* Returns the state of the  mouse (buttons and position) and keyboard
  176.      (ascii code, scan code and modifier key  status). It loops until a key
  177.      or mouse  button is pressed. */
  178.  
  179.      void interface(short *mb_state,short *x,short *y,unsigned char *key,
  180.                                 unsigned char *scan,long *mod,char release)
  181.      {
  182.      *key=-1;
  183.      *mod=0;
  184.      do {
  185.              vq_mouse(handle, mb_state, x, y);
  186.              if(iskbhit()) v_get_key(key,scan,mod);
  187.      } while(!(*mb_state & 3) && *key==-1);
  188.  
  189.      // Wait until mouse buttons are up or not, as required
  190.      waitmouse(release);
  191.      }
  192.  
  193.      void get_key(unsigned char *key,unsigned char *scan,long *mod)
  194.      {
  195.      long x;
  196.  
  197.      Supexec(conset);  // Allow Bconin to read shift key status
  198.                        // this would normally be in the initialisation code
  199.      x=Bconin(2);
  200.      *key=x & 0xff;
  201.      *scan=(x>>16) & 0xff;
  202.      *mod=Kbshift(-1);
  203.      }
  204.  
  205.      long conset(void)
  206.      {
  207.      *(char *)0x484 |= 0x08;
  208.      return 0;
  209.      }
  210.  
  211.      /* Exits when the mouse buttons are up if release=UP and are down if
  212.         release=DOWN
  213.      */
  214.      void waitmouse(char release)
  215.      {
  216.      short x,y, state;
  217.  
  218.      if(release==UP) {
  219.              do vq_mouse(handle,&state,&x,&y);
  220.              while(state!=0);
  221.      }
  222.      else {
  223.              do vq_mouse(handle,&state,&x,&y);
  224.              while(state==0);
  225.      }
  226.      }
  227.  
  228.      Asm code for detecting the presence  of  the AES (given as source code
  229.      with NVDI 2.5)
  230.  
  231.      CSECT TEXT,0
  232.  
  233.      XDEF _detect_aes
  234.  
  235.      _detect_aes     move.w  #$C9,d0
  236.              trap            #2
  237.              tst.w           d0
  238.              seq.b           d0
  239.              ext.w           d0
  240.              rts
  241.      END
  242.  
  243.      This works fine with TOS 4 and should be OK with other earlier version
  244.      as it is  all legal  code.  Problems  occur with AES replacements like
  245.      Magic and VDI replacements like NVDI,  so the program should appear in
  246.      front of them in the  AUTO folder.
  247.  
  248.      I have later versions  of  this  code  (particularly  interface) but I
  249.      managed to kill my Falcon and  I  can't  get  at  the code until it is
  250.      repaired.
  251.      ----------------------------------------------------------------------
  252.      To: Mårten Lindström
  253.      From: Jonathan Leckie
  254.  
  255.      1) Atari World subscription prices - This  information  is taken  from
  256.      the February issue of Atari world but I don't think the prices will be
  257.      out-of-date  you  can  always  write  and  ask.  Atari  World  have an
  258.      arrangement  with  "Sven Bornemark Musik"  to supply  subscriptions to
  259.      readers in  Sweden, Norway, Denmark  and  Finland.  Since you  live in
  260.      Sweden I will quote the prices for Swedish Kronor :-
  261.  
  262.      3  Issues without disc 140 Kr
  263.      3  Issues with disc    190 Kr
  264.      13 Issues without disc 560 Kr
  265.      13 Issues with disc    760 Kr
  266.  
  267.      You  should pay  the correct  amount  by  Post  Giro to :-  23 59 59-4
  268.  
  269.      The address of Sven Bornemark Musik is :-
  270.      Sven Bornemark Musik,
  271.      Lergosv 79,
  272.      238 40 OXIE {I don't know if it should be 0XIE - but you will know the
  273.                   postcode conventions}
  274.      Tel: 040 54 54 54
  275.  
  276.      I  think  it  would  be  sensible  to phone him  and  verify  all this
  277.      information.  Atari  World also claims  that  you  get  an "additional
  278.      Swedish supplement free with each issue".
  279.  
  280.      2) I have sent a DRAFT spec  for HTML 3 to Peter  but it  is quite big
  281.      (approx. 420 Kb) so if it is put on the disc it will be compressed.
  282.  
  283.      To: Derek Warren
  284.  
  285.      You  said your  directory program  was written  mainly to learn C and
  286.      that you  wanted feedback so here  is some (screeeeeaaach - funny eh).
  287.      I am not anything of an expert in C coding but I liked your function
  288.      definitions at the top (bell,  cur_posn,  etc)  but  I notice that you
  289.      used 'Goto`s' shame, shame, shame.  I myself have  used goto`s in  the
  290.      past (forgive  me)  but   in   the    current   climate  of  re-usable
  291.      modular structured  programs   using  Gotos   is  a   definite  no-no.
  292.      If  the programming police were to catch  you it would be 3 years hard
  293.      COBOL in the AIX mines.  May  I  suggest  you  use (in the  case of C)
  294.      functions instead. So this code :-
  295.  
  296.      rez_no = Getrez();
  297.      if (k==0 && rez_no==0)
  298.      {
  299.           not_low();
  300.           goto end;
  301.      }
  302.                                would be replaced by :-
  303.  
  304.      rez_no = Getrez();
  305.      if (k==0 && rez_no==0)
  306.      {
  307.           not_low();
  308.           end();
  309.      } else {
  310.        /* do code that can be done if in high or med res. */
  311.      } /* end of main code */
  312.  
  313.                                where end is :-
  314.  
  315.      void end() /* commands to be done at end */
  316.      {
  317.        enbl_cur;
  318.        mouse_on();
  319.        keybd_repeat(15,-1);   /* '15' puts speed of first keypress response
  320.                                                   approx. back to normal */
  321.        cls;
  322.        gem_off();
  323.        exit(0);
  324.      }
  325.  
  326.      You have used functions elsewhere  in the program so just extend their
  327.      use to replace the Gotos.  Your program will obviously still work with
  328.      gotos but it is better style to use functions and it makes the program
  329.      easier to  read, debug and modify  (apparently).  The inclusion of the
  330.      Goto command in C was really a concession to the early users that used
  331.      rubbish BASICs  without functions or  procedures. Try and get a C book
  332.      that helps with the  concepts  behind IF ELSE and using functions.  If
  333.      I am completely mis-judging you, sorry,  but that was what occurred to
  334.      me when I was looking through it.  The actual code looks O.K. though.
  335.  
  336.      To: All
  337.  
  338.      In  case  anyone is interested  UDO ver. 4 should  be  available  from
  339.      FloppyShop, Goodman, LAPD, Merlin  and Power PD as we read.  For those
  340.      that  don't  care or can't  remember I was  looking for it  because it
  341.      converts ASCII, LaTeX, RTF, HTML formats (+ others).  I haven't got it
  342.      yet but it  looks  funky and  is available  for  Atari, DOS and Linux.
  343.      Registration costs 15 pounds.
  344.      ----------------------------------------------------------------------
  345.      To: *.*
  346.      From: Martin Milner
  347.  
  348.      The recent notes about STOS/TOS incompatibility and STOS versions have
  349.      finally spurred me to  write  with  some  recently  acquired info that
  350.      should be useful to anyone programming in STOS.
  351.  
  352.      STOS/TOS independence
  353.      ---------------------
  354.      I have  for  several  years  now  achieved  TOS  independence  for the
  355.      joystick  by  using  the  joystick  commands  from  the  missing  link
  356.      extensions, which seem to work on  all versions of TOS, (including TOS
  357.      4.nn), but the mouse has until  recently always been a problem without
  358.      using STOSFIX. However, recently  I  have  come  into  possession of a
  359.      generic STOS fixer, which can 'pre-fix'  a  compiled program for up to
  360.      10 TOS versions, and it works brilliantly.
  361.  
  362.      The original fixing code was  produced  by Les Greenhalgh, and Anthony
  363.      Jacques has now put a nice  GEM  interface  on  it (written in C), and
  364.      sent me a copy. (Thanks Anthony).  As  it's freeware, I've sent a copy
  365.      to Ictari to put on the  disk.  The  program  uses  a  set of up to 10
  366.      DEFnnnn.DAT files produced by STOSFIX3 to  achieve the fixing, and no,
  367.      don't ask me how it's done,  I've  no  idea!  I've included the set of
  368.      DEFnnnn.DAT files with the  program,  they  should  enable you to make
  369.      your programs able to run  on  most  current  versions  of TOS with no
  370.      further treatment required. If you add more default files, the program
  371.      will use  the  first  10  it  finds.  It  can  also  be  used  to  fix
  372.      BASIC206.PRG, as I had to do before using STOS on the Falcon.
  373.  
  374.      STOS compiler versions
  375.      ----------------------
  376.      In Ictari 32, someone was  asking  about  whether compiler version 2.5
  377.      was the latest. Well, I've been using version 2.6 for some time, which
  378.      I believe was issued  when  the  STE  was  released, but I've recently
  379.      found out that there is a  version  2.7 (from Anthony Hoskin), which I
  380.      believe was issued with STOS 3D. I've sent a copy of that to Ictari as
  381.      well. I've just found out  that  I  needed  this version to overcome a
  382.      problem with using one  of  the  commands  from  the latest version of
  383.      Anthony's Falcon extension, so it  would  probably  be a good idea for
  384.      others to  use  it  too.  Note:-  You'll  need  to  have  the compiler
  385.      extension already. As it  is  (was?)  a  commercial product, I haven't
  386.      included the extension files, only the compiler program and accessory.
  387.  
  388.      Using the STOS Sprite Editor on the Falcon.
  389.      ------------------------------------------
  390.      Finally, using the  STOS  sprite  editor  on  the  Falcon is virtually
  391.      impossible due to  many  of  the  graphics  commands,  (eg:- box, bar,
  392.      circle,  etc)  not  working.  I've  now  produced  a  patch  file  for
  393.      SPRITE.ACB, (SPRPATCH.ASC), which can be used  to update the editor so
  394.      it will work on the Falcon. You'll  need the latest version of Anthony
  395.      Hoskins Grafix II extension (3.6  upwards),  which has the replacement
  396.      graphics commands in it. To patch the  editor just do the following in
  397.      the program editor:-
  398.  
  399.      load "SPRITE.ACB"
  400.      load "SPRPATCH.ASC"
  401.      save "SPRITE.ACB"
  402.  
  403.      Then reload STOS or do an accload to reload the editor accessory.
  404.  
  405.      Hope the above info/programs/files  will  be  of  use  to some of you.
  406.      Enjoy.
  407.  
  408.      */ See the STOS folder for the  patch  programs and next month for the
  409.      Generic fix program.  ICTARI /*
  410.      ----------------------------------------------------------------------
  411.      To: Tony Harris
  412.      From: David Preston
  413.  
  414.      Blitters - A minor correction.
  415.  
  416.      While STe's certainly do have that  particular bit of silicon wizardry
  417.      on board, the blitter's first appearance in  an  ST was in the Mega ST
  418.      (TOS 1.09). This was  followed  by  the first one-box blitter-equipped
  419.      ST, STFM's fitted  with  TOS  1.4  (aka  1.04).  Since  then (I think)
  420.      they've all had one as standard.
  421.  
  422.      To: Jason Railton
  423.  
  424.      SeaPest problems
  425.  
  426.      Erm, just a plain vanilla TOS 1.62  STe with 1mb on board, I'm afraid.
  427.      I didn't post a message  last  time  cos  I  didn't want to labour the
  428.      point, but  like  Stephen  Bruce  (ICTARI  32),  your  3D  demo didn't
  429.      acknowledge the mouse either...
  430.  
  431.      To: Mårten Lindström
  432.  
  433.      UNICODE
  434.  
  435.      I see that NVDI 4 advertises UNICODE support.
  436.  
  437.      To: Peter Hibbs
  438.  
  439.      One way of compressing your sprite data  might be to use PackIce. Most
  440.      instances of Ice 2.4 I've  come  across  on  coverdisks and PD library
  441.      disks have  included  decompression  routines  in  assembler.  I  even
  442.      compiled one using Devpac 2 from  a coverdisk (assembly language might
  443.      as well be some obscure dialect of  Klingon  to me) and got it working
  444.      within STOS on one occasion but  had  a clearout and haven't been able
  445.      to duplicate the feat since...
  446.  
  447.      If you do  crack  the  compression  question  _really_ effectively you
  448.      might even be able to store the 'reflections' along with the sprites.
  449.  
  450.      There was a report on the development  of  a basketball sim for one of
  451.      the consoles on telly recently,  where  the  players looked as if they
  452.      had reflections in the polished, varnished court floor. The result was
  453.      very effective, looking almost as if  the scene was being raytraced or
  454.      whatever on the fly. But  of  course  the programmers had included the
  455.      'reflections' as part of the sprites, applying a softening mask to the
  456.      reflection bit, so it didn't require  anywhere near as much processing
  457.      as it appeared. Looked good, though...
  458.  
  459.      I'm not sure whether you mean  like  a  reflection in a floor or what,
  460.      but the principle is pretty much the same.
  461.  
  462.      To: ICTARI
  463.  
  464.      Once you get to #100 you could use the extender for numbering purposes
  465.      - eg. ICTARI.100! (That'll  fix  those  clever  dicks who use "Install
  466.      application"!) ;-)
  467.  
  468.      To: David Seaman
  469.  
  470.      Sorry, but I can't see the  problem with Stock Controller. The version
  471.      you submitted does seem to  be  the  one  without the disk commands to
  472.      which you earlier referred as  problematical,  but  with regard to the
  473.      sorting problem, all I can achieve is a listing in stock number order.
  474.      Is this not what is supposed  to  happen?  I  know  I'm a bit dim, but
  475.      you've really got me baffled with this!
  476.  
  477.      To: *.*
  478.  
  479.      Shuffling demo - ICTARI 32
  480.  
  481.      I think I forgot to  explain  what  you'd  actually _use_ that sort of
  482.      routine for. Apart from  the  obvious  card  games, the same principle
  483.      works for shuffling questions in a quiz game, random tile dissolves in
  484.      a slide show etc etc.
  485.  
  486.      */ Looking through my hard  disk  I  find  that  I do have the PackIce
  487.      source code, I will have to study them further.  PDH /*
  488.      ----------------------------------------------------------------------
  489.      To: Jim Taylor
  490.      From: Peter Hibbs
  491.  
  492.      You say you want to generate an  image  in memory using all the normal
  493.      VDI commands and then print out  the  whole image to a printer (Ictari
  494.      27 and 32). I think  I  can  provide  half the answer, perhaps someone
  495.      else can do the rest. I  have  used the technique described below very
  496.      successfully on a program I am writing.
  497.  
  498.      The idea is to make  the  VDI  system  output  its  graphics data to a
  499.      memory buffer rather than the  screen  which  can  then be dumped to a
  500.      printer in the normal way.  First  allocate  a  memory buffer which is
  501.      large enough for your image and store  the start address of the buffer
  502.      (i.e. #buff_addr). As you probably know,  the GEM system maintains two
  503.      'screen' addresses in  RAM,  the  'physical'  screen  address  and the
  504.      'logical' screen address. The 'physical'  screen address is the actual
  505.      address that the hardware uses when  displaying the screen image which
  506.      can be anywhere in memory  but  is  usually  the  last 32K of RAM. The
  507.      'logical' screen address is the  RAM  address  that  the VDI uses when
  508.      outputting its images  and  is  usually  the  same  as  the 'physical'
  509.      address so that when a VDI function  is used, the image appears on the
  510.      screen. However, it is  possible  to  change  the 'logical' address to
  511.      another location in RAM so  that  the  graphics  output will be stored
  512.      there instead of in the screen RAM.
  513.  
  514.      The sequence below shows the  technique  using Assembler Macros (which
  515.      should be easily convertible to another language) :-
  516.  
  517.      First we need to allocate a block of RAM to store the VDI output. This
  518.      can be done with 'malloc' or just define a buffer in RAM, e.g.-
  519.  
  520.      buff_addr       ds.b            32000           32K buffer
  521.  
  522.      Next we need to find the current screen address with -
  523.  
  524.                      logbase                         fetch screen addr
  525.                      move.l          d0,scrn_addr    save in (scrn_addr)
  526.  
  527.      This address is  saved  so  that  the  proper  screen  address  can be
  528.      restored later (if we don't do this  we  won't be able to see anything
  529.      on screen).
  530.  
  531.      Next we change the  'logical'  screen  address  to  the address of the
  532.      output buffer -
  533.  
  534.                      setscreen       #-1,#-1,#buff_addr      change addr
  535.  
  536.      This command is the  BIOS  (TRAP  14/5)  call  which allows the screen
  537.      resolution and screen addresses to  be  changed.  As  we don't want to
  538.      change the resolution or 'physical'  screen  address, a negative value
  539.      is placed in those positions.
  540.  
  541.      Now call the required VDI calls  to  generate  the image, note that as
  542.      nothing will appear on screen during this operation, it would probably
  543.      be wise to display suitable 'please  wait' message before the function
  544.      is called.
  545.  
  546.                      vsf_interior    #2                      set attribute
  547.                      vsf_style       #9                      set attribute
  548.                      circle          #100,#200,#300          draw circle
  549.                      etc
  550.                      etc
  551.  
  552.      When the image has been drawn, the screen display can be restored with
  553.      the same BIOS call but with  the  original  screen address used as the
  554.      'logical' screen address -
  555.  
  556.                      setscreen       #-1,#-1,scrn_addr       restore addr
  557.  
  558.      Any further output to the  screen  will  appear  on the screen and the
  559.      contents of the RAM buffer can now be sent to the printer.
  560.  
  561.      The one big flaw in the  above  is  that  the buffer is still the same
  562.      size as  the  screen  which  is  not  much  good  for  larger  images.
  563.      Unfortunately I have not  found  a  way  to  make the 'logical' screen
  564.      larger during program execution. I  have  found  the two RAM addresses
  565.      which store the x and y screen  sizes  (at the A_line data address -12
  566.      and -4 respectively)  but  even  though  I  have  changed these before
  567.      calling the above code,  the  VDI  still  does  not  recognize the new
  568.      values. Maybe a new virtual workstation  needs  to be opened after the
  569.      values have been changed for the VDI to recognize them, I did try this
  570.      but it didn't work properly and I  don't  know enough about the VDI to
  571.      know if this  should  work.  It  must  be  possible  somehow, I think,
  572.      because the screen  expanders  (such  as  AutoSwitch  Overscan)  do it
  573.      although they run in an Auto folder and affect the whole system.
  574.  
  575.      If anyone can  throw  any  more  light  on  the  subject,  we would be
  576.      interested to hear about it.
  577.      ----------------------------------------------------------------------
  578.      To: Peter Hibbs
  579.      From: Mårten Lindström
  580.  
  581.      Warm thanks for the issue of Atari  World,  I  will now try at least a
  582.      three-month subscription for it.
  583.  
  584.      To: Ictari
  585.      From: Mårten Lindström
  586.  
  587.      Apologies for using "strange" and  uncommon English words. This wasn't
  588.      intended (I DO want my English  to  be as easily readable as possible)
  589.      and merely something that  might  happen  when  writing by dictionary.
  590.      Please continue to  point  out  any  other  "unusual"  features  of my
  591.      English that you might spot;  I  promise  to  not  find you finicky or
  592.      fastidious (or even finical).
  593.  
  594.      To: *.*
  595.      From: Mårten Lindström
  596.  
  597.      Unicode
  598.      -------
  599.      Just when I had  posted  my  previous  message,  I  discovered that 2B
  600.      apparently, according  to  "News"  in  ST  Application,  already  have
  601.      included Unicode support in their new NVDI 4.
  602.  
  603.      It remains to be discovered exactly HOW. With the VDI call VST_CHARMAP
  604.      (OP code 236 and taking a  single  intin)  you could, already with the
  605.      first  SpeedoGDOS  version,  select  between  Atari  8-bit  characters
  606.      (=mode 1) and Speedo 16-bit character  INDEXES (=mode 0). A fair guess
  607.      would perhaps be that a new mode (=2 ?) has been added for Unicode.
  608.  
  609.      (I haven't yet upgraded my own copy of NVDI (3.02). But I guess I will
  610.      have to now?)
  611.  
  612.      By the way, I  hope  I  didn't  cause  any  panic  with  my talk about
  613.      Unicode. Of course, the old  8-bit  characters  will be with us still,
  614.      for any foreseeable future. And  this  applies  to other computers too
  615.      (Windows NT is the system that I think presently has gone the furthest
  616.      in way of Unicode support, but Windows 95, although using some Unicode
  617.      for instance in  its  extended  file  names,  still  mainly uses 8-bit
  618.      characters).
  619.  
  620.      There are  alternatives  for  overcoming  the  dissimilarities between
  621.      different 8-bit sets - e.g. RTF. For  instance, in order to transfer a
  622.      file containing the text string "Mårten" (where "å" is non-ASCII) from
  623.      Atari (or from PC  DOS)  to  Windows  I  could  simply expand it thus:
  624.      {\rtf\pc Mårten}, which  Windows  programs  should interpret correctly
  625.      (see more in the texts on RTF that I have sent in).
  626.  
  627.      For the time being, Unicode will, I think, primarily be of interest to
  628.      writers of  word  processors  and  the  like.  But  even  if  not used
  629.      directly, Unicode is convenient just  for  reference purposes, I think
  630.      (e.g. for conversion tables)  -  allowing  the specification of almost
  631.      any commonly used character  or  symbol,  from  anywhere in the world,
  632.      through a simple 16-bit number.
  633.  
  634.      To: Tony Harris
  635.      From: Mårten Lindström
  636.  
  637.      The blitter chip was first included  in  the MEGA STs as standard. All
  638.      Megas, all STEs and all Falcons should have one; other Atari computers
  639.      (including TTs) normally not.
  640.  
  641.      But a program should, of course, not  rely  on a computer model or TOS
  642.      version  to  determine  the  presence  of  a  blitter  chip,  but  use
  643.      BLITMODE(-1) (XBIOS 64 with a word parameter = -1). Use bitwise AND on
  644.      the result with 1 to see if  a  blitter is "on" (configured by user to
  645.      be exploited by system) or with  2  to determine presence of a blitter
  646.      regardless of system configuration. Result: 0=NO.
  647.      (XBIOS 64 works with all  TOS  versions  -  even the "pre-blitter" TOS
  648.      1.00  which will always return 0=NO when ANDed as above)
  649.  
  650.      To: Peter Hibbs
  651.      From: Mårten Lindström
  652.  
  653.      Image compression with low decompression times
  654.      ----------------------------------------------
  655.      Yes, some sort of run length encoding  must indeed be the best choice.
  656.      But I would recommend to  encode  words "vertically" (in 16-pixel wide
  657.      columns). This technique is used in  TINY  images, and in Deluxe Paint
  658.      IFF ILBM compression  type  2,  and  although  requiring slightly more
  659.      programming  effort,  usually  gives   much  better  compression  than
  660.      encoding words or bytes "horizontally" a scan line at a time.
  661.  
  662.      The reason for this is of course the  way each byte or word in itself,
  663.      on the Atari, represents  a  horizontal  row  of  pixels; thus all the
  664.      pixels of a word are adjacent to pixels of a vertically adjacent word,
  665.      while only a single pixel  touches  a  horizontally adjacent word (and
  666.      the chances  of  a  compressible  match  decreases  accordingly).  The
  667.      difference disappears if working with  e.g. the 16-bit Falcon hardware
  668.      screen, where each word represents only a single pixel.
  669.  
  670.      In any case should each plane be done separately of course.
  671.  
  672.      As for the speed of  the  decompression,  for  any  kind of run length
  673.      encoding it should  be  possible  to  make  it  fast  enough  even for
  674.      animations, I think.
  675.  
  676.      By the  way,  the  weak  point  of  the  Tiny  /Deluxe  Paint vertical
  677.      compression scheme is with patterns.  If  your sprites contain much in
  678.      the way of patterns, you might  want  to  reserve some code ranges for
  679.      repeating patterns of 2 (or more?) words.
  680.  
  681.      References: Ictari  4: Picture formats by David Baggett and
  682.                  Ictari 16: IFF ILBM (vertical word compression) by myself
  683.  
  684.      Mirroring (and other manipulations) of images
  685.      ---------------------------------------------
  686.      A lookup table is really the best  solution  as  far as I can see. You
  687.      say you find lookup tables impractical  and  I agree that a 65536-word
  688.      table would be, but a 256-byte table isn't so horrible do you think?
  689.  
  690.      Since there isn't a built in Motorola instruction for flipping a word,
  691.      the only alternative to lookup tables, that  I can think of, is indeed
  692.      the shifting of one bit at  a  time  via  the X bit, like you suggest.
  693.      However, if you replace ROXL with ADDX
  694.  
  695.      ( example: LSR.W  #1,D0  ; 1 µs on an ST
  696.                 ADDX.W D1,D1  ; ½ µs  - " -  )
  697.  
  698.      then each bit will take  only  1.5  microseconds  on a standard ST, as
  699.      compared to 2 microseconds if shift operations are used both ways.
  700.  
  701.      Still, with the  help  of  a  byte  lookup  table  you  should be able
  702.      increase the speed, even further, by, at  the very least, a factor two
  703.      - and maybe three or four.
  704.  
  705.      Lookup tables are also what I  would  recommend to anyone who wants to
  706.      quickly shrink or enlarge an image (by a factor 2).
  707.  
  708.      To: Jim Taylor
  709.      From: Mårten Lindström
  710.  
  711.      GDOS
  712.      ----
  713.      I do understand your hesitancy to  rely  on  GDOS; it would be so much
  714.      nicer to be able to offer the user an inclusive package, not requiring
  715.      him to involve himself in, or even buy, GDOS.
  716.      But I am afraid there is no way  past  GDOS that I can see. Other than
  717.      writing your own  replacement  VDI  driver  from  scratch,  capable of
  718.      translating your VDI calls into drawing on a raster bitmap.
  719.  
  720.      Without GDOS, the system is  left  with  nothing  but the built-in VDI
  721.      screen driver, which won't give you  the  memory bitmap image that you
  722.      want. (Any call of v_opnvwk will  always  give you the same dimensions
  723.      as the PHYSICAL screen workstation (of  the  AES), and in any case you
  724.      cannot, in a clean way, directly control or access a memory bitmap for
  725.      it - though you can copy between it and a raster image of your own.)
  726.  
  727.      With GDOS, and the VDI driver  MEMORY.SYS,  you can open a workstation
  728.      (on device #61) that specifically does  what  you want; it allocates a
  729.      memory bitmap, the shape of  which  you  can  determine on the call of
  730.      V_OPNWK and the address of  which  you  will  receive on the return of
  731.      V_OPNWK (See chapter 5 of my GEM Guide).
  732.  
  733.                                 ---------------
  734.  
  735.      If only Atari had included GDOS  and  more  VDI  drivers in ROM in the
  736.      first place, or at least  distributed  them  with every sold computer,
  737.      you wouldn't have been in this dilemma.
  738.  
  739.      There was some discussion on writing our own freeware GDOS replacement
  740.      (including drivers), that any Ictari  member  or  anyone else would be
  741.      able to freely distribute with  his  programs  (and among others Simon
  742.      Rigby had looked into the  programming  of  drawing routines I think),
  743.      but I think we ended up at finding it not worth it (?).
  744.  
  745.      To: Simon Rigby and anybody interested
  746.      From: Mårten Lindström
  747.  
  748.      OUTLINE FONT FILE FORMATS
  749.      -------------------------
  750.      A long, long time  ago  you  asked  if  anyone  had information on the
  751.      Speedo font file format. I still haven't got that (has anybody else?),
  752.      but I HAVE now got some pretty detailed information on TRUETYPE files.
  753.      Unfortunately it is not in ASCII  disk file format (and furthermore it
  754.      is copyrighted by Apple and  Microsoft),  but  if you are interested I
  755.      think I could make the effort and write an article about TrueType.
  756.  
  757.      To: *.*
  758.  
  759.      HOW AN OUTLINE FONT ENGINE WORKS
  760.      --------------------------------
  761.      Although neither the end user  nor  the application programmer, making
  762.      his SpeedoGDOS function  calls,  needs  to  know  how  an outline font
  763.      engine goes about is business  internally,  I  think  there might be a
  764.      general interest in this subject,  so  here  is  an overview (there is
  765.      also some info in the text "Joy of GDOS" from Germany):
  766.  
  767.      The main task of  an  outline  font  engine  is  of course to generate
  768.      bitmap images from the outline  data  (from  then  on, there is little
  769.      difference between an outline engine and a bitmap font engine).
  770.  
  771.      The basis of any  outline  font  data  is  arrays of coordinate pairs,
  772.      describing the contours that form  characters (or "glyphs"). In Speedo
  773.      fonts these coordinate  pairs  refer  to  points  for  drawing "BÉZIER
  774.      curves" (= "CUBIC  B-splines");  TrueType  fonts,  on  the other hand,
  775.      merely use "QUADRATIC B-splines".
  776.      The difference between cubic and  quadratic  B-splines is, simply put,
  777.      that cubic splines use  TWO  "control  points" (= off-curve "magnets")
  778.      between each "anchor point" (=  on-curve point); quadratic splines use
  779.      only ONE control point between each anchor point.
  780.  
  781.      /¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯\
  782.      If the above explanation isn't enough, at the risk of making it appear
  783.      more complicated  than  it  really  is,  here  are  the  full B-spline
  784.      equations.
  785.      Note to Protext users: Characters ² and  ³ (253 and 254) below are, in
  786.  
  787.      the standard Atari set, superscript  2  and 3 ("squared" and "cubed").
  788.      Replace with Protext commands   r !253 !t2!t c and r !254 !t3!t c
  789.  
  790.      Linear (simple line): x(t) = (1-t)x0 + t*x1  (This is a straight line
  791.                            y(t) = (1-t)y0 + t*y1   from (x0,y0) to (x1,y1))
  792.  
  793.      Quadratic B-spline:   x(t) = (1-t)²x0 + 2t(1-t)x1 + t²x2
  794.                            y(t) = (1-t)²y0 + 2t(1-t)y1 + t²y2
  795.  
  796.      Cubic (Bézier curve): x(t) = (1-t)³x0 + 3t(1-t)²x1 + 3t²(1-t)x2 + t³x3
  797.                            y(t) = (1-t)³y0 + 3t(1-t)²y1 + 3t²(1-t)y2 + t³y3
  798.  
  799.      where t goes from 0  to  1,   (x0,y0)  is  the  first anchor point and
  800.      (x1,y1) etc. are the following control and anchor points.
  801.  
  802.      (The actual algorithm for calculating  points  on a quadratic or cubic
  803.      curve would use the  basic  linear  formula  (between  each anchor and
  804.      control point), repeated in 2 or 3  steps for each t. The curve points
  805.      calculated in one step would be used  as end points in the next, until
  806.      only two end points remain in the  final step that produces the actual
  807.      curve point for the t.)
  808.      \____________________________________________________________________/
  809.  
  810.      The coordinates for anchor and control  points are given in some font-
  811.      internal unit, called  ORUs  (Outline  Resolution  Units) in Bitstream
  812.      terminology and FUnits (Font Units) in TrueType.
  813.  
  814.      In the simplest case, the curves are  used to generate bitmaps in only
  815.      two steps:
  816.  
  817.      1)      Scale  them  -  i.e.   multiply   each   anchor/control  point
  818.              coordinate by some scaling factor - to match the pixel grid of
  819.              the current text  size  and  device  resolution.  (If rotation
  820.              and/or skewing is applied,  each  coordinate  must actually be
  821.              calculated as the sum of original  x  and y each multiplied by
  822.              some signed factor.)
  823.  
  824.      2)      Draw them on the bitmap (i.e. calculate the exact curves using
  825.              the B-spline equations above  and  then  determine what pixels
  826.              are inside and should be  drawn).  This  step is called "scan-
  827.              conversion".
  828.  
  829.      The simplest outline font  files  may  indeed  be  nothing more than a
  830.      collection of poly-beziers with  a  header  on  it; Calamus fonts may,
  831.      from what I have heard, be this simple (?).
  832.  
  833.                                 ---------------
  834.  
  835.      If the text size is big enough,  and the resolution high enough, there
  836.      is no need for anything more, but in small text sizes /low resolutions
  837.      you will start noticing that some  character parts (stems or bows) are
  838.      visibly thinner  than  others,  or  deformed,  or  in  bad  cases even
  839.      entirely missing, just  because  of  unfortunate  interaction with the
  840.      pixel grid (if for instance a very thin part of a character happens to
  841.      pass IN BETWEEN pixel centres, it  will "disappear" when the bitmap is
  842.      drawn). These bad effects become visible already at a character height
  843.      of about 60 pixels  and  get  worse  the  smaller  the characters get.
  844.      (Though exact figures will vary  widely between different characters -
  845.      e.g. the "@" character is in much more trouble than "-" or "|".)
  846.  
  847.      The remedy is called "hinting" or  "grid-fitting"  and is applied as a
  848.      step in between scaling and scan-conversion:
  849.  
  850.      1)      Scale outline curves.
  851.      2)      Grid-fit them.
  852.      3)      Draw them. (= scan-conversion).
  853.  
  854.      Grid-fitting means distorting the  outline,  moving points and curves,
  855.      to fit better onto the pixel grid.  Stems and bows can for instance be
  856.      made relatively  thicker  in  small  text  sizes,  and  horizontal and
  857.      vertical stems moved  to  be  aligned  with  pixel  rows  and columns,
  858.      ensuring uniform thickness when converted into bitmap image.
  859.  
  860.      In TrueType, the  hinting/grid-fitting  is  achieved  through complete
  861.      GRID-FITTING PROGRAMS, built from INSTRUCTIONS much like the processor
  862.      instructions of Motorola or Intel. The difference is of course that no
  863.      hardware processor (as far as  I  know)  has  been built to carry them
  864.      out; this is left for a  soft-ware  interpreter  which must be part of
  865.      any font engine dealing with TrueType fonts (thus one must be found in
  866.      SpeedoGDOS and NVDI).
  867.      At the heart are, of  course,  instructions  for moving the individual
  868.      points or whole curve segments of the outline data, but there are also
  869.      instructions for arithmetical and logical  operations, for moving data
  870.      about, and for (conditional) jumps and sub-routine calls.
  871.      Professional TrueType font designers  will  use  special assemblers or
  872.      even high level compilers to create the hinting routines and programs.
  873.  
  874.      By the way: It seems that  hinting  is  normally shut off when text is
  875.      rotated in non-right angles. The  reason  is,  from what I understand,
  876.      that hinting programs simply  aren't  flexible  enough to successfully
  877.      deal with such cases.
  878.  
  879.      BITMAP FONTS AND OUTLINE FONTS
  880.      ------------------------------
  881.      There exists a  strange  myth,  perhaps  even  among programmers, that
  882.      outline fonts generally are  better-looking  than bitmap fonts. Anyone
  883.      who has really  LOOKED  at  outline  text,  must  have  realized it is
  884.      precisely the other way around. And if looking doesn't help, then just
  885.      think about it; any font engine - whether outline or bitmap - will, of
  886.      course, in the end work with BITMAPS, copied to the screen or whatever
  887.      - the difference is, an outline  engine  is capable of generating NEW,
  888.      reasonably good-looking, bitmap images for any new size or resolution.
  889.      But the single set of character  images  in a bitmap font was designed
  890.      by a HUMAN artist (well, in the  best  case  at least) and in the size
  891.      and resolution IT WAS INTENDED FOR, no outline font can beat it.
  892.      The best an outline font designer  can  hope  for, is to make machine-
  893.      generated bitmaps as close  to  human-designed  ones  as possible, and
  894.      this, indeed, is most of what outline font technology is about.
  895.  
  896.      In fact, Microsoft  has  apparently  just  recently  come  up with the
  897.      ultimate solution (guess what): The  EMBEDDING  OF BITMAPS in TrueType
  898.      fonts. Yes, really! The circle has closed it seems.
  899.      Of course this feature will normally  be used only for some especially
  900.      tricky characters and in  small  sizes/low  resolutions, but Microsoft
  901.      does ALLOW even TrueType fonts with ONLY bitmaps and no outline data!
  902.  
  903.      To: *.*
  904.      From: Mårten Lindström
  905.  
  906.      POINTLESS POINTS
  907.      ----------------
  908.      I little while ago, when  I  was  writing  my  Gem  Guide, I thought I
  909.      understood the meaning of "font size" and typographical "pica points".
  910.      A point is 1/72 of an inch (≈ 353 micrometres) and when text is set to
  911.      for instance 12 points, it would  -  so  I thought - have a "character
  912.      cell height" of 12 points (= 1/6 inch  ≈ 4.23 mm), i.e. be suitable to
  913.      print in lines this far apart (at  a minimum). If  you merely know the
  914.      resolution of the device on which you  are printing (use 90x90 DPI for
  915.      screen; see WORK_OUT array for other  devices),  you should be able to
  916.      instantly figure out what point size  to  request  in order to match a
  917.      given text line height in pixels.
  918.  
  919.      Practically all GEM BITMAP fonts are indeed designed this way, so when
  920.      I found NVDI to return  character  cell  heights much larger than this
  921.      for Speedo fonts, I at first thought it a bug in NVDI.
  922.  
  923.      But no. It appears that  existing  GEM  bitmap  fonts are just a happy
  924.      exception, and that text point  size  more generally refers to nothing
  925.      as tangible at all as  a  "cell height" or "recommended line-spacing".
  926.      Instead, the point size merely refers to the "em" of the font.
  927.  
  928.      »»»» THE EM ? »»»»
  929.  
  930.      'Em??? What the *%#@ is the  "em"?'  you  may rightfully ask. Well, it
  931.      seems that the em originally WAS the height of the lead slugs on which
  932.      characters were cast. The  widths  could  vary,  but traditionally the
  933.      capital letter "M" was cast on a  square; hence the concept of the "em
  934.      square" or simply the  "em"  of  a  font.  You  might  see a potential
  935.      analogy between physical lead  slugs  and  the  cells  of a computer's
  936.      character bitmaps, both describing bounding  boxes for the characters,
  937.      but it seems that this  analogy  no  longer  holds very well. You will
  938.      find that ascenders and descenders  of  many outline characters go way
  939.      above and below any em defined for them.
  940.      Neither is there, of  course,  any  requirement  for  the width of the
  941.      letter "M" to equal the em; there  may  not  even BE a letter "M" in a
  942.      font (remember symbol fonts and  various non-Latin alphabets), but the
  943.      font will still always  have  an  em.  Similarly,  although many fonts
  944.      contain so called "em-dash" and  "em-space"  characters, the widths of
  945.      these need not be equal, neither to  each  other nor to the letter "M"
  946.      nor the em of the font. The "em-dash" and "em-space" are simply "wide"
  947.      dash and space characters  and  the  em  itself  totally devoid of any
  948.      exact meaning (except to define the  internal coordinate system of the
  949.      font).
  950.  
  951.      »»»» FICKLE LINE-SPACING »»»»
  952.  
  953.      To some of you  -  with  experience  of  the  new Atari programs (like
  954.      Papyrus etc.) that make use of  outline  fonts  -  it may already be a
  955.      well-known phenomenon that a  change  of  type-face,  EVEN AT CONSTANT
  956.      POINT SIZE, causes the number of  lines per page to automatically also
  957.      change (it  may  vary  WILDLY  depending  on  the  whims  of  the font
  958.      designers). Personally, I only recently  discovered  this with MS Word
  959.      on a PC. The reason is,  of  course,  that  - although there may exist
  960.      some option to use the set point  size  (= the em) as the line-spacing
  961.      value (sometimes called "exact" or  "solid" line-spacing) - the result
  962.      normally isn't usable, due  to  the  seemingly  routine  habit of font
  963.      designers to under-dimension em relative to characters. Thus, the poor
  964.      application  is  forced  to  try  and  figure  out  some  other,  more
  965.      reasonable,  line-spacing  value  based   on   maximum  ascenders  and
  966.      descenders (it seems that a TrueType  font can contain THREE different
  967.      sets of ascender, descender and  line-gap  values - one for Macintosh,
  968.      one for Windows and apparently one intended to unify all formats).
  969.      Atari programmers may actually have a slight advantage in that GDOS is
  970.      supposed to always deliver a  characters  CELL  height, that should be
  971.      immediately  usable  as  a  line-spacing   value;  thus  it  left  for
  972.      SpeedoGDOS or NVDI to sort out the mess in outline fonts.
  973.  
  974.      »»»» WHY ? »»»»
  975.  
  976.      So why, oh why, couldn't the em  of  each and every font have been set
  977.      to be that  line-spacing  value  that  applications  (or  GDOS) now so
  978.      painfully have to deduce  from  other  sources  (that  also would have
  979.      ensured  constant  line-spacing  between  different  type  faces).  Or
  980.      alternatively - and perhaps even  better  -  why wasn't simply the old
  981.      and obviously obsolete concepts of  em and typographical point dropped
  982.      completely on modernizing and computerizing typography (the pica point
  983.      WAS apparently redefined from 1/72.08246 inches in metal typography to
  984.      exactly 1/72 inches in digital typography).
  985.  
  986.      I would have preferred font sizes  given in millimetres and referring,
  987.      ALWAYS, to the useful line-spacing of the  font. (E.g. 4 mm text would
  988.      correspond to an  EXACT  LINE-SPACING  of  11.34  points  or AROUND 10
  989.      points FONT SIZE for most current fonts;  5 mm text would give a line-
  990.      spacing of 14.17 points which might  correspond  to ca. 12 points text
  991.      size.) I realize that metres  and  millimetres  may  perhaps not be as
  992.      appreciated by Anglo-Saxons as by  the  rest  of  us who have grown up
  993.      with them, but who can love POINTS?
  994.  
  995.      To: *.*
  996.      From: Mårten Lindström
  997.  
  998.      PC CONTEMPTIBLES
  999.      ----------------
  1000.      As you might have guessed from all  my  recent talk about PC things, I
  1001.      have now got myself such  a  device.  No,  please, I AM honestly sorry
  1002.      about this; I have  for  a  long  time  been  planning  to  buy a more
  1003.      powerful Atari computer than my  old  1  Mb  ST  (without an "E"), but
  1004.      didn't have the money until recently. But then I wanted the ability to
  1005.      run some  PC  stuff  too,  and  didn't  find  a  PC  emulator  a  very
  1006.      competitive alternative any more, and, well, sorry!
  1007.  
  1008.      Needless to say, my trusty old ST  is  still taking the seat of honour
  1009.      next to my PC on my desk (you  wouldn't SELL a friend would you?). And
  1010.      a very considerable part of the  time  I  spend  in  front of my PC is
  1011.      taken up by Gemulator sessions (in  spite  of Gemulator (4.05) not yet
  1012.      working too well with Windows 95).
  1013.      I still think it would be nice  to  have  a Falcon too, though I guess
  1014.      such dreams will, with my present  reduced assets, have to stay dreams
  1015.      for the foreseeable future.
  1016.  
  1017.      So, what do I think of the  PC?  Well,  compared  to my old ST it is a
  1018.      step up, in many ways (just the  wonder  of being able to use a super-
  1019.      VGA colour monitor, ah), though  I  guess  a  Falcon owner wouldn't be
  1020.      that impressed.
  1021.      Windows 95 offers,  all  in  all,  a  well-working fully multi-tasking
  1022.      environment, which I never had on my  1Mb  ST. But, on the other hand,
  1023.      it is only about how I imagine MultiTOS, Geneva or MagiC would work on
  1024.      an Atari (with enough RAM). Windows  95  may be the major breakthrough
  1025.      that Microsoft has made so much noise about, but only when compared to
  1026.      previous Windows versions (which  for  instance  didn't allow icons on
  1027.      the desktop as I understand  it).  The  general movement, I assume, is
  1028.      for modern systems to look more  and  more like each other, regardless
  1029.      of computer and despite Apple's frantic  efforts to claim copyright on
  1030.      the concept of user-friendliness  itself  (called  "the Apple look and
  1031.      feel" in Apple  terminology).  There  are  some  nice touches, windows
  1032.      being  resizable  in  all  directions,  and  task  switches  are  very
  1033.      conveniently accomplished e.g. through  the keyboard short-cut ALT-TAB
  1034.      (I hope the makers of Geneva, MagiC etc. will take after these ideas).
  1035.      There are minor  flaws  too,  such  as  the  dialog  box  shown before
  1036.      deleting a folder being very  uninstructive  compared to the one shown
  1037.      by any TOS version (even v1.0), but this was to be expected I guess.
  1038.  
  1039.      The PC itself is of course  a  less  inclusive and integrated piece of
  1040.      hardware than an Atari computer,  which  shows itself in various ways.
  1041.      For instance, the BIOS power saving  feature is unable to detect MOUSE
  1042.      activity, which means I must remember  to  at least press the shift or
  1043.      control key once in a  while  to  avoid  that the computer is suddenly
  1044.      shut down "in my face" (I  found  this very frustrating before getting
  1045.      used to it). On the other hand, it is, of course, precisely this - the
  1046.      open  architecture  (allowing  multiple   vendors   to  share  in  the
  1047.      development) - that is behind the  PC  success; with a foundation more
  1048.      primitive than any other  currently  used  personal  computer it seems
  1049.      nevertheless to be on its way to slowly crush all competition.
  1050.  
  1051.      The memory of my PC is 8 Mb internally, plus Windows comes with built-
  1052.      in virtual memory handling; my  hard  disk  is  "850 Mb" (actually 850
  1053.      million bytes = 811 Mb, falsely advertised  as 850 Mb by all retailers
  1054.      these days, though still 27 times the  size of my Atari Megafile). But
  1055.      as much as this would have been on my ST, it somehow doesn't seem that
  1056.      much at all on the PC; it  is  as  if everything took up ten times the
  1057.      space on the PC.
  1058.  
  1059.      The speed is breathtaking compared to  the  ST,  or at least should be
  1060.      when hardware specifications are studied. I  would be lying if denying
  1061.      to have actually experienced  this  speed  (e.g.  when ZIP compressing
  1062.      files or with various graphics  operations  or,  for that matter, with
  1063.      the necessarily very  processor-intensive  task  of  Gemulator), but I
  1064.      often find myself waiting for the  PC  and without really knowing why.
  1065.      The hard disk  -  in  itself  also  very  fast  -  seems  to be almost
  1066.      constantly reading/writing something and I haven't a clue as to what.
  1067.  
  1068.      This leads me to the overall sense of being at loss on my PC. On my ST
  1069.      I have a fair idea of the purpose of just about each and every file on
  1070.      my hard disk, and that of  every  disk  access  too. Not so on the PC.
  1071.      There may be many explanations of course including:
  1072.  
  1073.       1)     I really AM a rookie on the PC
  1074.       2)     Since the  PC  isn't  the  all-in-one  machine  that  an Atari
  1075.              computer is (and  the  hardware  and  OS  furthermore built in
  1076.              layers over a more primordial  core),  things simply ARE a bit
  1077.              more complicated.
  1078.  
  1079.      I however strongly suspect a  further  reason:  the tradition of over-
  1080.      protectiveness and patronizing attitude  on  the  PC and of Microsoft.
  1081.      Anything as complicated as files and  folders is supposed to be padded
  1082.      and hidden away from the mere  user. INSTALLATION PROGRAMS, objects of
  1083.      intense and unrestrained hatred  from  my  part  on  any computer, are
  1084.      immensely popular on  the  PC.  There  are  happy  exceptions, such as
  1085.      Gemulator, that come with  no  installation  program and instead allow
  1086.      the user full control over the  copying  of files and folders where he
  1087.      really wants them. But the ruling philosophy seems to be that the user
  1088.      shouldn't bother his little  head  with  what  an installation program
  1089.      does  to  his  precious  hard  disk,  and  if  (or  rather  WHEN)  the
  1090.      installation program fails, there  is  no  point  in offering a manual
  1091.      alternative, since the user is a complete moron anyway.
  1092.      PC installation programs have  left  me  with files missing (including
  1093.      the Windows 95 installation itself) or worse.
  1094.  
  1095.      To be fair to Microsoft, they have  now  taken some steps in the right
  1096.      direction; for one thing apparently  requiring  any program that wants
  1097.      to be  called  fully  Windows-95  compatible,  to  be  also  fully un-
  1098.      installable, ridding the hard disk  from  all  the garbage it may have
  1099.      littered it with (though I've  tried  a  few "uninstall programs" that
  1100.      didn't work too well). And  they've  also,  very nicely, implemented a
  1101.      number of features, that otherwise  would  be hidden in various system
  1102.      files and the like, as concrete  files and folders. For example: There
  1103.      is a folder for the desktop,  and  when  dragging a file icon onto the
  1104.      desktop, a special .LNK file (a kind of pointer to the source file) is
  1105.      created in this folder (better even than  on the Atari, where all info
  1106.      on the Desktop is hidden in  an  .INF  file). There are other folders,
  1107.      e.g. for a start menu (any sub-folders automatically become sub-menus)
  1108.      where commonly used programs can be represented in the same way.
  1109.      ----------------------------------------------------------------------
  1110.      To: Ictari
  1111.      From: Thomas Nilsen
  1112.  
  1113.      I have written a small example on how the object_change routine can be
  1114.      used from GFA. It is not a guideline on how to do RSC-programming, but
  1115.      merely an example on how to "de-select" selected buttons in RSC-forms.
  1116.      */ See GFA folder.  ICTARI /*
  1117.  
  1118.      To: All (Mårten Lindström)
  1119.  
  1120.      I need some help with a small problem regarding window-clipping.  I've
  1121.      written a routine just to figure out how to do non-modal dialog-boxes.
  1122.      But I'm having a  problem  getting  the clipping routine correct  when
  1123.      my window gets  a  redraw/moved  message  when  it  is behind  another
  1124.      window. It redraws the window fine in  most cases, but when part of my
  1125.      window is  seen on both side of  the  window topping my window it does
  1126.      not redraw correctly.  Sometimes both  the menubar and the dialog-part
  1127.      is drawn  over the  topped  window  and  sometimes just the dialog-box
  1128.      part. As far as  I  understand,  this  is  due  to  the   limit of the
  1129.      object_draw's clipping - as it only  clips  in one rectangular block -
  1130.      and  doesn't handle the redraw correctly  when there is more  than one
  1131.      block to clip. Or am I totally wrong here?
  1132.  
  1133.      ------------------------------ End of file ---------------------------
  1134.