Amiga.org
Amiga computer related discussion => Amiga Software Issues and Discussion => Topic started by: Sphinx_Ra on July 30, 2003, 05:14:33 PM
-
hello Everybody,
Plz Heeeeeelp :-x
I have Amplifier, and sinds i have
Melody1200Pro, the program does not
work, it says:
Software Error ramlib #80000003
Anybody had this to?? the problem is that
Amplifier is the only program that use
Hardware Coding (DSP) :-x :-x :-x
-
I have no idea about the melody but IIRC the #80000003 guru implies a bus alignment exception. I think...
-
Oke... but what is IIRC ??
And what must i think of
"bus aligment exception" ?
Some Mediator cards or somethimg???
Thanks
-
IIRC = 'If I Recall Correctly'
The dreaded 80000003-Guru is one of the most common on the Amiga: on the 68010- it signifies a word or longword access to an uneven address; on the 68020+ (which is capable of recognising the situation and performing two memory accesses in order to get the information they need) it is put up when the stack is pointing at an odd address. That should never happen, so either your RAM is faulty, or your program is screwing up bigtime. The stack being messed up is truly worthy of a CPU exception, the other reason is not. It's just to circumvent a design desicion.
Mind, I remember trying to crack a game which featured a bootloader which had its code shifted by one byte to odd addresses. By installing a custom exception handler to pull in the other byte, then returning from that exception, the program could execute that instruction. Of course, execution speed is very low with the CPU excepting at every mnemonic. I was so impressed I gave up on cracking the program.
-
Cymric wrote:
Mind, I remember trying to crack a game which featured a bootloader which had its code shifted by one byte to odd addresses. By installing a custom exception handler to pull in the other byte, then returning from that exception, the program could execute that instruction. Of course, execution speed is very low with the CPU excepting at every mnemonic. I was so impressed I gave up on cracking the program.
Hmmm, what reason was there to shift the code off by one byte? I don't understand how that would have "copy protected" it... :-?
-
Hmmm, what reason was there to shift the code off by one byte? I don't understand how that would have "copy protected" it... :-?
Its so that crackers can't step over the code in action replay. An even cleverer trick is to put the code offsetted by one byte, then encrypt it. Your exception handler then not only compensates for the offset, but decrypts the code WHILE its being executed. In action replay, all you see in RAM is junk!
If the exception handler also re-encrypts the last executed instruction, there is NEVER a complete decrypted copy of the code in RAM.
Of course, on 68020+ it will just crash horribly.
Another trick is to put the stack at an odd address and not use it so that the action replay can't be activated. (press the button on the action replay, NMI occurs, which causes a stack access, which causes a processor exception, so your machine gurus instead of going into action replay).
-
@ CYMric,
Cymric wrote:
IIRC = 'If I Recall Correctly'
The dreaded 80000003-Guru is one of the most common on the Amiga: on the 68010- it signifies a word or longword access to an uneven address; on the 68020+ (which is capable of recognising the situation and performing two memory accesses in order to get the information they need) it is put up when the stack is pointing at an odd address. That should never happen, so either your RAM is faulty, or your program is screwing up bigtime. The stack being messed up is truly worthy of a CPU exception, the other reason is not. It's just to circumvent a design desicion.
Mind, I remember trying to crack a game which featured a bootloader which had its code shifted by one byte to odd addresses. By installing a custom exception handler to pull in the other byte, then returning from that exception, the program could execute that instruction. Of course, execution speed is very low with the CPU excepting at every mnemonic. I was so impressed I gave up on cracking the program.
I luv it when you talk dirty ! :-D :-P
-
xeron wrote:
Hmmm, what reason was there to shift the code off by one byte? I don't understand how that would have "copy protected" it... :-?
Its so that crackers can't step over the code in action replay. An even cleverer trick is to put the code offsetted by one byte, then encrypt it. Your exception handler then not only compensates for the offset, but decrypts the code WHILE its being executed. In action replay, all you see in RAM is junk!
If the exception handler also re-encrypts the last executed instruction, there is NEVER a complete decrypted copy of the code in RAM.
Of course, on 68020+ it will just crash horribly.
Yeah I realised after I posted that It was probably to stop system monitors watching what's going on.
Another trick is to put the stack at an odd address and not use it so that the action replay can't be activated. (press the button on the action replay, NMI occurs, which causes a stack access, which causes a processor exception, so your machine gurus instead of going into action replay)
Hahahaha, yeah I figured that little trick out myself, somewhat accidentally ;-)
-
Wow...:-o learning every day :-)
Oke, so my RAM is faulty or the
Amplifier is screwing up hmmmmm...
Damn......
-
There is slight possibility your ramlib stack is too small; you could try Ramlibpatch in MCP or StackAid or install StackAttack. But in the latest OS the small stack problem should be fixed.
-
@browny:
Actually, I wasn't attempting to crack the program, now that I think about it. I was trying to insert some code so the power-led (and thus the low-pass filter) would be turned off.
-
Cymric wrote:
@browny:
Actually, I wasn't attempting to crack the program, now that I think about it. I was trying to insert some code so the power-led (and thus the low-pass filter) would be turned off.
Ahhh, the old "Trying to deactivate the filter" defence... It usually doesn't work when they see the "Trainer code" you've written ;-)
"Searching for Decrementing Opcodes? I don't know what you mean!"
-
@Zipper
I already tryd RamLibPatch in my
Starup-Sequence and StackAid and StackAttack :-(
I thought that indeed in OS 3.9 it
would never happen, but....
Oke, i'm now gonna take out the melody
and throw it away :-)
But thanks anyway for your thoughts :-)
-
Before you throw anything out, are you running Cybergraphx, and if so, what version?
If you happen to be running v4, you should know that there's a bug in any of the revisions later than "pre8" which cause big ramlib stack problems.
You can get the cfgx updates at http://www.vgr.com
Cheers,
Stuart
-
@bloodline:
Heck, I wish I *was* good enough to write trainer code myself... That would have made quite a lot of games I bought with my hard-earned cash very worthwhile. Surely you remember a few games which were nice in concept, but utterly unplayable?
-
Cymric wrote:
@bloodline:
Heck, I wish I *was* good enough to write trainer code myself... That would have made quite a lot of games I bought with my hard-earned cash very worthwhile. Surely you remember a few games which were nice in concept, but utterly unplayable?
Hmmm, quite a few actually... "Castles" was one of my favourite games in that catagory along with "Life and death"... neither of those were "score" based so I couldn't figure out how to adjust them to my advantage :-(
-
@ XFACTOR
Nope, i'm using P96 with mediator and
Voodoo3 2000 :-)
Could there be a problem hmmmmm...
-
You did download the latest driver for Melody1200Pro, right?
:-?
-
Ahh yes ... the dreaded 80000003 guru.
I have never used Amplifier or Melody1200Pro, so I can't give you a definite answer.
80000003 is the most common guru I get on my Amiga 2000HD, which is equipped with a 68000 CPU.
Through trial and error I found that this failure code seems to be a catch all for many problems I have encountered over the years.
Sometimes, it means that there is 68020 (or later) code in the program or an associated library. The 68000 CPU usually takes a visit to the guru when it encounters this code.
Certain programs cause problems for certain other programs. Certain programs will also interact with each other, causing system stability problems.
Sometimes, it means that the program can not find certain required files or libraries, they may simply be in a different directory or on a different drive than the program expects to find them.
Sometimes, a new program requires a newer version of a library that already exists on the system. If you don't update the library, the new program may crash. If you do update the library, other older programs may be crash.
Good luck .... I hope you get a more definite answer.
---------------
redfox
-
try upping your stack to 100000 this works fine here i seem to have to do this with most ppc programs too some 68k !
-
@poweramiga
:-D :-D :-D
Yes !!!!
Thanks, take a :pint
from me :-)
-
@poweramiga
:-D :-D :-D
Yes !!!!
Thanks, take a :pint
from me :-)
-
@PowerAmiga2002
:-D :-D :-D
YES !!!!!!!!!!
Thanks man, if i new
that before....:-)
Take a :pint: from me :-)
Oops...
Hmmmmm... don't bother the
upper side of the Reply's i
was (very) drunk last night :-)
-
@Cymric,
I believe ya,
But me grandmother wishes you the `flea`s of a thousand Camel`s` to decend on your ass !.
Grandmother`s eh, huh !. :-D :-o
guru -80000003, ARRRGHHHHHHHH