Mesen - NES Emulator

[Great Hierophant]

There is an option for this already (in the video options), it will run at exactly 60.0/50.0fps when turned on, rather than the standard ntsc/pal frame rates.

Dude, you deserve a for that option.

[geod]

After enabling both 60fps and vsync, the glitch do disappear.
Thank you!

[rainwarrior]

I tried using Mesen to debug an NSF and ran into a few problems. I realize NSF debugging probably isn't a priority (probably very few people do this) but here's my report if you want to take a look:

1. Execution starts in some internal code at $3F00. This puts an added burden of trying to understand this internal code from disassembly (would be better if it starts by breaking at INIT, or during PLAY... ideally the internal code would be a hidden implementation detail.)

2. Parts of the address space aren't viewable in disassembly and don't seem to show up properly in debugger. E.g. near the end of the internal code is JMP ($3E00) but $3E00 resolves to 0. Trying to look at $3E00 in the disassembly shows a gap in the address space there.

3. Banks in the memory display at the bottom seem to perpetually say N/A.

4. I imported a dbg file but all of the labels were $70 higher than they should have been? (I don't know if it's a coincidence that an NSF header has $80 bytes and an NES header has $10?)

5. I had some stuff in a segment with a load address different from its run address (i.e. copy to RAM before running). The address for this stuff was transposed from ~$400 to ~$8070. (That might be its load address +$70 but only the run address is really useful.)

6. Variables directly in RAM seem to be placed correctly.

7. I can't select a range of labels and delete them in the label panel. (Delete is disabled when a range is selected?)

8. Being able to drag a .dbg file onto the debugger might be a nice feature to have.

I've attached the NSF and its DBG file that exhibit this behaviour. The source code for this is here, if needed: github revision (building it is a bit of a process, but nsf.s ramp.s and nsf.cfg have relevant info)

[Sour]

Thanks for the feedback!

The latest appveyor build should fix all of these except 1 & 2 (which are a bit trickier to fix). I think the simplest solution for those would probably be to add "Break on Init" and "Break on Play" options and disable the "Break on power on / reset" option for NSF files? This would make the code at $3F00 more or less invisible, except for the infinite loop between IRQs. I'll take a look when I have some more time.

I've done some rework of the way the current bank was kept internally which means the CPU/PPU memory mappings should now properly work for the vast majority of mappers (only exceptions being mappers that have special nametables or that map CHR rom/ram to $2000+). The PPU mappings also show different colors for CHR ROM vs RAM now (green vs blue).

Let me know if you have any other issues debugging NSF files.

[rainwarrior]

The latest appveyor build should fix all of these except 1 & 2 (which are a bit trickier to fix). I think the simplest solution for those would probably be to add "Break on Init" and "Break on Play" options and disable the "Break on power on / reset" option for NSF files? This would make the code at $3F00 more or less invisible, except for the infinite loop between IRQs. I'll take a look when I have some more time.

Break on init/play would do the job pretty well, I think.

Let me know if you have any other issues debugging NSF files.

The labels look perfect for the NSF now. Drag-and-drop DBG is nice too.

