[Oberon] Emulators

[Michael Schierl]

Hello Wojtek,


Am 30.07.2020 um 01:38 schrieb Skulski, Wojciech:

> I not quite understand why he modified the software
> inside the image, so the software is not going to run on the FPGA
> anymore.

Let me give some background about my motivation for writing JavaScript
emulators (not only) for Project Oberon.

I'd like to make it fast and easy for interested people to access and
experience exotic operating systems, so that memories to it do not die.

I will therefore assume that most visitors of the page will pick an
image or two from the selection, interact with the system for a few
minutes, and are gone again forever. Therefore, it is more important to
me that the emulated system runs with good performance than that it uses
an unmodified disk image which may be used elsewhere (or using images
from elsewhere).

Same motivatoin, as archive.org provides for example
<https://archive.org/details/win3_stock>.

Which gives me no motivation to add emulation for slow and cumbersome
original hardware like PS/2 keyboards or SPI SD cards, resulting in
slower emulation speed and worse experience (if you load my Unicode disk
image and switch your keyboard to a layout that uses the Cyrillic
alphabet, it will just work in the JS emulator, but not elsewhere).

As I said before, the code for it exists in the C emulator and
elsewhere, and it is only a few hundred lines of code to port to
JavaScript, so certainly doable (just not by me). And it would remove
pressure to "do the real fix" (as described below).

> I would like to work on a OS software which is fully compatible with
> the FPGA board, because the FPGA is the target. The format of the
> image does not matter to me, if the content can be transferred back
> and forth between the emulator and the board.

Jörg has two boards (correct me if I am wrong, perhaps it is only one
board and two different bitstreams for it) and two emulators (one in
Oberon and the one from the macOS store). Each of them require some
different drivers on the disk image, so whenever he moves an image from
one system to another he has to make sure that the correct drivers are
on it, since otherwise the system won't boot or won't show an image.

What I wanted to state is that there is not "the FPGA board" any more.

And therefore I agree with Jörg that there should be a hardware
enumerator in the hardware (and the emulators) so that the software can
detect where it is running on and automatically load the correct
drivers. As it is easy to implement such magic on an emulator, but the
real goal is to make sure that the same enumerator can be implemented on
"the real thing", Jörg wanted to add this enumerator first to his
boards, and then when he got it working the plan was to add it to my
emulators.

Andreas also once mentioned that he does not like to add multiple driver
versions to his images if they cannot be automatically detected during
bootup. Not sure if he would add them if they could be detected, but we
will see when we have them.

> OK, let me believe there are some mysterious problems which are
> impossible to circumvent.

The only mysterious problem is that the emulator writer does not see it
as a goal to spend his own free time to please one user. Even if that
user happens to be you.

> If so, then it would be great to use the following two utilities to
> go back and forth between the two images.
>
> prompt> board2emu imageB.dsk imageE.dsk  # transfer SW from Board to
> Emulator prompt> emu2board imageE.dsk imageB.dsk  # transfer SW from
> Emulator to Board

For Extended Oberon, the lines to run (inside the image) for switching
the driver are something like

ORP.Compile Disk.JS.Mod/s Input.JS.Mod/s
ORL.Link Modules ~
ORL.Load Modules.bin ~

<https://github.com/schierlm/Oberon-extended/blob/515e5f3520d7162307739ff07c6e145daecd0d27/Sources/Disk.JS.Mod>
<https://github.com/schierlm/Oberon-extended/blob/515e5f3520d7162307739ff07c6e145daecd0d27/Sources/Input.JS.Mod>

Other images that are not as well organized as Extended Oberon may
require more or different changes.

Yes I see the problem here - you need to boot the image to be able to
run the commands. But if you only have the JS emulator, you cannot boot
the image. And in case Extended Oberon changes incompatibly (which does
happen), the drivers need to be adjusted, which requires some knowledge
of the Oberon programming language.

Doing them from outside would additionally require to implement both the
Oberon compiler and a way of manipulating the disk image on the host. I
think those exist somewhere, but I never used them. If you don't have
them, they add considerable effort to the conversion and porting them
from Oberon to the host is certainly more than a few hundred LOC of
porting SD Card and PS/2 keyboard from C to JavaScript.


Regards,


Michael