Hubbry Logo
Kickstart (Amiga)Kickstart (Amiga)Main
Open search
Kickstart (Amiga)
Community hub
Kickstart (Amiga)
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Kickstart (Amiga)
Kickstart (Amiga)
Kickstart (Amiga)
View on Wikipedia
from Wikipedia
Kickstart 3.0 ROM chips installed in an Amiga 1200
Kickstart 1.2 floppy disk

Kickstart is the bootstrap firmware of the Amiga computers developed by Commodore International. 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. Most Amiga models were shipped with the Kickstart firmware stored on ROM chips.

Versions

[edit]
The default boot screen displayed under Kickstart 1.3

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.[1]

Version summary

[edit]
Kickstart version V-number Retailed with Amiga models Launch date ROM capacity Autoconfig present in ROM[2] Early boot menu Boot from PCMCIA and ATA Autodetect memory
<0.4[3] <V24[4] Lorraine, first prototype[5]    1983[6] 64 KB[5] No No No No
0.4[7] V23 V24[4] Amiga "Velvet"[7]    1984[7] 128 KB[7] No No No No
0.6, 0.7, 0.9[8] V26 V27 V29[2] Amiga 1000 Beta 1985 256 KB No No No No
1.0[9][10] v30[10] Amiga 1000 1985 256 KB No No No No
1.1[10][11] V31 (NTSC)[10]
V32 (PAL)[10][4] 		Amiga 1000 1985–1986 256 KB No Auto Boot from Hard Disk No No No
1.2[10][12] V33[4][10] Amiga 500, Amiga 1000, Amiga 2000 1987 256 KB No Auto Boot from Hard Disk No No No
1.3[10][13][14][15][16][17][18] V34[4][10] Amiga 500, Amiga 2000, Commodore CDTV, Amiga 3000 1988 256 KB Yes No No No
1.4[19] V35[4] Amiga 3000 1990 512 KB
2.0–2.05[20][21][22][23] V36-38[4] Amiga 500+, Amiga 600, Amiga 2000, Amiga 3000, Commodore CDTV-CR 1990 512 KB Yes Yes 2.05+ No
3.0[24] V39[4] Amiga 1200, Amiga 4000 1992 512 KB Yes Yes Yes No
3.1[25] V40[4] Amiga 1200, Amiga 4000T 1993 512 KB Yes Yes Yes Yes
Amiga CD32 1993 1 MB
old 3.2 beta (1996)[26] V43 Amiga Walker, last prototype 1996 1 MB
3.1.4[27] V46 update only 2018 512 KB
3.2 (2020)[28] V47 update only 2020 512 KB

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.[29] 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.[30]

Function

[edit]
The default boot screen displayed under Kickstart 2.0, requesting that the user insert a boot disk

Upon startup 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

Kickstart 1.3 is the first version to support booting from a hard disk drive.[31]

From AmigaOS release 2.0 onwards Kickstart also contained device drivers to boot from devices on IDE controllers, support for PC Card ports and various other hardware built into Amiga models.

Diagnostic test

[edit]

At power-on self-test will run from the ROM, this is a short program that can produce a color on the screen corresponding with a fault.

If everything works correctly, the following screen color sequence will be displayed on older Kickstarts:

  • Dark grey – Hardware working and the registers are readable.[32]
  • Light grey – ROM verified.[32]
  • White – Initialization has succeeded and the Amiga is ready to boot.[32]


The following colors indicate a problem:

  • Red – Bad result on Kickstart-ROM test (Checksum error). A small fault in ROM data will cause a checksum error.[33]
  • Green – Bad result on lower part of chip RAM (256 KB). However, this does not always mean the RAM is at fault.[33]
  • Blue – Custom chip problem (Denise, Paula, Agnus) (used by Kickstart 3.0 and higher)[33]
  • Cyan – Rev 0.x Kickstarts - Kickstart error. [34]
  • Yellow – CPU exception occurred, this is a CPU error detection by the processor itself and can be an illegal instruction executed or address bus error – Cause can be a bad CPU or a bad Zorro expansion card.[33] CPU exception happened before the "Guru Meditation" trapping software took over the trapping of exceptions.[32]
  • Purple – Bad Paula on older Kickstart Amigas. [33]
  • Light green – CIA problem, not a color produced by the self-test.[35]
  • Light Grey – If it stops at grey the CIA may be defective.[35]
  • White - If it stops at white, the RAM chips that were used may not work well on an A500 mainboard in combination with other RAM chips.
  • Black/stripes/glitching – random code (ROMs swapped/ROM garbage) or CIA problem.[35]
  • Black – No video output or CPU not running for some reason.[35]

However, if an Amiga gives a color code, it does not always mean that the error comes from a hardware fault: red can also happen if a ROM is mapped to fastmem or by ROM-patches from software. For yellow it can be unstable software in memory. Some Amigas may briefly show a color on screen at power-on which is the previous background color. Bad activity on the data bus may have an effect on other chips on the bus.

The keyboard LED uses blink codes that come from the keyboard controller chip where:

  • One blink means the keyboard ROM has a checksum error.[35]
  • Two blinks means keyboard RAM failure.[35]
  • Three blinks means watchdog timer failure.[35]
  • When the Caps Lock key is repeatedly pressed approx. 10 times, and the Caps Lock LED is not turning on and off each time it is pressed, the CPU is not reading out key presses and mostly indicate a CPU crash. The CIA-A serial register is used and a CIA interrupt can be used to pickup key presses from the keyboard buffer. If the Caps Lock LED sticks on or off, the CPU is probably not servicing CIA interrupt requests.[35]

Usage

[edit]

In general, to run a specific Workbench version, it is generally required to run a Kickstart with a corresponding or greater version number.

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, as 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 startup. 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 reused, reducing boot time and allowing faster access and execution of Kickstart functionality. Similar shadowing functions were also developed for some devices without MMU hardware.

Compatibility issues with later versions of Kickstart

[edit]

Most of the Amiga games library were written to run on Amiga 500's with Kickstart 1.2 or 1.3. Some games are incompatible with later versions of Kickstart, meaning they do not work properly or at all. Commodore claimed 50 and 60% of games were compatible while magazines of the time claimed 40 and 85% of such. To remedy this, a utility was released and included in the coverdisk of the March 1993 issue of CU Amiga called Relokick, which emulates a Kickstart 1.3 based Amiga. The article in the magazine states that "the utility does take up a bit of memory, so beware that some WB1.3 1Mb only software may still cause problems.".[36]

References

[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Kickstart (Amiga)

View on Grokipedia
from Grokipedia
Kickstart is the bootstrap firmware for computers developed by , serving as the foundational operating system kernel stored in (ROM) on the of most models. It initializes the Amiga's custom hardware, including chips like Denise for graphics, Paula for audio, and Agnus for , while loading core software components to enable multitasking, operations, and the . Upon power-up or reset, Kickstart executes from memory addresses typically ranging from F80000toF80000 to FFFFFF (for 256 KB in early versions) or F00000toF00000 to FFFFFF (for 512 KB in later ones), beginning with a jump instruction to bootstrap the system and prepare it for loading additional software like the . Originally introduced with the in 1985 as a bootable containing essential operating system code, Kickstart evolved into an integrated ROM chip for subsequent models like the and 2000 to streamline startup and reduce reliance on external media. The firmware's name persisted across versions, reflecting its role in "kicking" the system into operation, and it forms the basis of by providing low-level services before higher-level components are loaded from disk. Key versions include 1.0 (1985, version 30, obsolete), 1.1 (1985, versions 31-32, obsolete), 1.2 (1986, version 33), 1.3 (1988, version 34, introducing autoboot capabilities), (1990, with enhanced chip set support), and up to 3.1 (1994), each adding features like improved and hardware compatibility while maintaining where possible. At its core, Kickstart comprises the Exec library for task scheduling and memory allocation, the Intuition library for the graphical interface, and various device drivers such as graphics.library, audio.device, trackdisk.device (for floppy drives), printer.device, serial.device, and timer.device, all linked through ROM tags in the ExecBase structure to ensure system integrity via checksums. It supports asynchronous and synchronous I/O requests, AUTOCONFIG for dynamic detection on II and III buses, and to allow applications to interact with custom chips at addresses like $DFF000 without direct access. This modular design enabled the Amiga's renowned multitasking and multimedia capabilities, making Kickstart a pivotal element in the platform's legacy for gaming, , and professional applications during the 1980s and 1990s.

Overview

Definition and Purpose

Kickstart is the proprietary ROM-based developed by for computers, serving as the foundational bootstrap component of . It consists of the Kickstart ROM image, which encompasses the ROM kernel—a collection of essential libraries, devices, and resources such as exec.library for , graphics.library for display handling, and intuition.library for support. This provides the core system code necessary to initialize the Amiga's custom hardware, including the processor, Denise video chip, and Paula audio chip, before transitioning control to the full operating system. The primary purpose of Kickstart is to establish a minimal bootstrap environment that detects and configures attached hardware, loads the operating system from disk, floppy, or other media, and manages basic operations until the full takes over. During power-on or reset, it executes from a dedicated ROM address (typically starting at $F80000), performing hardware diagnostics, allocating regions like chip RAM, and invoking boot structures such as BootNode to locate and execute the startup . This process ensures a seamless transition to multitasking capabilities without requiring external loaders for core initialization. First introduced with the in , Kickstart marked a significant advancement for personal computing by embedding substantial operating system elements directly into ROM, enabling faster and more reliable compared to systems reliant on extensive disk-based initialization. This ROM integration allowed Amiga computers to achieve near-instant hardware readiness, a feature that set them apart from many contemporaries in the that depended more heavily on slower media loading for basic system startup. The name "Kickstart" evokes the idea of starting the system into operation, highlighting the firmware's role in rapidly activating the Amiga's advanced multimedia hardware.

Role in Amiga Booting

Upon power-on or reset, the processor in the begins execution at $000000, which is mapped to the Kickstart ROM physically located at $F80000. The ROM, typically 256 KB in early models and 512 KB in later versions, contains the bootstrap that initializes the system. Kickstart then performs hardware autodetection, identifying components such as the CPU type, chipset, and available memory through the Autoconfig protocol, which dynamically assigns resources to expansion boards without manual configuration. Following hardware initialization, Kickstart integrates with by loading core resident libraries like Exec (the kernel) and (the graphical user interface) directly from ROM. It subsequently scans for bootable media on devices such as floppy diskettes or hard drives, executing a boot block if present to run the startup-sequence script. This process loads additional OS components and hands off control to the fully resident operating system, enabling the desktop or other applications. Kickstart's operations are inherently dependent on the Amiga's custom chipsets for effective . Specifically, it initializes Agnus for control and functions, Denise for video signal generation, and Paula for audio processing and operations, ensuring these peripherals are ready before OS handover. If no bootable OS is detected, Kickstart drops to a basic (CLI), allowing users to manually mount volumes or execute commands from ROM-based tools. In cases of boot failures due to hardware issues or software exceptions, Kickstart invokes the "Guru Meditation" error handler from Exec.library, displaying a diagnostic screen with error codes and task details for troubleshooting. This mechanism, or a fallback diagnostic mode during self-tests, provides essential feedback when standard cannot proceed.

History and Development

Origins at Commodore

The development of Kickstart originated during the early at Amiga Inc., a company founded in 1982 as Hi-Toro by engineers including , who had previously designed key hardware for systems. Renamed Amiga Inc. in 1983 due to a conflict, the team focused on creating a next-generation known internally as the Lorraine project, incorporating a processor and custom chips for advanced graphics and sound. A primary aim was to embed core operating system primitives directly into ROM to drastically reduce times, transforming what could take several minutes on disk-based systems into mere seconds by enabling immediate hardware initialization and kernel loading without reliance on secondary storage. This approach was conceived between 1982 and 1984 amid financial pressures, including a $500,000 from to sustain development, as the team pivoted from a game console concept to a full computer following the 1983 video game market crash. Key design goals for Kickstart emphasized to ensure across future models, preemptive multitasking support for the Exec kernel right from system startup, and seamless integration with custom chips like Agnus (for graphics and ), Denise (for video output), and Paula (for audio). Exec, the foundational kernel derived from the operating system licensed from MetaComCo, provided a compact for process management, , and device handling, abstracting low-level hardware interactions through libraries such as exec.library and handlers for consoles, files, and devices. This structure allowed for efficient allocation of chip RAM and fast RAM, enabling applications to leverage the Amiga's for fast graphics operations and four-channel sound synthesis without direct hardware dependencies, while maintaining a flexible, open-ended system extensible by developers. Early prototypes during 1983-1984 utilized EPROMs to test these ROM-based components iteratively, simulating the final environment as the team refined OS primitives alongside hardware simulations. Following Commodore International's acquisition of Inc. in August 1984 for approximately $27 million—which included repaying the loan and absorbing the engineering team—Kickstart was finalized as the bootstrap for the 1000's launch. Under Commodore's oversight, the initial implementation allocated a 256 KB ROM space, divided between the core Kickstart loader (handling OS initialization and Exec startup) and diagnostic routines for hardware testing, though production constraints led to loading the bulk of Kickstart from into RAM for the 1000. This integration marked Commodore's commitment to positioning the as a powerhouse succeeding the Commodore 64, with Kickstart ensuring rapid access to the multitasking environment and custom chip features from power-on. The was unveiled on July 23, 1985, at in New York (with first shipments beginning in late 1985), in part due to challenges in finalizing the ROM contents amid ongoing software-hardware . Prototypes prior to this relied heavily on erasable EPROMs for iterative Kickstart testing, allowing engineers like to debug boot sequences and kernel integration without full mask ROM production, a process that accelerated development but contributed to the timeline extension as Commodore integrated Amiga's innovations into its manufacturing pipeline.

Evolution Through Amiga Models

The Kickstart firmware debuted with the in 1985, utilizing the Original Chip Set (OCS) and loading a 256 KB Kickstart 1.0 image from due to the absence of onboard ROM chips, which limited initial times but allowed flexibility in updates. This design tied Kickstart closely to the OCS hardware, initializing basic graphics, sound, and memory allocation for the processor at 7 MHz. Subsequent models like the Amiga 500 and 2000, released in 1987 and also based on OCS, integrated 256 KB ROM chips with Kickstart 1.2, enabling faster ROM-based booting and better compatibility with expanding peripherals, though users often upgraded to Kickstart 1.3 in 1988 for improved stability and drive support. The Enhanced Chip Set (ECS), introduced in 1990 with the Amiga 3000, brought modest upgrades such as increased chip RAM addressing up to 2 MB and higher-resolution modes like 640x480, necessitating 512 KB ROMs with Kickstart 2.04 for full hardware initialization and enhanced graphics handling. By 1991, ECS appeared in consumer models like the Amiga 500 Plus and 600, where ROM upgrades to Kickstart 2.05 added IDE and PCMCIA device drivers, reflecting Commodore's strategy to extend OCS-era machines while transitioning to more capable chipsets. A pivotal advancement occurred in 1992 with the Advanced Graphics Architecture (AGA) chipset in the and 4000, which supported 256 colors from a 24-bit palette and up to 2 MB chip RAM; these models shipped with 512 KB Kickstart 3.0 ROMs (often as two 256 KB chips) to leverage AGA's capabilities, including new datatypes for true color and storage. Commodore's product strategy emphasized bundled upgrades, as seen in the 1991 CDTV multimedia player, which used ECS with Kickstart 1.3 plus an extended 256 KB ROM for booting and audio/video extensions, positioning as a home entertainment hub. Similarly, the 1993 console, built on AGA hardware akin to the , featured Kickstart 3.1 in a 1 MB configuration with CD32-specific extensions for its Akiko chip, enabling chunky-to-planar conversion for CD-based games and media. During the , the shift to modular ROMs facilitated accelerator card integrations, allowing users to load Kickstart into fast RAM for compatibility with upgraded processors. Commodore's bankruptcy in April 1994 curtailed official Kickstart development, freezing evolution at Kickstart 3.1 despite ongoing hardware like the tower. Post-bankruptcy, third-party developer Phase 5 extended the ecosystem through PowerPC accelerator boards like the 1997 CyberStorm PPC for /4000 models, which ran Kickstart 3.1 in emulated 68k mode alongside native PowerPC execution, sustaining compatibility into the early 2000s via enhanced OS support and peripherals.

Versions

Kickstart 1.x Series

The Kickstart 1.x series represented the initial firmware releases for the platform, providing the foundational bootstrap and operating system kernel components necessary for hardware initialization and basic software execution. Released starting in 1985 alongside the , these versions utilized the Exec kernel for preemptive multitasking and included core libraries such as for handling. Kickstart 1.0, specifically, featured Exec version 30.xx and Intuition 1.0, and was distributed on rather than ROM for the , marking the system's debut with support for up to 512 KB of chip RAM. Subsequent updates addressed early stability issues and expanded compatibility. Kickstart 1.1, released in December 1985, focused primarily on bug fixes, though it was limited to systems and remained floppy-based for the Amiga 1000. By 1986, Kickstart 1.2 introduced hardware support for the and models, with enhancements to the (CLI) for better scripting and command execution, while shifting to 256 KB ROM integration on newer machines. The series culminated in Kickstart 1.3 in 1988, the final 1.x iteration, which integrated more closely with 1.3 for improved desktop functionality and used 256 KB ROMs across supported models. Kickstart 1.3 was the first version to support booting from a . Key features of the 1.x series included the Autoconfig system for automatic detection and configuration of expansion hardware, such as memory and peripherals, via a standardized board identification process in the expansion slots. Basic multitasking was enabled through the Exec kernel, allowing cooperative and preemptive task switching, while built-in fonts like supported text rendering in the CLI and early graphical applications. A simple CLI environment facilitated diskless booting scenarios by providing console access for manual commands when no bootable media was present. However, limitations persisted, such as the absence of native hard drive partitioning support—requiring third-party tools for multi-partition setups—and monochrome-only diagnostics during the boot sequence, which displayed error patterns in black and white without color coding. ROM versions in the 1.x series could be identified using the CLI command "version," which outputs the Kickstart and library versions upon execution from the system shell. Alternatively, ROM provided a hardware-level verification method; for instance, Kickstart 1.3 (revision 34.5) has a checksum of $15267DB3. These detection methods were essential for compatibility on early systems.

Kickstart 2.x and 3.x Series

The Kickstart 2.x series, debuting with version in 1990 for the , represented a major evolution from earlier iterations, incorporating 512 KB ROMs and Exec library version 36.xx alongside 2.0 for improved multitasking and graphical interfaces. This release emphasized better , including optimized handling of Fast RAM, which allowed for more efficient allocation in expanded systems. Subsequent updates, such as 2.04 in 1991 for models like the + and 2000, addressed compatibility issues with the Enhanced Chip Set (ECS) through Exec 37.175, enhancing graphics and sound stability while fixing memory-related bugs. Kickstart 2.05, released in 1992 primarily for the Amiga 600, further refined these capabilities with Exec versions 37.299 to 37.350, introducing native IDE hard disk drive support and PCMCIA compatibility to streamline peripheral integration. These versions collectively advanced OS integration by supporting multi-language interfaces, starting with foundational right-to-left text handling for scripts like Arabic and Hebrew via updated intuition libraries, and included tools for basic hard disk partitioning to facilitate user-configurable storage setups. Transitioning to the 3.x series, Kickstart 3.0 arrived in 1992 alongside the and 4000, utilizing 512 KB ROMs with Exec 39.106 to enable support for the Advanced Graphics Architecture (AGA) chipset, which expanded color palettes and resolution options for more sophisticated visuals. This version prioritized seamless hardware initialization for AGA chipset-equipped machines, building on 2.x optimizations while introducing a more robust boot process. Kickstart 3.1, released starting in 1993 (with the ) and fully in 1994, and compatible across a wide range of models, featured Exec versions from 40.56 to 40.70 in 512 KB ROMs (1 MB for ), with notable enhancements to the (CLI) for better scripting and automation. It added Relocatable Types for (RTG) support, enabling compatibility with third-party graphics cards for higher resolutions beyond native chipsets, and incorporated datatypes for handling files like ANIM and CDXL formats to improve file viewing and editing workflows. The series also integrated an updated preferences editor for system customization and expanded HDDTools, such as HDToolBox, to support advanced partitioning schemes on larger drives. Multi-language support was further refined, allowing broader in user interfaces and applications. In 2018, released an official update to Kickstart 3.1 as version 3.1.4, maintaining 512 KB ROM compatibility while fixing over 20 ROM modules and numerous disk-based components for improved stability and large hard disk support exceeding 4 GB partitions. This update modernized CLI commands with native , softlinks, and handling, without introducing Y2K-specific fixes as previously rumored in unofficial patches. Subsequent developments continued with the 3.2 series, released by starting in May 2021. 3.2 (revision 47.xx) introduced enhanced USB 2.0 support, improved networking, and better compatibility for classic hardware, available as a full ROM and disk set for all 68k models. Updates followed: 3.2.1 in December 2021 with bug fixes and performance tweaks; 3.2.2 in March 2023 adding security enhancements and driver improvements; and 3.2.3 in April 2025, focusing on stability for larger storage and modern peripherals while maintaining . As of November 2025, 3.2.3 represents the latest official update for classic Amigas, with Exec version 47.496. Versions in the 2.x and 3.x series can be identified using the "version" command in the CLI, which outputs details such as "Kickstart 3.1 (40.68), Workbench 3.1 (40.68)" to confirm the exact ROM revision and associated OS components.

Technical Functionality

ROM-Based Initialization

The Kickstart ROM initialization begins upon power-on or reset, with execution jumping to the boot ROM entry point at F80000ontheAmiga1000,whichloadsthefullKickstartintoF80000 on the Amiga 1000, which loads the full Kickstart into FC0000–FFFFFFfromdisk.OnlatermodelsliketheA500andA2000,theintegratedKickstartROMstartsatFFFFFF from disk. On later models like the A500 and A2000, the integrated Kickstart ROM starts at F80000 (512 KB, from Kickstart 2.0) or $FC0000 (256 KB, Kickstart 1.x), depending on the ROM size and hardware configuration. This entry point handles the initial low-level setup, including CPU initialization for the 68000 or 68020 processor by establishing the supervisor stack pointer and exception vectors, ensuring the processor operates in a stable state before proceeding. The process then clears the chip RAM to zero out any residual data, preventing corruption during subsequent operations, while allocating an initial 64 KB block for system use, such as the ExecBase structure and temporary stacks. Following memory preparation, the ROM scans for expansion hardware using the Autoconfig protocol, starting at address E80000,whereunconfigured[Zorro](/page/Zorro)IIboardstemporarilyappearonebyoneviathe/CFGINsignalchain.[](https://wiki.amigaos.net/wiki/ExpansionLibrary)Thisdetectionprocessassignsbaseaddressesandresourcestodetectedboardsin[Zorro](/page/Zorro)slots,relocatingthemfromthetemporaryE80000, where unconfigured [Zorro](/page/Zorro) II boards temporarily appear one by one via the /CFGIN signal chain.[](https://wiki.amigaos.net/wiki/Expansion_Library) This detection process assigns base addresses and resources to detected boards in [Zorro](/page/Zorro) slots, relocating them from the temporary E80000 space to their final memory or I/O locations, with the ROM supporting both 16-bit and 32-bit cycles as needed for compatibility. The Kickstart ROM itself includes relocatable code segments to accommodate variants sized at 512 KB (standard for Kickstart and later) or custom 1 MB configurations, allowing flexible loading and overlay without hardware modifications on supported models. Resource loading commences with the initialization of Exec.library from the ROM, loaded into memory at address $00000004 and establishing the foundation for task scheduling and multitasking via ROM-tags in the resident module list. Subsequently, graphics.library and layers.library are loaded to configure the display, setting up modes such as 640x400 interlaced for PAL or NTSC systems by initializing bitplane pointers (e.g., at DFF0E0–DFF0E0–DFF0F6) and Copper lists for video timing synchronization during vertical blanking. Basic error handling during initialization involves checksum verification of ROM data using functions like SumKickData; if critical failures occur—such as memory corruption or autoconfig timeouts—the process halts and drops into the built-in ROM , displaying a hexadecimal dump of relevant memory for diagnostic purposes.

Device and Resource Management

Kickstart manages device interactions primarily through the Exec kernel's device list, a linked structure that enumerates available devices and handlers for system-wide access. This list enables the mounting of filesystems such as the Fast File System (FFS), which serves as the default for floppy disks and hard disk drives, facilitating operations post-initialization. For storage devices, Kickstart employs the trackdisk.device to handle low-level disk control, including motor management, raw track reading, and writing, ensuring reliable transfer without user intervention. Similarly, the console.device provides a text-based interface for output to windows, emulating an enhanced ANSI terminal for application display and user interaction. Resource allocation in Kickstart occurs via the Exec system's library and resource mechanisms, where core components like dos.library are initialized to support file operations, directory traversal, and handler assignments. This library integrates with the device list to register handlers for filesystems and peripherals, while font management is handled through diskfont.library, loading scalable and fonts into memory as needed for graphical interfaces. The Autoconfig process, executed during early boot, dynamically assigns memory addresses and interrupts to expansion peripherals, such as devices for video synchronization or ports for audio interfaces, preventing conflicts in the bus environment. At runtime, Kickstart supports expansion through libraries like expansion.library, which configures II and III expansion cards by allocating address spaces and initializing board-specific resources for peripherals such as RAM expansions or accelerators. To optimize limited ROM capacity, Kickstart implements for non-essential modules, deferring the loading of overlay components like additional device drivers or libraries from disk until explicitly required by the system or applications, thereby conserving initial .

Diagnostics and Testing

Built-in Diagnostic Mode

The built-in diagnostic mode in Kickstart is accessed by holding both mouse buttons while powering on or rebooting the , which brings up the Early Startup Control Screen. This interface, introduced in Kickstart , provides an internal testing environment primarily focused on hardware initialization and expansion board verification, allowing users to inspect configuration without proceeding to full boot. The screen offers options for boot configuration, display settings, and diagnostics, with the latter displaying details on installed expansion boards, including board number, manufacturer, product name, and status (working or defective). If a defective board is detected during startup, the halts and presents this diagnostic view to facilitate identification of hardware issues. During the ROM-based initialization sequence, automatic power-on self-tests () check for basic hardware functionality, including RAM (both chip and fast ), CPU registers, and custom chips such as Agnus for operations, along with pattern tests to verify video RAM integrity; these tests use color changes on the screen to indicate pass/fail states across all Kickstart versions. For expansion boards, the diagnostics scan slots and report failures in real-time. In Kickstart 3.x versions, the interface expands support for ECS/AGA chipsets and includes more detailed status reporting. Output is presented in a monochrome text mode, featuring a tabular format with hex values for register states and error indicators where applicable; earlier versions display a basic "Kickstart" initialization banner during entry. This setup aids in pinpointing configuration mismatches or faults, such as memory addressing errors or chipset incompatibilities. Limitations of the mode include its non-interactive nature for repairs—no tools for fixing issues are provided, and it relies on visual inspection or external intervention for resolution. It was primarily designed for factory quality assurance and initial troubleshooting rather than ongoing user maintenance, with changes (e.g., cache disabling or boot overrides) applying only to the current session.

Error Detection Mechanisms

Kickstart incorporates runtime detection primarily through the Exec library's alert , which monitors for low-level exceptions and hardware faults during operation. When an unhandled exception occurs, such as an address or bus fault in the 680x0 processor, Exec triggers a "Dead-End Alert" that manifests as the iconic screen. This screen displays the error in format as #DSGeCode.TASK, where D indicates non-recoverability (starting with 8 for fatal ), S is the subsystem ID, G the general , e the specific , and TASK the address of the offending task; for instance, an address might appear as 80000003, often linked to protocol violations when software attempts 68881/68882 instructions on unsupported hardware like a 68000 CPU. The display also shows the software name, task ID, and (PC) register value to aid , halting the to prevent further corruption. Error logging complements the visual alert by capturing diagnostic data for post-crash analysis. Exec writes alert details, including the full 32-bit error code and task pointer, to the LastAlert structure in the ExecBase, a RAM-based buffer that stores the four longwords of the most recent alert for retrieval by developers. For deeper traces, the built-in ROM-WACK debugger can output stack traces and register dumps via the serial port at 9600 baud, activated by connecting a terminal and sending a DEL character during the Guru display; this is particularly useful for capturing coprocessor-related faults, where codes like 80000003 signal absent or mismatched floating-point units unique to Amiga's hardware architecture. Hardware-specific errors, such as Copper list overflows in the graphics coprocessor (e.g., 82010003 for list overload) or 680x0 bus errors during DMA operations (e.g., 80000002 for invalid access), are similarly logged to facilitate identification of issues like malformed display lists or contention in the Amiga's custom chip bus. In Kickstart 3.x, error handling saw enhancements through SetPatch, a startup utility that applies ROM patches and introduces verbose reporting modes for improved diagnostics. SetPatch enables detailed console output during boot and error events, expanding on base information with additional context like patch application status and extended stack details, reducing ambiguity in recovery scenarios. For recoverable alerts (those starting with 0-3), the system preserves task context, allowing immediate access to a (CLI) for manual intervention, such as killing the faulty task or freeing resources, thereby enabling partial recovery without full . This mechanism underscores Kickstart's design emphasis on developer-friendly fault isolation, distinguishing it from total system halts in earlier versions.

Usage and Installation

Installing or Upgrading ROMs

Installing or upgrading Kickstart ROMs on systems involves replacing the chips on the , a process that requires careful handling of hardware components. For models like the and , the ROMs are housed in removable (DIP) sockets, allowing users to extract the existing 256 KB EPROMs, such as 27C020 chips, and insert new ones without . In contrast, higher-end models like the feature soldered ROMs, necessitating tools and professional expertise to avoid damaging the board. Upgrade paths typically involve transitioning from earlier versions, such as Kickstart 1.3, to later ones like 3.1, using official ROM kits originally distributed by Commodore or subsequent licensees like . The supports single-chip upgrades to Kickstart 3.1 via its DIP sockets, while the requires model-specific dual-chip sets for 32-bit compatibility and may involve additional hardware modifications for full functionality. Verified ROM images for these upgrades can be obtained from established archives like Aminet, but users must ensure they possess the original hardware to comply with copyright laws. Essential tools for the process include an programmer, such as the MiniPro TL866-II Plus, blank 27C020 or 27C400 chips, a compatible for the programmer, and a UV-C eraser for reusing chips. The programming steps entail loading the ROM binary file into the programmer software, inserting the blank , and verifying the burn before installation; for 32-bit Amigas, two chips (high and low) must be prepared and inserted into designated sockets like U6A and U6B. Following Commodore's 1994 bankruptcy, the rights to Kickstart ROMs transferred to entities including Cloanto Corporation, which licenses their use; personal dumping and installation for owned Amiga hardware is generally permissible, but commercial distribution remains restricted. Risks associated with installation include permanent damage to the EPROMs or motherboard from incorrect chip orientation, exposure to improper voltage levels (strictly 5V), or faulty power supply units that deliver unstable currents. To mitigate these, users should confirm proper seating of the chips, test voltages with a multimeter, and verify the upgrade by booting into diagnostic mode or using tools like the ROM update utility if available on the system.

Configuration Options

Kickstart configuration is achieved through software-based mechanisms that allow users to customize boot behavior, device handling, and system patches without altering the ROM itself. The primary tool for boot options is the startup-sequence script in the S: directory, which runs after Kickstart initializes the operating system and executes a series of CLI commands to set up the environment. For instance, users can insert delays in this script to ensure proper initialization of expansion hardware, such as by adding a Wait 2 Seconds command before loading drivers. Environment variables, managed via the SetEnv CLI command, provide further control over and are stored globally in the : directory for persistence across shells. This command enables or configures specific devices and features; for example, SetEnv SCSI_DEVICE scsi.device activates support by assigning the appropriate handler, while variables like SetEnv Language "english" influence locale-specific behaviors. System patching for enhanced functionality or bug fixes is handled by tools like SetPatch, which must be invoked early in the startup-sequence to modify Kickstart ROM routines in memory. SetPatch addresses known issues in Kickstart versions, such as flaws, and supports custom loaders through options like enabling AGA video modes on compatible hardware. For multi-ROM setups, third-party tools like MultiBoot extend this by allowing selection of different Kickstart images at time. In Kickstart 3.x series, the Prefs editor facilitates additional configuration, including Retargetable Graphics (RTG) modes for VGA monitor compatibility by adjusting screen resolutions and color depths via the ScreenMode preferences. Expansion hardware configuration relies on the Autoconfig protocol for automatic , but overrides are possible through card-specific hardware jumpers that disable Autoconfig and assign fixed addresses to prevent conflicts in multi-card setups. Software overrides can also be applied via expansion.library functions or device-specific commands in the startup-sequence, such as disabling a monitor's for the A2024 via settings. Multilingual support is configured through locale.library integration with , where SetEnv variables set language catalogs for user interface elements like menus and fonts. Troubleshooting tweaks include enabling verbose output in the boot process by modifying the startup-sequence to echo commands, and applying patches like StackAttack to monitor for memory leaks by enforcing stack size limits and reporting overflows during runtime.

Compatibility and Legacy

Backward Compatibility Challenges

One major challenge in using newer Kickstart versions arose from changes to core system , such as , which evolved from version 33 in Kickstart 1.x to higher versions in Kickstart 2.x, potentially breaking applications that relied on specific library interfaces or undocumented behaviors for graphical user interfaces. For instance, 2.0 in Kickstart 2.0 introduced enhancements that rendered some 1.x-era GUIs incompatible without code updates, as developers were encouraged to specify lower version numbers for but many legacy applications did not. Similarly, hard disk partition tables formatted under Kickstart 1.3 using the Old File System (OFS) often became unreadable in Kickstart 3.0 without loading the Fast File System (FFS) handler, since 3.0 prioritized RDB-based structures introduced in 2.0 and lacked built-in support for certain pre-2.0 OFS configurations on devices. Hardware mismatches compounded these software issues, particularly when running Kickstart 3.x on older OCS or ECS machines, where the ROM's assumptions about enhanced modes led to visual glitches or crashes in applications expecting consistent chipset behavior. On the , Kickstart 2.05 exhibited memory detection problems due to differing timing requirements in its OCS-based architecture, often resulting in incomplete chip RAM recognition limited to 512 KB, which disrupted booting or operation of memory-intensive software. To mitigate these challenges, users adopted hardware solutions like Kickstart switchers, which allowed seamless toggling between ROM versions such as 1.3 for legacy applications and 3.x for modern features, often integrated into accelerators or expansion cards. Post-1994, third-party developers created patched ROMs and emulation modes that simulated 1.3 behaviors within newer Kickstarts, enabling for incompatible binaries via tools like custom device handlers. The bankruptcy of in April 1994 severely limited official support for addressing these compatibility issues, leaving game ports, demos, and third-party software adaptations reliant on community efforts amid the absence of manufacturer-backed updates or hardware revisions.

Support in Emulation and Modern Systems

Emulation software for the relies heavily on Kickstart ROM images to accurately replicate the original system's boot process and hardware initialization. FS-UAE, a cross-platform emulator, requires users to provide original Kickstart ROM files for optimal compatibility across various Amiga models; for instance, the typically uses kick.rom version 1.3. Similarly, WinUAE, a Windows-based emulator, supports Kickstart ROM loading through an integrated scanner that verifies files via checksums, ensuring authenticity for full system simulation. It also handles ADF files for images and HDF files for hard disk emulation, allowing comprehensive recreation of software environments that depend on Kickstart's . Modern hardware recreations preserve Kickstart functionality through FPGA-based systems that aim for cycle-accurate emulation of architecture. FPGA platform incorporates Kickstart ROMs, such as 512 KB or 1 MB images placed as KICK.ROM on an , to boot OCS, ECS, and AGA chipsets with precise timing, supporting CPU cores like the 68000 for authentic performance. Vampire V4 boards integrate Kickstart directly into their FPGA cores via , where users can load versions from 1.1 to 3.2 using tools like VampireFlash for permanent installation or VampireMap for temporary mapping from disk, enabling standalone Amiga-compatible operation. In the 2020s, released Kickstart 3.2.3 as part of 3.2 updates in 2025, providing enhanced ROM support for classic 68k-based systems with improvements like reduced chip RAM reservations. The use of Kickstart ROMs in emulation and recreations operates under legal constraints that emphasize user ownership and licensed distribution. Individuals who own original hardware may legally dump their own Kickstart ROMs using tools like Transrom, while licensed sets are available through products such as Amiga Forever. Community projects, including those on the English Amiga Board, facilitate verification by providing checksums; for example, the CRC32 hash for Kickstart 3.1 on an A1200 is 1483A091, helping users confirm ROM integrity against corrupted or modified files. In the retro computing scene, enthusiasts continue to develop extensions, such as updated USB stacks in modern variants and 4K scaler compatibility via tools like AmigaVision with RetroTink hardware, ensuring Kickstart-based systems interface with contemporary peripherals.

References

  1. https://erikarn.github.io/amiga/docs/Amiga_ROM_Kernel_Reference_Manual_v1.3.pdf
  2. https://www.ikod.se/wp-content/uploads/2020/08/Amiga_Hardware_Reference_Manual_3rd_Edition.pdf
  3. https://www.amigakickstart.com/
  4. https://retrocomputing.stackexchange.com/questions/2889/how-does-the-kickstart-rom-load-and-start-workbench
  5. https://www.goto10retro.com/p/40-years-of-the-amiga-from-commodore
  6. http://www.retroisle.com/general/amiga_kickstart_wb.php
  7. http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node0171.html
  8. https://www.lemonamiga.com/page/kickstart-rom-2-04
  9. https://wiki.amigaos.net/wiki/Expansion_Library
  10. https://amitopia.com/amiga-roms-autoconfig-guide/
  11. http://amigadev.elowar.com/read/ADCD_2.1/Includes_and_Autodocs_2._guide/node0383.html
  12. http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node00C6.html
  13. https://www.lemonamiga.com/forum/viewtopic.php?t=4927
  14. https://retro-programming.com/amiga-boot-up-self-diagnostics/
  15. https://www.geekometry.com/2015/01/gamechangers-jay-miner-and-the-amiga-computer/
  16. https://lowendmac.com/2016/the-amiga-story-conceived-at-atari-born-at-commodore/
  17. https://arstechnica.com/gadgets/2007/08/a-history-of-the-amiga-part-2/
  18. https://aminet.net/docs/misc/rkrm-dos.pdf
  19. https://www.betaarchive.com/forum/viewtopic.php?t=33833
  20. http://wiki.classicamiga.com/Kickstart_Roms_Explained
  21. https://www.computinghistory.org.uk/det/63899/Commodore-Amiga-1000/
  22. https://wiki.abime.net/hardware/index
  23. https://www.amigaforever.com/kb/15-127
  24. https://www.amigawiki.org/doku.php?id=en:parts:custom_chips
  25. http://wiki.classicamiga.com/Amiga_models
  26. https://www.gregdonner.org/workbench/wb_30.html
  27. https://cloanto.com/amiga/roms/
  28. https://www.lemonamiga.com/page/kickstart-rom-3-1
  29. https://www.bcs.org/articles-opinion-and-research/the-rise-and-fall-of-commodore/
  30. http://amiga.resource.cx/exp/cyberstormppc
  31. https://bigbookofamigahardware.com/bboah/product.aspx?id=265
  32. http://amigadev.elowar.com/read/ADCD_2.1/Libraries_Manual_guide/node028E.html
  33. https://www.gregdonner.org/workbench/wb_11.html
  34. https://www.amigawiki.org/doku.php?id=en:system:overview_kickstart_versions
  35. https://www.gregdonner.org/workbench/wb_12.html
  36. https://www.gregdonner.org/workbench/wb_13.html
  37. http://amiga.resource.cx/search.pl?cat=kick
  38. https://wiki.amigaos.net/wiki/AmigaOS_Manual:_AmigaDOS_Command_Reference
  39. https://github.com/SirCathal/KickstartPalPatcher/releases
  40. https://wiki.amigaos.net/wiki/Preferences
  41. https://hyperion-entertainment.com/index.php/news/1-latest-news?start=5
  42. https://www.hyperion-entertainment.com/index.php/news/1-latest-news/290-amigaos-42-for-all-classic-amigas-released-and-available
  43. https://www.theregister.com/2025/04/10/amigaos_3_2_3/
  44. https://amigawiki.de/doku.php?id=en:system:kickstart
  45. http://amigadev.elowar.com/read/ADCD_2.1/Devices_Manual_guide/node00DC.html
  46. https://wiki.amigaos.net/wiki/Console_Device
  47. http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node02C7.html
  48. https://forum.amiga.org/index.php?topic=68476.135
  49. https://wiki.amigaos.net/wiki/AmigaOS_Manual:_Early_Startup
  50. http://amiga.nvg.org/amiga/reference/AmigaOS3.9_Manual/workbench/book-main147.html
  51. https://wiki.amigaos.net/wiki/Understanding_the_alert_error_numbers
  52. https://www.amigaforever.com/kb/16-122
  53. https://www.jaruzel.com/amiga/amiga-os-command-reference-help/setpatch.html
  54. https://www.pureamiga.co.uk/2021/05/30/burn-your-own-kickstart/
  55. https://docs.sidecartridge.com/sidecartridge-kickstart/hardware-installation/
  56. https://retrocomputing.stackexchange.com/questions/15865/who-ended-up-owning-commodores-semiconductor-ip
  57. http://amiga.nvg.org/amiga/reference/AmigaOS3.5_Manual/dos/book-main51.html
  58. https://fs-uae.net/docs/kickstart-roms/
  59. https://www.winuae.net/
  60. https://github.com/MiSTer-devel/Minimig-AGA_MiSTer
  61. http://wiki.apollo-computer.com/doku.php?id=system_tools:kickstarts
  62. https://www.hyperion-entertainment.com/
  63. https://eab.abime.net/showthread.php?t=47519
  64. https://misterfpga.org/viewtopic.php?t=9269
Add your contribution
Related Hubs
User Avatar
No comments yet.