[Oberon] Project Oberon: What are nexts steps?

[volkert at nivoba.de]

Am 05.05.2014 14:04, schrieb Andreas Baumann:
>
> I also absolute agree like marcus.
> One important but not easy to solve problem is to follow to goals at 
> ones (related to the presentation of information).
>
> First goal:
> I think it is very important to setup a focused approach related to a 
> FPGA Oberon system project.
>> - an easy to get and ready to use "Oberon Starter Kit" (FPGA System and Emulation-System)
> Second goal:
> On the other hand it would be very important to build a ecosystem 
> around the language oberon and related software and products available 
> today like the boards supported by CFB Software.
>
>
>
>> - a "Project Oberon Manifesto": Goals, principles, values, ...
> ==> it would be good to discuss the goal of the "Oberon Starter Kit" 
> or the thing which could be build or developed with the "Oberon 
> Starter Kit"
>
>
Here are my thoughts:

What is the path we want to evolve into the "Future Oberon"? (A) Project 
Oberon 2013 (B)
ETH-Oberon or (C) AOS/A2? For me it is A or B. A is alive, but at 
current state not more
than a "teaching" object. Stuck in 199X. B seams dead, but more feature 
complete. Stuck in 200X.
C is alive, more feature complete, support of multi core / multi 
processor. State of the Art,
compared with A or B. Maybe it is easier to reanimate B, than to move 
forward with A. Maybe it
is the best to go with C and forget A and B. Anyway. Let's say A 
"Project Oberon 2013" is
the future, where do we want to put the focus on? Client-System (= 
Workstation),
Small Server-Systems (incl. Embedded System). For me both. A Client is 
useless without a Server.
So better graphic capabilities and at least network/communication 
capabilities are essential
for Oberon. Next, what is the best runtime platform for "Project Oberon 
2013" to archieve this
capabilities? Options: (A) A Small RISC5 inspired VM on top of a host 
system, (B) Native System or
(C) RISC5 FPGA based System? For me it is first A, then B then C. With A 
we are able to reuse
capabilities of the host system. It make is easier to experiment with 
future System Oberon
features and it has the best portability. B would also be nice, on top 
of a ARM based System,
like the Raspberry Pi, Beaglebone, ..., but you need drivers, and at 
best some kind of HAL for
portabilty here. It is definitially more work than A, may be worth the 
effort. i am sure the
ARM Architecture is here to stay for the next 20 years and has powerfull 
soc implementations.
C is quite interesting, but I believe it is damned to fail, when 
migration to a new fpga-board
is so hard to archive. I am bit shocked about the statement from Paul 
Reed. I can not believe it,
when i see all the other FPGA-Retro Computer System Projects, which are 
n-times complexer than
Oberon. How about new capabities (graphics, network), when you are 
limited with
this (legacy)fpga system? Ok, Dead End.

So if the "Seed" is "Project Oberon 2013" and "FPGA-Oberon is a Dead 
End" the "Oberon Starter Kit"
for me is the current "Project Oberon 2013" with Peter de Wachter's 
Emulator (for Windows,
Linux, OS X, Raspberry Pi), all the documentation and an idea how to 
move forward from here
(in spirit of "Project Oberon" -> Manifesto). The other approach is to 
forget "Project Oberon 2013"
and try to reanimate ETH-Oberon and move from there.

I have no idea how large the "Oberon Community" is. 10 or 15 active 
people? I think there
should be one way to go.

End of my thoughts.

BW,
Volkert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.inf.ethz.ch/pipermail/oberon/attachments/20140506/e2782c1e/attachment.html