nesdev.org

tepples wrote:Do .lst files expand .repeat and macros differently from source files?

As far as I can tell they don't expand at all in listing files. Also it only displays the first 12 bytes of the expanded data.

When I set all of this up, run the ROM and step the debugger the application throws a std::length_error exception. Is this because I am using a CC65 snapshot from 02/27/2011? I saw on page 3 of this thread that as of 02/04/2011 the CC65 snapshot did not work with this patch, but there was no mention if version 0.25 fixed this or not.

Does the FTP link for the CC65 snapshot in the first post point to the proper (older) version? If not where can I get the right version?

qbradq wrote:When I set all of this up, run the ROM and step the debugger the application throws a std::length_error exception. Is this because I am using a CC65 snapshot from 02/27/2011? I saw on page 3 of this thread that as of 02/04/2011 the CC65 snapshot did not work with this patch, but there was no mention if version 0.25 fixed this or not.

Does the FTP link for the CC65 snapshot in the first post point to the proper (older) version? If not where can I get the right version?

Yes 0.25 fixed the compatibility problems, this must be some other bug. The FTP link in the first post is to the CC65 snapshot folder which always has the latest nightly build, so it's fine. Does it show any additional info with the exception?

If you want to share the .dbg file and the .nes ROM that produce that exception you can send them to e-mail address thefox (at) aspekt.fi

There are no other details as there are no debugging symbols in the executable. The stack trace is just a bunch of hex offsets

One suspicion I had was that I had unused segments defined in the object file. I corrected that but it made no difference.

You may download a zip file with the .nes, .nes.dbg and .o files here. The linker config outputs a single object file per your instructions.

The source tree is not needed for this to occur.

Steps to reproduce:
1. Extract ZIP file contents to a directory.
2. Load the .nes file with your patched Nintendulator binary (dated 02/26/2011)
3. Open the debugger window
4. Click the "Run" button
5. Click the "Step" button
6. Badness ensues

qbradq wrote:Steps to reproduce:
1. Extract ZIP file contents to a directory.
2. Load the .nes file with your patched Nintendulator binary (dated 02/26/2011)
3. Open the debugger window
4. Click the "Run" button
5. Click the "Step" button
6. Badness ensues

I can't reproduce this for some reason, it doesn't crash here. Did you try it without the source files?

EDIT: BTW, the stack trace + any additional info would be helpful even if it only displays hex addresses

Ok, so here's a head scratcher. When I start the program, then use the Open menu to open the ROM it works fine. However, if I start the program with the ROM file as the first command line argument the issue does appear.

I can work around this but it kinda throws my dev cycle off. I have a build script that loads the ROM in the emulator on a successful build. Would you mind to see if you can reproduce it this way?

qbradq wrote:Ok, so here's a head scratcher. When I start the program, then use the Open menu to open the ROM it works fine. However, if I start the program with the ROM file as the first command line argument the issue does appear.

I can work around this but it kinda throws my dev cycle off. I have a build script that loads the ROM in the emulator on a successful build. Would you mind to see if you can reproduce it this way?

Yes I was able to reproduce it, it was a stupid bug. The code which stripped the ROM path was assuming there was at least one / or \ in the path. Download http://thefox.aspekt.fi/nintendulator-bugfix.zip and extract to v0.25 folder to get the (hopefully) fixed version (this zip doesn't contain the mapper files).

Cool man, thanks for the quick turn-around. I really appreciate it! Thank you again for all of your hard work on this. I am sure it will save me a bunch of time in development.

I'd also like to let you know this was the only thing that convinced me to learn ca65 and ld65. Now that I have I wouldn't dream of going back

qbradq wrote:Cool man, thanks for the quick turn-around. I really appreciate it! Thank you again for all of your hard work on this. I am sure it will save me a bunch of time in development.

No problem, thanks for reporting the bug!

I'd also like to let you know this was the only thing that convinced me to learn ca65 and ld65. Now that I have I wouldn't dream of going back

I know, right?

Btw one "bug" with this version is that the way it behaves with macro line infos is kind of random. Since CC65 now supports multiple line infos for one macro address (line info for the macro invocation line, the actual macro body line and additional line infos for nested macros), it'll always pick the first one that the dbginfo API returns. This is sometimes the invocation line, sometimes one in the macro body, and sometimes might be something else. I didn't bother fixing this yet since I don't know what would be the best way to handle it.

EDIT: there's something seriously wrong with clicking on the source code listing to set a breakpoint in the latest release, I guess the new SVN updates broke it... EDIT2: fixed I'll release the fix later with a new version.

Version 0.26 released with the above bug fixes applied. Also displays init and play cycle counts for NSFs.

Thank you for your continued work on this thefox! I have been using this daily and it's a huge help.

every time i load a state, the mode changes from ntsc, pal, or hybrid. anyone else getting this bug?

yesyesyall wrote:every time i load a state, the mode changes from ntsc, pal, or hybrid. anyone else getting this bug?

I don't think this is a bug. The bug was that it DIDN'T change the mode in previous versions of Nintendulator. So what you're experiencing is the proper behaviour. Also this fix was made by Q, not by me.

ah, okay! thanks! is there a simple way i can stop that, or would it require surgery? i can revert to older versions, but i LOVE everything about my current version except for that little thing.

yesyesyall wrote:ah, okay! thanks! is there a simple way i can stop that, or would it require surgery? i can revert to older versions, but i LOVE everything about my current version except for that little thing.

I don't see why that feature would bother you... IF it always switches PPU mode to the next mode when loading, then you're using an older version which had a bug. This is not the proper behaviour I was talking about.