I try not to be /that Amiga guy/, but every time I dip in to a little Amiga history it leads me deep in to a rabbit hole of things that still amaze me.
Thinking about storage now…
My favourite drop in disk hack was probably diskspr¹ to store 980k on a double-density disk, which worked by replacing trackdisk.device².
And awesome libraries like xpk³, which allowed you to add aftermarket compression/encryption support to applications. Looks like people are still writing modules too, including LZMA⁴ support(although I can't begin to imagine how slow that would've been on my Amiga ;).
Argh, that link is cringeworthy. Amiga wasn't killed by piracy, but rather committed suicide thanks to atrocious commercial and stategic moves by Commodore's various owners. The DOS market had the same amount of piracy and none of the hardware manufacturers had any problem surviving.
The Amiga had emulators to run DOS and Mac software. Sort of the OS/2 effect where they ran DOS and 16 bit Windows apps so there was no need for native OS/2 apps.
Commodore had a nickle and dime marketing plan and made PC clones as well. The Commodore 65 was going to be the next 8 bit C64 type computer after the C128. But it never got out of prototype.
Mac and DOS/PC tech caught up to the Amiga around 1987-1992 and Amiga could not make a newer chipset in time to compete with them.
The Amiga was like the Mac but with true preemptive multitasking and 1/3rd the cost of a similar powered Mac. Amiga didn't earn a lot of money with the Amiga because they lowballed the price and Apple won because they highballed the price until Steve Jobs could come back to fix the company. Amiga had no Steve Jobs savior and went out of business because the DOS/PC cut into their sales too.
You are not wrong, but of what you mentioned only "nickle and dime" and "could not make a newer chipset" is very relevant. They never invested back their gains into Amiga R&D.
What they should have done:
kept Amiga extensible - kept the external bus when cost optimizing the A500 into the A600. (Instead the A600 was a crippled, slightly incompatible A500 that split the market and made it slightly less interesting to game developers.)
The chipset in A1200 and A4000 was too little, much too late. The A1200 was a case study in cheapskating and crippling an already anemic CPU. (It came with a disabled L1 cache. If it had only had 64 kilobytes of more RAM, they could have enabled the L1 cache.)
Should have partnered with SUN and made SunOS (Solaris-to-be) for high end Amigas, more powerful than what they ever produced. (They basically said "fuck you" to SUN.)
Etc etc.
It could also have helped to buy fewer business jets for the CEO, but I think that was more of a symptom of what was wrong. If they had done fewer completely idiotic moves, they could have afforded a few jets easily.
Right on the money. The platform became too expensive for the home market and too cheap for the pro market, with ridiculously low (and expensive) expandability. There were distribution and manufacturing issues, and they treated their R&D in such a shocking way that inevitably pipeline and products suffered badly. Managers were old-world two-bit sharks who treated the company like a cash machine. It was tragic and completely avoidable, and had absolutely nothing to do with piracy. If anything, piracy kept alive an ecosystem that had no business existing, there and now.
AmigaDOS was developed on SunOS Workstations that were modified.
I don't think the Zorro bus was as good as ISA or PCI and the A600 was like you said it was. The Amiga needed a networking adapter to work with networks and Apple Macs later had them as default or via a NuBus slot.
Plus most of the software for the Amiga was video games which limited the system to video games it needed more business software.
Zorro-2 was superior to ISA in pretty much all ways that count. It had auto configuration and just worked in general.
PCI is vastly superior to Zorro-3 though, in both features and performance. Z3 never achieved the performance given in the specs and had quite some problems. IIRC Dave Haynie said that he would have used PCI instead of developing Z3 if it had been out at the time.
There's no need to "think" about it. Even old 16-bit Zorro had DMA and plug-and-play, which actually worked. ISA was a shit-show and often 8-bit wide, too. All PCs at the time needed networking adapter for Ethernet and the Mac network was dog slow. (I won't go into the software side, I don't have time right now.)
I prefer to tell people amiga went out of business because they built the best computer in the world, and decided close down so everyone else could have a fair chance.
That's because PCs were at the heart of the business world. The Amiga was mostly a machine for entertainment and hobby use.
Due to this fact, piracy on the Amiga had a much larger impact on the platform than on the PC.
The final nail in the Amiga's coffin, of course, was the arrival of 3D: the Amiga couldn't play Doom (at that time), and so it quickly became the inferior gaming machine.
Most PCs couldn’t play Doom either, but they could be extended pretty cheaply with a better graphics card. That is what made the difference on the gaming side. The Amiga was kneecapped by mismanagement of its commercial side, including substantial opposition to third-party add-ons at a time when the PC side had standardized and unleashed the taiwanese.
In the pro market, Commodore didn’t even know how to play - they treated their machines like toys. Despite this, for a period, if you wanted to make music you bought Atari, if you wanted to do publishing you bought Apple, but if you wanted to do TV and FX you bought Amiga.
That first part isn't right. Doom was entirely CPU-bound software rendering, and 3d rendering cards didn't exist yet. You couldn't upgrade a 386 or 486 PC to play Doom better, short of replacing the entire motherboard with a new CPU platform.
What you're saying was fairly true by the time of QuakeGL and Quake 2 around 1997, but not Doom in 1993.
> You couldn't upgrade a 386 or 486 PC to play Doom better, short of replacing the entire motherboard with a new CPU platform.
Yes, you could; CPU+chipset (and, in some cases, + RAM, IIRC) processor upgrades which plugged into an expansion card (to power some of the support hardware) and the processor socket existed.
No amount of VGA, ram or HD upgrade would help with Doom. The difference between absolutely the worst 8bit ISA VGA cards (Realtek, RTG) and one of the fastest 16bit ones (ET4000) was 1-2fps on 386DX40, a whooping 10-30% of overall unplayable unless you are really stubborn <10fps performance.
The way you made Doom playable was swapping motherboard/cpu/ram/vga for a 40-66MHz 486/localbus ones at a cost of multiple A1200s, not exactly what one would call 'extended pretty cheaply'.
See also https://en.wikipedia.org/wiki/Professional_File_System which had a slightly different method of maintaining integrity. The filesystem metadata state would atomically change when the root block was updated, with all the actual changes being written to free space until then. You could do a load of writing, and hear the hard drive chugging away. Then it would finish, wait a second, and the hard drive would go "click", which was the atomic root block update.
It also had a rather interesting feature for log files, where you allocated a set size, and any appending onto the end of the file that made it longer would discard the part at the beginning of the file, without allocating any new space.
> It also had a rather interesting feature for log files, where you allocated a set size, and any appending onto the end of the file that made it longer would discard the part at the beginning of the file, without allocating any new space
The "Disk Doctor", as shipped with AmigaOS versions 1.2-2.04 was both a crude and cruel tool.
Its primary purpose was to "restore" a damaged volume to a state which enabled read-access, allowing you to copy the data to a different volume. At the time most users (myself included) viewed it as a repair tool which should have been able to restore a damaged volume to operational state again. You needed a second floppy disk drive to be able to copy the data to a different disk which was a rare thing to have in the old days. So we settled for what should have been a "fix in place" repair operation, but in reality "Disk Doctor" never left a volume in a better state than it was before, even if the file system structures had been sound to begin with.
The reasons why the "Disk Doctor" was so bad at repairing anything are legion.
For example, if a track could not be read because of a flipped bit or physical damage, "Disk Doctor" would attempt to restore the entire track to a sane state by reformatting it (physical low-level initialization). The "Disk Doctor" uses the same buffer for reading and writing data, which means that when it reformats a track, it will (as a side-effect) write the data that was last read back to disk. That data was written to a different track, and if it happened to contain file system data structures, then "Disk Doctor" would later pick them up and try to make sense of them: it was basically "fuzzing" itself.
Part of the diagnostic operations performed prior to "repair" was to detect damaged or deleted file system structures, such as files or directories which no longer had a valid parent directory ("orphans"). The "Disk Doctor" would gather these and add them to the root directory. It did not check if there already were files or directories present in the root directory which shared the same names, which could have the effect of corrupting the root directory. You might be able to list the root directory and find several files with the same names stored in it, but accessing these would only go as far as the first entry in the directory entry list.
When trying to recover the "orphaned" directory entries the "Disk Doctor" made no attempt to verify that the files and directories it added to the root directory were structurally sound. You could have ended up with fragments of files which were deleted ages ago and whose parts had been partly overwritten since they had been deleted. These broken file data structures could reference data and metadata blocks, which in turn would then break the disk validation process.
Thinking about storage now…
My favourite drop in disk hack was probably diskspr¹ to store 980k on a double-density disk, which worked by replacing trackdisk.device².
And awesome libraries like xpk³, which allowed you to add aftermarket compression/encryption support to applications. Looks like people are still writing modules too, including LZMA⁴ support(although I can't begin to imagine how slow that would've been on my Amiga ;).
1. http://aminet.net/package/disk/misc/Diskspr3#contents 2. https://wiki.amigaos.net/wiki/Trackdisk_Device 3. https://www.dstoecker.eu/xpkmaster.html#Overview 4. http://aminet.net/package/util/pack/xpkL2XZ