: 2). Loader. Currently the psion stuff builds the whole kernel into an a.out,
: which is then converted to psion '.img' and copied across. This is run as an
: application, it then hi-jacks the processor, relocates and voila you're
: running Elks. This means the 'loader' part of the code is always resident
: and occupying space within the kernel code segment. I've been thinking
: around how to remove it and loader the minimum. Again any suggestions?
:
The as86/ld86 combo supports multiple text and data segments, but they're
all combined into one during ld86 load phase. However, just like libc.a
does, you can use place code into higher segments to control it's loader
order within the CS or DS segment. Segments 0, 1, 2 are text, and
3-14 are data, IIRC. The libc startup code uses segment 1 for some special
initializer processing, but if you put the loader portion in segment 2,
using:
#asm
.seg 2
#endasm
in the loader files, they'll end up last in CS. Of course, the special loader
generated symbol _etext will be wrong if you plan on using it... but that
shouldn't be a problem.
The details of the above might be slightly off, check libc.a sources for sure.
I figured all this out when writing my as86 .o file loader...
: 3). The fonts are also currently located in the kernel (data I think). I
: would like to remove them but need something to load them onto the
: machine......Does 'a.out' or Psion '.img' support extra segments?
See above...
Regards,
Greg
