Wojtek Without really doing it, your simple question can't be answered easily. It all depends! Generally, the Oberon system covers four parts A) The programming API (aka procedures) your modules use B) The Oberon language your modules are written in (the language constructs you're using) C) The CPU the Oberon system is running on D) The HW the Oberon system is running on A) is (not completely but) fairly stable across all NW Oberon systems Unless your application modules uses very HW specific things, it can be ported quite easily from system to system. That said there are however a few catchups: Texts and Objects. There are systems where Texts has extensions and systems without. So the API to Texts.Mod is not completely stable. There are systems where all objects have a common type all objects are inherited from (S3, AO) and there systems where this is not the case. B) Here you have basically two different approaches: 1) Either you have a compiler (see point C) below) for the Oberon language your modules are written in. Or 2) you port your code from one Oberon language to the other. Oberon went through different steps of evolutions: starting with Oberon-1 to the enhanced Oberon-2, taking a different approach with ActiveOberon and kinda back to the roots with Oberon-07. (neglecting all the dialects of the mentioned languages for a moment) Depending on the language constructs you were using, the porting task is rather easy, fairly complex or almost impossible. C) There is a handful of CPUs (or better ISAs) the compiler can have as target: x86, x64, Sparc, ARM, RISC-V, RISC5... As seen in B) there is also a handful of Oberon languages. For the compiler this multiplies out: L languages on M machines = L*M different compilers. It's often that you have L frontends (language parsers) with M backends (code generator). For LinzOberon on FPGA, you would need the combination: "Oberon-2" parser frontend with a "RISC5" code generator backend. This does not exist so far. D) the HW is quite different from machine to machine. Here some examples: memory size, file system, display size, color depth, IO addresses, networking... So the HW-dependent SW layer (aka HW drivers) like Input, Display, Kernel, FileDir etc. have to be adapted accordingly. To have a system like LinzOberon on FPGA, you would need to mimic the HW it's running on. It depends on the language constructs you were using in your modules. From what I see in the screenshot you attached, I'm just guessing: I could imagine that porting your code over to Oberon-07 is faster than waiting for an Oberon-2 compiler for RISC5 Assuming you modified the Verilog to offer color graphics and enough RAM ( br Jörg Am 28.11.20, 03:51 schrieb "Oberon im Auftrag von Skulski, Wojciech" <oberon-bounces@lists.inf.ethz.ch im Auftrag von skulski@pas.rochester.edu>: Joerg: thank you. I made the change. I often run my computer w/o rebooting. I started looking into V4 in some more detail after I decided to dust off my B2 Data Analysis Framework developed in 1996-1998. It was sitting somewhat forgotten in my archives. The attached display may not be meaningful to you. A nuclear physicist will recognize the dE versus E in the upper plot, neutron multiplicity versus charged particles in the middle one, and 1D histogram in the lower one. I wrote not only this framework, but also extensive documentation. I will post it on RiskFive, time permitting. So now I am thinking how I can port this to FPGA Oberon. Ideally the entire V4 would be ported as well because it is just wonderfully useful. So I looked into V4 Kernel.Mod and I can appreciate how different it is from the V5 aka FPGA Oberon. I wonder where is the line between lower system modules like Kernel or Display, and upper modules like Edit, Elements, or Dialogs. Porting the lower level is probably hopeless. Too many dependencies on the OS. But the upper level should be portable. Unfortunately the language has been changed. I wonder how many code changes will be necessary to port V4 to FPGA Oberon System. Of course I know that a new board will be needed. RiskZero with its 4 MB is probably sufficient. Your Pipistrello will be more than sufficient. Thank you, Wojtek ________________________________________ From: Oberon [oberon-bounces@lists.inf.ethz.ch] on behalf of Jörg [joerg.straube@iaeth.ch] Sent: Friday, November 27, 2020 8:16 AM To: 'ETH Oberon and related systems' Subject: [EXT] Re: [Oberon] Oberon V4 Windows startup oberon.exe Wojtek In case you're building LinzOberon new, you might correct the following small error: In "Files.GetTempName()" change "n := tempno;" to "n := tempno MOD 80000000H;" If your Windows system runs for more than 24 days without a boot, tempno might be negative. The WHILE in GetTempName only works if n>=0. br Jörg -- Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon