ROM and RAM relation.

[Rinku]

Hello,

 

I think this question has been asked before but I couldn't find the topic, so I'm sorry.

 

So, I know the ROM is the thing I modify all the time. What relation has the RAM to the ROM?

If I take the code 811C7948 XXXX who changes the A-button size at offset 1C7948 in RAM, can I get any information from it where the A-button size is stored in ROM? I don't think so...

 

I've heard several explanations before but I didn't understand (I'm not a programmer).

 

Thank you very much!

[SoulofDeity]

Hello,

 

I think this question has been asked before but I couldn't find the topic, so I'm sorry.

 

So, I know the ROM is the thing I modify all the time. What relation has the RAM to the ROM?

If I take the code 811C7948 XXXX who changes the A-button size at offset 1C7948 in RAM, can I get any information from it where the A-button size is stored in ROM? I don't think so...

 

I've heard several explanations before but I didn't understand (I'm not a programmer).

 

Thank you very much!

 

In the rom's filesystem, each entry has both a virtual and physical address. The physical address is the location of the data in the rom, the virtual address is the location of the data in the ram. If the ram matches up, you can find the rom address that way. Keep in mind though that many entries share the same virtual addresses.

[DeathBasket]

In short, the ROM stores all the data needed for the game to run and RAM is where everything actually happens.

 

 

If I take the code 811C7948 XXXX who changes the A-button size at offset 1C7948 in RAM, can I get any information from it where the A-button size is stored in ROM? I don't think so...

 

Not directly. Since this isn't part of a file that has been loaded from the ROM, you'd have to set a breakpoint at that address to find the code that writes a value there. This would probably lead you to something that's in the game's code file ('code.zasm') which is always loaded at the same address, so you'd be able to find this in the ROM by adding/subtracting a constant value from the RAM address.

 

 

In the rom's filesystem, each entry has both a virtual and physical address. The physical address is the location of the data in the rom, the virtual address is the location of the data in the ram. If the ram matches up, you can find the rom address that way. Keep in mind though that many entries share the same virtual addresses.

 

What? Read this: http://wiki.spinout182.com/w/Zelda_64_Filesystem

[SanguinettiMods]

The interface comments are encoded in MIPS assembly in the ROM, which means you cannot find them like other data within the ROM. If you need to patch and interface code to the ROM, I suggest consulting someone like spinout or Sakura.

[SoulofDeity]

In short, the ROM stores all the data needed for the game to run and RAM is where everything actually happens.

 

 

 

 

Not directly. Since this isn't part of a file that has been loaded from the ROM, you'd have to set a breakpoint at that address to find the code that writes a value there. This would probably lead you to something that's in the game's code file ('code.zasm') which is always loaded at the same address, so you'd be able to find this in the ROM by adding/subtracting a constant value from the RAM address.

 

 

 

 

What? Read this: http://wiki.spinout1...a_64_Filesystem

 

All that does is go more in depth about what I was talking about, the physical and virtual mappings of the files in the rom. The only thing I didn't state was that some files are compressed.

[DeathBasket]

But you were saying something about the file table containing the RAM addresses of the files, which it doesn't.

[SoulofDeity]

But you were saying something about the file table containing the RAM addresses of the files, which it doesn't.

 

the virtual mappings are the RAM addresses.

[DeathBasket]

No they are not. The virtual address is where the file would be in a decompressed version of the ROM, the physical address is where the file actually is. This has nothing to do with RAM. Only the actor table (as far as I know) explicitly gives the RAM addresses for files and those are all 80800000 or higher (N64's highest RAM address with expansion pak is 807FFFFF) and are used for relocating the code so it can run properly in any area of RAM it gets loaded in to.

[SoulofDeity]

No they are not. The virtual address is where the file would be in a decompressed version of the ROM, the physical address is where the file actually is. This has nothing to do with RAM. Only the actor table (as far as I know) explicitly gives the RAM addresses for files and those are all 80800000 or higher (N64's highest RAM address with expansion pak is 807FFFFF) and are used for relocating the code so it can run properly in any area of RAM it gets loaded in to.

 

Well, then it's labelled incorrectly, it shouldn't be called a virtual mapping it should be called a decompressed mapping. When talking about binares (elf, coff, pe, etc.) virtual addresses refer the offset that the data is loaded at in ram, not where its at when uncompressed. I always assumed the virtual mappings were the offsets they were loaded at + 0x80000000 (start of ram)

[spinout]

Virtual, in this case, means where the files would be if the rom was decompressed. Decompressed ROMs have the same virtual and physical addresses for each file, except no physical end address is provided, indicating to the engine that the file is decompressed.

 

As for this topic, I once integrated the "A+C" interface to ROM. I don't know where I put the source but try applying this patch to a clean debug ROM and looking at the differences. Nemu will be your friend as far as figuring out this stuff goes.

[SoulofDeity]

Virtual, in this case, means where the files would be if the rom was decompressed. Decompressed ROMs have the same virtual and physical addresses for each file, except no physical end address is provided, indicating to the engine that the file is decompressed.

 

As for this topic, I once integrated the "A+C" interface to ROM. I don't know where I put the source but try applying this patch to a clean debug ROM and looking at the differences. Nemu will be your friend as far as figuring out this stuff goes.

 

If no one minds, I'll reword the wiki as logical mapping instead of virtual. Purpose being that logical memory is static and virtual memory is capable of being dynamically remapped.

[Jason777]

 

 

If no one minds, I'll reword the wiki as logical mapping instead of virtual. Purpose being that logical memory is static and virtual memory is capable of being dynamically remapped.

 

I'm not sure if many people would approve... Well, the ones who have gotten into the area of hacking where these terms are used. One such example where the term "virtual address" is thrown all over the place is in information regarding actors and certain areas or code within the actor.

[SoulofDeity]

I'm not sure if many people would approve... Well, the ones who have gotten into the area of hacking where these terms are used. One such example where the term "virtual address" is thrown all over the place is in information regarding actors and certain areas or code within the actor.

 

Or just word 'hack' in general. Many people fail to realize that modding is taking something you have and giving it a new purpose or use while hacking is using something in a way it was never intended and against its own laws to achieve a particular result. Idk, just a pet peeve of mine.

[Arcaith]

There are a lot of disparities in terminology used by communities like this, and they usually arise from the early days of said communities. Having said that, using logical instead of virtual would be pointless, given that the files it references are decompressed when loaded into memory therefore they change in size and location, hence the reason why two offsets are specified in the filetable.

[Rinku]

In the rom's filesystem, each entry has both a virtual and physical address. The physical address is the location of the data in the rom, the virtual address is the location of the data in the ram. If the ram matches up, you can find the rom address that way. Keep in mind though that many entries share the same virtual addresses.

 

I might have understood this explanation, but DeathBasket states it is false...

But still, thank you!

 

The interface comments are encoded in MIPS assembly in the ROM, which means you cannot find them like other data within the ROM. If you need to patch and interface code to the ROM, I suggest consulting someone like spinout or Sakura.

 

Does that mean that the interface comments are not stored in the ROM as a simple hex value, like Navi's colours would be?

 

That is really complicated (for me, of course, I guess your explanations are alright), I barely understand anything.

I wish I would have been following the Ocarina of Time hacking scene from its beginnings on (I would probably better understand if I had seen the discoveries in the right order), but I didn't know about it back then.

 

Thank you very much to you all!