[Oberon] Oberon OS / HAL / FPGA

[D EMARD]

ULX3S FPGA open[soucre/hardware] can run oberon
https://github.com/emard/oberon

Oberon has been ported from FleaFPGA (minimal changes)
so FleaFPGA runs the same oberon

FleaFPGA is out of stock, getting ULX3S board can be sometimes
difficult, skriptarnica.hr shop or Goran may send a board or two but
for larger quantities there will be crowdfunding campain.

As all is opensource and detailed PCB and parts list online,
you can also request independent PCBA assembly of the board
and people sometimes produce boards that way

Oberon has been ported from FleaFPGA (minimal changes)
FleaFPGA runs oberon

HDL is not 100% done in LOLA2 but some parts manually
edited but after all it directly boots the SD card image downloaded
from oberon site bringing up windows with ps2 mouse and kbd working.

I don't know what exactly version is this as I'm not so
deeply understanding all oberon historic development branches...



On 2/25/20, daniel.schmid at bluemail.ch <daniel.schmid at bluemail.ch> wrote:
>
> Dear Oberon Listeners
> As a rather new user of Oberon (AOS build 9799) I am interested in whether
> there are really FPGAs on which Oberon runs? Does it have to do with the ETH
> PULP project (http://asic.ethz.ch)?
> Thanks a lot and kind regards
> Daniel
>
> ----Ursprüngliche Nachricht---- Von : oberon-request at lists.inf.ethz.ch Datum
> : 22/02/2020 - 12:00 (MN) An : oberon at lists.inf.ethz.ch Betreff : Oberon
> Digest, Vol 189, Issue 21
>
> Send Oberon mailing list submissions to
> 	oberon at lists.inf.ethz.ch
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://lists.inf.ethz.ch/mailman/listinfo/oberon
> or, via email, send a message with subject or body 'help' to
> 	oberon-request at lists.inf.ethz.ch
>
> You can reach the person managing the list at
> 	oberon-owner at lists.inf.ethz.ch
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Oberon digest..."
>
>
> Today's Topics:
>
>    1. Re: Project Oberon (was: Coding practice) (Skulski, Wojciech)
>    2. Re: Project Oberon (was: Coding practice) (Michael Schierl)
>    3. Re: Coding practice (Hans Klaver)
>    4. Re: Project Oberon (was: Coding practice) (Skulski, Wojciech)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 21 Feb 2020 19:08:19 +0000
> From: "Skulski, Wojciech" <skulski at pas.rochester.edu>
> To: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
> Subject: Re: [Oberon] Project Oberon (was: Coding practice)
> Message-ID:
> 	<SN6PR07MB506914243460CA48D653ECD4FF120 at SN6PR07MB5069.namprd07.prod.outlook.com>
> 	
> Content-Type: text/plain; charset="utf-8"
>
> Joerg:
>> As you know, Project Oberon has two parts: a) the Oberon OS and b) the HAL
>> (HW abstraction layer)
>
> Physically it has the third layer, which is FPGA boards and emulators which
> can be termed "soft boards". I actually think that emulators are the most
> undervalued part of the project. They have a great potential.
>
>> 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??
>
> The informal nature of this arrangement creates a problem, I think.
>
>> 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
>
> It would be more natural if the said persons formed a formal Advisory
> Committee with NW being a chairman. If you look around either the industry
> or academia, you will such committees everywhere. The Oberon community is an
> exception.
>
> The community could then discuss, submit propositions and patches to the
> Committee, which could then improve and prioritize the propositions. The
> final step would be an inclusion in the official system. The process would
> be open and transparent.
>
> Lacking a formal procedure is adversely affecting the progress. One can of
> course say "we do not need any damn progress", which is more or less the
> present situation.
>
>> 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.
>
> This is both reasonable and good. It provides a stable base.
>
> The actual firmware implementation is rising some timing issues. The
> implementation can be fixed without touching the instruction set.
>
>> 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.
>
> This is great.
>
>> New HAL features can be added to Project Oberon. I added a 16 color
>> display by changing VID.v and Display.Mod.
>
> Any practical instrument will need to add new peripherals. It can be done
> with new modules. It will not disrupt the foundation.
>
>> But this feature is not taken over into NWs release. ... 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.
>
> A full HD display will take 2,073,600 bytes with 8 bit color. A board with 4
> MB can afford this. There is no reason why the limitation of the ancient
> FPGA board dictates the BW display. The display resolutions and colors can
> be encapsulated in Display and/or SysDef and transparantly implemented w/o
> disrupting the base system. This is why I am advocating that the system is
> parametrized. Without parametrization any change will lead to a domino
> effect. With parametrization the changes will be possible.
>
> All that was actually envisioned in the NW book, but then he did not provide
> the properly parametrized foundation.
>
>> 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.
>
> This is not true. Some instrumentation needs a display. It is not right to
> say "this design is limited by an ancient technology, but this is OK because
> a more general design is not needed anyway".
>
> Wojtek
> --------------------------------------------
>
>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__lists.inf.ethz.ch_mailman_listinfo_oberon&d=DwIGaQ&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=P3kwBLSq9W3-eEJ5UObHdHOuAx2lOGAjiyI6CUg0UM8&s=lP7bIxmlc8S6jY60eI0HON2tBaBJf9Cw1N6nfQRGdzU&e=
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.inf.ethz.ch_mailman_listinfo_oberon&d=DwIGaQ&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=P3kwBLSq9W3-eEJ5UObHdHOuAx2lOGAjiyI6CUg0UM8&s=lP7bIxmlc8S6jY60eI0HON2tBaBJf9Cw1N6nfQRGdzU&e=
>
> ------------------------------
>
> Message: 2
> Date: Fri, 21 Feb 2020 23:22:21 +0100
> From: Michael Schierl <schierlm at gmx.de>
> To: "Skulski, Wojciech" <skulski at pas.rochester.edu>, ETH Oberon and
> 	related systems <oberon at lists.inf.ethz.ch>
> Subject: Re: [Oberon] Project Oberon (was: Coding practice)
Message-ID: <b45acd45-61d1-19fc-214a-3d3adc367c59-6628-5640 at gmx.de>
> Content-Type: text/plain; charset=utf-8
>
> Hello Wojtek,
>
>
> Am 21.02.2020 um 04:01 schrieb Skulski, Wojciech:
>> 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.
>
>
> In my opinion the order is wrong here. Successful collaboration requires
> first to determine the goals (and non-goals) of the collabroration,
> because depending on how the goals match, different members may join or
> not. And it does not only matter if goals are achievable (by the
> members), but also if they are desirable (to most members).
>
> [A good example was the Subversion VCS project, which defined first that
> they want to build a centralized version control system, and which
> features are in-scope and which are out-of-scope. Then they attracted
> like-minded people and were able to achieve their vision, by closing any
> feature requests that were out-of-scope of their vision as WONTFIX.]
>
> I guess there are at least 5 people in the list who are interested in
> "improving Project Oberon", but what is an improvement to some of them
> is a feature-creep or deterioration to others. Which also explains that
> there are different code bases.
>
> For example, some time ago I suggested removing some unused exported
> members, like Display.Handle, from some Project Oberon modules, and
> un-exporting some others, to make coupling lower and make it easier to
> understand some code; and immediately I got some reactions why you
> cannot remove them - "What if somebody wants to create a different
> windowing/input manager? What if somebody wants to extend this or
> that?". My answer would be "If they really want, they would have to add
> this, or something similar, back".
>
> Another example is actual hardware availability. For me it is enough
> that at some point in time, actual hardware existed to run the thing
> (proving that the design is indeed implementable in real hardware), and
> that today there are some means to still run the thing (which need not
> be hardware, but emulation is fine).
>
> So what is an improvement to the system for me is the opposite for
> others, and vice versa.
>
>
> Regards,
>
>
> Michael
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 21 Feb 2020 22:57:51 +0100
> From: Hans Klaver <hklaver at dds.nl>
> To: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
> Subject: Re: [Oberon] Coding practice
Message-ID: <EED11038-B551-4ABD-96BC-7CF53C1B4787-2319-8260 at dds.nl>
> Content-Type: text/plain; charset="us-ascii"
>
> As I found this Omi document Programming Conventions very useful and
> instructive for
> Oberon and Component Pascal programmers, deserving wider circulation, a few
> years ago I made a .pdf document of it (by means of 'printing to PDF'),
> which can
> be found here: https://hansklav.home.xs4all.nl/oberon.shtml
> <https://hansklav.home.xs4all.nl/oberon.shtml>
>
> There you can also find a link to a document that deserves to be better
> accessable
> to the Project Oberon community: the book The Oberon System, User Guide and
> Programmer's Manual, by Martin Reiser. This is the first volume of the
> 'Oberon Trilogy',
> describing an early (1990) version of the Oberon System in a very clear and
> informative
> way, imho still useful for the present Project Oberon 2013 user and
> programmer.
>
> The .pdf file resides on the oberoncore.ru <http://oberoncore.ru/> website.
>
> I own a hardcopy of this book, which I bought in 1991 and which sparked my
> interest
> in Oberon. Not only is it very well written but it is the book with the most
> attractive lay-out
> of all Oberon books!
>
> --
> Hans Klaver
>
>
>> The guys at Oberon microsystems published a set of Programming Conventions
>> for Oberon/L a.k.a. Component Pascal. It is included in the Help file with
>> the Blackbox Component Pascal system. Several possible styles i.e.
>> multiple
>> statements on one line, statements split over several lines etc. are
>> considered to be good practice. Thankfully, nobody is forced or
>> constrained
>> by the Oberon language itself (unlike some languages) to use a prescribed
>> programming style.
>>
>> Rather than inventing our own programming conventions, we adopted those,
>> with the kind permission of Oberon microsystems, for the Astrobe
>> development
>> system. If you do not have access to the original Blackbox document refer
>> to
>> Chapter 8. 'Programming Conventions and Guidelines' in the 'ARM Cortex-M
>> Oberon Programmers Guide' which you can download from:
>>
>> https://www.astrobe.com/Oberon.htm
>>
>> When I'm writing new code from scratch then I use my own personal
>> preferences (which can change from one month to another!) However, if I am
>> making minor modifications to existing code I try to follow the principle
>> of
>> 'when in Rome do as the Romans do' and adopt a similar style to the
>> original
>> author. If these principles are not followed the result can be code that
>> looks as ugly as a one-page document written in 17 different fonts.
>>
>> Regards,
>> Chris Burrows
>> CFB Software
>> https://www.astrobe.com
>>
>>
>> --
>> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
>> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20200221/bfcca061/attachment-0001.html>
>
> ------------------------------
>
> Message: 4
> Date: Sat, 22 Feb 2020 03:53:43 +0000
> From: "Skulski, Wojciech" <skulski at pas.rochester.edu>
> To: Michael Schierl <schierlm at gmx.de>, ETH Oberon and related systems
> 	<oberon at lists.inf.ethz.ch>
> Subject: Re: [Oberon] Project Oberon (was: Coding practice)
> Message-ID:
> 	<SN6PR07MB506954CF66FEEE606EAE841EFFEE0 at SN6PR07MB5069.namprd07.prod.outlook.com>
> 	
> Content-Type: text/plain; charset="us-ascii"
>
> Michael:
>
>> I guess there are at least 5 people in the list who are interested in
>> "improving Project Oberon", but what is an improvement to some of them
>> is a feature-creep or deterioration to others. Which also explains that
>> there are different code bases.
>
> Where is the value proposition if improving the system is not it?
>
> W.
>
> ------------------------------
>
> Subject: Digest Footer
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
>
> ------------------------------
>
> End of Oberon Digest, Vol 189, Issue 21
> ***************************************
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>