Project64 Debugger

[shygoo]

(17-06-2017, 06:48 PM)Ecksters Wrote: This is awesome, how simple would it be to do this in OoT? I can see many people liking something like it for the Haunted Wasteland section, you should be able to colorize the polygons that are safe and which ones void out.

​

This should definitely be possible, but OoT's collision data looks more complicated than SM64's. If there is documentation somewhere on how the collision data is structured in RAM, I could give this a shot.

(25-06-2017, 12:48 AM)PartyPlanner64 Wrote: ​
[snip]​

​

Will be addressing most of this stuff soon, thanks for the suggestions. Really like the enum and dynamic symbol ideas .

(20-07-2017, 03:56 PM)AirysDark Wrote: ​
Is there anyway I could use this to track memory it's displaying. And tell the tool to ignore them in display. To make it easy to find the memory path I'm looking for?

Sorry it's hard to explain what I'm trying to say lol

​

If I understand correctly, you want to filter out specific memory addresses? The Symbols tool should be useful for that. Try right-clicking data in the memory window then click Add Symbol, then Debugger -> Symbols... to see what you've added.

---

​

For anyone interested, the recent-builds index has been updated to include project info and a long todo list: http://shygoo.net/pj64d/

[AirysDark]

that's not it. i need to be able to mark the memory or highlight it. so when new memory is displayed it will not show or mark/highlighted the memory.

kinder like when i used to make modded menus for gta v. scan all the offsets the games showing at the point in time. highlight it all. then select hide offset. so 10,000,000 useless offsets are not showing to make it easy to find e.g players speed jump ammo etc.

what im trying to achieve. is to find the memory path of yoshi voice. but sitting at the char select screen. mark/hide the memory being displayed. then selecting yoshi. and see what memory is being displayed.

[shygoo]

Been a while since I last popped in! I'm working on a tool that makes it easier to mess around with the graphics microcode, and it's off to a good start.



I'd like to display DMA log information when clicking on the commands, to make the process of tracing uncompressed gfx resources back to ROM effortless.

A scene exporter is also in the works -- here's a very basic Wavefront OBJ of SM64's title screen:



Back on the MIPS side of things, I added a stack trace window to show the chain of active functions. You can doubleclick the routines to visit them in the commands window. This should eliminate the need to copypaste the RA register a million times while backtracing.



In other news, all the debug features have been merged into the Project64 master branch! One thing Zilmar changed during the merge is the addition of a config setting for the fixed RDRAM allocation. It's now disabled by default but you can enable it by adding
Fixed Rdram Address=536870912 under [default] in Config/Project64.cfg (this puts the memory base at 0x20000000 for Cheat Engine, etc).

[mzxrules]

one thing that could be beneficial to making dlist viewing less overwhelming is adding in some code to detect macros that generate multiple "instructions"

[shygoo]

It's been quite a while since I've worked on this, but I went ahead and put up a new stable snapshot link since the last one was ancient. Most notably, the debugger window now has all the memory mapped registers, annotations are shown for special read/write instruction addresses, and the RSP debugger's register window has been fixed.

https://github.com/shygoo/project64d/releases/download/snapshot5/pj64d-snapshot-5.zip

Debugger:
 Add all memory mapped registers
 Add branch arrows column
 Add FCSR31 register to FPR tab
 Add shortcut keys for Skip/Step/Go (F1,F2,F4)
 Add tooltips to the buttons
 Add register field highlighting
 Add annotations for:
  Reads/writes to system registers, ROM header, symbols
  Exception vectors
 Context menu:
  Add 'View memory' for load/store addresses
  Add 'Follow' for jumps/branches
  Add 'Run to line'

Memory Dumper:
 Add binary support
 
Memory Search:
 Add ASCII string search
 
DMA Log:
 Add highlighting for sequential loads
 
Script API:
 Support address ranges for events.onexec/onread/onwrite
 Make events.read/write/exec return a callback ID
 Add events.remove(id) for callback removal
 Add events.ondraw(func)
 Add screen.print(x, y, text) [Unstable!]
 Add ugpr (upper 32 bits of GP registers)
 Add dfpr (double floating-point registers)
 Add gpr.lo, gpr.hi, ugpr.lo, ugpr.hi
 Add optional maxLen arg to mem.getstring and rom.getstring
  
Script Console:
 Remove character output limit
 Add 'Copy' button
 Add 'Clear' button
 
Interpreter core:
 Break out of invalid CRC halt if debugger is enabled
  
RSP Plugin Debugger
 Fix register window
 Use 0x1000 for IMEM base address

[misscelan]

Hey first all of all, thanks for this awesome fork!

I'm currently messing with the N64 sdk trying to make some homebrew stuff, and I was wondering if this could be used to "capture" calls to "printf" or "osSyncPrintf". It would be very useful to debug some stuff when developing.

Thanks!

[shygoo]

Hey welcome to the forum! If you know the virtual address of the printf function in question, trapping it and logging the output to the console should be doable using a combination of events.onexec and mem.getstring. jaytheham set up something similar to that in a script posted here: http://origami64.net/showthread.php?tid=755&pid=7450#pid7450