[Oberon] Adjusting Module, Stack, Heap, and Video Memory

[JR]

Chuck

Thx for the technote.

Four remarks:
- Currently, the display memory is mapped into physical RAM. Hence dynamic changing of display geometries directly influences the amount of RAM available for the heap. You can only do that, if you a) reduce the display geometries or b) when you increase the geometries you have to make sure there are no heap objects allocated in the memory the extended new frame buffer will occupy. You might follow this calculation:
   (physMem = 100000H (* 1MB *); base := physMem - 256 - LINELEN * screenH; MemLim := base - 16).

- If we want to enlarge the RAM in the future, another way of memory mapping could be envisioned. As display memory is very time critical we could allocate it in SRAM as today, and could use DRAM only for the physical RAM. As RISC-5 is a 32 bit machine, the max address range is 4 GB. So, we could define all addresses <2G can be used for physical RAM, all addresses >2G are used for display, IO addresses and ROM. Then the base address of the display is always the same (=80000000H). The only limiting factor is the size of the SRAM the display address range is mapped into.

- As the boot loader is written in Oberon, instead of „patching“ you could change the constants stackOrg and MemLim in BootLoad.Mod, recompile it and extract the code.

- If you want to change the stack size (what I did when implementing the color display on a 1MB machine), you have to take this into account: Unfortunately, the stackSize is defined in Kernel.Mod and a second time in Modules.Mod. Either you change the stackSize consistently at both locations or you import Kernel.stackSize in Modules.

br
Jörg

> Am 11.01.2019 um 20:07 schrieb Charles Perkins <chuck at kuracali.com>:
> 
> I wrote a technote on modifying V5 Oberon for different video geometries and more memory.
> 
> It mostly summarizes what other people have done.
> 
> If anyone is curious it can be found at:
> https://github.com/io-core/technotes/blob/master/technote002.md <https://github.com/io-core/technotes/blob/master/technote002.md>
> 
> The ROM offsets I used to patch the boot loader are off by one from Michael Schirl's code... FYI!
> 
> Best Regards,
> Chuck
> 
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20190112/421ddf7b/attachment.html>