Ultimate Amiga

Games Corner => The Crypt of Bloodwych => Bloodwych Editors and Modifications => Topic started by: bruceuncle on May 10, 2014, 08:52:16 AM

Title: Bloodwych Amiga Disassembly
Post by: bruceuncle on May 10, 2014, 08:52:16 AM
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 ;)
Title: Re: Bloodwych Amiga Disassembly
Post by: MadMunky on May 10, 2014, 09:20:50 AM
Quote from: bruceuncle on May 10, 2014, 08:52:16 AM
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
Title: Re: Bloodwych Amiga Disassembly
Post by: bruceuncle on May 10, 2014, 09:44:29 AM
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  ;D

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!
Title: Re: Bloodwych Amiga Disassembly
Post by: Hungry Horace on May 11, 2014, 07:28:45 AM
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)

Title: Re: Bloodwych Amiga Disassembly
Post by: bruceuncle on May 15, 2014, 02:38:04 AM
Quote from: Hungry Horace on May 11, 2014, 07:28:45 AM
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.

Quote from: Hungry Horace on May 11, 2014, 07:28:45 AM
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.

Quote from: Hungry Horace on May 11, 2014, 07:28:45 AM
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.

Quote from: Hungry Horace on May 11, 2014, 07:28:45 AM
I've never actually compiled any asm in Amos though...
Do you mean
or
?

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!  ;)

Quote from: Hungry Horace on May 11, 2014, 07:28:45 AM
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!".  8)
Title: Re: Bloodwych Amiga Disassembly
Post by: Hungry Horace on May 15, 2014, 01:14:31 PM
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)
Title: Re: Bloodwych Amiga Disassembly
Post by: Hungry Horace on May 15, 2014, 08:04:09 PM
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]


Title: Re: Bloodwych Amiga Disassembly
Post by: bruceuncle on May 16, 2014, 12:10:33 AM
Great stuff.  That makes a big difference as I can put some meaningful label names in.
Title: Re: Bloodwych Amiga Disassembly
Post by: bruceuncle on May 20, 2014, 02:01:13 PM
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:


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!  ;D

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.
Title: Re: Bloodwych Amiga Disassembly
Post by: Hungry Horace on May 20, 2014, 03:30:31 PM
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 ;)
Title: Re: Bloodwych Amiga Disassembly
Post by: Hungry Horace on May 20, 2014, 09:18:37 PM
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 :D
Title: Re: Bloodwych Amiga Disassembly
Post by: bruceuncle on May 22, 2014, 02:45:44 AM
Quote from: Hungry Horace on May 20, 2014, 03:30:31 PM
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!).  ;D

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.  8)  8)  8)

A note on the Resource auto-generated labels:

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   ;)
Title: Re: Bloodwych Amiga Disassembly
Post by: Hungry Horace on May 22, 2014, 08:55:27 AM
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!!

 
Title: Re: Bloodwych Amiga Disassembly
Post by: Hungry Horace on May 23, 2014, 09:41:02 AM
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  :)
Title: Re: Bloodwych Amiga Disassembly
Post by: bruceuncle on May 23, 2014, 10:29:08 AM
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!  ;D

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 ;D

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  :D ) 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  :o .  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.
Title: Re: Bloodwych Amiga Disassembly
Post by: bruceuncle on May 23, 2014, 10:32:37 AM
Quote from: Hungry Horace on May 23, 2014, 09:41:02 AM
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).
You posted this whilst I was typing.  You'll have to adjust the longword sizes in both hunk_header and hunk_reloc.  And you'll need to adjust the length of the code that gets copied:
CodeMover:
    move.l  #$58CF8,d0
Title: Re: Bloodwych Amiga Disassembly
Post by: Hungry Horace on May 23, 2014, 06:55:13 PM
yeah, it turned out the original code (before CodeMover did its stuff) was in a higher memory location than i expected, so i needed to widen my search to see the 'end' values duplicated in memory. (i stick "HORACE" at the end of my file to check for this)

I have written an AMOS program that takes the BW439 binary and a "new" block of data, and spices the two together. It keeps the reloc termination at the end of the file (after the new data) and automatically updates three values, the hunk_header the hunk_reloc and the CodeMover value as mentioned... it also 'cracks' the game, to ensure it still runs from disk, and also pads out the new code for 2-3 bytes if needed, in order to ensure the final size of the data is a multiple of 4.


I have already successfully added $3000 bytes to the file and it's still running without problem in 512k from disk... i am hoping this enough for a few basic hacks to keep the game interesting :)

My plan is actually to write / test new code in the Action Replay III , when running the game from an A500 setup. I can then just save out the data block and let it become the code i insert into the binary using this AMOS program.

The only additional work i need after that is to ensure the original instructions are patched so that my new code can run.


On a side note, you mentioned using a differenct version to "see if the disk version differed from the WHDload version" .... WHDLoad always uses "original" data and then performs its patches in memory only. Therefore, the 439 binary *is* the original from the genuine disk (439 is actually the iPF/SPS preservation disk number) and it even includes the copy protection unmodified.

The code which you identified as being an RTS instead of a BSR in your version basically stopped the Rob Northern Copylock from being called. (So i guess you were using a cracked ADF?)

My patch on this uses the WHDLoad method of cracking the game, which instead of skipping the RN code from being called, replaces it with code that feeds the 'correct' numbers, which ensures the game continues to run after any other future checks.

Title: Re: Bloodwych Amiga Disassembly
Post by: Hungry Horace on May 27, 2014, 03:20:03 PM
i'm currently in the process of building some patches to the game which can be implemented in a Macro-like manner.

I have decided that I really like the idea of additional "characters" like Zendick, and I have looked for special rules that apply in his case.

I have managed to create a script which adds patches for any character number (zendick is $40) to have their own name, and to hold a special item. That special item requires 3 seprate patches, simply to:

1- have the item in the first place
2- drop the item when they are killed
3- offer the item for trade when spoken to

i'm pleased to say all three patches are working great, and my next addition will be to allow characters to stand in the central position like Zendick does. 

This should allow my Book of Skulls maps to have a really interesting element to them. I am hopeful I may be able to add a few extra conversation topics into the game also so that there is just enough variation to stop it looking like too much of just a data-hack!!
Title: Re: Bloodwych Amiga Disassembly
Post by: Hungry Horace on May 27, 2014, 04:38:28 PM
Attached trial picture of one of the new characters....  Ophinous, who carries the Fleshbane sword.

I've put this one in because I've actually already shown a picture of this character before when I was trialing the monster editing.
Title: Re: Bloodwych Amiga Disassembly
Post by: Hungry Horace on December 10, 2015, 06:41:06 PM

bruceuncle - is there any chance of you repeating your re-sourcing of this, for the Bloodwych, Extended Levels binary?

I would be very grateful, as you did a great job on the original game!
Title: Re: Bloodwych Amiga Disassembly
Post by: bruceuncle on December 15, 2015, 10:54:06 PM
Quote from: Hungry Horace on December 10, 2015, 06:41:06 PM

bruceuncle - is there any chance of you repeating your re-sourcing of this, for the Bloodwych, Extended Levels binary?

I would be very grateful, as you did a great job on the original game!
Sure, just point me at them binaries.  Realistically, I won't get to them until after Xmas as AMOS Pro comes first.  I overdid the sitting a couple of weeks ago and spent a fortnight studying the ceiling for my troubles.  No real harm but very painful!
Incidentally, couldn't login through Tapatalk so I'm tapping this out the hard way through the keyhole than is my smartphone.  Very tedious! ;)
Title: Re: Bloodwych Amiga Disassembly
Post by: Bit on December 16, 2015, 07:01:28 AM
Hey, I missed this one somehow. I grabbed the listing immediately, and
just finished the build of my 'flow-skeleton'.
By that I found a few code/data-mismatches, which I should be able to solve myself, so that's just for the records:

Code: [Select]
there should be code instead of data at:

00148E,
0050CA,
0050D2,
007A7C, seems to be the adress part of a jump
        there's also a same thing in Atari-code
00A166,
00BEBC,
00CE58

and here are in fact datas instead of code:

002E88 (to the label),
00D39C

have to check how it can get to those routines:

0036AE, 00397A, 006C04, 00786A, 007FD4, 00833A,
0083F6, 00CC34,
00D720 (this one really unused, i think)

I'm also looking forward to a good disassembling, to me the labelnames aren't that important, because the order will be pretty the same as in the normal version. (at least that it was with the Atari).

Comparing both sources I can say (on a first view), that a lot of things are pretty the same, so HH, you're absolutely right with this.