However... NSFe files seem to have broken label addresses. I probably should have checked this too. (The RAM code labels appear fine, it's only the ones that point at ROM code?) Given that the issue with NSF seemed coincidentally related to the header size, maybe this is related to how NSFe can put its DATA chunk at a variable location in the file? (I know NSFe debugging is an even more obscure need. I think Mesen is actually the only debugging emulator that even plays NSFe.)

Example attached (basically the same thing in NSFe form. source).

[Sour]

Yep - same issue for NSFe files (the position the PRG starts in the file has an impact on the import logic).
It should be fixed now - .nes/nsf/nsfe files should all work properly. UNIF won't work though, and since UNIF files can be split into multiple prg chunks, it would be harder to add support for it (and I doubt anybody making CC/CA65 projects is building UNIF files anyway?). FDS files won't work either, for obvious reasons.

I'll try to look into adding break on play/init next weekend.

Unrelated, but something I had noticed a long time ago, forgotten about, and just noticed again when loading your NSFe file - wouldn't it make sense for the NSFe spec to either specify the encoding for all strings (e.g in a separate chunk), or state in the spec that NSFe files (and ideally NSF too) should all use UTF-8? As is, there is no real way to guarantee the track names/artist/etc are displayed properly (NSF files have the same problem with the artist/etc fields). e.g in your NSFe, you encoded the é in Prélude as it would be in CP-1252 (it also seems to show up as "Pr|lude" somewhere else in the file). Mesen interprets all the strings as UTF-8, which makes the Prélude display incorrectly in this case.

[rainwarrior]

Unrelated, but something I had noticed a long time ago, forgotten about, and just noticed again when loading your NSFe file - wouldn't it make sense for the NSFe spec to either specify the encoding for all strings (e.g in a separate chunk), or state in the spec that NSFe files (and ideally NSF too) should all use UTF-8? As is, there is no real way to guarantee the track names/artist/etc are displayed properly (NSF files have the same problem with the artist/etc fields). e.g in your NSFe, you encoded the é in Prélude as it would be in CP-1252 (it also seems to show up as "Pr|lude" somewhere else in the file). Mesen interprets all the strings as UTF-8, which makes the Prélude display incorrectly in this case.

The é in that case wasn't any deliberate attempt at encoding it that way, it's just how that string was generated by default with the tools I was using. The | elsewhere is unrelated (that's intentional, intended for another purpose not used by the NSF).

It's kind of hard to specify a standard for text in NSF. It was never initially specified but CP-1252 is common. Shift-JIS is even more common, I think. Most are plain ASCII though. (Maybe an upcoming NSF2 spec could finally standardize on UTF-8?)

NSFe I think we could get away with retroactively specifying UTF-8, but only because it's a very underused format. I haven't really encountered any collection of NSFe except the one Disch made when he created the format.

Most NSF players just display in local ANSI, I guess. I think you'd be hard pressed to find any that support unicode, actually. NSF is a thing that long predates the big switch to unicode. NSFPlay traditionally displayed in whatever the local ANSI is. If you run it on windows in Japanese mode, it'll display Shift-JIS.

[Sour]

It's kind of hard to specify a standard for text in NSF. It was never initially specified but CP-1252 is common. Shift-JIS is even more common, I think. Most are plain ASCII though. (Maybe an upcoming NSF2 spec could finally standardize on UTF-8?)

Any new spec should definitely use UTF8, anything else makes it harder to manage these days, for essentially no benefit. Even zip files are plagued with the same issue, the file names have no standard encoding. :\

Looking at NSF2's spec, it does already say that strings should be in UTF8:

All strings are UTF-8; players should indicate an error for characters that they cannot display.

Although it doesn't explicitly say that the name/artist/copyright fields should also be UTF8.

I guess NSF2's only benefit vs NSFe was that it was backward-compatible with NSF? I imagine this was mostly for the sake of backward compatibility with hardware players that cannot be updated or are no longer maintained. (Otherwise I'd argue it'd be simpler to expand NSFe)

[rainwarrior]

NSF2 is an unimplemented "speculative" spec. There's no publicly available rips in this format, or publicly available devices or emulators that use it*. Nothing in there is established yet. I wouldn't recommend trying to implement it.

Though, to be honest, NSFe can easily be extended to add everything wanted for NSF2, so I'm not sure we even need it. If you want a backward compatible format we already have it. Anything that would need NSF2's real features isn't going to be backward compatible anyway.

My plan is to implement something like the NSF2's proposed features for NSFPlay (the version on the wiki is a bit out of date with subsequent discussions about it). I'll enable them with a new NSFe chunk. Maybe I could also harden up and release a revised "NSF2" but I don't really know if there's any necessity to make use of that idea.

_{(* There is one rip of Battletoads and some corresponding partial test implementation to support it in Nintendulator.)}

[lidnariq]

Most NSF players just display in local ANSI, I guess. I think you'd be hard pressed to find any that support unicode, actually.

Most linux-y things will print unknown text using UTF-8 nowadays.

Shift-JIS is even more common, I think. [...] If you run it on windows in Japanese mode, it'll display Shift-JIS.

Specifically the "MS932" variant.

[rainwarrior]

One more thing about NSFs: if using PAL region the INIT should have 1 passed for X, not 0.

FDS files won't work either, for obvious reasons.

I understand that banking code in and out would be complicated, since the regions FDS files are loaded to are arbitrary (though at least they're specified in the file itself), but for the moment if I were to create an FDS that does not need overlapping symbols, could this not work just as code from RAM already does?

Specifically the "MS932" variant.

Thanks. This will be helpful when I try to write code to automatically detect it in old NSFs.

[tepples]

NSF2 is an unimplemented "speculative" spec.

One of us should ping the IRC channel to see if kevtris or anyone else has been making use of it.

to be honest, NSFe can easily be extended to add everything wanted for NSF2

Including playback on things like a PowerPak or similar, with the same NES handling the loading, playback timing control and track selection, and actual execution of the audio driver? I think that's why kev proposed NSF 2 instead of NSFe, as it'd be a pain to decode the chunked format in 6502 assembly.

[rainwarrior]

to be honest, NSFe can easily be extended to add everything wanted for NSF2

Including playback on things like a PowerPak or similar, with the same NES handling the loading, playback timing control and track selection, and actual execution of the audio driver? I think that's why kev proposed NSF 2 instead of NSFe, as it'd be a pain to decode the chunked format in 6502 assembly.

1. It's not a pain to decode the chunked format in 6502 assembly. This is a false premise. (...also proposed NSF2 is a chunked format for all data past the main ROM.)

2. The PowerPak is not going to magically grow the other NSF2 features just because it's backwards compatible.

It'd actually be relatively easy to add NSFe support to the PowerPak. It could use the same player with a different loader. The reason it doesn't already support it is just that it's a minority format. (...as opposed to NSF2 which is a non-existent format.)


Ahh, I'm sorry we're having this pointless digression in your Mesen thread, Sour.

[rainwarrior]

FDS files won't work either, for obvious reasons.

I understand that banking code in and out would be complicated, since the regions FDS files are loaded to are arbitrary (though at least they're specified in the file itself), but for the moment if I were to create an FDS that does not need overlapping symbols, could this not work just as code from RAM already does?

Here's an example to try this out. This is a build of my minimal ca65 example for FDS with dbg and source.

Mesen appears to correctly load the symbols with the right addresses. The addresses for RAM < $800 appear inline perfectly. Labels for $6000+ seem to have been loaded with the correct values (listed as RAM in the address column too), but they are never shown in the disassembly?

[Sour]

Ahh, I'm sorry we're having this pointless digression in your Mesen thread, Sour.

No worries, not the first time it happens! :p

Labels for $6000+ seem to have been loaded with the correct values (listed as RAM in the address column too), but they are never shown in the disassembly?

Labels for "NES RAM" are actually meant to be limited to the 2kb of internal ram and are only used if a value below $2000 is specified (I've added bound checking to the edit window so this can no longer be entered manually)

For the FDS, the issue is that the information in the .dbg file isn't really very precise when it comes to the contents of work/save RAM (especially if bankswitching is involved). That being said, I've added some code that should be able to get work/save ram labels to work properly in typical cases (no bankswitching, etc.). For FDS, it should also work correctly, so long as you're not reusing the same parts of work ram in different files (your example seems to work fine).

I also added the Break on Init/Play options for NSF files.

One more thing about NSFs: if using PAL region the INIT should have 1 passed for X, not 0.

It looks like I broke this a long time ago when fixing the playback speed when Dendy timings are selected. Haven't fixed it just yet since I was wondering, what should this return for Dendy timings? Would returning 1 like for PAL be good enough? Or would it make more sense to have another value for Dendy (e.g X = 2)?