Kodewerx https://www.kodewerx.org/forum/ |
|
[N64] The Legend of Zelda: Ocarina of Time [V1.2, U] [GS] https://www.kodewerx.org/forum/viewtopic.php?f=18&t=1178 |
Page 1 of 1 |
Author: | HyperHacker [ Tue Mar 27, 2007 6:52 pm ] |
Post subject: | [N64] The Legend of Zelda: Ocarina of Time [V1.2, U] [GS] |
Hello. Stay In Third-Person View When Using Weapons 8138C0CC 2400 When Holding Hookshot, Aiming Dot Is Always Visible 801DBB15 0001 Note: May only work in Kakariko Village. Unless otherwise specified, hookshot codes apply to the Longshot as well. Hookshot Aiming Dot Never Visible 8107C558 2400 Hookshot Aiming Dot Always Visible 8107BC88 2400 Note: With this code the aiming dot shows up even when the object is too far away to hit. Exit Weapon Aiming Mode As Soon As You Release The C Button 8138C6F4 2400 Hookshot Can Grab On To Any Surface 81001420 0800 81001422 00D0 81001424 8FBF 81001426 0014 81000340 27BD 81000342 0018 81000344 3C1B 81000346 8000 81000348 277B 8100034A 03C0 8100034C AF64 8100034E 0000 81000350 AF65 81000352 0004 81000354 3C04 81000356 1040 81000358 2484 8100035A 0019 8100035C 8845 8100035E FC9C 81000360 14A4 81000362 0006 81000364 3C04 81000366 8FA4 81000368 2484 8100036A 00CC 8100036C 8845 8100036E FCA0 81000370 14A4 81000372 0002 81000374 2400 81000378 AC40 8100037A FC9C 8100037C 8F64 8100037E 0000 81000380 03E0 81000382 0008 81000384 8F65 81000386 0004 Source: Code: ;The hookshot code gets decompressed from ROM into wherever space is available ;in RAM whenever you pull it out. Therefore it's impossible to patch the code directly ;because it keeps moving around. Instead, this hack patches the decompression routine ;to check for the sequence of instructions we want to change and patch them wherever ;they end up. It was quite a pain to make. 80001420 j 80000340 ;hook lw $ra, 0014($sp) ;moving this 80000340 addiu $sp, $sp, 0018 lui $k1, 8000 addiu $k1, $k1, 03C0 sw $a0, 0000($k1) ;Store regs sw $a1, 0004($k1) ;Check for 10400019 (instruction to be replaced) lui $a0, 1040 addiu $a0, $a0, 0019 lwl a1, FC9C($V0) ;Read the word bne $a0, $a1, end ;Check for 8FA400CC (next instruction to ensure we're editing the right data) lui $a0, 8FA4 addiu $a0, $a0, 00CC lwl a1, FCA0($V0) ;Read the word bne $a0, $a1, end nop ;Delay sw $zero, FC9C($V0) ;NOP it ;Restore regs and return end: lw $a0, 0000($k1) jr $ra ;we'd be jumping back to this instruction anyway lw $a1, 0004($k1) Hookshot Chain Length Modifier 81001420 0800 81001422 00D0 81001424 8FBF 81001426 0014 81000340 27BD 81000342 0018 81000344 3C1B 81000346 8000 81000348 277B 8100034A 03C0 8100034C AF64 8100034E 0000 81000350 AF65 81000352 0004 81000354 3C04 81000356 8FA2 81000358 2484 8100035A 0018 8100035C 8845 8100035E F58C 81000360 14A4 81000362 0008 81000364 3C04 81000366 8F28 81000368 2484 8100036A 1C44 8100036C 8845 8100036E F590 81000370 14A4 81000372 0004 81000374 2400 81000378 3C04 8100037A 2402 8100037C 2484 8100037E ???? 81000380 AC44 81000382 F58C 81000384 8F64 81000386 0000 81000388 03E0 8100038A 0008 8100038C 8F65 8100038E 0004 Note: The Longshot's default value is 0026. FFFF is about 2,521 times as long, more than enough to reach any object. (It would take about an hour for the chain to fully extend.) This works well with the "Hookshot Aiming Dot Always Visible" code. Source isn't included because it's the same as the "Hookshot Can Grab On To Any Surface" code with a few numbers swapped. Hookshot Chain Length Modifier + Grab Onto Any Surface 81001420 0800 81001422 00D0 81001424 8FBF 81001426 0014 81000340 27BD 81000342 0018 81000344 3C1B 81000346 8000 81000348 277B 8100034A 03C0 8100034C AF64 8100034E 0000 81000350 AF65 81000352 0004 81000354 3C04 81000356 8FA2 81000358 2484 8100035A 0018 8100035C 8845 8100035E F58C 81000360 14A4 81000362 0009 81000364 3C04 81000366 8F28 81000368 2484 8100036A 1C44 8100036C 8845 8100036E F590 81000370 14A4 81000372 0005 81000374 2400 81000378 3C04 8100037A 2402 8100037C 2484 8100037E ???? 81000380 AC44 81000382 F58C 81000384 AC40 81000386 FC9C 81000388 8F64 8100038A 0000 8100038C 03E0 8100038E 0008 81000390 8F65 81000392 0004 Note: The "Hookshot Can Grab On To Any Surface" and "Hookshot Chain Length Modifier" codes cannot be used together; use this instead. Source: Code: 80001420 j 80000340 ;hook lw $ra, 0014($sp) ;moving this 80000340 addiu $sp, $sp, 0018 lui $k1, 8000 addiu $k1, $k1, 03C0 sw $a0, 0000($k1) ;Store regs sw $a1, 0004($k1) ;Check for 8FA20018 (instruction to be replaced) lui $a0, 8FA2 addiu $a0, $a0, 0018 lwl a1, F58C($V0) ;Read the word bne $a0, $a1, end ;Check for 8F281C44 (next instruction to ensure we're editing the right data) lui $a0, 8F28 addiu $a0, $a0, 1C44 lwl a1, F590($V0) ;Read the word bne $a0, $a1, end nop ;Delay ;Write 2402xxxx (the chain length value) lui $a0, 2402 addiu $a0, $a0, xxxx sw $a0, F58C($V0) ;write it ;Since we must be in the right datablock, don't check before replacing the next instruction ;to make the hookshot grab anything. sw $zero, FC9C($V0) ;NOP the branch to enable hooking anything. ;Restore regs and return end: lw $a0, 0000($k1) jr $ra ;we'd be jumping back to this anyway lw $a1, 0004($k1) All Text Can Be Skipped (Very glitchy) 801D913C 0034 Text Boxes Are Empty 801D913C 0030 GS Button To Change Current Dialogue To "You got a pocket egg" Then Close It 881D913E 0007 Note: Using this in some dialogue can cause glitches or put the text sequence into an endless loop. Disable Low Health Warning Alarm (About fuckin time someone did this! ) 8006620B 002E Note: Link won't pant either. Disable Low Health Warning Alarm (Alternate) 81066210 1000 Low Health Warning Alarm Always On 81066210 2400 Horizontal Distance Between Hearts In Health Meter (default 4120) 81065EDA ???? Size Of Pulsing Heart In Health Meter (default 3F80) 81065EE2 ???? Y Position Of Pulsing Heart In Health Meter (default 42BD, lower=further from top) 81065EEA ???? Change Colour Of Health Meter 8106557C 2400 Don't Die When You Have No Health 813A0B5C 2400 Note: This routine seems to be loaded dynamically, but was in the same place in two different areas. Not to be posted on GSCentral or any other site owned or run by Rune or his associates. You know the drill. [edit] Stupid phpBB cut off my thread title. |
Author: | Dualscreenman [ Tue Mar 27, 2007 6:56 pm ] |
Post subject: | |
Hyperhacker lives! Oh, and nice codes... |
Author: | Mewy [ Wed Mar 28, 2007 4:58 am ] |
Post subject: | |
Hihi... Rune's a dog! |
Author: | tolos [ Wed Mar 28, 2007 6:23 am ] |
Post subject: | |
greetings to HyperHacker. Nice job too |
Author: | redplanet1 [ Wed Mar 28, 2007 10:26 am ] |
Post subject: | |
Neato |
Author: | Parasyte [ Wed Mar 28, 2007 11:54 am ] |
Post subject: | |
FYI, you can save an instruction by using this: Code: lui $k1, 8000
sw $a0, 03C0($k1) ;Store regs sw $a1, 03C4($k1) Then change the corresponding loads, as well. And I'm sure it would be easier to check the ROM source address on that code. It would save a few instructions also, since you would only be checking one word instead of two. Some nice work, in any case! |
Author: | HyperHacker [ Wed Mar 28, 2007 12:52 pm ] |
Post subject: | |
Ah, I missed that one. I'm not sure where the source address is kept after decompression, if anywhere, but I'll see if I can do that next time. |
Author: | HyperHacker [ Thu Nov 15, 2007 1:14 am ] |
Post subject: | Re: [N64] The Legend of Zelda: Ocarina of Time [V1.2, U] [GS] |
Kabump. Item Select (updated): Code: 81400000 0154 D01C8D74 0001 81400000 011C D01C8D74 0002 81400000 012C D01C8D74 0004 81400000 0148 D01C8D74 0008 81400000 013C D01C8D75 0020 81400000 015C D138FD90 3329 8138FD92 0040 D138FD90 3329 8138FD90 0810 81400100 3C1B 81400102 8040 81400104 976F 81400106 0000 81400108 2409 8140010A 0154 8140010C A769 8140010E 0000 81400110 036F 81400112 D821 81400114 0360 81400116 0008 81400118 3C09 8140011A 8012 8140011C 3C0F 8140011E 801D 81400120 A5E0 81400122 8D74 81400124 0810 81400126 0057 81400128 240F 8140012A 0001 8140012C 3C0F 8140012E 801D 81400130 A5E0 81400132 8D74 81400134 0810 81400136 0057 81400138 240F 8140013A FFFF 8140013C 24E7 8140013E 0018 81400140 0810 81400142 0057 81400144 240F 81400146 0001 81400148 24E7 8140014A 0018 8140014C 0810 8140014E 0057 81400150 240F 81400152 FFFF 81400154 080E 81400156 3F66 81400158 3329 8140015A FFFF 8140015C 0127 8140015E D821 81400160 9369 81400162 ACF4 81400164 012F 81400166 4821 81400168 0810 8140016A 0055 8140016C A369 8140016E ACF4 Code: ;hook 8038FD90 J 80400100 80400100 LUI $K1, 8040 LHU $T7, 0000($K1) ;Get control flag ADDIU $T1, $zero, 0154 ;to End SH $T1, 0000($K1) ;Reset control flag ADDU $K1, $K1, $T7 JR $K1 LUI $T1, 8012 ;close to item base ;increment item - flag = 011C itemup: LUI $T7, 801D SH $zero, 8D74($T7) ;clear input flags J changeitem ADDIU $T7, $zero, 0001 ;decrement item - flag = 012C itemdown: LUI $T7, 801D SH $zero, 8D74($T7) ;clear input flags J changeitem ADDIU $T7, $zero, FFFF ;increment ammo - flag = 013C ammoup: ADDIU $A3, $A3, 0018 ;to ammo base - we can trash A3, the game won't care J changeitem ADDIU $T7, $zero, 0001 ;decrement ammo - flag = 0148 ammodown: ADDIU $A3, $A3, 0018 ;to ammo base J changeitem ADDIU $T7, $zero, FFFF ;return - flag = 0154 end: J 8038FD98 ANDI $T1, $T9, FFFF ;replaced ;does the increment/decrement changeitem: ADDU $K1, $T1, $A3 ;$A3 = selected item slot LBU $T1, ACF4($K1) ADDU $T1, $T1, $T7 J end SB $T1, ACF4($K1) ;lines to write the appropriate flag (MUST BE 0154 WHEN NO BUTTONS PRESSED) ;and to apply the hook only when 8138FD90 == 3329 must be added (else other ;code will be broken by it). On the inventory screen, press Up or Down on the D-pad to adjust an item's ammo. Press Left or Right to change the item. Note, if you give yourself an item you haven't obtained yet (except Bombchu and Magic Beans), your maximum is zero, so using one will reset your ammo to zero. It's been a while, I may have forgotten one or two small optimizations, but I'm rather pleased with the trick I came up with for choosing which subroutine to run (JR). I might have been able to make it shorter (kill that big bunch of jokers at the top) if all the subroutines were the same length, but eh. Actually, looks like I could shave a few lines if I moved the hook (90?), but then I'd have to use different registers and a lot of other shit I don't feel like doing this late at night. :-/ [done.] Another code that goes well with this: D138F9C0 932C 8138F9C0 2400 D138F8E0 918D 8138F8E0 2400 D138FCD0 128C 8138FCD0 2400 D138FD2C 128C 8138FD2C 2400 D138F9C4 128C 8138F9C4 2400 Lets you select empty item slots. You still need at least one item, though, so go get that Deku Stick. (Or if you're really lazy, give yourself one using the well-known old code 8011ACF4 0000.) BTW, I noticed using item 0xFC makes Link pull out a sword, even if you don't have one. You can't use it or put it away, though. |
Author: | Hextator [ Thu Nov 15, 2007 9:16 am ] |
Post subject: | |
Bloody brilliant. How many addresses of the ones you needed to access to complete this code were you aware of last night? Did you seriously start this hack yesterday? Everyone programs faster than me ;.; |
Author: | HyperHacker [ Thu Nov 15, 2007 3:26 pm ] |
Post subject: | Re: [N64] The Legend of Zelda: Ocarina of Time [V1.2, U] [GS] |
That would be the location of the items (8011ACF4) and their ammo (immediately after that), which item slot is selected (801D96D8), a routine that runs every frame on the inventory screen (~8038FDBC, which runs ONLY on that screen to show the item name, though other code gets swapped in there at times), and of course the controller input data (801C8D74). So, all of them. Also, updated the code. You don't have to press L anymore, and the hook is a bit shorter. I put in a small hack to stop it cycling through items so fast, not sure if it'll work. It doesn't with Renegade64 because it uses a timer to write instead of hooking interrupts like the real system does. I'll test it when I find the damn power cord. >_> [edit] Forgot one: 813900E2 ???? Which item to show as a blank space in inventory (default 00FF) |
Author: | HyperHacker [ Thu Nov 15, 2007 11:02 pm ] |
Post subject: | Re: [N64] The Legend of Zelda: Ocarina of Time [V1.2, U] [GS] |
New one. Why the fuck didn't we have this option to begin with? 813A8934 2400 813AB708 2400 813ABC10 1000 813AB944 2400 Enable alphabet select on name entry screen. Also, corrected some old ones that were typo'd/inaccurate: 811C7824 000? Debug bar modifier (0=none, 1=set 1, 2=set 2) D01C8D75 0022 811E5818 0003 D01C8D75 0021 811E5818 0004 D01C8D75 0028 811E5818 0005 Name entry alphabet select Hold L and press C-Left for Katakana, C-Up for English, C-Right for Hiragana. Note that the cursor will move. Still like to make a damn opening cutscene skipper. dlong made one, but I think it was for another version. The routine doesn't even run. [edit] Few more for the night. At least helps a bit with that opening scene. 810DA626 ???? Fuck up text 2200=normal, 2100=broken, 1100=obliterated, 2300=spacing is all wrong 810DA6A0 2400 Text is invisible 810DE2C8 2400 Game hangs when trying to display text (never shows it, waits forever for it to finish) 810E0A02 0004 Strange dots appear below text 811D920A FFFF Skip text Text will appear all at once instead of letter-by-letter. It will also advance to the next page instantly in some cases, so this is probably best used with a joker code. D01C8D74 0020 801D921F 0001 Press Z to skip text delays EG the text in the opening scene that waits a few seconds before advancing; this will advance it instantly. This is some sort of control byte/frame counter. 810E1750 240E 810E1752 0001 Skip text delays for some text Be nice to find a way to skip all the delays without having to press a button. Maybe auto-advance too, so you could just leave it at the opening scene while you go get a snack or something. |
Author: | James0x57 [ Sun Nov 18, 2007 12:43 pm ] |
Post subject: | Re: [N64] The Legend of Zelda: Ocarina of Time [V1.2, U] [GS] |
Oh cool, nice find, HH. |
Author: | HyperHacker [ Sun Nov 18, 2007 3:48 pm ] |
Post subject: | Re: [N64] The Legend of Zelda: Ocarina of Time [V1.2, U] [GS] |
Actually I think I found the reason English versions don't have the alphabet select: Japanese letters show up as gibberish when playing in English. You can use the code to put it in Japanese mode, though, and it'll show up fine, even the English letters. I bet I could hack it to always use the Japanese font, which would display both English and Japanese text just fine, but it's much larger so I wonder if text would get cut off or wrapped wrong, or even the control codes and special characters might be different. Also, having the alphabet select code on will crash the game when a text box closes. I know why it does that, but preventing it would require doubling its length. Better to just turn it on, create your save file, then turn it off. (You can do this on real hardware too, or just turn it into a GS Button code. The file will still be there even if you power off before ever actually selecting it.) |
Author: | HyperHacker [ Mon Nov 19, 2007 10:25 pm ] |
Post subject: | Re: [N64] The Legend of Zelda: Ocarina of Time [V1.2, U] [GS] |
Link gets revived by a fish which then turns into a bug. More at 11. 80072CC8 Checks for bottled fairies ($A0) when you die 810722BE ???? Which item is a bottled fairy (default 0018) 810722CC 2400 Every time you die, a fairy revives you, and your first bottle is emptied 8007233C Sets the bottle to empty 8107233A ???? Which item the bottled fairy turns into 8107233C 2400 Don't lose your bottled fairies when you die |
Author: | HyperHacker [ Sun Dec 02, 2007 12:55 am ] |
Post subject: | Re: [N64] The Legend of Zelda: Ocarina of Time [V1.2, U] [GS] |
810723DC 2403 810723DE 000? A Button Icon Language (0=Japanese, 1=English) I was trying to get it to use the Japanese font, but no. I don't think it can display the English text in that font, even though it has English characters in it. [edit] Item Select works on real hardware \o/ but the hack to prevent it cycling really fast doesn't. It's not too bad though, giving myself all the items wasn't very difficult. Alphabet Select works too, I just turned it into a GS Button code and hit the button on the name screen, and bam, the icons appeared. |
Author: | HyperHacker [ Wed Dec 05, 2007 2:53 am ] |
Post subject: | Moar! |
Quadruple post, oh noes 813A0830 0810 813A0832 0001 813A0834 4408 813A0836 4000 81400004 3C1B 81400006 8040 81400008 C768 8140000A 0000 8140000C 4608 8140000E 3182 81400010 4488 81400012 4000 81400014 E606 81400016 0068 81400018 080E 8140001A 820E 8140001C 8608 8140001E 082C 81400000 ???? Multiply Link's Speed 0000: Can't move (0x) 3F00: 0.5x 3F80: 1x 4000: 2x 4040: 3x 4080: 4x (fast enough to fly off the map if you aren't careful) 4120: 10x (good for trekking across Hyrule Field, but upon leaving Lake Hylia, you'll run off the map.) 41A0: 20x (wheee!) 42C8: 100x (byebye Link! Gets you from Kakariko to Lon Lon Ranch instantly, but upon arrival, you run right off the map. ) Code: 803A0830 J 80400004 MFC1 $T0, $F8 ;save this 80400004 LUI $K1, 8040 LWC1 $F8, 0000($K1) MUL.S $F6, $F6, $F8 MTC1 $T0, $F8 ;restore it SWC1 $F6, 0068($S0) J 803A0838 LH $T0, 082C($S0) 811C778A ???? Link Acceleration (default 00C8) 810641F8 2400 Link's max running speed is slightly higher 8139F734 E609 Link's max running speed is 1/3 normal 8139F734 E608 813AC324 ???? Link's max running speed modifier (default 3E0F) The first line isn't required if you want to reduce the maximum speed. It disables a second max speed check. 3F80 is nice. Unfortunately this only applies when running, you'll slow right down when you hit water, leave ground, etc. If you use 3F80 I suggest using 0x32 for acceleration so you don't blast off like a rocket as soon as you move. 811C77C4 ???? Link Stepping Speed (default 0172) Increasing this makes him walk slower while actually still moving the same speed (moonwalk!). 8000 is really fast, fun to watch. 7FFF is little baby steps even at full speed. This game's a real bastard when it comes to handling speeds. What I have now is a hackish method, I'd really like to find the "proper" max speed variable. <_< The multiplier is nice, but you can't really move slow anymore. |
Author: | HyperHacker [ Sat May 23, 2009 8:26 pm ] |
Post subject: | Re: [N64] The Legend of Zelda: Ocarina of Time [V1.2, U] [GS] |
ffffffffffffff. I've been trying to make a hack based on the v1.0 actor spawn that, among other things, blows up any random object (by deleting it and then spawning an explosion in its place) when you Z-target it and hit a certain button. I found the actor spawn function: 80025750, works the same as other versions. It seems I have two choices when I make this hack. I can hook at 803A0C38 (the same routine the v1.0 actor spawn hooks) and have the game freeze at random for no reason whatsoever. I've looked over the code dozens of times and can see absolutely nothing wrong with it. It will just freeze after anywhere between 10 seconds and 10 minutes while the code is active, even if you just sit there doing nothing. The alternative is I can hook anywhere else and have the game only freeze when I blow shit up, because the actor spawn routine won't work when called from that location. Fuck. This is the relevant part, as it's the only part that runs if I'm sitting there doing nothing, and even that is enough to freeze. Code: 803A0C38 My code also writes the necessary pointer at 80400008. Obviously this should not have any destructive effect on the game, as the only registers affected are $V0 (the return from the original function) and $K1 (not used). I did try actually calling the original function; I don't quite remember but it either crashed right away or just didn't make a difference. The v1.0 actor spawn doesn't call it anyway and has no such problems.JAL 80400030 ;the delay slot on this just loads $A1 from the stack 80400030 LUI $K1, 8040 SW $RA, 000C($K1) SW $A3, 0010($K1) SW $A2, 0014($K1) SW $A1, 0018($K1) LW $V0, 0008($K1) ;Anything targeted? LW $V0, 0000($V0) BEQ $V0, $zero, return NOP ;...lots of code that doesn't even execute... return: ADDIU $V0, $zero, 0001 ;return 0 to run normally or 1 to be able to walk in the air :-D LW $A1, 0018($K1) LW $A2, 0014($K1) LW $RA, 000C($K1) JR $RA LW $A3, 0010($K1) The game just freezes completely at random. I see no pattern at all to it. If I hook somewhere else (say Link's behaviour or rendering code) the random freezes seem to stop, but the actor spawn doesn't work. This also has a second annoying glitch. If I spawn an explosion (which is really just spawning a bomb and setting the fuse timer to almost 0), and I haven't yet pulled out a bomb in that area, it freezes. It would suggest the game doesn't load the bomb code this way. Yet the v1.0 actor spawn doesn't have this problem. What's the difference? It does the same damn thing! |
Author: | Parasyte [ Sun May 24, 2009 10:22 am ] |
Post subject: | Re: [N64] The Legend of Zelda: Ocarina of Time [V1.2, U] [GS] |
Have you tried opening the exception handler displays ("debug menu") when it freezes? What about hooking the exception handler? The exception contexts for MIPS are well documented, it shouldn't take much to dump the info by hand (or write a code that does it for you...) It really sounds like a problem with thread-safety. |
Author: | HyperHacker [ Sun May 24, 2009 3:26 pm ] |
Post subject: | Re: [N64] The Legend of Zelda: Ocarina of Time [V1.2, U] [GS] |
Hooking the exception handler might work, but where would I find it? I was doing this in Mupen, which like most emulators can't display the crash screen for some reason. Apparently it wasn't freezing when Hex tried it though, so maybe Mupen just fails. It's been giving me a lot of grief lately for some reason. |
Author: | Parasyte [ Sun May 24, 2009 10:00 pm ] |
Post subject: | Re: [N64] The Legend of Zelda: Ocarina of Time [V1.2, U] [GS] |
According to the r4300i datasheet, the exception vector lies at 0x80000180. That would be a good place to start, I imagine. Probably the reason emulators won't open the exception menu is because they don't emulate N64 very well. I would be impressed if any of them even bother to emulate exception handling, since they seem so content to live with their shitty "HLE" paradigm. |
Author: | Hextator [ Mon May 25, 2009 2:28 pm ] |
Post subject: | |
^ Which is a bother for TLB misses in GoldenEye, preventing any good code testing from occurring. I believe that was the true reason the code wasn't crashing for me, by the way. I don't trust PJ64's exception emulation. Also, about the exception vector - hooking ASM codes at the address jumped to from that vector is a great way to write codes that execute every frame, but I'm not sure it works with the GameShark as I believe I've read that the GameShark engine is hooked the same way. Because of that, lots of my codes for certain games, in addition to the fact that they usually rely on the expansion pak, are very limited in their scope of usability. C'est la vie. :/ Edit: Are you sure that 0x80000180 isn't some interrupt handler? I thought we agreed that the exception vector was held in one of the COP0 registers? You had me playing with it before. Here's the relevant code: Code: ;TLB overwrite test
;Doesn't assemble right in Renegade >.> 80000004 J 80400040 ;K1 is free 80400040 LUI K1, $8040 ;Stack gen, lol :D SW V0, $0000 (K1) SW V1, $0004 (K1) MFC0 V0, EPC SW V0, $0008 (K1) LI V0, ExceptionHandle MTC0 V0, EPC LUI V0, $7F06 LUI V1, $E444 ADDIU V1, V1, $0FF0 SW V1, $7CCC (V0) ExceptionReturn: LW V0, $0008 (K1) MTC0 V0, EPC LW V0, $0000 (K1) J 8000000C LW V1, $0004 (K1) ExceptionHandle: MFC0 V0, Status SRL V0, V0, $4 J ExceptionReturn MTC0 V0, Status |
Author: | Parasyte [ Mon May 25, 2009 5:27 pm ] |
Post subject: | Re: [N64] The Legend of Zelda: Ocarina of Time [V1.2, U] [GS] |
I'm not sure what you're taking about. COP0 registers contain a lot of information about why an exception has occurred, but they don't control where the exception vector lies. (The "vector" is the address where the CPU will "jump" to when an exception occurs.) For the record, non-maskable interrupts (NMIs) are exceptions. See the datasheet for more info (in other words, RTFM). |
Author: | Hextator [ Tue May 26, 2009 11:46 am ] |
Post subject: | |
Parasyte wrote: I'm not sure what you're taking about. COP0 registers contain a lot of information about why an exception has occurred, but they don't control where the exception vector lies. (The "vector" is the address where the CPU will "jump" to when an exception occurs.) If I recall you said something about EPC, which I thought was short for "error PC" was a register holding the exception vector (which is like, never 0x80000180). But if you're saying it's not, now, I guess...it's not. I indeed haven't "RTFM". For the record, non-maskable interrupts (NMIs) are exceptions. See the datasheet for more info (in other words, RTFM).[/quote] This was just me avoiding a technicality to point out a distinction. Excuse me. Though I suppose it reinforces the idea that 0x80000180 is indeed the exception vector. |
Author: | Parasyte [ Tue May 26, 2009 4:25 pm ] |
Post subject: | Re: |
Zeld wrote: If I recall you said something about EPC, which I thought was short for "error PC" was a register holding the exception vector (which is like, never 0x80000180). But if you're saying it's not, now, I guess...it's not. I indeed haven't "RTFM". EPC contains the "cause address" of an exception. That means, if an illegal instruction was executed at address 0x80012344, then EPC would contain 0x80012344, and CPU would begin executing the exception handler, which means... the exception vector! 0x80000180. Exception vector: Where the CPU goes to handle an exception. Error PC: Indicates where the exception occurred. Technically, there are also other registers in COP0 which can help to tell you why an exception occurred, and what the problem was. But it's still the code at the exception vector which must handle the exception. "Handling" the exception means handling virtual memory misses (perform MMU page swapping), handling breakpoints and traps, divisions by zero, or even panicking to hang the system -- which might attempt to spew a load of debug info to a developer console or (in the case of games like Legend of Zelda) wait for the user to press a key combination to open a list of data pages containing a load of debug info spewed earlier by the handler. |
Author: | HyperHacker [ Tue May 26, 2009 4:47 pm ] |
Post subject: | Re: [N64] The Legend of Zelda: Ocarina of Time [V1.2, U] [GS] |
Hm, so could you hack the exception handler to just make some attempt to resolve the situation (e.g. x/0=some huge value, all unmapped memory reads 0, etc) and return to the code? That might be useful for exploring beta content in games that crashes because of some invalid/uninitialized value, by just ignoring it. |
Author: | Parasyte [ Tue May 26, 2009 6:03 pm ] |
Post subject: | Re: [N64] The Legend of Zelda: Ocarina of Time [V1.2, U] [GS] |
Yes. That is what exception handlers are meant to do. |
Author: | Hextator [ Wed May 27, 2009 8:39 am ] |
Post subject: | |
I know what an exception vector is! Geez. I know how to modify them on the DS, too. We even discussed setting them for using bkpt instructions in place of "suspicious" instructions for coding a software debugging system (since the mov pc idea only worked in some cases and definitely wasn't any good for Thumb mode). That may have been the confusion. Since the DS lets you modify the exception vectors I guess I assumed the N64 had a system for that. Also, yeah, try {/*stuff*/} catch (Exception e) {/*nothin'*/} is very useful. |
Author: | Parasyte [ Wed May 27, 2009 4:41 pm ] |
Post subject: | Re: [N64] The Legend of Zelda: Ocarina of Time [V1.2, U] [GS] |
Exception vectors cannot be changed on NDS. The vectors lie within the BIOS, which forwards the CPU to a handler which can be set programmatically. That may be what you're thinking of. |
Author: | 47iscool [ Sat Sep 13, 2014 9:06 pm ] |
Post subject: | Re: [N64] The Legend of Zelda: Ocarina of Time [V1.2, U] [GS |
Not trying to copy you HyperHacker, but check this out, an ASM hookshot code: http://gamehacking.org/vb/threads/9321- ... #post82598 |
Page 1 of 1 | All times are UTC - 8 hours [ DST ] |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |