Project64 Debugger

[shygoo]

I just downloaded the Euro rom from here https://www.emuparadise.me/Nintendo_64_ROMs/Paper_Mario_(Europe)_(En,Fr,De,Es)/40077-download and it runs fine for me on either interpreter or recompiler. Not sure what problem you're having but I'd assume it doesn't have anything to do with my changes.

[Nutta]

When will there be a final stable release? I'm really getting sick of nemu64.

[shygoo]

I'm not sure there will ever be a final release as there's been no shortage of good ideas and suggestions for new features . And with the addition of convenient memory breakpoints, I think the debugging experience is already very comparable to Nemu64's.

[mzxrules]

i need moar registers to look at

Oh, also are there keyboard hotkeys for the debugger? Clicking to step through is dumb

[jaytheham]

Just tried out snapshot three, memory breakpoints and scripting are choice

A few things:
The + button to add breakpoints seems broken, but there are other ways to add them now so it's not a big deal.
The assembly/register window stopped drawing it's content sometimes, and I had to switch between the register tabs to make it redraw them.

Any chance of an onExec event that doesn't do any checks itself? Could be slow I know.

Edit: Additional thoughts:
Show the float value of the registers next to the hex value.
Perhaps this is some weird convention, but the labels of the FPRs in the FPR tab are 1/2 the name in the commands table (i.e.: SWC1 F6, 0x0000 (s0) actually stores the value from the register labeled F3 in the FPR tab).
Also, I keep unintentionally setting BPs on addresses in the 0x0xxxxxxx range, because the memory viewer defaults to that, but really I want to be setting them in the 0x8xxxxxxx range because BPs there will actually work. It's not super obvious why the breakpoints aren't triggering on values I can see changing until I remember to check which address space I've set them in.

[Jorgasms]

This is pretty sweet. Would love to be able to see more registers so I can finally get rid of Nemu

[jaytheham]

I've been playing around with scripts a bit, very cool, so easy to use.

It would be great if the scripts console stayed scrolled to the bottom so you could see the most recent output, currently it resets to the top every time you write to it.
Also if the scripts window (and thus the console) was resizable that would be nice.
A reference to the ROM itself similar to the mem.x would be useful too.

Keep up the great work! This is the best thing to happen to N64 hacking in a long time.

*edit*
By the way, how do you build the project? In VS2013 I get a load of errors that don't look skippable.

[shygoo]

Gamblor Wrote:Does the debugger have the ability to place conditional breakpoints?

​

I commited a debug.breakhere() function which will be part of the API in the next snapshot. It pauses the game at the current instruction and shows the debugging window.

jaytheham Wrote:​
Any chance of an onExec event that doesn't do any checks itself? Could be slow I know.

​

Yeah, I was thinking of implementing this as events.onexec(null, func). It should be simple enough to add, and I'm sure it will cause some lovely FPS dips . I'm also thinking of adding an events.onjal(func) to trap every JAL.

jaytheham Wrote:​
Perhaps this is some weird convention, but the labels of the FPRs in the FPR tab are 1/2 the name in the commands table

​

This is definitely broken. I should probably do more testing before I release this stuff.

jaytheham Wrote:​
It would be great if the scripts console stayed scrolled to the bottom so you could see the most recent output, currently it resets to the top every time you write to it. Also if the scripts window (and thus the console) was resizable that would be nice.

​

I've commited fixes for these.

jaytheham Wrote:​
A reference to the ROM itself similar to the mem.x would be useful too.

​

ROM data can be accessed via the mem.x interface using 0xB0000000 addresses. However, I noticed that mem.u32 is the only function that works due to PJ64's MMU implementation. I'm not sure if this is a PJ64 optimization quirk or an actual N64 quirk. In any case I'll add a rom.x interface that should do the same thing mem.x does but for ROM.

jaytheham Wrote:​
By the way, how do you build the project? In VS2013 I get a load of errors that don't look skippable.

​

I've been using VS2015 to build. Others were also having trouble building with older versions I think.

[shygoo]

Just commited a fix for the FPR issue and added a rom interface to the JS API.

I'm gonna start uploading interim builds more frequently here http://shygoo.net/pj64d/

[jaytheham]

I was hoping to have a poke around with the code and maybe make a few commits now that I have the project building on VS2015, but when trying to run any script I get the error:
SyntaxError. Parse error (line 485)
Because duk_peval_string(ctx, apiScript) from CScriptInstance:: StartScriptProc() is non-zero. There doesn't seem to be any exception thrown and I'm not excited about trying to debug duk after a quick look into it, I don't suppose you've come across this and know how to avoid it?