Project64 Debugger

[mzxrules]

how would I define a symbol at an address like say, 80831698 (Link, called when swapping held item)?

[shygoo]

One little feature that I forgot to mention about that last snapshot. To make things easier for people using external memory scanners like Cheat Engine, I made RDRAM always allocated at 10000000 in virtual memory. So for example if you scan for a 4-byte value and its address in Cheat Engine is 1033B400, the actual N64 address would be 8033B400.

mzxrules Wrote:​
how would I define a symbol at an address like say, 80831698 (Link, called when swapping held item)?

​

Make a file: "/Save/<INTERNAL GAME NAME>.sym" with the contents "80831698,code,function_name,Link, called when swapping held item". (Descriptions may contain commas)

[mzxrules]

but how would the program know where 80831698 is in ram? Zelda 64 doesn't use TLB

[shygoo]

Oh, gotcha. I'm not familiar with this type of address mapping. Do you have any documentation on it? Or a location in the code that references/calls that 80831698 address?

[mzxrules]

The Zelda 64 engine uses overlay files. The key thing with overlays is that the files contain a relocation table that remaps code/data to some arbitrary real address at runtime (i.e. jals or similar are able to jump directly to a function, etc.). The Zelda 64 engine maintains a number of overlay tables, which keep track of where an overlay is address in ram (if it is in ram). This allows for the game to convert from virtual ram to ram if needed (though Zelda 64 rarely does this). Note that there's no consistent standard between the tables. Also note that the assigned virtual address space is greater than or equal to the size of the overlay file on rom, as some overlays allocate space for uninitialized variables.

[queueRAM]

(28-12-2016, 07:26 AM)mzxrules Wrote: but how would the program know where 80831698 is in ram? Zelda 64 doesn't use TLB

​

Most N64 games don't use the TLB or hardly make use of it at all. 0x80000000-0x9FFFFFFF (KSEG0) is directly mapped, cached RDRAM.

The programming manual describes it this way, from Basic Memory Management: "The KSEG0 address space is expected to be the most popular, if not only, address space used. In this address space, the physical memory locations corresponding to be KSEG0 address can be determined by stripping off the upper three bits of the virtual address. For example, virtual address 0x80000000 corresponds to physical address 0x0000000, and so on."

[Gamblor]

Does the debugger have the ability to place conditional breakpoints?

[shygoo]

Somewhat, but it isn't perfect yet. You could do it with a script using events.onexec() and a conditional alert() to pause emulation.

Example

Code:

​
const example_proc = 0x80370000

// pause when example_proc is called and A0 is 0x10

events.onexec(example_proc, function(){
    if(gpr.a0 == 0x10){
        alert('example_proc(0x10) called')
    }
})

[shygoo]

(28-12-2016, 10:56 PM)mzxrules Wrote: Overlay files

​

I glanced over this and if I understand correctly, this mapping is done entirely within the game and has nothing to do with hardware, right? I don't plan on supporting game-specific things but I could add some sort of pseudo-address field to accommodate. Another option would be to maintain a custom symbols table with a script that reads the specifics of the overlay system for mapping. At the moment the script API doesn't support any GUI stuff per se, but any relevant data can be sent between the game and an external program over a socket.

Example of an external gui program w/socket
https://github.com/shygoo/project64/commit/48a5e1357515302f40e0287bd6c99c18bd90bf2e#diff-85c421e96300341e1bddd673935a431f

[RobiNERD]

Shygoo, you should add functionallity for europe roms (i'm not sure if they work but paper mario doesn't)