[Oberon] Oberon System emulator for Windows
skulski at pas.rochester.edu
Thu Feb 13 04:53:38 CET 2020
I just put all this stuff on Github. I suspect I created a mess with "pull requests", "branches", etc because I never used github before. I have no clear idea how to tame the monster.
In any case, I hope that you can get these files from
The ASCII folder contains both the BlackBox and ASCII. It was not my intention. I wanted to keep them separate.
Also, the master is empty. I have no idea why.
Please note all that I did was to factor out the basic hardware interface into one file. This is still Andreas' EOS as of Feb/03. I made no changes other than using named constants for crucial system addresses. Also note that the EOS has changed since then.
I did not modify the many constants in Display or the FileDir, because these interfaces self contained. These two do not need to be factored out any further because they are already organized very well.
From: Oberon [oberon-bounces at lists.inf.ethz.ch] on behalf of Pablo Cayuela [pablo.cayuela at gmail.com]
Sent: Wednesday, February 12, 2020 9:37 PM
To: ETH Oberon and related systems
Subject: Re: [Oberon] Oberon System emulator for Windows
I'm glad for the great news! I'm wondering about the anonymous contribution...
I see that you are collecting all sparse const declarations all over the modules and put it on an exportable definition module.
I think it is a great work that you're doing for clarity and for classes, because I struggle with that kind of things too when using these and other examples with my students.
Even is hard for my to understand and I can't explain too many parts of the code.
Prof. Pablo Cayuela
On Wed, Feb 12, 2020 at 5:24 AM Skulski, Wojciech <skulski at pas.rochester.edu<mailto:skulski at pas.rochester.edu>> wrote:
this is a great news! I started a sweep over the entire Oberon System in order to make it portable to my future FPGA boards. Step 1 was to weed out all the strange memory locations like "12", "24", "-60", etc. Negative locations are used to interface the modules with hardware, while the small positive locations interface the modules with the boot loader and among themselves.
The verbatim addresses are scattered all over the code. Porting the code would involve changing the numbers in many places, which may cause inconsistencies among the modules. So I gathered all the literal constants in a single module named SysDef.Mod. It is attached. I have all the sources with this module imported and the changes already implemented. I was now looking for a way to compile this version of the System, which I have not done yet.
I did this work under BlackBox, because BlackBox is a great way of formatting the source. But this has created a major incompatibility between the source editor and the compiler running under the emulator. I was thinking what to do next. Like for example continuing the project under Linz V4 with the RISC5 compiler.
The anonymous expert on this mailing coached me through these numbers. His help was essential. There are certain modifications to the compiler which enable importing SysDef.Mod by the standalone MODULE*. These modifications will allow to use a consistent set of definitions across both the boot loader and the actual System. Doing this is paramount for a board developer, though it has no bearing on emulated environments.
I hope nobody will feel uneasy looking at the attached file... It looks quite different from the officially adopted Oberon coding style.
Thank you again for the great news!
More information about the Oberon