This article includes a list of general references, but it remains largely unverified because it lacks sufficient corresponding inline citations. (August 2008) (Learn how and when to remove this template message)
Autoconfig is an auto-configuration protocol of Amiga computers which is intended to automatically assign resources to expansion devices without the need for jumper settings. It is analogous to PCI configuration.
AutoConfig is integrated within the Amiga's Kickstart firmware, usually stored in ROM. When the system is switched on, AmigaOS interrogates each expansion device in turn and assigns address space or resources as needed. For example, in the case of a memory card, the OS can dynamically add the memory to the system. Through Autoconfig the OS can access firmware on expansion devices, for example, to boot from a disk connected to a hard disk controller.
Expansion devices respond to certain fixed memory addresses starting at hexadecimal (or for Zorro III) if the /CFGIN signal is asserted and the device is not already configured. The CPU reads nibbles of configuration information (usually supplied by a PAL) such as manufacturer ID, product ID, and the amount of address space the device requires. The CPU then writes a base memory address to the device (or tells it to "shut up" if for some reason it can't be configured), and the device asserts /CFGOUT.
The /CFGIN of the first device is tied to ground. The second device's /CFGIN is controlled by the first device's /CFGOUT, and so on.
In a backplane design such as the Amiga 2000, connecting the /CFGOUT of one slot directly to the /CFGIN of the next would create the problem that an unoccupied slot would break the configuration chain. To solve this, the backplane ORs the /CFGIN and /CFGOUT signals to form the /CFGIN for the next slot (/CFGOUT is pulled low if undriven), which allows empty slots to be bypassed. This requires one 74LS32 (quad OR gate) on the Amiga 2000, which is the only motherboard hardware required by Autoconfig.
Autoconfig is part of the Zorro II and Zorro III expansion bus specification for configuring expansion devices in Amiga systems. Zorro II was first used in the Amiga 2000, though a similar expansion bus is present on the Amiga 1000. Zorro II is a relatively straightforward extension of the 68000 bus. Autoconfig requires the 68000 data and address bus to be available to all devices on the bus. In theory, a virtual address system, as used in PCI, would require a minor revision to Autoconfig.
The Amiga 2000 can accommodate five Zorro expansion cards, such as, RAM expansions, SCSI controllers and graphic cards. However the standard does not put a limit on the number of devices. In the A2000, two Zorro II slots are aligned with ISA slots. The Zorro bus and ISA bus can be connected by means of a "bridgeboard", such as, the Janus Hardware Emulator, which allows emulation of Intel 80286 or 80386 systems.
Zorro III is the 32 bit auto-configuring expansion bus of Amiga 3000 and Amiga 4000 systems. From the A3000 design onwards, it was deemed desirable for all enumerable hardware expansions to use Autoconfig. It is OS-legal for non-Autoconfig hardware to be completely ignored and the standard was adopted in AmigaOS 3.1.
Compared with PCI configuration, Autoconfig is much simpler, yet provides the same basic functions. PCI allows random access to the configuration space of devices, which requires system registers and I/O lines. Autoconfig requires no such system hardware, but has the restriction that devices can only be configured in sequence, and they remain configured until reset. Autoconfig does support hot-plugging but only for one device (the last one). Most manufacturers which required hot-plugging instead did not use Autoconfig for whatever was being added and removed (e.g. a PCMCIA card) but instead assigned whatever resource was necessary permanently to the port or controller and handled the addition or removal much like inserting a floppy disk.
An Amiga's Autoconfig is performed by the OS at boot-time and may not be changed without rebooting. In theory, PCI can change its resource allocation at any time, though both the popular Linux and Windows operating systems do not allow such changes due to architectural limitations in the respective operating systems. Direct PCI hardware (e.g. a PCI card), however, may not be hot-plugged (PCI configuration registers are a separate part of the specification) due to the synchronous arbited[check spelling] nature of the bus. So, PCI can reallocate resources on the fly, which it does when the OS loads and may override BIOS resource allocation, but cannot change the hardware while the system is running. Autoconfig can change the hardware while the system is running but only for the last hardware in the config sequence, or to add a new piece of hardware. Neither Autoconfig nor PCI PnP actually allow this in any considerable operating system.