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.After IO 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.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. Amiga Workbench 1.3 Rom Code Can UseThe 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 IO via the trackdisk.device and have data and code stored on the floppy based on its own bespoke tracksector layout. It follows the AmigaDOS commands provided in S:Startup-Sequence, which is the equivalent of MS-DOSs 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. 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. S:Startup-Sequence gets executed by dos.library and workbench.library gets loaded from LIBS:, as above. At that point, project and tool icons can be used to launch additional tasks that can receive arguments in the Workbench-friendly way. 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. 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. They are not treated specially, and are not put into write-protected memory. The LoadWB command merely locates workbench.library and tells it to start Workbench. 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.). 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, Im a normal bootable disk, please boot me.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |