Ultimate Amiga

Please login or register.

Login with username, password and session length
Advanced search  
Pages: 1 2 3 [4] 5 6   Go Down

Author Topic: Bloodwych Amiga Disassembly  (Read 48948 times)

0 Members and 1 Guest are viewing this topic.

Hungry Horace

  • Amorphous Blue-Blob Man
  • Site Admin
  • A4000T
  • ******
  • Karma: 307
  • Offline Offline
  • Gender: Male
  • Posts: 3,364
  • Don't forget... Ameboid's need love too!
    • AUW
Re: Bloodwych Amiga Disassembly
« Reply #45 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....
Logged
Quote from: KillerGorilla
because winuae is made of code and your amiga is made of stuff

bruceuncle

  • AMOS Dev
  • A500
  • *****
  • Karma: 6
  • Offline Offline
  • Gender: Male
  • Posts: 425
  • WINUAE Amiga User
Re: Bloodwych Amiga Disassembly
« Reply #46 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  ;)
Logged
Repeat after me ...  "The AMOS Pro architecture is complex but it is not complicated."

Hungry Horace

  • Amorphous Blue-Blob Man
  • Site Admin
  • A4000T
  • ******
  • Karma: 307
  • Offline Offline
  • Gender: Male
  • Posts: 3,364
  • Don't forget... Ameboid's need love too!
    • AUW
Re: Bloodwych Amiga Disassembly
« Reply #47 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?  :)

Logged
Quote from: KillerGorilla
because winuae is made of code and your amiga is made of stuff

bruceuncle

  • AMOS Dev
  • A500
  • *****
  • Karma: 6
  • Offline Offline
  • Gender: Male
  • Posts: 425
  • WINUAE Amiga User
Re: Bloodwych Amiga Disassembly
« Reply #48 on: March 07, 2016, 10:26:50 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.
Logged
Repeat after me ...  "The AMOS Pro architecture is complex but it is not complicated."

bruceuncle

  • AMOS Dev
  • A500
  • *****
  • Karma: 6
  • Offline Offline
  • Gender: Male
  • Posts: 425
  • WINUAE Amiga User
Re: Bloodwych Amiga Disassembly
« Reply #49 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  ::)
Logged
Repeat after me ...  "The AMOS Pro architecture is complex but it is not complicated."

Bit

  • A600
  • *
  • Karma: 5
  • Offline Offline
  • Posts: 69
Re: Bloodwych Amiga Disassembly
« Reply #50 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.
Logged

Hungry Horace

  • Amorphous Blue-Blob Man
  • Site Admin
  • A4000T
  • ******
  • Karma: 307
  • Offline Offline
  • Gender: Male
  • Posts: 3,364
  • Don't forget... Ameboid's need love too!
    • AUW
Re: Bloodwych Amiga Disassembly
« Reply #51 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)
« Last Edit: March 08, 2016, 08:56:52 PM by Hungry Horace »
Logged
Quote from: KillerGorilla
because winuae is made of code and your amiga is made of stuff

Hungry Horace

  • Amorphous Blue-Blob Man
  • Site Admin
  • A4000T
  • ******
  • Karma: 307
  • Offline Offline
  • Gender: Male
  • Posts: 3,364
  • Don't forget... Ameboid's need love too!
    • AUW
Re: Bloodwych Amiga Disassembly
« Reply #52 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
Logged
Quote from: KillerGorilla
because winuae is made of code and your amiga is made of stuff

Hungry Horace

  • Amorphous Blue-Blob Man
  • Site Admin
  • A4000T
  • ******
  • Karma: 307
  • Offline Offline
  • Gender: Male
  • Posts: 3,364
  • Don't forget... Ameboid's need love too!
    • AUW
Re: Bloodwych Amiga Disassembly
« Reply #53 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 :)
Logged
Quote from: KillerGorilla
because winuae is made of code and your amiga is made of stuff

Bit

  • A600
  • *
  • Karma: 5
  • Offline Offline
  • Posts: 69
Re: Bloodwych Amiga Disassembly
« Reply #54 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.
Logged

Hungry Horace

  • Amorphous Blue-Blob Man
  • Site Admin
  • A4000T
  • ******
  • Karma: 307
  • Offline Offline
  • Gender: Male
  • Posts: 3,364
  • Don't forget... Ameboid's need love too!
    • AUW
Re: Bloodwych Amiga Disassembly
« Reply #55 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?
« Last Edit: March 09, 2016, 09:01:28 PM by Hungry Horace »
Logged
Quote from: KillerGorilla
because winuae is made of code and your amiga is made of stuff