One thing:
One of the most confusing things happens in line 005410.
There it pushes an adress (it's the flash-cursor-routine!) onto the stack,
but continues with jmp (a0), (eventhandler). So the next RTS that comes up launches that flash-routine!
Such mixes of bra and conditional jumps to the same routines hurt throughout the whole code - that's absolutely the same for Atari and Amiga.
I'm tempted to say, they did program it in Aseembler..., or they had a really weird compiler...
Title: Re: Bloodwych Amiga Disassembly
Post by: Hungry Horace on December 16, 2015, 08:55:00 AM
I have the Extended levels binary (and data blocks) for you bruceuncle and will dig then out!

Love everyone's work on this and very much appreciated :)
Title: Re: Bloodwych Amiga Disassembly
Post by: Hungry Horace on December 16, 2015, 07:29:10 PM
Hi BruceUncle

Files attached to this post...  (bottom)

BEXT-CLEAN is the main exe as before.  the other files (in a sub folder) are the extracted data blocks which should help label up some of the data (maps etc)


=====

Edit:

Quote from: Bit on December 16, 2015, 07:01:28 AM

I'm tempted to say, they did program it in Assembler..., or they had a really weird compiler...

hi bit - i dont know if you have ever read the "Trazere Trinity" article?


http://www.ultimateamiga.co.uk/index.php/topic,9683.msg45822.html#msg45822

it confirms they wre written in 68k asm on the Atari/Amiga :)

It also confirms that the PC wasnt ported by the original authors, and this explains it's many problems!!


The article is written by Richard Hewison (Rainbird Rich) who was a project manager for Mirrorsoft at the time of  Bloodwych's release. He later wrote two excellent guidebooks for the Isometric "sequels" Legend and Worlds of Legend.


Title: Re: Bloodwych Amiga Disassembly
Post by: Bit on December 17, 2015, 02:02:26 AM
That explains a lot...  ::)
Title: Re: Bloodwych Amiga Disassembly
Post by: Hungry Horace on December 17, 2015, 06:09:42 AM
Even more amusingly, there is code within Legend that is unchanged from its use in Bloodwych....
Title: Re: Bloodwych Amiga Disassembly
Post by: Hungry Horace on January 07, 2016, 07:21:00 PM
updated resource file attached.

Includes the new graphic routine calls (thanks bit) updated, including comments.

Also a few parts for the champion screen and the graphics data blocks labels done.
Title: Re: Bloodwych Amiga Disassembly
Post by: Hungry Horace on January 07, 2016, 09:06:26 PM
some info for Bit form this: (using addresses from resource) ....  you might want to look into these.


lb 00CA82 - seems to be used after selecting various graphics (e.g. shields) to do some drawing - A1 holds the graphic location

lb 00CCEA - used for writing text on the top line in game (including on game completion)   - A6 holds a text string location

lb 00CC14 - used for writing text on the lower line in game (including on game completion)

lb 00EAD8 - start of player 1 data block?

lb 00EB3A - start of player 2 data block?

lb 00C745 - null length string used for clearing printed text?
Title: Re: Bloodwych Amiga Disassembly
Post by: Bit on January 07, 2016, 10:30:55 PM
player data blocks surely right,
top line string - handling this one will be next routines in my list,
null length string - let's see
Title: Re: Bloodwych Amiga Disassembly
Post by: bruceuncle on January 16, 2016, 09:47:51 PM
Quote from: Hungry Horace on December 16, 2015, 07:29:10 PM
Hi BruceUncle

Files attached to this post...  (bottom)

BEXT-CLEAN is the main exe as before.  the other files (in a sub folder) are the extracted data blocks which should help label up some of the data (maps etc)

@Hungry Horace.  I'm running Resource in superhires, interlaced.  Can you cope with that resolution?  Reason being that Resource wraps to 1280 pixels, which would be a pain if you're running 640 pixel width.
If it's a problem just let me know and I'll put a hires environment together.  I would prefer to stay in superhires as it makes using Resouce a lot easier (more real estate on screen).
I've taken a different approach with this disassembly to try to get rid of the absolute address label versus data problems that the first disassembly had.  Should have the results (and the macros) ready this afternoon (OZ time).
Title: Re: Bloodwych Amiga Disassembly
Post by: Bit on January 16, 2016, 11:16:31 PM
About the offset problems in the 439-disassembly:
I made my memorydump in UAE at adress 0 with length 0x80000.
When I load this file with seek-value 0x400-0x5c into my data-array M[], the label's adresses fit fine to M[xxxx]. There are still some $-variables leftover that needs to be adjusted. Here's the listing:

Code: [Select]
#define delta (-0x400+0x5c)
#define var_0060 &M[0x0060+delta]
#define var_0068 &M[0x0068+delta]
#define var_006C &M[0x006C+delta]
#define var_0070 &M[0x0070+delta]
#define var_0098 &M[0x0098+delta]
#define var_05C8 &M[0x05C8+delta]
#define var_05C9 &M[0x05C9+delta]
#define var_0656 &M[0x0656+delta]
#define var_0658 &M[0x0658+delta]
#define var_065D &M[0x065D+delta]
#define var_0C50 &M[0x0C50+delta]
#define var_13C2 &M[0x13C2+delta]
#define var_13C4 &M[0x13C4+delta]
#define var_20F4 &M[0x20F4+delta]
#define var_230A &M[0x230A+delta]
#define var_31D9 &M[0x31D9+delta]
#define var_3212 &M[0x3212+delta]
#define var_3DC0 &M[0x3DC0+delta]
#define var_41DE &M[0x41DE+delta]
#define var_41ED &M[0x41ED+delta]
#define var_447E &M[0x447E+delta]
#define var_463A &M[0x463A+delta]
#define var_463E &M[0x463E+delta]
#define var_4B1A &M[0x4B1A+delta]
#define var_505A &M[0x505A+delta]
#define var_505B &M[0x505B+delta]
#define var_5794 &M[0x5794+delta]
#define var_5864 &M[0x5864+delta]
#define var_628A &M[0x628A+delta]
#define var_685E &M[0x685E+delta]
#define var_6FA8 &M[0x6FA8+delta]
#define var_7C0E &M[0x7C0E+delta]
#define var_7C20 &M[0x7C20+delta]
#define var_7C2C &M[0x7C2C+delta]
#define var_7C3A &M[0x7C3A+delta]
#define var_7C4D &M[0x7C4D+delta]
#define var_7C6F &M[0x7C6F+delta]
#define var_7C87 &M[0x7C87+delta]
#define var_7C93 &M[0x7C93+delta]
Title: Re: Bloodwych Amiga Disassembly
Post by: Hungry Horace on January 17, 2016, 10:02:06 AM

Quote from: bruceuncle on January 16, 2016, 09:47:51 PM

@Hungry Horace.  I'm running Resource in superhires, interlaced.  Can you cope with that resolution?  Reason being that Resource wraps to 1280 pixels, which would be a pain if you're running 640 pixel width.
If it's a problem just let me know and I'll put a hires environment together.  I would prefer to stay in superhires as it makes using Resouce a lot easier (more real estate on screen).

I admit, I do use a standard 640 width setup, because I like it to look the same however or whatever I'm running on....

Does it matter though? The previous disassembly looked fine on my setup!

