<div dir="ltr"><div dir="ltr"><div>Dear Wojtek,</div><div><br></div><div>I'm glad for the great news! I'm wondering about the anonymous contribution...<br></div><div>I see that you are collecting all sparse const declarations all over the modules and put it on an exportable definition module.</div><div>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.</div><div>Even is hard for my to understand and I can't explain too many parts of the code.</div><div><br></div><div>Best regards,</div><div><br></div><div>Prof. Pablo Cayuela</div><div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 12, 2020 at 5:24 AM Skulski, Wojciech <<a href="mailto:skulski@pas.rochester.edu">skulski@pas.rochester.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Pablo:<br>
<br>
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. <br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
I hope nobody will feel uneasy looking at the attached file... It looks quite different from the officially adopted Oberon coding style.<br>
<br>
Thank you again for the great news!<br>
<br>
Wojtek<br><br>
</blockquote></div></div>