RT (Room Transfer) program

Damn.....thank you for your efforts.
At the moment i figured out that there is a significant problem reading the room layers. To certainly identify all 0xFFFF's is not that easy it sounds like. I will try another (the 6th?) idea now and hope this will work. After that i come back to the sprites. It's no problem to write the sprites to bank 0x3F (the last bank in the 2nd MB), so i will try this.

Ok, got it now. The last few hours i had trouble with a strange memory leak, but not in the code that handles the room transfer. The problem occures when creating the new rom name. No idea whats happen here, the debugger can't help me. For the moment i need to use a hardcoded name "_Zelda3(U).smc" for the output rom. I will fix this.

But good news: Thanks to your hint with the jsl, the sprites work now. I write them in the last bank before the 2nd MB starts, this is bank 0x3F. The layer code also works properly. And against all odds, the PW rom works too :-)

https://www.dropbox.com/s/gn68y40ndk26hif/RT.zip

This is great news. I will test and analyze the code in hex tomorrow.
 
Meanwhile I've tested the header some more. If hole/warp, staircase1 or 2 are not in the room, their value is irrelevant. But with staircase3 and 4, which are also Door1 and 2; this special transit will not work in bg1. In fact it need a special door to make the transit, namely type 35 (which is displayed normally only on bg2).
 
This is good news, since we know, that if there's max space for the header, all values must be filled (with room 0 by default). If on bg1, it is impossible to use type 35 (door is not displaied, will not go through), but if type 0 or all other, it will transit normally (it will not go into room 0). If on bg2, if will never go to room 0, if the door goes up or down. So the effect door1 is room 0 will only work on door which leads left or right and only if type 35. If type 32, the transit is normal.
 
So if don't use doors type 35, the additional expanded header will never bug the rom.

This is perfect, so we don't need to care about the additional bytes, awesome!

Update:
-Items work
-Memory leak closed (was only a wrong positionated bracket :-D)
--> The new rom name is now the name of the destination rom plus a "_" at the beginning.

Now i will take time to clean up program code and change some internal things.

https://www.dropbox.com/s/gn68y40ndk26hif/RT.zip

I've just tested this new version, and it is great . All calculations are correct, and the modified rom was also tested in-game (sprites, items, header, layers). I've also tried to do the transport of room1 into room 310 and everything was copied (sprites, layer etc). And the layer area of 310 was correctly expanded from 1 line to more lines. This is looking great, really.

Thank you :-), i do my very best. The most awesome thing for me is the fact that it works with parallel worlds. I think this will be very useful when hacking Zelda 3.

The latest HM reads the pointer for the header pointer table and the data bank of the headers, so this can be modified, HM will work with that.
But when moving the other data (like we do with the Room Transfer tool) HM will not work with that. HM will also not work with the moved headers like we do it (all 320 rooms, not only 296).

I think this tool will work with PU properly since the RT follows the pointers, nothing is hardcoded (like in HM). The asm will then be interpreted as data of the room and be copied, but not changed.
Can you explain what you exactly mean with "space"? As far as i know there is no space for this rooms, all pointers point to an end marker similar to 0xFF. The only space for asm code i can see here are the pointers for the rooms 296-319, they can be overwritten without crashing the game (i think).

I think the PW works since the code affect the primary pointers (and no game can change this). There's a bank breach with items on PW by the way. So the items will not work for above room 260. But this really is a minor problem, since the main goal of locating! the data in hex is not solved with this program.
 

Yes i have a really confusing code for preventing these breaches. That's what i meant when i said i will take time to clean up and change some things. After that this will no longer be a problem.

I wonder if this would work with Parallel Universes considering Euclid is using room 319 space for some asm work there! Can I still edit my rom with the header moved elsewhere (with latest HM)?

Once the new code is in, all versions of HM will not work. But the program is capable of reading the header if it is normal or on HM964 new location. Once the code is read, the new code is written on a specific place, incompatible to all HM versions. I wish we could merge the RT with HM (this would be an awesome tool), but unfortunatelly not possible without the source code of HM.
 
I suggest to not use room 319 (leave its pointer). When you run PU through the RT, there should be no changes in dungeons (if there are changes, like sprites or items are no longer there, then it is incompatible). I hope it is compatible to PU (this would mean you could use all 318 rooms, who knows the Emus can handle this).
 

Yes i have a really confusing code for preventing these breaches. That's what i meant when i said i will take time to clean up and change some things. After that this will no longer be a problem.

Good to hear, that this can be fixed.

Merging the tools would be amazing but like you said, not possible without souce code, really a shame....

Ok the bank breach with parallel worlds is fixed. There is another little piece of code i need to rewrite to make it absolutely safe.

https://www.dropbox.com/s/gn68y40ndk26hif/RT.zip

Edit: Fixed minor mistake in bank calculation due to the changes i made before.

Ok, fixed the last piece of code to prevent bank breaches, should not happen anymore.

https://www.dropbox.com/s/gn68y40ndk26hif/RT.zip

Tested the RT with a parallel universes rom, but didn't work, mistake when reading sprites i guess. Will see if i can fix that.

This is now very well made (a very usefull tool for locating data). Tested with Alttp and PW (no bank breach for items). Don't know about PU, but I know that rom is very edited (but since it is compatible with HM, it should work?).

Yes i think there is only a problem by reading the end marker of the sprites. I will try to analyse this.

ToDo: Torches, Pushable Blocks, Pits, Chests, Messages

Ah, sorry, works with PU, just forgot to cut the header before using RT :-D.
I really need to fix this to make it work with headered roms.

