system-startup Reference

Narrative reference for the system-startup module, synthesised from the AmigaOS NDK 3.2 Release 4 (Autodocs/system-startup).

Unlike other entries in the library reference, this module is documented in the NDK as a narrative process description, not as a function catalog. It describes the role of the system-startup process — the first userland task that runs after dos.library finishes initialising itself — and the ROM-Updates mechanism it controls.

Background

system-startup is to AmigaDOS what init is to Unix. It is the initial process that takes control as soon as all essential system libraries are initialised. As part of its job, it also updates system components from disk if newer replacements are available there — see ROM-Updates.

The system-startup module was factored out from dos.library and is now a process and a module of its own. The functions it performs were previously executed by the boot shell through CliInit(), a private and now obsolete LVO of dos.library.

Startup mechanism

The system-startup process proceeds as follows:

  1. system-startup completes building dos.library.
  2. system-startup initialises intuition provisionally.
  3. system-startup mounts all volumes collected and recorded in ExpansionBase, left there by auto-bootable controllers.
  4. If a newer file system has been loaded from the RDB, this file system is placed in the FileSystem.resource, then added as filesystem to the resident list.
  5. system-startup continues to mount some important RAM-based handlers, namely PRT:, PAR:, SER: and PIPE:.
  6. system-startup starts the file system of the boot volume.
  7. System assigns are made, namely L:, FONTS:, DEVS:, LIBS:, S:, C:, SYS: and ENVARC:. The latter is a "late assign".
  8. All remaining file systems are started.
  9. system-startup mounts RAW: and CON:, and adds the con-handler to the resident list.
  10. Unless disabled by the boot menu, system-startup looks for ROM-Updates on file systems (see ROM-Updates).
  11. As part of this update process, any provisional version of intuition is shut down and replaced by the final version.
  12. If the boot monitor is AGA-based, graphics and intuition are "enlightened" — i.e. AGA modes are enabled. This does not happen by default for backwards compatibility.
  13. All RTF_AFTERDOS rom-modules are initialised.
  14. system-startup reads DEVS:System-Configuration, the legacy intuition preferences.
  15. system-startup opens the boot console, and the Startup-Sequence.
  16. Unless flagged as silent in Expansion, the boot console is forced open.
  17. If flagged by Expansion, the SysLog module is loaded and initialised.
  18. If flagged by Expansion, the debug and interactive shell variables are set.
  19. The boot shell is initialised through System().
  20. system-startup dies down as the shell takes over.

ROM-Updates

The ROM-Updates mechanism is part of system-startup and is able to replace some system-modules by corresponding RAM versions if available on disk. ROM-Updates can be disabled from the Boot-Menu through a flag in ExpansionBase. Note that ROM-Updates does not enforce a reboot.

A RAM-module replaces a ROM-Module if the version of the RAM module is strictly larger than that of the ROM module — i.e. a V48 module can replace a V47 module. The only exception is intuition, which can always be downgraded to V40.

Search path

The search path for ROM-Updates is as follows:

  • The boot volume. If a replacement module is found there, it is used. If, however, the boot volume contains a non-loadable (probably empty) dummy file of the name of a ROM component, scanning is aborted and the ROM module is not updated.
  • Any other mounted volume, in the order they appear in the DosList. The only exception is intuition.library in version 40, which is only scanned for on the boot volume.
  • The file system is upgraded automatically from the RDB if a new version exists there. It is not upgraded from file.

Upgradable modules

At the time of writing, the following ROM modules are upgradable from disk:

Module Source
filesystem (aka FFS) from the RDB if a newer version is available
con-handler from L:
ram-handler from L:
shell, BootShell, CLI from L:Shell-Seg
intuition from LIBS:, with the option for downgrading to V40
console.device from DEVS:
gadtools.library from LIBS:
syslog from L:
mathffp.library from LIBS:
mathieeesingbas.library from LIBS:
audio.device from DEVS:
workbench.library / icon.library already RAM-based but use the same search path

See also: dos.library — CliInit() (obsolete); exec.library — ExpansionBase, resident list, ROM modules.