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 10721 times)

Bit

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

Hungry Horace

  • Amorphous Blue-Blob Man
  • Site Admin
  • A4000T
  • ******
  • Karma: 305
  • Offline Offline
  • Posts: 3,283
  • Don't forget... Ameboid's need love too!
    • Amiga Online
Re: Bloodwych Amiga Disassembly
« Reply #31 on: January 17, 2016, 10:02:06 AM »



@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
Logged
Quote from: KillerGorilla
because winuae is made of code and your amiga is made of stuff

Hungry Horace's Artwork Available
Buy my work

http://twitter.com/horaceandspider

bruceuncle

  • AMOS Dev
  • A500
  • *****
  • Karma: 6
  • Offline Offline
  • Posts: 425
  • WINUAE Amiga User
Re: Bloodwych Amiga Disassembly
« Reply #32 on: February 10, 2016, 11:45:09 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.
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 #33 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.
« Last Edit: February 11, 2016, 03:27:51 AM by Bit »
Logged

bruceuncle

  • AMOS Dev
  • A500
  • *****
  • Karma: 6
  • Offline Offline
  • Posts: 425
  • WINUAE Amiga User
Re: Bloodwych Amiga Disassembly
« Reply #34 on: February 11, 2016, 11:48:42 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.  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:
  • absolute address to Dn using MOVE or LEA or whatever
  • MOVE.w Dn to Copper List entry (low word of address)
  • SWAP Dn
  • MOVE.w Dn to Copper List entry (high word of address)
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 #35 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...
Logged

Hungry Horace

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

Hungry Horace's Artwork Available
Buy my work

http://twitter.com/horaceandspider

Hungry Horace

  • Amorphous Blue-Blob Man
  • Site Admin
  • A4000T
  • ******
  • Karma: 305
  • Offline Offline
  • Posts: 3,283
  • Don't forget... Ameboid's need love too!
    • Amiga Online
Re: Bloodwych Amiga Disassembly
« Reply #37 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 :)
« Last Edit: February 27, 2016, 11:05:45 AM by Hungry Horace »
Logged
Quote from: KillerGorilla
because winuae is made of code and your amiga is made of stuff

Hungry Horace's Artwork Available
Buy my work

http://twitter.com/horaceandspider

bruceuncle

  • AMOS Dev
  • A500
  • *****
  • Karma: 6
  • Offline Offline
  • Posts: 425
  • WINUAE Amiga User
Re: Bloodwych Amiga Disassembly
« Reply #38 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!  >:(

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

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

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

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

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.
« Last Edit: February 29, 2016, 10:28:21 PM by bruceuncle »
Logged
Repeat after me ...  "The AMOS Pro architecture is complex but it is not complicated."

bruceuncle

  • AMOS Dev
  • A500
  • *****
  • Karma: 6
  • Offline Offline
  • Posts: 425
  • WINUAE Amiga User
Re: Bloodwych Amiga Disassembly
« Reply #39 on: March 02, 2016, 07:12:11 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?
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: 305
  • Offline Offline
  • Posts: 3,283
  • Don't forget... Ameboid's need love too!
    • Amiga Online
Re: Bloodwych Amiga Disassembly
« Reply #40 on: March 02, 2016, 05:24:24 PM »

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!
Logged
Quote from: KillerGorilla
because winuae is made of code and your amiga is made of stuff

Hungry Horace's Artwork Available
Buy my work

http://twitter.com/horaceandspider

Bit

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

Hungry Horace

  • Amorphous Blue-Blob Man
  • Site Admin
  • A4000T
  • ******
  • Karma: 305
  • Offline Offline
  • Posts: 3,283
  • Don't forget... Ameboid's need love too!
    • Amiga Online
Re: Bloodwych Amiga Disassembly
« Reply #42 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!
« Last Edit: March 04, 2016, 09:11:21 AM by Hungry Horace »
Logged
Quote from: KillerGorilla
because winuae is made of code and your amiga is made of stuff

Hungry Horace's Artwork Available
Buy my work

http://twitter.com/horaceandspider

bruceuncle

  • AMOS Dev
  • A500
  • *****
  • Karma: 6
  • Offline Offline
  • Posts: 425
  • WINUAE Amiga User
Re: Bloodwych Amiga Disassembly
« Reply #43 on: March 04, 2016, 11:27:47 AM »

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

« Last Edit: March 04, 2016, 12:06:39 PM by bruceuncle »
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 #44 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!
« Last Edit: March 04, 2016, 12:28:44 PM by Bit »
Logged
Pages: 1 2 [3] 4 5 6   Go Up