General ASM Help topic

Conn wrote:So the code will look like:
start here: $08/8A5D 9D E4 03    STA $03E4,x[$08:03E8]  
then hack:
cmp #$08
if yes:
write a code to get again the x value so that  in this case the new ice layer is stored to ,x[$7E:2AAA]
reenable the dma transfer... and that's it

Amazing find, however I am still confused how to find out which tile to replace. We know that $7E2000,x is the start of the tile searching, but how can we relate that to the position of the ice rod shot? Also, what if there are two ice rod shots flying around at the same time?

There's also the fact that this discovery alters the overworld. Would it also apply to the dungeon mode too?

Finally, if we weren't hijacking the ice rod code, how would we do it for chests? (I can make it room specific very easily, too, as that kind of data is logged in the ram map, thankfully.)
---
I think I may have discovered the updating code:

Math's Disassembly wrote:JMP $D09C   ; ($6509C) Sets the tile map update flag and exits.

Wii's Disassembly wrote:CODE_0CC52C:        A9 03         LDA #$03                  ;\ Update tilemap
CODE_0CC52E:        85 14         STA $14                   ;/
CODE_0CC530:        E6 11         INC $11                   ; Next sub-game mode
CODE_0CC532:        60            RTS                       ;

EDIT2: I have just figured out that there are $00-$7F per row. ($7E would be the last tile to show up on screen, because every 2 values you increment, it moves right one tile. Kinda similar to how the text works in this game.)
If you wanted to move down/up one row, add or decrease the tile spot value by $80.

To find out what tile type something is, either use Hyrule Magic's tile map editor (don't forget to convert decimal to hex!) or memory watch the ice rod passing over the tile type at $7E:03E8.

(And yes, this applies to both big and little squares on the overworld map.)

Also, what if there are two ice rod shots flying around at the same time?

The second shot will be stored to $03E7, so this address must be watched in your code as well.

Amazing find, however I am still confused how to find out which tile to replace. We know that $7E2000,x is the start of the tile searching, but how can we relate that to the position of the ice rod shot?

But this is easy, look at above code:
$00/884A BF 00 20 7E LDA $7E2000,x[$7E:2AAA] A:0AAA X:0AAA
X has the value 0AAA and is the specific tile to replace!
I did this in my screenshot and the corrrect tile was replaced by my cheat where the ice was shot over.

All you have to do is regaining this x-value by repeating the code that leads to it: Here's the asm how the code gets the tile position (in this case it is 0AAA):

Code:


$00/883E A5 02       LDA $02    [$00:0002]   A:0A80 X:0004
$00/8840 38          SEC                     A:00EB X:0004
$00/8841 ED 0C 07    SBC $070C  [$08:070C]   A:00EB X:0004
$00/8844 2D 0E 07    AND $070E  [$08:070E]   A:002B X:0004
$00/8847 05 06       ORA $06    [$00:0006]   A:002A X:0004
$00/8849 AA          TAX                     A:0AAA X:0004
$00/884A BF 00 20 7E LDA $7E2000,x[$7E:2AAA] A:0AAA X:0AAA

So check if $03E8 gets a value 08, then (1) hijack the code, (2) regain the x-value by simply repeating above asm, (3) load the ice tile map data into the Accumulator and store it to $7E2000,x and (4) make a dma transfer to display it.

Here's basic information about graphics:
each tile displayed has a gfx means the tile itself, a palette and a map. The map tells the rom where on the screen the tile is displayed and is 2 bytes, in our case, deep water is CD 02.
CD is the tile gfx for deep water, for shallow water it is DA and so forth. Each bg tile is indexed this way. The 02 has the palette and attributes like mirror, flip. In 02 the 0 tells us that it is neither mirrored nor flipped, the 2 tells us that it uses palette 2.

We want to hack into the map which starts at 7E:2000.. First you need to insert an ice tile that can be addressed by the map just as deep water is indexed with CD and shallow water with DA. For me this would be the most difficult part since I do not know which tile can be replaced or where this tile can be added. In any case, it must be transferred via dma to vram to the other tiles on the overworld. Maybe SePH or Euclid can help since they added this tile to the overworld in PW. So imagine you can index this tile to E9.
We then simply need to check the value $03E8 (and $03E7); when it is a 08 we look where the 7E:2000, x was, in my example it was at 7E:2AAA. We see that it is a CD 02 and then we simply store a E9 02 to this ram address, make a dma transfer and your ice tile will be displayed!

I was also thinking about that you actually should also transform the shallow water into ice layers (would be not logical if only deep water freezes).

