SlimJim's Not-so-short First-Impressions Review of AmigaOS4(Pre) June 12 2004

Introduction

A nice padded envelope arrived at my door this friday and from the title of this review I guess you can all imagine what it contained. After more than a decade after Commodore, the Amiga operating system has reached a major stepping stone, hopefully one that will be sturdy enough to bring this scarred and so far ill-fated system to new heights along with its equally dented and diminished (but still fervently loyal) user base.

The "Pre-" (Developer-) version of AmigaOS4 is delivered in a stiff-paper foldable case that looks very nice and professional. No paper manual is included and since this is just a developer's prerelease there's nothing surprising about that. The text on the CD refers to the installation manual on-disk. I guess the crowd that this release aims to cater for are mostly a more-than-average computer-savvy lot. They also tend to have more than one computer (whether it be a classic Amiga or some other architecture). -- and these things do come in handy when getting the system up and running.

Note that in the following (rather lengthy, I'm afraid) review, I will make comments and pose critique (both good and bad) on the system that arrived in my mailbox. I make these comments fully aware of the "in progress" status of the OS. There is no "politics" involved here (although I'm an Amigan by heart and cannot be considered fully "objective" of course). Any critique should be considered a helpful suggestion toward future developments rather than any belittlement of the hard work gone into this long-awaited release. I'm also in no position to compare AOS4 to the status of other offerings in the market. So I won't.

The JIT Petunia emulator for AOS4 is not included in the pre-release. All emulation of 68k code runs interpreted. Also, the Graphics subsystem is not yet fully PPC native. Full specifics can be found at the usual sites.

Unless noted otherwise, when I write "AmigaOS4", I am always really referring to "AmigaOS4(Pre)".

Installation and the woes of hardware

But first things first. I have an AmigaOne-XE G4 which is by now two years old. It has 256MB of memory and a 60GB hard drive. I have run Linux Debian on it previously, but I must admit that Debian PPC wasn't all that impressive, so most of my Linux work has actually be performed on an x86 box the last few years (boo! hiss!). I have a 4-way broadband router and to this I have both the x86 box, the A1 and my trusty A4000/060 connected. My plan was also to move stuff from the A4000 to the A1 over the network later. Between the A1 and the x86 I share a large 21" monitor through a Level1 KVM switch. In the past I could never get the mouse and keyboard to work under UBoot v0.0.1(worked once Linux was loaded though). So I ended up sharing the screen, but using two sets of mice and keyboards when wanting to fiddle with Uboot.

In the machine I have a Radeon7000 and a Soundblaster Live! card. Both are bought specifically to be compatible with AOS4.

The first thing I needed to do was to check the installation manual. I got the web version off my parallel-running x86 Debian installation and tried to follow it to the letter. In order to update the flashrom, a secondary computer (or booting into your LinuxPPC-installation) is actually a requirement, since you have to create a floppy somehow. Linux reads the AOS4 CD without problems and I got the correct image from it. Using the dd program I was then able to create a floppy. Reboot of the A1 and setup of some commands had Uboot 1.0.0 installed within seconds. Whereas easy in principle, this step would likely throw a newbie, but that's the price of using a "pre"-version. Final versions will not need this step (or at least be self-going without having to use a secondary Linux installation). There are instructions for creating a CD-updater too, as well as update through a network connection. I didn't explore any of those options.

After a by-the-book one-time modification of the Uboot parameters the installation CD itself was now supposed to start up. It didn't. In fact it seemed the system didn't recognice the CD-ROM at all, but instead went onward in the boot-list and tugged uselessly at the harddrive (where, understandibly, no AOS bootable disk were yet to be found). Swithing over to the x86-Linux I checked on the Amigworld amigaos4 IRC help-room, where my settings where concluded to be OK. However, the CD-ROM itself is a non-descript old bugger (NEC 282) and that might be the problem. So I grabbed the nifty Benq 48x16x48 drive from my other machine and tried that. To my chagrain it turned out to be even worse: whereas the NEC didn't like to boot from CD, the drive was itself atleast listed by UBoot. The Benq didn't even go that far. Eventually I turned to the CD in my A4000, a 24x standard thing. And, finally, that one worked nicely. I bet you, for you inner eye, can imagine a rather releived SlimJim when Kickstart finally began to boot!

The installation proceeds in roughly two steps: First, the CD-based Amiga workbench loads and you (after choosing language and keyboard settings) partition the harddrive in Media Toolbox. If the gfx-card has a problem, this is where you'll se it I suppose; for me it worked flawlessly in 800x600 during the intallation.

