Page 7 of 7

Re: Nintendulator Debug Extensions

Posted: Wed Oct 17, 2012 6:23 am
by qbradq
I'm trying to update my assembler to output version 2.0 debug info files. Can you point me to the documentation on this file format? I've looked at the dbginfo.c file but I can't make heads or tails of what it's doing.

Re: Nintendulator Debug Extensions

Posted: Wed Oct 17, 2012 7:01 am
by thefox
qbradq wrote:I'm trying to update my assembler to output version 2.0 debug info files. Can you point me to the documentation on this file format? I've looked at the dbginfo.c file but I can't make heads or tails of what it's doing.
There's no documentation as far as I know. Easiest way to figure it out is probably just to play around with CA65 and see what kind of output it produces for different source inputs.

Re: Nintendulator Debug Extensions

Posted: Sun Oct 28, 2012 11:01 am
by thefox
thefox wrote: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.
I've made good progress and I'm pretty happy with how it works now. Couple of examples:

Debug output:

Code: Select all

.zeropage
  some_var: .byte 0

.proc something
  lda #$69
  ; RAM table (for reading/writing bytes) is automatically defined.
  luaExecStr "print( 'value from memory is ' .. RAM[ 0x234 ] )"
  ; RAM table can also be indexed with symbols. Only works for global symbols right now (no scopes, but of course it's always possible to define aliases for scoped variables in CA65).
  luaExecStr "print( 'value from memory is ' .. RAM.some_var )"
  luaExecStr "print( string.format( 'A = %X, X = %X, Y = %X', REG.A, REG.X, REG.Y ) )"
  rts
.endproc
luaExecStr doesn't embed any code/data in the ROM (but it will embed one NOP if requested, as is required in some cases), it works by defining debug symbols for the information it needs and outputting the data in a separate segment, which is then output to a separate file. All of Lua code is executed in 0 cycles, so it's nice for prototyping.

Runtime asserts:

Code: Select all

  luaExecStr "if RAM.some_var > 50 and REG.A = 0x49 then iup.Message( 'Assert failed', 'Something went wrong' ); NDX.stop() end"
It's of course possible to define a simpler macro for runtime asserts, which will hide the iup.Message call etc.

Prototyping:

Code: Select all

; foo.s (6502 code)
.bss
ARRAY_SIZE = 100
array: .res ARRAY_SIZE

.code
.proc gahh
  luaExecFile "gahh-proto.lua"
  rts
.endproc

-- gahh-proto.lua (Lua code)
-- Fill "array" with something.
array_addr = SYM.array[ 1 ]
for i = 0, SYM.ARRAY_SIZE[ 1 ] - 1 do
  RAM[ array_addr + i ] = i + 123
end
IUP GUI toolkit is also included by default. It can be used to implement custom debug dialogs:

Code: Select all

-- Lua code
ctl = iup.label { title="something", expand="YES" }
dlg = iup.dialog { ctl, title="Debug Helper", size="200x200" }
dlg:show()

; 6502 code
luaExecStr "ctl.title = string.format( 'some_var is %X', RAM.some_var )"
Functions currently exported from the emulator:

Code: Select all

NDX.getPPUCycles
NDX.setRegister
NDX.print -- For printing to the Nintendulator Debug Information window, normal print() prints to the Lua console
NDX.getRegister
NDX.writeRAM
NDX.getCPUCycles
NDX.stop
NDX.readRAM
NDX.getSymbols
Eventually I hope to add support for "stand alone" Lua scripts (like in FCEUX), which don't need to be executed from within the code.

Now I just need a new project which I can use all of these features on. ;) BTW, release will come some time later, my repo got corrupted so I need to set up the source control again to make it easy to merge stuff from the official Nintendulator SVN repo.

Re: Nintendulator Debug Extensions

Posted: Thu Nov 01, 2012 8:22 pm
by thefox
thefox wrote:Eventually I hope to add support for "stand alone" Lua scripts (like in FCEUX), which don't need to be executed from within the code.
Did that too. Also added support for CD (Canvas Draw) graphics library, as well as an ability to overlay graphics generated with it on top of the emulated view. Then I wrote a little FCEUX compatiblity module (incomplete) and ported over some of the Lua scripts from FCEUX, like SMB Snow and miau's Megaman 2 Laser Eyes. Cool, cool, should be done soon.

