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

Charles Perkins chuck at kuracali.com
Sat Jan 12 22:17:59 CET 2019


Thanks Jörg,

I have made some edits to the technote based on your comments. I hope I
have done them justice.

As far as real hardware goes, I look forward to seeing what the community
can do with the new FPGA platforms that are coming available. Before too
long I will want to move beyond an emulated system, and I will want a big
screen and lots of colors!

br,
Chuck

On Sat, Jan 12, 2019 at 12:05 AM JR <joerg.straube at iaeth.ch> wrote:

> 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
>
> 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
>
>
> --
> 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/6752f016/attachment.html>


More information about the Oberon mailing list