Editing the block types in overworlds is relatively much simple actually. You only have to edit the block types in the 16x16 block editor and save, that's it!





On dungeons it's a little more complicated because you have to change it in hex (was discovered a while back by Spane):

Spane wrote:Hi
I've figured out a way to change the dungeon block typs via hex. It's really easy.
As an example. Go in a dungeon and in the dungeon piece editor. Look at the first line of tiles and note the block types.
01 01 01 00 02 01 02 00 01 01 02 02 02 02 02 02
Now open you rom in a hex editor. I prefer Hex-Editor MX.
And now search for the 16 variables. The editor find the variables by 71859.
And now chance as an example the first 01 to 00.
Save the rom and go again to the dungeon piece editor. You have changed successfully the block type.
For the rest of the block type, it will work in the same way.
I hope I've helped you. More freedom in editing dungeon we come.

Greetings Spane

Also I've added a block types database to the documents for those who want to change theirs!

http://zeldix.forumotion.com/t135-block-types-database

@ SePH: Great thank you, this will help a lot

@Potentialing: if you can send me a rom with the edited ice layers (con.s@gmx.de), I can create your desired hack in very short time. I have enough knowledge about the code now but I do not dare to change tiles with hyrule magic since I do not know whether they could be used at another place.

When I was editing overworlds in GoT, I also needed some new tiles. So I've mapped the intire Walls gfx and couldn't find blocks 94, 95, 110, 111. These 4 small gfx tiles in the 16x16 gfx editor were not found on the entire overworld of Alttp and neither GoT. So I used these 4 to make transit from mud into grass, eaqual to the one at the end of the cliff. But the cliff ones are type= jump down, while the normal ones are type= walk on it normally. Default type is 1, so it needs to be changed into 14 for slippery as suggested by SePH, I had to change this from type 1 (solid, but unused), into type 0 (walk on it normally).
 
So you can take all four to make an ice block similar to PW ice block. This gfx tile is optimal, since it repeats for all gfx values. Also if you use palette 7, it will display a water-ice blue-light blue colours to use.
 
For 32x32 you can use tile 3529, for the biggest tile, you can use 7922 (this tile can easily be replaced by 169 for instance, since this is just normal grass).

That's also very valuable information
I think only small 16x16 tiles are needed. But there could be more than one necessary, e.g. for the slantwise half water/half land tiles. dunno how this can be implemented yet...

Edit:
I tried to examine the vram transfer... umm, it is unfortunately more difficult as I expected at first place: the cd 02 is actually compressed and will decode in 4 8x8 tiles as far as I can tell to 7E/1000 something. from here it will go as map into vram. But I think it isn't unsolveable nevertheless, but it makes it much more complicated.

Edit 2:
I examined a bit more the tile replacement in the background. It happens quite often actually (moving waves and so). The tile gfx are replaced (the map remains untouched) which wondered me in the first moment but then... of course, you cannot load all the various tiles all together into vram.
When the ice touches the water, I know which 16x16 tile is affected. This will be converted into 8x8 tiles to the map. I am not sure yet if we get from this to the gfx tle replacement. I will examine more if you manage to insert some ice tiles into the overworld if you like.

Conn wrote:That's also very valuable information
I think only small 16x16 tiles are needed. But there could be more than one necessary, e.g. for the slantwise half water/half land tiles. dunno how this can be implemented yet...

I think we could use a table+loop to check if the tile in question isn't on the list of tiles we want.

Code:

LDX #$00   ; Counter
Loop:   ; Loop label
LDA $"tile_to_replace"
CMP TilesWeWant,x
BEQ ADesiredTile
INX  ; Increase counter
CPX #$YY ; Compare to number of times to loop
BCC Loop ; Loop if less than that number
; End of loop etc.
RTS
ADesiredTile:
; If you found a tile on the "approval list", run code here.
RTS
TilesWeWant:
db $tile1,$tile2,etc


Conn wrote:I will examine more if you manage to insert some ice tiles into the overworld if you like.

That would be very nice if you could look into it more! My head's completely fried from mindlessly trying to get this to work for 3 days nonstop.

I put the ice tiles just outside of Link's house. I took 16x16 block $B7 and gave 8x8 tile $10D a behavior of $0E. Hope this helps!

phew... I tried the complete day and must say, this is toughy. It may go beyond my skills.
I made some progress as you see here:



