" ... simple as possible, but no simpler."   ... A. Einstein

"Computing Systems" includes multiple aspects.^[1] For an overview of these systems, begin with the Wikipedia article. For authoritative documents see Support and References. For other uses of the name Oberon, refer to the disambiguation page.

Oberon V5 RISC emulator on GNURoot Debian on Android on an Alcatel 9015B tablet with keyboard and mouse connected by Bluetooth.

Audience

A novice interested to learn computing from the foundations will appreciate the freedom from overwhelming and unnecessary complexity imposed by other systems. The more advanced user will find an efficient tool with complete sources allowing study in depth. The system engineer might adapt Oberon to specific requirements such as intensive computation, big data computation and automation.

Typical usage progresses through these stages.

1. Installation
2. Configuration
3. Production
4. Bug repair
5. Customization and development

The reader should install and use at least one Oberon system. As preparation, an introductory course covering programming basics is advantageous but not essential.

System Characteristics

Oberon was developed as a stand-alone personal workstation and remains viable in that capacity. The system was designed to attain compactness, comprehensibility, efficiency, reliability, responsiveness,^[2] security and simplicity. The extreme compactness is immediately evident to a novice installing ETH Oberon on a bare PC. The complete system including applications, documentation, graphical interface, fonts and source texts was installed from ten HD diskettes^[3]. For the contemporary perspective refer to Use Cases.

This Book

An Oberon system comprises a collection of modules and this book presents one module per page^[4]. An example is Sort.Mod from ETH Oberon. Additionally there are Tool pages, each of which is a template of executable commands. An example is Sort.Tool. A system building Tool is a template for rebuilding the entire system, including system installer and module packages.

Contributors are listed in the Hall of Fame/Contributors page. Also linked under Local Pages below.

Historical Perspective

Oberon genealogy. Click to enlarge. SVG is rendered from the DOT source.

Following development of the programming languages Euler, Algol W, Pascal, Modula and Modula-2, Niklaus Wirth proceeded to create the Oberon language (language report) with original release occurring in 1986. The language design was driven by the wish to design an operating system similar to the OS of the Alto and the insight that Modula-2 did not have the required language construct, which we would now call type inheritance. Wirth chose the other viewpoint and called it type extension. Beside other syntactic differences, which were mainly simplifications, type extension is the major difference between Modula-2 and Oberon. Having met at Xerox PARC, Wirth collaborated with Jürg Gutknecht to build a complete operating system written in the Oberon language. This system was also named Oberon. The distinction between language and system is usually obvious from the context where the term appears.

In subsequent developments, small syntactical changes created various dialects of the language (Oberon-2, Component Pascal, Active Oberon, and Oberon-07), with compatibilities and incompatibilities. Variants of the operating system also evolved, again entailing small incompatibilities. The four most prominent of these OS flavors are

• ETH Oberon (formerly System 3, S3) is written in Oberon-2^[5].
• V4 Oberon (aka Linz-Oberon) basically written in Oberon but with many extensions in Oberon-2
• AOS (aka Bluebottle and A2) written in Active Oberon, and
• Oberon V5, described in Wirth's Project Oberon, 2013 Edition and written in Oberon-07.

With reasonable effort, incompatibilities can always be resolved to allow shift of source text from one system to another.

Beside being a stand-alone operating system, Oberon has been implemented as an emulated operating system atop other systems, decades before virtualization became a buzz-word. The most prominent of these emulated Oberon Systems was Oberon V4, which was implemented on top of SunOS 1 & 2, Ultrix, Irix, AIX, MacOS 7,8,9 (both 68K and Power PC), AmigaOS, TOS (Atari), OS/2, Microsoft Windows, HPUX, and (of course) Linux^[6]. Oberon V4 was sometimes also called Linz-Oberon, due to the fact that it was maintained by the group around Hanspeter Mössenböck, who joined the faculty at JKU Linz in 1994. But also System 3 was implemented on top of another operating system for MacOS (68K and PowerPC), SunOS (SPARC and x86), and Microsft Windows. A2 is running as an emulated OS on Microsoft Windows, Linux, and Solaris (x86). In 2015 Peter Matthias revitalized System 3 under the name "Oberon Linux Revival" (OLR) as a multi-platform proof of concept running both in framebuffer-mode and in the X-Window System on X86, Mips, and ARM hardware under Linux.^[7]

Refer to the articles about the language and about the OS for further details and to find references to the extensive literature.

System Variants

The Oberon system runs directly on several machine architectures and as a subsystem in several host operating systems. Order of rows is approximately chronological.

In A2, identifiers "A2" and "Oberon" in the name or text of a source module denote context ^[21] where necessary. This is the syntax in ActiveOberon.

