Hacker News Reader

Comment by Jupe | Hacker News Reader

> but any programmer of modern systems could learn lots from seeing firsthand how incredibly efficient Amigas are.

Agreed. Much of the Amiga's OS was quite elegant in my opinion. Everything was reachable by a linked list. Start with AbsExecBase (0x00000004) and traverse the linked lists from there to find virtually anything/everything. (Intution objects included).

If it wasn't for bit planes and lack of memory protection, I think it would have had a fighting chance (oh, and if not for C= incredibly horrific management).

View on HN

>(oh, and if not for C= incredibly horrific management).

I believe that to be the real, non-surmountable problem.

Newer generations with better hardware and memory protection would have been totally possible.

Virtualization could have taken care of backwards compatibility.

Some practical modern examples include:

- Whdload, which patch and wrap floppy-booted games so that they can run from the harddisk, allowing for returning back to multitasking when done, with optional MMU protection.

- AROS, an AmigaOS-like open source OS, which can run classic Amiga software through reasonably well integrated emulation.

- MorphOS, a PowerPC AmigaOS-like OS with similar slick emulator integration.

memory protection would be hard I think, right? The whole OS was based around message passing by just linking a message to the target process message port pointer.

edit: but, as per your other comment, you know that. How do you see protection working in amigaOS? Just share the pages that are needed for messaging and protect everything else?

A flag day would be needed. This means literally breaking the ABIs. New interfaces would take care of setting up shared memory or doing cross-space copying.

There's always ways to deal with old software, such as through virtualization.

that's why the later OS releases after amiga/commodore imploded extended some of the memory APIs to say "This needs to be globally visible". That way you'd allocate message memory in globally accessible memory and the MMU could do "things".

(Not that I'm a fan of that solution, just saying, they had to hack around it.)

https://wiki.amigaos.net/wiki/Exec_Memory_Allocation

(I don't do later amigaos things though :-)

Obviously, the lack of memory protection was what enabled the global AbsExecBase implementation to begin with. I guess it would be possible to implement as a shared read-only page mapped into each process in a protected environment, but not sure about how the details would look.

Of course the highly integrated custom chips were also a great thing to have, and made very low-level programming fantastically easy and powerful. The OS was great, but there was also the almost parallel universe of low-level programming. When you hit the bare metal on an Amiga, it sings.

And it sure felt like it had a fighting chance, it was easily the best computer platform for a number of years. Oh to be young again, and so on. :)

> I guess it would be possible to implement as a shared read-only page mapped into each process in a protected environment

Fun thing, that's exactly how vDSO's work.

>I guess it would be possible to implement as a shared read-only page mapped into each process in a protected environment, but not sure about how the details would look.

The main issue is the passing of pointers to physical memory through exec messages.

Of course, with a flag day and some virtualization to make up for it, it would have been possible to run old software on new hardware and a protected AmigaOS.

> oh, and if not for C= incredibly horrific management

Thanks to that horrific management, the future of the Amiga was dead the moment it was released. No significant update of the OS for five years (KS1.0 in 1985 to KS2.0 in 1990). No significant update of the hardware for seven years (Amiga 1000 in 1985 to Amiga 4000 in 1992). And that was while the IBM-compatible PCs and Windows were going through those years that established their dominance for the next decades.

I remember upgrading to an A3000 from an A500. 1.3 and 2.0 were like night-and-day. The 3000 was a pretty big hardware leap in terms of integration, but you are right, it was still incremental. The chipset, which is what made the Amiga an "Amiga", barely changed.

The 1200/4000 AGA machines were too little, too late. By that time, everyone was getting 386's with SVGA and Soundblasters.

When the original Amiga team left Commodore, the next generation chipset, Ranger, was finished and ready.

But CBM management decided to discard it. But that wasn't, by far, the only time they went directly against the architects' judgement. Like how they later forbid the A3000 team from using a DSP, or the fate of AA+/AAA.

> Everything was reachable by a linked list. Start with AbsExecBase (0x00000004) and traverse the linked lists from there to find virtually anything/everything.

It sounds like this very openness is the problem - all of the benefits of AmigaOS involve processes reading one another's memory, and conversely modern OSs have to put so much effort into protecting the user from apps attacking one another.

The Amiga was ultimately tied to its m68k architecture. No matter what Commodore did, it would have become unviable as the m68k died and was no longer developed. There were other very interesting computers back then, including the ARM-based Acorn Archimedes. But they weren't the Amiga; if anything, they didn't have anything like its huge software library.

>The Amiga was ultimately tied to its m68k architecture.

>No matter what Commodore did, it would have become unviable as the m68k died and was no longer developed.

AROS, Amithlon, MorphOS very much demonstrate in practice how untrue this is.

Not to mention Apple with the Mac: 680x0 -> PowerPC -> X86/64 -> Arm

Reply on news.ycombinator.com