Yes, PU has a header by default to be able to bring in gfx (zcompress works only with header, which is odd). I couln't see any problems with sprites (end marker is the first FF after the pointer).
 
Regarding the rest. Messages are ok by default I guess, since they use max space (all 320 rooms can have a different message).
 
Torches and Pushable blocks can be expanded, but only 4x80 in hex, with 4 pointers for blocks, and 3x80 for torches). Chests space is hardcoded as well, as far as I could examine (or maybe there's a byte close to primary pointer in that asm code, which controls this hardcoded block, but I couldn't find it).
 
And unfortunatelly the same with pits (hardcoded block). Only 57 rooms out of 320 can have damage pits (I hope we can expand this). There's just enough torches, blocks and chests, but there's not enough damage pits.

Since I couldn't find any pointers for Damage pits and Telephatic messages in my original documents, I've looked into it and found them.
 
Damage pits
-----------
 
primary pointer at
394AA,
code is
DF 0C 99 00, 00990C = 190C
 
data at
190C (hardcoded block to 72)
72 in hex is 114 in dec :2= 57 rooms with pits possible
 
I hope we can find a way to expand this.
 
 
 
Tel. messages
-------------
 
primary pointer at
3B500,
code is
A8 B9, 1D F6
add 07,  1D F6 07, 07F61D= 3F61D
 
bad news for this one, asm needed, similar to sprites, to move this, but I don't think moving is necessary, because of the max space for messages is used by default
 
data at
3F61D (hardcoded block to 280)
280 in hex is 640 in dec :2= 320 rooms (all rooms covered)
 
If we could somehow find, how Telephatic messages are usign hardcoded block 280; we could use the same amount on pits that hurt and make max space for it also. If this is found, maybe it can be traversed into chests too (currently has 1F8, so 280 would be a benefit; the same with torches and blocks, courently one pointer has 80 in hex after it; imagine this being 280 as the messages - then we could use a lot more blocks and torches; while still have it in logical borders, so that the emus would support it).

Ok i saved this and hopefully get it work.

Updata: Pushable Blocks, Torches and Chests added.

Unfortunately due to the lack of RAM i couldn't really extend pushable blocks and torches, maximum is what you figured out, 0x200 for blocks and 0x180 for torches. The problem here is that the game loads ALL blocks and torches of the whole game when going into a dungeon room, so there is no way to extend this without overwriting other RAM, plus there are some hardcoded adresses that would need a recode. But i think the actual maximums are better than nothing.
Regarding the chests: There should be no maximum (ok, 0x8000 as bank size is the maximum :-D).
Since there are no secondary pointers, i couldn't divide the data this nice in sections saying "chest room 1" and so on, there is only the word "Chest" at the beginning. Same for pushable blocks and torches.

If you have some time for that, could you please test if it works as it should? I had some problems with small chests saying me i would need the big key, but the big chest indicator isn't set, i have no idea what happend. And please try chests behind the past limit of 0x01F8.

So it is the Ram issue (I think the actual maximums for torches and blocks is fine - just enough), and the extended part of chest definitions is good news. However when I tested chests long ago, it did not read past 1F8. Small chests acting as big is usually if the middle byte is 80 instead of 00, so it must be 00, and the chest will be regarded as small. Exception is, if one room has a big and small chest (not recomended, since the program and emulator can get confused).
 
Also, I didn't find the shourtcut for downloading this last version.

Oh sorry, i forgot the link, here it is: https://www.dropbox.com/s/gn68y40ndk26hif/RT.zip


The maximum of 0x1F8 is a hardcoded adress in the code that loads the chest (look around the pointer adresses for chests and you will see it or use the disassembly), i changed this.
I know about the 0x80 for a big chest since you discribed this in your document. The 0x80 isn't set but the game tells me i would need the big key. There are 3 small chests in the room.

I saw another little problem. I tried to copy a random room into room 260 (the starting room), but when going in the game hangs, black screen. It seems it is not possible to overwrite this room, there is something hardcoded.

Analysis:
-pushable blocks (number of bytes ok, pointers ok, data ok, tested ok), the program must know to change the values at 8896 to extend the last bank to 80
-torches (number of bytes ok, pointers ok, data ok, tested ok), the program must know to change the values at 88C1 to extend the last bank to 80
-chests (pointer problem here, since I wrote the address for main pointers leading to BF, so the correct version is this
EBFB must be A0 F0 41, (remains)
EC0A must be A2 F0 41, (the program makes is A1 F0 41 at EC09)
EC10 must be A0 F0 41, (the program makes it at EC0F).
In my doc I have EC09, EC0F= but leading to BF, not the code, so the code is one byte after, where the pointer must be.
I've fixed this manually and now the big-key message to open small chests is gone.
 
Current version of the program can have 4x80 blocks, 3x80 torches, but only 1F8 for chests.

EDIT
I've just found the expansion for chests!
It is at EBF6! just before EBFB (pointer). Currently it is F8 01, so reversed 01F8. I've expanded this to 1C 02 is 21C, put the chest at the end, and it works. Expanded spece must be dividable with 3. So 1F8+3+3+3+3...
Max (didn't test it yet) with two bytes is FF FF= can be divided with 3. FFFF= 65.535 :3, is 21.845 chests possible in theory (didn't test it yet).

Thanks for that, i will correct the pointers.

Regarding the chests: Yeh, when you read my last post you will see that i told you this about 0x1F8 :-D, the program changes this value already, so there is no problem for more chests.