code starts at 0x77ba0 (don't ask me for asm now)

I ran in several bugs though:
- it works so far only in that screen shown, in other screens it will shift to left or right (guess other coordinates will have to be calculated)
- you cannot walk on the tiles.
- it slow-downs the rom in an annoying way (had to make a check for lda $4210 to get 00) for vram transfer this might be fixed with a real dma transfer (I used dimple lda $2118 sta $2116 method)... FIXED!
- when you shoot an arrow or fire rod, the tiles can appear - this is no problem; can be solved by a simple check - FIXED

I am not sure if I am able to get this to work, and I will not look at it the next days, I guess  (took me several hours to get that far)

Edit: fixed the slowdown by using a normal dma $420b transfer, fixed that the new tiles are only built up when using the ice rod
currently I try to trace what makes link walk on tiles and why it isn't here. He will walk on patched blocks with e.g. b7 00 at 7E2ABA

ok, so far I got it working to walk on the "ice" you shoot.




There are two problems you must solve yourself:
- link jumps not out of the water when approaching an ice tile floating. He does however so at other tiles, so this is a problem of the ice tile itself I am not able to solve
- give them another color of frozen ice

I'll try to solve the remaining issues:
- load the correct coordinates also at other screens
- when returning to shallow water he from ice tile Link keeps walking as if he were on ice

^so you guys are wanting to make the ice rod make a normal water tile like an ice tile?

that is a very neat idea indeed!

jupp, we are up to... 8) 

Potentialing, can you provide a rom with only the tile changed (without the layer in front of Link's house)?
I may can change the tile properties myself then...

I finished it... this patch was breaking my balls (needed one week to get the calculation of the tiles).



So give me a break before requesting more...

This is really amazing.  I never thought this idea could ever be brought this far. You deserve a long break.

Thank you... this code really was a challenge for me.
I added the asm to the single hacks, but do not know how to write it in this asm file to copy a single byte to an address. Does anybody know?
For example I want only one byte (0E) copied to address 0x71566. Can I simply write:
org $071566 0e?

For someone who thinks he's not as good as the likes of Euclid and MathOnNapkins, I clearly think you still have a thing or two behind your sleeve! The asm works you've made in the past weeks clearly demonstrates your full potential! Keep it up, as those are really well made

Enjoy your break, gotta agree with PuzzleDude, it's well deserved

*haha, thank you
Well, my approach is quite different I guess... but really, I could never make an editor (as for AST) or creating a hack like PW.
I'm just happy to help you guys out, so if there are other issues you are stuck with, just ask

^ Very nice work Conn!!

Anyway, you can teach me how to do this stuff?

@Conn: I assume you 0x0E is an Adress or Constant, so as far as i know you can't using the assembler to insert one byte (correct me if i am wrong). You need to write the complete instruction.

org $071566
xxx $0E (or $#0E)
where xxx is the instruction (LDA for example, just what you need)

@Erockbrox: ty... hm, I do this stuff for approx. 10 years (hacking bszelda), so I know a little bit how the machine works. It's mainly tracing with geiger what I do and manipulating the code.

@XaserLE: the problem is I'd need only 1 byte there without opcode. You know there are LDA $, X instructions where the X points to a single byte. I do not know how to get this one byte rewritten in a correct assembly instruction, since I usually hack directly into the hex code of a rom.

Yes i know, what i meant was, you have to overwrite the complete lda, so go to the lda with org $07155 (one byte before the position where you want the 0E) and overwrite this with LDA $0E. Since there is already a LDA, it is not changed and only the adress is changed to 0E.

*lol, this is tricky... but yes, possible  
So if there was a 00 before the 0e you need to write brk #$0e

Funny ^^

I just checked the caves of my hack and it won't work on 8x8 screens yet (only 16x16) - here the calculation of the coordinates needs to be adjusted and the tile rehacked.

Yeah i understand that form you point of view (i assume you work with hexeditor most) this looks like a dirty trick :-D, but it isn't. This is the usual way to insert code via the assembler cause the assembler isn't there for inserting single bytes, it is there for overwriting and inserting code, therefore you need to overwrite the whole command if you want this piece of code to do what you want :-)

thanks

I've tested this icerod patch a little more, while it seems to work on all overworld, indoors is different, dunno why.

Before fixing this, I wait until Potentialing is returning I guess...

The problem is that the dungeons are somewhat hardcoded to not allow shallow water and ice in the same dungeon. What is ice in some rooms, will auto change into shallow water in the other and vice versa. So dungeons will really not allow it.

I've also fledged your code a bit further, since the tile you've choosen was the tile as a part of the bridge (which is non-neutral gfx tileset), fixed the use of rod in dark world also, and I've also fixed some collision problems (the games actually wont allow any direct collision between ice and shallow water etc). But there's one more problem I couldn't fix, when shooting fast in all directions, the rod affects the non-water tiles, such as walls, which can lead to walk off screen.