[Oberon] Re. Native Oberon on sourceforge

easlab at absamail.co.za easlab at absamail.co.za
Sun Apr 9 02:39:18 CEST 2006


Op Saturday 08 April 2006 04:16 schreef easlab at absamail.co.za:

> >  > Previously we dicussed oberon0.dsk being GPL. 
> > > I suggested that the real
> >  > inner-guts/kernel..etc. would not be available.
> >  >
> >  > Peter E. wrote:
> >  >> In case it helps any, Oberon0 is built & etc. in Native.Tool. The
> >  >> sources are referenced there and were on ftp.oberon.ethz.ch a few
> >  >> months ago at least.
> >  >
> >  > Did anybody confirm that this allows an Oberon0 to be built 
> > >  without any extra 'key part' ?
> 
Jan Verhoeven wrote:
> I went to the website and couldn't find anything worthwhile.
> 
What 'website' ?
What would YOU consider as interesting ?

>  > >  - Oberon0 compilers written in another language
>  > > (preferably Modula-2
>  > > or Pascal) running on computers that do not run with the Oberon OS
>  >
>  > ? what do you mean by 'Oberon0 compilers' ?
> 
> As far as I know, the Obero0 disk is at least partly built up with an
> Oberon0 compiler (native to Oberon). If we want to be able to 
> rebuild the Oberon0 disk, we at least will need an Oberon0 
> cross compiler for DOS, Linux and Mac.
> 
My fileOberon0Files.Text has no text: "Compiler" .
Which means that the 'boot floppy' doesn't have a compiler.
Which makes sense since a compiler is a special/seldom-used tool
  and is not needed to install and *USE* N-O.

>  > >  - all files that are now making up the Oberon0.dsk image
>  > >  - a general idea why these files are present
>  >
>  > Well I think, it was an intelligent guess at the most essential files
>  > which could fit on 1.4MB.
>  >
> >  - a general idea what new files are required for the 
> current machines
>  >
>  > What "machines" ? It still remains a x86 only sysytem?

> But wouldn't it be nice if it would also run on PPC, Alpha and 
> perhaps an NS 32032?

Some of these exist.
Consider the economics of the exercise: ratio of 'builders to users'.
We are already too dispersed/fragmented.  OTOH 'portability' 
is an sensible [unstoppable world] trend & ARM [and its Intel 
derivatives] are the current leaders in portablility and there is 
already some N-O expertise in ARM-oberon. So I think the 
economics of ARM-oberon could make sense.

>  > Are you intending to cater for:
>  > - StandAlone,
>  > - DOSbased
>  > - LNO           ?
> 
> Let's start with standalone, but able to be built with DOS, Unix and Mac.
> 
There are already so many Oberons, what's your aim ?
I guess you want to write oberon for your 8-bit Uprocs ?
Then the whole aspect of N-O's multi-tasking becomes inapplicable.
Do you just want the Oberon syntax, or do you want the special 
features of N-O, like 'immediately executable commands' and
mouse-chording ?

== Chris Glur.


More information about the Oberon mailing list