Topic       : The GFA-Basic Compendium
Author      : GFA Systemtechnik GmbH
Version     : GFABasic.HYP v2.98 (12/31/2023)
Subject     : Documentation/Programming
Nodes       : 899
Index Size  : 28056
HCP-Version : 3
Compiled on : Atari
@charset    : atarist
@lang       : 
@default    : Document not found
@help       : Help
@options    : +g -i -s +z
@width      : 75
@hostname   : STRNGSRV
@hostname   : CAB     
@hostname   : HIGHWIRE
@hostname   : THING   
View Ref-FileHow to force a fastload on TOS 1.00/1.02 (exploit a bug in TOS)
______________________________________________________________________________

The binary must meet 2 requirements:
  1) No relocation data (must be 100% pc relative)
  2) The ABSFLAG in the header must be set to non-zero (word at offset 26)

The OS will load the file and relocate it.
Control will be passed to the binary like normal.

The OS fails to do 2 things (the bug):
  The BSS and heap memory areas will not be cleared (thus its fastloaded).
  The binary is not closed, it cannot be deleted or moved from the Desktop.

The binary should close itself before it terminates.
  If not, the system will have 1 less file handle available to other apps.
______________________________________________________________________________

To close the binary you have 2 options:

Method #1 (used in PinHead v1.4)
Call fsfirst() with "*.*" in the current dir and open the 1st file you find.
Then simply close the file.
Now fclose(previous handle-1), the binary will then be closed.

Method #2 (used in DC Squish II v2.12)
Check the TOS version:
  If its TOS 1.00:
    If the word at offset $15D2 = $601A, then the next word is the handle.
  If its TOS 1.02:
    If the word at offset $1632 = $601A, then the next word is the handle.
  Call fclose() with the file handle, the binary will then be closed.

TOS 1.04 and up do not have this bug and also supports fastload directly.
______________________________________________________________________________

This technique is probably only useful in small \auto folder programs as it is
sort of hard to write a rather large application that has no fixups.

The information regarding this trick was discovered by dis-assembling the
above mentioned programs and studying the code. Tests were made with old
versions of TOS to verify the mysterious offsets mentioned as well.

The Atari Compendium mentions a bug related to the ABSFLAG and some versions
of TOS, but does not state the nature of the problem. Well, now I know.  ;o)

==============================================================================

Related information:

From the PinHead v1.4 documentation:
  *************
  *           *
  * NEW STUFF *
  *           *
  *************

  -------------
   PinHead 1.4
  -------------

  PinHead Now Fastloads Itself!
  -----------------------------

       Version 1.4 of PinHead uses an undocumented feature of TOS 1.0 and
  1.2 to "fastload" itself.  This means that the speedup starts one
  program sooner in your AUTO folder, since the PinHead program file does
  not cause memory to be cleared when it runs.

       (NOTE: Normally, the use of this undocumented feature would result
  in the PinHead program file being left "open" by the system.  PinHead
  1.4 uses a special technique to avoid this bug in TOS, and you will have
  no trouble deleting, renaming, or copying the PinHead program file after
  it runs.)

From the DC Squish II manual, page 19, 1st paragraph:
  When the FAST bit is OFF, both the BSS and the HEAP
  memory areas are cleared. Early TOS versions, 1.0 and 1.2
  do not know about the FAST bit and therefore 'always'
  clear both the BSS and HEAP. There is a trick to make
  GEMDOS load files 'fast' on TOS 1.0 & 1.2, and SQUISH
  uses this technique to allow fast-equivalent execution
  speed.
______________________________________________________________________________

GEMDOS Processes+