Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[bruceuncle]

Did someone mention disassembly and a 68k version?  I don't know the game in detail (shame on me!) but if you can supply the executables and data files I can Resource them...  Got plenty of macros, libraries and practice now after all that Resourcing in CSI AMOS

[MadMunky]

Did someone mention disassembly and a 68k version?  I don't know the game in detail (shame on me!) but if you can supply the executables and data files I can Resource them...  Got plenty of macros, libraries and practice now after all that Resourcing in CSI AMOS

Bruce are you talking about the Amiga version? Bit is doing the PC version but if you know how to do the 68k version your more than welcome I can PM you the disk

[bruceuncle]

Yep, the Amiga version.  I'm still up to my neck in AMOS bugs and docs.  But I do like an occasional diversion as AMOS docs and cross-referencing can drive me up the wall some days 

I don't think people in the Amiga community understand how powerful the Resource program is.  I'm pretty sure the problem arises from the printed manual being a bit skimpy.  The built-in help system is far more extensive but you can only really use it on-screen, accessing each menu item in turn.  And a bit like some 'phone manuals, it assumes you know what you're looking for and what all those menu items do!  I know it took me quite a while using it to realise how easy it is to do some pretty complex stuff with it and how powerful it is.

Yet another project is to Resource the Resource Help library and turn it into a manual...  Aaaargh!

[Hungry Horace]

Didn't I post the amiga binary somewhere?? (I have attached a copy to this post)

This would be excellent bruceuncle, and I'd very grateful for any efforts you made into this!

The binary file contains everything... Game code, data, graphics,sound... But we have mapped out a lot of the data so I would gladly help you with this in order to make the resourcing easier.


My ideal situation is to have the asm source  code and actually get it implemented into Amos code so that I could implement using IFF graphics (making new additions easier) but retain the main game core in asm so that the internal logic remains unchanged.

I've never actually compiled any asm in Amos though...


There is also the extended level,s, but there is a lot of duplication in that code anyway.  I've also attached the WHDLoad slave source code, as it patches the copy protection and disk loading etc. (although obviously uses the WHDload macros for the latter)

[bruceuncle]

Didn't I post the amiga binary somewhere?? (I have attached a copy to this post)

Thanks - got it!
I may take a little time out this weekend to do the first few passes in Resource.

The binary file contains everything... Game code, data, graphics,sound... But we have mapped out a lot of the data so I would gladly help you with this in order to make the resourcing easier.

Anything you've got on the data locations (and format?) of any data files and any data embedded in the binaries would be of enormous help.  The most tedious part of Resourcing binaries is sifting through the first few disassembly passes for incorrect data-versus-code assumptions.

My ideal situation is to have the asm source  code and actually get it implemented into Amos code so that I could implement using IFF graphics (making new additions easier) but retain the main game core in asm so that the internal logic remains unchanged.

Yeah.  My own attitude to AMOS programming is to use it (AMOS) to get stuff up and running, then see what might benefit from a bit of asm optimisation.  The compiler just incorporates the code in the final compiled program.  AMOS still takes care of passing parameters in and out where you define machine-code Procedures.  I used parameter passing in that DBL Editor I released a while back if you want to look at an example.  So, you should easily be able to incorporate existing machine code from Bloodwych into an AMOS program as long as the source code and data are reasonably structured.  In any case, when the source has been extracted, it is, of course, editable and can be reassembled into whatever building blocks you need.

I've never actually compiled any asm in Amos though...

Do you mean

• "never actually compiled a program with machine code in it"

or

• "never actually used machine code in an AMOS program before"

?

The compiler shouldn't be a problem as I seem to vaguely remember some of the tools use embedded machine code and they have compiled versions.  I'll check up on that.

Incorporating machine code into AMOS is easy once you understand how to do it.  I prefer putting the machine code into Procedures as that way you can easily call them from AMOS and define parameters and return values.  Piece of cake! 

I've also attached the WHDLoad slave source code, as it patches the copy protection and disk loading etc. (although obviously uses the WHDload macros for the latter)

Looks like I'll need to find out more about WHDLoad    I'd been putting that off as I've got my hands full with what I'm having to learn already.

