Trainer for Pandora

[TCH]

I've just released my trainer for the game Pandora.

You can download it here.

Thanks for the help who helped in the making, the credits are in the trainer.

[StingRay]

You need to take care not to place chip memory data such as copperlists in public/fast memory. Tried your trainer on my 512k/512k A500 and didn't see anything so I quickly checked the code.

Other than that, I really like the font.

[TCH]

Blast, i knew i forgot something... Galahad warned me about this and i planned to copy the copperlist to the ChipRAM, but then i have entirely forgotten about it. :/
Thanks for telling, fixed and updated.

Thanks, it's my first fontset ever. I drew it 8-10 years ago, but never used it...until now. It's a reduced version though, only contains chars from 32 to 127. The full is here:

[Viceroy]

If using standard A500 configurations, you only get a black screen once the trainer loads.

I can get the trainer to appear if I set 1MB Chip RAM or set AGA, but then of course the game doesn't load...

Can this please be fixed to work on an "A500 / KS 1.3 / 512KB Chip & 512KB Slow RAM"?

[TCH]

Edit: It should run with 512 kb only. I'll check this. Thanks for telling.

I don't understand right now, why it does not work with only 512 kB. The interrupt code is at $7ff00-$7ffdf. The screen RAM is at $7af00-$7feff. (Two planes.) The copperlist is at $7aeb8-7aeff. And the charset resides inside the program itself. It should work on 512 kB.

Edit: Okay, i discovered, that at the screen RAM clearing i did not divide the length by four, that's caused the black screen and the freeze and that is fixed now. However it still crashes at exit.

Edit: The

Permit()

call crashes at the end.

[Toni Wilen]

Not sure if this causes this exact problem but system supervisor stack is located at the end of chip ram (if there is no other RAM available) and you'll overwrite at least part of it.

[Exodous]

Are you just stomping on the memory at the locations identified for screen RAM and the copperlist?

If so, there could well be other things already in those memory locations, which would explain the crash on exit.

If you're allocating memory and use only what you allocate then you should be OK. If you just stomp all over memory, make sure you do it after disabling the OS and then don't try going back to the OS when you're done.

[TCH]

@Toni Wilen:
How long is the system supervisor stack? I did not touch the last 32 bytes, the last address i use is $7ffdf.

@Exodous:
I did disable the OS, but i need to return as the DOS will load the game itself. As for allocating; if Toni is right, then the problem is the IRQ code, which must be at an absolute address and i cannot allocate absolute addresses.

[TCH]

@Toni: You were right. I moved one page backwards the interrupt code and now it does not crash at exit. Now the game crashes...

Edit: No wonder why, it has been overridden. The game filled up everything up to 7ff00. I need to find a place for the interrupt's 224 byte.

[Toni Wilen]

Originally Posted by TCH

@Toni Wilen:
How long is the system supervisor stack? I did not touch the last 32 bytes, the last address i use is $7ffdf.

Probably 6k because last 6k of chip ram is not available for allocation in chip ram only config.

[TCH]

In the meantime it turned out, that 256 byte was enough, but then again, the game has overridden everything up to 7ff00. The system used bytes down to 7ff7c.

Edit: I've put the IRQ code to $100. Now the trainer works with 512 kB too. Thanks everyone.

[Exodous]

I just wrote a long post with an example showing how my degrader tool handled this using LoadSeg to load the executable, disabled the OS and then used RunCommand to call the loaded executable.

At the point of putting the the equates for the _LVO offsets, I noticed that RunCommand is only available on dos.library v36 and above, which would require Kickstart 2.0 or greater, so wouldn't be any use in your application.

I thought I'd still share this idea as you may still be able to use LoadSeg and then, from the resulting seglist, call the program directly so you don't require to go back to the OS after setting up your trainer?

LoadSeg http://amigadev.elowar.com/read/ADCD.../node02C5.html

RunCommand http://amigadev.elowar.com/read/ADCD.../node02EA.html

[TCH]

Version 1.0.2 is up, you can download it.

Edit:
@Exodous: If i use system routines, don't i need the OS during setting up the trainer?

[Exodous]

LoadSeg should load the file into memory and fix all the relocatable sections from the hunk data. The resulting seglist is a BCPL pointer, so to get to the start of the hunk code you need to multiply this address by 4, and the code starts at offset 4.

After this, for the purposes of your code, the OS likely isn't needed. However, it may be that the game file you've loaded needs certain OS functions. Though if it only uses ROM based libraries and no extra disk IO loading files for example, it should be OK.


Here is a standalone example which saves the passed CLI arguments, loads a file (gameexe) and calls it with the original passed CLI arguments. If you want to pass "blank" arguments, set d0 to 1 and point a0 to a string containing a CR and null terminator (dc.b 10,0)

This example assembles in Devpac, but should generally be compatible with other assemblers.

_LVOOpenLibrary		equ	-552
_LVOCloseLibrary	equ	-414
_LVOLoadSeg		equ	-150
_LVOUnLoadSeg		equ	-156

	output	loadsegexample

