[comp.sys.amiga.programmer] DOS Overlays

david@walking.pub.uu.oz.au (David Le Blanc) (06/27/91)

The other day, I decided to have a look at overlays. I have found out
the following.

1) When Blink creates overlays, it generates an 'overlay' table, and
   and 'overlay' hunk for the loader.

   When the loader encounters this hunk, it does the following.

   a) Load the table into memory.
   b) Corrupt the 3rd to 6th long words (inclusive) of your FIRST 
      loaded segment. (I dont REALLY mean corrupt. I'll get to it..)
   c) Halt loading, leaving the file open.

2) When your program is loaded, you find that the ROOT overlay is
   in memory (and all your data) and an overlay table. Your load file
   is also still open.

   You also find that a table has been placed into your loaded segment
   at the 3rd longword (room left for instructions to jump over the table
   I assume). This table appears to be :

       BPTR   Executable_File_Handle
       APTR   Overlay_Table
       BPTR   [Fill in the blanks] #1
       APTR   [Fill in the blanks] #2

3) You can load in more chunks of your program via calls to 'Seek' 
   since you know the address of the File Handle, and the overlay 
   table containing the seek offset,

   Eg from Lattice's _ovlyMgr (reproduced without permission)

       FF52(PC) = address of file handle.
       (A3)     = contains the pointer into the overlay table for the
                  segment we want to load.

       | 00B4  223A FF52                      MOVE.L    FF52(PC),D1
       | 00B8  2413                           MOVE.L    (A3),D2
       | 00BA  76FF                           MOVEQ     #FF,D3
       | 00C0  4EAE FFBE                      JSR       FFBE(A6)

   Now to LOAD the code, you call LoadSeg(). The AmigaDos manual
   says 'LoadSeg(name)(d1)'.

   Eg from Lattice's _ovlyMgr (reproduced without permission)

       FF44(PC) = address of #1
       FF36(PC) = address of File_Handle. 

       | 00CA  243A FF44                      MOVE.L    FF44(PC),D2
       | 00CE  7200                           MOVEQ     #00,D1
       | 00D0  263A FF36                      MOVE.L    FF36(PC),D3
       | 00D8  4EAE FF6A                      JSR       FF6A(A6)

   This code here says LoadSeg(NULL,#1,FileHandle)(d1,d2,d3).

   I would assume that #1 is a pointer to the loaders hunk tables 
   for relocation purposes (Nice of it to leave it lying around :)

   Can anyone explain WHY's, and maybe describe the unknowns #1 and #2?
   Why is #2 never accessed? (I would probably know when I understand
   what it points to..)

   Does WB2.0 have a direct call you can make to 'LoadSegFromFileHandle()'
   (in the same way it has OpenLock() and its ilk)

   Any pointers to GOOD documentation about all this would be greatly 
   appreciated!

Thanks Everybody!
   David




--

 -----------------------------------------------------------------------------
   David Le Blanc    UUCP (home)   : david@walking.pub.uu.oz.au
   Life is a puddle. ACSNET (work) : david@mlb.geomechanics.csiro.au
 - CSIRO Division of Geomechanics - Fragment analysis and 3D Fractal imaging -
          "What do you mean officer? This bike can't GO 140 km/h"
 -----------------------------------------------------------------------------

rosenber@ra.abo.fi (Robin Rosenberg INF) (06/29/91)

In article <6124@walking.pub.uu.oz.au> david@walking.pub.uu.oz.au (David Le Blanc) writes:

>       BPTR   Executable_File_Handle
>       APTR   Overlay_Table
>       BPTR   [Fill in the blanks] #1
>       APTR   [Fill in the blanks] #2

#1 is Hunk tablble
#2 is Global vector

According to the source ovs.a in the directory source on the fourth
disk on the Lattice/SAS C distribution.

----------
	Robin

baxter_a@wehi.dn.mu.oz (06/29/91)

In article <6124@walking.pub.uu.oz.au>, david@walking.pub.uu.oz.au (David Le Blanc) writes:
> 
> The other day, I decided to have a look at overlays. I have found out
> the following.
> 
> 1) When Blink creates overlays, it generates an 'overlay' table, and
>    and 'overlay' hunk for the loader.
....> 
> 2) When your program is loaded, you find that the ROOT overlay is
>    in memory (and all your data) and an overlay table. Your load file
....> 
> 3) You can load in more chunks of your program via calls to 'Seek' 
>    since you know the address of the File Handle, and the overlay 

>    This code here says LoadSeg(NULL,#1,FileHandle)(d1,d2,d3).
> 
>    I would assume that #1 is a pointer to the loaders hunk tables 
>    for relocation purposes (Nice of it to leave it lying around :)
> 
>    Can anyone explain WHY's, and maybe describe the unknowns #1 and #2?
>    Why is #2 never accessed? (I would probably know when I understand
>    what it points to..)
> 
>    Does WB2.0 have a direct call you can make to 'LoadSegFromFileHandle()'
>    (in the same way it has OpenLock() and its ilk)
> 
>    Any pointers to GOOD documentation about all this would be greatly 
>    appreciated!
> 
> Thanks Everybody!
>    David


While I can't follow your disassembly, I have had much trouble with the SAS/C
 overlay manager, and SAS/C have offered to send my a pre-beta of
one that is supposed to work properly. I have not received the replacement 
Blink, so I can't comment on it. Sounds like you should enquire. The
Sydney people are quite helpful.

Regards Alan