Were all Amigas except for A1000 un-upgradeable OS-wise?

Question

In his latest video, "The 8-Bit Guy" on YouTube talks about the original Amiga 1000: https://www.youtube.com/watch?v=kjapiUQOi2s

One of the things he mentions is that, unlike all later Amigas, it has no ROM containing the OS. Instead, you had to put in floppy disks to boot it up, loading in the Workbench and whatnot each time you powered it on. It's mentioned that this was done because they had not fully finished the OS at release, and wanted to be able to send updates to existing customers.

As I understand it, all later Amigas instead had the OS/Workbench on a ROM, so no floppies were needed and it booted up quickly. But since the very definition of "ROM" means it cannot be overwritten, doesn't that mean that there was a massive downside to all Amigas except for the very first one, in that they were permanently stuck with whatever version of the Amiga OS/Workbench that was current when the machine (or its used ROM) was manufactered?

This sounds unreasonable to me.

Does this mean that, as soon as a new version of Amiga OS was released, all Amiga owners had to do the "start with floppy disk" routine, just like A1000 owners, lest they want to use the now outdated built-in ROM version of the OS? If so, it seems like the use of such a ROM was highly limited and almost pointless. It would feel very strange to me to have to slowly load in the OS every fresh boot from floppies and just bypass the fast ROM chip every day.

Or did they actually sell new ROM chips that you soldered onto your Amiga after removing the old chip? That sounds kind of crazy... I must be missing something vital about this.

Answer 1

All later Amiga models come with the core of the operating system stored in a ROM called "Kickstart" - the A3000 is a somewhat special case, but that's not relevant here. The ROMs do not contain Workbench - i.e. the actual desktop and its utilities - but the kernel, DOS, graphics routines etc. These ROMs were socketed, not soldered to the board in all Amiga models.

'Loading' the OS from ROM is obviously a lot faster, especially if your system is initially only supporting floppy disks for storage. And it was cheaper - especially for Commodore, because it could manufacture its own ROMs, but not its own RAM.

Updating the Operating System only required you to buy a new set of ROMs and disks, open your computer and replace the old ROMs with the new ones - or have your dealer do that for you, if you didn't want to void the warranty.

Alternatively, you could load a newer version of Kickstart - the part of the OS which usually resides in the ROM chips - from disk and activate it by patching the machine's reset vector and then reset the computer. This was never an official solution, but there were 3rd party tools to create that kind of boot disk.

In reality, 90% of the Amiga users never needed to upgrade their operating system. By the time the Amiga models that had the OS in ROM (A500 and A2000) were released, the first generation of the Operating System had become pretty stable and further 1.x updates only contained improvements not relevant for your average floppy disk only user. And if millions of potential customers run version 1.x of the operating system, commercial software vendors will make sure their software works with that version.

The much more likely scenario was people downgrading their OS, usually via a "Kickstart switcher", because the Kickstart 2.x version their Amiga shipped with wasn't compatible with one of the Games they were trying to run.

None of this is strange at all: While the Amiga could actually be used as a very powerful and innovative graphics workstation, the vast majority of its owners used it like any other homecomputer was used in the eighties: switch it on, insert a disk, load a game or application - then switch it off again a few hours later. Nobody was thinking about "Operating Systems" back then, especially since many of your applications and all of your games killed the OS as soon as possible.

Answer 2

they were permanently stuck with whatever version of the Amiga OS/Workbench that was current

You'd be stuck with the Kickstart version you had, but later versions of AmigaOS were a bit flexible with Kickstart compatibility. Kickstart 2.x ROMs can run various AmigaOS 2 versions and Kickstart 3.1 can run versions of AmigaOS higher than 3.1. All later versions just patched Kickstart 3.1 once booted.

Or did they actually sell new ROM chips that you soldered onto your Amiga after removing the old chip? That sounds kind of crazy.

It was quite common at the time to distribute part of the operating system in ROM. A number of other systems used the same approach. For example, the original Macintosh also has in ROM graphics routines, UI widgets, device drivers, etc. And yes, you could get replacement ROMs from Apple for certain Macs.

ROM chips were often in sockets, not soldered in place, for this reason.

I must be missing something vital about this.

It was to cut costs. ROM is cheaper than RAM per byte - roughly half as much so. If you replace the ROM with RAM, you would need an equivalent amount of RAM to take its place, doubling the base RAM requirements of the base model and probably adding several hundred dollars to the price at launch.

Also, not having to load a quarter megabyte off disk at boot time really speeds things up.

Answer 3

One of the things he mentions is that, unlike all later Amigas, it has no ROM containing the OS. Instead, you had to put in floppy disks to boot it up, loading in the Workbench and whatnot each time you powered it on.

Not quite. One disk contained the 'Kickstart' (OS ROM image) which was loaded into the 'Writable Control Store' when the machine was powered on. The WCS was then write-protected so the machine acted as if it had the OS in ROM, until it was powered down. As with other Amigas of the time, virtually all of the OS was contained in the ROM, including Workbench.

The minimum disk contents required to boot most Amigas is merely a standard 'bootblock' (containing less than 512 Bytes of code) which simply returns control back to the OS. This allows a disk with a 'custom' bootblock to completely take over the machine if desired, providing a consistent method of starting the machine both for hardware-banging games and OS friendly apps.

The 'Workbench' disk contains utilities and optional OS stuff like printer drivers, fonts, and CLI (Command Line Interface) commands. One of the CLI commands is called 'LoadWb', which is a tiny program that simply sends a message to the OS telling the Workbench to open. A minimal 'Workbench' disk only needs this one command to open the Workbench, plus the script file 'startup-sequence' (containing one line, 'LoadWb') if you want to automate the process.

since the very definition of "ROM" means it cannot be overwritten, doesn't that mean that there was a massive downside to all Amigas except for the very first one, in that they were permanently stuck with whatever version of the Amiga OS/Workbench that was current when the machine (or its used ROM) was manufactured?

This sounds unreasonable to me.

It's not unreasonable at all. Having the OS in ROM had several advantages:-

1. Used less RAM. Mask ROM was cheaper than RAM and easier to support in the hardware. In the Amiga's case it was coupled directly to the CPU rather than on the custom chip bus, which eliminates DMA contention and allows the CPU to run at full speed even when ChipRAM bandwidth is saturated.

2. More compact. The WCS board in the A1000 used an enormous amount of board space compared to a ROM. More ICs, more capacitors and resistors etc. made the board much more expensive. When larger ROMs came out they only needed a socket with 2 more pins to quadruple the ROM capacity.

3. Almost instant startup - faster than a much more powerful PC with fast hard drive.

4. More Reliable. No chance of becoming corrupted by disk errors, accidental file deletion, being overwritten by newer files, viruses etc. Automatic 'memory protection' prevents corruption due to errant code, especially important for the Amiga because most models don't have an MMU.

5. Better OS stability. Mask ROMs needed to be made in large quantities to keep the cost down, so there was more incentive to 'get it right' first time rather than releasing a buggy OS and pushing out constant bug-fixes.

6. Fewer OS versions to support. This obviously made it easier for developers because they had fewer configurations to program for and test. It also reduced fragmentation of the userbase because owners were less inclined to upgrade than they might be with a disk-based OS. This was especially important for the Amiga because its userbase was much smaller than other platforms such as the PC and C64, which made Amiga software more expensive and harder to justify producing.

The Amiga was not alone in having a ROM based OS. The vast majority of contemporary 'home' computers did, as it was virtually essential for machines without fast mass storage devices. ROMs were also used in some PCs like certain models of the hugely successful Tandy 1000, and of course the original IBM PC which 'booted' into Cassette BASIC if a disk wasn't present.

Or did they actually sell new ROM chips that you soldered onto your Amiga after removing the old chip? That sounds kind of crazy...

Yes, they did (except the ROM was plugged into a socket - not soldered in) - and it's not crazy. One obvious advantage for Commodore was that it virtually eliminated piracy - which was a huge problem on the Amiga - because for most users it was cheaper to buy the ROMs than 'burn' EPROMs. The lack of piracy meant they could sell them cheaper, and didn't have to worry so much about people pirating the system disks since they were useless without a matching ROM. Customers got a relatively cheap OS upgrade plus all the other benefits listed above. With a ROM switcher board they could instantly switch back for compatibility with older games etc.

But that wasn't always their only option. The A3000 had the ability to soft-kick newer ROMs from disk, and some accelerator cards had a 'map-rom' function which could load a ROM from disk to a specific RAM space on the accelerator card. theoretically any Amiga with an MMU should also be able to do it. For machines that didn't have this ability Commodore produced special versions compiled to run from a memory location in normal RAM. These were sent to developers so they could test their code with newer OS versions before they were officially released. Actual ROMs were generally preferred though because soft-kicking requires a reboot (and slow loading on floppy-only machines) and the relocated version was vulnerable to memory corruption as well as taking up valuable RAM space.

I must be missing something vital about this.

I think what you are missing is that everything wasn't always done the PC way, and not just because the technology wasn't good enough. If you are only familiar with modern PCs you may think that having the OS in ROM is silly, but you may be forgetting that many modern computing devices do have their OS in ROM.

The difference today is that the ROM is FlashROM which is programmed in-circuit via USB or over a network. Of course that has its downsides, such as possible 'bricking' of the device if something goes wrong during an update, opportunity for malicious hacking, and distributing images in an encrypted format to prevent reverse engineering etc.

Another thing you may not be aware of is the penalties PCs take for using a disk based OS. Only a few years ago it was normal for a PC to take take several minutes to boot into Windows, even with many optimizations to speed up the process such as caching icons and combining all the drivers into a single file. That is one reason PCs have so many options for sleeping, resuming from disk etc. rather than shutting down completely.

PCs are also famously vulnerable to viruses, worms and other malware that take advantage of the fact that a disk-based OS can so easily be compromised. it's taken an enormous amount of effort to make Windows secure and reliable, yet major disruptions from cybercrimes such as ransomware are still rampant, largely because it's too easy to 'upgrade' the OS in a modern system.

Hard drives fail too, and installing a modern OS still takes ages. Solid State Drives are gaining in popularity largely because they make the OS load faster. But what is an SSD really? It's just a large FlashROM which looks like a hard drive to the system. So modern high-end PCs are running their OS from ROM, just less efficiently.

Answer 4

The question is illogical by definition of a computer. As soon as an unrestricted program can be loaded it can replace any existing OS.

This is true as well for all Amigas. A newer OS can of course be loaded, replacing whatever function is resident in ROM. The advantage of having some OS in ROM is fast startup and low memory (RAM) footprint - leaving more user RAM for application programs. Quite important in a time when one MiB was still a lot of memory.

Using A ROM also made much sense as ROM was cheaper to produce than RAM of the same size. If an OS needs like 256 KiB of RAM, it would already fill up half the RAM of a 512 KiB machine, leaving, after loading some BASIC, not much more RAM available than on some older 8 bit computer. Putting (most of) the OS into ROM turns a machien with the same 512 KiB RAM into a quite generous offering.

The usage of ROM for the OS in whole or parts was done by other computers at the time as well, like Apple MacIntosh, Archimedes or Atari ST. Both featured large parts of the OS in ROM while still loading extensions/patches/configurations from Disk.

In addition, having (most of) the OS in ROM, allowed start and operate from small boot devices, like floppies, thus enabling a modern OS on a computer without a hard drive. After all, these machines (Atari ST, Amiga, etc.) were intended for a lower priced segment than a PC or an Apple Mac.

The method of using ROMs to store large parts of an OS only declined when RAM sizes grew manifold.

Answer 5

All Amiga models having sufficient memory were upgradable.

The Amiga 3000 is a good example: it shipped with an early release of Kickstart 1.4 (version 36) in ROM, which served only to load a more recent Kickstart from the hard drive. The 68030 MMU was used to relocate the loaded Kickstart to the usual 0xf80000 area and make it read-only.

However, especially for developers on other machines, there were options. Developer versions of Kickstart V37 were available relocated to the start of the 2MB memory expansion area on an A500. A program called "zkick" was used to load and reboot into this image. Of course, this Kickstart image was not read-only since the 68000 CPU had no MMU.

Answer 6

Each AmigaOS release is divided into:

1. a ROM-based part — called Kickstart — and

2. a disk-based part — originally provided on two floppies labeled as Workbench and Extras, but in later versions, expanding in scope and spanning over more floppies.

The ROM-based part consists of:

• hardware initialization routines
• system diagnostic checks
• bootloader code
• a multitasking kernel (called Exec, from System Executive, and controlled via exec.library)
• a bitmap font engine and the default system font (Topaz)
• device drivers for accessing block devices
• filesystem driver
• a library providing functions for drawing 2D graphics (graphics.library)
• a GUI toolkit called Intuition (intuition.library)
• a text-based console window (terminal emulator)
• a command-line shell running in the above
• a mouse-driven, GUI file namanger and desktop environment called Workbench
• ROMWack; the system machine language monitor / debugger
• other bits and pieces

The disk-based part contains:

• most of the command-line commands (so-called AmigaDOS commands)
• more system libraries
• more fonts
• more device drivers
• various system tools and utilities

The files on the Workbench and Extras floppies allow formatting and preparing customized, bootable floppies for floppy disk drive-based use of the system (which is what many Amiga owners settled for due to HDDs being expensive), or bootable HDD partitions (if an HDD was available).

---

Since all the most important “core” parts of the OS come in the Kickstart ROM and are available almost immediately upon power-on, you can boot up to some kind of a working system relatively quickly.

You still need to boot from a block device such as a floppy or an HDD, though: upon-power on, the bootloader code in Kickstart waits for a bootable block device to appear, and wants to boot from one, before it lets you actually interact with any of the system.

A mere bootblock on an otherwise empty, formatted floppy disk is enough to drop you into a basic AmigaDOS shell (a command-line environment contained within a console window) although you also need to have some disk-based commands available for this to be useful.

In order to launch Workbench — the windows and icons-based desktop environment / file manager — you needs the disk-based LoadWB command which calls the necessary library functions from the Kickstart ROM to launch this environment.

