Ramlib Error #80000003 ?!?!

[Sphinx_Ra]

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

[Karlos]

I have no idea about the melody but IIRC the #80000003 guru implies a bus alignment exception. I think...

[Sphinx_Ra]

Oke... but what is IIRC ??
And what must i think of
"bus aligment exception" ?
Some Mediator cards or somethimg???
Thanks

[Cymric]

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.

[bloodline]

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... :-?

[xeron]

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).

[browny]

@ 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

[bloodline]

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 ;-)

[Sphinx_Ra]

Wow...:-o learning every day :-)
Oke, so my RAM is faulty or the
Amplifier is screwing up hmmmmm...
Damn......

[zipper]

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.

[Cymric]

@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.

[bloodline]

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!"

[Sphinx_Ra]

@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 :-)

[xfactor]

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

[Cymric]

@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?