skulski at pas.rochester.edu
Thu Jul 30 01:38:15 CEST 2020
thank you for the clarification. I understated that you are not working on it anymore, so the remarks are for anyone who wants to work on the emulators.
>From my perspective, the system either works or it does not. If it does not, then something is missing.
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.
I understand why Michael used the PNG trick: because otherwise he could not serve the file over the net. He packed an arbitrary binary content in the PNG envelope in order to serve the file. It was brilliant. But I not quite understand why he modified the software inside the image, so the software is not going to run on the FPGA anymore.
OK, let me believe there are some mysterious problems which are impossible to circumvent. Due to these problems, the image (in whatever format) can be used under the emulator or with the board, but the contents of the two images are not the same. Let me then believe that ImageB.dsk can only work with the board, while imageE.dsk can only work with the emulator. The reason "why" is fully known to the emulator developer. From my user's perspective I only know that imageB.dsk works here, while imageE.dsk works there. It is all that I need to know.
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
In both cases, the destination imageX is created in situ. The utility first makes the empty image, and then it transfers the files from the source, making necessary modifications.
I can envision a variation of the same theme, like making the corrections "in situ" with the same image.
prompt> toBoard image.dsk # apply fixes such that the SW will run on the FPGA
prompt> toEmul image.dsk # apply fixes such that the SW will run under the emulator
If this could be realized than I would say the entire toolchain works and it is very convenient in practice.
Does it make sense?
From: Colby Russell [oberon at x.colbyrussell.com]
Sent: Wednesday, July 29, 2020 11:33 AM
To: ETH Oberon and related systems; Skulski, Wojciech
Subject: [EXT] Re: [Oberon] Emulators
On 7/29/20 7:49 AM, Skulski, Wojciech wrote:
> Concerning Colby's emulator, the comment in the text explicitly says
> that it can open Peter de Wachter's format.
To reiterate what Michael has by now already said: the in-browser
emulator supports the disk *format* that Peter's emulator uses, but the
*Oberon system build* that Peter's disks uses—or the executables that
you would get by building Wirth's distribution or what's on
projectoberon.com—does not have the necessary system modifications to
work under the in-browser emulator.
(In fact, you should be able to find that same comment in the sources
that Michael has hosted on GitHub, because I contributed the change
upstream several months—maybe even a year or so—before I first
experimented with packaging the emulator as a single, portable file that
More information about the Oberon