9

Amiga OS resident modules (libraries, devices, etc...) are location-agnostic, in that it is technically possible to compile them as location-independent code to be loaded at runtime from disk, or to compile them with fixed addresses to be stored in ROM, and Exec will automatically fetch and activate them in both cases. For example, for libraries, probably the most known example of this characteristic is the workbench.library in the A4000T version of the 3.1 Kickstart ROM, that was moved to disk due to space constraints.

Additionally, filesystems can too be stored on disk in the Rigid Disk Block structure on hard drives, and the system will load and link them at boot.

Now, suppose one wants to assemble a custom Kickstart for Amiga that can boot right into a regular Workbench, while keeping the modules in ROM to the bare minimum needed.

  1. What is the minimum set of modules that are strictly necessary for the Amiga to boot into Workbench and can't be placed on disk, under the assumption that you do not want to modify the modules?

  2. What would be the minimum set if one was to eventually provide a bare-bones implementation of a graphic toolkit to assist the system during the boot (mainly for diagnostics), that is until the system passes the critical state that allows it to load the full UI subsystem from disk?


Addition: as correctly pointed out, A1000 and early A3000 can load a Kickstart from disk, however the question here is a bit different: which libraries, devices are absolutely needed in the Kickstart for the machine to bootstrap the system. Especially after Kickstart 2.0, when the Kickstart got in it many modules that arguably are not "core" and could have lived on disk (think about Gadtools....).

  • What are you trying to achieve? If you want the whole intuition interface to be available, why not just let Workbench do its thing? If you only care about auto-running some specific program, what don't you need? – RichF Feb 12 at 16:19
  • I think the answer to "what could have lived on disk" is still "the whole thing", even after your edit. Not only were there Amiga models loading kickstart from disk by default, there were also tools like "softkick". To read from a block device, not very much is needed ... – Felix Palmen Feb 12 at 16:27
  • The link contained in Brian H's answer to another question may provide some clues: retrocomputing.stackexchange.com/a/6138 – traal Feb 14 at 19:53
4

Original Amiga 1000 was loading the kickstart from the floppy disk. There were even games that doesn't require Kickstart. From there I understand, there is no need for kickstart modules to start the system except a boot rom smiliar to the A1000.

  • 1
    Not sure if it's helpful, but (also) early versions of the A3000 shipped with the kickstart on the hard disk as a binary image that was loaded when the system was cold boot. You could boot to 1.3, 2.1, 3.1... it was just a matter of having the right kickstart image. – Geo... Feb 12 at 14:29
  • Yes, technically correct, but the boot rom could only load from a floppy disk and it basically load a full Kickstart in memory. My question is a bit different: of all the modules the Kickstart contains, which one is really needed? – user180940 Feb 12 at 14:59
4

Because the Amiga is so flexible in its use of system software, what you hope to accomplish here becomes really pertinent.

Obviously, doing anything useful is going to require the creation of a Task (or Process) to provide some form of user & hardware interaction. A Task can be managed using exec.library, and a Process brings in the possibility of high-level I/O, so uses dos.library.

You mentioned booting into Workbench. In a nutshell, starting the Workbench Process means loading workbench.libary, which depends on intuition.library (for windowing, menus, mouse, etc.) and on dos.library (for Process and File/Disk I/O). Then, those libraries naturally have their own dependencies, such as intuition.library using graphics.library. So it quickly becomes a matter of which system software services your Task or Process needs. Then, from the "dependency graph", you can tell what you need to load.

Looking at the DiagROM project as an example custom "Kickstart ROM" that boots the machine, it seems to use Exec, Dos, and Graphics. This leaves plenty of space in the standard-size ROM for the DiagROM app to do its thing. If it relied on Workbench, then more of the system software would be needed, and so there might not be space for the app itself.

Many Amiga games get by on only Exec and the trackdisk.device. That's because they can use the device to load a custom boot block from the floppy disk, then their boot code can take over and control the hardware, bypassing all of the system software, if desired. So that's a very minimal set of dependencies.

If you really want to boot into Workbench, then that's likely to require everything you would find in the stock Kickstart 2.0+ ROM's. Why? Because those ROMs are actually designed to provide everything needed by a "minimal" boot floppy that drops you into Workbench and allows you to run whatever App is on the floppy. This preserves the most space possible for user applications and data on an 880K floppy, with the system software only needing space for disk-loaded Dos commands (C: path) and startup scripts (S: path).

If you don't need Workbench to run your Task (or Process), then you can strip out those things that Workbench requires, but that your application can do without. Even if you want to access all the hardware, you can do that with your own "internal" drivers, rather than pulling in whichever Library, Device, or Resource is used to access that hardware in Workbench - just as a game might not use graphics.library or gameport.device, though it obviously uses the associated hardware.

In determining which system software services you actually need, the best thing to do is to prototype your app. If your Task or Process doesn't need to directly call a Library then you shouldn't need it as a dependency in ROM. If you do call a Library, then you need it and all of its dependencies.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.