Dude, you deserve aSour wrote: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.

Moderator: Moderators
Dude, you deserve aSour wrote: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.
Break on init/play would do the job pretty well, I think.Sour wrote: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.
The labels look perfect for the NSF now. Drag-and-drop DBG is nice too.Sour wrote:Let me know if you have any other issues debugging NSF files.
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).Sour wrote: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.
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. :\rainwarrior wrote: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?)
Although it doesn't explicitly say that the name/artist/copyright fields should also be UTF8.All strings are UTF-8; players should indicate an error for characters that they cannot display.
Most linux-y things will print unknown text using UTF-8 nowadays.rainwarrior wrote:Most NSF players just display in local ANSI, I guess. I think you'd be hard pressed to find any that support unicode, actually.
Specifically the "MS932" variant.rainwarrior wrote:Shift-JIS is even more common, I think. [...] If you run it on windows in Japanese mode, it'll display Shift-JIS.
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?Sour wrote:FDS files won't work either, for obvious reasons.
Thanks. This will be helpful when I try to write code to automatically detect it in old NSFs.lidnariq wrote:Specifically the "MS932" variant.
One of us should ping the IRC channel to see if kevtris or anyone else has been making use of it.rainwarrior wrote:NSF2 is an unimplemented "speculative" spec.
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 wrote:to be honest, NSFe can easily be extended to add everything wanted for NSF2
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.)tepples wrote: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 wrote:to be honest, NSFe can easily be extended to add everything wanted for NSF2
Here's an example to try this out. This is a build of my minimal ca65 example for FDS with dbg and source.rainwarrior wrote: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?Sour wrote:FDS files won't work either, for obvious reasons.
No worries, not the first time it happens! :prainwarrior wrote:Ahh, I'm sorry we're having this pointless digression in your Mesen thread, Sour.
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)rainwarrior wrote: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?
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)?rainwarrior wrote:One more thing about NSFs: if using PAL region the INIT should have 1 passed for X, not 0.