oberon VS fynedesk

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

The problem with recreating the original Project Oberon system hardware on a current FPGA board is that Prof. Wirth's original design for the Xilinx Spartan 3 starter kit board (https://reference.digilentinc.com/spartan-3/spartan-3) relied on the fact that this board had 1 MB of fast, 32 bit wide, asynchronous SRAM, which is easy to handle. Thus, the CPU clocked at 25 MHz didn't require a cache and even had cycles to spare for the framebuffer accesses.

The OberonStation board replicated this design by using two 16-bit wide SRAMs. All other current boards using SRAM only have a single 16-bit wide SRAM, so all accesses to machine words such as the RISC5 instructions would take two cycles; often, the RAM is also too small, e.g. the BlackIce (https://mystorm.uk) has only 512 kB.

Most of the boards on the market today have SRAM or DDR RAM, which makes controlling the external memory much more complex and requires significant changes to the nice and simple Project Oberon hardware. There are ports using SDRAM, e.g. for the ulx3s (https://radiona.org/ulx3s/, https://github.com/emard/oberon) or FleaFPGA and Papilio Pro (https://opencores.org/projects/oberon_sdram).

On a really large FPGA, you could get by using on-chip block RAM only, but FPGAs with 1 MB of block RAM are still quite expensive...

We (I am one of the developers) also have https://github.com/FyshOS/fynedesk as a desktop environment.

If U like a Go Desktop try this: https://github.com/fyne-io/fynedesk

The Oberon channel has several videos of Oberon in action,

https://www.youtube.com/results?search_query=The+Oberon+Chan...

While Oberon was quite cool, people should also learn about its Xerox influence,

"Eric Bier Demonstrates Cedar"

https://www.youtube.com/watch?v=z_dt7NG38V4

Also dive into what happened afterwards, Oberon-2, Active Oberon, Zonnon,...

Active Oberon could be considered quite modern, also makes the distinction between safe and unsafe pointers, which improves the experience for low level coding.

https://github.com/metacore/A2OS

One of the best things about these systems is proving what systems programming with automatic memory management were capable of.

Given Oberon-2's influence on Go, maybe improving Fyne (https://fyne.io/fynedesk/) with something like gRPC for the dynamic experience, could be a possible sucessor.

The thing is with go is it's kind of made for web applications. It's made by google for google. Taking a look at the standard library you can see the most fleshed out parts are for general system access, networking and particularly http, and crypto. People have obviously made things outside of those scopes like fynedesk, but that's where the focus of golang is.

Another angle for when a toolkit is mature could be when it’s used for a full desktop environment :). MacOS and Windows native toolkits obviously tick the box. GTK+ has Gnome, Qt powers KDE (both have Go bindings), Enlightenment is powered by EFL (no Go support yet). Fyne is being used for FyneDesk https://github.com/fyne-io/fynedesk

One other idea that I had: There are new approaches to the desktop like e.g. FyneDesk, a *nix desktop environment written in Golang (using its own GUI toolkit). It's BSD-licensed (3-clause) and I would expect the team being more than happy with anybody trying to make it available to a wider audience. Might be worth a thought.

100% agree on the theming, quick glance at the current implementation seems to indicate hardcoded values (I am assuming this is an early spec) https://github.com/fyne-io/fynedesk/blob/master/theme/theme.go

we were thinking of contributing to this project fyne-io/fynedesk: A full desktop environment for Linux/Unix using Fyne (github.com)