Module := "MODULE" Identifier "IN" Identifier ";" ...

Where context is not formally recognized, an identifier in a comment is possible.

Module := "MODULE" Identifier "(* IN " Identifier "*);" ...

An identifier can also be prefixed to the module identifier.

Module := "MODULE" Identifier Identifier ";" ...

As the Oberon filesystem does not support folders, name conflict can be avoided by prefixing a file name.

NameOfModuleFile := Identifier Identifier ".Mod"

The name of a file containing a module source can differ from the name of the module. Within the scope of a module, the name of an imported module can be aliased. Out := OutStub for example. Syntax is in the Oberon-2 Report.

Use Cases

Installing

The Oberon0 installer for ETH Oberon running under QEMU in Debian Linux.

A system is chosen and, using the link in the table of variants, an installation archive is retrieved. Instructions for installing and configuring the system are linked in the last column of the table. For some systems, instructions are also available in a system specific page linked in the third column.

Getting Started

The user interface of the Oberon System is quite surprising on the first sight.^[22] It is a so called text based user interface (TUI) and combines the point-and-click convenience of a graphical user interface (GUI) with the linguistic strength of a command line interface (CLI). It is closely tied to the naming conventions of the Oberon language. Any text appearing (almost) anywhere on the screen can be edited and can be used as command input. Commands are activated by a mouse-middle, MM, click^[23] on a text fragment of the form Module.Command (optionally followed by parameters, which are terminated by ~). A command is defined by a procedure, which has an empty argument list. Parameters to the command have to be defined before executing the middle click and must be explicitly scanned and retrieved by the procedure. There are no checks nor any questions asked during command execution. This is sometimes called a "non-modal" user interface (UI). Nothing like a command prompt is required. Although radically different from a command line, the TUI is very efficient and powerful.^[24] Active elements can be embedded in Oberon texts: a clock showing the current time, push buttons, or graphical elements visualizing data. Most user interface elements are realized with the help of documents. A steep ascent in the early learning curve can be somewhat challenging. No questions are asked: this is a deliberate design decision, which needs getting used to. For example, most familiar editors ask the user when closing a modified text: this is not the case in the Oberon System. The usage of the TUI and programming interface is fully documented in Martin Reiser's book "The Oberon System".^[25] A short introduction to the user interface can be found on Niklaus Wirth's home page.^[26] The later Versions of System Oberon, Oberon V4 (or V4 in short, sometimes also referred to as Linz-Oberon) and ETH-Oberon (sometimes also called Oberon System 3, S3 or Spirit of Oberon), enhanced the basic interface with different but incompatible implementations for buttons, drop down menus, and other active elements. V4 used for that purpose a dedicated control character embedded in normal text in contrast to System 3, which extended the kernel by introducing persistent objects. Both extensions include a large set of user interface elements.

Mastering the Oberon user interface, both the purely textual and also the so called Gadgets System (under ETH Oberon), is absolutely non-trivial. Therefore it is recommended to proceed after a successful installation of Oberon System 3 to André Fischer's Oberon System 3 Tutorial. An expanded version of this tutorial is published as a book,^[27] which is now out of print. Although the book has a standard copyright, it is available in electronic form under a single user license in every installed version of System 3 (Windows, Linux or Native, i.e. also with the Gadgets toolkit of OLR^[7]). If you try to read it in System 3, you are confronted with the classical chicken and egg problem: You have to master the user interface to have access to the documentation of the user interface. Therefore some detailed instructions for reading "The Oberon Companion" – after a successful installation of the Oberon System can be found by opening the file Book.Tool with the command Desktops.OpenDoc. If this command is not present in any of the windows/viewers, which are opened by default when you start the Oberon System, you can click anywhere with the left-mouse button (ML) in any viewer and type the command Desktops.OpenDoc Book.Tool ~. Then move the mouse over Desktops.OpenDoc and do a middle-mouse button (MM) click. This will open an new viewer with a table of contents of "The Oberon Companion". All lines with blue text are hyperlinks to the chapters of the book, which in turn can be clicked with the MM button so that the chapter will open in a new viewer. The license in Book.Tool gives the user the right to print a single copy for personal use. I had good results in print with a GhostScript based free PDF converter. If you want to print an open document in Oberon, i.e., the contents of a window (or viewer in Oberon terminology), you have to set the star shaped mark by hitting the F1 key (see Tutorial) and then issue the command Desktops.PrintDoc Default * ~ by a MM click on Desktops.PrintDoc. In an Oberon command the * is not a wildcard, but symbolizes the marked viewer.

Reading this Book