I can however run anything on FSUAE anyway
Title: Re: Bloodwych Amiga Disassembly
Post by: bruceuncle on February 10, 2016, 11:45:09 PM
Quote from: bruceuncle on January 16, 2016, 09:47:51 PM
@Hungry Horace.  I'm running Resource in superhires, interlaced.  Can you cope with that resolution?  Reason being that Resource wraps to 1280 pixels, which would be a pain if you're running 640 pixel width.
If it's a problem just let me know and I'll put a hires environment together.  I would prefer to stay in superhires as it makes using Resouce a lot easier (more real estate on screen).
I've taken a different approach with this disassembly to try to get rid of the absolute address label versus data problems that the first disassembly had.  Should have the results (and the macros) ready this afternoon (OZ time).
Sorry for the appalling delay - I had to take some enforced downtime  :( .
Which I used to re-read a lot of the Resource and AMOS stuff (I print everything and keep it in display books so's I can peruse at my leisure - i.e. lying down  ;) ).
I took a very different approach to this disassembly as the auto-labels generated by Resource, for code that uses absolute addresses, really muck things up.  With a bit more informed work from someone who knows the game, it should be possible to identify exactly what's going on here.  Pay particular attention to what's being done with the Copper List (labelled "CopperList000" and "CopperList001" in the disassembly) to identify where the bitmaps are coming from.  Something strange with an illegal interrupt (search on "FIX") which doesn't make sense to me.  Also, some of the code appears to clear large chunks of code - maybe an anti-hacking device?
Anyway, read the READ_ME.txt file in the attached ZIP for all the gory details of what I did.  Note particularly the label prefixes I used to identify different types of stuff.  Makes searching for stuff a lot easier.  Hope it does the job.
Title: Re: Bloodwych Amiga Disassembly
Post by: Bit on February 11, 2016, 03:16:20 AM
I don't have any Amiga-tools to make those things visible. Is there any chance that you could export this to a simple txt-file?
If you got a lot of options to offer how this should look like,
try to make one that looks like that (so, opcode and current adress included in the line, labels can be pretty pure).
L_14002:
 move.l #$207bc,$204a4 // 14002: 23FC 0002 07BC 0002 04A4
Perhaps a second one when labels got names, you surely revealed a lot of things that I already haven't filled in.

Offsets of labels and real table begins are hard to be revealed, because they obviously used a lot of macros creating different temporary offsets
summed up by the assembler and shared to label and offset as it liked to do...

I can't see if that Illegal-call happens in the same place as in the Atari-code, but if so, it's reached by using the main text print-routine having a special escape combination, which in other cases sets the gfx-cursorposition or changes the current active colors.
Maybe it's used for debugging purposes, or there's something after the end of the game (can't remember what is happening then).
I bet on a debugger-call.
Title: Re: Bloodwych Amiga Disassembly
Post by: bruceuncle on February 11, 2016, 11:48:42 AM
Quote from: Bit on February 11, 2016, 03:16:20 AM
I don't have any Amiga-tools to make those things visible. Is there any chance that you could export this to a simple txt-file?
Sorry Bit, I assumed anyone interested was using Resource.  It's available in the AMOS Extensions disassemblies AMOS_Extns.rar (http://www.ultimateamiga.co.uk/index.php?action=dlattach;topic=9794.0;attach=1146).  But it's a steep learning curve.  I've attached an asm source output by Resource if that helps.
Also added a further *.rs file as I noticed that I'd missed four START+ refs that need fixing by hand, and some dc.w codes that Resource had kindly turned back to AFLINE code!

The reason I used labels containing the absolute address (after the code has been relocated to $00000400) is that some of the operands are absolute address references.  And it's a lot easier to find them in the binary.  And you may need to see what's there in some of the code that puts the Copper List instructions together.  The data for a Copper instruction is limited to word length, so it has to use two instructions to get the absolute address of any data its aiming at.  So look for runs of SWAP instructions on data registers as the easiest way to do it is:
Title: Re: Bloodwych Amiga Disassembly
Post by: Bit on February 11, 2016, 12:46:59 PM
Oh thanks! The assembler-listing is pretty enough for now. I got the one of the Atari, so all I need is the basic 'skeleton', so, sequence of routines and that. The content of the routines is to be expected the same, except for the graphic-things, and how this works I did understand in the meantime. What I need are the unnamed labels that reveal the offsets to make a huge comparison of all and help out with some information. And that's in it - so, thanks for this lot of work.
I know it are about 700 routines and I count about 600 data-labels in my stuff...
Title: Re: Bloodwych Amiga Disassembly
Post by: Hungry Horace on February 12, 2016, 09:43:26 AM
Looking forward to having a peek at this!

Thanks BruceUncle :)
When I see it , I'll have a better idea of how it differs in labelling from BW, as I confess you've lost me a bit ATM ;)
Title: Re: Bloodwych Amiga Disassembly
Post by: Hungry Horace on February 27, 2016, 10:47:24 AM
A could of questions for BruceUncle on this i guess...

having looked over the Bext .rs now, it's looking rather good.

I'd love to be able to re-compile from a new source (and then future label updates etc, would have to be put into the .asm and only if needed also back to the resource version)

- Compiling BEXT with barfly throws up hundreds of errors, but devpac only a few... traditionally i'm much more used to using BarFly for compiling.... what would be the cause of this ? (i appreciate this original BW resource needs more work)  ....  what can i do to fix it ?  (i dont relally care what i end up compiling with, as long as it works!)


- I've identified many many more data blocks (including graphics and soundfx) since this original resource. Would it help to have those to do this again? Can Resource be made to substitute a datablock with a simple INC "filename"  instead, or can we only do this when we get to the .asm stage?

- Can my updated labels and comments be easily exported from my most recent .rs (attached) and put into a new resource of your original file, to better match what you did with BEXT?

- there are some lines where fixed numbers are used, that should probably be declared (e.g.  #ZendikCharacter  should be used for #$40 in some locations) ... can we do this in Resource, or again, is this more for the .asm output?

As much as I am liking how much i've managed to edit the game thanks to the resource, i must admit, coding patches and relocating code in memory is much much harder than it would be compared to simply re-compiling the game with my changes!

All help/comments etc very welcome :)
Title: Re: Bloodwych Amiga Disassembly
Post by: bruceuncle on February 29, 2016, 10:24:42 PM
Dead lucky you are Hungry Horace.  Just after my last post, my PC expired with an impressive display of visual fireworks on screen and lots of worrying BSOD activity from Windows 7.  My ageing GTX460 had expired.  Shortly after that I totalled my smartphone  :( .  As I still can't drive very far, I was reliant on postal deliveries for both, which went badly wrong on both counts and took ages and many phone calls.  So I only got things back to normal (GTX960 and Lumia 640) just after your post.  Far too long without any communication abilities!  >:(

Quote from: Hungry Horace on February 27, 2016, 10:47:24 AM
- Compiling BEXT with barfly throws up hundreds of errors, but devpac only a few... traditionally i'm much more used to using BarFly for compiling.... what would be the cause of this ? (i appreciate this original BW resource needs more work)  ....  what can i do to fix it ?  (i dont relally care what i end up compiling with, as long as it works!)

Resource uses the assembler syntax for either Assem or C.A.P.E.68k or Macro68.  The Assem syntax seems to be the most compatible with Devpac (Genam).  I don't know Barfly but would suspect it uses something slightly different for some instructions and is why you're getting heaps of errors (or warnings?).

With Devpac I got 7 errors:

One was a line of nonsense code just before an RTE - easily fixed. 

One complained about:
  SECTION  xxxxx,CODE,CHIP
Devpac uses:
  SECTION  xxxxx,CODE_C
so easy fixed.

The others complained about Resource using:
  LINK.W  #-offset
instead of plain
  LINK  #-offset
I took the easy way out and turned off Strict Mnemonics.  It would be better to edit the offending lines in the source as the assembler may use its default sizes if the *.B, *.W and *.L size specifiers disappear, thus upsetting the size of code and data blocks.

The only other line needed was:
  ORG  $0003A4
to put the code into the correct memory location (puts GameStart at $000400).

I've attached the files in a zip.  (Don't pay any attention to the numbering system, the 40 is arbitrary and the 3 indicates the original plus two attempts.)

Quote from: Hungry Horace on February 27, 2016, 10:47:24 AM
- I've identified many many more data blocks (including graphics and soundfx) since this original resource. Would it help to have those to do this again? Can Resource be made to substitute a datablock with a simple INC "filename"  instead, or can we only do this when we get to the .asm stage?

Can't be done in Resource without an awful lot of commenting lines out and commenting the INCBIN "filename" lines in.
Better done in the *.asm file.
Note that you can use the Partial Binary Save to save chunks of data.  Set the Start on the line where the data block starts.  Set the End as ONE LINE AFTER the data block ends.  You've probably discovered this already  ;)

Quote from: Hungry Horace on February 27, 2016, 10:47:24 AM
- Can my updated labels and comments be easily exported from my most recent .rs (attached) and put into a new resource of your original file, to better match what you did with BEXT?

Erm yes.  With a bit of work.  If you're talking about the same executable,  the labels and their offsets can be written to a file with a Resource macro.  Then use another macro to import them to the new *.rs file, using the offset to locate the cursor and the label to create the new one.  Difficult to describe  ;D .  Will only work where the executables used for the *.rs files are identical.
I can redo the original to the same format as the BEXT_CLEAN one if you want.  It's mainly a matter of using those macros with a bit of manual correction.

Quote from: Hungry Horace on February 27, 2016, 10:47:24 AM
- there are some lines where fixed numbers are used, that should probably be declared (e.g.  #ZendikCharacter  should be used for #$40 in some locations) ... can we do this in Resource, or again, is this more for the .asm output?

Two ways to do it:

Use the Custom Bases (#1 and #2) under SYM to create them on the fly.  But I think you lose them when Resource closes (must check that!).

Create Symbol Libraries.  Not as hard as it looks.  Just read the docs on Symbol Libraries.  There's heaps of examples in the AMOS Extensions Disassembly stuff I did.  The rules are that within each library, the symbol values must be unique (which is why you'll probably need more than one library - think of them as separate equates lists) and the values must be in ascending order.  That last one is a gotcha if you're defining signed values as Resource treats them unsigned.

Quote from: Hungry Horace on February 27, 2016, 10:47:24 AM
As much as I am liking how much i've managed to edit the game thanks to the resource, i must admit, coding patches and relocating code in memory is much much harder than it would be compared to simply re-compiling the game with my changes!

Too true.  As far as I can see, you should be able to get a working executable out of the source.  I haven't done a byte-for-byte comparison yet.  Note that the code for Bloodwych commandeers the Amiga without any safeguards.  Like relocating the code to $000400 and allocating a stack at a fixed address ($006000 from memory, may be wrong!).  As all this is done outside of AmigaDOS, all hell could break lose if you tried it in any situation other then the WHDLoad one.  It takes over the machine, aaargh!


I'll have a look at the original and the *.rs file you supplied and get back to you.
Title: Re: Bloodwych Amiga Disassembly
Post by: bruceuncle on March 02, 2016, 07:12:11 AM
Quote from: Hungry Horace on February 27, 2016, 10:47:24 AM
All help/comments etc very welcome :)
Hi HH, attachment BLOODWYCH_HH_024.rs.uaem.zip only has a 1k file in it  :'( so could you please repost?
Title: Re: Bloodwych Amiga Disassembly
Post by: Hungry Horace on March 02, 2016, 05:24:24 PM
Quote from: bruceuncle on March 02, 2016, 07:12:11 AM
Quote from: Hungry Horace on February 27, 2016, 10:47:24 AM
All help/comments etc very welcome :)
Hi HH, attachment BLOODWYCH_HH_024.rs.uaem.zip only has a 1k file in it  :'( so could you please repost?


