Slave ASM and compile

[field3d]

Oh wow excellent tips. I see some commands are tricky and needed to know not to guess as move the 8 bytes in the PL S, etc.

I made some tests and I could inject finally properly some NOPS (4e71) inside codes now all is very clear.

Yes @jotd I noted that I installed amikit with HRT Mon to check and wow the memory is so big is very good the tip because the F 0 FFFFFFF is unreal hehe.

Just one thing I see there are different source codes that support games that are not AMIGA DOS 100% as Psygnosis games. I have some .raw or .scp or .ipf formats What format is supported or how can I convert my images to the proper format accepted? Solved maybe.

Well in these examples I could made the image via the install and with softress plugin apparently work. However, the installation of the source install fine the game and images but crash and they are not recognized. Apparently I think it will be a problem as I suppose as images are not the same than what is the source and these ones in specific involve tracks and sectors. The images created by th install I boot with without the whdload and run fine but the whdload slave crash One example is lotus 3 and nighbreed.

[paraj]

Originally Posted by copse

Is there a resource that will let one get set up in using whdload for patches avoiding the problems above? There was some thought expressed to creating an hdf for instance to streamline the process, but that was dismissed due to it requiring on device assembly using barfly.

I've started a new thread: https://eab.abime.net/showthread.php?p=1684526 to avoid cluttering up this one. It's not streamlined, but should be sufficient (otherwise complain over there).

[field3d]

All is fine and runs perfectly about compilation I have a lot checked and compiled without any problem. But as I said night breed anction game and lotus 3 I have some problems. I have some of my versions and I’m testing the source codes available in whdload I noted they check crc agains d0 the crc16 as normally is done, of course to check this. But I add my new crc and is accepted is perfect but when I run it says:

“Exception "Line 1010 Emulator" ($28)
at $1304C occurred.”

Any idea what could be happening?

The same thing happen with both titles but apparently is something more I can’t catch why is not running.

[paraj]

Originally Posted by field3d

All is fine and runs perfectly about compilation I have a lot checked and compiled without any problem. But as I said night breed anction game and lotus 3 I have some problems. I have some of my versions and I’m testing the source codes available in whdload I noted they check crc agains d0 the crc16 as normally is done, of course to check this. But I add my new crc and is accepted is perfect but when I run it says:

“Exception "Line 1010 Emulator" ($28)
at $1304C occurred.”

Any idea what could be happening?

The same thing happen with both titles but apparently is something more I can’t catch why is not running.

You can't just change the CRC check value. The check is done to ensure the version that is being patched is the expected one. Generally whdload slaves assume you have the original game/demo in the expected versions, and just don't work if you don't. Some support multiple versions and uses CRC to find out what version you have (and some nicer ones only support one but check it's the expected one anyway as a courtesy, but don't rely on it!).


Unless you are an expert then don't use versions other than the supported one! It's very likely all patches need to be changed. Sometimes it's just a few, or a fixed offset just needs to be applied, but really, this is not something I would venture into unless I was very familiar with how the game/demo worked already.


If you have a different version of some game compared to what the slave supports the very first thing you need to do is compare them at a high level, and figure out what is changed. If it's just a matter of you having a cracked version, then maybe it's easy, but again, not beginner level stuff..

[jotd]

supporting new versions is less painful with some methods

I personally dump the binary of one of the supported versions just before boot / main / etc... then I dump the binary of the unsupported version and disassemble both.

Beyond Compare is able to relate both sources (it will focus on the instructions, and less on the offsets). Search the patch addresses on the side of the supported version, and try to match it on the unsupported version. Then adapt the patchlist offsets. Works great. I used to do it manually and was reluctant to adapt to more versions until I found this method.

[field3d]

@jotd Yes I was thinking that. I will try to check my release. Maybe I changed in that times some things but as is a lot of time and need to dig deep against the release untouched. I just want to preserve for nostalgia that releases. If I boot from the disk images it runs very good but I don’t know what I did at the 90s. I need to familiarize fine with eh WHDLOAD btw.