-=+=- One Of The Hyper Fast Board In EUROPA -+- DIGITAL-X -=+=- _________ _____ _______ _____________ ______ _________. ._____\__ (_____) __/_____(___\_____ |/ ____/ \ |______ | / /| | \_ | | | | \____ \ | / `------/_____/ l_____|-----/_____/|_____| l____|-----l______\_________/ .. ^cG .. N [1] +31 570 637050 28.8 .:::. .:::. N [4] +31 570 AUG'98 ISDN N [2] +31 570 636468 57.6 ·::::. .::::· N [5] +31 570 AUG'98 ISDN N [3] +31 570 677702 28.8 ::::::::: N [6] +31 570 AUG'98 ISDN .::::· ·::::. ·:::· ·:::· ·· ·· System: A2000/060/50 64MB 9.2Gigi Space Picasso II+ GFX Card On SysTem : Amiga ECS/AGA * Pc Warez * /X-Tools 2100+ * GameBoy * PSX C-64 * Super Nes * Modules * Nice Girls 18+ * Nintendo 64 And A Dist Site's For : Wanted Team (PLHQ) * Cyber Dreams (EHQ) Nirvana (SWHQ) * Exlex (NHQ) @BEGIN_FILE_ID.DIZ.------------------------------------------. | HAAGE & PARTNER | | | | WarpUP - Our Response | | english/german | `------------------------------------------' [ISDN] DigiTal-X CBD*WT*EXL* 6Ndz [ISDN] @END_FILE_ID.DIZ _/\_ _____ ____ ______\__/____ dNo/jA! ____ __ ______ ___\ _ | | /____\ _ |-------| |`--'| _ / |__ \/ | --|- _ /|__ \/ | __ | --|- | \/| .-`--'-----'----'--\/-'--'-----'---'---'----'----'-----'-. | ÷ a ÷ t ÷ l ÷ a ÷ n ÷ t ÷ i ÷ c ÷ | | --- CBK --- STS --- RYL --- LFC --- X!TREK --- GNX --- | | Absolutly one of the fastest in Europe! | rUNNING 4nODES + 4tELNET (24H) Node1: [-- +46-XX-XXXXXX--] Node2: [-- +46-XX-XXXXXX--] Node3: [-- +46-XX-XXXXXX--] Node4: [-- +46-XX-XXXXXX--] Node5: [-- FIND ME ON IRC-] Node6: [-- FIND ME ON IRC-] Node7: [-- FIND ME ON IRC-] Node8: [-- FIND ME ON IRC-] SUPPORTING : AMIGA - PEZE - N64 ______ _____ _____ ___.-___ __ _____ _____ ______ _) _Y _Y _Y (__) | _Y __Y _Y (_ \_ | \_ | \_ l_\_ _/\_ \_ _/\_ l_\_ | _/ | | | | | | l | | | l | | | | | l__| l_____l__| l__ l__| l__ l__| l__| | `--' `--' `--' `--' `--' ______ _____ ___.-______ _____ _____ _) ._ Y_ _Y (__) _Y _Y __| \_ |/ / | \_ | \_ | \_ |_\_ _/_ | __/ . | l | . | l | l | l__| l__| l__ l__| l__ l__ | 2F `--' `--' `--' `--' `--' 3nds Ringdown loaded with AMIGA/ASCII/CONSOLE/PSX/MAC 4040 26mb 9.5gb cd-rom 2/33.6ds 1/28.8ds 3/TELNET * TRSI RECORDZ DKHQ * AFTERSHOCK HQ * HOODLUM DK HQ * * MOT!ON HQ * ROYAL HQ * TRADERS DREAM HQ * STYLE HQ * * LSD HQ * LIGHTFORCE HQ * POLKA BROS. WHQ * PUZZLE WHQ * * KEFRENS WHQ * SAVE OUR SOULS HQ * ARTWORK EHQ * OLDSKOOL HQ * * 5TH DYNASTY HQ * TWILIGHT * LOOKER HOUSE EHQ * ARSENIC HQ * * CRUX & BAD KARMA HQ * X-TREK HQ * ABUSE HQ * OMA HQ * THE PROTECTORS ARE: ZINKO^PLAYMATE^SISko^BILBO BAGGIn^NEIL/FLT^BLACK PANTHER/PSG UFOK/MsT^LsD^PsG^iHS^FURY/PSG/M!/SYS/HLM^KELDON/HF/LFC <0> +45 58ASK4IT <0> <0> +FIND ON IRC <0> · · _ __\ /__ _ _ _)\\ \ / //(_ _ -\ __\° X °/__ /- _ __ ___ ___) \/_\/ (___ ___ __ _ ((- \ - -\\\_\\__\\__ _ /¦\ _ __//__//_///- - / -)) _. \__)_¯_¯_(__/ ._ _/ \|_ | | | | | _|/ \_ __\ ___ _/\____\/__ __ _| | | | |_ __ __\/____/\_ ___ /__ _/ \ (_) \_ \/ /_/\\| |_|_| |//\_\ \/ _/ (_) / \_ | \_\/ | | | | | \/_/ | _|___ __ | | | | | __ ___|_ \|__/ \/_| | | | |_\/ \__|/ | · _) ¯_¯_¯ (_ · | | ·H2o!· \\___ \ / ___// | ¯\_______________________ _) Y (_ _______________________/¯ __ \___ ___/ __ - -->\__ fRIENDS oNLY! <<- (_) ->> fRIENDS oNLY! __/<-- - HAAGE & PARTNER WarpUP - Our Response The philosophy of Amiga-compliant software-development As the developer of the StormC developer-environment it has always been our aim to support all significant new Amiga-developments. Our philosophy is to place in the hands of the developer a tool that enables him to achieve the best result with the minimal effort possible. The first step in this direction was demonstrated with the introduction of StormWIZARD for AmigaOS and p.OS and with the p.OS-support of StormC. Developers that use StormC and StormWIZARD are able to easily maintain a common appearance and version of their software on both platforms. From the economic point of view this is a very important factor. Supporting an alternative operating system on the same CPU is one thing - supporting a new type of CPU is a completely different and much more complex matter. In about 2 years of development we have taken the next step and completed a hardware-independent PowerPC-interface. This interface, called WarpUP, was first presented to the public on Sep 26, 1997 on our homepage and on Sep 28, 1997 at the Amiga-meeting in Hof, Germany. Shortly before that, on Sep 26, our solution was presented to Phase 5 because we were and are of the opinion of having made a valuable contribution to supporting the PowerPC-platform. Phase 5, however, did not seem to be of this opinion and published a very emotional statement on Sep 28 in which they announced to cease any developer support for us and called WarpUP and our StormC compiler "unusable". However, reactions like that of Phase 5 are very unproductive. They bring disorder to the Amiga-market that has just been revived and they help neither Amiga-producers, nor Amiga-users. The attacks by Phase 5 on our WarpUP-package are in our opinion an ill-considered over-reaction. As opposed to the statements made by Phase 5, our package contains a solution that is compatible to that of Phase 5, as well as an alternative that completely replaces the Phase 5 software. The user is given the full freedom of choice - whichever approach he prefers, he can use. The compatible solution was known to and tolerated by Phase 5 at all times. Therefore it comes as even more of a surprise that Phase 5 now announce to cancel any further support and to intentionally make future PowerUP-boards incompatible to our software. Instead of entirely shutting out a software-solution, the user must be given the opportunity to make his own experiences with either software and discuss the advantages and disadvantages of both approaches in a reasonable way. Whoever denies this freedom of choice acts in a dictatorial manner in order to protect himself from any competition. We offer all interested users and developers information on our developments. The complete archive that includes a number of demo programs (that also run on 68K-Amigas that has an 040 or better) and full documentation is available free of charge from our FTP-server. Everybody is welcome to judge WarpUP for himself. Our development shows in an impressive way that is not necessary to create a new executable-format or a way to dynamically link libraries. From its very beginning, he Amiga operating-system has offered all features that are necessary to support a new type of CPU - be it with or without an additional 68K-CPU present in the system. The notes Phase 5 made regarding such new techniques for new OS-versions must invariably betray to the attentive reader the plans of Phase 5 of dropping AmigaOS in the near future in favor of their own development. What should not be forgotten is that the rights for further development of the Amiga operating system are held by Amiga International who will surely not surrender these rights in favor of a deviating approach. In the midst of this necessary discussion about a standardized interface between the PowerPC and AmigaOS one should never forget that it is the users who keep the Amiga alive - not a single hard- or software company. At the end of this discussion, the closing statement has to be: "And the winners are: The Amiga-users" In the following document we will provide you with a deeper and more technical insight in the course of our development of WarpUP and StormC for the PowerPC. The development history of WarpUP Nearly two years ago, at the Computer '95 show in Cologne, Amiga Technologies announced new Amiga models that were to be based on the PowerPC-CPU. At the same time, Phase 5 also made first announcements of their PowerPC-boards for all Amiga-models available in the market. This caused us to decide to make our developer-system PowerPC-compatible. The development of StormC-PowerPC commenced in March 1996, right after the CeBit. The concepts we set up at that time were intended to stick as tightly to the Amiga operating system as possible which didn't pose a problem at all. For this reason, we never even had the idea of using a different executable-format, even less without a official decision of the copyright-holder to the operating system. Our concept was also designed to enable us to quickly react to any possible changes to the OS and its application interface in order to save software-developers as much conversion work as possible. Unfortunately, the Amiga got into financial trouble yet again, a situation that, contrary to what the Amiga-users and -developers were led to believe, was not (and probably could not be) solved by Viscorp. Further development of the operating system as well as the long-awaited construction of a PowerPC-Amiga did not happen. What also remained missing was the definition of an interface for Amiga PowerPC-applications. However, we did not let ourselves be put off by this and kept developing in an Amiga-compliant way, as our solution did not mandate nor assume a change to the existing operating system. When Phase 5 announced that they would be building a dual-processor-board that would have a 68K and a PowerPC run in parallel, it became an urgent necessity to support the so-called Mixed-Binaries. This type of program contains 68K- as well as PPC-code within one and the same program. In the most optimal case it is completely irrelevant to the programmer which parts of a program are present in which type of code. Access to data (e.g. global variables) can be made by both CPUs without problems and a switch from one CPU to the other is done fully automatic, without any additional programming. The developer only decides which part of the program should best be run on the PPC (e.g. the raytracing-core or the conversion functions for graphics formats, etc.) and which parts are to remain on the 68K (e.g. everything regarding the graphical user interface). In this context it should not really matter if the code-parts are tightly interwoven, i.e. common variables and data structures are used, return jumps from one part to the other are made via so-called function pointers, etc. Much to our surprise, Phase 5 chose to use the ELF format which makes generating the necessary Mixed-Binaries (which are even recommended by Phase 5) a pain for the programmer: The PPC part of the program must be loaded manually; It is not possible for the CPUs share global variables; Data structures are interpreted differently by current 68K compilers than they are interpreted by GNU-C for the PPC, therefore these structures can not be shared between the CPUs; Return jumps via function pointers and even "normal" switches between the CPU must be programmed manually. When adding this up, you end up with a very long way when porting an existing AmigaOS program to the Phase 5 solution. As you might know, select developers have had access to special PPC developer-boards for almost a year - the fact that no application of significant size could be ported as of yet clearly indicates the problems involved in the approach required by Phase 5. After almost 18 months of development, WarpOS and StormC now offer the optimal way to create Mixed-Binaries. The developer breaks down his program into a 68K- and a PowerPC-part, in the most simple case by choosing which of the program modules (C source codes) should be compiled for which CPU, in the most difficult case by breaking each program module down into two new modules (one each for the 68K- and PPC-code). After that, only a recompile is necessary and there you have a your new PPC-program. StormC and StormLink take care of everything else. A single executable is generated from the 68K- and PPC-parts - this means that no PPC-parts have to be loaded at a later point during program execution. Due to the shared access to global variables and the compatible interpretation of the data structures by the 68K- and PPC-code, not a single line of source code needs to be changed. Context switches between the CPUs are generated automatically - the programmer doesn't even need to know when exactly these switches occur. In the middle of October '96 Phase 5 finally provided us with two PowerPC developer-boards and a very rudimentary software-interface to the PowerUP-board. Despite the simplicity of this software interface it was already so different from our (and thus: the Amiga-compliant) approach, that from the very start of the actual development we had to go our own way. Phase 5 was fully informed about what we were doing. Our way was not the one proposed by Phase 5, but it was a possible and flexible way and at that point Phase 5 did not make any objections. At the Computer '96 we were already able to present our first developments done with StormC and StormPowerASM. These developments were based on the tried-and-tested Amiga hunk-format and worked flawlessly. Under real-life conditions it soon became apparent that the performance of the PowerPC could not be noticed as much as we had expected - this was due to the complicated way that was necessary to handle AmigaOS-calls - which was in turn caused by the dual-processor technology employed by Phase 5. For every function call it is necessary to execute a context switch to the 68K CPU, execute the 68K system-function and finally switch back to the PowerPC-program with another context-switch. Upon every switch it is of course necessary to flush the data cache which takes a tremendous amount of time. The way we see it, it would have been possible to speed up the context-switches by extending the hardware. Phase 5 would not hear anything of that, though - a fact that surprised us quite a bit. At the same time we asked to be given more information on the hardware in order to help with the problem. This plea for information was rejected with the explanation that Phase 5 could make changes to the hardware at any time, so that our solution would not work anymore. Software that was directly adapted to the hardware would then not work anymore. Only for their very own software would it be guaranteed that an adaptation could be made in a very short time. For us as a software-developer this was very dissatisfying answer since it only told us that the software-side of the PowerUP board was to be held under monopolistic control in order to keep competition away. At that point in time we already suspected that Phase 5 would use these arguments to force any unwanted developments out of the market without discussion. For this reason we are not too surprised about the draconian measures Phase 5 announced they will be taking against our WarpUP software. It was the December of last year when our developer-team, above all Sam Jordan an Michael Rock, created a solution that drastically improved the context switches compared to the Phase 5 solution. It was already in January 97 when we had a very stable extension to the Phase 5 software that achieved a context-switching time of 0.5 milliseconds as opposed to the 60-90 milliseconds of the Phase 5 software. For all applications that we could now convert 1:1 this improved technique yielded a speed increase on the PowerPC-side that we deemed sufficient. Any application that wants to gain more speed from the PowerPC requires special programming anyways. In this case, the developers should be aware that they have to undergo a tremendous effort for only a small target-market - this will most likely not pay off in the software-market for dual-processor boards. We were and still are convinced that future Amiga models will have ONE CPU, regardless of which manufacturer will be supplying it. After that we spent time improving our developer system and programming the necessary PowerPC-native ANSI- and math-libraries as well as making sure that everything kept working in a stable and Amiga-compliant way. In the month of April we presented our first demos and the developer-system at a club-meeting in Heilbronn and at the "Magic Days" in Trier where we also held a few seminars that dealt with the problems that arise when programming the PowerUP-boards. At the show in Trier we spoke to Wolf Dietrich and Gerald Carda of Phase 5 and asked them to publicly discuss the choice of the object format and the concept of the PowerPC-interface. This idea was, as you might have guessed, rejected. The reason we were given was simple: "We have decided it that way and this way it will be done. There will be no discussion!" A short time after the show, a new version of the software-interface (PPC.library) was released by Phase 5 (we hadn't received any new version from the author for more than 3 months). We tested the new library and, as could be expected, our software would not run anymore. The changes made to the PPC.library had been so significant that even what had been a legal approach only a few months back was not usable anymore. In order to avoid further incompatitibilities with the Phase 5 solution, we compiled a list of requirements that would ensure Amiga-compliant access to the PPC.library in order to define a standardized interface to the PPC.library in cooperation with Phase 5. This list was discussed by our authors and Mr. Carda at Phase 5 (the author of the PPC.library had canceled at short notice), given a quick okay but not incorporated until this day! When presenting our solution and its capabilities at the same occasion, Phase 5 were amazed to see that our author Sam Jordan had accumulated a knowledge about the PPC that exceeded that of the Phase 5 developers and probably still exceeds it today. Four weeks later, a new version of the PPC.library was released that had a number of features that we had presented earlier in our solution. The suspicion that Phase 5 had "re-engineered" our software was not far-fetched. This version of the PPC.library was yet again incompatible to our solution, a fact that did not surprise us a lot anymore. As a consequence to the persistent ignorance of Phase 5, we decided to create our own software solution to entirely replace the PPC.library and to do so as soon as possible. This should not, however, mark the end of our willingness for cooperation. On June 5, 1997 the first version of our PowerPC- and Warp.library successfully worked after first removing the PPC.library from the LIBS:-directory! Up to this date we have still taken care to provide a solution that cooperates with the interface provided by Phase 5 - in the same way that was previously accepted and tolerated by Phase 5. The two further versions of the PPC.library by Phase 5 that reached us until this day again refused to work with our software-interface. Times and times again we had to adapt our software and add workarounds for bugs of the Phase 5 programming. As a highlight we must mention the change that was made to the library around the end of July. As we all know, Phase 5 had already announced the boards to be shipping in June. That date was getting delayed week by week. At the end of July, Phase 5 provided yet another version of the library - this time it was necessary to completely recompile any software that had already been created in ELF-format for PowerUP. We could not understand this at all, especially since the boards were scheduled to be shipping months earlier. By the way, developments that were based on StormC were not affected by this. Only a very small part of the compatible library had to be re-compiled to get everything up and running on the Phase 5 PowerUP again. The latest version of the PPC.library was provided to us together with the PowerUP consumer-board. It also included the first documentation for the "revolutionary" messaging system that was at least half complete. Developers that were planning to develop PowerUP-software could therefore only now start the development process. That is one of the reasons why there is no application software for PowerUP yet. Anything that had been developed earlier must now be changed in concept and re-programmed with a lot of effort. Developers that currently decide to program software for PowerUP using the Phase 5 approach must be aware that their software will most likely NOT run on PowerPC-boards of competing manufacturers and neither will it run on a potentially planned PowerPC-Amiga. The statement by Phase 5 in which they claim WarpUP to be a "Hacker Kernel" shows their fear of any potential competition. Very similar to what is happening now, Phase 5 denied ProDAD support a year ago. Phase 5 might counter this by saying that ProDAD also received a developer-board and were able to develop. What they won't tell you is that Phase 5 never laid open the hardware specifications - a dire necessity if you want to develop an operating system for the PowerUP-boards. Solutions and Ways For you as a user this discussion might be absolutely of no use at all. But if you want to buy a PowerPC-optimized software product and have to pay attention to whether it supports the PowerPC board of company X or Y, you will ask yourself why nobody cared to provide a standard for this right away. We as a software-company do neither have the time nor the necessary resources in order to provide software concepts for every new Amiga-hardware-platform. The same applies to many other companies, and that is why a hardware-independent interface between the 68K-operating-system and PowerPC-control-software must be defined. This definition must be made in a way that neither puts hard- nor software-companies at a disadvantage and that avoids any market-monopoly to arise. For this reason it is necessary to install an independent consortium that sets the necessary standards. Our proposition shows a possible way that can be flexibly adapted. As an independent software-developer we are of course willing to adapt our interface for other Amiga-PowerPC-platforms in order to ensure that the software will run. Support for the ELF-object-format is of course possible as well, if an independent consortium can be convinced of its advantage for the future of the Amiga. The arguments currently provided by Phase 5are not likely to convince any developer unless he plans to abandon Amiga-development and wants to orientate himself towards the A\BOX. Talking about industry standards and a list of development systems that could possibly be used on different and more expensive platforms completely misses the point. Phase 5 might be in the situation to be able to afford such development systems, but this will not cause development to become any faster. In our opinion, software development for the Amiga should continue to be made on the Amiga. It was some time ago, when the UK company Index that already holds a license for building Amiga-Clones and selling the AmigaOS, announced RISC-based accelerator-board. Every software developer who read this announcement has to consider the question whether applications must be adapted once, or once for every board. The software-solution by Phase 5 contains - from the point of an AmigaOS developer - so many significant changes (ELF-format instead of Hunk-Format, dynamic linking instead of shared-libraries) that it is virtually impossible for any other PowerPC-hardware-developer to also provide this interface. And the possibility of licensing the software from Phase 5 is highly questionable when looking at their current behavior and has not yet been announced by them. Only when a binding standard has been agreed on can software-houses start porting their software, certain in the knowledge that manufacturers of different PowerPC-boards will have to provide compatible solutions. Only then can the user be sure that nobody will try to have his own way. In shape of the PowerPC-boards by Phase 5, a first step into a wonderful Amiga-future has been made. However, we are of the strong opinion that theirs can not be the only solution and we are hoping for further manufacturers to risk entering the once-again blooming Amiga-market. It is only by means of the necessary competition that innovative development can be ensured. The accusation of Phase 5 that WarpUP is solely designed to favor StormC as the development system for PowerPC applications is simply false! Every developer of compiler systems has the chance to create a PowerPC-compiler. This compiler can write the Amiga-hunk-format like it always has. It is the programmer of the application (or, in the case of StormC, the runtime-system) who takes care of the specialties of the PowerPC and uses the PowerPC.library of WarpOS to handle these. Since the PowerPC.library is a 100% Amiga-compatible shared-library, it is usable by everybody. It is easily possible to use a different compiler for the 68K-part (e.g. SAS/C for an existing application) and the PPC-part (e.g. StormC-PPC for the ported parts) in one Mixed-Binary. We will be happy to help any company wanting to port their compiler for the PowerPC with the experience we have gained in the past two years. We are very interested in cooperation with Phase 5 and all other companies that want to make new PowerPC-developments, as well as in cooperation with Amiga International. At the same time we wish for a peaceful co-existence of alternative solutions IF these provide useful extensions and do not exclude a common application interface. Please tell us your opinion As Phase5 decided to go public with aggressive attacks against our solution, we would now like to know your opinion on that matter (after you read our response). Thanks a lot. warpup@haage-partner.com © 1997 HAAGE & PARTNER Computer - http://www.haage-partner.com ------------------------------------------- HAAGE & PARTNER WarpUP - Die Stellungnahme Die Philosophie der Amiga-konformen Software-Entwicklung Als Hersteller des StormC-Entwicklungssystems haben wir immer die Bestrebung, alle wichtigen Amiga-Entwicklungen mit unserem Entwicklungssystem zu unterstützen. Unsere Philosophie bei unseren Umsetzungen ist es, den Entwicklern ein Werkzeug an die Hand zu geben, das es ermöglicht, mit weitgehend geringem Aufwand die beste Lösung zu erzielen. Einen ersten Schritt in diese Richtung demonstrieren wir mit unserer Entwicklung von StormWIZARD für AmigaOS und p.OS und mit der p.OS-Unterstützung durch StormC. Entwickler, die StormC und StormWIZARD nutzen, haben es sehr einfach mit geringem Aufwand für beide Plattformen ein identisches Erscheinungsbild für ihre Software zu schaffen. Wirtschaftlich betrachtet ist das ein sehr wichtiger Faktor. Aber alternative Betriebssysteme sind nur eine Entwicklungsrichtung und ein neuer Prozessortyp eine ganz andere und wesentlich komplexere Angelegenheit. In knapp 2-jähriger Entwicklungszeit haben wir den nächsten Schritt vollzogen und eine Hardware-unabhängige PowerPC-Unterstützung fertiggestellt. Die Lösung, mit dem Namen WarpUP wurde am 26.09.97 auf unserer Homepage im Internet und am 28.09. auf dem Amiga-Treffen in Hof der Öffentlichkeit vorgestellt. Die Lösung wurde kurz zuvor, am 26.09. auch bei Phase 5 vorgeführt, denn wir waren und sind der Meinung, hiermit einen wertvollen Beitrag zur Unterstützung der PowerPC-Plattform zu leisten. Bei Phase 5 ist man jedoch offensichtlich nicht dieser Meinung und veröffentlichte am 28.09. ein sehr emotionales Schreiben, in dem die Auflösungen der Zusammenarbeit angekündigt und Lösungen wie WarpUP und StormC als unbrauchbar bezeichnet wurden. Reaktionen wie diese von Phase 5 sind jedoch sehr unproduktiv. Sie bringen den gerade wieder neu belebten Amiga-Markt durcheinander und helfen weder den Amiga-Firmen noch den Amiga-Anwendern. Die Angriffe seitens Phase 5 gegen unser WarpUP-Paket sind unserer Meinung nach eine unüberlegte Überreaktion. Entgegen der Darstellung durch Phase 5 besteht unser Paket sowohl aus einer zur Phase 5 Lösung kompatiblen als auch aus einer alternativen Lösung. Der Anwender hat hier die Entscheidung, welche Lösung er bevorzugt. Die kompatible Lösung war bei Phase 5 immer bekannt und wurde auch geduldet, um so unverständlicher ist für uns deren angekündigte Absage einer weiteren Unterstützung und die Herstellung einer absichtlichen Inkompatibilität zu unserer Lösung. Statt dem konsequenten Ausschluß einer Softwarelösung muß dem Anwender die Möglichkeit geboten werden, durch Ausprobieren eigene Erfahrungen zu sammeln und gemeinsam vernünftig über Vor- und Nachteile aller Möglichkeiten zu diskutieren. Wer diese Freiheit verwehrt, zeigt diktatorische Züge mit dem Hintergrund, sich vor Konkurrenz zu schützen. Wir bieten allen interessierten Anwendern und Entwicklern Einblick in unsere Entwicklung. Das komplette Archiv mit Demoprogrammen, die auch auf einem 68K-Amiga (ab 040er) lauffähig sind und einer bereits vielfach gelobten Dokumentation, die von allen selbst beurteilt werden kann, stellen wir auf unserem FTP-Server kostenfrei zur Verfügung. Unsere Entwicklung zeigt eindrucksvoll, daß keine Notwendigkeit dazu besteht, ein neues Executable-Format oder Verfahren zur dynamischen Anbindung von Bibliotheken zu schaffen. Das Amiga-Betriebssystem bietet seit jeher alle Eigenschaften, die benötigt werden, um neue Prozessortypen zusammen mit oder ohne dem vorhandenen 68K-Prozessor zu nutzen. Die Hinweise seitens Phase 5 zur Einführung solcher neuen Techniken für neue OS-Versionen müssen Sie als aufmerksamen Leser unverkennbar von deren Absichten überzeugen, in naher Zukunft das AmigaOS durch eine eigene Entwicklung abzulösen. Die Rechte zur Weiterentwicklung des Amiga-Betriebssystems liegen bei Amiga International, die diese mit Sicherheit nicht für eine abweichende Entwicklung aus der Hand geben werden. Bei allen notwendigen Diskussionen zur Schaffung einer standardisierten PowerPC-Schnittstelle für das AmigaOS darf nie vergessen werden, daß es die Anwender sind, die unseren Amiga am Leben erhalten und keine einzelne Hard- oder Software-Firma. Am Ende der Diskussion muß es also heißen: "Und die Gewinner sind: Die Amiga-Anwender". Im folgenden Text finden Sie einen tieferen und technischeren Einblick in den Verlauf unserer Entwicklung von WarpUP und StormC für den PowerPC. Die Entwicklungsgeschichte von WarpUP Zur Computer 95 in Köln vor fast zwei Jahren kündigte damals noch Amiga Technologies neue Amiga Modelle auf der Basis von PowerPC-Prozessoren an. Zeitgleich veröffentlichte Phase 5 auch erste Mitteilungen über das Erscheinen von PowerPC-Turboboards für alle bereits im Markt verfügbaren Amiga-Modelle. Für uns war das die Entscheidung, auch unser Entwicklungssystem PowerPC-tauglich zu machen. Die Entwicklung an StormC-PowerPC begann im März 1996 direkt nach der CeBit. Die Konzepte, die wir uns damals erarbeiteten, sahen vor, so nah wie möglich am Betriebssystem AmigaOS festzuhalten, was kein Problem darstellte. Wir kamen daher nie auf den Gedanken, ein verändertes Executable-Format zu nutzen, schon gar nicht ohne offizielle Entscheidung der damaligen Eigner aller Rechte am Betriebssystem. Unsere Konzeption sah auch vor, schnell auf mögliche Veränderungen im OS und dessen Applikationsschnittstelle reagieren zu können, um den Software-Entwicklern komplizierte Umarbeitungsarbeiten zu ersparen. Leider geriet Amiga Technologies in dieser Zeit ein zweites Mal ins Straucheln, was sich auch durch die zunächst solvent präsentierte Firma Viscorp nicht veränderte. Ein Beginn der Weiterentwicklung des Betriebssystems und der Bau der lange erwarteten PowerPC-Amigas blieb aus. Ebenfalls ausgeblieben ist daher die Definition der Richtlinien der Schnittstelle für PowerPC-Amiga-Applikationen. Wir ließen uns dennoch nicht beirren und entwickelten Amiga-konform weiter, da unsere Lösung keine Veränderung des bestehenden Betriebssystems voraussetzte. Durch die Ankündigung von Phase5, ein Dualprozessorboard mit einem 68K und einem PowerPC im parallelen Betrieb zu bauen, ergab sich die dringende Notwendigkeit sogenannte Mixed-Binaries zu unterstützen. Diese Programmform enthält in einem Programm sowohl 68K- wie auch PPC-Code. Im optimalen Fall ist es für den Entwickler eines Programms völlig irrelevant, welche Teile des Programms in welcher Codeform vorliegen. Der Zugriff auf Daten (z.B. globale Variablen) ist problemlos durch beide Prozessoren möglich, der Wechsel von einem Prozessor auf den anderen geschieht vollautomatisch, ohne zusätzliche Programmierung. Der Entwickler entscheidet nur, welcher Programmteil sinnvollerweise auf dem PPC arbeitet (z.B. der Raytracer-Kern oder Konvertierungsfunktionen für Graphikformate etc.) und welche Teile in 68K bleiben (z.B. die Ansteuerung der graphischen Benutzeroberfläche). Dabei sollte es auch wenig stören, wenn diese Codeteile eng verzahnt sind, d.h. gemeinsame Variablen und Datenstrukturen benutzen, Rücksprünge aus dem einen Teil in den anderen über sogenannte Funktionspointer erfolgen etc. Zu unserer Überraschung wählte Phase5 mit der Nutzung des ELF Formats einen Weg, der diese dringend notwendigen (und von Phase5 sogar empfohlenen) Mixed-Binaries zu einer Qual für den Programmierer macht: Der PPC Programmteil muß manuell nachgeladen werden; Nutzung gemeinsamer globaler Variablen ist nicht möglich; Datenstrukturen werden von den gängigen 68K Compilern anders interpretiert als vom GNU-C für PPC und können deshalb nicht gemeinsam genutzt werden; Rücksprünge über Funktionspointer oder auch normale Wechsel von einer CPU auf die andere müssen manuell programmiert werden. Alles in allem ist es ein sehr langer Weg, ein existierendes AmigaOS Programm auf die Phase5 Lösung zu portieren. Nicht umsonst konnte - trotz fast einjähriger Vorlaufzeit mit Hilfe der speziellen PPC-Developerboards, die an einige ausgesuchte Entwickler vergeben wurden - bislang keine größere Applikation portiert werden. WarpOS und StormC erreichen jedoch nach nun fast 18-monatiger Entwicklungszeit genau diese optimale Strategie der Erstellung von Mixed-Binaries. Der Entwickler zerlegt sein Programm in einen 68K- und einen PowerPC-Teil, im einfachsten Fall durch Einteilung der Programmodule (C-Quelltexte) in die jeweilige Kategorie, im aufwendigsten Fall durch Zerlegung einzelner Programmodule in jeweils zwei neue (für 68K- und PPC-Code). Dann muß nur noch neu kompilieren werden und schon hat man das fertige Programm. StormC und StormLink übernehmen den ganzen Rest. Aus den 68K- und PPC-Teilen wird ein einziges Executable erzeugt, d.h. ein Nachladen der PPC-Programteile entfällt. Durch den gemeinsamen Zugriff auf globale Variablen und die kompatible Interpetation der Datenstrukturen durch den 68K- und PPC-Code muß am Quelltext nicht eine Zeile geändert werden. Kontextwechsel von einer auf die andere CPU werden vollautomatisch generiert, der Programmierer muß nicht einmal wissen, wo genau dieser Kontextwechsel stattfindet. Mitte Oktober vergangenen Jahres war es dann soweit. Phase 5 überließ uns zwei PowerPC-Entwicklerboards und eine sehr rudimentäre Software-Schnittstelle zum PowerUP-Board. Trotz der Einfachheit der Softwareschnittstelle wich sie von unseren und damit von den Amiga-konformen Konzepten soweit ab, so daß wir bereits zu Beginn der praktischen Entwicklung mit Wissen von Phase 5 unseren eigenen Weg gehen mußten, um die Konzeption des AmigaOS aufrecht zu erhalten. Es war zwar nicht der von Phase 5 vorgeschlagene, aber ein möglicher und flexibler Weg und man hatte dagegen vorerst nichts einzuwenden. Bereits auf der Computer 96 zeigten wir erste Entwicklungen mit StormC und StormPowerASM, die auf dem bewährten Amiga Hunkformat basierten und tadellos funktionierten. In der Praxis stellte sich sehr schnell heraus, daß die Geschwindigkeit des PowerPCs gar nicht so deutlich zu spüren war wie wir erwartet hatten, was an den kompliziert zu handhabenden AmigaOS-Aufrufen lag, bedingt durch die Dualprozessortechnologie, die Phase 5 einsetzt. Pro Funktionsaufruf ist es nötig, einen Kontextwechsel zur 68K CPU zu machen, die 68K-Betriebssystemfunktion auszuführen und mit einem weiteren Kontextwechsel zum PowerPC-Programm zurückzukkehren. Bei jedem Wechsel ist selbstverständlich ein leeren des Daten-Cache nötig, das erneut sehr viel Zeit verschlingt. Nach unserem Verständnis wäre eine Beschleunigung des Kontextswitch mit einer Erweiterung der Hardware lösbar gewesen. Bei Phase 5 stieß unser Vorschlag jedoch auf taube Ohren, worüber wir uns nur wundern konnten. Gleichzeitig baten wir darum, tieferen Einblick in die Hardware-Eigenschaften zu bekommen, um bei der Lösung der Problematik behilflich zu sein. Diese Bitte nach der Offenlegung der Hardware-Beschreibung wurde, wie auch alle weiteren Bitten, mit dem Hinweis abgelehnt, daß durch Phase 5 jederzeit Hardware-Änderungen gemacht werden könnten, die dann nicht mehr funktionieren würden. Dann würde Software, die direkt auf die Hardware abgestimmt wäre, nicht mehr funktionieren. Lediglich bei ihrer eigens entwickelten Software wäre es garantiert, daß eine sofortige Anpassung stattfinden kann. Für uns als Software-Hersteller war das eine unbefriedigende Antwort, macht man damit lediglich klar, daß auch die Software-Seite monopolistisch überwacht werden soll, um Konkurrenten fernzuhalten. Wir hatten bereits damals die Vermutung, daß Phase 5 dieses Argumentation nutzen wird, um ungewollte Entwicklungen diskussionslos zu verdrängen. Wir sind daher auch wenig überrascht über die diktatorischen Maßnahmen von Phase 5, die jetzt gegen unsere Entwicklung angekündigt wurden. Noch im Dezember vergangenen Jahres erarbeitete unser Entwicklerteam, allen voran Sam Jordan und Michael Rock eine Lösung, die den Kontextwechsel gegenüber der Lösung von Phase 5 drastisch verbessern sollte. Bereits im Januar diesen Jahres hatten wir einen sehr stabilen Aufsatz zur Phase 5 Software lauffähig, der eine Kontextwechselzeit von im Schnitt 0,5 Millisekunden gegenüber 60 bis 90 Millisekunden der Phase 5 Lösung brachte. Diese verbesserte Technik brachte für alle Applikationen, die wir nun 1:1 umsetzen konnten, eine unserer Meinung nach ausreichende Beschleunigung auf der PowerPC-Seite. Für alle Applikationen, die mehr Geschwindigkeit aus dem PowerPC herausholen sollen, ist eine spezielle Programmierung sowieso nötig. Die Entwickler müssen sich dann allerdings im klaren sein, für eine sehr kleine Zielgruppe einen enormen Aufwand treiben zu müssen, der sich auf dem Software-Markt für Dual-Prozessorboards kaum rechnen wird. Wir waren damals und sind auch heute noch der Überzeugung, daß zukünftige Amigas mit nur einem Prozessor ausgestattet sein werden, egal von welchem Hersteller diese Prozessoren kommen. Wir verbesserten in der darauffolgenden Zeit unser Entwicklunssystem, programmierten die nötigen PowerPC nativen ANSI- und Mathematik-Bibliotheken und achteten weiterhin darauf, daß alles Amiga-konform und stabil funktionierte. Im April präsentierten wir unsere ersten Demos und das Entwicklungssystem auf der Clubmesse in Heilbronn und bei den Magischen Tagen in Trier, wo wir auch erste Informationen zur Problematik in Vorträgen veröffentlichten. Wir sprachen vor der Messe in Trier mit Wolf Dietrich und Gerald Carda von Phase 5 und baten die Wahl des Objektformates und die Konzeption der PowerPC-Schnittstelle öffentlich zur Diskussion zu stellen, was sie, wie Sie erahnen werden, abgelehnt haben. Ihre Begründung war lapidar: Wir haben das so entschieden und genau so wird es gemacht. Es gibt keine Diskussion! Kurze Zeit nach der Messe kam dann eine neue Version der Software-Schnittstelle (PPC.Library) von Phase 5 (der Autor hatte bereits seit 3 Monaten keine neue Version mehr an uns geliefert). Wir testeten diese Lösung und wie zu erwarten, war unsere Software nicht mehr lauffähig. Die Änderungen in der PPC.Library war so tiefgreifend, daß selbst der noch wenige Monate zuvor erlaubte Weg nicht mehr nutzbar war. Um weiteren Inkompatibilitäten zur Phase 5 Lösung vorzubeugen, stellten wir einen Anforderungenkatalog für einen Amiga-konformen Seiteneinstieg in die PPC.Library zusammen, um gemeinsam mit Phase 5 eine standardisierte Schnittstelle in ihrer PPC.Library zu schaffen. Die Liste wurde von unseren Autoren mit Herrn Carda bei Phase 5 diskutiert (der Autor der PPC.Library hatte kurzfristig abgesagt), kurz abgenickt, aber bis heute nichts umgesetzt! Bei der zeitgleichen Vorführung unserer Lösung und der Demonstration der Eigenschaften wurde sehr erstaunt zur Kenntnis genommen, daß sich unser Autor Sam Jordan in der Zwischenzeit ein PowerPC-Wissen angeeignet hatte, das die Fähigkeiten der Phase 5-Entwickler übertraf und wahrscheinlich heute noch übertrifft. Vier Wochen nach diesem Treffen erschien eine neue Version der PPC.Library mit einigen Features, die wir zuvor in unserer Lösung präsentiert hatten. Der Verdacht des "Re-Ingeneerings" durch Phase 5 lag nahe. Auch diese Version der PPC.Library war wieder zu unserer Lösung inkompatibel, was uns ebenfalls wenig überraschte. Als Konsequenz auf die Ignoranz von Phase 5 entschlossen wir uns, so schnell wie möglich eine Softwarelösung zu schaffen, welche die PPC.Library völlig ersetzt. Für unsere Bereitschaft zur Kooperation sollte das allerdings keinen Abbruch bedeuten. Am 5. Juni 1997 lief die erste Version unserer PowerPC- und Warp.library, nachdem zuvor die PPC.Library aus dem LIBS:-Verzeichnis entfernt wurde! Bis zum heutigen Zeitpunkt haben wir dennoch Sorge dafür getragen, unter extremen Bedingungen eine Lösung bereitzustellen, die weiterhin mit der Phase 5 Schnittstelle zusammenarbeitet, wie sie auch durch Phase 5 geduldet wurde. Die beiden weiteren Versionen der PPC.Library von Phase 5, die bis zum heutigen Tage bei uns eintrafen, verwehrten ebenfalls unserer Software-Schnittstelle den Dienst. Immer wieder mußten Anpassungen vorgenommen und Fehler in der Phase 5-Programmierung umgangen werden. Als Höhepunkt ist die Veränderung der Bibliothek von Ende Juli zu erwähnen. Wie wir alle wissen, hatte Phase 5 bereits zum Juni die Auslieferung der Boards angekündigt. Das verzögerte sich jedoch immer wieder von Woche zu Woche. Ende Juli wurde nun wieder eine Bibliothek von Phase 5 bereitgestellt, die es zwangsläufig notwendig machte, daß jede Software, die bereits unter PowerUP im Elf-Format entstanden war, neu kompiliert und gelinkt werden mußte, um wieder mit der aktuellen Softwareschnittstelle kompatibel zu sein. Für uns war das eine unverständliche Vorgehensweise, hatte man doch bereits Monate zuvor die Auslieferung der Boards geplant. Übrigens waren die Entwicklungen, die auf StormC basieren, nicht davon betroffen, da lediglich ein kleiner allgemeiner Programmteil der kompatiblen Bibliothek von uns neu kompiliert werden mußte, um alles wieder unter Phase5-PowerUP lauffähig zu machen. Die letzte Version der PPC.Library erhielten wir nun zusammen mit dem PowerUP-Serienboard. Auch die erste, halbwegs vollständige Dokumentation zu dem angeblich revolutionären Messagesystem war dabei enthalten. Entwickler, die vorher planten, PowerUP-Software zu entwickeln, können demnach erst jetzt mit der Entwicklung beginnen. Ein Grund, warum es noch keine Anwendersoftware für PowerUP gibt. Wenn bereits entwickelt wurde, muß jetzt die Konzeption der Anwendersoftware neu überarbeitet und mit viel Aufwand neu programmiert werden. Entwickler, die sich momentan dazu entschließen, Software für PowerUP mit der Phase 5-Lösung zu programmieren, müssen zwangsläufig damit rechnen, daß Ihre Software NICHT auf PowerPC-Boards anderer Hersteller und auch auf einem eventuell geplanten PowerPC-Amiga läuft. Das Statement von Phase 5 in dem von WarpUP als einem "Hacker Kernel" gesprochen wird, zeigt deren Angst vor einer möglichen Konkurrenz. Ähnlich wie es zur Zeit gegen uns geschieht, wurde der Firma ProDAD bereits vor einem Jahr die Unterstützung durch Phase 5 verweigert. Phase 5 wird nun natürlich mit dem Hinweis kontern, daß auch ProDAD ein Entwickler-Board erhalten habe und durchaus entwickeln konnte. Was dem Anwender jedoch verschwiegen wird ist, daß Phase 5 nie die Hardwarebeschreibung offengelegt hat, was nötig ist, um eine Betriebssystem-Entwicklung für PowerUP-Boards vorzunehmen. Es sei denn es wird zu einer Entwicklung, die von Phase 5 gewünscht ist. Lösungen und Wege Für Sie als Anwender mag die Diskussion, die momentan entbrennt, überflüssig sein. Aber spätestens dann, wenn Sie ein Softwareprodukt einsetzen möchten, das PowerPC optimiert ist und Sie beim Kauf darauf achten müssen, ob es für das PowerPC-Board der Firma X oder Y geeignet ist, fragen Sie sich doch, warum man sich nicht rechtzeitig auf einen einheitlichen Standard geeinigt hat. Wir als Software-Firma haben nicht die Zeit und die nötigen Ressourcen, um für jede Amiga-Hardware-Plattform neue Softwarekonzepte erarbeiten zu können. Anderen Firmen geht es genauso, weshalb zunächst eine Hardware-unabhängige Schnittstelle zwischen 68K-Betriebssystem und PowerPC-Steuersoftware definiert werden muß. Diese Definition muß so ausfallen, daß weder Hard- noch Softwarehersteller benachteiligt sind und eine Monopolstellung im Markt vermieden wird. Erfoderlich ist die Bildung eines unabhängigen Gremiums, das diese Aufgabe übernimmt. Mit unserem Vorschlag zeigen wir einen möglichen Weg, der flexibel angepaßt werden kann. Als unabhängiger Software-Entwickler sind wir selbstverständlich Willens, unsere Lösung auch für andere Amiga-PowerPC-Plattformen umzusetzen, um die Lauffähigkeit der Amiga-PowerPC-Software zu gewährleisten. Auch eine Unterstützung des Elf-Objekt-Formates ist denkbar, wenn man ein unabhängiges Gremium von dessen Vorteil für den zukünftigen Amiga-Markt überzeugen kann. Die Argumente seitens Phase 5 können zur Zeit keinen Entwickler überzeugen, es sei denn, er plant den Ausstieg aus der Amiga-Entwicklung in Richtung A/Box. Von einem Industriestandard und einer Liste mit möglichen nutzbaren Entwicklungssystemen auf anderen und teuren Plattformen zu reden, ist lediglich Augenwischerei. Phase 5 ist vielleicht in der glücklichen Lage, sich entsprechende Entwicklungssysteme leisten zu können, aber schneller entwickeln werden sie deshalb nicht. Unserer Meinung nach sollte die Software-Entwicklung für den Amiga weiterhin auf dem Amiga stattfinden. Vor geraumer Zeit hat die englische Firma Index, die bereits eine Lizenz für Amiga-Clones und das AmigaOS erworben hat, ebenfalls RISC-basierte Turbo-Boards angekündigt. Jeder Software-Entwickler, der diese Ankündigung gelesen hat, muß sich auch mit der Frage beschäftigen, ob Applikationen allgemein oder für jedes Board extra angepaßt werden müssen. Die Softwarelösung von Phase5 enthält - aus Sicht eines AmigaOS Entwicklers - so viele tiefgreifende Neuerungen (ELF-Format statt Hunk-Format, Dynamic linking statt Shared-Libraries), daß es für einen weiteren PowerPC-Hardware-Entwickler nahezu unmöglich ist, diese Schnittstelle ebenfalls zur Verfügung zu stellen. Und die Möglichkeit der Lizensierung bei Phase5 ist bei deren derzeitigem Verhalten fragwürdig und bislang auch nicht angekündigt. Erst wenn ein allgemeiner Standard erarbeitet ist, können Software-Häuser beruhigt Software umsetzen, hat man doch dadurch die Gewißheit, daß sich Hersteller anderer PowerPC-Boards ebenfalls kompatibel verhalten müssen. Der Anwender kann sich dann sicher sein, daß keiner einen Alleingang realisieren kann. Mit den PowerPC-Boards von Phase 5 ist ein erster Schritt in eine wundervolle Amiga-Zukunft getan. Wir meinen allerdings, daß dies nicht die einzige Lösung sein kann und hoffen auf weitere Hersteller, die im wieder aufblühenden Amiga-Markt einen Einstieg riskieren. Denn nur durch die notwendige Konkurrenz ist eine innovative Entwicklung gewährleistet. Den Vorwurf von Phase 5, mit WarpUP unser Entwicklungssystem StormC für PowerPC-Applikationen favorisieren zu wollen, müssen wir entschieden zurückweisen. Jeder Hersteller von Entwicklungssystemen hat die Möglichkeit, einen PowerPC-Compiler zu erzeugen. Dieser Compiler kann wie gewohnt das Amiga-Hunk-Format schreiben. Erst der Programmierer einer Applikation (oder wie im Falle von StormC: das Laufzeitsystem) kümmert sich um die Spezialitäten des PowerPCs und benutzt dazu die PowerPC.library von WarpOS. Da es sich bei dieser Bibliothek um eine 100 % kompatible AmigaOS Shared-Library handelt, steht die Nutzung dieser Bibliothek jedem offen. So ist es durchaus denkbar, zwei verschiedene Compiler für den 68K-Teil (z.B. SAS/C bei einer bestehenden Applikation) und den PPC-Teil (z.B. StormC-PPC für die portierten Teile) in einem Mixed-Binary einzusetzen. Wir sind gerne bereit, jeder Firma, die ihren Compiler für den PowerPC umsetzen will, mit unserer, in den letzen 2 Jahren gewonnen Erfahrung zu helfen. Wir sind sehr an einer Kooperation mit der Firma Phase 5 und allen anderen Herstellern, die PowerPC-Entwicklungen umsetzen möchten sowie an einer Zusammenarbeit mit Amiga International interessiert. Ebenso wünschen wir uns eine Koexistenz alternativer Lösungen, wenn damit sinnvolle Erweiterungen bereitgestellt werden und eine allgemeingültige Applikationenschnittstelle davon nicht ausgeschlossen wird. Sagen Sie uns Ihre Meinung Da Phase5 sofort mit einer Stellungnahme and die Öffentlichkeit ging, die unser Lösung scharf attakierte, würden wir jetzt - nachdem Sie auch unsere Darstellung gelesen haben - gerne Ihre Meinung zu diesem Thema erfahren: warpup@haage-partner.com © 1997 HAAGE & PARTNER Computer - http://www.haage-partner.com · · _ __\ /__ _ _ _)\\ \ / //(_ _ -\ __\° X °/__ /- _ __ ___ ___) \/_\/ (___ ___ __ _ ((- \ - -\\\_\\__\\__ _ /¦\ _ __//__//_///- - / -)) _. \__)_¯_¯_(__/ ._ _/ \|_ | | | | | _|/ \_ __\ ___ _/\____\/__ __ _| | | | |_ __ __\/____/\_ ___ /__ _/ \ (_) \_ \/ /_/\\| |_|_| |//\_\ \/ _/ (_) / \_ | \_\/ | | | | | \/_/ | _|___ __ | | | | | __ ___|_ \|__/ \/_| | | | |_\/ \__|/ | · _) ¯_¯_¯ (_ · | | ·H2o!· \\___ \ / ___// | ¯\_______________________ _) Y (_ _______________________/¯ __ \___ ___/ __ - -->\__ fRIENDS oNLY! <<- (_) ->> fRIENDS oNLY! __/<-- - ÷ n O R T H E R N p A L A C E ÷ ________ _______ ________ ____ ______ _______ _______ ________ ____\_ // _ \\_ // |_ ___| //_ //_ /_\_ / \ / / / _/ / _/ _| /____/ _/ / / / /____/______\_________\ _____\_____|____\. _________\ _______/______\ \/ cDr|_____|m's \/ ________ _______ _______ _______ ______ _______ ____\_ // _ \\ // _ \\ _//_ /____ \ /____/ ./ / ./ \ /____/ / /_______|_______|_______________|_______________________\ A4040/26mB/9.5gB/cD-rOM/2x33.6dS/1x28.8dS/tELNET/aMIGA/aSCII/cONSOLE/mAC tRSI rECORDZ hQ ÷ aFTERSHOCK hQ ÷ hOODLUM hQ ÷ mOT!ON hQ ÷ rOYAL hQ tRADERS dREAM hQ ÷ sTYLE hQ ÷ lSD hQ ÷ 5tH dYNASTY hQ ÷ aBUSE hQ aRTWORK eHQ ÷ oLDSKOOL hQ ÷ x-tREK sCHQ ÷ tWILIGHT hQ ÷ oMA hQ pOLKA bROS. wHQ ÷ pUZZLE wHQ ÷ kEFRENS wHQ ÷ lOOKER hOUSE eHQ rOYAL MAC SCHQ ÷ cRUX & bAD kARMA hQ ÷ lIGHTFORCE hQ aRSENIC hQ ÷ sAVE oUR sOULS hQ zINKO/pLAYMATE/sISKO/bILBO bAGGINS/bLACK pANTHER/uFOK/fURY/kELDOn 3 nODEZ rINGDOWN / tELNET aVAILABLE / aSK 4 nUMBERS! _/\_ _____ ____ ______\__/____ dNo/jA! ____ __ ______ ___\ _ | | /____\ _ |-------| |`--'| _ / |__ \/ | --|- _ /|__ \/ | __ | --|- | \/| .-`--'-----'----'--\/-'--'-----'---'---'----'----'-----'-. | ÷ a ÷ t ÷ l ÷ a ÷ n ÷ t ÷ i ÷ c ÷ | | --- CBK --- STS --- RYL --- LFC --- X!TREK --- GNX --- | | Absolutly one of the fastest in Europe! | rUNNING 4nODES + 4tELNET (24H) Node1: [-- +46-XX-XXXXXX--] Node2: [-- +46-XX-XXXXXX--] Node3: [-- +46-XX-XXXXXX--] Node4: [-- +46-XX-XXXXXX--] Node5: [-- FIND ME ON IRC-] Node6: [-- FIND ME ON IRC-] Node7: [-- FIND ME ON IRC-] Node8: [-- FIND ME ON IRC-] SUPPORTING : AMIGA - PEZE - N64 [MorphADD by Icarus/TRSi Version 1.05] USER: ATLANTIC POWER --------------------------------------------------- - ------------------------ THIS FILE CAME FORM -+- DIGITAL-X DHQ ¸µµm ------------- -- - ____µµµµµµµµµµµµ___ - -- ---- -- - ÆØØØ# - -- --------- __æÑØØØØØØØØØØØØØØØØØØØØÑæµ__ Ø#WØØØ®____ æØØØØØØØØØØØØØØØØØØØØØØØØØØØØØØm_ æØØØØØØØØØP~ ,ÆØØØØØØØØØØØØØØØØØØØØØØØØØØØØØØØØØL æØØØØØØØØØP jØØ##ØØØØØØØØØØØØØØØØØØØØØØØØØØØØØØØ _ØØØØØØØØØ" ¶ØØØØØØØØØØØÑ@@@@@@@ÑÑØØØØØØØØØØØØØØ# ,ØØØØØ@¶ÑØØ#" JØØØØØF _ÆØØ mØ ¤ÑØØØØØØ ¸ØØØ#" ,ØP¯¬# #ØØØØØ4_ ¶ØØØØØ@ ØØØØ ¬ÑMØF ÆØØ# _µØ@ æ" ¬WØØØØØØQ ¬"" ¯¯ _Ø*´ÆØØØbµµ*M¶¶¶µÆwwe ¶ØØØØØØ#µæ# ¸æ° JØØØØØ° ¸# ¬#mµ_µm_ _µæ##wm#ØL__ ,mmmmmææ _Æ# ,ÆØØØØ" µ° _µm¶°¯ ¶ç __µæw**¶°" "¶E5¶#w__ÑØP"¯__µÆ#¶F ,ØØØØØÞ J _æP"'_æÆØØæm®N__m¸ ¶¶Nµ__ ""°¶*wQM^maæØ°¯ #_æØ#Z°°¶Ñ_ æW__Æ"__æØØØØØØØØØØ@¶° ¶F"¶° ¬°¶*w# Øm_F°¶#µ# ¬¶¤° °¨2ØØØØØØØØØ@" æ ©Mt ¶KØ __Ø" ¯"°#ØØ#° F ,µ* 0@w ¶¶*mµµ*°¶*mwµ___æ~ ° _K f¶k ¬# ' _ µÆ""" a*" # ¶L `#_ _µw^" _J° ¬L ¶K ¬Ñw _æØ° 0*=¢mwµµ___ ¶_¬Øk ¶NØ# ¬¶ØØØm_ ¬""°¶¶Ñ#__ ¶Øb_ ØØØØ# " ¶ØØæw -- -- - _ØØØ@" - -- --- ---- ------------------------------------------------ _Ø@° [1] +31-057-637050 28k8 USR [2] +31-570-636468 57k6 USR DS ----------------------------------------------------------------------------- Uploaded on 26-Dec-97 at 00:57:01 on line # ¢ Done by BALTIMORA Who called from DiGiTaL-X NVR/CBD/DO------------------------------------------------------------ ----------------------------------------------------------------------------- [A¡RaDDer v3.5 By A¡Rcø]