[Oberon] Large displays in Emulated RISC Oberon

[Michael Schierl]

Am 17.06.2014 17:48, schrieb Charles Perkins:
> Excellent! 
> 
> In my changes I had left the bootloader alone but an 'hardware' change such
> as expanding the address space and moving the IO registers naturally suggests
> re-linking the bootloader to match. Will you be re-linking 
> the bootloader for your modified emulator?
> 
> In any case I look forward to downloading and working with the revised emulator.

I also updated my Java emulator to support the new enlarged address
space. As my emulator loads the boot ROM from a file too, I extended the
file with a few extra words that contain the size of the actual RAM and
the base addresses for ROM and Display. That way it is easy to switch
between different RAM sizes just by using a different boot ROM file. As
Oberon tends to use all its RAM and only GC when it is almost full, it
makes sense to run it with different RAM sizes - I don't always want to
spend 1GB (1/4th of my RAM) for Oberon :)

I also updated the precompiled jar file and the disk/ROM images
available at <http://schierlm.github.io/OberonEmulator>


Now that we can have Oberon systems with different memory sizes and
different display sizes I think it would be interesting to create an
Oberon RISC emulator in Oberon that runs inside Oberon and uses a file
of the host Oberon filesystem as its disk and uses a Viewer in the host
system as its screen. Probably the guest system would need some changes
like the ones for my JavaScript emulator
(<https://github.com/schierlm/OberonEmulator/blob/master/Oberon/power-management.patch>)
so that the host knows when the guest is idle. But then

* it would serve as a good documentation of the RISC processor as I
  assume everybody who is interested in Project Oberon can read Oberon
  source code (but probably not everyone can read Java or C source
  code).

* it would probably make it easier for people experimenting with
  (virtual) hardware changes or paravirtualized hardware (like for
  example a host filesystem that shows files of the host filesystem as
  files to the guest instead of taking it from inside an image) since
  at the moment everyone who tries this must be proficient in modifying
  both Oberon and C/Java source and then it would be enough to do both
  sides in Oberon (and others can port it to C/Java once it is tested
  and working in the emulator)

* Debugging features like a kernel debug interface or hardware
  watchpoints or single-stepping could be added to the emulator and
  everyone (regardless whether he uses real hardware or which emulator
  he uses) can use it for debugging

* It would also be a nice base for some research/analysis of different
  speedup techniques for virtualization on the same architecture (like
  for example QEMU or VirtualBox implement) - these other
  virtualization software is open source but due to the complexity of
  the i386 architecture I think it is hard to understand/follow these
  techniques there. Having them implemented for a simpler architecture
  like RISC5 would make me and probably others have a look at them and
  try to understand them. Or an User-Mode-Oberon (in analogy to
  User-Mode-Linux) - i. e. a compiler that compiles the Oberon system
  so that it runs inside another Oberon system  does not use its real
  hardware but redirects disk to a file and memory access to a chunk on
  the heap) would be interesting, although I think too large parts of
  the compiler would have to be rewritten for that.

What do you guys think about it (the RISC on RISC emulator, not all the
things you could do with it)? It is definitely too much work for me
right now (considering the limited experience I have with the Oberon
system yet), doing the Java and JavaScript emulators definitely was a
lot easier for me, but probably someone else wants to give it a try?


Regards,


Michael