ultiboberon VS oberon-riscv

Ultiboberon – Oberon on bare metal Raspberry Pi\ (8 comments)

This project is still a great example of a complete computer design, starting from Niklaus Wirth's own RISC5 CPU (not a RISC-V) and very simple peripherals over the OS, runtime/garbage collector, compiler, GUI and simple example applications.

One problem of the original implementation is that it was based on an old Xilinx Spartan 3 development board. This is not only no longer available, but it is one of the few FPGA boards that used 32 bit wide fast (12 ns IIRC) asynchronous SRAM chips. Wirth's hardware design relies heavily on this.

Some years ago, there was a compatible board, the OberonStation. However, it seems this is no longer manufactures: https://pcper.com/2015/12/meet-the-oberonstation-kid-friendl...

However, some modified designs exist that implement a cache in FPGA block RAM and an SDRAM controller. These can be used one more recent FPGA boards:

- FleaFPGA "Ohm" board with a Lattice ECP5 FPGA and 32 MB RAM (https://fleasystems.com/fleaFPGA_Ohm.html) - https://github.com/Basman74/Oberon_SDRAM

- Radiona ulx3s, another ECP5 in an open source design (https://github.com/emard/oberon) - https://github.com/emard/oberon

- PapilioPro using a Xilinx Spartan 6 LX, another open source PCB design (https://papilio.cc/index.php?n=Papilio.PapilioPro) - https://opencores.org/projects/oberon_sdram

Shameless plug: my student Rikke's port of Project Oberon to RV32I (this is a real RISC-V), however, we still need to find some time to build an FPGA-based SoC. Currently, it runs in emulation: https://github.com/solbjorg/oberon-riscv

You might want to have a look at https://github.com/solbjorg/oberon-riscv.

Thanks for the link!

Adapting the Project Oberon compiler code generation isn't that difficult, but the devil is in the details :). My student Rikke described some of the challenges porting Project Oberon to RISC-V in her project report (https://github.com/solbjorg/oberon-riscv/blob/master/report....).

I assume that the most time-consuming task to get Project Oberon to run on ARM/Raspberry Pi would be to write device drivers for more complex devices, e.g. USB and Ethernet. These could be written in Oberon (which would be a considerable effort) or possibly be abstracted by using a bare-metal hypervisor that supports VirtIO device abstractions, e.g. Vmware ESXI. This way, one would only have to implement VirtIO drivers in Oberon, which is considerably less complex.

Connecting a PS/2 keyboard and mouse instead of USB might also be an alternative, since drivers for PS/2 are far less complex: http://www.deater.net/weave/vmwprod/hardware/pi-ps2/