WebBrowser.Open https://en.wikibooks.org/wiki/Oberon ~

Desktops.OpenDoc 
"http://www.loband.org/loband/filter/org/wikibooks/en/%20/wiki/Oberon"[29]

Desktops.OpenDoc 
"http://www.loband.org/loband/filter/org/wikibooks/en/%20/wiki/Oberon/Oberon.Sort.Mod"

firefox https://en.wikibooks.org/wiki/Oberon

firefox https://en.wikibooks.org/wiki/Oberon/Oberon.Sort.Mod

Oberon Text

Confusingly for a novice, three forms of line ending can be found in text files in contemporary computer systems.

• In Oberon and some other systems, a line of text ends with the carriage return character, denoted CR.
• In Unix-like and some other systems, a line of text ends with the line feed character denoted LF.
• In DOS, Microsoft Windows and some other systems, a line of text ends with the two characters, CR and LF.

This multiplicity poses no difficulty in Oberon; most Oberon systems allow convenient editing with any of these line endings.^[30]

An Oberon Text^[31] can appear to be no more than a plain text comprising a sequence of ASCII characters. Nevertheless Text in Oberon is a type defined in the Text module. A Text of this type is a sequence of characters including non-printing characters. A character in a Text can have attributes including typeface, size and color. Furthermore a Text can include non-character objects; an image or a hyperlink for example. Consequently two displayed documents, one an Oberon Text and the other an HTML text, can have the same appearance and the same behavior of links.

 VAR
   T: Texts.Text;
   R: Texts.Reader;
   ch: CHAR;
 BEGIN
   NEW(T);
   Texts.Open(T, “Texts.Mod“);
   Texts.OpenReader(R, T, 0);
   Texts.Read(R, ch);
   WHILE ~R.eot DO
     Out.Char(ch);
     Texts.Read(R, ch)
   END
 END

System Startup

Brief remarks here are intended to guide the student toward study of the authoritative documents.

Booting and Multi-booting

Boot Manager runs on the PC hardware independent of the operating system. In this case Boot Manager ran on a virtual guest machine provided by QEMU. The screenshot is grabbed by the QEMU host.

ETH Oberon, A2 and other systems working directly on x86 hardware offer the further possibility of multiple operating systems requiring boot management. Boot Manager was written by André Fischer according to Oberon principles and is now maintained in the SVN repository at the ETH. These pages have additional information.

• Using a boot manager, with application to ETH Oberon, predating Boot Manager.
• André Fischer's instructions for Boot Manager.
• Boot management subsequent to Boot Manager. Topics including GPT and UEFI.

Contributing a Module or Tool Not in the Book

Firefox and A2 on Wayland and Weston on Debian 10.

• Initialize a Module or Tool page from a published release. Preferably the latest. Oberon.Sort.Mod, for example, is taken from the Oberon subsystem in UnixA2. Indicate the source in the wiki edit subject line.
• Use Oberon naming conventions.
• Avoid page duplication. If two systems share a source module, a page redirect might be preferable to duplicate pages.

Addition of a Text is the first two steps of the dataflow diagram above. The first step is performed by the contributor. The second is performed automatically by the MediaWiki server. Retrieve the MediaWiki module (ETH Oberon, Oberon subsystem of A2) to your Oberon system and compile it. Open a viewer with the module to be contributed and * mark the Text. Translate to MediaWiki markup with "MediaWiki.Markup * " and save the <Module>.Mod.mw with Edit.StoreAscii or ET.StoreAscii.

To add the page to the book, a browser capable of HTTPS is necessary; Desktops.OpenDoc in ETH Oberon is inadequate. Being logged in to a Wikimedia account is advisable. In the table above, click on an identifier to open the system specific page. There add the name of the intended module and "Publish change". The new entry will be colored red. Click on it to open the page for the new module. Copy and paste the text from <Module>.Mod.mw and "Publish change".

Editing this Book

All progress is welcome. Correct errors in grammar and in algorithms. Present unrefined ideas in the talk pages.

Comparing Versions and Pages

Oberon has module Diff. For example, two pages can be retrieved to files TextFile1 and TextFile2. Then MM on Diff.Do TextFile1 TextFile2 .

To compare versions of a page within the book, open the history using the button at the top of the page. Choose two versions and "Compare selected versions".

To compare distinct pages, ID numbers are specified in a URL. In the page history of ETH_Oberon/2003-01-05/HTML.Mod, when the mouse pointer is hovered over the date in the entry for the original version, ID 3702511 is reported by the browser. The original version of A2/Oberon.HTML.Mod is ID 3504568. The URL

https://en.wikibooks.org/wiki/?diff=3504568&oldid=3702511&diffonly=1

