How does the Kickstart ROM load and start workbench?

Question

As I understand, on the Commodore Amigas, the kickstart copies itself into a region of memory which is later made read-only. Does kickstart also copy workbench into this region?

How does kickstart find workbench? It might be on a floppy; so is it stored in a particular location, like a MS-DOS boot floppy has a reserved region for booting? Or does kickstart load a particular file by its name? And what does kickstart do to the file once it's been loaded? Does it jump to a particular routine or something else?

Answer 1

The Amiga Kickstart ROM is made up of numerous modules, libraries, and device drivers. One of the modules is Strap, as in Bootstrap. After I/O and expansion devices have been enumerated and initialized (including any expansion ROM they contain, which provide more libraries or device drivers), Strap takes over bootstrapping.

Bootable disk devices have already been enumerated by Kickstart, and Strap's job is to boot a DOS from the highest priority bootable disk. If the trackdisk device driver detects a floppy in drive DF0, that is the default highest priority, so the Amiga will boot from floppy. Floppy boot starts by searching the first two sectors of the disk for a "Boot block". If it does not find a custom boot block, then it jumps into the Kickstart dos.library, and you boot into a shell. If it finds a boot block, then it loads it into newly allocated RAM and jumps to it. The boot block code can use the trackdisk.device to continue loading and booting custom code, which is what most games will do. It is noteworthy that the custom code can choose whether or not to use the filesystem driver from Kickstart, or just do I/O via the trackdisk.device and have data and code stored on the floppy based on its own bespoke track/sector layout.

If there is no custom boot block, then dos.library has its own method of initializing and using the filesystem to continue booting. It follows the AmigaDOS commands provided in S:Startup-Sequence, which is the equivalent of MS-DOS's Autoexec.bat. There is also a workbench.library in LIBS: that gets loaded at this point, thus providing the Amiga graphical shell, which is populated by icons, stored in ".info" files, which are found by scanning the filesystem.

If you do not insert a floppy, then Strap looks at its enumeration of bootable disk devices, selects the highest priority boot device, and starts it booting by jumping to ROM code provided by that device's autoboot controller ROM. From here, the process depends on the autoboot ROM, but it is similar to the floppy boot process. The main difference is that hard disks contain Rigid Disk Blocks, and those blocks can contain filesystem drivers. So a hard disk also does not have to use the filesystem driver in Kickstart. It can load a bespoke filesystem from its disk first, then continue the boot process using that filesystem. This is how advanced filesystems like SFS and PFS3 work. S:Startup-Sequence gets executed by dos.library and workbench.library gets loaded from LIBS:, as above.

If Strap found no floppy or bootable device, then it displays the familiar "Insert Workbench" disk screen, and continues scanning for a boot disk to be inserted by the user.

Answer 2

Your opening statement is only partly correct:

As I understand, on the Commodore Amigas, the kickstart copies itself into a region of memory which is later made read-only.

This is true for the Amiga 1000 computer. The A1000 contains a small boot ROM which contains code to self-test and then request a Kickstart disk. Kickstart is loaded from disk into a special area of RAM called the Write Controlled Store, WCS. Then the boot ROM flips the WCS into read-only mode and reboots - this time the boot ROM is disabled and invisible, Kickstart is present where it needs to be in read-only memory, and Kickstart boots the machine. I asked a question about the A1000 WCS here which you might like to read to find out more details.

For all other Amigas, there is no boot ROM or WCS, and no Kickstart disk. Instead Kickstart is in a physical ROM - at power on, Kickstart is already in the right place in the memory map and, obviously for a ROM chip, is read-only.

(I understand that some Amiga 3000 models may be a special case - they have something called Superkickstart which can load Kickstart from somewhere else, but I do not know much more than that.)

Does kickstart also copy workbench into this region?

No, not exactly, but portions of "Workbench" are actually part of Kickstart.

If we are referring the the Workbench disk, then no - files on the disk are loaded into RAM and are lost whenever the Amiga is rebooted. They are not treated specially, and are not put into write-protected memory.

If we are referring to the Workbench "application": some of the Workbench app is on disk, but most of it is in Kickstart - workbench.library contains the Workbench code. The LoadWB command merely locates workbench.library and tells it to start Workbench.

(In another special case, the Amiga 4000T ROMs, and the later 3.x ROMs from Cloanto, do not have workbench.library in ROM, requiring that to be on disk instead. This is due to space constraints - space on the 512KiB ROM is at a premium, but it was relatively easy to shift workbench.library onto disk and gain more space in the ROM. This is fine for hard drive based systems, but means that a lot of floppy disk apps suddenly become incompatible because they do not have workbench.library on disk.)

How does kickstart find workbench? It might be on a floppy; so is it stored in a particular location, like a MS-DOS boot floppy has a reserved region for booting?

Yes, this is correct - floppy disks have boot sectors. Kickstart loads the boot sector into RAM and executes it. On the Workbench disk - and many other disks - the boot sector contains a simple bit of code which simply calls back into Kickstart to say "yes, I'm a normal bootable disk, please boot me".

(Games and demos often had custom boot sectors which loaded the game/demo code directly; boot sector viruses had their own code to install themselves in memory and then called the "please boot me normally" Kickstart code so they behaved normally but hid their payload.)

Hard disks technically have boot blocks. I believe (but I am not certain) that these are actually unused, and when booting from hard disk Kickstart always goes straight to the "please boot me normally" routine instead of executing boot blocks.