VOGONS

Common searches


First post, by llm

User metadata
Rank Member
Rank
Member

http://www.thealmightyguru.com/Reviews/Castle … CA-TheGame.html (thealmightyguru was in contact with the author and got his ok for distribution)

Castle Adventure is perfectly working under dosbox - but i try to unpack the exe (IDA detects oversize - that normaly(or very often) means some sort of exe packer was used)
the mighty UNP http://unp.bencastricum.nl/ and some other EXE unpackers are unable to detect/unpack the used packer (it does not seems to be Microsofts EXEPACK)

the game itself is compiled (according to Wikipedia: https://en.wikipedia.org/wiki/Castle_Adventure) with Microsft Basic 2.x+ (according to the release date)

any ideas?

Reply 1 of 5, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Moved this to Milliways because it has nothing to do with getting the game running in either DOSBox or real DOS.

FYI, the executable is NOT packed. The header indicates the actual program image size, but the file size is an integral of 128 because the old versions of BASCOM write in 128 byte blocks (probably due to using an FCB). Note that stuff past the program image is either extraneous (as in the case of BASCOM), appended overlay(s), or info for debuggers like CodeView; it's not indicative of packing.

Reply 2 of 5, by BloodyCactus

User metadata
Rank Oldbie
Rank
Oldbie

yeah, its not packed. 1 second in a hex viewer would tell you that.

--/\-[ Stu : Bloody Cactus :: [ https://bloodycactus.com :: http://kråketær.com ]-/\--

Reply 3 of 5, by llm

User metadata
Rank Member
Rank
Member

thanks for moving the post and the info that the game isn't packed at all

it seems that some sort of decryption is done before the actual game starts (the IDA disasm looks strange after the third call after start) - lets see

Reply 4 of 5, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

There is no encryption. Many BASIC compilers put parameter data immediately after CALL and INT instructions, and the subroutines read the data and adjust the return address past it. I suppose this method of passing parameters can have greater flexibility than the more common method of pushing onto the stack, but data between instructions causes problems for disassembly, to say the least.

That page mentions Castle Adventure's savegame bug. The SAVE command writes monster data including the x,y position, but the LOAD command does not read the position, causing the monster array to get filled with wrong values.

I made a fix so the game correctly loads all of the monster data from save files. I'm sure that the bug would be easy to fix in the source code, but having to do it in the compiled code is not easy for the reason I described earlier. Put the attached program where CASTLE.EXE is located, and it's named so you can start the game by typing "CASTLE" as usual.

Edit: updated fix that works on all known versions of the game.

Attachments

  • Filename
    CAFIX.ZIP
    File size
    288 Bytes
    Downloads
    74 downloads
    File license
    Fair use/fair dealing exception