[Oberon] ORL.Mod

[Charles Perkins]

Dear Paul,

On May 19, 2014, at 8:40 AM, Paul Reed <paulreed at paddedcell.com> wrote:

> Dear Chuck,
> 
>> I would like to be able to create the inner core startup binary image that
>> is loaded by the RISC5 boot loader from the flash.
>> 
>> Does anyone have a copy of the ORL.Mod file that they can share with me or
>> can it be made generally available?
> 
> As I've commented before, the code for a cross-linker such as ORL.Mod is
> pretty much the same as Modules (e.g. with no need to call the module
> bodies).
> 
> Rather than publish an additional whole load of cross-tools, with
> attendant dependencies and version-control issues, I'd prefer to help with
> any specific issues you have modifying Modules and would be delighted to
> see such a contribution.
> 
> Now that Peter de Wachter has kindly contributed a highly-portable RISC
> emulator, the task of self-building is considerably easier and would mean
> that no cross-tools are needed, a very significant advantage (GCC anyone?)
> :)
> 
> Let me know what you think.
> Cheers,
> Paul


I agree, there is no need to duplicate code and a self-hosted environment is
in fact my goal.

What I had hoped to learn from ORL.Mod is the format of the binary image
that is laid down in the boot track of the disk or flash card.

I know that the image will contain a sequence of modules and I assume they
are in this order: Kernel, FileDir, Files, Modules

The image clearly holds more than concatenated module files however. It 
appears to be a preserved system image. I want to create this system image.

From BootLoad.Mod I see that the system will first read one sector (512
bytes) from the start of the binary file into the start of RAM, and then from
the 5th word in memory (byte location 16) it reads the overall length of the
image and then it reads all the rest of the image into memory.

Chapter 14 in the new Project Oberon book tells me that the boot loader
then concludes with a branch to location 0, which will transfer control to
the module Modules. So does word 0 contain another branch instruction,
this time to the initialization routine for Modules? 

I would like to understand the following better:

byte offset in memory and in image:
0 - Branch... to the Initialization routine of Modules?
4 - ?
8 - ?
12 - Memory Limit (value overwritten to this offset by the boot loader)
16 - AllocPtr
20 - root of chain of module descriptor pointers?
24 -  Limit/Stack/Heap Origin (value overwritten to this offset by the boot loader)
28 - ?
32 - MT starts here... how big is it?

Are there other structures that come before the modules in memory?

Thank you for your patience,
Chuck