[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 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 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" -> Manifest). 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/577bd4c7/attachment.html