AmigaOS 4 Update
by Ben Hermans

June 2003 proved to be a very interesting month for the OS 4 development team with the start of the "AmigaOS 4 Tour", a roadshow throughout several European countries organized largely by Jürgen Schober of Point Design (who also came up with the idea) in conjunction with local user groups and dealers.

Visitors attending these venues were given (or will be given) a demonstration of the new functionality introduced in AmigaOS 4.0 as well as a chance to see OS 4 running on Cyberstorm PPC hardware without the 68K CPU being used.

Hyperion developers Steffen Haeuser, Hans-Joerg and Thomas Frieden attended the show in Augsburg, Germany and I should be making an appearance at the show in Sweden.

Reaction so far from users proved to be very positive. Some users have nonetheless expressed anxiety that the AmigaOne version would still be very far into the future.

We do not share these concerns. The chipset dependency of AmigaOS has been largely overstated throughout the years, sometimes even as an excuse why AmigaOS should be ditched altogether in favor of a new system.

It should be remembered however that the Draco also ran AmigaOS although it didn't have the custom chipsets. If the chipset dependency were such a massive problem, you would also not have seen anything like Amithlon either.

The chipset dependencies of AmigaOS are located in three main areas and nowhere else:

1. Exec.

   We already demonstrated ExecSG running on AmigaOne hardware so that is pretty much taken care of.

2. Devices.

   AmigaOS has quite a number of hardware banging devices like scsi.device, timer.device, keyboard.device, parallel.device, serial.device, audio.device, cia.resource etc. etc.

   All of these need to be re-implemented for the new AmigaOne hardware. In the process the USB stack needs to support the hardware as well.

   (This is incidentally also the reason why porting AmigaOS 4.0 to other PPC hardware involves more work than just adapting the HAL of the ExecSG kernel.)

   One advantage is that this work is highly modular: you don't need to have serial.device up and running before you can proceed to parallel.device. All of this work can be carried out by developers in parallel.

   The work on re-implementing these devices has already started although most OS 4 developers are still working on the actual OS functionality itself.

3. Graphics.library.

   Graphics.library is the OS module, which deals with getting everything on the screen, and as such it was initially geared exclusively towards planar (AGA type) graphics.

   What RTG solutions like Picasso 96 do is patch graphics.library to redirect output to chunky graphics boards either sitting on the Zorro bus or some kind of PCI bus.

   For OS 4.0 we are aiming at better integration of Picasso 96 with graphics.library considering we now have the AmigaOS source-code, which was not available to the developers of Picasso 96.

   This will be some work, especially because we then subsequently plan to offer SNAP as a monitor driver for P96, effectively unlocking support for 190+ graphics chipsets to AmigaOne users.

   SciTech is currently in the process of migrating SNAP to Linux PPC, which will take care of all the nasty endian problems we would have to deal with otherwise.

   Once that process is completed, we expect to be able to integrate SNAP into AmigaOS 4.0 in a matter of no more than 2 weeks, based on the experience integrating SNAP into other operating systems.

As you can tell, we have a firm handle on the situation.

There is nothing overly challenging there, just a lot of grunt work, which can luckily be divided up easily between different developers, many of whom will be coming off from their assigned work for OS 4.

The reason why we are still very much concentrated on AmigaOS 4.0 for the Cyberstorm is three-fold: first of all, it serves as "proof of concept". Once it is completed for this hardware, it will prove that it runs, runs well and is fast, even when executing 68K legacy programs.

Secondly, we need revenue to sustain further development, not only of the AmigaOne version but also of subsequent OS updates.

Thirdly, we do not believe in trading in one small PPC user base for a potentially even smaller user base of AmigaOne machines. This will deter developers from developing an OS 4 native version of their software; instead you'll just get OS 3.x versions, which run on a wide variety of platforms. Software developers need to see a decent return on invested time and for that, they need the largest possible target audience. It's clear that many people have invested heavily into their Amiga's in the past and some of these people may be reluctant to buy an AmigaOne. By releasing a version of OS 4 for the classic hardware, we are giving these people a chance to give their machines a new lease of life and possibly inspire them to buy an AmigaOne.

Having said all that, what have we been doing in June?

Once we got the system up and running, our main focus was bug-hunting and stabilizing it sufficiently as those that have attended the Tour events can testify.

We also incorporated support for loading OS 4 native ELF binaries into DOS.

Subsequently, our focus turned to providing a complete, stable and functional tool chain to develop OS 4 native programs, which would also be used to migrate the OS modules from 68K to PPC.

This involves porting our ixemul-free GCC compiler (using Olaf Barthel's C runtime library) from 68K to PPC, a job that should have been completed by the time you are reading this.

It also involved coming up with some tools, which rework OS 3.x source-code in order to recompile them easily for OS 4 and PPC.

In the process of refining these tools, we already converted timer.device, cia.resource and input.device to PPC, which are particularly frequently called upon devices. (Utility.library, expansion.library are also available in PPC as part of ExecSG and we also have a ppc native ramlib).

By doing so we have also taken a significant step in the direction of a new OS 4.0 SDK, to be released concurrently with or shortly afterwards OS 4.

We also developed an OS 4 cross-compiler, which runs on OS 3.x for those (OS4) developers who don't have a PPC (yet). This seems to work quite well because SFS and CDFS were successfully compiled in that manner.

Summing up, we have been laying the groundwork for the migration of all OS 3.9 modules, which are available to us in C to OS 4 as painlessly and effortlessly as possible.

If every OS 4 developer takes on a few OS modules and converts these to OS 4 native versions, this process would be concluded pretty rapidly.

This push will come in early July.

I'll tell you how it went in my next update.

Meanwhile I hope you liked the screenshots of the reworked Intuition, which shows off about 80% of the default look we are aiming for.

Based on the reactions we got, we have already modified the design slightly in terms of visual appearance although nothing is set in stone yet.

We appreciate your input and support.