Hi, everyone!

Recently, I decided to return to an old passion of mine: the A2 operating system (formerly Bluebottle) and its language, Active Oberon.

I’ve created MiniA2, a project that makes Active Oberon easier to use outside of A2. Active Oberon is a general-purpose language with active objects and built-in synchronization through AWAIT. MiniA2 brings together the compiler, standard library, command-line tools, and editor support, so you can write applications and build standalone executables without running the A2 desktop.

As a practical example, I’m building AO-Doom, a Doom clone written in Active Oberon. It already loads classic maps and supports rendering, movement, pickups, weapons, and several enemy behaviors. It’s still a work in progress, but it gives the toolchain a substantial real-world application to support.

I’d welcome feedback from anyone interested in language tooling, concurrency, Oberon, or Wirth-style languages.

Explore MiniA2:

https://github.com/active-oberon/minia2

Available packages:

https://active-oberon.github.io/a2-registry

AO-Doom:

https://github.com/active-oberon/ao-doom

For a quick introduction to the language, I’ve also added an Active Oberon page to Learn X in Y Minutes:

https://learnxinyminutes.com/active-oberon/

So now that I've got AOS running again (thanks u/andrejjjP), I decided to try my hand at creating a Minecraft clone. Soren Rener built the voxel ray tracer years before Minecraft and it's a brilliant piece of work. But he didn't document how to build your own worlds with it. Here is the trick. The fractal voxel world is built in the file srvoxels.Mod and it's controlled by srRender.Mod. I used Claude to analyze the code and build a file srMine.Mod and I altered srRender.Mod to srMineRender.Mod to control it. It's super simple at this point, just some islands in some water with some trees and a blue sky. But I think it's pretty cool. Here's the source.

https://github.com/jmdrake/AOSMineCraft

Just in case there is somebody out there who benefits from it: I have written a German description of Oberon-07 from scratch. (And a syntax-poster)

The report also covers the differences from classic Oberon. You can find it here.

And as always: as soon as I put the article online I find an error. It is visible in the screenshot. “wenn ein von einem Projekt …” should be “wenn es von einem Projekt …”. There are probably a lot more and more serious errors and omissions. It is what it is.

Feel free to copy that thing, host it, translate it … it's all fine with me. Only catch: Don't make me responsible for what you do with it. I can't offer any kind of support.

I am thinking about evolving my old Oberon parser into a real compiler. In the process I looked at the code that is in Compiler Construction (Version of May 2017) which emulates the RISC CPU of the Oberon System computer to the extend that compiled Oberon-0 programs from the book should be executable on other machines. However I found that the code for the store instruction looks weird and is unlikely to work - well, as far as I can tell.

Did I find a real error, or is this merely a trick I am not aware of?

I think the condition should be ~ODD(IR DIV 20000000H) rather than adr>= 0. Am I wrong?

There are three places where Oberon is not a context-free grammar:

Qualified identifiers: m.x the parser needs to know that m is a module identifier;

Type guards: x(t), the parser needs to know that t is a type identifier;

Type guard cases: CASE x OF t : s END, the parser needs to know that t is a type identifier.

I'm writing a stand-alone parser for Oberon, and I seem to only be able to parse the expression x(m.t) by also parsing module m to find out if t is a type name. Is there any way to avoid that?

(I know that those constructs are completely reasonable to a one-pass recursive decent compiler where the type information can be known at every step. But the annoying thing is that just three small changes could make the grammar fully LL(1). Say, m::x, x@t and TYPE x OF t : s END for the above,)

The Programming Language Oberon document gives very limited descriptions of these procedures. Could anyone, please, explain what they do more clearly, and/or correct my guesses about what they do?

I'm specifically interested in these:

• GET(a, v) -- I guess it gets the value at address a and puts it into v?
• PUT(a, x) -- it puts value of x at the address a?
• LED(n) -- from description it sounds like it does anything only when LEDs are accessible, so probably not relevant when working on normal PCs?
• VAL(T, n)
• COND(n)

I used to really love using that system. Recently I've tried downloading it for Windows and I can get it to run but all I see is the blue background and the mouse pointer. So I tried the Linux version and it doesn't come up at all. I was wondering if anyone else can still run it.

Hello, I would be glad if anyone could help me with the following questions:

• What was the rationale behind choosing punctuation symbols for logical conjunction (&) and negation (~), but for disjunction using 'OR'? It seems a bit unintuitive, why not just use only words or only symbols?
• What compiler would be best to use for good integration with C libraries on Windows? I've tried OBNC, FreeOberon, and the compiler by AntKrotov. They all seem to have different mechanisms for doing this, and I'm not sure which to use. I also tried Oxford Oberon compiler, but linking C doesn't seem to work on Windows in it.

There are three versions, each based on a slightly different processor instruction set, the final one was for Wirth's FPGA RISC machine. I'm after the middle one, the "Revised Edition" of 2011, which I can't find online. I've found old work that I was doing on the compiler for that particular version. I was making good progress expanding the language to full Oberon, so I thought I'd pick up from there.

An example is below. Oberon+ allows it, but OBC gives me a runtime error. I know that with a NIL pointer there's no record for the type guard to dynamically check, but there's also no other way to cast a NIL from one pointer type to another, despite them being compatible. It's making some basic list handling awkward to impossible.

EDIT: it doesn't work for Vishap Oberon either: Terminated by Halt(-10). NIL access.

MODULE Test;
    TYPE 
        R1 = RECORD END;
        R2 = RECORD (R1) END;
        P1 = POINTER TO R1;
        P2 = POINTER TO R2;
    VAR
        p1: P1;
        p2: P2;
BEGIN
    NEW(p2);
    p1 := p2;
    p2 := p1(P2);  (* okay *)

    p1 := NIL;
    p2 := p1(P2);  (* nil pointer error here *)
END Test.

I'm trying to rewrite the Oberon-0 compiler from Wirth's Compiler Construction from scratch in Oberon-2. I am naively treating Oberon like Ocaml, using extensible records as variant types. That works reasonably well, and being able to group variants using an inheritance hierarchy is a nice plus. Below is a subset of some of the types I am using in the abstract syntax tree. Variable, Selector, and Subscript are the variant branches of Designator

TYPE
    AST* = POINTER TO Node;
    Expression* = POINTER TO RExpression;
    Designator* = POINTER TO RDesignator;
    Subscript* = POINTER TO RSubscript;
    Selector* = POINTER TO RSelector;
    Variable* = POINTER TO RVariable;

    Node* = RECORD location* : Location.T END;
    RExpression* = RECORD (Node) type* : Type.T END;
    RDesignator* = RECORD (RExpression) END;
    RVariable* = RECORD (RDesignator) 
       name*: Name.T 
    END;
    RSelector* = RECORD (RDesignator) 
       Record*: Designator; 
       field* : Name.T 
    END;
    RSubscript* = RECORD (RDesignator) 
      array*: Designator; 
      index*: Expression 
    END;

This is fine, I can handle that. The problem is initializing them! So much boilerplate! I will need to write 48 of these in my AST module:

PROCEDURE NewSubscript* 
    ( location: Location.T; 
      type: Type.T; 
      array: Designator; 
      index: Expression 
    ) : Subscript;
VAR
    s: Subscript;
BEGIN
    NEW(s);
    s.location := location;
    s.type := type;
    s.array := array;
    s.index := index;
    RETURN s
END NewSubscript;

I feel that Oberon ought to define these constructors implicitly.

Although there would have to be caveats to preserve information hiding:

1. A constructor cannot be made for a record that extends a record from another module if that record has hidden or read-only fields.
2. A constructor can only be marked for export if all its record's fields (including the ones from its parents) are marked for export with "*".

If a field is hidden or read only, that's an indication that its has to be handled in a special way from within in its module. No initializing it from outside.

Although it might nice to have immutable records: records with constructors, but with all fields marked read-only. I haven't thought that part through yet.

This is the example code from the Oberon-2 specification in a curly brace syntax.

I'm working on adding the ML module system to an imperative language. I don't want to have to experiment with the base language, and I don't want it to be a source of complications, so Oberon 07 seems like the best basis for it.

