Welcome Guest [Log In] [Register]

Announcements

Welcome to Zelda64.net. Announcements can be found below!

6.26.2018  Make sure you keep your passwords safe. If you use the same password on here as on other sites, it is highly recommended that you change it. If you can't change your password, and want it changed, let me or other active staff know, and we can force a reset or change it for you. ~PwnzLPs
Welcome to Zelda64. We hope you enjoy your visit.


You're currently viewing our forum as a guest. This means you are limited to certain areas of the board and there are some features you can't use. If you join our community, you'll be able to access member-only sections, and use many member-only features such as customizing your profile, sending personal messages, and voting in polls. Registration is simple, fast, and completely free. A valid email address is required. Your email address will NOT be sold as it is only needed to prevent spammers (and admittedly, some still get around this, but this makes it a bit more difficult, plus, if the moderators need to contact you, we have an email on file to do so). Thanks for considering us!


Join our community!


If you're already a member please log in to your account to access all of our features:

Username:   Password:
Add Reply
  • Pages:
  • 1
  • 2
How do you create more space in the debug rom?
Topic Started: Jun 11 2017, 04:13 PM (1,094 Views)
z64offline
Member Avatar
Empath mapmaker
I've been wondering this for a while. I'm sure creating space can accomplish an array of things from characters to items...I'd like to know the process in which to do this for maps. Many maps I've made used to be too large in size or just over the scene size. I know you "could" get away with this (Using a scene that wasn't intended to get overwritten AS the extra space needed ), but I don't want to do that. I want to know the step to step how to write in or redirect the game data size space to be placed into a specific spot, because I have NO idea how to even begin much less where to begin. (I do have a skype on my phone or could even face chat if need be, but a walk through of this subject is something I believe is and would be essential.)
Offline Profile Quote Post Goto Top
 
Replies:
aroenai
Member Avatar
Sentient Hunk of Green Cheese
Killgore52
 
... but I would rather be focusing on the art side of zelda hacking.


:\ therein lies your fundamental problem, you're not going to be able to make anything functional if you don't actually understand what you're looking at.

Killgore52
 
And I have taken a look at the scene table and went to the offsets and I couldnt find any patterns or make sense of the data before me.


Seriously, read the cloudmodding wiki everything is explained.

In short: Scene table references the offsets in the DMA table for the Scene files, the Scene files reference the DMA offsets for the Room files. The location of those references in the Scene files will vary because it's an 04 command in the header that you have to find.

http://wiki.cloudmodding.com/oot/Scene_Table

http://wiki.cloudmodding.com/oot/Finding_.zmap_offsets

http://wiki.cloudmodding.com/oot/Scenes_and_Rooms
Edited by aroenai, Jun 12 2017, 08:23 PM.
Offline Profile Quote Post Goto Top
 
Killgore52
Member Avatar
Map Maker
I had no idea that the 04 command referenced the scene table. I only had so much time before work to go through it. And sometimes the cloud modding wiki does not explain it very well imo. And just because I would prefer to focus on the art side, doesnt mean I wont take the time to learn the technical stuff. It just means I would rather not.
Edited by Killgore52, Jun 12 2017, 10:19 PM.
Offline Profile Quote Post Goto Top
 
mzxrules

aroenai
Jun 12 2017, 07:11 PM
https://m.imgur.com/a/WSV8s
#coversdmaalreadywithouthandholding
You've made a critical error in your tutorial.

Quote:
 
Next, we need to update the asm that tells the game where Audioseq is located.

In MIPS assembly:

LUI $A1,xxxx
ADDIU $A1,$A1,yyyy

Compiled this looks like:

3C05 xxxx 24A5 yyyy

Replace the X and Y values with the original offset for Audioseq that you wrote down at the beginning of the tutorial.

If you're using the retail rom, you'll get no results. For some reason, the retail roms add 0x00010000 to the dma address.


The reason is simple: ADDIU stands for unsigned addition with an immediate value. The quirk here is that the immediate is treated as a signed 16 bit value (the "unsigned" part of the instruction actually means that a trap won't be triggered if the operation of the addition overflows). As such, any value over 0x7FFF actually performs subtraction, not addition. This explains why "retail roms add 0x00010000 to the address"

For example, NTSC 1.0's AudioSeq file starts at 00029DE0, thus the following operation will occur:
Code:
 
lui a1 0x0003 //a1 = 0x00030000
addiu a1, a1, 0x9DE0 //0x9DE0 is actually -0x6220; 0x00030000 + -0x6220 = 0x00029DE0



Quote:
 
I had no idea that the 04 command referenced the scene table. I only had so much time before work to go through it. And sometimes the cloud modding wiki does not explain it very well imo. And just because I would prefer to focus on the art side, doesnt mean I wont take the time to learn the technical stuff. It just means I would rather not.

The 04 command doesn't do that at all.

The scene table stores a direct reference the scene file. Outside of the dmadata file, it is the only reference to a single scene file's location in the rom.
The 0x04 scene header command stores direct references to the scene's room files. Outside of the dmadata file, the 04 command(s, don't forget alternate scene setups) contain the only reference(s) within the rom to the individual rooms for a given scene.
Edited by mzxrules, Jun 13 2017, 12:28 AM.
Offline Profile Quote Post Goto Top
 
aroenai
Member Avatar
Sentient Hunk of Green Cheese
mzxrules
Jun 13 2017, 12:16 AM
The reason is simple: ADDIU stands for unsigned addition with an immediate value. The quirk here is that the immediate is treated as a signed 16 bit value (the "unsigned" part of the instruction actually means that a trap won't be triggered if the operation of the addition overflows). As such, any value over 0x7FFF actually performs subtraction, not addition. This explains why "retail roms add 0x00010000 to the address"

For example, NTSC 1.0's AudioSeq file starts at 00029DE0, thus the following operation will occur:
Code:
 
lui a1 0x0003 //a1 = 0x00030000
addiu a1, a1, 0x9DE0 //0x9DE0 is actually -0x6220; 0x00030000 + -0x6220 = 0x00029DE0
Derp. I didn't even notice the YYYY values were all >0x7FFF on the retail roms for that addiu, I'll fix the wording later. The Audioseq page, which I used as the source for that asm, doesn't make that point of clarification either. Just lists them as upper and lower half of the address.

Still, considering fkualol never completed a glitch free version of the Fire Temple music patch for the debug rom and I've been able to port it completely to 9 of the other OoT rom versions... it's not that bad to have the initial reasoning wrong for the asm changes. XD
Offline Profile Quote Post Goto Top
 
1 user reading this topic (1 Guest and 0 Anonymous)
ZetaBoards - Free Forum Hosting
ZetaBoards gives you all the tools to create a successful discussion community.
« Previous Topic · Modding Questions · Next Topic »
Add Reply
  • Pages:
  • 1
  • 2