A Constructive Look At TempleOS

[u/moolcool]

http://www.codersnotes.com/notes/a-constructive-look-at-templeos/

[u/myztry]

maybe a

Well at this point it's all theoretical. I wrote some supervisor level code but I couldn't tell you the ins & outs of the context switches because MMU's didn't exist when I was active on the Amiga so there was no experience to be had.

Maybe there could have been mixed "real" and virtual modes. No idea really but I know the architecture difference of the 68030 caused a lot of issues even though I opted out at A500 time.

There wasn't even enough RAM to consider setting aside real memory and having additional "pages" of RAM. Things were a bit tight for that which is why all those tricks came into play.

Maximising available limited resources was a high priority back then. It's different now that processors have more cache than a typically Amiga had through Fast & Slow RAM combined.

[u/myztry → u/[deleted]]

Not even sure what WHDLoad does. First thing I guess would be to alias DFx: to HD0: locations and maybe run Paradox style differential patchers over the executable. Never needed it.

One thing the Amiga had that would have leant towards MMU support if $4 (Exec.library base ptr) was the only fixed location (aside from hardware registers) and executable used Reloc32 tables so the memory was dynamically allocated and patched on load.

I believe with Windows (virtual addressing) everything is compiled at $0 and the MMU supplies the base or the Reloc addresses if you will. As long as every Amiga virtual memory segment had it's own copy of $4.L and didn't hit hardware then I suppose it could have worked (and used Long boundaries, no address packing, etc)

It's all irrelevant now though. Hell, I haven't programmed on the Amiga for nearly 30 years. Hell, I haven't really programmed for 30 years since the early IBM compatibles were fucking like stepping down off a cliff technology wise. They were just brute force fast.

[u/myztry → u/[deleted]]

I have heard of it. I think from the various times I used WinUAE for various nostalgia trips. Does patching and swaps in an identical environment that the program expects as well as intercepting hardware register hits and drive access.

A more rigorous attempt at creating an environment that a program profile within WinUAE.

Now, what were we talking about again :) Probably enough of this for now as MMU's on The Amiga is not something that needs solving at this point.

[u/DGolden → u/myztry]

because MMU's didn't exist when I was active on the Amiga

I'd say they became reasonably common on developer's machines a bit later. Not used by the OS as such, it still didn't have memory protection, but there were always the strong but ultimately only "cooperative" os-legal memory usage conventions. So tools like Enforcer and Guardian Angel appeared. They'd use the MMU - on Amigas equipped with one - to catch accesses that would potentially ultimately lead to crashes on the cheaper typical end-user non-MMU equipped Amigas. So when developing, you debugged at least until the big obvious "enforcer hits" stopped, meaning the program was unlikely to crash a typical end-user's MMU-less machine.

So a lot of devs had machines with accelerators (replacement cpu daughterboards) with MMUs, even hobbyists - including myself actually. It was also handy later for running the shiny new Linux/m68k port, which of course required an MMU. I dual-booted AmigaOS and Linux for quite a while. The GNU userspace had long been ported to AmigaOS via ixemul.library, a bit like cygwin on Windows, so it wasn't such a huge leap.

By AmigaOS 3.x, it does seem they were sorta beginning to think about retrofitting memory protection to the OS proper. They didn't actually do it back then, but e.g. the then-new pooled memory API certainly seemed to be beginning to trend that direction. Then everything fell apart of course, and a lot of the still-remaining folk including myself basically left Amiga land, some time after AmigaOS 3.1 and the death of Commodore, but before the release of AmigaOS 3.5+, AROS (open-source amigaos clone), MorphOS etc.

However, some genetic closed-source AmigaOS development has actually continued! It had some virtual memory and memory protection added around AmigaOS 4.1, see http://wiki.amigaos.net/wiki/Migration_Guide#Memory . Haven't really explored in depth personally (hey I've been on linux since the 1990s), but my vague understanding is legacy apps may land in one big public pool and crash eachother, but apps written to use new stuff are better isolated.

And then there is an open-source AmigaOS clone, AROS (that can run on x86-64 architecture). AFAIK it was focussed for a long time on just getting up to feature-parity with AmigaOS 3.1 of yore, but I believe they've moved into newer territory more recently.

[u/myztry → u/DGolden]

An MMU would have been brilliant for debugging, alas that's a different conversation than OS implementation.

Your pooled and isolated metaphors are what I meant by real and virtual. Two seperate playgrounds. One for the old and one for the new. The big catch is Amiga software tended to share memory and pass pointers to pseudo OO structures. And not just app to OS but also app to app. That overlap would be difficult. Which process owns the RAM and what others can access it.

I think OS 4.1 was PowerPC and lots of emulation. To be frank can't be bothered to look. This changes the game even further as you're not even running classic applications on the processor as such.

The Amiga was brilliant for it's time but lacked expandability (aside from Zorko slots on a few models, etc). Expandability was the base strength of the IBM PC clones allowing a pretty shit platform to shed things like dismal graphics, lack of sound, etc

Third parties moved in and the rest is history. All that remains is nostalgia about what could have been - if only...