The GUI toolkit itself (Intuition) is available regardless of whether you launch Workdbench or not, and e.g. runs the shell windows.

AmigaOS programs always operate in a bitmapped graphics mode. The system software (or indeed, the video hardware) does not know or recognize the concept of a separate “text mode”. That said, you can of course simulate a “text mode” by crafting a program or a shell setup that opens up in a full screen mode, with no window borders, and uses a monospaced font.

---

So what does this mean from the perspective of OS updates?

It means you’d buy an OS update and receive a new Kickstart ROM chip, to replace the original, socketed chip on your motherboard (no need to solder anything). You would also receiva a new set of floppy disks, with new versions of the system files and utilities on them — relying on the new Kickstart ROM.

New OS releases were a major event. There was no culture of constant patches and updates — and also no common delivery channel for such updates. This was how it was with all microcomputer operating systems in the pre-commonly-available-Internet times. You used a single release version (usually the one that came with the machine when you bought it) for a long time. It could take several years for the next OS release to appear — and even then, you might not have felt a particularly strong need to update if everything was working fine with your current setup.

---

The A1000 (which, in its original configuration, always required loading the Kickstart from a floppy after a cold reboot) and the early A3000 units (which had a similar but more advanced bootloader which supported not only floppies also allowed loading the Kickstart code from the HDD into protected memory and choosing between two versions of Kickstarts at boot) were exceptions.

The other Amiga models came with a ROM-based (but socketed and therefore upgradeable) Kickstart.

The Amiga models which originally loaded their Kickstart from a block device could be upgraded or modified to use a ROM-based Kickstart, instead. Modifying the A3000 to use a ROM-based Kickstart would have released the user 512 kilobytes of RAM for other purposes (running applications).

On the other hand, the Amiga models which had a ROM-based Kickstart to begin with could be set up to boot into a minimal OS installation at cold start with the ROM-based Kickstart, and then launch another Kickstart from a file, rebooting the machine into this later OS release. This was popular, too, but required 512 kilobytes of RAM to be sacrificed for RAM-based copy of the Kickstart code and was never officially supported by Commodore.

---

For a mere gamer, especaily one using a floppy-based system with no HDD (HDDs and HDD controllers were expensive), the AmigaOS version did not usually matter much since they would only boot games on their system and games would generally come on bootable floppies and work even with the older Kickstart ROMs.

The AmigaOS version mattered more for a hobbyist-tinkerer or a user of productivity software, especially one with an HDD, since the later releases of AmigaOS supported HDD usage better and later versions of productivity software also generally required a later version of the AmigaOS.

---

Last but not least,

• You could theoretically update the disk-based system commands and tools to later versions without updating the Kickstart ROM so long as the updated commands used ROM-based system libraries in a way that remained compatible with the the esisting Kickstart ROM (I think Workbench and Extras disks from AmigaOS 1.3 were usable on a machine with the Kickstart 1.2 ROM, at least?)

• You could install alternative, enhanced replacements of many system tools and utilities made by 3rd parties (case in point: ARP, or the AmigaDOS Resouce Project, which provided enhanced replacements for many standard AmigaOS 1.3 system commands), usually distributed via the file areas of dial-up Bulletin Board Systems and via the FTP servers found on the (then-academic and not generally publicly-accessible) Internet.

• Commodore themselves did provide a SetPatch command which could patch any bugs found in particular Kickstart ROM release by redirecting those system library calls to RAM-based, fixed implementation. So even though the Kickstart code was technically ROM-based, it could still be patched and modified when needed. (There were also 3rd party patches or enhancements using a similar technique.)

Answer 7

Though others have covered the KickStart upgradability of the Amiga line fairly well, there is one aspect of this that I haven't seen covered that warrants a mention: The A1000 could only physically be upgraded to KickStart v1.3.

To briefly recap, the Amiga 1000 did not originally ship with a full KickStart ROM, but rather just enough to load one off of disk and store it in the WCS daughterboard RAM. Later revisions of the A1000 had socketed KickStarts as did all of the later Amiga models (save the early A3000 release covered elsewhere in this thread).

The thing to note, however, is that original A1000 only allowed for a 256KB KickStart ROM because the WCS daugterboard only had 256KB of RAM on it. While this was sufficient for the 1.x versions of KickStart, starting with v2.x the size of the ROM doubled to 512KB. As such, you could not load v2.x or 3.x into the WCS and thus stuck with v1.3 at the highest.

That being said, I believe there were ways to install later versions of KickStart ROMs into the A1000 (Phoenix and some other add-ons or modifications). As well, I believe it was possible to load a newer ROM from disk and "rekick" an A1000 that has enough RAM installed. However, I've never done this personally.