[Oberon] FPGA Oberon again

greim greim at schleibinger.com
Tue Feb 11 10:49:43 CET 2014

Hi Chris,

 > i know i am annoying or lets say more friendly:
 > here is another status report from the DAU (dümmster anzunehmender user):

> My recommendations from 'reading between the lines' of your posts are:
> * Contemplate the meaning of the proverb "Give a man a fish and you feed him
> for a day; teach a man to fish and you feed him for a lifetime". Only
> proceed with this project if you are motivated by that concept.
> * Re-evaluate your expectations to suit reality.
> * Don?t try to run before you can walk:


(by an unknown German Engineer)
> Follow the advice that Paul Reed has already given you in this mailing list.
> i.e. Build Oberon0 first using the sources from the Compiler Construction
> pages of Wirth's site. That will give you positive feedback of being able to
> get an Oberon program running on the Spartan board with a minimal amount of
> time and effort.
> * Expect to have to make some modifications to the source code of the
> compiler and maybe port some of the imported modules (e.g. Texts) to get it
> working as a cross-compiler using your preferred platform.
> Any existing well-documented Oberon-based system (e.g. ETH Oberon-2,
> BlackBox or Gardens Point Component Pascal) would require the least porting
> effort. You should expect it to take anything from a few hours to a day or
> two's work if you are already competent in the use of ETH Oberon or
> Component Pascal and you have studied the differences between the language
> you are using and the 2013 Revision of Oberon used in FPGA Oberon.
> * You will need to implement a linker / loader. However, the most difficult
> part of this work has already been done - just use Modules.mod as your
> starting point. Study the related documentation until you understand how it
> works before you attempt to modify it.
> Once you have successfully completed this exercise you should be totally
> self-sufficient in the use of Oberon FPGA and have gained the confidence and
> ability to take the next step  and adapt the system to suit your particular
> requirements,
Many thanks for your hints, i already stated to go on this stony way.
BUT, the question is not only how to do it but WHY ?
I would like to use the new FPGA Oberon with the main focus on hardware 
interfaces and Verilog, not to reinvent some parts of the OBERON system. 
If the picture on page 5 of the latest Edition of Project Oberon is not 
cheating, somebody has already realized the toolchain, at least as a 

Struggling around with Veriolog, the Xilinx ISE toolchain, hardware 
interfacing etc. porting it maybe to a Spartan-6 (the Spartan-3 board is 
running out of the program) , which requires interfacing to DRAM etc. is 
still a hell of work.
So WHY reinvent Oberon things again and again. And each Compiler, 
Runtime System is slightly different.
(Oberon for Python, Oberon for Javascript, Native Oberon, BlackBox, AOS 
Oberon...). I really don't like (even if i could) to write the 99. 
incarnation of an Oberon System.

Porting ORP.Mod to BlackBox requires for example to adapt all the 
Texts.Mod and Files.Mod interfaces. Also i am not sure at all yet, if 
BlackBox will handle the RS232 interface on Windows right. And this is 
necessary to realize the 2nd boot step.

Or should i use your Astrobe ARM development system ?
Maybe using an Olimex board instead of a PC?

Also for example ORX.Mod which seems to convert the *.rsc file to a 
Xilinx *.mem file is totally missing.



More information about the Oberon mailing list