Since I'm starting the Oberon parser from scratch I can choose a syntax, and I thought maybe this one would let people look at Oberon with fresh eyes.

module Trees {
    import Texts, Oberon;

    pub type Tree = pointer to Node;

    pub type Node = class {
        readonly name: pointer to array of char;
        left, right: Tree;
    };

    var w: Texts.Writer;

    pub fn (t: Tree) Insert (name: array of char) {
        var p, father: Tree;
        p = t;
        do {
            father = p;
            if (name == p.name^) { return; }
            if (name < p.name^) { p = p.left; } else { p = p.right; }
        } while (p != null);
        new(p);
        p.left = null;
        p.right = null;
        new(p.name, len(name) + 1);
        copy(name, p.name^);
        if (name < father.name^) {
            father.left = p;
        } else {
            father.right = p;
        }
    }

    pub fn (t: Tree) Search (name: array of char): Tree {
        var p: Tree;
        p = t;
        while (p != null && name != p.name^) {
            if (name < p.name^) {
                p = p.left;
            } else {
                p = p.right;
            }
        }
        return p;
    }

    pub fn (t: Tree) Write {
        if (t.left != null) { t.left.Write(); }
        Texts.WriteString(w, t.name^);
        Texts.WriteLn(w);
        Texts.Append(Oberon.Log, w.buf);
        if (t.right != null) { t.right.Write(); }
    }

    pub fn Init (t: Tree) {
        new(t.name, 1);
        t.name[0] = '\0';
        t.left = null;
        t.right = null;
    }

    Texts.OpenWriter(w);
}

If anyone needs a command line Oberon compiler (and basic Oberon System libraries without a UI), here is one:

Oberon

It's using the Portable Oberon 2 compiler from ETHZ.

Hi, I was curious why most programming languages (most of these popular enough so that I can be aware of them) have that "premature return" feature, where you can terminate the procedure (not a function) early on. For example, in Java:

void f() {
  if (true) return;
  System.out.println("quack");
}
...
f(); // does nothing because of that "premature return" (explicit procedure termination)

I was just sitting there thinking that this construct is kind of unnecessary, and the only language I found to not have (or, maybe rather "disallow") it was Oberon-7 (as I checked out, both Oberon-2 (1991), Oberon (1987), and other earlier languages from this "Wirth series" all had this "premature return" feature as well as "every other" high-level imperative programming language out there I am aware of...).

So, in Oberon-7, to rewrite Java's function above, you have to negate the condition, which is just fine (both examples are toyish, maybe I should apologize for that, but they both demonstrates these behaviors good enough):

PROCEDURE f();
BEGIN
  IF ~TRUE THEN
    Out.String("quack");
  END
END f;
...
f(); (* does nothing as well. But has no "premature return" option available! *)

So, are there any documents on this (and, perhaps, other) "improvements" (changes) in design (including the shift to explicit numeric conversion functions that I've read), or maybe there are some talks about it available that I am not aware of? I believe that the removal of this "premature return" was done for a reason, and I would like to know what it was... Does it has something to do with some philosophical/design aspects of "structured programming"? Thanks a lot!

Greetings from Iceland!

I've embarked on a journey to emulate the Project Oberon RISC5 system architecture using Icarus Verilog, with the end goal of creating a QEMU-like environment. This would allow for an exploration of the OS, compiler, and applications detailed in the Project Oberon book, all within a software simulation.

However, I've hit a roadblock. The emulation requires specific FPGA modules from the original hardware (a Digilent Spartan 3 board), including the clock (DCM), RAM, and IO components. My challenge is to either replicate these Verilog modules for a software simulation or find suitable alternatives that can be adapted.

This task is somewhat outside my comfort zone as a software engineer, primarily because it involves a deep dive into hardware emulation specifics I'm not very familiar with. I'm reaching out to see if anyone in this community has tackled similar projects or has insights into creating or modifying Verilog code for RAM, DCM, and IO emulation.

The ultimate aim is to produce a contemporary, step-by-step guide for working through the Project Oberon ecosystem without the need for the original FPGA board. Any advice, resources, or guidance on where to start with these hardware component emulations would be greatly appreciated.

Thanks in advance for any help you can provide!