Trainer for Pandora

[ross]

Originally Posted by ross

That is a bad habit because many unpredicted stuff can happen..

To make you understand better where the problem lies.

This piece of code is very very dangerous in an Amiga system (it is hidden in the Galahad Resource.s because it is relocated code, it refers to when IRQ6 handler was at $7ff00, but no matter where it is):

lbC00027C	cmpi.b	#$C0,($20518)
	bne.w	lbC000340
	move.b	#$E0,($20518)
	move.l	#$7FF1C,($78).w
	tst.b	($7FFD8)
	beq.b	lbC0002A6
	move.b	#$18,($3CAB).w

Leave aside the fact that you assume that the vector is for free use by anyone; can also be in a newly booted machine, but don't take it for granted.

The biggest problem is that you 'time scan' a memory location and you presume it isn't #$C0, until game is depacked!

This should NEVER be done on the Amiga, even for a simple machine like the A500.
A user reported to me that the ADF on his A500 was giving 'read/write' error while loading, although he was sure the disc had no problems (double checked it, and the exe was working without the trainer in the same disk). And he could repeat the problem systematically.

Sure in his machine for some reason which may be the chip allocation of anything, that location caused the vector to change to the new memory location, which in turn caused it to write to low memory, which corrupted the MFM buffer, which generated the read/write error while loading the game

[TCH]

@Galahad/FLT:
Thanks. Finally i am appreciated somewhere.

@ross:
I see, so you've integrated the trainer into the game's cracktro/decruncher.

I've triple checked if the vector is free, during the cracktro, the decrunching and the game itself. It was not used.

Also, i think Galahad disassembled an older version of the trainer, (1.0.0 or 1.0.1), because the L6 vector is no longer

7ff00/7ff1c

, but

100/11c

in the newer versions (1.0.2 and 1.0.3). (Toni suggested the game crashed on 512 kB only, because i trashed the system supervisor stack, so i've relocated it onto

$100

.)

But yes, the

c0

part is still there. If i cannot assume

c0

will not be there until the depacking, can't i just zero out the byte when the trainer exits? Right after that the game starts and the OS is killed, so nothing - in theory - can interfere. Or can it?

Since, the trainer is already done and released, i think i just upload the source here.
http://oscomp.hu/depot/PandoraTrainerSource.lha

[ross]

Originally Posted by TCH

@Galahad/FLT:
Thanks. Finally i am appreciated somewhere.

Nah, the appreciation has been there from different people.
Otherwise what would be the reason for replying to your messages and trying to improve yourself?

@ross:
I've triple checked if the vector is free, during the cracktro, the decrunching and the game itself. It was not used.

No. You have tried in your configurations.
But there can be hundreds of different ones and in none you have to assume that the vector is not used (at least when the OS is active).

Also, i think Galahad disassembled an older version of the trainer, (1.0.0 or 1.0.1), because the L6 vector is no longer

7ff00/7ff1c

, but

100/11c

in the newer versions (1.0.2 and 1.0.3). (Toni suggested the game crashed on 512 kB only, because i trashed the system supervisor stack, so i've relocated it onto

$100

.)

As I said, in Galahad's source that code is 'hidden'. So I certainly didn't got it from there.
It is from an 'early version' resourcing from which I based my patch.
But in any case, I repeat, does not matter where the code is copied.

But yes, the

c0

part is still there. If i cannot assume

c0

will not be there until the depacking, can't i just zero out the byte when the trainer exits? Right after that the game starts and the OS is killed, so nothing - in theory - can interfere. Or can it?

No, in Amiga you cannot touch memory that you do not own. NEVER.
OS is active during game loading (or before, or after, until you take over the system), you cannot trash memory as you like

[TCH]

Originally Posted by ross

Nah, the appreciation has been there from different people.
Otherwise what would be the reason for replying to your messages and trying to improve yourself?

I was just kidding.

Originally Posted by ross

No. You have tried in your configurations.
But there can be hundreds of different ones and in none you have to assume that the vector is not used (at least when the OS is active).

I see. Still, does it matter, when the game will kick the OS out of the control instantly?

Originally Posted by ross

As I said, in Galahad's source that code is 'hidden'. So I certainly didn't got it from there.
It is from an 'early version' resourcing from which I based my patch.
But in any case, I repeat, does not matter where the code is copied.

Okay, got it.

Originally Posted by ross

No, in Amiga you cannot touch memory that you do not own. NEVER.
OS is active during game loading (or before, or after, until you take over the system), you cannot trash memory as you like

I can, but maybe i should not.
It seemed to me, that since this is an A500 game which takes over the OS anyway, that i can do the same approach for that few moments, until the trainer runs.
Well, at least it is another reason for OS-friendly programming, instead of hw-banging. :P

[ross]

Originally Posted by TCH

Still, does it matter, when the game will kick the OS out of the control instantly?

It's what I'm doing in my patch
I take over the system, I change the vector, then launch the game.
In you case it is not 'instantly', because system is active between steps (it could be active even only for few ms and you can have big problems if the task scheduler runs/use code/data at memory that you modified improperly).

Well, at least it is another reason for OS-friendly programming, instead of hw-banging. :P

Yes, as suggested do not mix hw banging with OS active.

Of course I am blatantly on the hardware banging side, but only after I have properly taken over the machine.
So look for code, even made by others, that do just that, then abuse it as much as you like

[TCH]

I see, thanks. Though in this case, this is unlikely as it will be a fresh boot, calling the trainer and the game from the

startup-sequence

.

I am not very adept the hardware and the OS is so well designed, providing means virtually for everything, so usually i simply use the OS. Although i know, that there are cases, where the OS needs to get rid of to achieve full speed. Especially on the stock machines.