My bad... zipped the uaem file (the fs-uae attributes file!)

corrected zip attached!


i will respond on the other points in time, when i've had a chance to digest the information!
Title: Re: Bloodwych Amiga Disassembly
Post by: Bit on March 03, 2016, 10:50:52 PM
Comparing the extended levels versions, I found, that those don't use 32 spells, but 40. Adding those last 8 offsets to the spell-jumptable made sense and finally did connect a few routines that weren't connected. But - the first of those 8 gives me headaches:
That's the table:
Code: [Select]
adrEA005A0C:
dc.w $0000 ;0000
dc.w $0022,$002A,$0078,$00A8,$00AE,$0122,$014A,$0150 ;0022002A007800A800AE0122014A0150
dc.w $015A,$0160,$0168,$01CA,$01D2,$01D8,$01DE,$0224 ;015A0160016801CA01D201D801DE0224
dc.w $022A,$0272,$02A8,$02E8,$02F0,$02F6,$02FC,$0302 ;022A027202A802E802F002F602FC0302
dc.w $0310,$0422,$047C,$0484,$052A,$0530,$053E,$FFFA ;03100422047C0484052A0530053EFFFA
dc.w $0544,$013E,$062C,$0642,$064C,$067E,$06BA ;0544013E062C0642064C067E06BA
Adding FFFA to the basic offset given by
   lea   adrEA005A64.l,a0   ;41F900005A64
results in adress 5A5E - and that will run into an illegal opcode.
Any idea about that one? Is that known?
Title: Re: Bloodwych Amiga Disassembly
Post by: Hungry Horace on March 04, 2016, 05:53:37 AM
Surely FFFa should actually be .. -6?

Maybe it's something like spell failed / spell fizzled ?

Edit: ignore me - I can see you've already treated it as "signed"... Perhaps it simply never gets called.

Need to take some time this weekend to look over this new info!
Title: Re: Bloodwych Amiga Disassembly
Post by: bruceuncle on March 04, 2016, 11:27:47 AM
Quote from: Bit on March 03, 2016, 10:50:52 PM
Adding FFFA to the basic offset given by
   lea   adrEA005A64.l,a0   ;41F900005A64
results in adress 5A5E - and that will run into an illegal opcode.
Any idea about that one? Is that known?
You're forgetting that we're dealing with absolute addresses here where the final resting place for the code is with GameStart at $000400.  So the target address of $005A5E hits legitimate code.  One byte after the label Byte_005AD is where it points to, which is showing as data in the disassembly.  But setting it as code gives (I've manually inserted the label adrEA005A5E):

Code: [Select]
Byte_005A5D:   dc.b     $00
adrEA005A5E:   move.b   #$08,$0025(a4)
adrEA005A64:   moveq    #$00,d4

To those using Resource:

Set the cursor on the line with the adrEA005A64 label (the target base address).
Use */Convert specific EA's/Set base #1 
Set cursor on the line with the adrEA005A0C label (the jump table base address).
For each entry in the table use */Convert specific EA''s/Cvert W/base 1

That sets the correct assembler adrEA005A64-<target_address> format for the jump table entries.  Resource will generate its own lbCxxxxxx labels for any that don't exist.  Which will confuse the issue as these will represent offsets from the code start again!  You need to cursor to those labels, using right arrow from the jump table entry, and manually change them to represent absolute addresses (add $3A4 to the offset value).  Then left arrow gets you back to the jump table.

Keyboard Shortcuts:
[shift]+[alt]+[ctrl]+[1] = */Convert specific EA's/Set base #1
[ctrl]+[1] = adrEA005A64-<target_address>

On second thoughts (and probably third, fourth and fifth as well) don't worry about the Resource stuff above.  I've got macros that make it a snack, so I'll revise the *.rs and *.asm files accordingly and re-post them.  I'm revising the original BW disassembly to match the same labelling system and adding Hungry Horace's labels (all macros again) so it's probably quicker for me to sort them all out and re-post.  I know Resource is a bit of a bugger to get to grips with and some of this stuff is getting hard to describe in a post!  But for anyone using it, stick with it as it's well worth the steep learning curve.

No one said disassembly was easy  ;D

Title: Re: Bloodwych Amiga Disassembly
Post by: Bit on March 04, 2016, 12:09:32 PM
Oh yes, my fault - false translation. of 197C
Now that all makes sense...
it does
 move.b   #$08,$0025(a4)
 and then runs into an already known zone.
Fine fine fine! Thanks!
Title: Re: Bloodwych Amiga Disassembly
Post by: Hungry Horace on March 04, 2016, 08:49:08 PM
well bruceuncle... i can confirm your compiled version works fine with WHDLoad , so i will certainly start persuing the option of ripping data out of the original executable :D

not much more i can say other than "Thanks"!!!  I will have a try at compiling the same with Devpac (did you have to set any settings in the compiler?)

I will need to start looking at bit's comments to see what labels i can add of shared code between the two games also....
Title: Re: Bloodwych Amiga Disassembly
Post by: bruceuncle on March 07, 2016, 12:52:30 AM
Attached is a zip of the *.rs, *.asm and executable file revised yet again  :) .

I've made a lot of changes here.  It dawned on me that the label naming I'd originally used would make it a pain to extract labels that you guys might add later.  What was needed was a constant label prefix.  Reason being that Resource macros have no equivalent for "if x = y then".  The only way to do a comparison is to Exclusive OR the accumulator with a string.  If the result is zero (x=y) a macro fail gets generated.  If the result is non-zero, (x<>y) no fail.  Will explain more when I post the results for the original BW.

In the meantime, these are the label prefixes used and their meaning.  The checks are made in this sequence and earlier labels may be overwritten:

adrCd     Address referenced by a branch or subroutine call, so is definitely code.
adrLpAddress referenced by DBcc instruction, also definitely code.  Overwrites any previous label.
adrEAAddress reference by LEA instruction, may be code or data.
adrB_Address is data referenced as Bytes.
adrW_Address is data referenced as Words.
adrL_Address is data referenced as Longs.
adrJTAddress is the start of a Jump Table, either long absolutes or word offsets.  Overwrites any previous label.
adrJBAddress is the Base Effective Address used by a Jump Table of word offsets.  Overwrites any previous label.
adrJCAddress is a target address referenced by a Jump Table, of either long absolutes or word offsets.  Overwrites any previous label.

In the process, a lot more word-offset jump tables emerged...  Have fun  ;)
Title: Re: Bloodwych Amiga Disassembly
Post by: Hungry Horace on March 07, 2016, 08:54:52 PM
this is great bruceuncle.

There's a lot of code shared between the two games, so i should be able to start getting quite a few labels in there. 

Is it worth me pasting here, so they can go into Resource, or should i just crack on with putting them into the ASM file?  :)

Title: Re: Bloodwych Amiga Disassembly
Post by: bruceuncle on March 07, 2016, 10:26:50 PM
Quote from: Hungry Horace on March 07, 2016, 08:54:52 PM
this is great bruceuncle.

There's a lot of code shared between the two games, so i should be able to start getting quite a few labels in there. 

Is it worth me pasting here, so they can go into Resource, or should i just crack on with putting them into the ASM file?  :)


Do neither just yet.  I'm re-doing the original to the same standard.  Then the labels from the file you posted will be laid over the result.  It's better to keep it in Resource as long as possible so that it takes care of the references.

The process is easy.  Resource can output to a text file.  So all I do is :

Using your file:
Next label
Does it begin with "adr"?  If so skip it.
If not, grab the offset and label and write to a temp file.
Repeat until end.

Using the 'fresh' file and the temp labels file:
Read the offset and goto it.
Read the label and plonk it in.
Repeat until EOF

Should have it to you shortly.
Title: Re: Bloodwych Amiga Disassembly
Post by: bruceuncle on March 07, 2016, 11:54:57 PM
That should be "lbl" for the original Resource shop labels, not "adr"!  I should post from my PC rather than from my phone  ::)
Title: Re: Bloodwych Amiga Disassembly
Post by: Bit on March 08, 2016, 05:28:45 PM
Don't know if you already found it - took me ages, but the function that generates a random number is at 5218 in the normal version.
5214 calls that to produce a value between 0 and 100 (in D0), 5208 calls it to generate a random byte (in D0) with an offset added that can be set in data-byte 5207. I think this one is important.
Title: Re: Bloodwych Amiga Disassembly
Post by: Hungry Horace on March 08, 2016, 08:54:42 PM
i've started using the new .asm file to look for adr labels that i think are graphics.