An interesting choice in the keyboard selector is the tickbox for "Amiga keyboard". I know this will please many people. I suspect an adapter is needed though. I have a bog standard Windows PC keyboard and so haven't tested the classic keyboard support. The CD boot into the same view as you get when you boot from the CD later too. This is usable for rescue work.

Well aware of disappointing people wanting to hear of a dual-boot installation, I too decided to have AOS4 as a single entity on my hard drives as done in other earlier reviews. Media Toolbox is very intuituive and is looking a lot better than in earlier screenshots. I created four partitions; Workbench, Work, Data and Net. The 'Net' one is there due to me wisening up after my old Amiga days; the IBrowse cachenow and then caused the partition to be unvalidated. Better keep such things on its own...

You are also expected to leave some allocated memory on the disk for use as virtual memory. All partitions I created had the new FFS filessytem with long filenames. I have never lost data with FFS before and feel pretty secure with it (but I know others swear by e.g. SFS). After this parttioning it's time to reboot.

An annoying thing with this particular reboot is that there is still no AOS4 to find on the primary boot partition, so the Uboot will stop and trudge on the HD (much like it did when my CD-ROM(s) didn't work). It's a small thing to change the boot order temporarily, but the manual doesn't mention it and it should, for no other reason than consistency.

The CD-based Workbench starts up again and you choose languages/keyboard a second time. First the partitions have to be (quick-)formatted. This is the first real "WB operation" one gets to do - clicking on the icons, selecting from a menu - and I have to admit the Amiga-feeling came rushing back with full force at this point. Installation then flows pretty much without interferrence. And then AOS4 is in place! Overall the installation process feels both robust and secure. My hardware issues are wise to keep in mind though, if people stumble into problems and are sure they really have setup UBoot correctly.

Continuing on the hardware business, I'm sad to report that the Level1 KVMswitch doesn't like the A1 Uboot 1.0.0 at all. I have never been able to abort the upstart while lnked through the switch. Further, whereas Linux PPC at least could handle the peripherals once it was loaded, AOS4 doen't. The mouse doesn't work at all under AOS4 with the switch (I didn't try the keyboard since I already knew it didn't work with Uboot and wanted to retain that capability). The Monitor-sharing works nicely though, so in the end I run two sets of keyboards and mice (three sets if counting the A4000), the same as I did before. Without the KVM switch both mouse and keyboard works well. I am however yet to get the mouse wheel to work at all which is a disappointment. Also, using the Windows keys as a stand-in for the Amiga keys are just plain weird! We need replacement caps, and that fast ...

On the other hand my Radeon 7000 works flawlessly! I have a nice range of screenmodes and can finally utilise some proper monitor estate on my 21" monitor. Also, the soundcard works nicely and the configuration is just a simple requester long. Very nice! Of course I did select hardware among the "safe" AOS4 compatibles, but you never know until you really try it.

After the primary installation was complete, the Workbench: directory held about 60MB (I forgot to check it and have added some large wallpaper directories since, but that seems about right). The SDK is not installed at this point. To get at that, you have to put the CD back in the drive ... but we'll get to that at the end of this review.

Internet

My router supports DHCP, so I could just use the Connection Wizard in the Prefs directory to get stuff going. It ran directly, but oddly enough it set a very short "lease time" on the connection with my router, a time that ended just a few minutes later, disconnecting me. Redoing the Wizard setup and restarting the A1 seems to have solved this oddity, and now it works excellently. No need for Miami anymore, although i haven't checked how secure pages work as of yet.

I ran into a problem when trying to boost my program library -- namely the supplied IBrowse2.3. It has a bug (currently being worked on I hope) that simply crashes the program irreperably when you try to open the Settings. Since i run IBrowse2.3 on my Amiga4000 I know this is usually no problem. Thinking it might be a problem with the demo version, I planned to move my keyfile over from my A4000. First I tried to put it on a floppy only to remember that - alas - AOS4 doesn't recognice floppy drives yet (or at least not mine). So I thought I'd do it by ftp over the network. Now it gets interesting -- it also seems that IBrowse can't download anything from Aminet -- you get a "ftp protocol not supported" error. Not until going to some mirrors where you could download stuff over http, things began appearing on my hard drive. Most clients complain about missing libriaries of one sort of the other, however, and I don't feel like "polluting" the system drawers with stuff just to try and see if it works (don't worry, I'll note my findings on the appropriate lists. You need not shout at me). After wading through a host of various programs I eventually got RC-FTPd to work (the server, not the client) under AOS4. Running AmiTradeCenter on the A4000 made it possible to download safely to the A1. I found that using the (new?) ShowNetStatus command helped to get the FTP going. So now I have a full IBrowse2.3 going. It still crashes heavily when opening the Settings though.

I have now tanked over several gigs of old data from my A4000. I'm yet to find any data being lost in the transfer or any file getting corrupted when moving large files/dirs from my upload dir to another partition on the A1 hard drive. The HD transfer rates are OK (certainly compared to my old Amiga) but it can and will be improved in the future (installing the SDK at the same time as copying the large contribution backdrop directories from CD did bring the system to a crawl though).

Operating system, overall impressions and Quirks

The AmigaOS 4 prerelease sports a very robust system. But it is of course sensitive to failing third-party software. For the two days I've run it (almost 24/7) I have not been able to crash it while performing system integrated tasks (i'm thus not counting IBrowse as integrated since it's not installed with the base pack). The main source of crashes have been trying to start various third-party software. In none of those cases have the system just gone flat down -- there is always a requester giving the opportunity to kill the task, Continue or start the debugger, I'm no programmer, but the potential benefit of having this possibility directly integrated must be vast. Choosing the Kill or Continue button has in almost all instances I've tried (mostly related to games and some other minor programs) caused the program window and requester to freeze up completely. I think I only came upon one instance where the workspace was seemingly cleared of the offending program windows. Interestingly enough such "semi craches" very rarely seem to bring down the system as a whole. I.e. you can move the frozen windows to the side and keep working on other stuff -or at least save your work. This still gives me the impression that when it comes to overall stability, AmigaOS4 is already a very mature system.

Overall, the system talks a lot more to you now than it ever did. For example, when a classic program (notably RC-FTPd) pokes around in system resources in a "non standard" (but non-fatal) way, a requester silently informs you of this, listing the function used. The guru requester (I haven't encountered any black-red screen yet, only normal asl ones) all vary in severity, some let you just kill or continue (or look at it with Grim Reaper) whereas others gives an option to reboot. Another feature I don't remember from AOS3.9 is that the system offers to create drawers for you if a program (even a 3rd party one, like IBrowse) wants them but cannot find it at the designated place. Very simple to use!

The Rebooting is also a topic I would like to touch upon. The first cold-boot goes through Uboot to initialize the hardware. There are thus a short countdown and then a black & white progress bar showing kickstart and all the base components being loaded. Then the screen goes black and after a couple of seconds the workbench simply pops into view, ready to use. I haven't timed the cold start. It's not impressively short considering it's an Amiga but after becoming used to Linux, it's still very good. Now, there is a big difference between this initial cold boot and what happens when you warm-reset the system. The warm reset is done using your normal Amiga-Amiga-Ctrl combination (the different placement of the Ctrl-key on a PC keyboard makes this combination feel oddly akward, but perhaps that's just me.) Testing this, I was surprised that the screen didn't go black directly, as on the old machines (or as when pressing Ctrl-alt-backspace under Linux). Instead there is a clearly noticeable delay of several seconds before the screen flutters out into oblivion. I don't know why this is so, but if it is intentional and not some to-be-fixed bug, there should be some visual indication of what's going on. As it is, one keeps pressing the keys over and over, thinking one did it wrong. Once the warm reset is underway the reset time is impressive though -- within one or two seconds the system is up and running fresh again. Nice.

Here I have noticed a clear effect of the warm reset being a software thing. For the first time in my Amiga usage, the warm reset can cease to function properly. The one time I had an actual system freeze (after trying to "Continue" after a Guru when I obviously shouldn't) the warm reset didn't react at all and I had to reach for the reset button on the case (which is equivalent to a cold reset). This is of course a suspected danger when moving the warm reset from the custom hardware of the old Amiga keyboards to software, but still was annoying.

Furthermore, rebooting has hinted to me another difference in the layout of the new Amiga system: In the Uboot settings, I have set the harddrive to have first boot priority. Rebooting with the AOS4 CD in the drive should- and for cold-rebooting it does- *still* cause the system to start from HD, ignoring the CD. But when *warm-resetting*, that CD is recognized and booted from all the same! This gives me the impression that the Amiga OS is *really* "riding on top of" the hardware. It even has it's own boot device sequence. Although I realise warm-resetting an old Amiga also caused it to auto-boot whatever was in the drive, personally I find this boot behaviour annoying and non-intuitive. I always forget to remove the CD when rebooting and is utterly annoyed to have a CD-Workbench started (loading from CD also takes much longer than a normal warm reset).

Speaking of CD:s, there's also some quirkiness going on when inserting a mixed data/audio-CD in the drive (such as Quake). It seems that the first time the CD is inserted, it is treated as an audio-CD (you only see the tracks). You have to remove it and reinsert it to have it appear as a Data-CD. Weird. More serious is however that a CD is not recogniced at all sometimes -- and you have to remove it and reinsert both one and two times to get it to work (and then an additional time to get to the data content). I hope this will be more streamlined in the future -- unless if it is not just yet another example of a CD-ROM of mine acting bizarre ...

... At one instance, involving a swift removal of a CD while in the process of rebooting, I actually ended up at the purple "insert disk" animation! The tick was replaced with a (very ugly) boing ball. An easter egg perhaps?

Looks , Feel and configuration

This is AmigaOS. Have you used it before, you know how it feels already.

AmigaOS4 has the advantage of much more modern hardware than the classic, and thus the Workbench can perform accordingly. One must remember however, that the graphical subsystems are still not native PPC in this release. A complete Workbench overhaul is also something Hyperion has flagged for -- but for a later version of AOS4.

Overall, the graphical system seems more robust than I thought it would be, having heard of its non-PPC status. Windows can have oblique moving and I see no big difference between how it looks in AOS4 from how oblique moving looked under LinuxPPC. It is not entirely smooth, that much is clear however, and large program windows do stutter considerably. Also moving an oblique window over another window causes the background window to flicker rapidly (very rapidly; it's not disturbing, but it's there). On the plus side, requesters and Icon displaying is unnervingly fast; You can still see the order in which they update, but unless for very large directories with hundred of files, I can actually begin using the Workbench windows themselves as listers for starting Multiview, for example. Subtle improvements iinclude a much better-looking display of AmigaGuide documents (with shaded buttons). Text flicker madly when resizing such text windows though.

An important thing for the Amiga experience is the mouse cursor. This moves quickly and fluently and I have not reacted on any sluggish or "jumpy" behaviour, not even under heavy load. It has frozen once -- when the whole system froze -- but not even low memory seems to slow the thing down. This gives a very responsive, Amiga-like feel.

I noticed that there are a whole host of useful commodities in the Tools drawer. After having added ClickToFront, DepthToFront and PowerMenus (gives context sensitive menus) to WBStartup I feel like the Workbench just became much easier to use. FKey has received the nice capability of "Learning" key commands. Being able to close windows with a button is worth gold. In this regard we mustn't forget Amidock -- it allows you to assign hotkeys to all your programs. This is something of a requirement for me and it's very good to see working so nicely.

The use of a default path is working much better now. For example, if the icon of a file specifies an unknown tool, you get the option to choose a new tool (this is good in itself). But in the ASL requester you don't have to go to the directory of e.g. Multiview to select it; just write Multiview in the requester and it will load, regardless of where your directory focus happens to be. I have not seen this feature within a file selector earlier, and it's very useful. With the Pre-release-CD comes , apart from the SDK itself, a host of contribution software. For some reason the Installer nowadays resides in the Utilities drawer(was this always so?) The programs on the CD install OK, but all third-party software I've tried so far wants it to be in C: A simple copy into the default path solves this, but still it might perhaps be considered for the final release. Surely an Installer is so crucial it belongs in C: anyway? I was annoyed by the lack of auto-updating in normal windows. This really became irritating when checking my upload-directory while doing FTP transfer from the A4000. Even worse, the "Update" menu item doesn't have a Keyboard shortcut.

Generally, speaking on behalf of a theorethical newbie buying a new Amiga, it's rather counter-intuitive that many of the basic OS configuration options can only be found far apart from each other -- or are separated into different programs while seemingly doing the same thing, to the un-initiated. If you aren't intimately familiar with the name of every OS component (like you would be if you, say, waited a decade for a new Amiga system...), many designations would be rather cryptic.

There have been multiple discussions and ponderings over the default look and there is not so much I can add to a topic so subjective. I can only say that I personally like the look. And, to use an old cliché, all is configurable. Just to give some ideas:

• I changed the Window widths both right and bottom to make them more narrow
• I changed size and geometry of scroll arrows.
• I made the menus transparent and able to pop up under the mouse
• I changed some textures in the window borders (you can have different depending on inactive/active etc). You can also add a gradient to them afterwards.
• I played around with the gadget look controls

I can honestly say there are so many configuration options I haven't had time to explore them all. There are also places where obvious room has been left free so as to harbour future buttons and knobs. Certain features such as Styles, or settings for Strings are also "in development" and not included in th pre-release.

What I really miss is documentation on what all does. It's not always clear what effect a certain setting will have (indeed, what it really means...) and whereas there is a "preview" button supplied I noticed no effect when clicking on it. What will probably be needed for any sort of "public" release is a generous sprinkle of help buttons all over the place. Or at the very least a massive manual.

I find it disturbing that the "Workbench is reconfiguring the screen. Please close all windows except drawers" thing is still there. Such a thing reeks of old - bad - times (and is very impractical now that you have memory enough to run many programs at aonce).

As a side note, I think it is a bad idea to separate the GUI and Workbench configuration utilities. I know there is a conceptual difference, but a newbie won't. It's not intuitive why the "Icon Quality" controls shouldn't be in the same prefs program as the "Background text colour" controls for example. Also, the existance for a separate "Popup menu" prefs editor is not warranted at all. There are already menu configuration options in the GUI prefs editor. You get the uncanny feeling you are doing it all over again (you don't, but it feels like it) when having to open a separate prefs program to define the popup behaviour. The same goes for the ASL prefs. AHI and Sound is also a pair that would look better under the same umbrella.

When being on the subject of the Workbench prefs, a note is warranted on the Screen Title format requester. Remember seeing the memory contens of the OS in the title bar? When looking at screenshots in the future we must remember that those number might be misleading -- because it's the owner of the Workbench himself that sets the labels for the output. I was surprised by the wealth of customization which was available in this regard; you essentially produce a string by writing text and selecting display options from a immense amount of combinations. That's very useful and shows great attention to detail. Thumbs up!

A beef I have about the default title bar text is that the default displays three values - total, fast and virtual. For me, that is (at the time of writing) Total: 47MB, Fast: 47MB, Virtual: 184MB. "Virtual" is not "harddisk virtual memory" as was my first thought, but actually ("virtualized") memory set aside from the pre-adressed Physical memory in order to have it free and available for on-the-fly memory adressing later (I'm sure I got that wrong, but that's how I understand it). So 184+47=231MB is actually free available memory out of my 256MB . Not bad, but the "Total" field is confusing, since it's always the same as the Fast memory ... I would think a more intuitive default would be needed for a public release (ditch the Virtual/fast separation and display only available total memory. The guys in the know configure what they want anyway).

I did a (very) primitive memory/stability check with Multiview, by simply opening large pictures and letting them stay on the desktop (so in essense I was opening a large amount ov Multiview sessions). Doing so, the available "Fast" memory kept dropping as suspected. However, I thought the "Virtual" memory would kick in once the "Fast" got too low, but apparently not so -- when at 1MB Fast, I got "Not enough memory" errors from Multiview. At that point there where 169 MB of "Virtual" memory available. At this point, the system was very slow but still usable and stable - and importantly, the mouse cursor never slowed down at all during the entire process. Closing the Multiview windows dutifully returned all memory to the same amount as it was before. I've done the same test over and over again without rebooting and without ending up with less memory afterwards, nor any stability issues. I know its a very crude test, but I also know thst my A4000 wouldn't have been able to take that kind of punishment without loosing more and more memory and in the end crash like a stone. The reason why the "Virtual" memory doesn't kick in is interesting though (but, as said, the graphics system *is* still preliminary).

The Time prefs editor has a nice option to use a remote nfs server to keep track of time. Haven't tried it, but other reviewers has claimed it works fine. Other prefs programs, such as Pointer and WBPattern haven't changed much. The PrinterPrefs gave me warnings of a missing "printer.device", but since i don't have a printer connected to the A1 I haven't investigated this further. The "Screens" preferences are very nice. They work in a similar way to the MUI screen definitions and it seems very sleek and useful. There is a Picasso96Mode Preference editor too, but I'm using the Radeon screen modes so I haven't fiddled with that. A last example on a "new" prefs program is the "Internet" prefs. It is very similar to Miami, actually. So far I haven't had anything to complain about; as said, the wizard got everything running smoothly for me.

A curious thing was that the first time I opened many of the Prefs requesters I got an error saying that they couldn't open directories in the system: directory. Starting the prefseditor a second time made everything work normally. I can only conclude that those directories were created automatically (although the system failed to inform about it). Those prefs works fine after the second time.

Programs

It should be mentioned that although I have played around a bit, I haven't tested any of the program extensively. As for the games, I've only just tried to install them using the original CD:s. I haven't downloaded any PPC versions of Quake yet,. for example.

The SDK installs into a directory of its own and ends at roughly 200 MB in size. The installation should also set up the environment properly, but I haven't tried to compile anything yet. It includes the 2.95.3 GCC compiler as the default. GCC 3.4.0 is also included, but still considered experimental. Vbcc is also in there along with the system Includes, Autodocs, guidelines for programming AOS4 and PDFs on compilers and debuggers. There is a directory of example code both for beginners and advanced users and the source code for the CLIB2 runtime library.

Personally, I'm at the "beginner" end of the scale, but I really look forward to checking out the SDK further in the future.

IBrowse demo installs without problems. Note that this is not the final OEM version of IBrowse (v2.4 or 3.0 depending on timing) that will be included in the final release of AmigaOS4. Rather it's the standard 2.3 time limited demo version. It's usable with a 2.x keyfile. This release also has some serious bugs (noted at the beginning of this review). Still, it's a nice browser. I feel it's rather slow to update though, maybe the same or slower that on my A4000/060. It's likely the non-JIT emulation that is the culprit here. I was amazed to find my fourth mouse button work to scroll text in IBrowse (still not the mouse wheel). My 4th button doesn't even work in Linux!

In the contribution drawer we can find old gems such as YAM, SimpleMail and UAE, but also new stuff such as a demo of AudioEvolution4 (looks very good, that one). There are also some developer info on e.g. MUI, Shell programs like KinCon and Font related stuff such as TTEngine. DOpus is a familar face, although I've never used it much. I copied a bundle of extra backdrops and toolbar icons to my Presets directory in the Prefs drawer. There is also a set of games (like Duke3D) which I haven't touched yet.

From the Amiga4000 I copied my entire Final Writer97 directory straight over to the A1,. I'm glad to report (as other have) that FW works nicely. It even looks better -- appently it uses the OS Screen prefs. It is not impressively fast (emulation again), but fully usable. I think I have to delete the configs for my Swedish version though (I have both english and swedish) -- it ran on a separate screen and that screen is obviously not defined anymore, which means the program can't open at all.

I installed Payback with all the latest fixes --- and was calmly informed by the operating system that "this program has a known problem", giving me the opportunity to abort or to take my chances and start it anyway. That's service! Of course I took my chances only to have it crash and burn on me. Hopefully a fix will come for this. I cannot wait to play PaybackPPC.

I thought Hyperion's own Freespace would be a safe bet - but no. It went through the installation fine only to complain on a missing "wizard library" when I tried to enter my serial code. Only tried it once, because this happens at the end and it takes quite a while to install.

I also had trouble with QuakeI & II. This is not so surprising; Remember that I haven't updated these installs at all yet.

Conclusions

The pre-release is still a rough system and it was rightly judged not fit for a final release; There are still too many small annoyances and things that need plenty of polish, not to mention the bits that are actually still missing entirely (such as Petunia, VM-pager scheme etc and a native gfx-system). I have tried to give examples throughout this review of things an end-user notice. I might have sounded picky at times, but these are my impressions and I better comment while I still remember it, right?

However: the AmigaOS4 prerelease *is* a much more able system than I suspected from the pre-release status. The base system seems stable and feels both responsive and quick even under the limitations of a non-complete gfx-system. This is very important and I was suprised not to encounter any large snags in my enjoyment (which is why I was able to concentrate on smaller grievances). The Installation was smooth and once every A1 is sold with updated firmware, it should be easy for a newbie Amigan too. Much attention to detail has gone behind the hood (note how I haven't even begun discussing the stuff *really* under the hood, like ExecNG. I'll leave that topic to more able people), stuff you do notice and appreciate in everyday use.

If you have managed to read this far, I'm impressed. I apologize for the length. But it's not every day a new AmigaOS lands in my lap. And certainly not one with so much promise for what will come. Something to instill pride in the developers and the community both. Something to allow the battered Amiga users to take a first uncertain step toward a carefully optimistic future.

SlimJim, Uppsala 2004