Print

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

[Hungry Horace]

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

[Hungry Horace]

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

[Bit]

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

[Hungry Horace]

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!

[Bit]

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 <

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

[bruceuncle]

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.

[Bit]

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)

[bruceuncle]

Attached are the final Bloodwych files from the disassembly.  I renamed the file sets to give a fresh versioning start to them:

BW_001	BW binary file as assembled
BW_001.asm	BW source file (edited for Devpac)
BW_001.rs	BW Resource file
BW_001_labels.csv	BW Labels in CSV format
BW_EXT_001	BW_EXT binary file as assembled
BW_EXT_001.asm	BW_EXT source file (edited for Devpac)
BW_EXT_001.rs	BW_EXT Resource file
BW_EXT_001_labels.csv	BW_EXT Labels in CSV format
BW_Output_Labels.rsmacro	Resource macro to output labels
BW_Output_Labels.s	Resource 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:

• Add any new labels and symbols to the *.rs files but don't use them for anything else.  You can use the supplied Resource macro to output labels from it whenever you need to.
• Check if there are any offset tables unresolved.  Any table of dc.w definitions that starts with "dc.w $0000" is a likely candidate.  You guys know more about the data than me so use your own judgement.  If the offset values are fixed, you can leave it alone.  If the data they point to is dynamic (i.e. you might want to change it) then you must convert it to symbols. Give me a yell if you need to do that and I can walk you through the process.
• Output new *.asm files as needed.  For Devpac, the only editing needed is to change the SECTION line at the start.  Also, remove any Symbol equates at the start that represent a label with a ".w" suffix (Resource keeps popping them in for some reason).  If an assembly spews heaps of errors, make sure you've got Strict Mnemonics (in Options 1) turned OFF when you export the *.asm file.
• Spin off an *.rs file set to experiment with resolving those A4 offsets.  Find where A4 is pointed to.  That's the base address.  Start defining whatever labels you know about from that address upwards.  The A4 offsets can then get converted to symbols - see page 7 of the PDF of the help files.

Have fun with it all 

[Hungry Horace]

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)

[Hungry Horace]

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 :/

[Hungry Horace]

Actually it's possible the code is resizable, but whdload patches break it...

[bruceuncle]

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 ASM	Strict Op-Code
CMPI   #value,<effective address>	$0Cxx
Relaxed ASM	Relaxed 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.

[Hungry Horace]

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

[Hungry Horace]

And of course, thanks again for the 002

[Hungry Horace]

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