NDX (Nintendulator Debug Extensions)

[JeffAMX]

Is there a way to disable the Debug Information Window from popping up at start up?

[thefox]

Is there a way to disable the Debug Information Window from popping up at start up?

Simply close it and it shouldn't pop up the next time you open the app.

[zlash]

I'm having problems getting it to work
I'm using both the emu and CC65 builds attached to the first post.
The debug information log says the debug info is loaded, however when I start stepping through the disassembly the boxes on the bottom (combobox and list) are blank.

I tried changing the paths on the generated .dbg file from relative to absolute, but it was irrelevant.

Any ideas?

Thanks in advance.

[thefox]

I'm having problems getting it to work
I'm using both the emu and CC65 builds attached to the first post.
The debug information log says the debug info is loaded, however when I start stepping through the disassembly the boxes on the bottom (combobox and list) are blank.

I tried changing the paths on the generated .dbg file from relative to absolute, but it was irrelevant.

Any ideas?

I can take a look at it if you send me the ROM and the .dbg file. My email is thefox (at) aspekt (dot) fi.

[zlash]

Thanks for your help! However, looking again at the files before sending them, I found that there were no problems other than my own stupidity.

I overlooked a part of my build script and forgot to add -g when creating the objects. Fixed it, and now everything works as expected.

Now debugging is 38.5%(Not scientifically corroborated) more convenient! Great work!

[Karatorian]

Ok, I know it's a little nit-picky, but was it really necessary to put the timer regs in the same place as the FDS regs when there's a hundred other places they could have been?

Also, it doesn't work in Wine at all. Not that you probably care.

[tepples]

Also, it doesn't work in Wine at all.

"FCEUX. Because Nintendulator is Java-trapped."*


* The name's origin is historic. Technically, programs written in Java are no longer Java-trapped, but the problem of free programs that work only on a non-free platform continues.

[cpow]

Also, it doesn't work in Wine at all. Not that you probably care.

You could try the Linux build of NESICIDE which is capable of source level debugging, also. Get/install the three .deb packages from the link.

[Karatorian]

I'll have to look into NESTICIDE, I've been wishing for an emulator with debugging support for some time now.

FCEUX is actually pretty useless on un*x, because the debugger UI is Windows only.

[tepples]

FCEUX is actually pretty useless on un*x, because the debugger UI is Windows only.

As long as un*x runs on an x86 CPU, FCEUX for Windows works fine in Wine without sound, except closing the Hex Editor will crash FCEUX. I have no problem with FCEUX in Wine on Xubuntu 11.10; what problem did you run into?

[Karatorian]

Actually, I never tried it in Wine. I used native builds.

[thefox]

Ok, I know it's a little nit-picky, but was it really necessary to put the timer regs in the same place as the FDS regs when there's a hundred other places they could have been?

Didn't know the FDS regs were there. Feel free to modify the source to change them.

[thefox]

I've added an example of using the debug output feature from C code in the first post. It doesn't support outputting variable values just yet though.

[thefox]

I added banking support to the proc/scope profiling feature yesterday, it's pretty cool. Release will come later...

[thefox]

I've started working on bolting Lua support to NintendulatorDX. My vision about it is a little bit different than the way FCEUX handles it. I want to embed Lua code in to the ROM, so that it can be used for 1) runtime asserts 2) prototype code 3) debug output, among other things.

At the moment I have two macros that work like this:

Code: Select all

luaExecStr "NDX.print( 'foo' .. 12345 )"
luaExecFile "src/lua-test.lua"

Now the hardest part is coming up with a nice way for the Lua code to interface the emulator. I first thought about copying the interface from FCEUX (which I believe copied at least parts of it from Snes9x), but I think I'll come up with my own one instead. Or maybe both, so I can get compatibility with Lua scripts made for FCEUX.

The main motivation for coming up with a new interface is that I believe the FCEUX way is too verbose for "inline" runtime asserts (FCEUX uses stuff like memory.readbyte(0x123)==0x69 when it could be RAM[0x123]==0x69).

If anybody has ideas about how the Lua-emulator interface should work, let me know!

Also, note to self, I need to add a way of retrieving the debug symbols.