Table of Contents

NITROS-9 LEVEL2 BOOTING SCREEN AND WHAT IT MEANS

by Chris Hawks. 12 May 2006

Updated by L. Curtis Boyle June 23, 2019.

The 1st part (“WHAT THE BOOT SCREEN MEANS”) explains what all the characters on the boot screen means, in the order that they appear, to help you figure out where things are going wrong.

The 2nd part of this document (“THE BOOT PROCESS EXPLAINED”) is the technical explanation.

WHAT THE BOOT SCREEN MEANS

The first thing that should appear, after you type DOS, is that the screen will clear (whether it is 32, 40 or 80 column will depend on which version of REL you have used) and it will print NITROS9 BOOT in the center.

This indicates that the kernel track (usually track 34) has been loaded, and at least the REL module in that appears to be working.

After that, things print from the upper left corner of the screen:

in the OS9boot file.

If the screen clears and it prints a NitrOS-9 splash screen, then SysGo is running.

SysGo will also make a “dummy” call to the Set the Time, which is used to kickstart multi-tasking by initializing the Clock module and clock IRQ.

If it freezes here, you may have the wrong Clock/Clock2 module.

ERROR CODE LIST

(numbers that are blank or not listed should NOT appear on the NitrOS9 BOOT screen, as they are not legitimate errors at that point):

CHAR is the character that appears after the '*'