Re: Nintendulator Debug Extensions

Posted: Fri Nov 02, 2012 4:09 am
by qbradq
You never cease to astound :D

What's inspiring all of the Lua work fox? Is there a project you're working on that's using it?

Re: Nintendulator Debug Extensions

Posted: Fri Nov 02, 2012 7:56 am
by Movax12
This is awesome and I'm excited to use these new debugging features.

I assume you could define a breakpoint with something like: luaExecStr "print( 'Breakpoint encountered.'); NDX.stop() end"

With no code being output to your nes code/rom?

Re: Nintendulator Debug Extensions

Posted: Fri Nov 02, 2012 9:54 am
by thefox
qbradq wrote:You never cease to astound :D

What's inspiring all of the Lua work fox? Is there a project you're working on that's using it?
Thanks! As to why, I was bored and decided it was a good time to learn some Lua. :) But all of this will certainly come in handy in future projects. I wish I had had something like this when working on STREEMERZ.
Movax12 wrote:I assume you could define a breakpoint with something like: luaExecStr "print( 'Breakpoint encountered.'); NDX.stop() end"

With no code being output to your nes code/rom?
Yes. The macro outputs the string to a special segment, which is redirected to another file (I use extension .ndx for these). There's one case when it's necessary to output one NOP though:

Code: Select all

; Display a message when some condition happens:
lda foo
beq not_foo
  ; The emulator uses addresses (and banking information) to identify these, so
  ; if luaExecStr/luaExecFile is the very last thing before the condition label, it
  ; needs to output one NOP, so that its address is not the same as "not_foo".
  luaExecStr "print( 'foo happened' )", 1
not_foo:
Of course, at least in some cases it's possible to implement the above check like this too, avoiding the NOP:

Code: Select all

; NOTE: In Lua, all numbers evaluate as true, so have to explicitly check for non-zero.
luaExecStr "if RAM.foo > 0 then print( 'foo happened' ) end"
All of this stuff only works in CA65 of course, and only with debug file enabled. (I could make it work universally by using a special register write, like the debug output feature currently does, but that's low priority.)

Re: Nintendulator Debug Extensions

Posted: Tue Nov 06, 2012 6:18 am
by qbradq
I've made a test ROM for TNROM boards configured with 32KB of VRAM (link). I've found that I needed to build the mappers from SVN to get it to work. Have you considered updating your mappers to the latest SVN?

Re: Nintendulator Debug Extensions

Posted: Tue Nov 06, 2012 7:33 am
by thefox
qbradq wrote:I've made a test ROM for TNROM boards configured with 32KB of VRAM (link). I've found that I needed to build the mappers from SVN to get it to work. Have you considered updating your mappers to the latest SVN?
Ah I didn't know about, in fact I remember requesting >8KB CHR-RAM support for MMC3 from Quietust but didn't get a reply (but looks like he implemented it after all) (correction: I misremembered, he did reply, and implemented the support not long after the reply, unknown to me). But yeah, I'll add the updated mappers to the upcoming release.

Re: Nintendulator Debug Extensions

Posted: Tue Nov 06, 2012 7:51 am
by qbradq
The MMC3 code appears to support 256 1K RAM banks now, although I only tested 32KB. Glad to hear it'll be in the next release :D

Re: Nintendulator Debug Extensions

Posted: Thu Nov 08, 2012 7:09 am
by thefox
Well, I decided to release v34. It's not perfect, but I'm done with tinkering. :)

Download from HERE.

