Weird problem

[BippyM]

As some of you know I am writing a WHD slave for Croak!

I have come to a particularly strange problem.

I have managed to get my slave to recognise and support both the original af35 powerpacked version, and also unpacked version!

The patches I have done so far work flawlessly on the uncompressed version (Inf lives and vblank timing) but for the packed version I have the strangest error with the vblank timing!

The game waits 200 frames before the vblank actually kicks in. I have tested and the patch is in the right place and anything I put outside my vblank loop is executed fine, but the loop itself isn't run for the first 200 frames, despite me having it set to run every 2nd frame!

Any ideas?

my loop code is:

_waitvb
        movem.l    a0/a1,-(a7)
        lea    delay(pc),a0
        lea    count(pc),a1
        addq.l #1,(a1)
        subq.w    #1,(a0)
        bne.b    .skip

        move.w    #$2,(a0)
        waitvb
        blitz
        clr.l (a1)
.skip        movem.l    (a7)+,a0/a1
    
        cmp.l    #7,d0            ; code we removed
        rts                ; return to game

[StingRay]

what are you doing with "count"? Can't see it used anywhere except for the addq.l #1,(a1)/clr.l (a1).
Edit: I guess I know what you're using count for.

As for the rest, I don't think it is possible to find the problem without looking at the game code as the code for the delay is correct.

[Asman]

Hi

I have managed to get my slave to recognise and support both the original af35 powerpacked version, and also unpacked version!

I think that better is unpack powerpacked version in install script ( xfddecrunch ). Furthermore user can pack a file with packer which is supported by WHDLoad ( xpk or other ). Don't forget to load a file in proper way ( function resload_LoadFileDecrunch ).

Regards

[StingRay]

Originally Posted by Asman

I think that better is unpack powerpacked version in install script ( xfddecrunch ). Furthermore user can pack a file with packer which is supported by WHDLoad ( xpk or other ). Don't forget to load a file in proper way ( function resload_LoadFileDecrunch ).

The file is an executable file which is loaded using LoadSeg(), slave uses Kick1.3 emu. resload_LoadFileDecrunch can't be used here.

[Asman]

Hi,

The file is an executable file which is loaded using LoadSeg(), slave uses Kick1.3 emu. resload_LoadFileDecrunch can't be used here.

Upss, I didn't know that. So LoadFiledecrunch + Relocate can be used in that case . Furthermore Kick1.3 emu may be kicked out ( if kick1.3 is used only with LoadSeg ).

Regards

[StingRay]

Originally Posted by Asman

Hi,



Upss, I didn't know that. So LoadFiledecrunch + Relocate can be used in that case . Furthermore Kick1.3 emu may be kicked out ( if kick1.3 is used only with LoadSeg ).

LoadFileDecrunch + Relocate would work but using LoadSeg is much simpler here (and makes more sense anyway). Also, the kick1.3 emu is necessary as the game is using a lot of system functions.

[BippyM]

the count is used simply to count up.. I used that to determine the 200 frames before it actually started executing the vblank!

I waited until blitz was called (freeze system) and then I checked the location held in count!

[BippyM]

I have now checked the offsets of the crunched file in comparison to the uncrunched file and it's err.. identical, 100% identical.. so why is it doing this?

[Leffmann]

Initial value of delay getting messed up most likely. A pointer stepping outside its supposed bounds and writing delay by mistake perhaps? Are you using the correct word size for reserving space and setting the delay value initially? Check the outside code, f.ex what does the code look like from where you jump into _waitvb? There's nothing wrong in the _waitvb routine itself.

[StrategyGamer]

Powerpacker is trashing some memory. I have seen it trash ram before. That is why I generally avoid powerpacker.

[Asman]

Originally Posted by StingRay

LoadFileDecrunch + Relocate would work but using LoadSeg is much simpler here (and makes more sense anyway). Also, the kick1.3 emu is necessary as the game is using a lot of system functions.

You're right LoadSeg is much simpler. In my opinion LoadFileDecrunch + Relocate makes sense, because:

- I can relocate hunks into FAST memory ( speed up )
- I can pack files ( safe disk space )

Of course LoadFileDecrunch + Relocate costs work a bit ( sometimes a lot ).

Regards

[BippyM]

I am not using powerpacker myself. It is compressed with it on the coverdisk, and I just wanted to add direct support for the coverdisk version!

I am more than happy to decrunch it during install and using it uncompressed (it's only 151kb).

The game passes the load address to a5 and then copies itself to $f2 where it does a jmp address..

I simply break into the uncompress routine and change the jsr to an rts and copy the load address to my location instead of the game.

After that powerpacker is finished and I can work on patching the game itself. So in theory powerpacker cannot trash memory, esp whd memory as it is confined to the area I gave it to work with and the slave is naturally outside of this area, and the game has not been patched!

[BippyM]

Leffman you are correct. I was doing the following

		move.b	#$75,(-1,a5)		; Make the game RTS back to slave
		lea	_fileaddress(pc),a5	; Change location game will put jsr address

		move.l	a0,d0			; Following 3 lines are code we overwrote
		lsr.l	#2,d0
		move.l	d0,(a4)

Powerpacker executes the same code in a loop, so after I moved my address into a5 it patched -1,a5 so overwrote my counter

I put that inside a routine to test if it had been run once, and now it works fine

Thanks guys for all your help.. next highscore patching