Problem creating my first Whdload install: empty slave

[emuola]

Decided to try to make my first own install using the new Fred's Journey. The game has only one adf file, so it should be simple to create a whdload install for it.

https://www.pouet.net/prod.php?which=85282

Whdload install script goes through without errors and it seems all is ok. However my .slave file is 0 kb in size and I get:

DOS-Error #235
(bad loadfile hunk)
on loading "Freds.slave"

The disk1 file gets created ok and everything else also seems to be as it should (compared to the files of other simple working whdload installs).
Is there some basic error in my install script, which could cause this? I've tried with different #version settings (DIC and Files), but the slave is always empty.

Any clues?

[StingRay]

Originally Posted by emuola

The game has only one adf file, so it should be simple to create a whdload install for it.

The number of files/disks has absolutely nothing to do with the difficulty creating a patch. There can be single file games/demos which take MUCH longer to patch than a trackloaded game with several disks.

Whdload install script goes through without errors and it seems all is ok. However my .slave file is 0 kb in size and I get:

DOS-Error #235
(bad loadfile hunk)
on loading "Freds.slave"

Did you copy the correct slave to the install directory? If so, I'd like to see the install script.

[emuola]

Originally Posted by StingRay

The number of files/disks has absolutely nothing to do with the difficulty creating a patch. There can be single file games/demos which take MUCH longer to patch than a trackloaded game with several disks.

Ok, I somehow assumed that the more disks the more complicated Live and learn!

Originally Posted by StingRay

Did you copy the correct slave to the install directory? If so, I'd like to see the install script.

I'm not 100% sure what do you mean by "copying the correct slave"? Here's the install script. Sorry, just starting this, so be patient

[StingRay]

I'm not 100% sure what do you mean by "copying the correct slave"?

Well, you need to create a slave which contains the patches for the game. This is a normal AmigaDOS executable and needs to be in the same directory where you have the install script.

Here's the install script.

The install script looks fine. So I suppose Freds.slave is broken.

Sorry, just starting this, so be patient

No problem, we all have to start somewhere.

[emuola]

Originally Posted by StingRay

Well, you need to create a slave which contains the patches for the game. This is a normal AmigaDOS executable and needs to be in the same directory where you have the install script.



The install script looks fine. So I suppose Freds.slave is broken.


No problem, we all have to start somewhere.

Ok, thanks for the input StingRay

Actually I just realized that I'm trying something way beyond my capabilities here... I though that if there aren't any copy protection stuff or something like that, the installer would patch me the files somehow. How wrong I was...

There are some examples supplied with the dev package, let's see.

[emuola]

I have to say this is way out my league :/ I have to start with something a lot more easier.

[Retro1234]

Try a Generic Slave but any real patching a good grasp of ASM is required - That's why I don't code Slaves

[emuola]

Originally Posted by Retro1234

Try a Generic Slave but any real patching a good grasp of ASM is required - That's why I don't code Slaves

Yeah, I realized that

[jotd]

