Author
|
Topic: tile not loaded properly (Read 614 times)
|
Con
Guest
|
 |
« on: May 10, 2007, 07:11:22 am » |
|
Hi, you guys helped me out so well yet, and I encountered a new problem while I try to fix bszelda and need your help once again. We have only a bad dump of BS zelda Map 1 and there is a monster in Dungeon 8 which is not properly loaded:  . Since we recently got Map 2 we know now which monster should be there: (Map 2 is a second quest to BS Zelda Map 1, just like there was also a 2nd quest in original zelda, NES)  The location of the correct monster in Map 1 is $CE:C219-C246, but the game unfortunately loads the buggy monster which is loacated at $CE:BBC1-BBE0. When I debugged the game I got this address which refers to the buggy monster tile: $C5/E070 B7 17 LDA [$17],y[$CE:BBC1] I assume that if it was ...,y[$CE:C21F] the monster should be loaded correctly (got this address through comparison with map 2). This may also be important: Before we had Map 2 as reference, this buggy monster was (wrong) fixed to become a dragon. The patcher (Dreamer_Nom) changed at $C9:6CAE the value B7 to AF. With this change, the rom loads ... y[$CE:BBE1] instead of ...y[$CE:BBC1]. I know that this is complicated and maybe confusing, but I hope that you understand this and can help me. I am a beginner in ASM hacking and just don't know how these addresses are linked together. |
|
|
|
« Last Edit: May 10, 2007, 11:43:02 am by Con »
|
|
|
|
Tauwasser
Guest
|
|
« Reply #1 on: May 10, 2007, 09:01:40 am » |
|
Well you need to figure out where the y comes from. Try looking what asm is at C9:6CAE and follow it a bit.
cYa,
Tauwasser
|
|
|
|
|
Con
Guest
|
|
« Reply #2 on: May 10, 2007, 11:47:15 am » |
|
Sorry for the broken images, bszelda.zeldalegends.net is currently down, so I hosted the images elsewhere. That's the funny thing: if I try to trace C9:6CAE there will come only another address with that y  $C5/D9E4 B7 00 LDA [$00],y[$C9:6CAE] If I disassemble C9:6cae it says this: $C9/6CAE B7 FF LDA [$FF],y[$55:5555] (but this can't be correct, because the B7 (buggy ghoma) was in the patch by DN altered to AF to display the dragon. And Map 2 has also this B7 value there, so I assume this is correct. Danke dir  |
|
|
|
« Last Edit: May 10, 2007, 12:02:05 pm by Con »
|
|
|
|
Tauwasser
Guest
|
|
« Reply #3 on: May 10, 2007, 01:12:15 pm » |
|
Well if you already did figure out that C9:6CAE is read by the code at C5:D9E4, then you most likely are editing the enemy number (or another index number) that is used for a table lookup. No you just need to check the table or whatever it is reading to know how to alter data at C9:6CAE to generate the desired monster.
cYa,
Tauwasser
|
|
|
|
|
Con
Guest
|
|
« Reply #4 on: May 10, 2007, 01:34:45 pm » |
|
Yep, it is a table with a lots of FF and so on. I already altered the values there to look if I get it to work, but didn't succeed. I got everything inside the room but not my desired monster. I also don't understand the logic in this table so that I can estimate the hex which needs to stand there to get finally to the address y[$CE:C21F]  All in all I also don't believe that it is the table: Map 1 and Map 2 are very alike and the table data doesn't differ in this region... |
|
|
|
|
Tauwasser
Guest
|
|
« Reply #5 on: May 10, 2007, 02:49:35 pm » |
|
Well, you need to assess the code that reads the table (all of it and what they make of the read values). Then, you need to compute what values exactly there need to be in the table to get your monster. Then you can change the index to the desired one.
cYa,
Tauwasser
|
|
|
|
|
Con
Guest
|
|
« Reply #6 on: May 10, 2007, 05:59:08 pm » |
|
Yes, this must be the reason. While debugging I noticed that less addresses and also less table data is loaded in map 1 in compare with map 2. When I checked other rooms both maps load more or less the same data. So the bug must be inside the values that determine the table load.
Unfortunately, I don't know which opcodes are responsibility for this matter... do you have a clue? I also did not find an obvious difference which tells me what the reason could be while comparing the trace logs of both maps
|
|
|
|
|
Tauwasser
Guest
|
|
« Reply #7 on: May 10, 2007, 07:15:10 pm » |
|
Umm, while I guessed quite good till now, it would require more data from you to make an anylisis... And I'm not up to d/l'ing some rom that I would need to search for a whole while...
Post some necessary data or something and narrow your values down.
cYa,
Tauwasser
|
|
|
|
|
Con
Guest
|
|
« Reply #8 on: May 11, 2007, 05:15:49 am » |
|
Oh, that's very nice from you that you offer your help :angel: If you want you can write me: con.s@gmx.de - the games are on www.bszelda.zeldalegends.net (I am co-webmaster of this site). I can also give you savestates and so on, so that you don't have to play through the games... |
|
|
|
|
Con
Guest
|
|
« Reply #9 on: May 16, 2007, 12:06:05 pm » |
|
Oh, maybe I misunderstood your offer. Sorry. I managed to get this monster in...  The problem was at these pointers $C0:cb0b 00 E4 CD $C0:cb0e 00 E4 CD $C0:cb11 00 E4 CD By comparing with Map 2 I changed E4 to F4, F8 and FC, so that this monster appears. Full topic: http://z9.invisionfree.com/bszelda/index.php?showtopic=535&st=0Unfortunately, there is no palette change to blue yet, and it hasn't the original behaviour. It uses to throw many fireballs and the heads are regenerating after a little while if you can't slash the monster in time. Also, it might be weaker. I have no clue how to trace this data. If I could than I can simply see which addresses are used in Map 2 and transcribe it into Map 1. I assume that there is another (4th) pointer loaded from the $C0 bank... Has anybody an idea how to trace? |
|
|
|
|
Tauwasser
Guest
|
|
« Reply #10 on: May 16, 2007, 04:15:25 pm » |
|
Umm, sorry, I didn't have time yet to look at that specific thing. Got lots to do in the last few weeks. I'll nevertheless take a look, because obviously instead of solving the issue with the index you just killed the other monster and made it look like the original  cYa, Tauwasser |
|
|
|
|
Con
Guest
|
|
« Reply #11 on: May 16, 2007, 06:35:59 pm » |
|
That's very nice from you. Thanks a lot I'll also keep on looking but my asm knowledge is unfortunately not very skilled, also I am on vacation for a few days now... I don't think that I "killed" the other monster but restored the original monster. I don't know if you know about BS-X games, but this game was broadcasted in 4 weeks. This monster is part of week 4 but we unfortunately only have a dump of week 3. It is assumable that this monster was first fixed in week 4 then. Also if I write the "E4" to the respective addresses in map 2, I'll get the buggy monster inside this rom:  This buggy monster is in my opinion more a substitute if there is a failure in the code. Here are 2 debug logs(map 1 and map 2) in which I assume the mistake must be somewhere: http://www.bszelda.zeldalegends.net/stuff/Con/debug.zip The first difference is: Map 1: $C5/D328 F0 0C BEQ $0C [$D336] $C5/D32A AD 55 00 LDA $0055 [$00:0055] Map 2: $C5/D09F F0 0C BEQ $0C [$D0AD] $C5/D0AD AF 2A 20 7E LDA $7E202A[$7E:202A] After this several different addresses are loaded. I do not know why map 1 doesn't jump to c5:d336 where the (assumable correct) af 2a 20 7e is located. But I also can be completely wrong and this sequence was only spaced out in the log... Talk to you in a few days again |
|
|
|
« Last Edit: May 16, 2007, 08:05:21 pm by Con »
|
|
|
|
|
