I've been toying with the idea of making a totally new boot strategy.
This new strategy would have a modular type system whereby the boot process would be visual. This bootstrap process wouldn't necessarily be tied to OS-9, but would focus on giving more diagnostics during boot time and boot into other environments possibly.
Currently the way to bootstrap a CoCo is to type DOS (Dragon users type BOOT). The command reads 18 256-byte-sectors of data from track 34 into memory which is 4608 bytes. (my memory on what the Dragon has isn't clear, so someone will have to help.) Currently the REL, BOOT and KRN modules reside there for Level 2, and the REL, BOOT, KRN, KRNP2 and INIT modules for Level 1.
What I am proposing to do is a radical departure from the current system. I propose that we create a boot environment that mimics what Microware has done for its current OS-9 systems.
A "system environment" will reside on the boot track that has a system dependent but hardware independent layer called the "boot manager". The boot manager will consult a "boot table" to determine the order that the booting will take place from one device to the next. The boot table will contain a list of "booters" that will talk to hardware to obtain a boot file.
Imagine that you have 2-floppy drive system and a SCSI hard drive. The boot table would have three entires:
The boot manager would consult the table and try each booter in the above order. If a bootfile was successfully obtained by that booter, then the system would boot. If not, then the boot manager would go to the next booter, and so on until it reached the end.
The boot manager would also communicate through "i/o handlers". Here's a list of I/O handlers I envision:
ioh_coco3 (handles I/O to a CoCo 3's 40 or 80 column screen)
ioh_coco (handles I/O to a CoCo's VDG screen)
ioh_6551 (handles I/O to a 6551 serial port)
The idea is that the I/O handler allows for displaying info and also getting input from the user. The boot manager would be configured to use one I/O handler.
The boot manager itself would be system dependent:
In other words, the boot manager chosen would set up the memory and environment for that particular OS so that when the bootfile is obtained, it is ready to run in that system.
I would appreciate comments in regard to these new ideas.
You seem to have CSS turned off.
Please don't fill out this field.
That's an interesting idea but I'd like a slightly different strategy. I'd like to be able to tell the boot manager on the fly what to look at first rather than have a fixed order. To some extent I can do that now with my RGBDOS system with an AUTOEXEC.BAS program with has several entries for boot drives. AUTOEXEC.BAS runs LINK.BAS in silent mode hard coded for a specific boot drive# corresponding to my selection. I am able to boot into either an original NitrOS-9 or the current SourceForge NitrOS-9 from the same hard drive.
One other point, if the new boot manager is to be automated and will test for a legitimate boot disk, we will need a better way of identifying an OS-9 disk. The current LNS0 does not have sufficiently unique info to prove the disk is OS-9. This causes problems with some emulators that use .dsk for any disk if you save a program and it goes to gran0. The emulator guesses wrong as to whether the disk is Basic or OS-9 and can't read it.
I don't see why we cannot have it both ways (select or autoboot). This could be a configuration in the boot manager. In fact, I would rename boot_table to boot_config since it could hold a number of parameters (autoboot vs ask the user, for instance).
bootman_nos9l1 and bootman_nos9l2 could be as lax or as stringent as we want to code when querying a device and verifying that it is indeed valid for booting.
I have some additional thoughts regarding this new boot strategy.
First and foremost, I believe it has follow a modular framework. I don't think we have to go so far as to actually have an OS-9 module header and CRC (like Microware has implemented their low level boot software), but the source needs to be easy to modify. Here's what I envision:
This new boot manager would be written in 6809 assembly using the rma/rlink utilities and NOT mamou. Using rma/rlink would give us the ability to break the code into assembler modules (NOT OS-9 modules) for easy management of the source and building of the objects.
Roughly it would be organized this way:
Boot Supervisor (only one): boot_supervisor (platform and device independent module)
Boot Managers (choose one): boot_manager_nos9l1.asm, boot_manager_nos9l2.asm (manages the boot process for the correct OS)
Boot Drivers (choose as many as you like): boot_1773, boot_ide, boot_scsi, etc....
Boot Config (only one): boot_config (basically static data that defines boot parameters, order of booters, etc.)
Boot I/O Handlers (only one): ioh_coco3, ioh_coco2, ioh_dragon, ioh_tano, ioh_6551, ioh_sio (these handle input/output for the boot process)
So the idea would be to write the code in this manner. Rlink would create one large binary which would then reside on the boot track.
You had me at "a boot environment that mimics what Microware has done". Assuming the old boot track could still be used, or the new system with just one booter still fitting on the boot track, it wouldn't impact those who didn't care.
Users without HDB-DOS or replacement ROM still type "DOS" and have to go to extra steps to customize a boot with their hard drive booter. It would be cool if many common ones could fit, taking away one more bit of pain for less tech savvy users.
But, you have to really want to do that. A $40 CoCoSDC, or DriveWire, makes a rather common hard drive platform that is within the reach of most. I don't expect I will ever boot off of anything beyond my CoCoSDC or DW.
Not sure I understand that Allen. How would someone without HDB-DOS boot to the CoCoSDC or Drivewire?
Unless the CoCoSDC replaces the disk ROM as part of the pack, a Coco user must enter something to boot OS-9.
Sign up for the SourceForge newsletter: