Are you Olaf Barthel? Much respect! Your Amiga software is fantastic. Thanks for all the things you've written over the years.
The overlay system was indeed very unusual, Thomas Richter did a good job describing it in https://aminet.net/package/docs/misc/Overlay (and of course it's also covered in Ralph Babel's Amiga Guru Book). That's really interesting that Aztec supported it natively, I never knew that.
But it also seemed to be that, if you wanted to, newer linkers (e.g. blink, phxlnk/vlink) combined with appropriate pragmas in the C code, and an example overlay manager from one of these sources, would allow you to make your own overlay executable?
I can't say I ever did it myself - the nearest I got to seeing an overlayed executable was seeing Titanics Cruncher or Imploder use the overlay feature to decompress while loading, skipping the whole question of loading/unloading nodes.
The Aztec 'C' overlay manager code is something of a clever hack which also needs support from the linker to pull it off.
Unlike the original overlay manager (ovs.asm) provided by MetaComCo, two helper functions (segload() and freeseg()) would let you load and unload those overlay nodes on demand whose function pointer address you passed to them. For example, if a node would contain a function called palette() you invoked segload(palette) and, sufficient memory being available, would load the node into memory which would contain that function.
Both segload() and freeseg() cleverly rewrote the jump tables which led to the respective functions through the miracle of self-modifying code (fine in the age of the 68000-68030 but a nightmare on the 68040). The linker did its part by producing overlay information which "hacked" the dos.library/LoadSeg function behaviour, preventing it from ever unloading any of the overlay nodes because that was now the job of the freeseg() function.
Half of the magic of the overlay support happens within dos.library/LoadSeg, one quarter happens in the linker, 20% happens within the overlay manager code and 5% happen in the AmigaDOS manual's developer documentation on how to tell the linker to use overlays.
The original Electronic Arts creativity software (Deluxe Paint, Deluxe Video, Deluxe Music and, um, Deluxe Print) made use of overlays extensively because the original Amiga then featured only 256 KBytes of RAM. With the next year's release of Deluxe Paint 2, etc. the developers had already switched from Lattice 'C' to Aztec 'C' because it gave much better control over which parts of the program would have to be in memory at a time.
You can write an overlay manager in 'C' but it is bound to be far less elegant that the assembly language version. I am familiar with Ralph Babel's 'C' version which (of course) perfectly matches the behaviour of the original ovs.asm code. But I would be really scared to try it in production code.
Thankfully, the use of overlays fell out of favour as newer Amiga models either shipped with more RAM installed, or could be expanded more easily.
The overlay system was indeed very unusual, Thomas Richter did a good job describing it in https://aminet.net/package/docs/misc/Overlay (and of course it's also covered in Ralph Babel's Amiga Guru Book). That's really interesting that Aztec supported it natively, I never knew that.
But it also seemed to be that, if you wanted to, newer linkers (e.g. blink, phxlnk/vlink) combined with appropriate pragmas in the C code, and an example overlay manager from one of these sources, would allow you to make your own overlay executable?
I can't say I ever did it myself - the nearest I got to seeing an overlayed executable was seeing Titanics Cruncher or Imploder use the overlay feature to decompress while loading, skipping the whole question of loading/unloading nodes.