AmigaOS - Moving from the Past to the Future

With AmigaOS4.0 on the horizon, many people have been asking what the future holds for the AmigaOS. To understand the future we have mapped out, one also needs to spend a bit of time looking at the past.

The situation we inherited is of a hardware base of 68K machines, some of which have been extended via third party cards to support PPC processors, and graphic and audio chips. We even have some PCI expansion boards.

On the software side, we have AmigaOS3.9 as the latest release, and the additional hardware mentioned is supported by various third party solutions. This is to say nothing of the many third party patches, add-ons and enhancements that have been created and which pepper every user's installation to a level that would scare even a kit car enthusiast.

In short, we have a mess.

In considering the future that sees AmigaOS4.0 as the first rung on a long ladder back to the stars, we had to look at the following requirements for a future proof solution.

1. Compatibility with as much existing software as possible.
2. Move from a 68k processor and proprietary hardware to a new, open platform.

3. Abstract completely from the hardware domain.

4. Provide a powerful foundation for the future.

5. Prevent 1 and 2 from having a negative effect on 4.

6. Advance the functionality of the AmigaOS.

These six requirements taken separately represent complex problems but taken together, they present an immense engineering project. Most difficult of all has been how to achieve both points 1 and 6 in the same project. Backwards compatibility demands keeping a majority of the existing AmigaOS whilst advancing the product requires looking at new ideas, concepts and architectures. This led us to make a new distinction in the history of the AmigaOS.

Amiga Generation 1 (AG1) refers to all AmigaOS technology that is OS3 or lower, architecture built around a single address space trusted task model and firmly anchored to proprietary hardware architecture.

Amiga Generation 2 (AG2) refers to brand new, designed from scratch set of services that will be responsible for implementing point 6.

I will talk more about these, and particularly about AG2 later in the article, but for now, if I use them then at least you'll know what they mean.

Given the headaches and potential for disaster, it was decided that we would approach the project in stages, building from the bottom upwards and the top downwards at the same time to eventually meet in the middle.

Stage 1 - AmigaOS4.0

AmigaOS4.0 brings the AmigaOS to a new piece of hardware, the open platform AmigaOne. A customer would expect to be able to run the majority of their old AG1 software on it whilst having a faster and more stable experience. In addition, they would expect to see a more complete product that doesn't require a shed full of third party enhancements. Finally they would want to be able to take advantage of the new hardware standards open to them - integrated Ethernet, USB, PCI and AGP - finally being able to buy for their platform in standard computer retail outlets.

1.1 - Low Level Foundation

The first crucial stage has been to create the beginnings of a low-level hardware abstraction layer that frees the AmigaOS from any hardware dependencies inherited from AG1 whilst allowing AG1 applications to run. This has been done by the development of ExecSG and its new component influenced library model. It implements what is called a mixed binary modality, meaning that it can seamlessly marshal both PPC and 68K binaries and allow them to call between each other.

1.2 - Workbench and all that Jazz

Theoretically the low level foundation is all that is needed in order to get AG1 running on AmigaOS4.0 and that has been part of the test cycle. However, many of AG1 models were written in handcrafted 68k assembly code and are speed crucial to the operation of the operating system and so a second task has been to remove old BCPL code and to convert 68k code in C, a far more portable solution which can then be compiled directly into PPC binary form. Eventually the entire AmigaOS will be PPC native but concentrating on the most speed crucial pieces first maximizes development resources whilst minimizing time to market.

1.3 - New Features

Whilst having AmigaOS3 on new hardware would provide a much faster and more stable product, it is hardly going to set the world alight. A lot of effort has been spent both in removing the need for third party enhancements by expanding the functionality of the OS and in adding new functionality - an integrated TCP/IP stack, a media toolbox, a system wide service that registers and monitors running applications, and many graphical enhancements to Intuition and Workbench, for example.

1.4 - So what will it feel like?

AmigaOS4.0 will feel like an Amiga, but an Amiga on fire. It will look like an Amiga, but an Amiga that has moved from kindergarten finger painting to art college. It will be the best Amiga ever BUT it won't represent the giant leap forwards everyone has been calling for. This is because this is just the first step, and the most important part of that first step has been ensuring backwards compatibility whilst removing dependency on both an old processor and an old multimedia chipset. With that sorted out in a stable and efficient manner, we now have the foundation for the future.

Stage 2 - Amiga Generation 2 (AG2)

The first Amiga was launched in 1984, almost two decades ago. Since that time computing architecture and design has changed but the AmigaOS, thanks to business difficulties has been unable to advance, both in keeping up with and in setting the agenda.

This is not to say that change is always a good thing. The simplicity and efficiency of the original AmigaOS design is something that even the latest offerings from our competitors can only dream of attaining. What is clear though is that with the AG1 transition complete, it is time to undertake a complete review of the AmigaOS.

AG2 combines a review of the AmigaOS in general with a review of each individual component. This dual approach is very important to ensure that we develop a full rounded, and more importantly, an honest picture of the AmigaOS. The purpose of this review is to decide how we move our platform forwards in the coming months and years.

