Problem creating my first Whdload install: empty slave
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? |
Quote:
Quote:
Did you copy the correct slave to the install directory? If so, I'd like to see the install script. |
1 Attachment(s)
Quote:
Quote:
|
Quote:
Quote:
Quote:
|
Quote:
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. |
I have to say this is way out my league :/ I have to start with something a lot more easier.
|
Try a Generic Slave but any real patching a good grasp of ASM is required - That's why I don't code Slaves :D
|
Quote:
|
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 :) |
Quote:
- 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. :) |
Quote:
Quote:
|
Quote:
|
Quote:
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. |
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: Quote:
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. |
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. |
Hmm.
I disassembled the game (only one big file really) and found e. g. this in the start. Code:
ABSEXECBASE EQU $4 |
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.
|
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. |
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.
|
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 :bowdown |
All times are GMT +2. The time now is 19:25. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.