Introduction
Pondering the question, which of the modules of the Outer Core of Embedded Oberon are actually required to have a functioning operating system core, I put my eyes on System.mod.
Trap and Abort Handlers
The trap and abort handlers in System.mod are required elements. However, they do not actually to be in System.mod, where they simply are installed at their invocation addresses. There is no dependency on any variable or procedure in that module. Both handlers call Oberon.Reset.
Consequently, they can be moved to Oberon.mod, from where System.mod is loaded upon startup.
Oberon.mod
The body of Oberon.mod then reads:
MODULE Oberon;
BEGIN
(* ... *)
Modules.Load("System", Mod); Mod := NIL;
Kernel.Install(SYSTEM.ADR(trap), 20H);
Kernel.Install(SYSTEM.ADR(abort), 0);
(* ... *)
END Oberon.Another Step
Once we’re there, however, we can go one step further: don’t even load System.mod upon startup, it’s not required for a functioning system at this point. Only when executing system commands, it will be loaded as any other module.
Note that Embedded Oberon loads and intitialises RTC.mod from the body of System.mod. Hence, if we need this real-time clock module, we either load System.mod from the body of Oberon.mod, or we load RTC.mod from Oberon.mod as well. It is not clear to me why RTC.mod is loaded from System.mod, as it does not have any dependency on anything defined and declared therein. Hence RTC.mod could be loaded elsewhere in the startup procedure.
Texts.mod
Texts.mod is not required for the basic functionality of the operating system. System.mod uses it for output from commands, and Oberon.mod uses it for greeting and error messages. Consider an unsupervised control system, which might not even have an input-output console, in which case text output and command input would not be possible in the first place.
Oberon.mod would then have to output error messages to a log medium, or to a remote alarm system. This requires a corresponding logging concept and design. For example, error messages could be logged in a non-volatile log buffer in the FPGA, or a file.
Then an operator comes along to the unsupervised system, plugs in a terminal, and could read the logs, with the help of a corresponding module on the SD card. Only then Texts.mod needs to be loaded. The same is true for System.mod, as it basically provides commands for system inspection and management.
Bottom line for now: a logging concept is needed.