The review process consists of the following:

1. An assessment of the positive and negative of the AG1 element
2. A redefinition of that element
3. An identification of the various 'customers' for that redefined element
4. An investigation into what our potential competitors are doing
5. An investigation into current research and other blue sky thinking around that element
6. An identification of current trend in areas of usage that touch that element

As can be seen, this review process is intended to be detailed and comprehensive, utilizing a multi dimensional focus in other words looking at the domain from many different directions. This is important because many technologists only look at a domain from their own viewpoint and this end up producing a solution that is tailored to a minority of potential customers. We intend to look at each domain from the point of view of the designer, the developer, the user, the hardware engineer and any other identifiable customer. Only by doing this can we have a hope of providing a successful solution.

Given the large number of domains that need to be reviewed, the length of the reviews and then the work required, it will be sometime before AG2 technology can be experienced in full by the user but they will start to feel the effects of it fairly quickly.

As an example, consider the graphics service. With AG1 we have an essentially planar based graphics model wrapped into graphics.library which was tied to the custom chipsets but is now presented as a heavily patched solution sitting on top of the picasso96 third party RTG system. Sitting on top of this is Intuition and on top of this Workbench. Sitting to the side of graphics.library are the printing, video and 3D solutions. All of these are heavily dependent on their supporting layers, which ultimately leads back to graphics.library.

The AG2 review of the graphics service removes that approach. It introduces a customer and supplier model of analysis. Who will be the customers of the graphics service? What services will those customers require? Who will supply services to the graphics service? What services does the graphics service require in order to service its customers?

Suppliers to the graphics service will be the hardware abstraction layer, encapsulating the graphics hardware but there will also be other inputs into it - scanners, digital cameras, video cameras, and video feed in general - static and streaming graphics inputs.

Customers of the graphics service are in abundance. User environments, 2D, 3D and video applications, font users, printers, monitors, developers who need a flexible and powerful set of tools, professional DTP, graphics artists and video editors.

This review feeds back into the general review of the AmigaOS. How can this customer and supplier analysis lead to an entity model that leads to a flexible yet integrated operating system architecture that both provides what is needed now and yet which can grow with the future? What about AG1 backwards compatibility?

To extend the graphics service example, consider this development path. Once designed, the AG2 graphics service will be implemented from the bottom upwards. However, it will be implemented as an independent service that will sit next to graphics.library. In essence there will be two graphics services, one AG1 and one AG2. Initially the AG2 graphics service will be an exclusive mode that takes over the entire graphics hardware, suspending the AG1 graphics.library. Applications will have to specifically call the new graphics service to make use of its capabilities and there will be no mixing. It will either be the AG1 graphics.library or the AG2 graphics service.

From a user point of view this won't be that obvious because it will be wrapped into a screen switching operation. Where it will be obvious is that there will be no intuition support in the AG2 world. This means that AG2 using applications at this stage will most likely be games or those, which implement their own interfaces on full screen.

The next stage will be to create a proxy service solution. In this all AG1 graphics.library public API calls will be translated into AG2 graphics service calls. Again, this will be transparent to the user and they won't notice much of a difference from the first stage. This is because Workbench, Intuition, layers and all AG1 using apps will still be doing what they currently do. They only difference is that they will be using the AG2 graphics service instead of the AG1 graphics library. At this point, we may extend Intuition to be able to make use of the new features of the AG2 graphics service but it would only be a temporary measure.

The key achievement of this stage will be that we can finally remove graphics.library without affecting backwards compatibility, and for the first time ever, the AmigaOS will be running exclusively on its brand new AG2 graphics service.

With this, the AG2 graphics service will be complete. What will then happen (or more likely already be happening in parallel) is that other AG2 domain projects, for example the user environment domain, the printing domain, all of which had input into the AG2 graphics service project and all of which are customers of the new service will then begin their new implementation but directly on top of the AG2 graphics service.

For example, the AG2 user environment review will at the very least see Intuition re-implemented if not completely replaced, most likely with a descriptive producer model to allow for completely redefinable user environments.

What the last page or so should have shown was that the AmigaOS will move forwards and, unlike almost all other OS development, it will do so without being hamstrung by having to sacrifice the future for the past. Review of each domain is followed by independent but parallel implementation, which is then followed by replacement of the old by the new.

This should also answer all the questions about will AmigaOS4.0 introduce better printing, support for scanners and cameras etc. Since all are graphical, there is little point in spending considerable time on these services since they are customers of the graphics service itself and until it has been implemented, any effort spent would merely be relying on an old and soon to be replaced element. What is important is that those customers will have full input into the design of that which will supply them when they are finally implemented.

In summing up, the transition from old to new hardware and the creation of a foundation for AG2 has been our preoccupation for over 2 years now but with its approaching release, the future of the AmigaOS, of Amiga Generation 2 is being laid and users will get to experience this development first hand as more and more pieces of AG2 are released and then brought together to complete the picture, providing a platform for the future.

Fleecy Moss
CTO
Amiga Inc