I have a separate program to rip data blocks out, and then i'm able to load the blocks as raw data and view them (and export to IFF etc)


Firstly, the new ASM is giving me much cleaner label points to match up to where graphics are... this is really positive and makes things much easier.... so massive thanks to BruceUncle  :)

Second, there is at least one point (character head graphics) where there is no label at the start.   adrEA031E34  (translates to offset $31AB0 in the file).  There may be others.

In this case, I think the actual head graphics start at offset $322AC ... but there is no label here. Perhaps somewhere in the code it just uses the first label and address the length of the datablock to it to reach the starting point.  It's worth looking into, but i will naturally start my .graphics file rip at the "real" location, and i can leave in the datablock 'as is' or rip out as a separate file for separate INCBIN inclusion.
I just thought i would make it known as something to be aware of.


Thirdly, in some cases there are labels in the middle of graphics. This occurs a lot in the objects/tiles section. adrEA0494B2 (real offset $4912E)  has a massive 320 pixel wide tile set block, including objects, spells, icons etc.  However, the code uses labels in the middle of this picture, to jump to certian points (e.g. the point where the book scrolling graphic is) ....

This obviously causes me little headache for ripping (i simply ignore the 'marker' address label)  but will cause some issues when i start replacing the data blocks with INCBIN "data/Icons.graphics" ....

I am thinking that instead of say, the 'next' label being used:
e.g     
Code: [Select]
lea adrEA04D5B2.l,a1 (i think this the book turning, which is used only once)

Assuming we change the main graphic label to: adrEA0494B2  = adrAllGraphics

The page turning code should be changed to say:
Code: [Select]
lea adrAllGraphics.l+#PageTurnOffset,a1
i assume this is possible, and would simply be optimised by the compiler as a 'genuine' label?


