Amiga.org
Amiga computer related discussion => Amiga Software Issues and Discussion => Topic started by: Vincent on December 18, 2004, 11:31:20 PM
-
When I try to use any PPC software I get the following:
PowerPC Data access exception (load operation)
Memory protection violation - Access to 00000000
The excepting instruction is located at 54A8AC90
Task name: 'ramlib_PPC' Task address: 54B035C8 Task ID: 112
There's a hex dump after that.
Any ideas how to solve this?
I can post the hex dump if need be, but as it's all letters and numbers I thought I'd ask to save the bother ;-)
Oh, it's a 603e/175MHz and 040/25MHz with 96MB ram.
-
Vincent wrote:
When I try to use any PPC software I get the following:
PowerPC Data access exception (load operation)
Memory protection violation - Access to 00000000
The excepting instruction is located at 54A8AC90
Task name: 'ramlib_PPC' Task address: 54B035C8 Task ID: 112
There's a hex dump after that.
Any ideas how to solve this?
I can post the hex dump if need be, but as it's all letters and numbers I thought I'd ask to save the bother ;-)
Oh, it's a 603e/175MHz and 040/25MHz with 96MB ram.
The "ramlib" crashed constantly when I used to use my PPC, one of the reasons why I had to abandon using it :-(
-
Usually this is caused by some library/device crashing in initcode. The crash is blamed on "ramlib" even though the crash actually happens inside the library/device code.
In most cases this crash is due to lack of ramlib stack. There are various ways to patch this, for example MCPRamLibPatch in MCP package (http://de.aminet.net/pub/aminet/util/cdity/MCP130.lha), or RamLibFix in MMULib.lha (http://de.aminet.net/pub/aminet/util/libs/MMULib.lha).
This is very commonly happening with Warp3D libraries which are totally bogus, calling recursive OpenLibrary inside library init code... This will explode with standard ramlib stack. Warp3D doesn't work reliably without some sort of ramlib stack patching.
-
I've installed MMUlib, but now I can't get a display on my BVision, CGXMode in the Prefs won't work and there are no BVision modes in ScreenMode prefs either.
--edit--
Problem solved - had to add <>NIL: to the BPPCFix line
-
Ok, I'm using the RamLibFix at the start of the startup-sequence (I can't find anything about it in the docks) and I still get the error.
-
This is very commonly happening with Warp3D libraries which are totally bogus, calling recursive OpenLibrary inside library init code... This will explode with standard ramlib stack. Warp3D doesn't work reliably without some sort of ramlib stack patching
Are you sure about that? I've never seen it do this.
-
Are you sure about that? I've never seen it do this.
Yes I am sure.
In general, if the ramlib stack is not patched to be larger, it is not safe to call OpenLibrary for disk based libs (that is, for libs that are not already in memory. that is non-KS-ROM libs) in LIB_Init. These calls must be made in LIB_Open.
Anyway, the crash can be worked around by loading the sublibs manually before opening the library in question.
Also the open might actually work, depending on pure luck (due data allocated before the stack being not critical for trashing) or OpenLibrary patches not being installed (each patch usually adds to stack usage).
-
Well, I meant "the recursively calling OpenLibrary()" bit for warp3d libraries.
Regarding the ramlib crash, I think my 3.x installation was protected by MCP's ramlib patch anyway. I also used stack attack to increase stack allocation generally.
-
Vincent
put the ramlibpatch, after the SetPatch.
-
Framiga wrote:
put the ramlibpatch, after the SetPatch.
Done, but still no luck :-(
-
Anybody have any more ideas?
Please say you do :-)
-
@Vincent:
Tried StackAttack (http://de.aminet.net/pub/aminet/util/boot/StackAttack.lha) as suggested by Karlos?
/Patrik
-
I had similiar problems. It was a heat related issue. Get the inside of your caser cooler and see if that helps.
-
@Patrik
Yup, still get the error.
-
I have 2 fans in there now, an old PSU fan extracting heat out through the 3.5" drive bays and an old P500 fan cooling the 040 and ppc, I can't see it being heat related.
--edit--
There is also the original ppc fan on the board (the p500 fan is on the cooler/040 side and the original fan on the other).
The errors come up right after a cold boot after being switched off for 24 hours, so I'm pretty sure it's not heat related.
-
Well you said it was working fine the other day vince so err what did you do to break it? whatever it was remove it and try again :-)
Personally I would check you have the WarpOS prefs setup properly, I forget what settings I use... but you have my settings already on CD so :-)
-
I haven't installed anything, that's the strange thing.
The only thing I've done since getting it working was change screenmodes of progs to use the bvision, that was it.
I spent most of the time playing ArTKanoid ;-)
DoomWOS is working now, but anything else that uses the PPC comes up with the same error (W3Ddemos, Quake, Payback)
-
Okay, tried your settings (deleted my CyberGraphX, PowerPC and Warp3D dirs and copied yours over).
No change, DoomWOS still works, everything else is up the swanny :-(
-
Problem solved (well, the Warp3Ddemos work so I thought I'd post with what I did asap before anything else happens ;-) )
Checked out my libs dir and I had the following in Warp3D:
GFXDrivers
W3D_CyberGFX4.library - 40,292 bytes - version 4.2
W3D_CyberGFX4_PPC.library - 16,128 bytes - version 4.0
W3DPicasso96.library - 38,664 bytes - version 4.2
W3DPicasso96_PPC.library - 20,508 bytes - version 4.2
HWDrivers
W3DPermedia2.library - 579,708 bytes - version 4.2
W3D_Permedia2_PPC.library - 502,980 bytes - version 4.2
Now, in my backup (created as soon as the BPPC and BVision were installed and working) I had:
GFXDrivers
W3D_CyberGFX4.library - 38,996 bytes - version 4.0
W3D_CyberGFX4_PPC.library - 15,412 bytes - version 4.0
HWDrivers
W3DPermedia2.library - 93,120 bytes - version 4.31
W3D_Permedia2_PPC.library - 396,812 bytes - version 4.2
Notice the difference? Mainly in the filesizes of the HWDrivers dir being ~700,000 missing
God knows what happened (or what installation, or me getting libs from Karlos to try Quake stuff...), but it seems to be happy now :-)
-
Vincent wrote:
God knows what happened (or what installation, or me getting libs from Karlos to try Quake stuff...), but it seems to be happy now :-)
The libs you got from me are implemented rather differently from the original 4.2 - the 680x0 driver really is 93K and really does support everything its 579K predecessor did (and a lot more). The WOS version is a bit larger (180K). The 4.2 driver you had from me was just a quick bug fix and recompile of the original 4.2 source.
Compatibility wise, the 4.3 drivers should work with everything that obeys the W3D API. There is a known conflict with some versions of MiniGL (affects BlitzQuake, for example) which is due to aggressive optimisations in that version of MiniGL making assumptions about the driver and taking shortcuts.
Everything else I have tested worked OK (as I tend to use them on a daily basis ;-) )
-
I suppose I should've stated the first list was the "current" (non working) libs, deleted and replaced by the backup ones (2nd list).
@Karlos
I'll try chucking the 4.31 lib back in later on... once I've had some fun in Quake ;-)
-
You only have the 680x0 half, so unless you are running 680x0 3D apps you won't see a difference at all. Lemme know if you want the PPC version too.
I haven't as of yet had any chance to benchmark directly the gain of the PPC version (at the function level) since I need to compile a WOS friendly benchmarking tool for it. I doubt the gain will be as great as the 680x0 side (which is more than 2x faster in some cases) since the PPC will most likely reach bus saturation anyway.
-
I still say it is a heat issue. Replace the original fan on the PPC (the originals sucked...) with a much more powerful one.
There is no way you can get it to cool. Important is how warm the chip is, so the most important fan is the one on the PPC itself.
Keeping the chip cool did wonders for my system.
-
@Karlos
its W3D 4.3 available for public?
-
Kraftwerk wrote:
I still say it is a heat issue.
It's been working almost full time since getting it fixed on the 19th with only a few software errors (unrelated - I'm trying stuff out).
The issue was with the libraries themselves.