New stuff:
- Lua scripting
- Banking support for profiling
- Debug breakpoints (write to a magic register or call ndxDebugBreak macro to stop the emulator)
- Better documentation
- Feature demo for CA65
- Mappers updated to the latest version from SVN
- Source moved to gitorious (https://gitorious.org/nintendulatordx)

As usual, if you find anything wrong in the docs (wrote them in a hurry) or anywhere else, let me know. The Lua-emulator thread synchronization is still a bit iffy (should work, but the user has to know what he/she is doing).

Re: Nintendulator Debug Extensions (NintendulatorDX)

Posted: Thu Feb 26, 2015 9:11 pm
by thefox
Decided to put together v35. It has a bunch of old changes that I couldn't bother to merge to the public repository. From now on I'll probably be updating only the public repository.

The changes:

Code: Select all

  * "Expand macros" option.
  * CA65 debug header no longer tramples over custom character mappings.
  * Absolute file paths can be used in debug files.
  * Bug fixed from dbginfo.c that caused some (rare) debug files not to
  be loaded.
  * readMemory() function added to the Lua interface.
  * Latest updates from the main Nintendulator repo integrated.
  * Warnings are given for uninitialized PRG-RAM accesses.
  * Memory can be randomized on power-on.
  * Lua, CD and IUP updated to the latest versions.
  * Updated project to Visual Studio 2013.
  * Added limited PowerPak hardware emulation (requires recompilation).
  * Diagnostic message is shown if PPU_DATA is written to during rendering.
  * NTSC NES borders are displayed.
Download from the usual place: http://kkfos.aspekt.fi/projects/nes/too ... dulatordx/
The git repository was moved to GitHub: https://github.com/fo-fo/nintendulatordx

Re: Nintendulator Debug Extensions (NintendulatorDX)

Posted: Sat Feb 28, 2015 9:52 am
by GradualGames
By expand macros, does this mean in the code view in the debugger you will see the macro expanded in place, so you can see the context of the surrounding code? I recall in previous versions it would "jump" to the macro in the code. If this is what you've improved, then awesome, thanks!

Re: Nintendulator Debug Extensions (NintendulatorDX)

Posted: Sat Feb 28, 2015 11:14 am
by thefox
GradualGames wrote:By expand macros, does this mean in the code view in the debugger you will see the macro expanded in place, so you can see the context of the surrounding code? I recall in previous versions it would "jump" to the macro in the code. If this is what you've improved, then awesome, thanks!
Not quite like that, but maybe sort of similar if I understood you right. When the option is turned on, the behavior is same as in previous versions. When the option is off, NDX will stay at the highest possible level and not display macro contents (previously it'd go as deep into macros as possible).

It probably should have an option to set the desired depth. At the moment it will reset the depth on every step. (Fortunately I think most people would be usually interested only in the highest or the lowest depth).

Re: Nintendulator Debug Extensions (NintendulatorDX)

Posted: Sat Jul 11, 2015 6:17 pm
by thefox
Here's version 36: http://kkfos.aspekt.fi/projects/nes/too ... dulatordx/

This release contains some fixes to search paths of assembly and Lua source files. There's a menu option for using an NTSC/PAL aspect ratio and support for blargg's NTSC filter. The NTSC filter doesn't support field merging yet, so it can be a bit flickery, but should give a general picture about how the game is going to look on an NTSC TV. There's an option to darken the overscan area of the screen (with 90% safe area), but note that this doesn't work if the NTSC filter is turned on. Performance overall might be a little bit worse than earlier release because some upscaling is done in software.

NOTE: The results you get from the aspect ratio options may depend on your display drivers. I noticed that on my GeForce 8800 GTS the driver used nearest neighbor filtering when scaling the image, and on my current Intel HD 4600 it uses bilinear filtering. Bilinear filtering works better for the aspect ratio settings (because of the 2x upscaling done in software before the aspect ratio stretch). Unfortunately I haven't found a way to force the filtering algorithm in DirectDraw, so looks like the only way to get consistent behavior is to switch to Direct3D (might happen in the future).

All in all there are many gotchas in this version which I couldn't bother to fix just yet, but also didn't want to sit on it for an eternity. Hopefully somebody out there will find some use out of it.

If you try it out and encounter any problems, LMK.

Changes:

Code: Select all

  * NDX searches for source files in the current working directory
  (previously only relative to the ROM directory)
  * NDX searches for Lua scripts relative to current working directory.
  * Menu option added for NTSC/PAL aspect ratio.
  * NTSC filter support added (blargg's nes_ntsc).
  * Frame skip option removed.
  * Color depths other than 32-bit removed.
  * Diagnostic is shown if invalid black (0xD) is used in rendering.
  * Improved the implementation of Lua require().
  * Fixed a bug that caused the A register to be cleared when
  ndxDebugBreak was used without the debugger window being open.
  * Fixed some problems with POV axes (patch from Nintendulator main
  repository)
  * Lua code can call back into 6502 code (NDX.jsr())
  * Menu option for darkening borders outside the 90% safe area of
  the (NTSC) screen.