AmigaOS's way

[OSMAN]

Hi!

Could you tell me how AmigaOS handled things (compared to Linux or Windows)? I'm interested, because I've never used Amiga and I am wondering how could it be 32bit system with so big step in technology at 80s!

(And I think I'm going to use it as an example for my OS; is there any reasons why shouldn't I do so?)

[Pype.Clicker]

just before solar gets it, could you be more precise at what "things" you're interrested in ?

[OSMAN]

Memory management, device management, directory formula, scheduling algorithm, etc. what comes to your mind.

[Solar]

;D ;D ;D

AmigaOS in a nutshell:

Microkernel architecture making for clean APIs; efficiency came from simplicity (static priority round-robin best-effort) and complete lack of memory protection - any message, no matter the size, was merely a 32bit pointer. On the downside, bugs and malware could kill / corrupt anything, and memory fragmentation was an issue. There were, however, mechanisms for virtual memory, but not generally used.

It was not rooted in any previous systems like AT&T Unix or MS-DOS; designed from ground up as end-user oriented system both for gaming and office work. That resulted in stuff like long filenames, clean on-disk file layout, and concepts like external app localization, long filename support, datatypes etc. that did grow on the drawing board instead of evolving in the wild.

Being designed as dual GUI / CLI system from the start meant that everything - including driver installation, mounting of drives etc. - had to be possible both ways, and comfortably so. I believe this made many a designer think twice about how to do things, and resulted in better user interfaces to the system.

In comparison to Linux, the whole system was designed, implemented and supported by one party, instead of cobbled together from stuff originating from hundreds of projects, each with their own ideas about How It Should Be Done. To the end-user, AmigaOS (up to and not including v3.5) was a single functional block. You delved only so deep as you were interested (and competent) to delve. Behind-the-scenes knowledge was not required to get it running. (Running on a very well-defined set of hardware only of course helped.)

In comparison to Windows, AmigaOS never tried to reinvent itself every other release. Sure, it generated sales for Windows to introduce another set of RDBMS API on every release, but it didn't help complexity. AmigaOS started on a very high level, and evolved very casually. (Commodore not really believing in AmigaOS as an office / mainstream OS and neglecting it left, right and center, again, helped things.)

The makers of AmigaOS also had the guts to go their own ways, instead of merely stealing other people's ideas. Many concepts I have yet to see in other systems, as they cling to inferor but popular workarounds for problems that AmigaOS solved beautifully.

I'd suggest getting yourself a copy of Amiga Forever (Amiga Emulator), toying around with it (it has some apps preinstalled), and finding out for yourself. Some of the concepts don't become apparent just by someone mooning around over it.

Bottom line: More precise questions get more precise answers.

[Solar]

• Memory management: Unprotected, non-virtual adressing, non-paging. (Amiga PC's of the 68k generation didn't have a MMU.) Binaries came in "Hunk" format; upon loading, a place in RAM would be found for each hunk, and relocation applied where necessary (68k does support PC-relative adressing). When processes ended, the memory would be returned to the free list. As said before, fragmentation was an issue.
• device management: Drivers were "special case" libraries with a standard API. As memory was unprotected, there was no "supervisor mode". A specific drive / device was activated through a device "mount list" that passed parameters to the driver. You'd e.g. have the mount list "CD0" that adressed the driver cdrom.device that tunneled through scsi.device. (Any drive was considered SCSI in AmigaOS; IDE interfaces came only later, and made IDE / ATAPI devices "mimic" as SCSI.) You could "execute" the mount list from CLI, by double-clicking it from the GUI, or placing it in a special "startup" drawer to have it activated at boot time.
• directory formula: Not sure what you mean here. Drives had a name terminated by colon, directories were seperated by slashes. Whatever device was used for booting had an aliased name "SYS:", system directories included SYS:C, SYS:Libraries, SYS:Prefs, SYS:Tools, SYS:Devs, SYS:Storage (for dormant drivers), SYS:Classes. Each drive had a "physical" name (i.e., "ZIP:") defined by the mountlist, and each medium had a "logical" name ("MyZIP01:") defined upon formatting. You could access a medium by either logical or physical name (very useful for scripting). Any directory could be given an alias (SYS:Libs and LIBS: was the same; C: included SYS:C, SYS:Prefs and a couple of others, equalling $PATH / %PATH% on Linux / Windows).
• scheduling algorithm: See above. Static priority round-robin, with priority given as signed char (-128 to 127, 0 being default, higher number == higher priority). Setting user processes at 5 or higher got your system into trouble (some system tasks ran at 5), lower ones left more CPU for critical apps.

Hope that helps.

[OSMAN]

Thanks.

I thought that AmigaOS would cost even the emulator is free!
That's why I haven't got it.
Hey, but if it's free, I'll get it right away

[distantvoices]

@solar: I just wonder - has Thomas Detert ever composed music for Amiga Games?

That scheduler 's made the performance of the OS pretty crispy. I've seen amiga os in action in former times - playing star wars I with a friend, playing pirates! with another one, hurrying the turrican guy throu masses of monsters too ... or this famous dragon tale game where you instructed the character with mouse movements or joystick moves about what to do next.

Ahhh ... but still, the sound of the c64 sid chip 's never been beaten. *gg* Just compare modern versions of clystron tunes with the original.

stay safe ... *oh nostalgia*

[Solar]

I thought that AmigaOS would cost even the emulator is free!

You are right on both accounts.

The emulator is free, the AmigaOS files aren't. You can download (Win)UAE anywhere, but you have to pay a license for the AmigaOS files (and the kickstart ROM image). That is why I recommended AmigaForever, because it comes with fully licensed copies of AmigaOS (both old versions and new) as well as a couple of applications pre-installed.

[OSMAN]

I am using Linux and I want AmigaForever, but its site won't let me download it, it just goes between the pages!

How can I get it (for free)?

[Solar]

Amiga Forever is a package of various Amiga emulators and licensed versions of the AmigaOS files.

Again, you can get the emulators for free - e.g. from the UAE homepage - but you still need the AmigaOS files and corresponding Kickstart ROM image. Those are not for free. The most convenient way to get hold of them is, again, the AmigaForever package. In the Online Shop click on "Buy Cross-Platform" and follow the instructions.

[Crazed123]

If you want something Amiga for free, you could try AROS.

http://www.aros.org/

Amiga Research Operating System

[OSMAN]

I tried AROS.

I downloaded the 20Mb image, burnt it to disc, booted, and
just a blank screen with cursor appeared after grub!
Why?

[Solar]

That question is probably better asked in the AROS forums...

[distantvoices]

http://aros-exec.org/

might help

[Solar]

Perhaps you are at this point (from AROS user documentation):

In either way, you are faced by the already-infamous input prompt (sorry, we don't have a "Workbench" - yet).

Note that AROS is still very incomplete, and in some regards does not behave like the original. (The shell, for example, is case sensitive - yuck!)