From the DC Squish II manual page 19, 1st paragraph:
Code: Select all
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 an 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
From the PinHead v1.4 docs:
Code: Select all
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 seems to me it has to be some physical characteristic of the binary. The program is not given control until after TOS has done loaded it, so there has to be some thing in the file that triggers this behavior. Something odd about the prg header or such, but I don't see it. I have dis-assembled both, and they do indeed have code to close the file, the so called side affect of the trick.
That feature is new to PinHead v1.4 so I compared it to v1.3 and the only real difference I can see is the BSS segment was removed and some code added to close the binary. Version 1.4 is only 260 bytes bigger, but I'm still not sure how this works. I tried some tests on Hatari, but I think the memory clear is to fast for me to see any differences.