RT (Room Transfer) program

RT (Room Transfer) program

DOWNLOAD:
https://www.dropbox.com/s/t81ywev9rxn3cfk/RoomTransfer.zip

MIRROR:
http://www.bwass.org/bucket/RoomTransfer.zip

Information:
------------
This is the Zelda ALttP Room Transfer.

Cause Hyrule Magic lacks the possibility to expand the data for rooms (objects, sprites and so on) and especially edit the rooms 296-319, this tool was written to merge ROM files. You can edit rooms in separate files and put all together in one after editing. Therefore you can also move rooms behind Hyrule Magics possibilities (296-319).

The new data written at offset 0x1F8000 (beginning of bank 0x3F). Make sure there is no data at that place. To understand the dungeon data take a look in PuzzleDude's DungeonData.txt (within this zip-file).

The only thing you should keep in mind is that entrances must be set in by yourself with Hyrule Magic, they are not copied/extended. Better delete white spaces in your rom filename.

Usage:
Run command prompt in Windows first.

1.)
command:
RT.exe ROM.smc

--> Will make a copy of the rom with all room data moved to the end and save it under the new name "_[name of rom]"

Example command:
RT.exe Zelda3.smc
------


2.)
command:
RT.exe SourceROM.smc DestinationROM.smc

--> Will copy all rooms from source rom into destination rom and save it under the new name "_[name of destination rom]"

Example command:
RT.exe Zelda3.smc Zelda3hack.smc
------


3.)
command:
RT.exe SourceROM.smc DestinationROM.smc SrcRoom1-DestRoom1-SrcRoom2-DestRoom2-....-....

--> Will copy specified rooms from source rom into destination rom and save it under the new name "_[name of destination rom]"

Example commands:
RT.exe Zelda3.smc Zelda3hack.smc 98-101
RT.exe Zelda3.smc Zelda3hack.smc 98-101-54-76-32-68



Credits:
Coded by XaserLE (www.le-softworks.com)
Thanks goes to PuzzleDude for his detailed dungeon data document.

XaserLE wrote:In two weeks i have more time. Then i will use my RHE to write a new program that copies fully automatically a specific room from one rom to another (including the correct room header) and recalcs header data if needed. So you can use a seperate rom to edit the rooms 296-319 in and then by one click merge them fully functional (but without sprites) with your actual rom to a new one.

 
This would be a great thing to have. This is why I've made the indoor data study in the first place.
 
If you study my document further, you can see, that it also has indoor items fully decoded. So they can also be moved to another address to allow more space.
 
If only all the data (objects, items, sprites, header etc) for one room would be stored at the same place, moving would be no problem.
---------------------------
 
What about a possibility to have a program, which would simply export the hex data for choosen room to a txt file. Object data, header, items and chest definitions (I've hex decoded this, pointers and all), but ignoring the telephatic messages, torches, pushable blocks and sprites (all of those are different).
 
Using precalculated pointers and new locations, we could then bring all rooms together in one file easily in hex, without having any programs (wouldn't mind having one though to actually insert the data at fixed locations and in order from room 0 to 295 or 319).

Hey i see i am not the first one that had this idea :-D
In the test (see picture) i moved the header and the object data (0xF8000, you told me). If you could gave me the other things i could implement all to move a room completely :-)
Or is there any data you don't know? Sprites?

This is from my hex Dungeon data document


1.) Object data indoors

primary pointers at
-8746, 01 80 1F --> F8001
-874C, 00 80 1F --> F8000
-883F, 01 80 1F --> F8001
-8845, 00 80 1F --> F8000
all coresponds to F8000

at F8000, 3 byte pointers, for rooms 0-319.
*Let's say the pointer is
6A 84 0A = reversed 0A 84 6A --> points to 5046A
etc

*Room code
start (pointer points to it)=5046A as example
....bg1...FF FF
....bg2...FF FF
....bg3...FF FF. (end)

Data are objects: x position, y position, size, type.
Data holds room layout (2nd byte) and floor1 and floo2 value (1st byte).
---------------------------


2.) Sprite data indoors

*Primary pointer at: (value 2E D6 can change!, because of the overworld sprites)
4C298, but 2 bytes only = 2E D6
No third value 09, to make it 2E D6 09 = 09 D6 2E = 4D62E.
no value is 09 to define 40000. (Decoded for taking the data out, but can not put it back elsewhere).

*Secondary pointers at (this can change! because of the overworld sprites)
4D62E (block is 300) = in dec is 768:2 = 384 (for 320 room + some additional data).

*Data is at:
4D92E (block is 1371) = ends at 4EC9E (always the end regardless of the overworld sprites)


*Pointer read:
2E D9 = reversed D9 2E = 09 D9 2E --> points to 4D92E = room 0.


*Sprite Code
for room 0 = Ganon
00 05 17 D6 FF,
sort sprite is 00, y = 05, x = 17, type = D6-Ganon, FF = end.

The 05 is not only y coordinate, but also: if the sprite is on bg1 or bg2.
---------------------------


3.) Item data indoors

-These are red dots in HM, to define stuff under jars (heart, magic, key, bomb etc)


*Primary pointer at E6C1
Code BF 69 DB 01, 85 00, A9 01

69 DB 01 points to DB69

01 defines the global bank. Can be realocated anywhere between 0 and 400000. For instance BF 69 DB 23, 85 00, A9 23; new address is 11DB69.


*Secondary pointers at:
DB69 (block is 282), 282 is 642 in dec :2 = 321 rooms (for 320 rooms + 2 bytes)

*Data at:
DDEB (block is 8C7)


*Pointer read
EB DD reversed is DD EB = direct address = DDEB


*Item code
CE 13 0B FF FF,
CE = x, 13 = y, 0B = type, FF FF = end

A jar object is necessary at the same location for the item to work!
---------------------------


4.) Indoors pushable blocks

*Number of bytes to define block data at:
8896,
default is 8C 01 = 18C = 396 bytes :4 = 99 blocks, but
maximum is 00 02 = 200 = 512 bytes :4 = 128 blocks (29 more).

*Primary pointers at:
1. 15AFA, DE F1 04, --> 271DE (but with hardcoded block = 80)
2. 15B01, 5E F2 04, --> 2725E (but with hardcoded block = 80)
3. 15B08, DE F2 04, --> 272DE (but with hardcoded block = 80)
4. 15B0F, 5E F2 04, --> 2735E (but with hardcoded block = 0C by default, 80 max)

Pointers can be changed to another place, but it will only read the 80 bytes in hex after this location.


*No secondary pointers, but Data directly at:

271DE (block is 80+80+80+0C) = 18C = 396 in dec :4 = 99 pushable blocks.
max block is 80 x 4 = 200 in hex.

*Code (4bytes for one block!)
0B 01 3A 19 (no ending value! FF), room values are mixed, so the space must be hardcoded, that the game knows where to stop reading values.

0B 01 is 10B = room 267.
3A is x, 19 is y.
---------------------------


5.) Indoors torches


*Number of bytes to define torch data at:
88C1,
default is 2C 01 = 288 bytes, but
maximum is 80 01 = 384 bytes. (around 28 torches more)

max was tested, 8C 01 crashes the game, too much data for torches. So 80 in hex for one pointer is max.

*Primary pointers at:
1. 15B16, 6A F3 04 = 04 F3 6A = 2736A (block 80)
2. 15B1D, EA F3 04 = 04 F3 EA = 273EA (block 80)
3. 15B24, 6A F4 04 = 04 F4 6A = 2746A (block 20, max 80)

If 04 is changed to 24, new data is at 12736A and at 88C1 to 80 01, the block can be 384 bytes long.


*No secondary pointers, but Data directly at:

2736A (block is 80+80+20) = 12C = 288 in dec.
max block is 180 in hex

1 torch in a new room is 6 bytes, then +2 bytes for each torch.
2 torches is 8bytes, 3 is 10 and 4 is 12 etc.


*Code (example)
43 00, AA 03, B6 03, AA 09, B6 09, FF FF

43 00 = room 67,
AA is x, 03 is y for the first torch
B6 is x, 03 is y for the second torch etc
FF FF is end.

The upper room has 4 torches.
---------------------------


6.) Room header properties

*Primary pointer at B5DC
Code BF, 02 F5 04, 85 0D, E2 20 C2 10, A9 04

02 F5 04 points to 27502

04 defines the global bank. Can be realocated anywhere between 0 and 400000. For instance BF, 02 F5 24, 85 0D, E2 20 C2 10, A9 24; new address is 127502.


*Secondary pointers at:
27502 (block is 280)

*Data at:
27782 (block is 87E)

*Pointers + data
27502 (block is AFE)

*Pointer read
82 F7 = F7 82 = 04 F7 82 = 27782


*Header code (14 bytes maximum)

1st byte,
bg properties + collision

2nd byte, 3rd byte, 4th byte, 5th byte, 6th byte, 7th byte
PAL, BLK, EnemyBLK, Room effect, Tag1, Tag2


8th byte
Plane properties for hole/warp and staircase 1, 2, 3

9th byte
Plane properties for staircase 4

10th byte, 11th byte, 12th byte, 13th byte, 14th byte.
hole/warp, staircase1, staircase2, staircase3, staircase4.
---------------------------


7.) Chest definitions

*Primary pointers at:
1. EBFB, 6E E9 01 = E96E
2. EC09, 70 E9 01 = E970
3. EC0F, 6E E9 01 = E96E
all for E96E

Repoint all 3 accordingly. 01 to 23 is 11E96E for instance.

max bank is 1F8 = 504 in dec : 3 for one chest = 168 chests possible in the game.


*No secondary pointers, but Data directly at:
E96E (block is 1F8)


*Code is (3 bytes for one chest definition)
04 00 23, 04 00 = room 4, 23 is a content of the chest.
23 in hex is 35 in dec is 35: Armor 3 in Hyrule magic.

04 80 23, 04 00 = room 4, but 80 is big chest, 23 is Armor 3.

04 01 23, 04 01 is 104 in hex is room 260, 23 is Armor 3.

*Definition will only work with the chest object in the same room.
---------------------------


8.) Indoor damage pits

*Couldnt find any pointers here


*Data at 190C (block is fixed to 72)

72 in hex is 114 in dec :2 = 57 rooms with pits are possible.

2 bytes for a pit definition.

*Code
72 00 = room 114

No pointers, fixed location and block size. No FF ending, just a list of rooms in hex.
---------------------------


9.) Indoor telepatic messages

*Couldnt find any pointers here


*Data at 3F61D (block is fixed to 280)

280 in hex is 640 in dec :2 = for 320 rooms. Rooms go from 0-319.

2 bytes for a message definition.

*Code
72 00 = message (monologue number) 114

No pointers, fixed location and block size. No FF ending, just a list of message values in hex.

--------------------------
--------------------------

With this you should be able to bring all the data for one room out of the rom. Bringing it in on other address is a different thing, since not all data can be realocated to other global banks.

Thanks, great :-)
I've never seen this document before, i only have this little PM you sent me on kafuka.org with the indoor data at F8000.
I will do what i can. At first moving a room with headers and indoor data and then, step by step, the other values if possible.

Here is the long version of it on this forum
http://zeldix.forumotion.com/t58-vital-dungeon-hex-data
 
Yes, go step by step. Basically I can bring all data of a room out of the rom into txt manually (but this is a lot of work). Copy from hex editor into txt. With this hex string in the txt, the data is secured.

Thank you, this tool is going to be awesome! :-)

@XaserLe
 
Here the example of (manual) data extraction for room 56 in Alttp to help you with your custom program.
 
 
1.) objects F8000
 
find pointer = 1+56= 57, 57x3= 171 (dec), select block 171 in dec from position F8000;
last 3 bytes (that are still a part of the selected block) are the pointer!
AE 92 1F = 1F92AE (snes) = F92AE (pc = hex)
 
 
pointer --> jump to data= start of data= F92AE, end is third FF FF after start.
 
all data is:
E1 04 FC 23 00 18 31 01 FC 83 04 20 22 61 FC 81 00 FC 24 81 18 49 02 FC 84 85 22 5B 61 FC 8B 04 18 B1 01 FC 2B 00 FC 2C 81 18 C9 02 FC 8C 85 20 DA 61 FC 8E 81 20 6A 65 69 3A 66 FC E1 38 2F 23 C8 2C 63 C8 34 63 C8 54 63 C8 5C 63 C8 2F AB C8 2C A0 C8 34 A0 C8 54 A0 C8 5C A0 C8 2F 1D 3F 2F 23 79 2F 63 79 2F A3 79 2C E1 79 2F E9 40 6B 23 7A 6B 63 7A 6B A3 7A 68 E1 7A 44 61 41 47 67 7A 44 A5 42 53 67 79 39 EB FE 59 10 F8 4B 67 FA 4B 6F FA 4B 97 FA 4B 9F FA 60 81 FE 01 11 C0 01 5B C0 01 91 C0 01 D9 C0 FF FF FF FF F0 FF 02 2E 22 1C FF FF
 
 
 
2.) header 27502
header (staircase1 is opened)--> header is 11 bytes long
 
find pointer = 1+56= 57, 57x2= 114 (dec), select block 114 in dec from position 27502;
last 2 bytes (that are still a part of the selected block) are the pointer!
46 F9 = add 04 = 46 F9 04 = 04F946 (snes)= 27946 (pc = hex)
 
 
pointer --> jump to data= start of data= 27946, end is examined (11 bytes in this case, because staircase1 is opened in HM)
 
all data is:
80 0A 08 11 00 00 00 00 00 00 28
  
 
3.) sprites 4D62E
find pointer = 1+56= 57, 57x2= 114 (dec), select block 114 in dec from position 4D62E;
last 2 bytes (that are still a part of the selected block) are the pointer!
53 DD = add 09 = 53 DD 09 = 09DD53 (snes)= 4DD53 (pc = hex)
 
pointer --> jump to data= start of data= 4DD53, end is FF.
 
 
all data is:
00 06 0C 81 0A 07 81 0C 0C 9A 10 0C C5 14 06 9A 18 0C 9A 1A 07 81 FF
  
 
4.) items DB69
find pointer = 1+56= 57, 57x2= 114 (dec), select block 114 in dec from position DB69;
last 2 bytes (that are still a part of the selected block) are the pointer!
80 DF = add 01 = 80 DF 01 = 01DF80 (snes)= 00DF80 (pc = hex).
 
pointer --> jump to data= start of data= DF80, end is FF FF.
 
 
all data is:
A4 0C 0A A4 0D 07 A4 12 0A A4 13 08 FF FF
--------------------------------------------------------
 
 
End result for room 56 is
(I hope you can make a custom utility to be able to extract the lower codes into txt automatically)
 
1) objects
E1 04 FC 23 00 18 31 01 FC 83 04 20 22 61 FC 81 00 FC 24 81 18 49 02 FC 84 85 22 5B 61 FC 8B 04 18 B1 01 FC 2B 00 FC 2C 81 18 C9 02 FC 8C 85 20 DA 61 FC 8E 81 20 6A 65 69 3A 66 FC E1 38 2F 23 C8 2C 63 C8 34 63 C8 54 63 C8 5C 63 C8 2F AB C8 2C A0 C8 34 A0 C8 54 A0 C8 5C A0 C8 2F 1D 3F 2F 23 79 2F 63 79 2F A3 79 2C E1 79 2F E9 40 6B 23 7A 6B 63 7A 6B A3 7A 68 E1 7A 44 61 41 47 67 7A 44 A5 42 53 67 79 39 EB FE 59 10 F8 4B 67 FA 4B 6F FA 4B 97 FA 4B 9F FA 60 81 FE 01 11 C0 01 5B C0 01 91 C0 01 D9 C0 FF FF FF FF F0 FF 02 2E 22 1C FF FF
 
2) header
80 0A 08 11 00 00 00 00 00 00 28
 
3) sprites
00 06 0C 81 0A 07 81 0C 0C 9A 10 0C C5 14 06 9A 18 0C 9A 1A 07 81 FF
 
4) items
A4 0C 0A A4 0D 07 A4 12 0A A4 13 08 FF FF

Great, well made, thank you, that will help a lot.
Next Thursday is my last test for this semester, after passing it i will begin :-)

Nice. This is my other document for data extraction:
 
data extraction TXT
https://www.dropbox.com/s/y809qw1iukc908q/Data%20extraction.txt
 
 
Test in end july, this reminds me on the time, when I was still studying.

Wow, it seems you hold a whole treasure of hex data from this game :-)
Yes the semesters a really hard (computer science) and i am glad if the tests are done and i have 2 months of freetime.
What did you study?

Regarding the hex data. I made those documents a while back (they are similar though, but this one is more focused on extraction). I used Hyrule Magic and reverse engeneering.
 