Other than that last query, it's looking really good, and i'll be happy to do the same with the original file (which i've ripped graphics from , but not as clean as this) once that is in the same format.



@bit - random number generator sounds great!   Any thoughts if this is used in the graphics routines (i.e. the wall scrolls/signs) ... as this seems to be a seeded / 'fake' random colourisation (in other words, it always produces the same result)
Title: Re: Bloodwych Amiga Disassembly
Post by: Hungry Horace on March 08, 2016, 09:04:03 PM
additional:

all of these label points are markers within the icon graphics set;  (please ignore the fact i've butchered this for my code - the value of place(x) is the location of a label in the asm file)

Code: [Select]
place(x)=$04D0B2-_difval : name$(x)="44" : inc x
place(x)=$04D0E2-_difval : name$(x)="45" : inc x
place(x)=$04D112-_difval : name$(x)="46" : inc x
place(x)=$04D5B2-_difval : name$(x)="47" : inc x
place(x)=$04D5E2-_difval : name$(x)="48" : inc x
place(x)=$04E522-_difval : name$(x)="49" : inc x
place(x)=$04F9B2-_difval : name$(x)="50" : inc x
place(x)=$04F9BA-_difval : name$(x)="51" : inc x
place(x)=$04FC72-_difval : name$(x)="52" : inc x
place(x)=$04FC92-_difval : name$(x)="53" : inc x
place(x)=$04FF12-_difval : name$(x)="54" : inc x
place(x)=$050A32-_difval : name$(x)="55" : inc x
place(x)=$050B3A-_difval : name$(x)="56" : inc x
Title: Re: Bloodwych Amiga Disassembly
Post by: Hungry Horace on March 08, 2016, 09:20:15 PM
just poking around this new source

Code: [Select]
adrJT00B58A:
dc.w adrJC00B322-adrJT00B58A
dc.w adrJC00AD12-adrJT00B58A
dc.w adrJC00B164-adrJT00B58A
dc.w adrJC00B148-adrJT00B58A
dc.w adrJC00B374-adrJT00B58A
dc.w adrJC00B374-adrJT00B58A

adrJC00B374  is called for the end of game routine - which means it *must* be the code that draws the Entropy creatures (monsters $6B and also $6C in BEXT) ... this would explain the use of the same address, as these are the same graphic re-coloured.
 
I would therefore suggest the other addresses are likely to relate to drawing routines for the other major 4-space occupying monsters:

   adrJC00B322 - behemoth ($67)
   adrJC00AD12 - crab ($68)
   adrJC00B164 - large dragon ($69)
   adrJC00B148 - small dragon ($6A)

.... i will obviously test out this hypothosis with live data soon, but surrounding code at those addresses makes it look likely :)
Title: Re: Bloodwych Amiga Disassembly
Post by: Bit on March 08, 2016, 09:51:04 PM
The main random-routines is used only three times:
for the two others and in the beginning of battle-stuff
The 0-100-random-routine is used only in that routine that calls the main one.
The Byterandom-routine is called around 20 times, but only two times within the dungeon-drawing-routines, still I can't say what this is. I did set breakpoints, and couldn't hit them - so no carpetcolors in the beginning.
Title: Re: Bloodwych Amiga Disassembly
Post by: Hungry Horace on March 08, 2016, 10:03:24 PM
No worries bit - it's just nice to know you are finding stuff i never could!


I tried to see if my "label plus offset" idea would work. Sadly DevPac rejected it, but maybe BruceUncle will know a way around it!

I was actually going to post this to try and find an automatic way of finding the offset values.... i have a feeling that may need some ASM macros.  :S  (although a 'length of file' macro for that would probably be very useful)

Code: [Select]

PlaySound:
; formerly adrCd00968E
; === input d0 = sample number
move.w d1,-(sp)
move.w #$0001,_custom+dmacon.l
move.w #$0080,_custom+intena.l
asl.w #$02,d0
lea AudioSample1.l,a0   ;  formerly adrEA051A82
adda.w AudioSampleOffsets(pc,d0.w),a0
move.w AudioSampleOffsets+#2(pc,d0.w),d0  ; <<< not permitted by DevPac  :(
lea $0030(a0),a0
move.w -$0002(a0),d1
lsr.w #$01,d1
asl.w #$02,d0
move.l a0,_custom+aud.l
move.w d1,_custom+aud0+ac_len.l
move.w #$0040,_custom+aud0+ac_vol.l
move.w d0,_custom+aud0+ac_per.l
move.w (a0),_custom+aud0+ac_dat.l
move.w #$0078,d1
adrLp0096E0:
dbra d1,adrLp0096E0
move.w #$8001,_custom+dmacon.l
move.w #$0078,d1
adrLp0096F0:
dbra d1,adrLp0096F0
move.w #$0080,_custom+intreq.l
move.w #$8080,_custom+intena.l
move.w (sp)+,d1
rts

AudioSampleOffsets:
dc.w $0000 ; sample 1 offset
dc.w $0028 ;
dc.w $0000 ; < sample 1 offset
dc.w $009B ; < sample 1 playback rate?
dc.w $0084 ; < sample 2 offset  (length of AS1)
dc.w $005D ;
dc.w $0646 ; < sample 3 offset (length of AS1 + length of AS2)
dc.w $0028 ;
dc.w $1ECE ; < sample 4 offset (length of AS1 + length of AS2 +length of AS3)
dc.w $0049 ;
dc.w $3684 ; < sample 5 offset
dc.w $0049


edit:  just wondering if that list of offsets can be re-written as another in the style of the jump tables?
Title: Re: Bloodwych Amiga Disassembly
Post by: Bit on March 08, 2016, 10:18:24 PM
Just thought my current headerfiles can give you some inspiration.
There are the data-offsets (vnumsn,h, vnumsx.h, not Amiga yet, but sequence is almost the same - especially relative distances - Atari game start 0x14002), where I added the name of the corresponding theme-file. Maybe that helps a bit. For all graphic-things: there's in most cases just one routine that handles them!
Also added my main header where you can see the complete sequence of routines (with no offsets, but towards the end more and more names). If you need a certain adress, just tell me and I try to find it in the Amiga sources. At least for the adressregisters I should be able how to use them, maybe can tell more.
Title: Re: Bloodwych Amiga Disassembly
Post by: Hungry Horace on March 08, 2016, 10:40:40 PM
wow bit... that is crazy! There are so many labels i need to get into both the BW and BEXT amiga sources :/

might need some kind of tracking spreadsheet for all of these, lol


edit:  just seen more jump tables relating to switches/triggers.... now my brain in in overload and needs sleep! so much code to explore! :D
Title: Re: Bloodwych Amiga Disassembly
Post by: Bit on March 08, 2016, 11:06:27 PM
Slow down - the danger to mix up things is big (i know what i'm speaking off)!
 I'll continue to update my listings in the 'source details'-thread now and then.
At the moment I am working at three Atari-versions (always the extended levels simultaneously). V5 is the most developed one, but stands still, except for some tests with Mad Munky - there are a few bugs in it, but more I dislike some things in the concept now.
V6 is the hot thingy and currently at V6.12 (twelve, not 1.2) ;).
I can't see any bugs - which is suspicious - then they are evil und lurk deep in   :o
So I'm at V7 where I'm putting in all that gained knowledge, just to have some confirmation for V6.
And then all that Amiga-stuff comes in and wants to be mixed with that too - always jumping between C, 68kasm and my pseudo-emu-code.... I'm just thinking about, why not to translate it to AMOS-BASIC  8) ;) - while Munky already shows C->Javascript-Translators :-X

Edit: this thread needed urgently an halfways-off-topic non-0x post with good ole smileys :D
Title: Re: Bloodwych Amiga Disassembly
Post by: bruceuncle on March 13, 2016, 10:57:29 AM
Quote from: Bit on March 08, 2016, 11:06:27 PM
Slow down - the danger to mix up things is big (i know what i'm speaking off)!
Quite right.  If the intent is to start modifying the disassembly, then there's a LOT more work to be done in Resource before you get to that stage.  I'm doing some of that for you guys but you will need to do a lot of checking yourselves.

The reason?  Just because the disassembly will compile back to the original binary and run is good.  But there are heaps of references that will be pointing to the wrong places if the size of code and data is changed.

When disassembling a binary that uses absolute addresses with a fixed origin in memory, Resource can only do part of the work automatically.  There are three areas where the job has to be done manually and thoroughly.  All the examples below are taken from the original BW binary brought up to the same standard as the extended levels one and with Hungry Horace's labels overlaid:


It should be becoming obvious why all these three cases have to be fully resolved.  If the code or data changes size when you add mods, any original, unresolved, references will be pointing to the wrong addresses.  At best a tiresome bug would result, or far more likely for code changes, a nice fat red Guru!

I'm manually resolving these (in the same order as they appear above).  BUT how can I be sure I've got them all?

Short Absolutes are a bugger to find as they can appear in just about any instruction format.  So pattern searching for them is very tricky.

Word-sized Jump Tables are not too hard to find as they always result in something like:

              jsr     (a0)

Word-sized and Byte-sized data offset tables can be very difficult to spot.  And it looks like the code sometimes uses calculated offsets into an offset table itself that come from yet another table.  I may be wrong as I'm trying to get all the obvious ones nailed down and haven't spent time chasing down what the code's actually doing.

I think I've got all the Short Absolutes nailed.  But needs checking.
I think I've got all the code Jump Tables nailed.  More confident than the above but pretty sure.
I'm about halfway through the data Offset Tables.  I'm not at all sure I will have got all of them!

So you guys will have to spend some time looking through the detail to check after I'm finished.  You'll need to do it in Resource so that the symbols referring to labels change automatically as you turn my "adrXXxxxxxx" labels into something meaningful.  To do that you need to understand Resource's "Dynamic String Indirection".  It's explained on page 4 of that PDF I published from the help files.  It works like this:

Dynamic String Indirection

Using the Short Absolute example in (1.) above, we need a symbol that will replace:
              move.b  d0,$05C9
with
              move.b  d0,adrEA0005C9.w
If we just add a symbol as the text adrEA0005C9.w it will work but will not change if we later change the label to which it points to something more meaningful.  To do that, we can use Resource's Dynamic String Indirection.  This locks on to the file offset where the label is and expands it to look like the label itself.  The syntax for the above label looks like this:

              \e0$0225\e.w

     \e0       tells Resource the target is a label.
     $0225     is the file offset.
     \e        ends the Dynamic String Indirection format.
     .w        is plain text that Resource will just tack to the end.

Note that the offset is the target absolute address, $0005C9, minus $03A4 to adjust for the origin (GameStart) being at address $000400.  I use a macro to do all that for me.

If you've ever used these instructions to resolve a jump table or a data offsets table:

*/Convert specific EA''s/Set base #1  ( [ctrl]+[alt]+[shift]+[1] )
*/Convert specific EA''s/Set base #2  ( [ctrl]+[alt]+[shift]+[2] )
*/Convert specific EA''s/Set base #3  ( [ctrl]+[alt]+[shift]+[3] )
*/Convert specific EA''s/Cvert W/base 1  ( [ctrl]+[1] )
*/Convert specific EA''s/Cvert W/base 2  ( [ctrl]+[2] )
*/Convert specific EA''s/Cvert W/base 3  ( [ctrl]+[2] )

Resource does all the work for you.  It creates the correct symbol automatically.  To see what's underlying these conversions, use:

LABELS/Edit single/Symbol - dest

Anyway, enough waffle.  To show where I'm up to, I've attached the latest work-in-progress of the BW Resource file.  The finished versions of that and the revised BW_EXT file will be available shortly (bearing in mind how time consuming some of these searches can be  :) ).
Title: Re: Bloodwych Amiga Disassembly
Post by: Hungry Horace on March 13, 2016, 12:55:24 PM
With the offset tables, eg the action one you posted, surely many won't need changing if we treat them as a datablock to be edited separately?

For example , the scrolls.block data does this, but I would not expect the see a label for every scroll in rhe game!! Instead , I simply ensure that if I alter the scrolls data, the offset table is also updated

(It might even be prudent to separate the offsets and the text data, and write an Asm macro that calculates te offsets, by reading the line termination (this is what my editor already does)

I'm still thinking a spreadsheet of addresses and "actual names" for BW, BEXT, and rhe Atari version might help a bit....
Title: Re: Bloodwych Amiga Disassembly
Post by: Hungry Horace on March 13, 2016, 08:08:46 PM
i've started the spreadsheet and pulled in all of the labels from the BEXT asm using some VBA. Won't take too long to do the same with BW either.

At the moment, i'm using it to identify code that i know will be shared between versions. As well as tweeking the labels which refer to datablocks / graphics etc, i'll also add in what i know about the game mechanics, either from my editor, hacks or even from the WHDLoad source.

I have a dedicated folder on dropbox, if Bit / BruceUncle, you'd like access?  It would make sense to all update labels in one place, and I can add macros to export in any form you'd like  (Bruce, you may want something that suits resource for example?)

I'd love to get all the stuff bit has identified as shared with the Atari Source in there, so i may need to ask for further comments from you Bit :) 


downlaod link is here, but shared access would be better:
https://www.dropbox.com/s/l1po6bbig0wfed9/BW%20Data%20Mapper.xlsm?dl=0
Title: Re: Bloodwych Amiga Disassembly
Post by: Bit on March 14, 2016, 03:28:20 AM
Nice idea, thought the whole time how we can organize such a workspace, but this look good.

Just a few warnings about shared routines of normal and extended version:
1. Only a very few routines have a real 'assembler'-layout, so, movem in the beginning and in the end, a fine rts and the argument handling by the stack. Think you know that. So you also know that much things got 'jumped' by bra instead of being called by bsr (now and then...), some routines run into others, 'borrowing' that ones rts. So after all, in some cases it is hard to say where the start of a routine is, and a lot of routines jump to the nextby rts that belongs to another one, kind of abusing it. That also may happen together with optimizing compilers.
2. Even more evil is, that before the main eventhandler, a routineadress (clean cursorblock) gets pushed on the stack, so, whatever the jumptable of the eventhandler says, that one is executed next. Some may call it strategy... (others not!)
3. Data-layouts of the Npcs of both versions are different, so, the code may be basically the same, but there is the one or other extension (even bugfixes!), and especially the indices differ then!
4. Did attach huge files with the data-tables the other day, position of same or similar table often differs! (Not only the relative offset)

So - prepare for ugly surprises! But after all, it can be handled.

Edit: Will not be available this week - have to visit the hospital for two or three days, nothing bad, but may hurt some days... :/
Title: Re: Bloodwych Amiga Disassembly
Post by: Hungry Horace on March 14, 2016, 02:09:31 PM
Quote from: Bit on March 08, 2016, 05:28:45 PM
Don't know if you already found it - took me ages, but the function that generates a random number is at 5218 in the normal version.
5214 calls that to produce a value between 0 and 100 (in D0), 5208 calls it to generate a random byte (in D0) with an offset added that can be set in data-byte 5207. I think this one is important.

I cant work out what these number refer to.... i think this is adrCd0055BC  (5218?)

Code: [Select]
adrCd0055BC SWAP D1
MOVEQ #0,D0
MOVE.B (adrB_0055DE).L,D0
MOVE.W D0,D1
LSR.B #3,D1
EOR.B D0,D1
LSR.B #1,D1
ROXR.B #1,D0
MOVE.B D0,(adrB_0055DE).L
SWAP D1
MULU.W D1,D0
SWAP D0

is this right?


bit - dont worry if you cannot answer! Hope everything goes ok for you and you recover well!
Title: Re: Bloodwych Amiga Disassembly
Post by: Bit on March 15, 2016, 02:06:19 AM
Still there this night. Starts at Wednesday - so tomorrow I have to sleep a little bit sooner.

See my Amiga-emu-code - pretty understandable, hm?

Code: [Select]
void func_05208(void)
{
  move_q(1, DREG1);
  CALL func_05218();
  swap_w(DREG0);
  add_b(data_05207, DREG0);
}


void func_05214(void)
{
  move_w(hex(0x6400), DREG1);
  OPEN_END(func_05218)
}

void func_05218(void)
{
  swap_w(DREG1);
  move_q(hex(0x0), DREG0);
  move_b(data_0523A, DREG0);
  move_w(DREG0, DREG1);
  lsr_b(hex(0x3), DREG1);
  eor_b(DREG0, DREG1);
  lsr_b(1, DREG1);
  roxr_b(1, DREG0);
  move_b(DREG0, data_0523A);
  swap_w(DREG1);
  mulu_w(DREG1, DREG0);
  swap_w(DREG0);
}

One note about that merchant-bug in the things that I sent to you.
That's a very ugly assembler thing, which is hard to handle in C++.

cmp.w #8, D6

The carry-flag is set if D6 is less than 8. But if D6 comes with 0xffff (-1) it is not set. It treats D6 as unsigned - whatever length is has.
Now, I made version 7 because of this problem, setting the 8bit-variables to unsigned, but wasn't aware that this is the same for longer values. When I replaced my emu-command

if (ccmp_w(8, D7))
by
if (D7.w0 < 8)

...it did show up.
And it did all the other rendering fine until the merchant appears.
I'm not amused now. When I set all signed by default, wonder what then will happen:

do
{
  something
} while (--D6 >= 0);
This one never ends, because it's never less than 0.  >:(
Title: Re: Bloodwych Amiga Disassembly
Post by: bruceuncle on March 15, 2016, 03:09:39 AM
One big difference between the original and the extended is the use of Short Absolute addressing.  The original uses it all over the shop!  The authors seem to have realised this was a very baaad idea and it disappeared in the extended binary.
Causes a lot of problems that I've been ironing out.  The source assembles but the binary doesn't match on size - the assembler uses Long Absolute unless ".w" forces it otherwise!  Finding them has been a major pain.  Glad to see that the work on offsets meant that the target addresses were still valid, just different as the extra words of code displaced everything.
There's also a "$000A(pc)" reference which chokes the assembler (not allowed as ref to an absolute address that's not in the code's area).  Easily replaced with a "dc.l".
Nearly there but will need a bit more tidy up tonight.
Title: Re: Bloodwych Amiga Disassembly
Post by: Bit on March 15, 2016, 11:11:43 AM
Here's an original bug in the normal version:

Code: [Select]
lbC001C2E:
        move.w #$FFFF,lbW001F66.l
001C36 movem.w d0/d1,-(sp)
001C3A moveq #-$01,d5
001C3C bsr.l lbC009500
001C40 bcc.s lbC001C9A
...
lbC001C9A:
rts
 
In case of that 'early' return, the stack isn't corrected!
The bsr-routine works clean without caring for that.
In the normal flow of the routine the stack gets corrected, just not the quick return. That one is corrected in the extended levels version!

...and IMHO - that line should be tst.w $0000(sp)

006828   tst.w   $0002(sp)
Title: Re: Bloodwych Amiga Disassembly
Post by: bruceuncle on March 16, 2016, 12:00:38 PM
Attached are the final Bloodwych files from the disassembly.  I renamed the file sets to give a fresh versioning start to them:
BW_001BW binary file as assembled
BW_001.asmBW source file (edited for Devpac)
BW_001.rsBW Resource file
BW_001_labels.csvBW Labels in CSV format
BW_EXT_001BW_EXT binary file as assembled
BW_EXT_001.asmBW_EXT source file (edited for Devpac)
BW_EXT_001.rsBW_EXT Resource file
BW_EXT_001_labels.csvBW_EXT Labels in CSV format
BW_Output_Labels.rsmacro     Resource macro to output labels
BW_Output_Labels.sResource macro source

The macro loads into Macros 1, #1.  To use it, load whichever *.rs file you want to extract from, then just run the macro.  It will extract all labels that do not begin with "adr".  The output file is T:Labels.txt, just rename and copy it out.  The file format is:

     "label_name",decimal_offset,decimal_address

Each line is terminated with CrLf.  I used decimal format for the numerics so's the likes of Excel can import them without having a fit.

If I may suggest a way forward:

Have fun with it all  ;)
Title: Re: Bloodwych Amiga Disassembly
Post by: Hungry Horace on March 16, 2016, 07:53:49 PM
Aggh.. Lost my post halfway through.  :-[

Ok... so let me remember - firstly, that thanks for all of your hard work mate - very much appreciated!

I had loads of questions but have managed to remove most of them after having a look through it all :)

I guess the big one is , now that it compiles as the same size, do you think it will all work with data size changes? how confident are you ? ;)


