The OS 9 Boot Process on the Color Computer and Dragon

The OS-9 Boot Process on the Color Computer and Dragon

Author: Alan DeKok

This note gives a concise walk-through of how OS-9 boots on the Tandy Color Computer, followed by a short Dragon 64 boot summary.

Color Computer Boot Sequence

Typing DOS at the DECB OK prompt starts the boot chain.

1. Track 34 is loaded from disk.
2. That track is placed at address $2600.
3. Execution begins at $2602.
4. $2602 contains a branch to the entry point of the REL module.
5. REL copies the boot track from $2600-$37FF to $ED00, then continues execution from the relocated copy.
6. REL jumps to OS9p1.
7. OS9p1 initializes system variables, the memory map, system call tables, and interrupt handling, then calls BOOT.
8. BOOT reads logical sector $000000 from the disk and determines where the OS9Boot file is located.
9. BOOT requests RAM large enough for OS9Boot and loads it directly into memory.
10. BOOT returns to OS9p1 after setting the low-memory pointers that describe the loaded bootfile.
11. OS9p1 links to OS9p2 and executes it.
12. OS9p2 installs additional system calls, links to the clock module, and calls it.
13. The clock module enables multitasking and returns to OS9p2.
14. OS9p2 then performs F$Chain to CC3Go, which prints the startup banner and runs the startup file through a shell.

Dragon 64 Boot Sequence

On a Dragon 64 running DragonDOS, typing BOOT starts a similar sequence with a different loader layout.

1. DragonDOS loads sectors 2-17 inclusive, a total of 4096 bytes.
2. Those sectors are placed at $2600.
3. The first two bytes of sector 2 must be ASCII OS.
4. Execution begins at $2602.
5. The boot code switches the machine into RAM mode.
6. It copies the loaded image to $F000.
7. Execution continues at $F04F.

Why This Matters

Understanding the boot process helps when you are:

• debugging boot tracks and bootfiles
• customizing startup behavior
• studying how OS9p1, OS9p2, and BOOT cooperate
• bringing up a new port or storage configuration

It also makes it much easier to reason about where a failure occurred during early startup.