This tutorial is for those who plan on hacking the operating system boot process, or would otherwise like to better understand how the the official 65c02 Basic machine boots up and functions at a lower level.
On the official 65c02 machine, there is a very small ROM program starting at $200 in memory, this page of memory is also read-only and cannot be overwritten. Technically, one can perform a soft reboot by doing a JMP $200 in their code. Be warned, that this ROM code doesn't do any resetting of CPU flags or registered, and no memory is cleared! So, you have cleared the interrupt flag on the CPU, interrupts will cease to work until the flag is set again. The decimal flag is also unaltered, which may give some very unpredictable results when math operations are performed. You have been warned. The ROM may be updated at some point in the future to set a proper CPU flag and register environment. Also, the stack isn't reset, which can also result to some very odd behavior. I am leaving the ROM code in this unsafe state, as it gives smart players a way to hack into machines which may be vulnerable to this bug.
Anyways, so all the ROM code does currently is load the first block(256 bytes) from the first block device and then executes the code. Simple, enough? It loads the code into $800, this is the system bootloader code, which is explained in the next section.
The bootloader should be the first 256 byte block on your block device, the official 65c02 machine comes with a working bootloader installed, and this section here will explain what it does. For players who do not possess Mission Designer status, and thus cannot create custom in-game machines, this is the first part of boot code which any player can modify to begin their journey of creating a custom operating system. This bootloader can for example load a second stage boot program which could technically present the player with a menu of installed operating systems. Currently this bootloader is very basic, and works much like an old school PC bootloader, where it loads the OS kernel. The bootloader is hardcoded to locate and load a file called KERNEL.SYS from the block device, and load it into $f000, then begins executing it from memory right after.
This isn't technically part of the machine boot process, as it is part of the operating system itself. I will explain what it does here for completion. The kernel will configure a jump table at $fe00, which are the externally exposed API calls which player created programs can call. These API calls include printing a null-terminated string to the terminal, grabbing linefeed-terminated input from the terminal, among other very common and helpful utility functions. The kernel then is responsible for loading the various device drivers in memory and initializing various memory pages required for the operating system to function at runtime. These drivers include a file system driver, which allows programs to easily read and write from/to the file system, and a network driver, allowing programs to listen on ports, and create new connections to other in-game machines. The kernel should also update the interrupt service request vector located at $fffe-$ffff to handle external interrupt requests, either the user pressing Ctrl-C on their keyboard, or other hardware interrupts requiring the kernels attention. Once the operating system is set-up, the kernel will then load in memory and begin execution of the system shell program.
While this section is definitely not targeted towards the novice player, it is very meaningful to know and understand, as it can allow you to either make small patches to your existing operating system, or if you are advanced enough, to write your own in-game operating system.
At a later date, it will be possible for players to publish their custom operating systems in the form of an installation disk for other players to use and explore.