The only real main question i have is over the re-labelling. I have no problem doing this in resource in principle, but it's not overly practical. I tend to get through a lot more by looking through it on my laptop natively as raw text, (and recently opening it up with bit's code beside it).

This helps when maintaining the list of labels on my spreadsheet, as it's much easier to get a group of related labels and compare them to similar groups in other code etc.

There is no problem with me outputing a file in the same layout as your labels.txt though, so how hard would it be to make a Resource Macro which imported new labels in that from?

Simply something like this

Code: [Select]
Open newlabels.txt
For x=1 to last line of file
  Take line X
    - get new name
    - get offset
  Jump to offset
 Relabel  (assume all referring code is changed to this reference)
Next

save .rs
i had a look at your resouce macro source but i didnt really understand it - i guess there is an editor for it somewhere?

There are VBA macros i'm using in Excel to do things like:
 - Update all new labels
 - Easy update of a set of Jumptable references into meaningful labels
 - List all BW labels not in Bext (and vice versa) to to keep consistency
    (where data blocks differ and are not interchangable, i will use the suffix 'ex')

So adding the extra one will be no hassle at all :)

Sorry BruceUncle - looks like this compiled version doesnt work - it throws up an error at $8916?

not only is there no label here, suggesting that we are jumping into a wrong address on Quickstart, but also the code that resides around here doesnt look like what i'm expecting to see. (coincidently , the sound code i've referred to in the other thread)
Title: Re: Bloodwych Amiga Disassembly
Post by: Hungry Horace on March 16, 2016, 09:13:25 PM
Ok so i fixed one part - some left-over comment that was superceeded by fixing of longword values shown as labels (in the Crysal clicking code somewhere)

I fixed this myself....

The next one is thrown up by the following routine compiling as 2 bytes longer than it was originally?

Code: [Select]
adrCd007BE8:
bsr adrCd007D6C ;61000182
lea adrEA050362.l,a1 ;43F900050362
move.l #$00050006,d5 ;2A3C00050006 ;Long Addr replaced with Symbol
move.l screen_ptr.l,a0 ;207900008D36
add.w #$0DE8,a0 ;D0FC0DE8
add.w $000A(a5),a0 ;D0ED000A
lea $70,a3 ;47F80070
bra adrCd00CCB8 ;600050AC

adrEA007C0E:
dc.b $5F ;5F
dc.b $3C ;3C
dc.b $24 ;24
dc.b $3C ;3C
dc.b $10 ;10

as a result, the adrEA007C0E data is actually at adrEA007C10: and it does downhill from there!   


edit... found the problem, but how to fix?  just dc.w ?