Thanks again.  I relish the break from AMOS docs and bugs for a little while.  AMOS is a loooong project for spare time work and it can take quite a while to get to the bottom of exactly what something does or why it's not working.  I need something where I can say "That's complete!". 

[Hungry Horace]

I did mean I have never used ASM in AMOS in any form whatsoever!!

I will definitely look at a complete list of data areas for you....   My editor uses a data file with addresses in it to determin locations in different versions - If I accompany this with data block lengths I am sure this will cover a lot for you, and I know MadMunky might hacse some info on where certain graphics are stored.



Don't stress too much about WHDLoad's own macros, I was more thinking that the "patch lists" might help you determin the location of some of the important code for marking up (e.g. copy protection, Disk routines, keyboard stuff etc)

[Hungry Horace]

I split the topics

This is mostly from what i call, at the moment, the "439 datamap" (used to load the specific 439 binary into my editor) , but i have also add some lengths on the right for you...

Sorry about the mix of hex and binary data lengths (it depends on how i checked them) but i hope this helps


---------

000002C3 - Raw keyboard Keys for Control [12]
000002D6 - Main Menu Text [$EC]

0000D8E1 - Words Text [$85C]
0001899F - Gamer Font [$1DB]

0000EBBC - Map Data #1 [!4096]
0000FFBE - Map Data #2 [!4096]
000113C0 - Map Data #3 [!4096]
000127C2 - Map Data #4 [!4096]
00013BC4 - Map Data #5 [!4096]
00014FC6 - Map Data #6 [!4096]

0000FBBE - Object Data #1 [!1026]
00010FC0 - Object Data #2 [!1026]
000123C2 - Object Data #3 [!1026]
000137C4 - Object Data #4 [!1026]
00014BC6 - Object Data #5 [!1026]
00015FC8 - Object Data #6 [!1026]

000057F4 - Switches Data #1 [!64]
00005834 - Switches Data #2 [!64]
00005874 - Switches Data #3 [!64]
000058B4 - Switches Data #4 [!64]
000058F4 - Switches Data #5 [!64]
00005934 - Switches Data #6 [!64]

00006CD2 - Triggers Data #1 [!128]
00006D52 - Triggers Data #2 [!128]
00006DD2 - Triggers Data #3 [!128]
00006E52 - Triggers Data #4 [!128]
00006ED2 - Triggers Data #5 [!128]
00006F52 - Triggers Data #6 [!128]

00017200 - Monsters Data #1 [!768]
00017500 - Monsters Data #2 [!768]
00017800 - Monsters Data #3 [!768]
00017B00 - Monsters Data #4 [!768]
00017E00 - Monsters Data #5 [!768]
00018100 - Monsters Data #6 [!768]

000171F4 - Monsters Totals / Counts [!12]

00007166 - Dungeon Start Locations [!24]
0000704E - Keep Start Locations & Floors [!26]

0000578E - Blu Gem Locations [!24]
00005776 - Tan Gem Locations [!24]

0000E7A6 - Character Statistics [!512]
0000E9A6 - Character Pocket Contents [!256]

00018400 - Spell Runes [!128]
00019B0A - Spell Names []


00019F98 - Scroll Address References [!3380]
0001A02A - Scroll Text Data [included above]

0000A418 - Character Body Selections [!86]
0000A596 - Character Head Selections [!86]
00034E44 - Character Colours [!1720]

00009AD8 - Monster Palettes []
00009A34 - Monster #1 Colours [!32]
00009E28 - Monster #2 Colours [!32]
0000A1AA - Monster #3 Colours [!32]
00009B9C - Monster #4 Colours [!32]
0000A022 - Monster #5 Colours [!32]

[bruceuncle]

Great stuff.  That makes a big difference as I can put some meaningful label names in.

[bruceuncle]

Here's a first-cut disassembly attached.

Before you look at it, there's some things you need to know about how Bloodwych loads, and hence how it runs:

• Resource puts a load of equates at the start of the source.  These are any symbols that have been defined for the code.  Even if one of Resource's built-in libraries has been used, it puts the equate in anyway so the resulting source is stand-alone.  There will be some leftover rubbish there - just ignore it all and skip to the start of the actual code.
• The executable is a memory dump with a relocator tacked on to the beginning.
• The vast majority of address references are coded as absolute addresses, meaning the final location for the game MUST start at $00000400 for them to make any sense.
• The relocator ($5C bytes) takes care of this by copying a routine to address $00000090, pointing a trap vector to that address and issuing a trap #$00.
• This vectors to the routine at $00000090 and copies the entire game code from wherever the Amiga loader has put it to address $00000400.
• Finally, it jumps to address $00000400 to start the game.

The above works fine as long as the executable is loaded somewhere above $00000400 (WHDLoad puts it at $00001000).  The copying moves from start to end, so overlap is no problem.  It's quite possible that the original loaded code is overwritten in the copying but that doesn't matter as the overwritten bits will already have been copied (moved?) to the correct addresses.  Obviously the Amiga thinks the only memory used is where it originally loaded the code and knows nothing about this relocation!

To enable Resource to make sense of all the absolute addresses, its Origin has been specified as $000003A4 ($00000400 less the $5C bytes at the start containing the relocator).  That works fine for all the usual longword references to addresses.  The only drawback is that Resource will auto-generate address labels with names based on their offset from the start of the code.  So a label like lbC001234 DOES NOT refer to address $00001234.  You have to add $3A4 to get the absolute address.

This doesn't matter where labels are involved as a label is a label is a label... so it's only a name.  But where word references to addresses occur in the code (eg.  clr.w  ($0656).w) you need to subtract $3A4 to get the correct offset from the start of the code.

I've added in symbols for the $00DFFxxx hardware addresses to make more sense of the code.  As these are absolute addresses again, the offsets usually used in code won't work as symbols.  So I've prefixed all those symbols with "custom_".

I've also added in labels for the addresses Hungry Horace supplied.  Note that the file (as opposed to the executable code) has the usual hunk headers at the start.  So the file offsets will always be $20 bytes more than the code offsets.

Where text strings are referenced with Resource's auto-labelling, I've relabelled them to make the reference a little clearer.  All other data has been formatted as word data (because that fits nicely as 8 words to a line) unless it's obvious that it isn't.  A few address tables were obvious and have been formatted as such.  It's extremely unlikely that I made correct choices every time! 

