Why WarpOS and Warp3D have problems with Blizzard PPC ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Written by Harry Sintonen, Copyright © 2003. rev 2 Reintented for clarity in December 2009. Quotes from WarpOS_english.guide © Sam Jordan > March 1998: > > At the end of march we get another blow: Phase5 releases the BlizzardPPC > hardware and puts the ppc.library into the Flash ROM. It is started at > boot time and can't be deactivated. As a consequence, WarpUp doesn't > work on these boards and the customers even can't test our software. > Their free choice is removed. WarpUp looses even more terrain. > > As it turned out later the BlizzardPPC flash ROM not only causes problems > with WarpUp but also leads to a huge incompatibility to old software, like > old games, which simply can't handle the setup done by the 68040.library > and the ppc.library. At the time this document is written nothing has > changed yet. This is plain bollocks. First of all: Putting ppc.library to flashrom was in no way anti-WOS measure. The A1200 already had 68040/68060 and other modules in the flashrom since A1200 was considered plug'n'play system. Also, the idea was to provide working system even if you'd boot without the HDD. The ppc.library itself does very small changes to setup with just 680x0 libraries. Second: 68040 and 68060 systems does not work reliably without proper MMU setup. This stuff was found out by Mike Sinz decade ago when he developed the original 68040 library (see enforcer.lha [1], Enforcer.guide/COPYBACK_DMA for futher details). Additionally 68060 does not implement all 68k opcodes previous models did, so ISP060 and 060FSP emulation packages need to be installed. These packages require proper MMU setup to function properly. And finally, you can completely disable the Blizzard PPC card by pressing '2' during powering the system up. This way the system downgrade to 68EC020 and the flashrom 680x0 libs or ppc.library are not loaded. > July 1998: > > Again WarpUp is knocked out completely: a new flash ROM appears which > cares for full incompatibility to WarpUp. But even this obstacle is > bypassed and a new provisional solution is developed. The powerpc.library > V14.6 is released ans remains the latest WarpOS implementation for a long > time. ppc.library is driver software provided by the hw manufacturer. If 3rd party sw hack rely on some magic stuff, it can only be expected to break when the hw manufacturer release updates. In no way the hw manufacturer is obliged to maintain compatibility with such unofficial hacks. Next, I will address some issues that have been claimed to be caused by "buggy ppc.library" or to be "anti-WOS" features of some kind. Crashes at LoadSeg ~~~~~~~~~~~~~~~~~~ ----8<-----------------------------------------------------------------[2]-- From: Sam Jordan Subject: Re: Amiga Format's WarpUp vs PowerUP Date: 1998/03/20 Message-ID: <3512B443.3B2B@haage-partner.com>#1/1 Content-Transfer-Encoding: 7bit References: <3511214E.F62@hate.spam.com> <3511A7D8.1A83@haage-partner.com> <351130AF.DBD@hate.spam.com> X-Cache: nntpcache 2.3.2.1 (see http://www.nntpcache.org/) Mime-Version: 1.0 Cache-Post-Path: www!unknown@pcinf42.htlchur.ch Content-Type: text/plain; charset=us-ascii X-Complaints-To: news@ubnnews.unisource.ch X-Trace: ubnnews.unisource.ch 890385749 5437 (None) 194.6.161.227 Organization: Telecom Labor, Swisscom AG Newsgroups: comp.sys.amiga.programmer Steven Matty wrote: > > > Another load of BS. phase 5 don't sell SOFTWARE > > > They have no financial advantage in disabling > > > WarpOS! > > Do you know what? Very soon you will be *VERY* surprised > > (and disappointed ?) > > How? Please provide more details. I still think my > statement that phase 5 will not gain any money > or any more hardware sales by altering the hardware > so that WarpOS no longer runs. Then we have to look for other reasons while they *did* attempt to disable WarpUp. > > Here I am. Please have a look at newer Phase5 boards (for > > example all Blizzard boards) to see what happened. And I > > wonder if you will also support this new coup of P5. > > I don't have a Blizzard board. Please send me one and > I'll have a look at it. What should I be looking for? > > if OpenLibrary("powerpc.library") return(0); ? At library initialisation, the powerpc.library checks for the existance of the ppc.library and then returns 0. In the new version (V14) I even implemented an easy requester which politely tells the user that running WarpOS in parallel to the ppc.library is impossible and that the user should make sure, that the ppc.library is not opened when using WarpUp- applications. This requester is of no use anymore, because it even pops up if no application opens the ppc.library. ppc.library is opened at boot time and is placed in nonvolatile memory. This was confirmed by several people. > Again, phase 5 are doing something bad, but you > neglect to go into detail. Why? OK, I have some time to discuss this topic. After that I will leave the discussion since I'm using news at scool and we've got soon holiday. I expect this letter to be a start of new discussion which should discuss the question, why could Phase5 be interested in eliminating WarpUp for their new boards. At the beginning, let me say, that this is not definitively the end of the WarpUp existance for new Phase5 boards. Even if it has become impossible to integrate WarpUp into the system in a system compliant way, it should be possible to make WarpUp working on these boards. It's not a problem at all to gain control over the hardware (i.e. resetting PPC etc.) even if ppc.library is running, but we never allowed that, because this would potentially lead to an instable situation, as soon as any application would try to use the ppc.library if WarpOS has been launched. Now, the only possibility is to try to finish any ppc.library activity and that's in test phase now. This is not a clean solution at all, but the only one, as it seems. And it would probably work fine and stable. Now let's come to the question why the ppc.library was put into ROM. I personally can't find any reason, why this should give any advantage to the user or to the programmer. Additionally, putting ppc.library into ROM doesn't prevent alternative OS such as Linux or NetBSD to reboot the AMIGA to launch these OS. As a conclusion, the only effect of putting the ppc.library into ROM space is to make it impossible to let WarpOS work in the known way. At this point I want to mention that the new version of WarpOS contains now a hardware driver system which allows any hardware manufacturer to write driver for their own hardware - for free. The Blizzard driver was finished quite some time ago and WarpUp would work probably as good as it already works on most existing CyberStormPPC machines. V14 would even work much better, since it finally fixed those stack problems which I encountered a short time ago (who the hell has given 2KB stack to the RAMLIB? ) In my opinion, the coexistencs of both system was no problem at all. We provided the V7 for compatibility with ppc.library and V8+ to support special applications and to bring powerful multitasking capabilities to the user. Well, what about an ELF/PowerUp emulator for WarpUp? :) Assuming WarpUp would be eliminated, Phase5 would be able to provide the 'best solution' and the users would have their freedom to choose between ppc.library, ppc.library and ppc.library. I ask myself, why they need to eliminate WarpUp if they prove to provide the far superior solution? Assuming WarpUp will continue to work, this means that the user itself has the choice what to use. OK, leaving now and expecting a hot discussion to start :) I will inform myself over my comrades what happened here. I would be really interested if even ppc.library supporters also support the plan to eliminate the alternative software solution. bye -- Sam Jordan Member of Haage&Partner PowerPC Development Team s.jordan@haage-partner.com (business related) sam_jordan@bluewin.ch (private related) ----8<-----------------------------------------------------------------[2]-- ..and... ----8<-----------------------------------------------------------------[3]-- From: magicsn@birdland.es.bawue.de (Steffen Haeuser) Subject: WarpUp Crashes.. Date: 1998/08/12 Message-ID: <16000606504720271175@BIRDLAND.es.bawue.de>#1/1 References: <6qq918$54d$1@nnrp1.dejanews.com> Organization: Birdland BBS, Dettingen/Teck, South Germany, +49-7021-862428 Content-Type: text/plain; charset=ISO-8859-1 Newsgroups: comp.sys.amiga.hardware babissps@ath.forthnet.gr wrote : Hi! ba> My problem is that i cant get WarpOs to work. ba> Whenever i try to load a prog tha uses warpos it crashes ba> with a "Ramlib...." ..EVETYTIME... ba> This happent after the flashrom update,i know i am not ba> the only one with the problem... ba> From what i can undestand,it might be because ramlib has small ba> stack size..so when the progs are loading many libraries(warps loads 3..plus ba> the programs requirmenets) it crashes.I have tried a util called "Ramlibpatch" ba> i think,which i supposed to increase the stack to 8kb...but it dosnt do ba> anything.Is there any other way to increase the stack size of Ramlib,supposed ba> this is the problem.... No, this problem is nothing that MCPramlibpatch can solve. The problem actually is, that the latest FlashROM installs a certain OS-patch, that only works if ppc.library can be opened, and crashes, if it can't. If WarpOS is active, ppc.library can NEVER be opened. To fix it, use the new powerpc.library enclosed in the 3.1 Update *and* set the env-variable env:powerpc/TERMINATOR to the value 2 !!! This is important, without it it won't work !!! (This disables the above mentioned OS-patch again...). Do for example: echo >env:powerpc/TERMINATOR "2" echo >envarc:powerpc/TERMINATOR "2" You only have to do this once. Note: If you start ppc.library applications in your startup (like CGX PPC or ppc.library datatypes or ElfLoadSeg or PPCInstall or RC5-PPC) then this might NOT WORK !!! You should better remove this applications from your startup. Please report to me if this helped. Okay, this is a kludge, the only real fix would be if Phase 5 removed the Anti-WarpOS-Code from the FlashROM. But they seem not to want to do this. So set the env-variables, and it should work :) Steffen Haeuser ----8<-----------------------------------------------------------------[3]-- ..and... ----8<-----------------------------------------------------------------[4]-- From: magicsn@birdland.es.bawue.de (Steffen Haeuser) Subject: Re: **ppc boring questions... Date: 1999/02/24 Message-ID: <40000106674389000968@BIRDLAND.es.bawue.de>#1/1 References: <36D3D41E.5BC4@nottingham.ac.uk> Organization: Birdland BBS, Dettingen/Teck, South Germany, +49-7021-862428 Content-Type: text/plain; charset=ISO-8859-1 Newsgroups: comp.sys.amiga.misc Newsgroups: comp.sys.amiga.misc Mark.Howson@nottingham.ac.uk wrote : Hi! >> after installing cgx i tried some warpos demo and they didn't started >> becouse they could not open the screenmode requester... :?? Ma> Sounds like a rtgmaster problem (maybe you don't have it)? Try Ma> installing the latest rtgmaster_user version from Aminet. rtgmaster-problems normally appear out of two reasons: 1. ramlib Problem (can also happen on 68k systems without PPC) If too many programs use ramlib stack at the same time (examples of programs using much ramlib stack are: rtgmaster, MCP, later versions of CGX - old versions not - and cgx3dvirgin.library). Can be fixed by adding MCPramlibpatch >nil: to startup-sequence (the utility is inside rtgmaster_user.lha archive) 2. Termination Problem Some PowerUP Board FlashROMs (later ones) patch the LoadSeg Patch to cause WarpUP crash. Normally WarpUP programs which do NOT use PPC Shared Libs still run (but not always). But programs using PPC Shared Libs (like rtgmaster or x-dve.library or mpega.library) don't run then. Fix: - set env:powerpc/TERMINATOR to 2 - do not start ANY ppc.library program during startup (including CGX PPC, PPCInstall and ppc.lib based datatypes) or - Install the Utility from Frank Wille which removes ppc.library Residents (included in ppc.library Emulation) This is NOT the fault of WarpUP or rtgmaster. The problem is this LoadSeg Patch. If LoadSeg is currently used for a ppc.lib program, ppc.lib cannot be terminated... Steffen Haeuser ----8<-----------------------------------------------------------------[4]-- ppc.library install patch to dos/LoadSeg() function that does OpenLibrary("ppc.library", x) and does not test for failure. The original WarpOS "termination" just remove the ppc.library from the LibList and then install the powerpc.library. Afterwards, OpenLibrary will return NULL and thus LoadSeg call will crash. The claim is that not testing the OpenLibrary() result is one of the anti-WOS measures. This is just plain ridiculous. Once the ppc.library has been installed by the flashrom, it cannot be expunged (there is a dummy LIB_EXPUNGE vector). Thus, the OpenLibrary() call can never fail for this library. ppc.library is needed in the LoadSeg patch to allow transparent loading of ELF binaries. This library base is absolutely required for the patch to function properly. Forcibly removing running libraries is a evil hack and will definetely cause all sorts of problems. This is not ppc.library's fault. ramlib crashes ~~~~~~~~~~~~~~ This is very evident with Warp3D libraries, developed by Hans-Jörg Frieden, Thomas Frieden and Sam Jordan. The ramlib process crash happily when loading these libraries. Steffen Haeuser (author of various bogus libraries, including RTGMaster) repeatedly claimed this bug was caused by ppc.library. For example: ----8<-----------------------------------------------------------------[5]-- From: magicsn@birdland.es.bawue.de (Steffen Haeuser) Subject: Re: PPC C compilers Date: 1998/02/18 Message-ID: <32000606353413037899@BIRDLAND.es.bawue.de>#1/1 References: <34E95B91.15B7711D@geocities.com> Content-Type: text/plain; charset=ISO-8859-1 Organization: Birdland BBS, Dettingen/Teck, South Germany, +49-7021-862428 Xcanpos: shelf.01/199802221701!0025817165 milanos@geocities.com wrote : Hi! mi> Okay, I have to respond now. My personal experience is that the mi> WarpUP/RTGMaster combo is extremely buggy and can crash your PowerUP mi> card in such an extend that even a reset won't get it back to life, you mi> will have to shut down the machine. On other occasions I experienced mi> lock-ups with ZhaDoomPPC, trashed screen crashes with CrystalSpace mi> WarpUP port, which doesn't run whatever I try. I finally got ZhaDoomPPC mi> working without freezing and it is a lot slower than VDoomPPC on AGA. I admit that ZhaDoomPPC (especially early versions) is not the stablest of things... but after reports i got it runs much more stable than VDoomPPC. mi> This is not to publicly flame Steffen, his RTGMaster software is still mi> in development as is ppc.library. To say ppc.library is very buggy is a mi> load of nonsense, I have never had any trouble using it or developing mi> for it and it is very fast as well. rtgmaster has only one problem: If it does not get enough ramlib stack (for example if one tries to start it with WarpOS V7... WarpOS V7 uses ppc.library, and ppc.library has a bug in stack handling... - not ramlib stack, again something else...). The ramlib problem can appear, if you have a lot of CRAP TOOLS running that waste too much ramlib stack. That is a bug of these tools then, not of rtgmaster. There are a LOT of not cleanly done patches on Amiga. I reduced the stack usage of rtgmaster in the latest version to the absolute minimum (4KB for each library), i cannot do more. Well, in ppc.library, as i said before, there is PRINCIPIAL trouble, though. It had probably to be done again new from the start to get it stable. mi> Another big annoyance with WarpUP is that a reset is needed between mi> using WarpUP and PowerUP software, this is not P5's fault, they had mi> their system first. Another big annoyance of ppc.library is that i have to do a reset when i want to run their software. Steffen Haeuser ----8<-----------------------------------------------------------------[5]-- This is total bollocks and great example of the FUD campaign run by these people. The real reason for these problems is the library LIB_INIT routine and more precisely, calling OpenLibrary() for disk based libraries within the LIB_INIT. What happens in this case is, that ramlib itself will recurse and easily run out of of the 2KB stack. Also "if too many programs use ramlib stack at the same time" is complete nonsense. No programs use ramlib stack. Instead programs call OpenLibrary for a buggy library that does more OpenLibrary calls inside LIB_INIT. The only way programs can affect this indirectly is patching some functions that are called within ramlib, for example LoadSeg. However, this is not the cause of the problem, but it just make the problem trigger easier. The proper way to open disk based libraries is at LIB_OPEN when opencnt is 0. That function is called in the context of the library opener, not ramlib, and thus there won't be any stack problems. Also, LIB_OPEN calls can't cause such recursion. Yet these crashes were blamed on ppc.library. And even as of today [Feb 2003], Warp3D libraries do crash unless you run some hack to raise the ramlib stack size. Conclusion ~~~~~~~~~~ There are no anti-WOS routines in Blizzard PPC flashrom. There are just bugs in WarpUP and Warp3D and other libraries. Due to the FUD campaign run by WarpUP and Warp3D people, the wrong idea seems to be widespread. References ~~~~~~~~~~ [1] http://www.aminet.net/dev/debug/enforcer.lha [2] http://groups.google.com/groups?selm=3512B443.3B2B%40haage-partner.com&output=gplain [3] http://groups.google.com/groups?selm=16000606504720271175%40BIRDLAND.es.bawue.de&output=gplain [4] http://groups.google.com/groups?selm=40000106674389000968%40BIRDLAND.es.bawue.de&output=gplain [5] http://groups.google.com/groups?selm=32000606353413037899%40BIRDLAND.es.bawue.de&output=gplain