[Oberon] Project Oberon (was: Coding practice)

[Joerg]

As you know, Project Oberon has two parts: a) the Oberon OS and b) the HAL (HW abstraction layer)

a) The OS part of Project Oberon is collaborative, but perhaps in the peculiar way that you write your improvements in a mail to NW and he commits your request (or not). NW is a kind of „human git“😊

Andreas, Paul, myself, probably Chris and others provided input to NW to make the Oberon OS more stable and bug free.
The clearer you describe the error or the improvement including working code snipets, the more likely it is to be included by NW in a next release

b) In my point of view, NW sees his HAL (RISC5 instruction set, expected peripherals and memory layout) more or less as frozen. The only late addition he made to it were interrupts.

As long as any implementation (ASIC, FPGA, SoC, emulator) complies to the described HAL,
the Oberon OS and especially the compiler works on it as is.

New HAL features can be added to Project Oberon. I added a 16 color display by changing VID.v and Display.Mod. 
But this feature is not taken over into NWs release. If you see the Oberon OS (especially the inner core) as a good base for embedded systems, 16 colors is of minor interest as most embedded system not even have a display at all. And remember: colors need a lot of memory, so I had to reduce max code and heap size considerably to make 16 colors work in only 1 MB the board I have provides. BTW: The HAL is not bound to 1 MB. A compliant implementation can have up to 16 MB.

br
Jörg

> Am 21.02.2020 um 04:02 schrieb Skulski, Wojciech <skulski at pas.rochester.edu>:
> 
> Chris:
> 
>  thank you for the summary. I suspect we can wrap up this discussion as follows. (1) We roughly agree that a good style exists and it has even been written up. (2) Not much will change in any variant of the Oberon System (except Astrobe, where there is constant progress). 
> 
> I base prediction #2 on the dictionary definition of the word "project", which says "an individual or collaborative enterprise that is carefully planned and designed to achieve a particular aim".
> 
> In that sense "Project Oberon" is not a project despite its name. There is no "collaborative enterprise that is carefully planned". There is no "particular aim". In particular, improving Oberon System code quality is not an aim which we would all agree upon. For this reason it is not likely to be achieved. I hope this prediction will be proven wrong.
> 
> Lacking a collaborative project, there are several  individual "Oberon Projects". They remain disjoint and pursued in isolation. Not much is moving forward on a common FPGA Oberon System frontier despite seven years since the original release. Things have actually deteriorated because the FPGA boards have disappeared, what was only partly compensated by the Oberon System emulators. An emulator without an actual board has a somewhat limited function. 
> 
> If there was a common FPGA Oberon System project, then how it would look like? (I know I am dreaming.) Here is my own individual dream list concerning the FPGA Oberon System, which is my main interest.
> 
> 1) A project means collaboration among people. So the first step would consist of forming a team willing to communicate and to collaborate on a common FPGA Oberon System. 
> 
> 2) The team would agree on a set of achievable goals. 
> 
> 3) The team would prioritize the goals and assign them to its members.
> 
> 4) Any FPGA project consists of HW, FW, and SW which need be co-developed in parallel. The list of tasks and responsibilities would follow this division.
> 
> 5) Based on the experience with the present System, augmented with emulators, the team would agree on the FPGA board architecture and features. I submit to consideration that the FPGA board would provide two or four MB, preferably of the synchronous type which delivers better performance than ASRAM. Having more than a single MB would allow to add color to the display, as well as develop more ambitious applications. 
> 
> 6) Designing a new board may not be even necessary. Five RiskFive sets exist and these can be distributed among the team. So this step can be short circuited. More such sets can be manufactured by any team member. I can provide the design files and the BOM.
> 
> 7) Simplified and cheaper board versions can be eventually designed. Other boards can get adopted to the project. (Preferably no SDRAM which is hard to interface.)
> 
> 8) The next ingredient is the FW. The current version of RISC5.v is not ideal. Considerable discussion can be devoted to fixing the timing flaws. Team members versed in FPGA firmware could work on fixing RISC5.v.
> 
> 9) The RISC5top.v seems to be surprisingly resilient. The FPGA board designs should take this into account by providing peripherals served by the RISC5top. RiskFive is very close to doing this. We actually achieved this stage.
> 
> 10) I am strongly advocating that factoring out the memory locations in the code will help while working on HW and FW interfacing. I have already done and published this step.
> 
> 11) Ethernet can be brought back to Oberon System with the addition of Ethernet controller(s) to the HW. This has been done with RiskFive, which is Ethernet-ready. Other FPGA boards (to be developed) can add their own variants of Ethernet controllers.
> 
> 12) After achieving the above, the Oberon System code would be ready for a serious facelift. Ethernet services, printing, file sharing, or remote program execution are all among possible facelifts, according to individual interests.
> 
> 13) After achieving the above, the team could continue pushing the Oberon System to become a contender against MicroPython or FreeRTOS, for example. There would be enough momentum in the collaboration that such ambitious goal can become a reality.
> 
> Please note that the above list, though maybe long, is kind of logical. Most of these steps follow one after another in a natural order. 
> 
> How likely is it to happen? 
> 
> Wojtek
> 
> 
> 
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon