PDA

View Full Version : Re: retroben's random new GS codes topic


HatCat
25th December 2013, 01:25 AM
Edit:I am only half right.
You are still utilizing information from a save file to get the end-result GS code.
Not to start a fight,(we are all friends here,right?) LOL rhyming
Would you want someone else posting three pages of back-and -forth replies in your topic.
I should just rename this topic to "retroben and friends' random new GS codes" for anyone to use,just to stop the arguing.
It is the holidays after all.

Something like that.

ok, new thread, now no more distractions! :D

HatCat
25th December 2013, 01:28 AM
BatCat, are you 100% sure that you posted the correct offset and value for heart piece #5? I'm curious how you determine where the heart piece data is stored in the save file.

One problem I have is that when I make 2 save files, there's quite a few differences for some reason, so it's somewhat difficult to figure out the correct location and value for the heart pieces.

I use HxD like you only I use the File Compare feature to look at the bytes side-by-side.

Yes, many other bytes besides the heart piece bit we're looking for also change whenever we save with the Song of Time, but I know more than enough about the MM save file at this point to dismiss which ones are crap (like the exact time of the day you saved the game, inventory equipment, generally anything before 0x200 in the save file).

I'm re-checking it currently.
My problem is that I have the Bombers' Notebook collected, and when you help hand-down-my-pants-in-the-toilet out the save file also sets those bits, which unfortunately are very close to the heart piece.
I'm still double-checking to make absolute sure I gave you the right offset.

HatCat
25th December 2013, 01:40 AM
Yes RPGMaster, I just finished re-checking and I AM absolutely sure that the 0xF42 offset into the FLASHRAM save file I gave you is correct.

Of course, Project64 falsely writes flashram as little-endian.
The byte order is wrong. Once buffered into RDRAM, it should really be 0xF42 ^ 0x003, or 0xF41, not 0xF42.


How do I know that my information is correct?
Because I collected this heart piece, saved with the Song of Time, checked the differences between the old flashram and the new one, saw that 0xF42 was masked in with |= 0x08, deleted the byte from 0x08 to 0x00, updated the checksum by hand, saved changes to the flashram, loaded the game up, tried to collect the heart piece from him a second time, he gave it to me a second time, which proves that my change made the game forget that I'd ever collected the heart piece from him.

RPGMaster
25th December 2013, 01:50 AM
The reason I asked is that I tried checking for a value change and couldn't find an address that lets me see the hand again.

Good idea about the editing save file thing. Idk why I keep forgetting useful methods -_-. I wish there was a way to debug the game and set a breakpoint on the save file itself lol. I'll keep trying the value search. I may have skipped a few things.

I'm going to try to check another heart piece that you have to physically touch. I'm guessing the reason it's different is because of the method of obtaining it lol.

HatCat
25th December 2013, 03:39 AM
If you do try editing the save file as I do, you must be very careful. I personally do the 16-bit checksum by hand or mentally in my head, but for you to do it manually requires an understanding of endianness at the very least. If you can, use my save editor with an empty argument/requests list to correct the checksum of the save file after bit-hacking it yourself.

If the checksum is wrong then your changes to the save data will all be discarded.

And I'm not sure that the hand popping in and out back again, has anything to do with the heart piece bit. Remember, if you already have the heart piece from giving him paper, he will still come out if you reset back to day 1 and give you 5 rupees instead. Controlling whether or not he ever comes out again is a different matter.

RPGMaster
25th December 2013, 04:48 AM
Rofl that would explain my hours of confusion yesterday with editing the save file by hand. I was wondering why my changes weren't working LOL.

Well, I guess I did something wrong then because I never saw him appear again. That gives me some hope :) .

You think theres a way to set a breakpoint in a debugger when the game is saving to the save file?

HatCat
25th December 2013, 06:20 PM
Haha, sorry for the late reply as I was kind of all tied up in something last night.

But I have no idea, because I've never once set a breakpoint.
I never even learned what a breakpoint is.

I sort of ended up, gradually understanding it over time tho, seeing examples and implementing some of the dynamics in the BREAK opcode on the RSP. So I get why it's useful for debugging; I just have no experience in using them.

come to think of it tho, what you asked, I think somebody did implement that in pj 1.6 source

RPGMaster
25th December 2013, 07:18 PM
No problem. I guess I'll start with using cheat engine's debugger. I still got a few ideas to try out. Thanks for the tip on using your save editor to fix the checksum. That should come in handy later on :) .

What emulator has the best debugger? I usually just use Nemu for debugging. I never bothered trying to use Pj64's debugger. Problem with Nemu's debugger is I can't set a breakpoint on things that get or set values to or from the rom or save file. I think the term is DMA, but I could be wrong lol. That's why I'm going to try out cheat engine's debugger. If I'm able to debug the file i/o process, then this would be much easier.

HatCat
25th December 2013, 07:58 PM
I usually have only used either the integrated debugger in Project64 1.7+ or Renegade64 to attach and hook to an emulator externally and debug RDRAM that way, but yes Nemu64 has the better debugging apparatus.

I'm not sure there is a way to set breakpoints in Project64 for finding codes, but, don't take my word for that either.

RPGMaster
25th December 2013, 08:25 PM
I think I'm on the right track, although it's a very slow method. Is there a memory location for the save file? What I mean is, would I be able to access it with a memory editor or debugger? So far, I tried setting a breakpoint on the address for heart piece #0 and #1. When I select one of my files in game, it loads a 4 byte value from some strange area of memory. It seems like that same address for the 4 byte value loads data from the sra, but it would probably take a long time since it's loading other values as well :( .

We will need to learn more about file i/o unless we find another way to find the address.

HatCat
25th December 2013, 10:14 PM
Is there a memory location for the save file? What I mean is, would I be able to access it with a memory editor or debugger?

&RDRAM[0x1EF670] is the entry point to the game's memory where the save file will be buffered into (as well as updated while playing the game in real-time). However, it probably only stores the old heart piece values and never updates those while the game is playing.

It's tricky, tho, cause the byte order is mixed after loading it from the *.FLA file into RDRAM. ...0x000 becomes ....0x003, ...0x008 becomes ...0x00B, ...0x009 becomes ...0x00A, ...0x00F becomes ...0x00C ... you need to flip the order of bytes every 32-bit word for the addresses in little-endian which I provided you, or do XOR by 03.

RPGMaster
25th December 2013, 10:36 PM
Alright thanks. Lol ya, the byte order confuses me, when it comes to searching for values. That's why I end up just searching 1 byte instead of a 4 byte value. I really should write down everything important that I've tested/ learned. I forgot that setting a breakpoint on the heart piece location (before loading the save) can give me clues. I believe I found the area of memory that loads data from the save file.

When I looked at 80507a00 through 80507B8C, i saw data that looked like the data in the .fla file. Let me know what you think.

Edit: Found it. It's 801F05B1 for Heart Piece #5. I'm going to have to write down every useful technique I've learned -__-. Out of curiosity, how did you find out about the save file checksum? It's actually very useful to know detailed information about save data. It saves a lot of time to be able to quickly change save file data.

HatCat
26th December 2013, 12:41 AM
Yes, there are other copies of the save file in the RDRAM, but they are sometimes built-in saves or backup copies. The one I gave you is the "real" one that gets updated in real-time as you play.

Edit: Found it. It's 801F05B1 for Heart Piece #5. I'm going to have to write down every useful technique I've learned -__-.

So is 1F05B1 a temporary buffer for copying from to an external byte when you leave the place with the heart piece, or is it the byte where a temporary buffer writes TO to remember the heart piece value?

Out of curiosity, how did you find out about the save file checksum? It's actually very useful to know detailed information about save data. It saves a lot of time to be able to quickly change save file data.

I found out about the 16-bit checksum through simple logical conjecture.
Before I knew even the very first thing about the Zelda MM save file, I had to conclude that it was divided into 8K chunks of save buffers.
Then, I had to look at before-after comparisions when changing small amounts of data.

Eventually, I realized that *(file_block + 0x100A), in big-endian addressing, was the starting point of the 16-bit checksum, which I realized on my own through trial and error had the general pattern of adding up the values of all of the bytes before it within that current save file block.
(I had already learned about very basic checksums from the Super Mario 64 save editor I wrote.)

RPGMaster
26th December 2013, 07:09 AM
I believe that certain heart pieces have a different method. While struggling to find the address, I remembered that I debugged save data in SSB64, so I debug either Heart Piece #0 or #1 (lol I forgot which 1 .___. ) and it eventually led me to 80507a00 through 80507B8C which had the save data. Save data is directly loaded to that area. For heart piece #1, the game copied the data to multiple areas, but for heart piece #5, it only copied to 1 location [801F05B1]. I believe there is no temporary buffer for those type of heart pieces, but i could be wrong. It loaded the 08 when I started playing on the file. I will double check later. Save data seems like a useful thing for me to learn.

Now all we need to do is find all the heart pieces in the fla file, then I'll find the RDRAM location for each one. I wonder why no one has done this before. Is there a speed hack code that doesn't use a button activator code? If not I'll make one myself. I don't get why there aren't more unique codes. In OOT I couldn't even find unbreakable deku stick code, so I made my own code lol.

HatCat
26th December 2013, 09:12 PM
Unbreakable deku stick...heh, I never thought about making that one.
They are pretty effective weapons, after all. Maybe not as powerful as the Great Fairy's Sword in MM, but in OOT, a jump attack with those things is almost always instant KO.

And I don't know why I'm the first person to do this.
I guess going through all 52 heart pieces all over again and comparing the values intensively to mine out the heart piece bits seemed too frustrating, trivial and un-rewarding to most people...but I really need this research to get done so I can build an app that detects which heart pieces are missing so we don't have to go back through all 52 of them to remember which one we forgot through annoying trial and error. :D

I don't recommend getting HPs like the Inn Toilet one anymore.
It's too annoying to debug / see whether it's been collected yet or not.

How about you get the visible one on The Moon in the Deku dungeon?
I'll give you the code to warp there that I made myself a few years back:


803FF39A 00?? // == 004E for Deku dungeon on the moon
883FF395 0014


Press the GS button (in Project64, F9) to warp to the moon.

Use Press L to Levitate or something to fly all the way over to the heart piece at the end of the dungeon.

RPGMaster
26th December 2013, 09:23 PM
Alright, I'll go try out the moon one. I'm pretty sure I fully understand the toilet inn heart piece though. I hate how buggy the game is when you use codes to unlock items. I was trying to figure out why I lose all ammo after shooting 1 arrow. I know a ghetto fix, but I forgot how I fixed this problem in OOT -___-.

Also by any chance do you know a code to allow me to use Fierce Diety Link anywhere, without weird glitches like c button items and heart pieces looking more transparent?

I'm going to also take a quick look at the west bank heart piece as well. It's fun making new codes. Today I've been working on changing the physics, I found run speed data, now I'm going to see how to change rolling and maybe jumping too. Climbing was too hard for me to hack ;/.

retroben
26th December 2013, 09:37 PM
I could try to find the HUD codes for transparency.

If you want to see something pretty awesome,there is an OOT hack that replaces Link with a Sonic model.

It also uses Gameshark codes for rolling and high speed.
I have seen a video of it in hilarious action.
There is more than one mod with Sonic in OOT.

The URL letters are ridiculous.

Since URL posting is tedious.
Go to YouTube,and place "watch?v=TrySshF4eVs" in the YouTube URL for the video.

I think you should Try Ssh F 4eVs. :D

HatCat
26th December 2013, 09:58 PM
The "Play As" modifier cheat that cames with Project64 should let you play as Fierce Deity Link if you think it will help.

RPGMaster
26th December 2013, 10:19 PM
I could try to find the HUD codes for transparency.

If you want to see something pretty awesome,there is an OOT hack that replaces Link with a Sonic model.

It also uses Gameshark codes for rolling and high speed.
I have seen a video of it in hilarious action.
There is more than one mod with Sonic in OOT.
Lol nice. Looks fun

The "Play As" modifier cheat that cames with Project64 should let you play as Fierce Deity Link if you think it will help.
I just want the code for fun lol. Thanks for the suggestion, I'll try it out. I keep forgetting that I wasn't using the default cheat list.

Here is unbreakable deku stick code, 8075D3F2 0030.

Now time for me to take a break from making game changing codes.
I went to the moon to get that heart piece, it used the same 4 byte buffer [803E8994], and it saves to 801F3933 . Lol now this is easier & faster than finding the save file location. I'll go check out the West Bank heart piece now.
YO that teleport code you made is sick! I'm lovin it. How did you even find this out?

retroben
26th December 2013, 10:49 PM
I enable use items anywhere to make Fierce Deity's mask work.

I ALREADY FOUND THE CODES!

It is part of the "no interface" code from glitchkill posted by punk7890*trademark icon*,an administrator of the site.

Majora's Mask (U)

Fierce Deity HUD Fix
803FD76F 00FF
803FD771 00FF
803FD773 00FF
803FD775 00FF
803FD777 00FF
803FD779 00FF
803FD77B 00FF
803FD77D 00FF
803FD77F 00FF
Only problem is when in fierce deity form,the three item slots x3,x5,x7 are still faded from being constantly updated to 46 in hex.
They are not faded when not Fierce Deity.
One side-effect is that the HUD is visible more often now (during mask transformations).

Also,don't use the giant's mask because you will get stuck.

I just thought of an awesome code idea.
Wear Majora's Mask!

Edit:The HUD is even visible while changing areas.

If you don't like the items flickering like a dying light bulb,disable the code for the duration of being fierce deity.
Or add the three lines as a seperate code.

HatCat
26th December 2013, 11:26 PM
I went to the moon to get that heart piece, it used the same 4 byte buffer [803E8994], and it saves to 801F3933 . Lol now this is easier & faster than finding the save file location. I'll go check out the West Bank heart piece now.

Ah, this is interesting!
You said 803E8994 is used for this Moon dungeon heart piece.
But 803E8996 is used for the North/South Clock Town heart pieces. I sense maybe there is a way to quickly debug all 52 heart pieces....

YO that teleport code you made is sick! I'm lovin it. How did you even find this out?

What I would do for most games is use memory search/compare every time I change worlds, but that's normally a lot harder than it sounds.
It may have been based on an existing cheat code with Project64.

However, what I did was plug in all 256 possible values for this byte, and hack out all the reachable world maps in the game.
The total results I've recorded on how you can warp to where, I recorded here:
http://forum.pj64-emu.com/showthread.php?t=1260

RPGMaster
27th December 2013, 01:12 AM
When I said, 803E8994, i meant that it's in that 4 byte area. If the value is 00080000 in big endian, then the address for the specific byte is at 803E8995. So what I did was just add (803E8994 + the emulator offset) as a 4 byte and display as hex in cheat engine. Lol I wish pj64 had static addresses, so that I wouldn't need to use pointers in a simple cheat engine table. What I say static addresses, I'm just talking about how everytime I reset my computer, the offset changes. I don't even mean the in game pointers, like how different stages may have different addresses. As I predicted, it seems like you can easily debug any heart piece that you can touch. The ones that are given to you by other people work differently. I don't even have to leave the area to get another heart piece, if I make the flag = 0.

Idk why I have a hard time getting the save file location for each heart piece. What I do is I make a save state right before I collect the heart piece. Then I do song of time, then make a backup copy of updated save file. I load the savestate I just made. Then I grab the heart piece and do the song again. Then I compare the 2 in HxD and I couldn't even find the 02 value for that moon heartpiece, but I did only try to look for like 2-3 mins.

When it comes to teleport, I wouldn't even begin to know what to look for in memory editor. You saved me a lot of work though :) .

@Retroben, thanks for the codes, I'll check them out.

Edit: I messed around and fought Odolwa. It was fun giving him extra HP, while I'm using fierce diety link. After I killed him and took the heart container, I noticed it used the same 4 byte buffer.

HatCat
27th December 2013, 04:07 AM
Awesome! So the heart containers share the same buffer address as the heart pieces you found so far do?

This makes it tremendously easier to quickly analyze the offsets for the remaining 52 heart pieces.
Mind you, I do happen to be working on a sort of separate emulation project right now, not related to the save in Zelda MM, but this stuff will definitely accelerate the product.

RPGMaster
27th December 2013, 04:18 AM
Ya my theory seems to be correct about the method depending on how you obtain it. I tried the west bank one, and I had to do the same thing I did with the Heart Piece #5. Basically all I have to do for ones where you grab the heart piece/container, I just get it, then set a reading breakpoint on the 4 byte buffer address, then I leave the area and the breakpoint activates.

For the other type of heart pieces, I have to just look it up in memory editor, and if I can't find it, then i have to find the value and location in the save file, then set a reading breakpoint while loading the game file.
Lol sometimes I have a habit of not writing things down. I'm curious about your project :) . What game is it for?

HatCat
27th December 2013, 04:37 AM
Probably all of them, granted it being a virtual machine and whatnot.

So, maybe if you used that seemingly unanimous buffer writeback address you found for the West Clock Town bank heart piece, that would control it too? (Of course you'd have to know which bit offset it is masked in the 8-bit pair, but that's in the present notes of my research anyway.)

RPGMaster
27th December 2013, 05:44 AM
It looks like the fla data is loaded in order in RDRAM. I was looking at 80507A00 and it matched 0xE60 in the save file location. So basically, 80506BA0 is the offset of the FLA data location into RDRAM where the game first loads the data. Then all you do is set a reading breakpoint on the save data location + offset to find where the important address is for certain heart pieces. I hope I explained it well enough, I have a tendency to do a bad job explaining things.

I set a reading breakpoint on 80507AD0 (you can only breakpoint in 4 bytes with Nemu unfortunately), then saw that it stores the value into 801F05A3, so that's the RDRAM address for the West Bank heart piece.

HatCat
27th December 2013, 06:54 PM
Maybe the save data gets loaded to there like you said, but the real-time updates to it whilst buffered into RAM should be still at 0x1EF670.

So maybe the other entry point for the flashram you found is where the backup data is of the unmodified FLA save file. That's an interesting piece to compare to...guess that was worth presuming on my part I have to say.

RPGMaster
27th December 2013, 07:54 PM
Lol ya you're right. I just realised that 1EF670 + 0xF30 = the 4 byte area for west bank heart piece.