[Oberon] Project Oberon: What are nexts steps?
volkert at nivoba.de
volkert at nivoba.de
Tue May 6 06:10:22 CEST 2014
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 (=
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
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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Oberon