5 ms·
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
by cmrdporcupine 1y ago
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.
- TheAmazingRace 1y agoDid 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.
- cmrdporcupine 1y agoYes, 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.
- bregma 1y agoMiNT 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 1y agoI 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 1y agoYes. 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.
- spogbiper 1y agoits 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 1y agoI 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.
- zozbot234 1y ago> 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 1y agoIt 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 1y agoI 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 1y ago> 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.
- Someone 1y agoThe 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 1y agoIt 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 1y ago> 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 1y ago3000 and 4000 were "high end". The 1200 was the 500/600 replacement with AGA and sold relatively well.
- actionfromafar 1y agoCommodore 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 1y agoThe 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 https://en.wikipedia.org/wiki/Amiga_Hombre_chipset [2] https://en.wikipedia.org/wiki/Advanced_Amiga_Architecture_chipset https://en.wikipedia.org/wiki/Advanced_Amiga_Architecture_ch...