part of NitrOS-9 to be loaded and executed. BOOTFILE is stored with the name ''OS9Boot'' in

the filesystem of the boot disk just like any other file. However, the LSN (the Logical Sector Number)

at which the ~~BOOTFILEFILE~~ starts on the disk is coded into the LSN0, which is a data structure stored at the first block on the disk.

at which the BOOTFILE starts on the disk is coded into the LSN0, which is a data structure stored at the first block on the disk.

Coding the start address into the LSN0 makes the process of reading BOOTFILE from disk into memory simpler -- the driver that performs

* (At least on some systems) BOOTFILE must use contiguous blocks on the disk -- it must not be fragmented.

* In order to use a modified BOOTFILE on a disk, the LSN0 must be re-written. If you forget to re-write the LSN0 data you can end up in the confusing situation where the actual BOOTFILE being used is not the one that you expect. Keep in mind that BOOT (the driver module which loads the BOOTFILE) finds the file through the LSN0 pointer and does not care about which name it has in the file system.

When creating disk images on a non-NitrOS-9 host system, the Toolshed os9 tool's "gen" command is used to set up LSN0 as part of the build

* The -t argument specifies the KERNELFILE; the file to be written to track 34 (the "boot track")

* The -b argument specifies the BOOTFILE; the file whose start LSN must be written into LSN0.

Track 34 consists of 18 sectors of 256 bytes each; a total of 4,608 ($1200) bytes. The first 2 bytes of KERNELFILE are 'O' and 'S'; executable code starts at offset 2 (the 3rd byte) and is a BRA to the entry point of the REL module.

See: [[More about the NitrOS-9 Kernel file]], [[More about the NitrOS-9 Boot file]].

<li>REL copies the boot track ($2600 to $3800) to address $ED00, and jumps to another routine inside of REL at the new address</li>

<li>REL then jumps to KRN (OS9P1), which sets up system variables, the system memory map, system call tables, IRQ and SWI setup, and calls BOOT.</li>

<li>REL then jumps to module KRN (OS9P1), which sets up system variables, the system memory map, system call tables, IRQ and SWI setup, and calls module BOOT.</li>

<li>BOOT reads sector $000000 off of a disk, and finds out where the OS9Boot file is.</li>

<li>BOOT requests system memory for the size of OS9Boot, seeks to where OS9Boot is, and loads it directly into RAM.</li>

<li>It then returns to KRN (OS9P1), after setting up pointers in low memory to the OS9Boot file.</li>

<li>BOOT then returns to KRN (OS9P1), after setting up pointers in low memory to the OS9Boot file.</li>

<li>KRN (OS9P1) links to KRNP2 (OS9P2), and jumps into its execution entry point.</li>

<li>KRN (OS9P1) links to module KRNP2 (OS9P2), and jumps into its execution entry point.</li>

<li>KRNP2 (OS9P2) sets up more system calls, links to the CLOCK module, and calls it.</li>

<li>CLOCK sets up some more system calls, starts multitasking, and returns to KRNP2.</li>

<li>KRNP2 then does F$Chain of SYSGO (CC3GO). This prints a start up banner, and runs your 'startup' file through a shell.</li>

<li>KRNP2 attempts to locate and link a module named KRNP3 See: [[More about KRNP3]].</li>

<li>KRNP3 need not exist. If it does exist, it should initialise then return control to KRNP2.</li>

<li>KRNP2 inspects the Init module to find the name of the default program -- usually SYSGO.</li>

<li>KRNP2 does a F$Chain of SYSGO (CC3GO). This prints a start up banner, and runs your 'startup' file through a shell.</li>

When a NitrOS-9 Level 2 system boots, code at D.BtBug can be configured to provide debug information. Code in rel.asm loads D.BtBug either with a RTS ($39) or with a JMP ($7E) -- the jump destination is code fragment BtDebug. By default, it is set to JMP, and provides progress messages through the boot. Here is an example, with decoder.