Code: [Select]
lea $70,a3 ;47 F8 00 70 ; CUPLRIT <<< compiles as 47 F9 00 00 00 70
I guess these errors mean we don't have re-sizable code yet :/
Title: Re: Bloodwych Amiga Disassembly
Post by: Hungry Horace on March 17, 2016, 07:13:54 AM
Actually it's possible the code is resizable, but whdload patches break it...
Title: Re: Bloodwych Amiga Disassembly
Post by: bruceuncle on March 20, 2016, 06:02:04 AM
Quote from: Hungry Horace on March 16, 2016, 07:53:49 PM
Sorry BruceUncle - looks like this compiled version doesnt work - it throws up an error at $8916?
Sorry, sorry.  All my (embarrassing) fault  :-[ .

For starters, I disassembled the wrong binary.  I had two copies lying around from 18 months ago and picked the copy-protected one.

I also didn't do a binary compare of the files as the lengths matched and the one for the extension binary was okay so I wasn't expecting problems.  In fact the binaries were two bytes out of whack.  The load files will still be the same length as they are always allocated in increments of four bytes.  This is because the size of the stuff contained in a load file is measured in longwords, not bytes or words.  So a pad of 2 null bytes at the end is used if the binary in the load file needs it to ensure longword alignment.

The first was easily solved as Resource allows a binary file to be overlaid into the currently loaded *.rs file.  The difference between the two versions of the file is in one word - an RTS in one and a BSR.s in the other.

Checking the assembly listing threw up the other problems you found - one line inadvertently commented out and two Short Absolute address references.  (Which is why I used the absolute addresses embedded in the labels.  It's easy to compare with the assembled addresses to find where something has gone wrong if the result is shorter or longer than the original.)

Fixing those up resulted in a match on the binary sizes but 71 differences!

But that's actually okay as the differences are what can happen when one assembler is used for the original source and a different one is used to assemble the disassembly source.  As Resource has to have its Strict Mnemonics option turned off to get a coherent source with this disassembly, part of the original intent is lost and the assembler is left to make its own decisions as what op-codes to use.  There are two cases:

Case #1:
Strict ASMStrict Op-Code
   CMPI   #value,<effective address>     $0Cxx
Relaxed ASMRelaxed Op-Code
   CMP    #value,<effective address>     $Bxxx
where the "x"s are filled in according to what size the #value is and what the <effective address> mode is.  Both do exactly the same thing and take exactly the same number of clock cycles.  69 of the mismatches are caused by this case.

Case #2:
For the
   EXG   Ax,Ay
instruction, one assembler may encode the registers involved in the sequence Ax fist then Ay, a different assembler may put Ay first then Ax.  As the registers involved are encoded as bits in the op-code, the result can be different for any given register pair.  The result is exactly the same - the two registers get exchanged.

So please accept my apologies.  Attached is the revised zip.  There's a 002 suffix on the affected files.  I also added the (-ing huge) assembly listing in case anyone's interested.
Title: Re: Bloodwych Amiga Disassembly
Post by: Hungry Horace on March 20, 2016, 09:06:48 AM
Mate - why the hell are you apologising?

Your work on this has been tireless and you've done a fantastic job - please don't for one minute think there is any need for apologies! You've given me an opportunity to get "inside" this game like never before.

I had actually intended to spend the remainder of today sifting through for other minor corrections that might have been needed!!

In the end, have to used the copy protected one? I think this might be the better idea for the "pure" source (the BEXT is copy protected afterall)

Whdload obviously kills the protection anyway, but I have a suspicion I will need to test it outside of that due to any code  being malformed by the whdload patches.

I'd actually planned just to have the .src file "comment out" the original protection and re-use the code that WHD puts in, that removes it :)
Title: Re: Bloodwych Amiga Disassembly
Post by: Hungry Horace on March 20, 2016, 09:19:25 AM
And of course, thanks again for the 002 :)
Title: Re: Bloodwych Amiga Disassembly
Post by: Hungry Horace on March 20, 2016, 04:49:50 PM
for the record, (thank's to the original slave author Morbidus for this) the copy protection removing routine for BW is as follows    @ $d138


Code: [Select]
_copyprot: move.l #$8488ffc4,$24.w
moveq #0,d0
rts


and for BEXT  @ $db18

Code: [Select]
_copyprot: move.l #$4f8b3912,$24.w
moveq #0,d0
rts
Title: Re: Bloodwych Amiga Disassembly
Post by: Hungry Horace on March 20, 2016, 05:14:05 PM
Ok, so i added the crack to the game without WHDLoad (i.e. direct into the source code) and then recompiled it.

Mostly as a test to see if we had re-sizabel code yet.

There are a few graphical glitches - the bottom graphic for the shield, and the way the characters are being drawn (haywire colours) , but actually nothing major imho.

Hopefully i can locate the code for these two items and see if we still have any outstanding addresses as long-words etc.

Definate progress though :)


EDIT:

First graphical glitch fixed.... one of them-there long addresses!  (this one is for the Avatar/Shield graphic


Code: [Select]
;move.l #adrL_01000A,d7 ;2E3C0001000A
move.l #$0001000A,d5 ;2A3C00010008


I found a similar one, which appears to jump to the middle of the "level object data" , so i *think* this would need fixing also, but i admit, i don't know what it does (i couldnt see any change as a result of fixing it)

Code: [Select]
;add.l #adrL_010040,d5 ;068500010040
add.l #$00010040,d5 ;068500010040;


And one more...


Code: [Select]
;move.l #adrL_04080C,adrEA00B4C0.l ;23FC0004080C0000B4C0
move.l #04080C,adrEA00B4C0.l ;23FC0004080C0000B4C0

This one is an easy spot because #0004080C are the mask colours used throughout the game :)

(probably this one should be set up as a fixed number with EQU eventually - might help spot certain bits of code!)
Title: Re: Bloodwych Amiga Disassembly
Post by: Hungry Horace on March 20, 2016, 08:46:35 PM
nailed another one... definately at least part of the cause of the graphical glitches:

Code: [Select]
adrCd00AD2E:
add.l #$000396F0,a1 ;D3FC000396F0 ;Long Addr replaced with Symbol

This is erroneously replaced as a number, and *does* refer to a label :)


I think the label should be GFX_Bodies  (396F0 - $3A4 = $3934C, which appears to be that) ... however, it's not fixing it here, so maybe i've made some other fix above incorrectly, and i should probably revert back to 002 and add  each fix in turn!

edit : (again)

fixed code:
Code: [Select]
add.l #GFX_Bodies,a1 ;D3FC000396F0
:D

I have a modification to the main menu text which therefore affects the entire game (in terms of offsets) ....   i've also taken out the copy protection, using the above mentioned new code....  the fact that all the graphics now appear correctly, and the game seems to run, is a major breakthrough i think :)
Title: Re: Bloodwych Amiga Disassembly
Post by: MadMunky on March 22, 2016, 06:21:40 AM
I don't know what any of this means but keep up the good work all, seems like your making good progress in understanding the source. :)
Title: Re: Bloodwych Amiga Disassembly
Post by: Hungry Horace on March 22, 2016, 06:28:06 PM
Quote from: MadMunky on March 22, 2016, 06:21:40 AM
I don't know what any of this means but keep up the good work all, seems like your making good progress in understanding the source. :)

In summary - fixing the above items, we can now re-compile the amiga BW disassembly.

All of this means more labels are getting put in, slowly building up a more readable source code :)

Title: Re: Bloodwych Amiga Disassembly
Post by: Hungry Horace on June 25, 2017, 09:58:21 AM
Quote from: Hungry Horace on March 20, 2016, 08:46:35 PM
nailed another one... definately at least part of the cause of the graphical glitches:

Code: [Select]
adrCd00AD2E:
add.l #$000396F0,a1 ;D3FC000396F0 ;Long Addr replaced with Symbol

This is erroneously replaced as a number, and *does* refer to a label :)


I think the label should be GFX_Bodies  (396F0 - $3A4 = $3934C, which appears to be that) ... however, it's not fixing it here, so maybe i've made some other fix above incorrectly, and i should probably revert back to 002 and add  each fix in turn!

edit : (again)

fixed code:
Code: [Select]
add.l #GFX_Bodies,a1 ;D3FC000396F0
:D

I have a modification to the main menu text which therefore affects the entire game (in terms of offsets) ....   i've also taken out the copy protection, using the above mentioned new code....  the fact that all the graphics now appear correctly, and the game seems to run, is a major breakthrough i think :)


having another look at tudying some code. Realised i lost the .rs file i had applied these fixes too (glad i posted them here!!)

Only problem is that i cant remember how to do the macro or keyboard shortcuts that let me fix it :S

EDIT: Found... thankfully just a matter of using [V]  ... found in a spereate thread that had been chopped out of this one!
Title: Re: Bloodwych Amiga Disassembly
Post by: Hungry Horace on September 23, 2018, 09:31:30 PM
Anyone remember how to get the exact BW binary out of the last uploaded source code (v.002) ?!?  I am sure it must just be a DevPac setting i need to change!
Title: Re: Bloodwych Amiga Disassembly
Post by: Hungry Horace on July 29, 2019, 08:50:40 PM
In order to keep this in an 'on topic' place, here is a link to the source on GitHub

https://github.com/HoraceAndTheSpider/Bloodwych-68k
Title: Re: Bloodwych Amiga Disassembly
Post by: Hungry Horace on August 04, 2019, 10:20:50 PM
I’ve done a lot of today trying to understand the differences in my compile and the real compile today.

Most of this seems to come down to what ReSource calls “strict pneumonics” - which solves the CMP vs. CMPI problem mentioned by BruceUncle previously. Unfortunately with the option ON these instructions are right and others different. With them OFF it is the same - some differ again.

The good news is that I have a source which I can compile which is relocatable - I was able to add to the main menu text and the game still ran normally, despite clearly pushing everything else in the game (the menu is very early on) further up memory.

I still want us to be working from a “base” asm file which when compiled in DevPac is exactly the same as one of the original binaries, and without warnings etc. What I will likely do therefore is take the working source and manually make the fixes where the differences are. There’s a lot, but maybe I can script some of it.
Title: Re: Bloodwych Amiga Disassembly
Post by: Hungry Horace on August 07, 2019, 08:32:43 PM
All done

I've just uploaded a version of the source to GitHub which is 100% recompilable to the original, and should be successfully relocatable.

Next job is to improve the labels and the INCBIN data blocks.

There's a few places where labels appear 'missing' - i'll also take a look at what they should be.
Title: Re: Bloodwych Amiga Disassembly
Post by: Hungry Horace on February 26, 2021, 07:22:26 PM
I’ve moved this project over to GitHub.

I’ve made some great progress on the Standard Bloodwych code, but it’s a shame bit and BruceUncle aren’t around to answer some questions as I have a few issues with the Extended Levels recompiled binary