Project64 Debugger « 1 2 3 4 »
Users browsing this thread: Pilzinsel64, 1 Guest(s)

Snapshot 3

Memory breakpoints can be managed from the Memory window by right-clicking values
Individual scripts are now stored in "/Scripts"
The API script is now compiled into the binary
Scripts can be run from the Scripts window by double clicking them
Symbols window is somewhat functional

Some additions in this snapshot are half-baked but I figured I'd put something up right now because it's been a while since the last update and having convenient memory breakpoints is important.

Memory breakpoints

[Image: 12cf27ae6b8fab656ee99c036e7b2e5e.png]

Much better now! Big Grin


[Image: a857e4cd31b1fb4e1e894dc8978f2ce9.png]

Double-clicking a script name in the list runs a script in its own thread. Yellow means initialising, and green means the event loop is running and events are waiting to fire. If the selected script is in its event loop state, the text input on the bottom can be used to evaluate code within its context (press Enter to run the code, up and down arrows to scroll through input history).


[Image: 1d390a907e8c4e06218a10ecbf4eb4ce.png]

Opening the symbols window while a game is running creates a file in "/Save" named "[GAME NAME].sym". Clicking the "+" button adds a new symbol (it doesn't save to the file yet, but manually edited files do work). Double-clicking a symbol with the "code" type opens its address in the commands debugger, and doing the same for any other type opens the memory viewer.

Symbol names with the "code" type show in the command debugger's "Symbol" column and can replace jump targets:

The format for the symbols (.sym) file is plaintext CSV where each line has a hexadecimal address, data type, name, and an optional description in that order. This might be tweaked later to be a superset of Nemu's COD file format for compatibility.

Valid symbol types are: code, data, u8, u16, u32, s8, s16, s64, float, and double.

A symbols file might look something like this:

SUPER MARIO 64.sym Wrote:802CA8E8,code,exampleProcA
802CB1C0,code,beh_mario_a,mario behavior function
8033B1AC,float,mario_x,Mario's x position

I'll be sure to address the register textbox overflow and unfinished bits in the next snapshot, hopefully it won't take long Smile
(This post was last modified: Yesterday, 09:22 PM by shygoo.)

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

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)

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

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?

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.
(This post was last modified: 28-12-2016, 10:58 PM by mzxrules.)

(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."

Does the debugger have the ability to place conditional breakpoints?

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

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')

(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

Project64 Debugger « 1 2 3 4 »
Users browsing this thread: Pilzinsel64, 1 Guest(s)