Re: Fastload equilvent for TOS 1.00 & 1.02 [solved]

GFA, ASM, STOS, ...

Moderators: simonsunnyboy, Mug UK, Zorro 2, Moderator Team

User avatar
lp
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2324
Joined: Wed Nov 12, 2003 11:09 pm
Location: GFA Headquarters
Contact:

Re: Fastload equilvent for TOS 1.00 & 1.02 [solved]

Postby lp » Wed Jul 04, 2012 11:06 pm

I've run into two programs that make the same claim. Anyone know how this "undocumented trick" works?

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
speed.

From the PinHead v1.4 docs:

Code: Select all

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.)


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.
Last edited by lp on Sun Jul 08, 2012 7:53 pm, edited 1 time in total.

User avatar
nativ
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 4088
Joined: Mon Jul 30, 2007 10:26 am
Location: South West, UK

Re: Fastload equilvent for TOS 1.00 & 1.02

Postby nativ » Wed Jul 04, 2012 11:23 pm

Hi LP

there was a thread about the PP/Med loading techniques on dhs.nu recently, think that's maybe more filing to 'fast load'

or the technique used in SWIV? ( perhaps Klaz could enlighten you )

or perhaps the method used in Revolver? ( a snapshot fastload acc )

Sorry I can't help with specifics these might be alternative routes to an answer however?

regards

/nativ
Atari STFM 512 / STe 4MB / Mega ST+DSP / Falcon 4MB 16Mhz 68882 - DVD/CDRW/ZIP/DAT - FDI / Jaguar / Lynx 1&2 / 7800 / 2600 / XE 130+SD Card // Sega Dreamcast / Mega2+CD2 // Apple G4

http://soundcloud.com/nativ ~ http://soundcloud.com/nativ-1 ~ http://soundcloud.com/knot_music
http://soundcloud.com/push-sounds ~ http://soundcloud.com/push-records

User avatar
Klapauzius
The Klaz
The Klaz
Posts: 4302
Joined: Sun Jul 04, 2004 7:55 am
Location: Bavaria
Contact:

Re: Fastload equilvent for TOS 1.00 & 1.02

Postby Klapauzius » Thu Jul 05, 2012 7:22 am

nativ wrote:there was a thread about the PP/Med loading techniques on dhs.nu recently, think that's maybe more filing to 'fast load'

or the technique used in SWIV? ( perhaps Klaz could enlighten you )

The thread on dhs was about not loading the entire program file into RAM by modifying the program header (segment sizes smaller than actual program file size). I think the BSS and heap would still be cleared with this method.
SWIV has nothing to do with this, as it's not using the TOS at all when loading. :wink:

Otherwise, I have no real idea how this should work, sorry.
Perhaps something like a non-conformity in the relocation table that triggers a bug in early GEMDOS versions and results in early termination of the PExec function?
http://www.klapauzius.net
http://dbug.kicks-ass.net/klaz

The tears are welling in my eyes again, I need twenty big buckets to catch them in, twenty pretty girls to carry them down, twenty deep holes to bury them in.

User avatar
lp
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2324
Joined: Wed Nov 12, 2003 11:09 pm
Location: GFA Headquarters
Contact:

Re: Fastload equilvent for TOS 1.00 & 1.02

Postby lp » Thu Jul 05, 2012 9:03 am

I had already thought of that, but PinHead v1.4 has no relocation table. :wink:

EDIT:
One point of clarification, DC Squish II does not claim to fast load itself (the TSR), but claims the squished files it produces use this trick. In both cases neither have relocation information, maybe that is related somehow.

I've tried several tests with Hatari and disk images (for better gemdos compatibility) but all my tests are inconclusive. I rebuilt pinhead with the fclose() removed and tried it on both older TOS versions. According to the PinHead docs if the flcose() is not performed the binary can't be renamed or moved after the machine boots. In my tests I am able to rename it and even delete it.

User avatar
lp
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2324
Joined: Wed Nov 12, 2003 11:09 pm
Location: GFA Headquarters
Contact:

Re: Fastload equilvent for TOS 1.00 & 1.02

Postby lp » Sun Jul 08, 2012 7:53 pm

I found two problems with my test cases. :oops:

Firstly, the PinHead doc is not exactly accurate, you can rename the file, but can't delete it. I kept trying to rename the file in all my previous tests. Also when devpac rebuilds my test case minus the fclose(), it sets the absflag to 0. Pinhead has this set to non-zero. When I force the absflag to non-zero, reboot to TOS 1.00, sure enough I can't delete pinhead from the auto folder.

So here's the trick. If your binary has no fixups, you can fake a fastload on TOS 1.00 and 1.02 by setting the absflag to non-zero. The compendium mentions a bug related to the absflag and recommends to never set it to non-zero. However it does not elaborate as to why. I guess this is why. It leaves the binary open and does not clear the heap. You have to close the binary yourself before it terminates if you use this method.

Also the squished files from DC Squish II have no fixups and the absflag set to 1. They trigger the same TOS bug.


Social Media

     

Return to “Coding”

Who is online

Users browsing this forum: No registered users and 5 guests