[cmrdporcupine]

Yeah if your secret sauce is a chip, with very particular timing and memory behaviour... you've just built in obsolescence. There's no abstracted API for doing the fancy graphics (at least not one used by games, etc), and the whole system is built around sharing the memory bus between CPU and VDP (not going to fly once memory & bus speeds became a fraction of the CPU speed and once cache was a serious thing)... it's just stuck in a grotto.. a neighbourhood that looks fantastic when you moved in but now the next city over is getting a brand new subway system while you're still stuck with an old fleet of busses.

Nevermind Moore's law and exponential improvements... you're stuck even falling behind in very incremental developments.

I also lived through this era, but from the Atari ST side. When I got my 486 it was a feeling of a kind of relenting "sigh" abandoning the 68k and its basic superiority... but economies of scale and the arrival of Linux (I used the very first versions, before the a.out->ELF transition even) made it worthwhile.

[zozbot234]

> the whole system is built around sharing the memory bus between CPU and VDP

Isn't this what "Unified Memory" does in more modern systems? There's nothing wrong with sharing memory between CPU and hardware graphics.

[cmrdporcupine]

We might be able to circle back to this now by putting some portion of memory and video on the die along with the CPU, but that was not going to happen for Atari and Commodore back in the 90s. Motorola wasn't going to shove 128KB or whatever of RAM into a 68k just for them, and even if they did it would have been so expensive

Memory speeds plateau'd while CPU speeds skyrocketed. Almost all the complexities of modern architectures have to do with this. There used to be "no need" for something as funky as L1/L2/L3 caches really because often your memory was faster than your CPU (hence why something like the C64's VIC-II or the Atari ST's "Shifter" are even possible).

Hell there were systems back then that didn't even have onboard registers in the CPU, but used external memory for it (TI's TMS series). The 6502's "zero page" is another example.

You can't do that anymore. The CPU will run many laps around your memory.

Still it'd be interesting to see what Jay Miner would have come up with in the late 90s or 21st century, if he was still around and in the game.

[giantrobot]

Unified memory is more about taking advantage of zero copy access for the GPU. Since everything the GPU wants is already right there there's no need to send it on a trip over a bus into separate GPU memory. Memory bandwidth is of course still important for both the GPU and CPU so that unified memory can be a bottleneck if it's slow or has too few channels.

[Someone]

The combination with “There's no abstracted API for doing the fancy graphics (at least not one used by games, etc)” only works as long as you have a solid unique benefit, and that, Amiga lost fairly rapidly due to Moore’s law.

[fulafel]

It lasted pretty long, especially considering the rate of evolution in those days. It debuted already in 1985, and there were some incremental improvements along the way (first the A3000 and then AGA A4000/A1200 in 1992). After the biggest lead in graphics started to shrink you still had a big user and software user base, multitasking desktop that was far ahead at least until W95, great CLI environment compared to PC stuff, competitive price etc.

[Someone]

> and there were some incremental improvements along the way (first the A3000 and then AGA A4000/A1200 in 1992)

About the A3000 Wikipedia says “The machine is reported to have sold 14,380 units in Germany (including Amiga 3000T sales)”, and about the A4000 “The machine is reported to have sold 11,300 units in Germany”. Both were on sale for about 2 years.

In comparison, the A2000 sold 124,500 units in Germany, again according to Wikipedia, in the about 4 years of its commercial availability.

So, about a 80% decline in sales per month, in what I think/guess was an expanding market for personal computers.

⇒ I don’t think those improvements made much of a difference.

[gpderetta]

3000 and 4000 were "high end". The 1200 was the 500/600 replacement with AGA and sold relatively well.

[vidarh]

The A3000 was more than twice as expensive. The A4000 even more expensive. They were not mass market machines.

Variants of the A2000 continued in the market after the A3000 was released, such as the A2500, so people who didn't need the upgrades - or could make use of them (e.g. the VideoToaster didn't fit in the A3000 case without modifications) would continue to buy cheaper models.

[fulafel]

.. And the 1992 Amiga 600 and 1993 1200 sold 193k/95k. The volume was always in the A500 form factor machines that used a TV as the display half the time.

Commodore's focus on low cost stuff (in their own way) while PC clones managed to push the HDD+SVGA setup price down was a critical factor for how things turned out I think. In the high end there was also Apple, Macintosh had launched a year before the Amiga and made the professional GUI market harder to enter.

But the fateful focus also let the masses have access to a great hacker's computer growing up, without the vibe satirized by "Office Space" that marked the Microsoft platforms.

[actionfromafar]

Commodore operations were very, very poor, too.

If they had been smarter with money, I'm sure they could have innovated in many many ways without giving up on backwards compatilibity. Sony put a PS1 inside the PS2. The Sony MSX2 contained an MSX1-on-a-chip.

Amiga could easily have had a PCI bus for external video chips.

And I'm not even going into the more crazy PS3-like ideas like "so, memory and bus speed are just a fraction of CPU speed? Ok, here are 32 parallel CPUs with their own chunk of the VDP bandwidth and their own local memory".