As the game uses no system memory allocation calls, all it variables space is contained in the executable - hence vast areas of zeros in the data.  This makes for an enormous assembly source file size (don't try and print it!!!).  But I thought it better to leave the whole lot there as there are many labels in the area, indicating references from the code.  I've also included the *.rs file for anyone with Resource (V6.06) if they want to massage it a bit more.  It obviously needs all those word-length address references sorting out for starters...

In at least two places, code references 'data' addresses in the midst of other code.  Which looks suspiciously like self-modifying code!  Which could be a disaster on a 68020 and up as they have instruction caches which need to be flushed after any code mods.

Whilst most data addresses are referenced as absolute, there are many referenced as offsets from a base register.  With a bit of careful mapping, you should be able to derive the structure of some of the data.

The good news is that we've now got the code and this disassembly is probably more than 95% correct as to code-versus-data choices.

The bad news is all those absolute addresses.  It makes porting any of the code a real pain as they would have to be converted to pc-relative or base-data-register offsets to be of any use.

Have fun and let me know if it's any use.

PS.  The copy of Bloodwych used is one from a floppy disk version as I wanted to see how it differed from the WHDLoad one.  There's one instruction different to the Bloodwych439 executable - a bsr in Bloodwych439 replaces an rts in the floppy version.  Search for "!!!' in the source.

[Hungry Horace]

epic. really amazing stuff mate, and many many thanks!!

So does this compile ok? I guess it would only run with WHDload as the copy protection needs to be removed, but I will see if I can find more addresses for labeling to make it easier still.

I look forward to one day understanding the content enough to make enhancements or re-build the main game engine in AMOS

[Hungry Horace]

Hey BruceUncle

This might be useful, i dunno... but its really easy to 'crack' bloodwych.

It has a Rob Northern copy protection. In the 439 EXE you can wipe over the existing code with the following (there is no effect to the files size, thanks to the copy protection keeping some space reserved.

In pure hex (good for a cheap copy/paste job in a hex editor!

Code: [Select]

23 FC 84 88 FF C4 00 00 00 24 70 00 4E 75
and in ASM:

Code: [Select]

move.l #$8488ffc4,$24.w
moveq #0,d0
rts

I don't claim to have found this... it's straight out of the WHDload slave developed by Morbidus and Girv.


However, i plan to use this version to start making nasty code hacks into the game, by splicing code onto the end of the file

[bruceuncle]

So does this compile ok? I guess it would only run with WHDload as the copy protection needs to be removed, but I will see if I can find more addresses for labeling to make it easier still.

No, it won't successfully compile unless you can persuade an assembler to just produce the code as a chunk of 'data' that also happens to be a program.  The Amiga loader would expect to see a nice juicy reloc32 hunk so's it can replace all those absolute addresses with fully relocated ones.  Which would wreck the program when it's relocated by its own built-in loader to that $00000400 address.  In any case, you'd be putting a lot of trust in my abilities to accurately sort out code-versus-data disputes in a program I've never even run (yet!). 

I should also have included the list of labels that I'd assigned so you can track them, so they're at the bottom of this post.

What are you using to view the code?  A powerful macro text editor with good search facilities would be good.  Best would be Resource itself, but it has a bit of a steep learning curve if you've never used it before.  Its big advantage is its ability to almost endlessly chase through address references to see where they go and what they do.  And then to backtrack to precisely where you started.     

A note on the Resource auto-generated labels:

• They all start "lb".
• The next letter will be "C" (=code) "L" (=long) "W" (=word) or "B" (=byte) indicating what Resource though the destination was.  So if you see something like bsr lbBnnnnnn you know there's something wrong because Resource thinks the destination is a byte, not code!
• The hex digits are the offset from the start of the code, not an address!

Anyway, this is the list of labels I added.  The numbers are line numbers in the assembler file.  Ones ending in Msg are text pointers:

63         ProgStart:
94         CodeMover:
116        GameStart:
252        RawKeyCodes:
254        MainMenuText:
4083       PartyFullMsg:
4086       RipMeOffMsg:
4089       NeverTrustUnnaturalMsg:
4092       KeepTalkingMsg:
4095       NotMyFriendMsg:
4098       NameNotImportantMsg:
4101       ZendikMsg:
4104       TooGreedyMsg:
4528       WhatThyBusinessMsg:
4565       AnyLegendsMsg:
4568       AnyEnchantedMsg:
4571       AnyWeaponsMsg:
4574       AnyPowerfulMsg:
4791       VeryPossibleMsg:
4800       NotWithMaggotsMsg:
4916       WhereIsThisMsg:
4930       ComeJoinMsg:
5460       F1_F2_F10_Msg:
5463       InsertLoadDiskMsg:
5466       InsertSaveDiskMsg:
5867       MayBuySpellMsg:
5870       SelectNewSpellMsg:
5873       ThouHastAllMsg:
5876       PauperMsg:
6349       SpellFizzledMsg:
6357       SpellFailedMsg:
7392       TanGemLocs:
7395       BlueGemLocs:
7422       SwitchData_1:
7427       SwitchData_2:
7432       SwitchData_3:
7437       SwitchData_4:
7442       SwitchData_5:
7447       SwitchData_6:
7888       OutcomeMsgs:
7899       HitsForMsg:
7901       NumHitsMsg:
8321       DoorLockedMsg:
9279       TriggersData_1:
9288       TriggersData_2:
9296       TriggersData_3:
9306       TriggersData_4:
9315       TriggersData_5:
9324       TriggersData_6:
9373       KeepStartLocsFloors:
9455       DungeonStartLocs:
9527       AccursedBloodwychMsg:
12837      MonsterColours_1:
12855      MonsterPalettes:
12899      MonsterColours_4:
13168      MonsterColours_2:
13347      MonsterColours_5:
13461      MonsterColours_3:
13641      CharacterBodySel:
13717      CharacterHeadSel:
17441      WordsText:
18037      SelectChampsMsg:
18040      SelectThyChampMsg:
18192      CharacterStats:
18231      PocketContents:
18367      MapData_1:
18626      ObjectData_1:
18713      MapData2:
18971      ObjectData_2:
19180      MapData3:
19294      ObjectData_3:
19359      MapData4:
19617      ObjectData_4:
19682      MapData5:
19940      ObjectData_5:
20005      MapData6:
20263      ObjectData_6:
20574      MonsterTotalsCounts:
20867      SpellRunesMsg_1:
20869      SpellRunesMsg_2:
20985      GamerFont:
21272      SpellNamesMsg:
21279      WearWithPrideMsg:
21344      ScrollOffsets:
21355      ScrollTexts:
28763      CharacterColours:

I've just read your other thread, so I'll put some Resource help there.  Good to see it's of some use to you guys.  Have fun   

[Hungry Horace]

Hey BruceUncle,

Thank you for all your help with this. I have some experience with ASM but I must admit, I only understand about 85% of what you've said! In particular relating to recompiling, reloc32 headers and stuff... you've lost me a bit.


I have only been using a standard text editor, which is what I've always done for my ASM coding, and used Barfly to do my compiling. I've got resource installed, and tried to use it a few times, but never particularly in depth.


You said you are not confident that you have identified all data vs. code .....  But I would assume however, that having instructions as declared values wouldn't make a difference in the short term? I have actually seen this done before in to get around compilers that haven't recognized certain (maybe 68020+ specific?) instructions. Sure, it would be nice to be confident that everything is correctly identified, but not essential immediately AFAIK ? (I could be totally wrong on this)


I would really appreciate any help / guidance you can provide in what I need to do (in laymen's language!!) to make the exe compilable... and/or otherwise let me know how I can go about butchering extra code onto the end without the loader complaining (which ic currenclty does, complaining of a "bad loadfile hunk" which to me just means "the size isnt what i'm expecting from the initialization data you've give me" if I understand it correctly.


Would it help to split the program into two? 

One as the "real" program, which you described before as being like a memory dump which includes code... which we could compile "safely" without worrying about wrong addresses, or expanding the code further (this might be limited to areas at the end of the file to being with though - I need your comments on this!)

I am even thinking.... could an AMOS program load the exe into the correct address ($400) and run it? I don't know how to specify that an AMOS program sits in a "safe" space to do this though, although we could just use the ASM relocator from AMOS and trash the memory...  (leading me on to the next item)

The second program would be the loader and relocator alone. This would include the compiled memory dump section above simply as an  " INC gamefile "


I am going to use your very helpful guide on the other thread to add lots of extra labels in though, just whilst I get to grips with resource a bit more, so again, even more thanks is due to you!!

 

[Hungry Horace]

in further developments, I've worked out how to get the reloc header to allow me to have a larger file (turns out its a single block of x no. long words I needed to  update)

The only thing i'm not sure of is whether this "new" area i'm adding is being moved to the appropriate address by the CodeMover routine (although I did adjust a number in it).... I don't think it is, as I would otherwise expect to see the last bit of "junk" I put in the location duplicated by the move (although that could be because of how i'm checking it atm).

edit:  I am now please to report that it is being correctly moved, which gives me the option to add in a space for new code 

[bruceuncle]

It's probably easiest to answer all the above by describing a bit about how the Amiga was designed to operate and how Bloodwych completely trashes that concept! 

The Amiga Loader

Unlike some other machines of that era, the Amiga doesn't allow you to load a program to an absolute address.  Nor will it let you reserve memory starting at a specific address.  However, some programmers like using absolute addresses when coding in asm.  (And it's probably easier to converted ported code from another machine?  I dunno, never done it.).

When the Amiga loads a program, it will put it anywhere that it's got a suitably sized block of memory free.  The same applies whenever a program 'asks' for some memory - it will be allocated from any free spot in memory.  The only thing the programmer can specify is whether it should load into, or allocate memory from, Chip or Fast RAM or 'don't care'.

The Amiga loader is what 'runs' an executable file by loading its program into memory and kicking it off at the start.  The loader looks for info in the executable file to tell it what to do.  These 'hunks' are defined in the AmigaDOS Technical Reference manual (I'll try and simplify it here, but hunks can do a lot more than I describe below).  They're easy to spot when you look at a hex dump of a file.  You'll probably already have noticed $000003F8 (hunk_header at the start of every file) $000003E9 (hunk_code shortly after the start of a file) and $000003F2 (hunk_end at the very end of the file).

When the assembler comes across absolute address references in a piece of code, it creates yet another hunk $000003EC (hunk_reloc32).  This contains a table of offsets into the executable code - one for every absolute address reference.  It also converts each absolute address reference to the equivalent offset from the start of the executable code - that's what gets put into the hunk_code section of the file. 

When the loader gets hold of the file, it loads the hunk_code section into appropriate memory (Chip, Fast or 'don't care').  This, as described above, can be anywhere!  But the loader now knows what the start address is.  If it finds a hunk_reloc32 section, it uses the offsets in that section to change each reference back from the offset the assembler put there to a new absolute address.  This means the program can now run happily as if nothing had changed.  Now, however, all those absolute addresses will be different from what they were originally (unless, by some huge coincidence, it happened to get loaded at exactly the same address as was used when it was assembled).

Bloodwych just uses hunk_header, hunk_code and hunk_end.  No hunk_reloc32.  So the loader assumes that it's 'position independent code' and it can load it anywhere it's got some space.  (The only constraint on where, is info in the hunks telling it that it must be Chip RAM.)  That's perfectly true for the first few bytes.  But Bloodwych then breaks all the rules and promptly whacks the 'game program' code to address $000400 and jumps there to run it.  AmigaDOS knows nothing at all about what just happened.  So if anything else was loaded, or any memory requested, it could easily be splatted right in the middle of the Bloodwych program!  Bloodwych can only get away with this because it's the only program running in memory in a freshly booted Amiga.

So no, you couldn't run such code from AMOS or anything else without first doing something about it.

A final note on hunks.  They contain the sizes of things.  But those sizes are in longwords.  So you need to divide by 4 to get bytes.

Life Wasn't Meant to be Easy

Okay, so why not just pull out the Bloodwych 'game program' bit and just assemble that, letting the assembler create the necessary hunk_reloc32?

Well, unfortunately, there are many ways of referring to absolute addresses.  The hunk_reloc32 method only works where the assembler knows for sure that it's dealing with an absolute address.  So instructions like:
    clr.b   $008C1F.l
will end up getting the hunk_reloc32 treatment.  (Note also the .l to force the assembler to use the value as the longword $00008C1F instead of the word $8C1F.)

But what about:
    move.b  d0,$05C9
The address $0005C9 is referenced, but as a word-sized operand, not a longword.  So it won't get the hunk_reloc32 work over.  You'd need to track down every one of these and convert it to something the assembler can deal with:
    clr.b   $0005C9.l
In doing so, note that you'll also shift everything following up by two bytes...

Now consider this bit:
    move.w  #$90FF,$004A(a5)
Is that #$90FF an address or data?  To find out, you'd have to track down what $004A(a5) refers to.  You might find:
    jsr  $004A(a5).w
later in the code!  Or it might just be data.  Given the size of the code, that's an enormous task.

Also note the importance of getting the code-versus-data judgement right when Resource-ing the file.  If you're trying to make it all relocatable and you've got some code incorrectly identified as data, you'll probably miss some addresses.  Aaargh!  I wouldn't like to take it on as a project

So What Can You Do?

Your best bet is to leave the executable 'as is' and hack over the top of it.  As long as you don't displace anything (use nops to fill any gaps) that would work.  You can tack some extra space onto the end of the file and jump into code there.  You'd have to hack it into the file in hex after you'd assembled what you want.  You'd also (and I'd just seen your post as I was typing this  ) have to alter the sizes in BOTH the hunk_header and hunk_code sections.  Strongly recommend reading the bit of the AmigaDOS Technical Reference Manual for the details...

You can also tell most assemblers to assemble your code at a specific location.  It's the ORG (ORiGin) directive in DevPac's GenAm.  You might get away with using the Resource disassembly by setting the origin to $0003A4 (not $000400 as you still need that tiny relocator code to do the dirty work).  I've never used that, so I don't know whether it produces appropriate hunks.  (Anyone got any help on that?)  The code-versus-data problem wouldn't apply then.


Don't know whether any of the above helps or whether I've just made it more complicated  .  As a lot of what they programmed in Bloodwych is such 'bad practice', I wonder whether they intended it to be that way specifically to prevent understanding it and modifying it.