Print

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

[bruceuncle]

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

[Hungry Horace]

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.

[Hungry Horace]

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

[Hungry Horace]

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.

[Hungry Horace]

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!

[bruceuncle]

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!

[Bit]

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

[Hungry Horace]

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

[Hungry Horace]

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:

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.

[Bit]

That explains a lot... 

[Hungry Horace]

Even more amusingly, there is code within Legend that is unchanged from its use in Bloodwych....

[Hungry Horace]

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.

[Hungry Horace]

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?

[Bit]

player data blocks surely right,
top line string - handling this one will be next routines in my list,
null length string - let's see

[bruceuncle]

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