[vidarh]

The last iteration of the Amiga chipset Commodore worked on when they went bankrupt (Hombre)[1] was intended to be a 2-chip system providing a 64-bit 3D chipset with a PA-RISC CPU on-die in the in one of them that'd break compatibility, and be used for both standalone computers, set-top boxes and for a high-end graphics card.

To sort out compatibility, the idea was for an "AGA Amiga on a chip".

I'm not convinced Amiga-users would've been all too happy with all of this - or that PA RISC was a good choice, given what we know now -, but it certainly would've been a massive upgrade.

(What Commodore was close to completing when they went bankrupt, though, was AAA[2] - which would've seen far more modest but still significant upgrades, like wider buses, support for chunky graphics modes, higher resolutions, far higher video bandwidth; AAA was in testing when Commodore failed)

[1] https://en.wikipedia.org/wiki/Amiga_Hombre_chipset

[2] https://en.wikipedia.org/wiki/Advanced_Amiga_Architecture_ch...

[TheAmazingRace]

Did you ever use MiNT on your Atari ST when it was relevant? I understand that for some folks, MiNT was kind of the gateway drug that often led users to Linux on PC shortly afterwards.

[bregma]

MiNT and a 16 GB hard drive with all the GNU tools installed. It was just like the Unix at work.

Linux came later after also going through AIX, HP/UX, A/UX, AT&T SVr4, SunOS, Solaris, OSF/1, ISC, ...

[TheAmazingRace]

I presume you mean MB and not GB? On native Atari hardware at least, you could only address up to 1 GB partitions on the very last TOS 4.04 based systems like the Falcon.

[bregma]

Yes. nobody had GB drives in those days. The drive I had on my ST was a 16 MB SCSI drive and the CPU ran at 8 MHz. The IBM XTs that were so popular at the time only had 10 MB hard drives and ran at 4.77 MHz.

[cmrdporcupine]

Yes, that was indeed the gateway. Among others.

Though my ST only had 1MB of RAM and a floppy, no hard drive. On that I ran a UUCP node to get email and news for a while. And some unix-like shells (Mupfel, I believe was one? Gulam was another great one). I did use MiNT a bit but the whole GNU toolset was a bit big for a floppy system, and the multitasking was only somewhat useful. You could get a unix-like environment without going fully MiNT.

The big jump for me was having a 200MB HD in my 486 when I got it. Massive life change.

[spogbiper]

its easier to see this in hindsight. the amiga was basically just using the model that every previous home computer had used, expecting game devs to use the hardware directly like they had been doing since the first home PCs. wasting resources on an API or any kind of abstraction was for user level BASICs and similar, not for professional games

[cmrdporcupine]

I was not a big Amiga user, but on the Atari ST we had a graphics abstraction API (VDI) from day one. Had the notion of a virtual device and drawing surface. All done through a proper syscall TRAP system, too. I am given to understand that the AmigaOS syscall API was in the form of JMPs.

So when the Falcon and TT Etc came along with full 16-bit 256 colour SVGA-like graphics, anything properly written GUI "just worked"

Games and the like, yes, had to fall back to a video compat mode.

[actionfromafar]

It used JMP, but you looked up the API base addresses from a fixed address, ($4 IIRC) so it worked basically the same. But only like some turned based games, and like some chess games etc used that API. The rest maybe used the APIs to allocate a screen but they were banging hardware after that. Most didn't even use the OS even to read the keyboard, which became an annoyance on the A600 which lacked some of the keys.

[cmrdporcupine]

I mean the advantage of the TRAP approach is more amenable to supervisor/user mode switch and memory protection and the like?

Separate topic from graphics and device independence though

[zozbot234]

The original Amiga platform had no MMU, hence no support for memory protection or virtual memory addressing. Some Motorola processors included it (the 68030 and up) but these were only used on high-end Amigas that were not the most common platform, and are more comparable to contemporary workstations. The AmigaOS just used the single address space approach, that's not necessarily incompatible with protected memory.

The Intel 80386 and its successors were quite exceptional in being "killer micros" with a workstation-class feature set for the time.

[actionfromafar]

Memory protection was basically impossible or at least "Research Level Hard" on the Amiga, because of how the OS was designed with linked lists and message passing of pointers. This was what made it so fast, but at a cost. (They would have needed something like Rust to balance that.)

Everything could have been fixed with the March of Moore. The OS could have gotten a hypervisor and been running each program in its own "VM" thinking it was the only program on the machine.

[cmrdporcupine]

Later iterations of OS extensions on the ST got memory protection support, albeit a bit inconistently and with likely backwards compat problems. FreeMiNT I think supports MMU + protection on 030 machines.

Achilles heel for classic MacOS, too. Sins of our fathers.

[zozbot234]

> So when the Falcon and TT Etc came along with full 16-bit 256 colour SVGA-like graphics, anything properly written GUI "just worked"

> Games and the like, yes, had to fall back to a video compat mode.

The Amiga had retargetable graphics too. No real difference there.

[actionfromafar]

Yeah. It was very much the same with DOS games, too.