multiple disks => more complicated install script. But install script is only the easy & tedious part (except in some cases where you have to code a RawDIC slave or figure out the layout of bitmap disks.

If you're patching an installable game (with executable), modifying a generic kick slave may do the trick. Sometimes you just need to add some assigns.

But if you want to patch something in the executable, you'll have to disassemble it (with ira -a, see ira tutorial on eab http://eab.abime.net/showthread.php?...l+ira+tutorial), debug the code while it's running and figure out what to change, then relate the code to executable segment offset

If the executable is packed, you have to use xfddecrunch in the install script to decrunch it, or unpack in slave and install a hook to be called back when the code has been unpacked.

There are tons of slaves, most of my slaves have source, Stingray ones too, CFOU! .... I did a lot of DOS-compatible/kickemu ones. For instance Microprose or Sierra, Lucasfilm titles. Check those, and use a working version/disassembly. I can provide enhanced disassembly for most games I've patched.

Then you can create a patchlist and use resload_PatchSeg.

Piece of cake after doing that for 25 years, I know

[StingRay]

Originally Posted by emuola

I though that if there aren't any copy protection stuff or something like that, the installer would patch me the files somehow.

It would be nice if that was the case but it's not possible. However, as Fred's Journey is a recently released game I assume the code should be fine (disclaimer: I haven't checked it but as it was made by Cosmos Designs I'd like to assume there aren't any major problems with the code). Hence you could try 2 things:


- use the Kickstart 1.3 emulation code, load the game using LoadSeg and, if you're lucky, the game might already work without any further patches.

- if you might want to have a bit more of a challenge you can also try creating a patch without using the Kickstart emulation code, you would have to load the game using resload_LoadFile, then you need to relocate the executable using resload_Relocate and you also need to patch/remove all OS calls in the code (AllocMem, OpenLibrary etc.). I wouldn't really recommend this for a beginner but it's always worth to try things.

[emuola]

Originally Posted by jotd

multiple disks => more complicated install script. But install script is only the easy & tedious part (except in some cases where you have to code a RawDIC slave or figure out the layout of bitmap disks.

If you're patching an installable game (with executable), modifying a generic kick slave may do the trick. Sometimes you just need to add some assigns.

But if you want to patch something in the executable, you'll have to disassemble it (with ira -a, see ira tutorial on eab http://eab.abime.net/showthread.php?...l+ira+tutorial), debug the code while it's running and figure out what to change, then relate the code to executable segment offset

If the executable is packed, you have to use xfddecrunch in the install script to decrunch it, or unpack in slave and install a hook to be called back when the code has been unpacked.

There are tons of slaves, most of my slaves have source, Stingray ones too, CFOU! .... I did a lot of DOS-compatible/kickemu ones. For instance Microprose or Sierra, Lucasfilm titles. Check those, and use a working version/disassembly. I can provide enhanced disassembly for most games I've patched.

Then you can create a patchlist and use resload_PatchSeg.

Piece of cake after doing that for 25 years, I know

Thank you jotd Indeed, you made it sound pretty easy Let's see where this leads me.

Originally Posted by StingRay

It would be nice if that was the case but it's not possible. However, as Fred's Journey is a recently released game I assume the code should be fine (disclaimer: I haven't checked it but as it was made by Cosmos Designs I'd like to assume there aren't any major problems with the code). Hence you could try 2 things:


- use the Kickstart 1.3 emulation code, load the game using LoadSeg and, if you're lucky, the game might already work without any further patches.

- if you might want to have a bit more of a challenge you can also try creating a patch without using the Kickstart emulation code, you would have to load the game using resload_LoadFile, then you need to relocate the executable using resload_Relocate and you also need to patch/remove all OS calls in the code (AllocMem, OpenLibrary etc.). I wouldn't really recommend this for a beginner but it's always worth to try things.

Ok, will try the GenericKick13.slave example. Thank you StingRay

[jotd]

if you might want to have a bit more of a challenge you can also try creating a patch without using the Kickstart emulation code, you would have to load the game using resload_LoadFile, then you need to relocate the executable using resload_Relocate and you also need to patch/remove all OS calls in the code (AllocMem, OpenLibrary etc.). I wouldn't really recommend this for a beginner but it's always worth to try things.

that is possible only if the game uses dos.library mainly (example: Oscar AGA). If the game uses graphics library and/or intuition or other extensively (to open screens and all), you're not going to be able to emulate those calls easily. I used to do that to some extent when taking on Harry OSEmu but when kickemu came out I gave that up.

[StingRay]

Originally Posted by jotd

that is possible only if the game uses dos.library mainly

Not true! Any and all OS functions can be emulated and I have done this in numerous patches as I don't really like patches which require Kickstart emulation. And usually, in the case of games or demos which disable the system, there aren't many OS calls.

[jotd]

Stingray, 20 years ago, I have written intuition library & graphics library emulation routines with OSEmu, implemented overlay loading with dos.loadSeg (Try to emulate overlayed executables for instance. it's horrible to do. And resload_Relocate isn't going to help a bit), added fastmemory support, added a lot of stuff, but still some games proved incompatible, and there were sometimes some strange lockups/issues, and endless hours of debugging. It allowed me to learn a lot about the OS, but it was also exhausting and frustrating.

When kickemu came up, it made those patches so much easier it wasn't worth maintaining an alternate and not reliable version like OSEmu. I know Psygore has his own osemu code that he sometimes links to his slaves. But since he never releases his sources it remains a mystery...

My notes about Maniac Mansion switch from OSEmu to kickemu:

Game worked almost OK using OSEmu but a bug in some gfx lib emulation routine f***ed up
the scrolling to the left (!). Using original graphics library through KickEmu works.

But I agree, if it's possible to get rid of KickEmu it should. But it's a hell more work. And is that worth the time?

And there are numerous cases where the games open an intuition file selector for instance. Good luck reimplementing that. I agree with you that with most action/arcade games it's more doable (specially ones that kill the OS in the floppy version but use the OS in the CD/AGA version). But frankly I prefer providing more games to people / adding joypad controls to slaves than reducing memory usage by 256kb and spend 5 hours more patching os calls.

Don't worry, we get along very well with Stingray, it's just that we have diverging interests sometimes, and we'll have to agree to disagree on that point.

[StingRay]

I am referring to your "only possible for dos.library mainly" statement and that is, plain and simple, incorrect!

It of course doesn't make sense to emulate OS calls for 100% system-friendly games/demos. For all other cases it just is a matter of how much time one is willing to spend emulating OS stuff. So regarding that, we actually do not disagree at all.

The game in question does kill the system and bangs the hardware directly which was the sole reason I suggested trying to do it without Kickstart emulation.

[emuola]

Hmm.

I disassembled the game (only one big file really) and found e. g. this in the start.

ABSEXECBASE	EQU	$4
CIAB_PRA	EQU	$BFD000
CIAA_PRA	EQU	$BFE001
CIAA_SDR	EQU	$BFEC01
HARDBASE	EQU	$DFF000
VPOSR		EQU	$DFF004
VHPOSR		EQU	$DFF006
JOY1DAT		EQU	$DFF00C
POT1DAT		EQU	$DFF014
DIWSTOP		EQU	$DFF090
DMACON		EQU	$DFF096
INTENA		EQU	$DFF09A
INTREQ		EQU	$DFF09C
BPLCON3		EQU	$DFF106
SPR0DATA	EQU	$DFF144
COLOR00		EQU	$DFF180
BEAMCON0	EQU	$DFF1DC
EXT_0011	EQU	$DFF1FC

Would there be something to look for in the code below? I mean related to the load routine or something to that direction. Sorry, I'm really a beginner here

[StingRay]

Those are hardware registers which you don't need to care much about except for BEAMCON0 (mostly used to switch between PAL/NTSC) as writes to this register have to be patched/removed for WHDLoad.

[jotd]

seems that you're using IRA. Good choice. But which version are you using?

because this EXT_0011 EQU $DFF1FC suggests that the version is old (it's FMODE address)

Looks that this is a game which is PAL/NTSC and also AGA aware. But whdload already starts with "degraded" ECS by default.

You may also use my cheapres.py post-processor for IRA (in https://github.com/jotd666/amiga68ktools) to try to put a name on some/most OS calls, and also custom register offsets. Really helps to see what's going on. You need a modern machine with python installed on it. If you can't, send/zone your executable I can try to process it myself.

[Wepl]

I would recommend to use an interactive Reassembler like ReSource. With that you can more easily follow the code paths and learn how a program is working. IRA is good for quickly disassembling a program but less suited to understand a more complex code structure.

[emuola]

Thanks for the tips and help guys

My IRA version should be the latest available. I also downloaded the demo version of the ReSource. Haven't really tried it seriously yet.

I also started to think about Winuae debugger, that could be a valuable tool? Or am I somehow completely on a wrong track here?

The main game file is in the Zone now (fred).

My appreciation to you Whdload experts has risen at least 1000% in the last few days