Vexiant

There should be a lot of zero's, and it very well may not be so with Quest 64. I know it's not with SM64. Sorry for the discrepancy as it's normally the case with most games. I'm currently extremely busy, so I'll just share this pastebin with you taken from the WIP .blank n64 hacking wiki: http://pastebin.com/TbEQw9Vr Hopefully it's of some avail.

I'm currently without internet at my house, but I'll get around to looking into it

Interesting indeed. I've neglected to look into the project, but I have started to take up programming outside of low-level MIPS in recent times. I'm rather busy though, so I don't think I'd be the one to take up such a project. Perhaps someone will though

Since I'm not capable of creating a topic in the "Tutorials" forum, I'll drop this here. I'm sure you've heard of searching for identical hex data to locate where a RAM address is in ROM. Well, I'm here to give you an even more informative rundown! The above method is viable most of the time, but you can of course potentially encounter an identical instance. Base 16 (hexadecimal) is just a form of a less legible binary pattern to preform an action in comparison to MIPS after all (say that because identical events can sometimes be common between games). Moreover, the Nintendo 64 OS doesn't impose any default locations when it comes to where a code or data segment is located and this includes the main heap (arbitrarily allocated data), how many "threads" there are (one stack per thread. e.g. Ocarina of Time has four iirc) or anything in relation to memory management. With that said, some games also utilize the main CPU's (VR4300) memory management unit's (MMU) translation lookaside buffer (TLB). Some games will make use of this depending on their addressing mode or kernel user mode (all of Rare's games) and it can be a total pain when it comes to reverse engineering games or trying to type up assembly codes for 'em. With the above said, I shall supply you with a tutorial that can be used on most Nintendo 64 games to trace RAM to ROM as long as it's within a code segment! Locating RAM to ROM (and vise versa): I will also go into detail about how to locate the start and end of the code segment in ROM! Note: Not all Nintendo 64 games use the same "code" file (again, as noted above). Nonetheless, "standard" functions are always in lower memory. By "standard functions," I mean functions that are within the code/text segment's within RAM. As stated in the "Memory Segment" category, things in higher memory are almost always arbitrarily located as well as mapped there through the TLB which makes it incredibly difficult to trace back to ROM. Locating the start and end of a code segment >To locate the start of the code/text segment's in RAM, you can do this one of two ways: 1.) If you're using Nemu64, you can utilize the "Show Rom Info" option I spoke of above to obtain the RAM entry point, breakpoint the address (which is a pointer) of the entry point and it will take you to where the standard (libultra) functions start! 2.) Moreover, you can open the ROM of your choice in a hex editor and navigate only 0x8 bytes in and copy the word found there. (A word is 32-bits long XX XX XX XX) >To locate the end of the code/text segment's in RAM: First, as also explained below, open a hex editor of your choice and navigate to 0x1000 and scroll down until the machine code ends, and take note of the address that it ends on as that is the end offset of the standard functions. Then: (End offset in ROM + RAM entry point) - 0x1000 >To trace a target RAM address from a MIPS JAL instruction in this segment: Discovered RAM Address = (JAL instruction & 0xffffff) << 2 (Discovered RAM Address - RAM entry point) + 0x1000 "&" is a bitwise AND "<<" is also a bitwise operator for left shift (A quick search with your favorite search engine would suffice in relation to more information!) Method to locating alternative code segments >In order to locate a game's compiled main.c file, open up a hex editor and search for the ASCII text "RSP Gfx" as all ROMS have that string to specify what Microcode Library the game uses. If the game has a file table, then the ROM search will put you between the start and end address of a file table entry. That string is always found in the main code segment! >If you've located the code segment, record the start address of it from the file table. Then, you must determine the RAM start address. See the tutorial on this page for methods. >To get the RAM end address, simply subtract the start address from the ROM's file table from the end address from the ROM's file table. Then, add the difference to the RAM start address. >If you have the ROM start address, RAM start address, and RAM end address, and have discovered code/text in RAM within the segment: (Discovered RAM Address - code segment RAM start address) + code segment ROM start address >To locate ROM to RAM, just swap RAM for ROM in the equation above: (Discovered ROM Address - code segment ROM start address) + code segment RAM start address Note: I've only noticed yaz0 games having file tables, and the ones outside of that that also had them are: Super Smash Bros and Star Fox 64. You can locate virtual addresses locations in ROM, but hence "virtual," you'd have to locate where they're loaded from. It's a whole complex process in itself though. The above method will suffice for now! I hope to see some conversions and mods soon! :3 As noted, you can do this for other games too. The PointBlank (.blank) community I'm apart of and have been apart of for six years now will have a Nintendo 64 hacking wiki soon. There you will find VERY useful tutorials and general guides for hacking. It will be released at the start of February. It will include data archives for various games as well, so you guys will more than likely enjoy that! Cheers, and happy hacking!

Well it was, subjectively, entirely his fault. I say subjectively as he can argue his case (read: He was starting fights with people often for trivial reasons). Anyway, that's enough discussion pertaining to personal matters as that's none of our business. Not even mine since I wasn't a victim of stated/accused actions.

Well, he left due to conflict with other scene members. Had that not happened, he'd probably still be working on it.

Yeah, hacking retro games are always fun, and easier than newer consoles. I have a little type up for individuals interested in hacking Nintendo 64 games. It mostly serves as a synopsis for why corruption isn't a viable method when it comes to N64 reverse engineering. Hehe, sorry for being off-topic, but any posts/activity on these message boards is very much in need at this point.

I'm definitely bumping this. He's removed the download and I seemingly neglected to save it, as I did download it initially. I really hope someone has it!

I beat Rayman 2: The Great Escape recently. I've known about it for years, though. I used to play it on a Dreamcast sampler disk called "Generator" as a demo (same as Sonic Adventure until I got it like two years later, lol). It's easily one of the most underrated Nintendo 64 games! Maybe sometime I'll write up some interesting, superfluous GameShark codes for it.

Falllout 4 is great! I can't wait until Bethesda releases their next Elder Scrolls game too

It's a good game, man. I'm surprised you haven't played it before!

Looking for a good hook, huh? http://doc.kodewerx.org/documents/r4300i_datasheet.pdf(Page 18) The GameShark hooks in a similar location, as noted near the bottom of this excerpt. Let me give you a rundown pertaining to what's around said address where the GameShark hooks to: "0x80000400 (physical address 0x400) is by default the boot location. All R4xxx series processors uses the first 0x200 of RAM for exception handlers. The first 0x400 of physical memory contains the Interrupt Vector Table (and first 0x180 are the Processor Exception Vectors) and configuration parameters. The "interrupt vector table" is a data structure that associates a list of interrupt handlers with a list of interrupt requests. Put simply, an interrupt and exception handler both alter program flow. Interrupts handle external event, e.g. cartridge issue (peripheral interrupt), Pre-nmi (reset type), etc. Exceptions handle instruction faults, e.g. dividing by zero, etc. One thing to note about interrupts and exceptions with the Nintendo 64 that the R4300i architecture doesn't distinguish between them as there's essentially a single handler for them and the two merely have unique masks. However, in applications outside of this situation, they have individual handlers. Along with that, the CIC chip can relocate the boot location/entry point (which I linked to information relating to this initially at the top of this category). You can locate the start of the code segment by going to 0x8 (a word long) in any Nintendo 64 ROM, copying the address and breakpointing (linebreaking) it (as explained further down the page). The word found there is a pointer to the start of the real game code (Where memory officially starts). Everything before that is pretty much bootstrapping related and is for the most part, the same between games. For games that make use of the 64DD keep a copy of the original disk's disk header at 800001A0 for reference. Exception Vectors Four exceptions are hardcoded to specific addresses: 0x80000000 is for TLB miss, 0x80000080 XTLB miss (64-bit), 0x80000100 for cache errors, and 0x80000180 for general exceptions (including caught interrupts). In addition to 0x80000180 the exception vector is here and can be used as a place to hook (to execute every frame) for Nintendo 64 GameShark codes ( made in assemby). However, a con to that is your code probably won't work on an actual GameShark as it hooks with a similar method (described below). In practice these are all just redirects to the general exception handler. Just a note about the exceptions: COP0 says why an exception occurs at a given point in time, but the vector table is the address where the CPU will jump to when said exception occurs/where the CPU goes to handle an exception. Speaking of which, the GameShark works by relocating the general exception handler to 0xA0000120 (uncached memory) and hooking GameShark utilities into the "regular" general exception handler at 0xA0000180 during which point in the execution path, a "code generator" gets executed. The code generator is basically an engine made up of instructions which act on behalf of GameShark codes, usually to make data at an address be written with a chosen value over and over again every time an interrupt occurs. Note, the GameShark writes to both cacheable and non-cachable memory (For a better understanding, read "CPU Addressing above")." Those excerpts are taken from a Nintendo 64 hacking wiki that is currently in the works. In conclusion, you can use 0x80000180, however your code probably won't work on an actual GS due to identical hooking methods (the GS overwriting your hook). I know Jason777 uses osWriteBackDCacheAll which seems to work great for him. For OoT 1.0 hooks, I shall direct you here: http://cloudmodding.com/zelda/oot

woah

hot

Bump. Quit being lazy, Nock