Bit

  • A600
  • *
  • Karma: 5
  • Offline Offline
  • Posts: 69
Re: Bloodwych Amiga Disassembly
« Reply #56 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.
Logged

Hungry Horace

  • Amorphous Blue-Blob Man
  • Site Admin
  • A4000T
  • ******
  • Karma: 307
  • Offline Offline
  • Gender: Male
  • Posts: 3,364
  • Don't forget... Ameboid's need love too!
    • AUW
Re: Bloodwych Amiga Disassembly
« Reply #57 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
« Last Edit: March 08, 2016, 11:05:29 PM by Hungry Horace »
Logged
Quote from: KillerGorilla
because winuae is made of code and your amiga is made of stuff

Bit

  • A600
  • *
  • Karma: 5
  • Offline Offline
  • Posts: 69
Re: Bloodwych Amiga Disassembly
« Reply #58 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
« Last Edit: March 08, 2016, 11:11:41 PM by Bit »
Logged

bruceuncle

  • AMOS Dev
  • A500
  • *****
  • Karma: 6
  • Offline Offline
  • Gender: Male
  • Posts: 425
  • WINUAE Amiga User
Re: Bloodwych Amiga Disassembly
« Reply #59 on: March 13, 2016, 10:57:29 AM »

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:

  • Short Absolute effective addresses.  These look like, for example (file offset $00023C):

                  move.b  d0,$05C9

    Resource does not automatically resolve these.  They have to be manually resolved to a label at the target address:

                  move.b  d0,adrEA0005C9.w

    That ".w" at the end is critical to tell the assembler that this is a SHORT absolute pointing to the label.

  • Word-size code Jump Tables.  You'll have already seen these in the BW_EXT disassembly.  For example (file offset $0011F2):

    adrEA0015AE:  dc.w    $0000
                  dc.w    $FF6C
                  dc.w    $00F0
                  dc.w    $FF4E
                  dc.w    $FFFA


    which becomes:

    adrJT0015AE:  dc.w    adrJB00166A-adrJB00166A
                  dc.w    adrJA0015D6-adrJB00166A
                  dc.w    adrJA00175A-adrJB00166A
                  dc.w    adrJA0015B8-adrJB00166A
                  dc.w    adrJA001664-adrJB00166A


    after the offsets have been resolved to the 'distance' between the base address and the destination addresses.  Again, these have to be resolved manually (with the help of a couple of macros to do the donkey work).

  • Word- and Byte-sized data offset tables.  These are similar to the jump tables above but act as pointers to blocks of data.  The binary contains  many of these,  For example (file offset $005D64):

    OutcomeMsgOffsets:
                  dc.b    $00
                  dc.b    $07
                  dc.b    $0E
                  dc.b    $15
                  dc.b    $21
                  dc.b    $29
                  dc.b    'MISSES'
                  dc.b    $FF
                  dc.b    'SHOOTS'
                  dc.b    $FF
                  dc.b    'CHANTS'
                  dc.b    $FF
                  dc.b    'CASTS SPELL'
                  dc.b    $FF
                  dc.b    'DEFENDS'
                  dc.b    $FF
                  dc.b    'HITS FOR'
                  dc.b    $FF

    becomes:

    OutcomeMsgOffsets:
                  dc.b    OutcomeMsgs_0-OutcomeMsgs_0
                  dc.b    OutcomeMsgs_1-OutcomeMsgs_0
                  dc.b    OutcomeMsgs_2-OutcomeMsgs_0
                  dc.b    OutcomeMsgs_3-OutcomeMsgs_0
                  dc.b    OutcomeMsgs_4-OutcomeMsgs_0
                  dc.b    OutcomeMsgs_5-OutcomeMsgs_0
    OutcomeMsgs_0:
                  dc.b    'MISSES'
                  dc.b    $FF
    OutcomeMsgs_1:
                  dc.b    'SHOOTS'
                  dc.b    $FF
    OutcomeMsgs_2:
                  dc.b    'CHANTS'
                  dc.b    $FF
    OutcomeMsgs_3:
                  dc.b    'CASTS SPELL'
                  dc.b    $FF
    OutcomeMsgs_4:
                  dc.b    'DEFENDS'
                  dc.b    $FF
    OutcomeMsgs_5:
                  dc.b    'HITS FOR'
                  dc.b    $FF

    after the offsets have been fully resolved.

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  :) ).
Logged
Repeat after me ...  "The AMOS Pro architecture is complex but it is not complicated."
Pages: 1 2 3 [4] 5 6   Go Up
 

TinyPortal 2.2.2 © 2005-2022