I studied European (and partially world) history. (But forgot a lot of it also  ).

Good strategy. A few yeara ago i recoded the mapeditor of the game "Settlers 2" (under the pseudo Xaser) and did the same. Used the original editor, changed something and searched via hex editor what happend :-)

Ok the semester is done :-D, i am free for two months!
I will start immediately!

Nice. Meanwhile we have also decoded the sprites. Since Conn made a entirely new routine to transfer indoor sprites. It seems like the third byte 09, which has defined the global bank was "somewhere inside" and the entire new code was necessary, which loads the new 29 bank separately. This byte can of course be changed to anything.
 
So now we can officially move all data, that is connected to the indoors. Of course this is actually needed for putting data back in, but for now we can concentrate to extraction only.

Yes i read this in the other thread, perfect.
But my main goal was rather to move data than extract. But no problem, i can also extract them cause this step is anyway necessary.
Could you update you indoor dungeon data describition with the sprite extraction? In the meanwhile i will start with the tool.

Could you update you indoor dungeon data describition with the sprite extraction.

  
I've updated the original document here
http://zeldix.forumotion.com/t58-vital-dungeon-hex-data#301


The extraction is just the first step. The second step is to insert, so basically all together is a transfer. However inserting can be done with precalculated pointers, giving the rooms enough space, so that they can not run out even on very filled room. The pointers would then be fixed, and would not change (so no bugs possible and quick restore of all pointers is possible).

This will be a lot of work. Coding such things like reading pointers in little endian an follow them is much harder as writing "normal" software, but i will manage this.
How do you want me to extract the data? To a text file with description like "Room xx - Sprites:..."?

I thought so. Maybe this is why HM never reads any pointers. Regarding the data extraction. Can be a standard txt, with the Room xx and then Objects followed by data, Header followed by data etc.

You could for instance simplify to read only secondary pointers for all data except sprites. These sec. pointers remain on place. Bigger problem with sprites, where the primary pointer remains, but secondary ones move.

Ok, somehow this will work even if it's the last thing I'll ever do :-D

Ok, the first alpha version. It moves room headers and recalculates header pointers. Next version will move room objects. I use the 3rd MegaByte of the ROM (0x200000 - 0x2FFFFF) for the data. Should work with all roms, cause nothing is hardcoded (except the pointer locations like 0xB5E7 and so on), the tool follows all pointers. Works also with ROMs that have the pointers moved with MathOnNapkins version of HM (by the way Math, thank you for cutting the pointers after room 295, that made it more complicated :-D).
I think that was the hardest part for now, the rest should be more paste and copy than coding (i hope so).

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

I've tested this out. Smart move with leaving the pointers in place, but moving the data only.
 
I found one problem though. It seem the read area is also maximum, which is 14 bytes, but the read area is changing (room0 of Alttp only has 10 bytes, next room has 14, next 11, then 7 etc, but it seems that RT always reeds 14).
 
Similar with RHE. But different problem there. RT is better, it just can not set the end of reading (I guess this is dufficult to do, since there's no FF indicator). The only way to se where it ends, is with original pointers. First one points to 82, next on on 8C, so 10 bytes long (for room 0).
 
 
 
Original Alttp (from room 0 to room 7)
pt---values
82---41 21 13 22 07 3D 00 00 00 10
8C---C0 00 00 04 00 00 00 00 00 00 72 00 50 52
9A---C0 1D 04 06 00 14 00 00 00 00 11
F0---C0 07 06 19 00 00 00
A5---00 18 0D 26 00 26 14 00 00 00 B5
B0---00 08 08 14 00 25 00
B0---00 08 08 14 00 25 00
B7---20 06 05 0C 00 25 00 00 00 17 17
 
 
Result of RT
 
60---41 21 13 22 07 3D 00 00 00 10 C0 00 00 04
6E---C0 00 00 04 00 00 00 00 00 00 72 00 50 52
7C---C0 1D 04 06 00 14 00 00 00 00 11 00 18 0D
8A---C0 07 06 19 00 00 00 00 0C 02 12 00 00 00
98---00 18 0D 26 00 26 14 00 00 00 B5 00 08 08
A6---00 08 08 14 00 25 00 20 06 05 0C 00 25 00
B4---00 08 08 14 00 25 00 20 06 05 0C 00 25 00
C2---20 06 05 0C 00 25 00 00 00 17 17 C0 07 06
 
 
Result of RHE
 
B0---41 21 13 22 07 3D 00 00 00 10 00 00 00 00
BE---C0 00 00 04 00 00 00 00 00 00 72 00 50 52
CC---C0 1D 04 06 00 14 00 00 00 00 11 00 18 0D
DA---00 00 00 00 00 00 00 00 00 00 00 00 00 00
E8---26 00 26 14 00 00 00 B5 00 00 00 00 00 00
F6---00 00 00 00 00 00 00 00 00 00 00 00 00 00
04---00 08 08 14 00 25 00 00 00 00 00 00 00 00
12---20 06 05 0C 00 25 00 00 00 17 17 00 00 00
20---C0 07 06 07 00 00 00 00 00 00 00 00 00 00
 
 
 
Should be like this (FF must be 00!)
 
60---41 21 13 22 07 3D 00 00 00 10 FF FF FF FF
6E---C0 00 00 04 00 00 00 00 00 00 72 00 50 52
7C---C0 1D 04 06 00 14 00 00 00 00 11 FF FF FF
8A---C0 07 06 19 00 00 00 FF FF FF FF FF FF FF
98---00 18 0D 26 00 26 14 00 00 00 B5 FF FF FF
A6---00 08 08 14 00 25 00 FF FF FF FF FF FF FF
B4---00 08 08 14 00 25 00 FF FF FF FF FF FF FF
C2---20 06 05 0C 00 25 00 00 00 17 17 FF FF FF
 
 
so it will look like this (similar to RT, but extra space must be 00)
 
60---41 21 13 22 07 3D 00 00 00 10 00 00 00 00
6E---C0 00 00 04 00 00 00 00 00 00 72 00 50 52
7C---C0 1D 04 06 00 14 00 00 00 00 11 00 00 00
8A---C0 07 06 19 00 00 00 00 00 00 00 00 00 00
98---00 18 0D 26 00 26 14 00 00 00 B5 00 00 00
A6---00 08 08 14 00 25 00 00 00 00 00 00 00 00
B4---00 08 08 14 00 25 00 00 00 00 00 00 00 00
C2---20 06 05 0C 00 25 00 00 00 17 17 00 00 00
 
 
one row version
(this is optimal for fast viewing and easy pointer calculation), (FF must be 00!)
 
60---41 21 13 22 07 3D 00 00 00 10 FF FF FF FF FF FF
70---C0 00 00 04 00 00 00 00 00 00 72 00 50 52 FF FF
80---C0 1D 04 06 00 14 00 00 00 00 11 FF FF FF FF FF
90---C0 07 06 19 00 00 00 FF FF FF FF FF FF FF FF FF
A0---00 18 0D 26 00 26 14 00 00 00 B5 FF FF FF FF FF
B0---00 08 08 14 00 25 00 FF FF FF FF FF FF FF FF FF
C0---00 08 08 14 00 25 00 FF FF FF FF FF FF FF FF FF
D0---20 06 05 0C 00 25 00 00 00 17 17 FF FF FF FF FF
 
Last two bytes of each row will be ignored (since they go over maximum). Also FF must be 00 (I've just put it on FF to see the extra space).

Yes i use the full 14 bytes for the header and if one is shorter i read the data behind (header of the next room). Not the best way cause like you said, it is nearly impossible to see the end. I would need to check all pointers to see if the actual read header is shorter than 14 bytes. MathOnNapkins' HM version uses 14 bytes too, but it seems it sets 0xFF for unused data. I will try to manage this.

I forgot: The Problem to see the end of a pointer is that it is possible to re-use them. The original game does this in some rooms. Therefore it is really hard.

It is ok, if this can't be changed to 00. I think it does not affect the actual game. Since if only 7 bytes are used, there's no staircase in the room (which will then be set to some other value, if 00, this staircase will lead to room 0, if it is random, it would lead to random room).

And if the staircase is additionally put in the room, the actual value is set.

I haven't really thought of that, but it doesn't matter if it is random, since a value must be set. So 00 will only put it to room 0, rather then random.

The only problem, which might occur, is when adding new values manually, so it is better to always use the HM on another rom, to set the values.