This is a first concept for a new Geneve boot process, which is implemented in the boot EPROM.
Over the years, and in particular after some debugging and disassembling, I found that the existing solutions (0.98 and 1.00) offer some potential for improvement (politely saying).
Both boot EPROMs offer to boot from one of several fixed sources. Also, they include code for a low-level access to the storage media. Such code should be part of a driver, and the driver should not be hardcoded into the EPROM, because there is always the chance of having bugs in it, or you encounter a new device that will not be supported this way.
Also, booting is performed the same way, once your hardware setup has evolved to a stable state. If you need to press a certain key every time for loading from your favorite device, this is somewhat annoying. Unfortunately, the Geneve does not offer a non-volatile storage (EEPROM) to store user preferences.
For that reason, I considered to write a new boot process with the following properties:
- The EPROM shall not contain any low-level device access code. It contains a fixed list of popular boot devices, though.
- The boot process is composed of two stages.
- The first stage consists of loading a boot loader from one device of the built-in list, using the DSR from the device. After successfully loading the first stage, control is passed to the loaded code, and the boot EPROM is no longer needed from there on.
- The second stage consists of loading a controller-dependent part that loads low-level routines into the system, still using the card DSR (but may also use own code).
- The controller-independent (CI) loader must be placed on one device of the built-in list. However, it has full control from where to load the controller-dependent (CD) part. That way, a known device may bootstrap any future, still unknown device.
- Since the EPROM passes control to the first stage, the first and second stage may be combined to a single stage, containing all required low-level routines.
- In case of a broken boot process, there is an override to force loading from DSK1.
This leaves a lot of space in the EPROM, and I envisage to get a more informative boot screen with memory test output, device detection, and a progress bar for loading. All of these are comparatively simple tasks. Also, the Swan should be shown on the screen, as it is the well-known brand icon of our computer.
The typical situations that I have in mind:
- Floppy only. The disk in DSK1 contains two files: @BOOT1 and @SYSTEM. The boot loader must be selected according to the floppy controller. The first and second stage are contained in @BOOT1.
- MFM drive. The drive (WDS1) contains the above files. As long as no space bar is pressed, loading will start from WDS1, which is part of the built-in list.
- SCSI drive. See MFM drive.
- Floppy and EXOTIC device. The second drive is not part of the built-in list. The Floppy drive contains the file @BOOT1 only. The file is tailored to point to the EXOTIC drive, from where @BOOT2 and @SYSTEM are loaded. This way, the floppy will only be used for the first stage, and most of the code will come from the second drive.
- SCSI and EXOTIC device. Similar to above; @BOOT1 and @BOOT2 may be combined and put on the SCSI drive, since the SCSI drive is fast. @BOOT2 is tailored to attempt loading @SYSTEM from the EXOTIC drive.
- Since the floppy drive may always be forced to load @BOOT1, you can do anything you deem reasonable from here on, probably booting a rescue system that you put on DSK1.
I cannot promise this will become real in any shorter period of time, but maybe someone here feels like starting with it, or has another idea.