Summing up it can be said that the conceptual design of our PowerUp system software fulfils all requirements to implement a standardized software interface for any kind of processor hardware (including multiprocessing systems) and offers an optimal hardware independency. The options offered by our solution are in addition based on well introduced standards, what results in various benefits for users and developers from the beginning (as demonstrated by the LIBMOTO example above).
Amiga conformity and future compatibility

The complete development of PowerUp system software is focused on conformity to the existing Amiga system software. Our solution made it possible to integrate a new processor transparently and fully compatible into the existing operating system environment while realizing new concepts and open new ways for the future.

As documented in the articles about guidelines for implementation of PowerUp applications, multiprocessing capabilities and the hardware independency resulting from our solution, PowerUp does not only offer extended performance, it also offers various basics for future hardware and software developments. By keeping the PowerUp system software as open as possible while preserving compatibility to major industrial standards we keep doors open for developers to participate on an innovative future for the Amiga. We are convinced that the Amiga should be open to cross platform standards without losing the positive and unique features of the Amiga and the Amiga operating system.

We do not deny that parts of our conceptual design are prepared to lead to the A\BOX. We like to give all developers, who work on new software generations for the currently introduced new processor, the possibility and security to easy switch to next generation machines independent from the - yet not determined - plans and decisions of the system vendor Amiga International. There is still no security, that those will fulfil the expectations of the Amiga community, even if we and all other people dedicated to the Amiga hope so. By keeping this in mind, we think it makes sense to provide also alternatives with our concept for developers and users to gain and offer long term perspectives.

With our solution, however, also a major improvement and evolution of the Amiga operating system is supported, because by using the structured design that we recommend to use, the new generation software with a modular design can easily be adapted to any modifications of the operating system. This offers the developers of the Amiga operating system much more flexibility for implementation of new features. This implies that software development under PowerUp makes major modifications of the operating system possible and is open to conceptual design changes. In addition we are open to share the technology and software designs with Amiga International in a cooperation.

In summary, there are simply no valid arguments for the resistance against the introduction of open standards, structured programming and an application software design which is as much independent as possible from the current operating system version to be prepared for future development of the operating system. The strict devotion to existing structures and the approach to develop a new generation of software for a new processor while fully preserving the actual operating system is contrary to a concept open for the future.
The ELF Linker Format

Related to the discussion about the ELF format, that was chosen as the main executable format for PowerUp, there is simply to say, that it is completely insignificant to the user, which linker format is used for software development. The statement, this would lead away from the Amiga is incorrect, which is proofed by the implementation of the GNU C system and additional compilers like SAS-C.

Correct is, that by using that new format development has to use different and new paths. But it is not correct, that basic features of the Amiga are dropped by the use of ELF as main linker format. Especially shared libraries, which are possible despite of the use of the ELF format, are possible under the PowerUp system software. In addition, the PowerUp System Software is also prepared to use Mixed Binaries. Therefore there is no need to either generate Mixed or Fat Binaries nor is there a need to reload ELF executables; it is simply up to the developer to choose one of these implementations by the way his programs are structured.
Recommended Guidelines for the implementation of
PPC software on PowerUp systems

We will not cover programming styles here in detail; there is quite a lot of documentation out there on this topic in our developer notes, the libraries and autodocs as well as the various examples provided by us. We will just discuss the basics to structured development under PowerUp.

Most important for porting software to the PowerUp is a conceptual guideline which phase 5 recommends to all developers. When porting or optimizing software to/for PowerUp (which effectively also means working on a completely new processor type) we recommend that the developers structure their software programs internally, if they haven't already done so.

To gain optimal performance out of the hardware design currently available and to secure an open design to future developments, we recommend the use of modular program structures by using sub tasks, which we call threads subsequently, because our approach is equivalent to multi-threading (a procedure where tasks create subtasks for different jobs). We are not covering details on memory allocation or memory protection for multi threaded systems in this description, because this is very much dependant on the options available from the operating system. The multi threading mechanisms implemented in the PowerUp system software are already prepared for memory protection, and as soon as it is implemented in the operating system, applications using the PowerUp system software benefit automatically from the memory protection.