produces a side by side comparison. "Compare" works well where a fraction of lines differ. When most or all lines in the compared pages differ, comparison has little or no value.

Hardware

Model Name	Image	Processor	Boot Store	Memory	Persistent Store	Approximate Price, US$	Notes
Ceres		NS320xx	32 kB ROM	2 MB DRAM	40 MB Hard disk drive	Rare and collectable; price unpredictable	[32] [33]
Intel 80386 PC and descendants	The ETH Oberon system on a Tatung TWN-5213 CU tablet.	i386[34], i486, P5 and various successors	Hard disk drive	SDRAM	Hard disk drive	Negligible for a disused machine	ETH Oberon is installed and used routinely.
Digilent Xilinx Spartan 3 Starter Board		Xilinx Spartan 3	SD[35]	1 MB SRAM	SD	100	Used and NOS boards on the market
Pepino LX9		Xilinx Spartan-6 FPGA	128 MB SPI	1 MB SRAM		100
OberonStation		Xilinx XC3S700AN FPGA	microSD	1 MB SRAM	microSD		Website unreachable September 2018.
RiskZero		Spartan-6 FPGA	full size SD, microSD	4 MB ZBT	full size SD, microSD	refer to Design files and cost.	Prototyping.
RiskFive		Xilinx Artix-7 FPGA	16-32 MB SPI Flash	4 MB ZBT	microSD	"expensive"	Motherboard plus FPGA module. Available.
Radiona ULX3S		Lattice ECP5 LFE5U-85F-6BG381C (85K LUT) FPGA	4–16 MB Quad-SPI Flash	32 MB SDRAM 166 MHz	microSD	60-140	Boards with 12K LUT also available. [36]

FAQ

Q. Why do some Oberon systems have a flat file system? Isn't a tree structured file system indispensable in highly productive contemporary environments?

A. The tree structured file system came into prominence during the 1950s and '60s when computer memories were miniscule in comparison to memories now available. The tree structure of those early file systems helped with organization of the operating system. Typical memory access is far faster than file access. With current hardware, a data structure can be composed and used in memory with much faster performance than a data structure in a file system. With some focus on choice of meaningful names for files, most users will find the flat file system entirely adequate. Also, most Oberon subsystems have access to a tree structured file system of the host. Additionally, ETH Oberon running on a bare PC supports the FAT16, FAT32 and ISO 9660:1988 file systems, all of which are tree structured. In reality, a flat file system in Oberon is a benefit rather than detriment.

Q. In ETH Oberon (or A2O) MM+MR opens a viewer with Edit whereas I prefer ET. How can that be fixed?

A. In ETH Oberon open TextFrames.Mod. MM on Edit.Open.

Edit.Open TextFrames.Mod

In the Oberon sub-system of A2.

Edit.Open Oberon.TextFrames.Mod

Change

OpenCmd = "Edit.Open"

to

OpenCmd = "ET.Open"

, MM on Edit.Store, recompile the module (TextFrames.Mod or Oberon.TextFrames.Mod) and reboot. TextFrames and all modules which import it could be reloaded but rebooting is simpler.

Glossary

