4 ms·

How much memory does it require to run?

johndoe0815 6y ago
The original Wirth RISC5 version runs in 1 MB RAM on an ancient Xilinx FPGA board. The RISC-V binaries are a bit larger, but still runs in 1 MB (but more is possible). A bit too large for typical block RAM sizes of affordable FPGAs, unfortunately. Some details on the port and the binary size differences can be found in the project report: https://github.com/solbjorg/oberon-riscv/blob/master/report.pdf https://github.com/solbjorg/oberon-riscv/blob/master/report....
- snvzz 6y ago
  "block ram" (like iCE40's sysMEM) is usually very fast, fancy and dual port, which is why there's so little of it, and is typically spread across the die for reduced latency purposes. From a CPU-in-FPGA perspective, it could be used for e.g. L1 cache. Actual RAM can be slower and external to the FPGA chip. The ULX3S (which can support the minimig Amiga implementation) and the DE10-Nano (miSTer's base board) would make overkill targets for this.
  - johndoe0815 6y ago
    Of course, external RAM is an option. However, using external SDRAM increases the complexity of the hardware significantly, which takes away a bit of the elegance and simplicity of Wirth's original RISC5 FPGA system. Wirth's system used a Xilinx Spartan 3 board with 1 MB of 32 bit wide fast asynchronous SRAM (https://multicores.org/blog/small-is-beautiful.html https://multicores.org/blog/small-is-beautiful.html). Unfortunately, FPGA boards with 32 bit wide SRAM are really hard to find nowadays, especially those supported by SymbiFlow...
    - snvzz 6y ago
      Definitely. SRAM is pure joy to use, but less and less common in FPGA devboards by the day.
- cfbsoftware 6y ago
  We (CFB Software) recently managed to squeeze the full Project Oberon into 512 KB of BRAM on Digilent's Arty7-100T and NexysA7-100T boards. It is sufficient to recompile the entire system on itself.
berkeleynerd 6y ago
I'd love to see a text-only version. That would be fun to develop against and almost any FPGA should be able to run it. Might evolve into an interesting embedded platform over time.
- johndoe0815 6y ago
  Astrobe provides Oberon systems for embedded applications, there is currently a version using Wirth's RISC5 running on 7-series Xilinx FPGAs - https://www.astrobe.com/RISC5/ https://www.astrobe.com/RISC5/ They also have a version for ARM Cortex-M controllers: https://www.astrobe.com/Oberon.htm https://www.astrobe.com/Oberon.htm
- cxr 6y ago
  The "Project Norebo" bootstrap system that this is based on is such a text-only adaptation. It's used for building Oberon system images from a machine that isn't itself running Oberon. Norebo works by taking what is otherwise a full-fledged Oberon system, NOP-ing the hardware display routines and relevant GUI setup, and then it hooks all writes that are destined for Oberon.Log (the text object that appears in the top right viewer by default on a vanilla Oberon system). The build scripts run this system in a headless emulator, and the text written to that log gets dumped over a serial interface instead, which eventually appears in the terminal as stdout. Here's a two minute video showing these build scripts running twice in a modified Norebo environment and producing identical disk images. The notable thing is that the first time it runs, it's actually running in a web browser―fully in a web browser, not shelling out to some cloud provider. EDIT: Sorry about forgetting the video link. It's here: https://www.youtube.com/watch?v=TUpd70Mu0Ek https://www.youtube.com/watch?v=TUpd70Mu0Ek

The original Wirth RISC5 version runs in 1 MB RAM on an ancient Xilinx FPGA board. The RISC-V binaries are a bit larger, but still runs in 1 MB (but more is possible). A bit too large for typical block RAM sizes of affordable FPGAs, unfortunately. Some details on the port and the binary size differences can be found in the project report: https://github.com/solbjorg/oberon-riscv/blob/master/report.pdf https://github.com/solbjorg/oberon-riscv/blob/master/report....

snvzz 6y ago
"block ram" (like iCE40's sysMEM) is usually very fast, fancy and dual port, which is why there's so little of it, and is typically spread across the die for reduced latency purposes. From a CPU-in-FPGA perspective, it could be used for e.g. L1 cache. Actual RAM can be slower and external to the FPGA chip. The ULX3S (which can support the minimig Amiga implementation) and the DE10-Nano (miSTer's base board) would make overkill targets for this.
- johndoe0815 6y ago
  Of course, external RAM is an option. However, using external SDRAM increases the complexity of the hardware significantly, which takes away a bit of the elegance and simplicity of Wirth's original RISC5 FPGA system. Wirth's system used a Xilinx Spartan 3 board with 1 MB of 32 bit wide fast asynchronous SRAM (https://multicores.org/blog/small-is-beautiful.html https://multicores.org/blog/small-is-beautiful.html). Unfortunately, FPGA boards with 32 bit wide SRAM are really hard to find nowadays, especially those supported by SymbiFlow...
  - snvzz 6y ago
    Definitely. SRAM is pure joy to use, but less and less common in FPGA devboards by the day.
cfbsoftware 6y ago
We (CFB Software) recently managed to squeeze the full Project Oberon into 512 KB of BRAM on Digilent's Arty7-100T and NexysA7-100T boards. It is sufficient to recompile the entire system on itself.

berkeleynerd 6y ago

I'd love to see a text-only version. That would be fun to develop against and almost any FPGA should be able to run it. Might evolve into an interesting embedded platform over time.

johndoe0815 6y ago
Astrobe provides Oberon systems for embedded applications, there is currently a version using Wirth's RISC5 running on 7-series Xilinx FPGAs - https://www.astrobe.com/RISC5/ https://www.astrobe.com/RISC5/ They also have a version for ARM Cortex-M controllers: https://www.astrobe.com/Oberon.htm https://www.astrobe.com/Oberon.htm
cxr 6y ago
The "Project Norebo" bootstrap system that this is based on is such a text-only adaptation. It's used for building Oberon system images from a machine that isn't itself running Oberon. Norebo works by taking what is otherwise a full-fledged Oberon system, NOP-ing the hardware display routines and relevant GUI setup, and then it hooks all writes that are destined for Oberon.Log (the text object that appears in the top right viewer by default on a vanilla Oberon system). The build scripts run this system in a headless emulator, and the text written to that log gets dumped over a serial interface instead, which eventually appears in the terminal as stdout. Here's a two minute video showing these build scripts running twice in a modified Norebo environment and producing identical disk images. The notable thing is that the first time it runs, it's actually running in a web browser―fully in a web browser, not shelling out to some cloud provider. EDIT: Sorry about forgetting the video link. It's here: https://www.youtube.com/watch?v=TUpd70Mu0Ek https://www.youtube.com/watch?v=TUpd70Mu0Ek