Hacker News Reader

Comment by johnklos | Hacker News Reader

This is an excellent way to preserve classic machines. There are lots of projects out there for new PCBs, new accelerators, new replacements for Amiga custom chips and so on, just as there are new updates to AmigaDOS (up to 3.2.1, which was released last year). For example:

https://github.com/endofexclusive/deniser

https://github.com/LIV2/Bluster

https://github.com/jbilander/ReAgnus

https://www.tindie.com/products/bobsbits/a500-amiga-500-repl...

https://github.com/terriblefire

Add the PiStorm, and you've got multiple ways to keep old hardware running while enjoying advantages of new hardware.

Lots of people are too young to remember using Amigas, but any programmer of modern systems could learn lots from seeing firsthand how incredibly efficient Amigas are.

View on HN

> 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).

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, 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.

> 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.

>(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 :-)

> 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.

> 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.

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

>deniser

GPLv2, OSH, great.

>Bluster

CERN OHL 1.2, OSH, great.

>ReAgnus

CC-By-SA. Not the best license for hardware, but technically OSH. Good.

>A500++

I understand directly based on A500+. Might be legally dodgy. But it is good that it exists, for preservation.

>TerribleFire

Mix of licenses in their projects. Some of them are OSH (great).

But some of them are not, due to restrictions on commercial use and/or derivatives.

From the above, I gather the one remaining big item that's not yet covered is the PAULA chip.

It seems we're getting close to an open hardware chip-by-chip whole ECS Amiga remake.

yup, the community is really coming together over this. I'm shocked and happily surprised. :-)

There are gary / buster drop-ins now too. Super Buster has been talked about for Zorro-III, but yeah, the AGA and A3000 glue logic stuff hasn't yet been dropped in.

>From the above, I gather the one remaining big item that's not yet covered is the PAULA chip.

I think Minimig has had a GPL'd Paula implementation for like 15 years.

Sure, it has. And minimig is great.

But minimig is a standalone whole-amiga replacement. It is not a replacement for each individual chip.

Paula has many functions, but some of them involve interfacing the analog world (floppy controller, UART, Audio). While a starting point, I don't think minimig's Paula is ready to go.

Reply on news.ycombinator.com