nesdev.org

perhaps the right solution might rely on something similar to the code/data log (CDL) of FCEUX.

Code/data logger sounds like a pretty cool feature. Thanks for the idea!
When using it for disassembling purposes, the downside would be that one would first need to play the whole game. And even then it may still miss some hidden or unused code/data areas.

That hasn't stopped its usefulness in FCEUX. If you add this feature to No$SNS that would be awesome. Something else that would help that was not added to NES but might be easier on SNES, is an address label logger, to help log address labels if someone intends to move code/data around it could help cut down the manual work a bit.

nocash, I've got at least one example where debuggers might have trouble... and believe me, this one I didn't need a debugger. ^_^

You're not going to find Mega Man's Soccer's hidden ending using any old debugger...

That's actually something that I found via good 'ole hex editing. I used my hex magic to find the ending through musical references to two ending tunes (yes, they were confirmed to be ending tunes by me), and then that lead to a whole bunch of other discoveries. I actually collaborated with JLukas to complete the package for the original ending, and I found a second ending.

The address label feature isn't a bad idea. Some of my music modifiers do use pointers (which means they require safe-cracking), and if you relocate that data, the music modifier is null and void until you modify your pointers. Sometimes, through common start and endpoint hex values in the data (or even ROM text), I can get away with finding unused music that pointer data alone won't reveal.

Also, another option that can help for debugging : can have a debug console to display debug message like with no$gba.
By the way, just donate to have the last 1.2 version (your site is now online again ), thanks for your great job.

debug console to display debug message like with no$gba.

Yes, that would be neat, I've been wondering about (how) to add it, too.
At the moment I'd vote for a CHAR output function (unlike the STRING output in no$gba). And that... by writing the character to an unused I/O address...
Are there already SNES emulators having that feature (so I could use the same I/O address)? Or real SNES hardware having that feature (like an RS232 port used to output characters to a terminal screen or log file)?

KungFuFurby wrote:nocash, I've got at least one example where debuggers might have trouble... and believe me, this one I didn't need a debugger. ^_^

Why would you expect a debugger to help you find alternate game endings?

If each ending uses a game's script system, and there's a table of scripts, then a debugger could help find the table.

For example, the ending of Thwaite assumes that at least one missile landed, and one of the characters investigates the wreckage and discovers who was the culprit. Stepping through the script system's setup (or, in the case of a freely licensed game like Thwaite, reading through the source code) would reveal a table that points to something else. (Spoiler: There's a hidden set of scripts for a no-damage run, which has a bunch of bad puns on "TAS". This leads to an ending where nobody discovers what really happened, and then it breaks the fourth wall and a developer thanks the player for having the dedication to make a tool-assisted speedrun.) This "something else" is not canon.

I've donated to get access to v 1.2. I'm noticing that assigning buttons on an external game controller now works. However, the default values created a confusing problem for me.

I have a SNES controller adapter with two ports. For whatever reason, I had the controller plugged into port 2. After assigning the buttons, I noticed (in for example Super Mario World, and later the SNES test program) that pressing one key on the pad pressed two different keys. The problem was that player 2's control were enabled and mapped to buttons 1-8 port 2. This is true even when "game controllers" is set to "one joypad". I think a safer bet for default values is to not assign any buttons, since they most likely won't end up on the button you want.

If a button is unassigned, it's saved as 00 in the config string. It's then loaded as "button 89" and consequently saved as hex 59 in the config string. I guess this doesn't hurt, but is a bit ugly.

I would suggest making the pad fully reassignable, including direction keys. You may want to to do this for various reasons.

The VRAM viewers tile views (and sometimes BG4?) are showing complete junk data.

The "stretching mode" setting does absolutely no difference in the two modes that I'm able to test, software and StretchDIBits. For example, software mode uses the blocky stretch mode, always, except in 50% zoom, where it uses resample mode, always.

The stretch type (which is a bad name for the setting) DirectDraw doesn't work here. I'm guessing some piece of Win9x voodoo stopped working in newer operating systems. I suggest also supporting Direct3D, which works better for various reasons on hypermodern operating systems (Vista, 7).

And finally, any chance of a DOS build of no$sns?

any chance of a DOS build of no$sns?

wtf? People still run DOS?

I want to have it for fun. I want to try it on a P100 laptop I have. no$sns Win performance is worse than ZSNES DOS performance, and even that is almost useless on that computer. But maybe Martin's asm+DOS can do wonders for this machine. On the other hand, ZSNES is written in asm, too...

nitro2k01 wrote:[...] ZSNES DOS performance [...] is almost useless on that computer.

Really? I could have sworn I remembered running ZSNES 0.400 at full speed on a 486/66. (albeit without the pseudo-transparency mode.)

1) That was that version and not the latest 2) I'm getting maybe 20-30 FPS here Super Mario World. (Don't remember since the last time I turned that computer on.) Might vary depending on the game as well, of course.

Just uploaded no$sns v1.3, http://nocash.emubase.de/sns.htm
New features are Nintendo Super System (Arcade Cabinet) emulation, and support for some more controllers/add-ons: Barcode Battler (EAN-13 format only, the formats for EAN-8 and UPC-A are still unknown), Four Twin Taps (for 8 player quiz game), and the Pachinko dial (for utmost stupidity). All that bizarre features are available to people donating some money to the nocash project; money will be blown up on making more such strange stuff. Or, without donating, everybody can now download no$sns v1.2 for free - with equally bizarre features like SFC-Box emulation.

For the game pad configuration - I've added a feature in no$sns v1.3 that prevents assigning the same PC gamepad to two different SNES joypads - I hope that will avoid problems/confusion in future.

DOS version would be nice. But... the modern multisync monitors are so damn slow on switching from text to graphics mode - I think it would be a pain to use (and make/test) it. And not too sure if it'd be much faster than the windows version - the overall emulation speed should be same no matter of the OS - at its best, things like video output might be slightly faster.

> I've added a feature in no$sns v1.3 that prevents assigning the same PC gamepad to two different SNES joypads

Meh, I love mapping player 2 the same as player 1, sans swapping left+right around. Makes for fun 'clone' fighting in Street Fighter games.

nothing new regarding improvments, bugs posted in this thread ?