Char ASCII Error # NitrOS-9 Error message
7 55 183 Illegal window type
8 56 184 Window already defined
9 57 185 Font Not found
: 58 186 Stack Overflow
; 59 187 Illegal Argument
< 60 188
= 61 189 Illegal Coordinates
> 62 190 Internal Integrity check
? 63 191 Buffer size is too small
@ 64 192 Illegal Command
A 65 193 Screen or Window Table is Full
B 66 194 Bad/Undefined buffer number
C 67 195 Illegal window definition
D 68 196 Window undefined
E 69 197
F 70 198
G 71 199
H 72 200 Path Table Full
I 73 201 Illegal Path Number
J 74 202 Interrupt Polling Table Full
K 75 203 Illegal Mode
L 76 204 Device Table Full
M 77 205 Illegal Module Header
N 78 206 Module Directory Full
O 79 207 Memory Full
P 80 208 Illegal Service Request
Q 81 209 Module Busy
R 82 210 Boundary Error
S 83 211 End of File
T 84 212 Returning non-allocated memory
U 85 213 Non-existing Segment
V 86 214 No Permission
W 87 215 Bad Path Name
X 88 216 Path Name Not Found
Y 89 217 Segment List Full
Z 90 218 File Already Exists
[ 91 219 Illegal Block Address
\ 92 220 Phone Hangup-Data Carrier Detect lost
] 93 221 Module Not Found
94 222
_ 95 223 Suicide Attempt
` 96 224 Illegal Process Number
a 97 225
b 98 226 No Children
c 99 227 Illegal SWI Code
d 100 228 Process Aborted
e 101 229 Process Table Full
f 102 230 Illegal Parameter Area
g 103 231 Known module
h 104 232 Incorrect Module CRC
i 105 233 Signal Error
j 106 234 Non-existent Module
k 107 235 Bad Name
l 108 236 Bad Module Header
m 109 237 RAM Full
n 110 238 Unknown Process ID
o 111 239 No task number available
p 112 240 Unit Error
q 113 241 Sector Error
r 114 242 Write Protect
s 115 243 CRC Error
t 116 244 Read Error
u 117 245 Write Error
v 118 246 Not Ready
w 119 247 Seek Error
x 120 248 Media Full
y 121 249 Wrong Type
z 122 250 Device Busy
{ 123 251 Disk ID Change
pipe 124 252 Record is locked-out
} 125 253 Non-sharable file busy
~ 126 254 I/O Deadlock Error

THE BOOT PROCESS EXPLAINED

One of our local Coco-nuts was having a problem with NitrOS-9 on his Coco3.

It had recently stopped booting NitrOS-9 from HDB-DOS in his SuperIDE.

We got together at the monthly Glenside Color Computer Club meeting to see if we could resolve the problem.

He brought his system and I brought a sub-set of my system to the meeting.

We were the 'presentation' for that meeting.

I booted my system from HDB-DOS and my SuperIDE adapter with his compactflash card in a compactflash to IDE adapter as the slave drive.

After my systems booted, I looked at the root directory of his compactflash card.

It looked OK to me, but, he did have some odd files there.

I shut down my system and swapped the compactflash cards.

(His as master and mine as slave.

The boot process started and loaded track 34 and the OS9boot and then just stopped.

From the debugging clues posted to the screen during the boot process, I was able to determine the the boot process was unable to find the 'sysgo' module.

I re-booted with my compactflash as master and his as slave, and copied 'sysgo' from my root directory to his.

We swapped the compactflash cards once again and his compact flash was able to boot!

I was asked to write-up our adventure as a article for the GCCC newsletter (Coco 1 2 3).

I had not been able to find any information on debugging the boot process in NitrOS-9 (except from the source code) so here it is.

STEP 1

The modules 'rel', 'boot', and 'krn' are loaded into memory from track 34 by the 'dos' command.

'Rel' ensures that it is located in the correct part of memory, sets up some of the hardware, clears the screen, and installs the debugging 'print' routine.

It prints 'NITROS9 BOOT' in the center of the screen and jumps to the execution address of the module 'krn'.

STEP 2

The module 'krn' uses the debug 'print' routine to put a 'K' on the startup screen.

It validates the modules in memory ('rel', boot, and 'krn') which prints their names on the startup screen and makes a system call (F$Boot) which puts a 't' on the startup screen and links the module 'boot'.

It puts a 'b' on the startup screen and calls 'boot'.

'Boot' reads LSN0 to find OS9boot and puts a '0' on the startup screen.

'Boot' then loads OS9boot and puts a '.' on the startup screen for each sector read.

'$F$Boot' validates all modules in OS9boot which prints their names to the screen, and puts a second 'b' on the startup screen.

Next 'krn' links to the 'init' module and puts 'i' on the startup screen.

Following this it links to and executes 'krnp2' the second part of the kernel.

STEP 3

'Krnp2' puts a '2' on the startup screen, and puts an 'x' on the startup screen.

Then 'krnp2' tries to 'chd' to the system device named in 'init' (usually '/dd').

Next 'krnp2' puts a 'o' on the startup screen and tries to open the output console named in 'init' (usually '/term').

'Krnp2' checks for 'krnp3' and runs it if available.

Then 'krnp2' puts a 'C' on the startup screen and tries to run the startup module named in init usually 'sysgo'.

STEP 4

'Sysgo' opens the output console, prints the NitrOS-9 startup banner and sets the data and exec directories.

'Sysgo' will execute 'startup' and 'autoexec' if available (unless you hold the 'shift' key) and finally starts a 'shell' on the console.

If something goes wrong during the boot, the module will call the 'crash' routine which will put a '*' and single character on the startup screen.

The '*' indicates that an error occured and the character's ascii value plus 128 is the error number.

For instance '*X' would indicate a 'Path Name Not Found' error.

'X' is ascii 88, and 88 + 128 = 216, the error code for 'Path Name Not Found'.

This is the error we saw when sysgo was missing from the root directory of the disk.

So, the start up messages look something like this: 

Krel boot krn tb0...................................................
......... bkrnp2 dd d0 rbf rb1773 term w w1 w2 w3 w4 scf cowin clock 
clock2 init i2xoC

Of course, YMMV (Your Modules May Vary)

This should give you some insight into what goes on during a NitrOS-9 boot, and perhaps some debugging assistance when something goes wrong.

RTS

Return to NitrOS-9 Ease of Use :: Tandy Color Computer