WHDLOAD Kick Off 2 CV

[alkis21]

Hard disk users should know that there's a new patch available that supports KO2CV Version 1.03. You can get it from http://www.whdload.de .

[Stainy]

I also see StingRay is fixing up Player Manager 2 !! hehe god knows why... it`s an aweful game... but some people seem to like it... he`s fixing bugs in the game as he goes... so I guess thats good in one way!

[alkis21]

The new WHDLoad patch for KO2CV1.04 is ready and it can be found in http://www.whdload.de/ . According to StingRay, this slave is programmed in a way so that it will support all future competition versions without the need for an update!

[Steve Camber]

I don't think it will work for all future versions - as the executable grows and hits the next 512byte barrier, the bootblock will change, so the checksum will change and the adf will no longer be recognised. In theory anyway!

[alkis21]

Oh well, if it doesn't we still know where to find him. I sent him a copy of my game as a minimum token of appreciation for his hard work.

[alkis21]

To be precise, what he said to me yesterday was "I now just look for the code sequence that has to be patched instead of using hardcoded offsets (which will change with every update)". In any case, I told him what you said and I am waiting for his comment on it.

[Kostas O]

I sent him a copy of my game as a minimum token of appreciation for his hard work.

Cornelius' Easter version i imagine...

[Steve Camber]

To be precise, what he said to me yesterday was "I now just look for the code sequence that has to be patched instead of using hardcoded offsets (which will change with every update)". In any case, I told him what you said and I am waiting for his comment on it.

It's just a search for the A1200 "disable cpu cache" code which removes the need for a boot disk, and will vary in position as KO2CV grows. Not sure why this has to be disabled though!
I've also taken the palette and copperlist fixes WHDload applies and imported them directly into KO2CV. No idea what effect that will have as I'm no amiga expert. I was never sure how the palette stuff was working anyway as it made no sense before... maybe just a bit of Dino luck.

[alkis21]

Not sure why this has to be disabled though!

Because WHDLoad won't work with the Cache disabled, and in any case there is no need for every game to do a software degrade as it's all done internally.

[StingRay]

I also see StingRay is fixing up Player Manager 2 !! hehe god knows why... it`s an aweful game... but some people seem to like it... he`s fixing bugs in the game as he goes... so I guess thats good in one way!

I just made the patch because people requested it. I don't care if the game is lousy or not because I never play it anyway.

I don't think it will work for all future versions - as the executable grows and hits the next 512byte barrier, the bootblock will change, so the checksum will change and the adf will no longer be recognised. In theory anyway!

This is of course correct, from my source:

Code: Select all

;      - simplified the patch for the Competition version,
;        code searches for the cache stuff and skips it,
;        should now support any future version automagically
;        as long as the bootblock is not changed



However, a possible solution would be that you just load "number of bytes required for game + some more bytes", some more bytes being a value that would leave enough room for any future updates, that way I'd never have to update the WHDLoad slave again when a new Competition version is released.

f.e.:

Code: Select all

MAX_PATCHSIZE = 20480 ; 20480 bytes for any patches (needs to be a multiple of 512)
...
move.l   #GAMESIZE+MAX_PATCHSIZE,$24(a1) ; load game + "buffer"
...


This should solve the "problem" nicely. Let me know what you think.

It's just a search for the A1200 "disable cpu cache" code which removes the need for a boot disk, and will vary in position as KO2CV grows. Not sure why this has to be disabled though!

It has to be disabled because any OS access is not allowed in WHDLoad, ExecBase contains a "bogus" odd address value which will make WHDLoad terminate with an error as soon as any ExecBase access is detected.

I've also taken the palette and copperlist fixes WHDload applies and imported them directly into KO2CV. No idea what effect that will have as I'm no amiga expert. I was never sure how the palette stuff was working anyway as it made no sense before... maybe just a bit of Dino luck.

The palette fix is required because the game has a serious bug, it writes palette values to "random" memory locations (really stupid code!), I can't remember why the Copperlist fix was required but it was definitely because of another bug in the game (unfortunately bugs are quite common in Dino Dini games, Goal! has lots of them too f.e.).

Because WHDLoad won't work with the Cache disabled, and in any case there is no need for every game to do a software degrade as it's all done internally.

This is not quite correct, I explained in my reply to Steve why it has to be disabled.

[Steve Camber]

However, a possible solution would be that you just load "number of bytes required for game + some more bytes", some more bytes being a value that would leave enough room for any future updates, that way I'd never have to update the WHDLoad slave again when a new Competition version is released.

f.e.:

Code: Select all

MAX_PATCHSIZE = 20480 ; 20480 bytes for any patches (needs to be a multiple of 512)
...
move.l   #GAMESIZE+MAX_PATCHSIZE,$24(a1) ; load game + "buffer"
...


This should solve the "problem" nicely. Let me know what you think.

The "some more bytes" option is not a permanent solution here, more of a "delaying of the inevitable". Have you seen the size of the wishlist!?
However, I can place an agreed identifier in the bootblock, even including the exact address of the cache disabling code which would signify it as a WHDLoad-friendly KO2CV adf.

How does that sound for a solution?

[Steve Camber]

I've also taken the palette and copperlist fixes WHDload applies and imported them directly into KO2CV. No idea what effect that will have as I'm no amiga expert. I was never sure how the palette stuff was working anyway as it made no sense before... maybe just a bit of Dino luck.

The palette fix is required because the game has a serious bug, it writes palette values to "random" memory locations (really stupid code!), I can't remember why the Copperlist fix was required but it was definitely because of another bug in the game (unfortunately bugs are quite common in Dino Dini games, Goal! has lots of them too f.e.).

I've just taken another look at this as it amazes me how it ever worked. It seems like a simple typo - Dino is writing the colours for the palette into DFF080 instead of the correct DFF180. In theory that should have been zapping other registers such as copper list, display and interrupt. Surely KO2 had no right to ever work!! Yet if I disable the code altogether then the palette does not change so it must be doing something useful. Can you shed any light on this? I'm an Amiga noob

[StingRay]

The "some more bytes" option is not a permanent solution here, more of a "delaying of the inevitable". Have you seen the size of the wishlist!?
However, I can place an agreed identifier in the bootblock, even including the exact address of the cache disabling code which would signify it as a WHDLoad-friendly KO2CV adf.

How does that sound for a solution?

Hello again, it's been a while. Been quite busy the last months so I didn't check the forum. Anyway, your solution sounds excellent, this will solve the problem nicely. Something like a "KOCV" ID (fits nicely in a long) followed by the offset to the cache disabling code at the end of the bootblock would be perfect I think. What do you think?

I also noticed that you have made quite a few updates to the Competition version meanwhile, I'll add support for the new versions in my WHDLoad patch now.