[Oberon] Oberon emulator and RAM size

[Michael Schierl]

Hello,


since running Project Oberon with larger RAM seems to get interesting
again, just a few notes about different RAM size support in Oberon
emulators:


* My Project Oberon emulator written in Java supports changing RAM
sizes since 2014. Memory can be increased in powers of two from 1 MB up
to 1 GB, and the memory splitting (between code/stack and heap) can be
configured as well. Note that using code sizes larger than 16MB (and
loading that much code) might trigger some bugs due to relative jumps.
And the running Oberon system requires a few patches to support this at
all. [It also supports 16- and 256-color modes; palette in 16-color mode
is editable via MMIO.]

* My Project Oberon emulator written in JavaScript (running in the
browser) recently (August 2018) got support for 16-color mode and larger
address space, too. Here the address space can only be set to 1,2,4,8 MB
and the memory splitting point will automatically be scaled
proportinally to memory size. Display.Mod needs recompiling when the
color mode or memory size changes.

Here is a 4MB image with 16 colors running in the browser:

<http://schierlm.github.io/OberonEmulator/emu.html?image=ColorBigmemDiskImage>


* I also have a fork of Peter's Emulator in C (not that well tested,
though) which is available at
<https://github.com/schierlm/oberon-risc-emu-enhanced> (Windows binaries
in the Release tab). It also recently (October 2018) got support for
16-color display with editable palette, memory sizes 1,2,4,8,16 MB (with
automatically scaled memory splitting point), and drag&drop support onto
the emulator window to trigger PCLink transfer. For using color display
and/or different memory sizes, use the .Mod files in
<https://github.com/schierlm/oberon-risc-emu-enhanced/tree/master/Mods>
*BEFORE* changing the values. Other patches to the system are not required.

* When using unpatched Oberon system (without recompiling the whole
system), in fact only 14 colors can be used, as the system uses 1 and 15
interchangably for white and 0 and 14 interchangeabley for black (14
mainly from invert mode on color 1). The Display.Mod linked above
accounts for that (in case Display.white is 1) and will shuffle the
remaining colors a bit. If you want 16 different colors, apply the patch
<https://github.com/schierlm/OberonEmulator/blob/master/ProposedPatches/better-display-compatibility.patch>
(at least the bottom part), change Display.white to 15 and recompile the
system.

* This emulator also contains very experimental (i.e. "be happy if it
does not segfault") support for HostFS, i.e. virtual hardware to access
files in one directory as if they were part of the Oberon disk. This
requires a modified inner core on the "real" disk image. Accessing the
files on the host while the emulator is running is *NOT* supported at
all, but you can shutdown the emulator, edit the files, and start it
again. And especially you can salvage your files easily if your
experiments rendered the system unbootable. An example inner core is
also for download on the release page. If you want to use HostFS, I'd
suggest to use my Java emulator as it is a lot more stable (as it has
the support a bit longer and I use it regularly). I know that the "!"
option for System.Directory does not work when using the HostFS files
from this repo (as System.Mod directly tries to access the filesystem in
that case). If you want them, apply
<https://github.com/schierlm/OberonEmulator/blob/master/ProposedPatches/filesystem-encapsulation.patch>
and then use the HostFS modules from
<https://github.com/schierlm/OberonEmulator/blob/master/Oberon/FileDir.HostFS.Mod.txt>
and
<https://github.com/schierlm/OberonEmulator/blob/master/Oberon/Files.HostFS.Mod.txt>
instead.


So even if you don't like Java or JavaScript, you should be able to
experiment with the emulator with larger address space. But it will be
*your* task to port a suitable Oberon compiler :D



Regards,


Michael


PS: I made an overview about the different virtual hardware addresses
used by the various emulators and/or real hardware, perhaps that helps
somebody. Maybe it is outdated again since some hardware or emulator may
use other addresses as well:

<https://github.com/schierlm/OberonEmulator/blob/master/memory-mapped-io.markdown>


PPS: The other patches in

<https://github.com/schierlm/OberonEmulator/blob/master/ProposedPatches>
may be controversial, but probably worth looking into for some of you :)