Also refer to the glossary in the Wikipedia article.
Active Oberon, the dialect appearing in system A2.
BRAM, Block Addressable Random Access Memory, as used in the FPGA machine^[37].
Columbus, a software tool in ETH Oberon used to inspect and modify gadget attributes and to add a new attribute to a gadget. Usage described in the tutorial
Definition ( or Module Definition), a summary of a module presenting constant declarations, type declarations, variable declarations and procedure headings.
fixup, the conversion from address relative to the base address of the module, to absolute address.
Gadgets, software infrastructure in ETH Oberon providing graphical entities and a graphical user interface. Usage described in the tutorial.
Inner core, a significant architectural entity in an Oberon system. Refer to System Startup.
INTEGER, an integer type in every Oberon system.
Interclick, a click of a mouse button while holding another button. MM+MR below is an example. The mouse tutorial has additional details. When editing a Text at least six interclick combinations are meaningful.
Lola-2, a hardware description language developed by Niklaus Wirth.
Juice, an alternative to Java.
LinzOberon, an implementation of V4. Ref. mailing list, 2020-11-28.
LONGINT, an integer type in ETH Oberon. Synonymized to INTEGER in the current V5.
LUT, look up table of FPGA. Referenced when quantifying the size of a FPGA device.
ML, the left button of the mouse or a click of that button, depending on context. Ref. Mouse support. Abstract meaning: specify a location. Example: locate an insertion point in a Text.
MM, the middle button or the wheel of the mouse, or a click of the button or wheel, depending on context. Abstract meaning: invoke an action. Example: execute a command.
MR, the right button of the mouse or a click of that button, depending on context. Abstract meaning: select an extent. Example: select a character sequence in a Text.
MM+MR, a click of the right button while holding the middle button or the wheel of the mouse. MR here is termed an "interclick". In a Text, take the word under the mouse pointer as the name of a file and open the text editor on it.
MR+ML, a click of the right button while holding the left button of the mouse. When editing a Text, select characters and delete them.^[38]
ML+MM+MR, nullification of an inadvertent mouse click.
MT, in V5, the constant address of the module table.^[39]
native, modifies the name of an Oberon system to indicate that it is installed on bare hardware; distinguishing from a subsystem such as UnixA2 installed atop a host system.
Oberon.Text, a file in ETH Oberon and in A2O specifying system configuration.
OMI/Slim binary (Oberon Module Interchange), a mechanism created by Michael Franz and Thomas Kistler allowing efficient portability of any module between differing systems. The language from this work was named Juice. Compare with Apple Fat binary. Slim binaries are mentioned in compilers page in the section "Compiler deployment in ports no longer updated".
Outer core, a significant architectural entity in an Oberon system. Refer to System Startup.
.odc, the conventional file name extension for a BlackBox/Oberon-F file (short for Oberon DoCument) quite similar internally to Oberon Text format.
(** any comment *), appears in some module sources. It means that any comment is an exported comment. A tool named Def produces a module interface file with this comment included, thus enhancing internal documentation.
PICL, a programming language for the PIC microcontrollers.
(** portable *), this comment in ETH Oberon marked a module where OMI/Slim binary code was portable across platforms. More generally, it means there were no SYSTEM dependencies or machine specificities. This exported comment appears in the documentation created by the above mentioned browser, Def, which was integrated into a tool called Watson in ETH Oberon.
Registry, the content of Oberon.Text specifying file system aliases, sound adapter parameters, LinkSchemes, MIME types and etc.
SB, in V5, the static base address. The base address for variables in the current module.^[39]
SHORTINT, an integer type in ETH Oberon. Not in V5.
SIZE, a signed integer type pertaining to memory address in A2. The difference of two addresses can be negative. New numeric types appeared in rev.9475.^[40]
SP, in V5, the stack pointer address.^[39]
Symbol file, a linearized excerpt of the symbol table of the compiler. The file contains descriptions of all exported objects. Ref. section 12.6.2 of Project Oberon, 2013 Edition.
Watson, a tool capable of extracting a module definition from a definition file, module file, module Text or object file. Usage described in the tutorial.
WTS, Write To Script, refers to Write and Script variants of Text document and conversion of a Write Text to a Script Text. Write is in V4 and Script is in ETH Oberon.

Support

• Bug tracker, language documentation and etc. primarily for A2: http://cas.inf.ethz.ch/projects/a2/
• The Oberon mailing list: https://lists.inf.ethz.ch/mailman/listinfo/oberon
• The Oberon Community Platform, http://www.ocp.inf.ethz.ch/wiki/OCP/Home. Server at the ETH decommissioned early 2020.

Developing

A few potential projects.

• For any system, compile a fresh release, with bug fixes and improvements, and post on a public server.
• Make a TUI for A2.
• With the cryptography modules in ETH Oberon and in A2 as a base, build an SSL implementation for ETH Oberon.
• Improve support of Unicode.
• Using HTTPS, automate the download and upload processes. Allowing MediaWiki.Get Oberon.Sort.Mod ... ~ and MediaWiki.Put Oberon.Sort.Mod ... ~ for example.
• Improve HTMLDocs in ETH Oberon and in A2O. Add support for styling and tables, for example.

Licenses

References

Approximate chronological order. Also refer to the Oberon Bibliography from ETHZ.

• N. Wirth, J. Gutknecht, Project Oberon, 1992(PDF).
  
• P.J. Muller, The Active Object System - Design and Multiprocessor Implementation(PDF), PhD thesis, Institute of Computer Systems, ETH Zurich, 2002. Containing the original description of A2.
  
• N. Wirth, Project Oberon, 2013 Edition. Originally published with co-author J. Gutknecht, 1992.
  
• Reviving a Computer System of 25 Years Ago, 2014 lecture by Prof. N. Wirth
• P. Reed, Project Oberon, 2015-present.

Links

• ETH Oberon Site Map. Formerly hosted at ETHZ and primarily addressing ETH Oberon and preceding systems.
• Oberon System 3 - Main Tutorial.
• ETH Hall of Fame and subsequent contributors.
• Catalog of Oberon Resources.

Footnotes