[Oberon] Oberon System emulator for Windows
pablo.cayuela at gmail.com
Thu Feb 13 03:37:54 CET 2020
I'm glad for the great news! I'm wondering about the anonymous
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
Prof. Pablo Cayuela
On Wed, Feb 12, 2020 at 5:24 AM Skulski, Wojciech <skulski at pas.rochester.edu>
> 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
> 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!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Oberon