This article needs additional citations for verification. (July 2009) (Learn how and when to remove this template message)
Most Amiga models were shipped with the Kickstart firmware stored on ROM chips. Its purpose is to initialize the Amiga hardware and core components of AmigaOS and then attempt to boot from a bootable volume, such as a floppy disk.
Commodore's AmigaOS was formed of both the Kickstart firmware and a software component provided on disk (with the software portion often termed as Workbench). For most AmigaOS updates the Kickstart version number was matched to the Workbench version number. Confusingly, Commodore also used internal revision numbers for Kickstart chips. For example, there were several Kickstart revisions designated as version 2.0.
|Kickstart version||V-number||Retailed with Amiga models||Launch date||ROM capacity||Autoconfig present in ROM||Early boot menu||Boot from PCMCIA and ATA||Autodetect memory|
|<0.4||<V24||Lorraine, first prototype||1983||64 KB||No||No||No||No|
|0.4||V23 V24||Amiga "Velvet"||1984||128 KB||No||No||No||No|
|0.6, 0.7, 0.9||V26 V27 V29||Amiga 1000 Beta||1985||256 KB||No||No||No||No|
|1.0||(none)||Amiga 1000||1985||256 KB||No||No||No||No|
|1.1||V31 (NTSC) / V32 (PAL)||Amiga 1000||1985–1986||256 KB||No||No||No||No|
|1.2||V33||Amiga 500, Amiga 1000, Amiga 2000||1987||256 KB||No Auto Boot from Hard Disk||No||No||No|
|1.3||V34||Amiga 500, Amiga 2000, Commodore CDTV, Amiga 3000||1988||256 KB||Yes||No||No||No|
|1.4||V35||Amiga 3000||1990||512 KB|
|2.0–2.05||V36-38||Amiga 500+, Amiga 600, Amiga 2000, Amiga 3000||1990||512 KB||Yes||Yes||2.05+||No|
|3.0||V39||Amiga 1200, Amiga 4000||1992||512 KB||Yes||Yes||Yes||No|
|3.1||V40||Amiga 1200, Amiga 4000T||1993||512 KB||Yes||Yes||Yes||Yes|
|Amiga CD32||1993||1 MB|
|3.1.4||V46||Amiga 500, Amiga 600, Amiga 2000, Amiga 1200||2018||512 KB|
|3.2||V43||Amiga Walker, last prototype||1996||1 MB|
The first Amiga model, the A1000, required that Kickstart 1.x be loaded from floppy disk into a 256 KB section of RAM called the writable control store (WCS). Some A1000 software titles (notably Dragon's Lair) provided an alternative code-base in order to use the extra 256 KB for data. Later Amiga models had Kickstart embedded in a ROM chip, thus improving boot times. Many Amiga 1000 computers were modified to take these chips.
Kickstart was stored in 256 KB ROM chips for releases prior to AmigaOS 2.0. Later releases used 512 KB ROM chips containing additional and improved functionality. The Amiga CD32 featured a 1 MB ROM (Kickstart 3.1) with additional firmware and an integrated file system for CD-ROM.
Early A3000 models were, like the A1000, also shipped with Kickstart on floppy disk, and used a 1.4 BETA ROM as bootstrap. Either Kickstart 1.3 or 2.0 could be extracted to a partition specifically named WB_1.3 or WB_2.x, respectively, and put in DEVS:kickstart, an absolute system location from where the A3000 system will find it at bootstrap and copy its image into RAM. This early A3000 supported both ROM based Kickstarts and disk-based Kickstarts, although not simultaneously. An A3000 configured to use disk-based Kickstart images had the benefit of being able to boot various versions of AmigaOS without additional tools, simply by selecting the appropriate Kickstart image at boot time.
The Commodore CDTV featured additional firmware ROMs which are not technically part of the Amiga Kickstart. The CDTV's original firmware ROMs must be upgraded in order to install a Kickstart version later than 1.3.
AmigaOS 2.1 was a pure software update and did not require matching Kickstart ROM chips. Workbench 2.1 ran on all Kickstart ROMs of the 2.0x family. Later releases of AmigaOS (3.5 and 3.9) were also software only and did not include matching ROM upgrades instead requiring Kickstart 3.1, with ROM-file based Kickstart components replacing those in ROM. Kickstart modules of AmigaOS 4 are stored on the boot disk partition.
Up to Kickstart v2.0 (V36) only 512-byte blocks were supported.Motorola 68040 uses write caches that requires the use of the functions CacheClearU() and CacheControl() to flush cache when program code has been modified. These functions are only available in Kickstart 2.0 or better.
Upon start-up or reset the Kickstart performs a number of diagnostic and system checks and then initializes the Amiga chipset and some core OS components. It will then check for connected boot devices and attempt to boot from the one with the highest boot priority. If no boot device is present a screen will be displayed asking the user to insert a boot disk – typically a floppy disk. Insertion of such a bootable disk (other than workbench-like disk) will result in:
a) a command line interface ("CLI") prompt to operate with ROM-internal and disks commands (including programs, scripts) (if the disk is non-workbench, or empty), or
b) a (basic) point and click UI named "Workbench" if the disk contains at least "loadwb" in the "startup-sequence" script residing inside the "s"-folder on this disk.
c) the disk booting into a customized workbench or an application, keeping the OS "alive" in the background.
d) a game or other application directly starting up, taking over all the hardware resources of this computer by avoiding to establish core Exec multitasking, driver initialization etc.
The Kickstart contains many of the core components of the Amiga's operating system, such as:
- Exec – the Amiga's multi-tasking kernel
- Intuition – functionality for GUI, screens, windowing and handling of input/output devices
- Autoconfig – functionality to automatically initialize or boot from compliant expansion hardware
- Floppy disk device driver and file system to read and boot from floppy disk
- DOS library for file access and handling
- AmigaDOS – Command Line Interface (CLI) functionality and a number of core CLI commands
- Graphics library for basic drawing and raster graphics functions using the native Amiga chipset
- Audio device driver for the native Amiga sound hardware
- Device drivers for the Amiga keyboard and mouse/gameports
The screen color after power-on shows the result of the self-test.
If everything is working the following screen color sequence will be displayed:
- Dark grey – Hardware working and the registers are readable.
- Light grey – ROM verified.
- White – Initialization is alright. Ready to boot.
These colors indicate a problem:
- Red – Bad Kickstart-ROM
- Green – No chip RAM found, or it is damaged
- Blue – Custom chip problem (Denise, Paula, Agnus)
- Yellow – Mostly a bad CPU (no trap routine) or a bad Zorro expansion card. CPU exception error before the "Guru Meditation" trapping software was enabled.
- Light green – CIA problem
- Light Grey – If it stops at grey, the CIA may be defective
- Black/stripes – ROM or CIA problem
- Black – No video output.
The keyboard LED uses blink codes where:
- One blink means the keyboard ROM has a checksum error
- Two blinks means RAM failure
- Three blinks means watchdog timer failure.
- When the Caps Lock key is repeatedly pressed approx. 10 times, the Caps Lock LED turning on and off each time indicates the CPU is correctly reading the CIAs. If the Caps Lock LED sticks on or off, the CPU is not servicing CIA interrupt requests.
In general, to run a specific Workbench version a Kickstart with a matching or greater version number is required.
It is not generally possible to boot directly into the Workbench windowing environment from Kickstart alone. Though much of the functionality required for Workbench is contained in Kickstart some disk-based components are needed to launch it.
From release 2.0 onwards it is possible to enter a boot menu by holding down both mouse buttons at power on or reset. This allows the user to choose a boot device, set parameters for backwards compatibility and examine Autoconfig hardware.
With third-party software, it is possible to use an alternate Kickstart to the version stored in the embedded ROM chip. Such software allows a Kickstart version to be loaded from file into RAM – for example Kickstart 1.3 may be loaded in order to run old software incompatible with Kickstart 2.0 or later. Several third-party vendors produced hardware Kickstart switchers (dual-boot systems) in the form of socket doublers in order to allow two ROM chips to plug into a single motherboard socket with some mechanism to switch between them. These became popular with users who had problems with later Kickstart versions causing incompatibility with earlier software titles.
An MMU-enabled Amiga is able to "shadow" Kickstart from the embedded ROM chip (or from file) into RAM and pass control to it at start-up. This is often preferable as RAM access times are significantly faster than ROM, particularly on expanded systems. At subsequent resets the copy of Kickstart is re-used, reducing boot time and allowing faster access and execution of Kickstart functionality. Similar shadowing functions were also developed for some devices without MMU hardware.
- "The Big Book of Amiga Hardware - Custom Chips: Kickstart".
- "Mysterious Ways - How to Code the Amiga - Important Kickstart Differences on Amiga". mways.co.uk. Archived from the original on 25 July 2014. Retrieved 2013-06-09.
- "Amiga Lorraine". amigahistory.co.uk. 2007-06-10. Retrieved 2013-06-09.
- "The History of the Amiga". amigahistory.co.uk. 2007-06-10. Retrieved 2013-06-09.
- "Amiga 1000 Developer 'VELVET'". Stefan Egger. 2015–16. Retrieved 2016-07-30.
- "Kickstart Roms Explained".
- "Kickstart Roms Explained".
- "32 / Expansion Board Drivers / RigidDiskBlock and Alternate Filesystems". amigadev.elowar.com. Retrieved 2013-06-09.
- "Mysterious Ways - How to Code the Amiga - General Guidelines". mways.co.uk. Retrieved 2013-06-13.
- "WORDSYNC" ADDENDUM to the SupraDrive Operator s Manual" (PDF). 090429 amiga.resource.cx
- amigahistory.co.uk - What your Amiga is telling you
- "blinking power led/no screen on amiga 500". abime.net. Archived from the original on 2012-04-03.
- "A3000 Booting Problems". amiga.serveftp.net. Retrieved 2011-11-03.