_Start:
	move.l	d0,_DOSArgLen		; Save DOS Cli arguments to pass to loaded file
	move.l	a0,_DOSArgs

	movea.l	4.w,a6			; ExecBase
	moveq	#0,d0
	lea	_DOSName,a1
	jsr	_LVOOpenLibrary(a6)	; Open dos.library

	move.l	d0,_DOSBase
	beq.s	.NoDOS

	movea.l	_DOSBase,a6		; This is for clarity in case this code is elsewhere as I could just move.l d0,a6
	move.l	#_GameFilename,d1
	jsr	_LVOLoadSeg(a6)		; Load the game file

	move.l	d0,_GameSegList
	beq.s	.NotLoadedFile		; If things are zero, we didn't get a file loaded

	lsl.l	#2,d0			; BPTR = address / 4, so multiply by 4
	addq.l	#4,d0
	move.l	d0,_GameFile		; Pointer to first segment code

; Call our trainer initialisation code
	jsr	_TrainerStart

; Call the loaded code
	move.l	_DOSArgLen,d0		; Argument Length
	movea.l	_DOSArgs,a0		; Arguments

	movea.l	_GameFile,a4
	jsr	(a4)			; Code starts at second long into seglist

; Call our trainer shutdown code
	jsr	_TrainerEnd

; Tidy up by unloading the file and closing the dos.library
	movea.l	_DOSBase,a6
	move.l	_GameSegList,d1
	jsr	_LVOUnLoadSeg(a6)	; Unload the game

.NotLoadedFile:
	movea.l	4.w,a6			; ExecBase
	movea.l	_DOSBase,a1
	jsr	_LVOCloseLibrary(a6)	; Close dos.library

.NoDOS:
	moveq	#0,d0
	rts


; Our trainer...
_TrainerStart:
	rts

_TrainerEnd:
	rts


; Data
	even

_GameSegList:	dc.l	0		; BCPL pointer to seglist

_GameFile:	dc.l	0		; Pointer to first segment data (the trainer probably needs this for patching?)

_DOSArgLen:	dc.l	0
_DOSArgs:	dc.l	0

_DOSBase:	dc.l	0

_DOSName:	dc.b	'dos.library',0

_GameFilename:	dc.b	'gameexe',0

[TCH]

Hey, thanks, this is very useful! I don't know if Pandora or it's decruncher needs something from the OS (i doubt the decruncher does), but i'll test it. Thank you again.

[Galahad/FLT]

So, I resourced your intro, and i've changed the setup to show you that you don't need to use hardcoded addresses for the copperlist and the screen setup.

i've commented the code to show you what i've done, so you can see how a screen is setup in the copperlist, where we get the values from, and how we set the copperlist to operate from any chip mem that is freely available.

Your code is so small, there really is no problem with you having it all run from chip mem and it being entirely PC relative, i.e. relocatable in any memory.

I've also set FMODE to 0 in your copperlist, saves problems on AGA systems and means they don't need to degrade to OCS/ECS to view your screen properly.

Hopefully this will give you further insight and the reasons why we do things the way we do.

[ross]

Just to add more fish to fry, yesterday I readjusted the intro and the trainer to work in a single file, in order to completely avoid the convoluted way used for the patch (the single file/trainer, that work in any memory config, is somewhere).

As this is a very simple trainer it is definitely a good beginner exercise.
The next step could be to repeat what I have done.
I'll wait to post the source code, but we can fully comment it later

[TCH]

@Galahad/FLT:
Thank you very much, i really appreciate it. I hope it will enlighten me in a few things.
I know that i don't have to use fix addresses for the screen and copperlist, i just wanted to do the simplest thing, because the point was the trainer itself. I know it is bad practice, but the game kills the OS in the zeroth second anyway. Still, if it can be done in the right way by equally or similarly simple means, i am definitely not against it. Thank you again.

@ross:
You mean, you made the trainer resident and the interrupt is inside the trainer code? Otherwise i am afraid i cannot follow you, becuase the trainer is a single file.

[Galahad/FLT]

Originally Posted by TCH

@Galahad/FLT:
Thank you very much, i really appreciate it. I hope it will enlighten me in a few things.
I know that i don't have to use fix addresses for the screen and copperlist, i just wanted to do the simplest thing, because the point was the trainer itself. I know it is bad practice, but the game kills the OS in the zeroth second anyway. Still, if it can be done in the right way by equally or similarly simple means, i am definitely not against it. Thank you again.

@ross:
You mean, you made the trainer resident and the interrupt is inside the trainer code? Otherwise i am afraid i cannot follow you, becuase the trainer is a single file.

You might be a newbie, but you've aptly demonstrated that you are a good learner, and I like the look of your trainer menu, and you've clearly got the basics of programming 68000 on the Amiga down well.

Once you learn the better way of doing things, you can concentrate of more interesting stuff, knowing all your setup code is flawless and works well.

Its a great start and you've got a good attitude

[ross]

Originally Posted by TCH

You mean, you made the trainer resident and the interrupt is inside the trainer code? Otherwise i am afraid i cannot follow you, becuase the trainer is a single file.

I mean I made a single file that embed both trainer and game.
So you do not need to 'wait and check' that the game is loaded in precise memory locations by someone external (i.e. the OS and/or the depacker).
That is a bad habit because many unpredicted stuff can happen..