The programmer can choose for all threads whether they should use the 68k or the PowerPC CPU. The asynchronous communication is handled fully transparently by our message system, which is used to exchange signals, messages and data between the different tasks. An efficient policy is for example to design a 68k master task which is used in the current implementation of PowerUp to start up the program, that handles the user interface and all related OS calls which are currently 68k based. This main task subsequently creates the threads required for the various jobs. Asynchronous file I/O operations for example may be implemented as a 68k thread while applying filter operations to a 24 bit graphics runs as a PPC thread. In this example, the 68k main thread sends a signal to the PPC thread and can continue to act on user input. The PPC thread sends back a signal upon completion of the filter operation to the controlling 68k thread which continues to act on the results, e.g. by copying the graphics data to a destination window. Of course subthreads can communicate to other subthreads without intervention of parent threads.

This implementation enables any application to automatically benefit from multi-processor designs. If for the above example the main thread instructs a subthread to work on an image manipulation operation which takes 30 seconds, the user does not need to wait for the busy pointer to disappear, but he can work on. In addition the programmer can ask the system for the number of CPUs present on the system and use this information to launch multiple identical sub threads, which are dispatched to different CPUs by the PowerUp system software, and which all execute a certain part of a complex operation. This enables programmers today to actually develop software which is prepared to use multitasking, multithreading and multiprocessing.

In addition this proposed procedure in combination with the implemented multiprocessing capabilities allows easy implementation of future developments of innovative hardware whith easy support by existing applications. So it is possible for developers to be prepared to use for example high end 3D hardware or special DSPs for multimedia operations as expansion products which can be implemented as Zorro III boards or even be connected via a local network and incorporate special functions, like a GL implementation or a MPEG/JPEG engine. All they will need to use this is to define a message port and the necessary message data structure. The vendor of a 3D or multimedia application that uses the PowerUp message system only needs to know the message port name, the function set and the message types to be able to fully use the extended hardware.

The multithreading system, that does not conflict with the Amiga OS philosophy, will be of advantage concerning future compatibility for software applications by taking advantage from the strict distinction of PowerPC and 68k based code segments, since for future OS developments the currently 68k based code parts can be easily replaced or updated. If for example the 68k based graphics calls will be replaced by a PPC native graphics system, the 68k library calls can be easily replaced by PPC calls for structured applications, especially if those new calls need a new structure or have extended functionality. We think this approach has a much better focus on any possible future development than any mixed binary solution that requires lots of context switches and may lead in addition to a lack of structured task dispatchment. By proposing our solution we give the developers, who develop with and under PowerUp, the security that applications will be easy to port, mostly hardware independent and prepared even for major changes of a possible future operating system, which we consider as important for the future development of the Amiga.
In regards to Warpup and the related public discussion, we have decided not to extend the discussion and to concentrate on technical facts only. In the technical documents published here most questions concerning our concepts and our hardware and software solutions are answered, which will help all readers to sort out misinformation and decide on their own which conceptual implementation and vision for the future they want to support.

We will not influence the Warpup development of Haage&Partner in any ways, nor will we support this product or developments using this software. It is up to Haage&Partner as the makers of this product to provide full PowerUp compatibility, which means compatibility to the PowerUp hardware and the PowerUp System Software. While this is not given, we do not recommend Warpup at all, and we give no guarantee or accept any liability or responsibility for the functionality, the performance, the compatibility or the usability of PowerUp Systems on which Warpup is installed, for any purpose.
Links to PowerUP software and Developers

As well as to developers who have received PowerUP developer systems and consider support for PowerUP in their software. Contact the vendors of your favourite applications to get more information on the status of PowerUp support!