11–20 of 44 posts
I've been working on this project for the last few months. I'm glad you find it interesting!
I won't reiterate what my advisor has already said, but like mentioned in the README of the linked repository, if you just want to try it, you can clone the emulator here, which includes a RISC-V image: https://github.com/solbjorg/oberon-riscv-emu
The port should also be quite easy to hack on, if you so wish. :) I'm happy to answer any questions as well.
Earlier quoted context omitted.
"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 mak…
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 ). Unfortunately, FPGA boards with 32 bit wide SRAM are…
Hi, this port of Niklaus Wirth's Project Oberon ( http://www.projectoberon.com ) to RISC-V (rv32im) is the semester project of my student Rikke Solbjørg at the department of computer science at NTNU in Trondheim/Norway. The system currently runs in a version of Peter de Wachter's emulator modified to use a RISC-V CPU emulation instead of Wirth's RISC5 (now isn't that confusing? ;-)). Rikke's announcement on the Obero…
I'm familiar with Oberon and have contributed to Peter De Wachter's Norebo bootstrapping scripts. I wrote a recent comment in another thread about the use of "applicative literature" in pedagogy. https://news.ycombinator.com/item?id=25490826> Rikke's README for this project—and many other projects related to Oberon—end up describing processes in natural language, with steps to be performed manually, e.g. to change the bootloader. This is not special to Oberon, though. The gist of my argument is that pretty much every student and professor already has a suitable environment for handling process documents that could be adapted to be also executable by a machine. Do you have any thoughts about this? Do you have any experience trying to work with anything that follows Knuth's "literate programming" paradigm (including difficulties you've encountered)?
Anyway, nice work by you and your students. Wirth's RISC machine has a simplicity that others don't, which makes it good for teaching, but it makes some pragmatic choices that make it more realistic than similar attempts that result in toy computers that are a little too toy-like. It's work like this that makes for a decent transition after going from not knowing anything about a computer to hands-on understanding using a practical fantasy system like Wirth's to a full-on "industry-approved" instruction set RISC-V.
Can anyone give a quick summary of what makes Oberan OS interesting? Is it an RTOS? A microkernerl? What's distinctive about it?
Can anyone give a quick summary of what makes Oberan OS interesting? Is it an RTOS? A microkernerl? What's distinctive about it?
As far as I know it's also the only system currently in existence that fullfills that promise.
Hi, this port of Niklaus Wirth's Project Oberon ( http://www.projectoberon.com ) to RISC-V (rv32im) is the semester project of my student Rikke Solbjørg at the department of computer science at NTNU in Trondheim/Norway. The system currently runs in a version of Peter de Wachter's emulator modified to use a RISC-V CPU emulation instead of Wirth's RISC5 (now isn't that confusing? ;-)). Rikke's announcement on the Obero…
I know that it and A2 are more complex than Oberon, but a riscV version of those would be awesome, particularly the concept of managed memory without GC.
Earlier quoted context omitted.
How much memory does it require to run?
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.
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
Can anyone give a quick summary of what makes Oberan OS interesting? Is it an RTOS? A microkernerl? What's distinctive about it?
It is a complete single user graphical workstation OS, written in a GC enabled systems programming language.
Niklaus Wirth got his inspiration out of Mesa/Cedar during his second sabbatical at Xerox PARC (during his first one he ended up creating Modula-2 inspired by Mesa).
You can see what Mesa/Cedar was capable of by checking this videos,
"Eric Bier Demonstrates Cedar"
https://www.youtube.com/watch?v=z_dt7NG38V4
The original Oberon system was a simplified version of it in more affordable hardware, then from its roots, a series of other variants were born, Oberon-2, Active Oberon, V4, System 3, Component Pascal, Zonnon, are the most well known. Eventually Niklaus Wirth decided to go back and see how much he could remove from original Oberon and still have it be a systems programming language with GC, thus Oberon-07 was born, with a couple of revisions, the latest one from 2016.
Going back to the original one, this is what you got in the package:
- A full stack single user graphical workstation, in a GC enabled systems programming language
- The only kind of application are modules, loaded dynamically
- Applications are just modules that register themselves into the system to be available on the REPL or in menus when loaded, e.g. Module.Command will load Module and call the procedure named Command, which can then be fed data from the REPL, mouse selection or selected application window
- This brings dynamism similar to Smalltalk and Lisp machines where you get access to whole OS and each application is extensible
At a given point during the 90's the ETHZ IT department had plenty of people using Oberon based workstations.
For a couple of screenshots about Oberon System 3 and Active Oberon, with links about Xerox PARC related stuff have a look at https://www.progtools.org/article.php?name=oberon§ion=co...
Can anyone give a quick summary of what makes Oberan OS interesting? Is it an RTOS? A microkernerl? What's distinctive about it?
What is interesting about Oberon is that it is a complete (i.e. OS + compiler + HW) usable system that can be understood in its entirety by a single human being within one lifetime. As far as I know it's also the only system currently in existence that fullfills that promise.