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

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

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.

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

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 Smile . And with the addition of convenient memory breakpoints, I think the debugging experience is already very comparable to Nemu64's.
(This post was last modified: 19-01-2017, 07:32 PM by shygoo.)

i need moar registers to look at Smile

Oh, also are there keyboard hotkeys for the debugger? Clicking to step through is dumb
(This post was last modified: 27-01-2017, 08:10 PM by mzxrules.)

10: Star 
Just tried out snapshot three, memory breakpoints and scripting are choice Smile

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.
(This post was last modified: 02-02-2017, 06:15 AM by jaytheham.)

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

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.
(This post was last modified: 18-02-2017, 08:14 PM by jaytheham.)

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 Big Grin. 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. Smile

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.

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/

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