offset # of bytes Function
-----------------------------------------------------------------------------------
007a 1 BYTE PAL/NTSC bits:
bit 0: if clear, this is an NTSC tune
bit 0: if set, this is a PAL tune
bit 1: if set, this is a dual PAL/NTSC tune
bits 2-7: not used. they *must* be 0
-----------------------------------------------------------------------------------
- PAL-flag patch has incorrect DPCM-pitch on 50 FPS.
- $6E-$6F patch is OK.
Rainwarrior, can you add "$6E-$6F patch" to NSFplay please?
It allows to play standard NTSC NSFs on 50Hz with correct pitch (dendy-style).
However the real Dendy has a little lower pitch than NTSC NES, since it CPU clock are 1.7734475 MHz (NTSC has 1.7897727 MHz). But you can neglect this fact.
Is this a thing that dendy hardware does, or related clones?
"Dendy" is only a brand. Chips were different (1990-1997). UA6527P and HA6527P chips have this bug. 25% and 50% duty cycles are swapped (on both square channels).
You can listen it on puNES 0.69WIP Here is a test program and recordings (8MB) that were made with 6 different chips.
Some pure-NTSC clones also has this bug: UA6527 (without "P") is the 2A03 NTSC clone.
DWEdit wrote:00 = 12.5% on both
01 = 25% (or 50% on buggy clones)
10 = 50% (or 25% on buggy clones)
11 = 75% on both
TA6527P (aka TA-03NP1) and NOACs, like UM6561 doesn't have this bug.
Most of famiclones that were assembled after 1992-1993 doesn't have this bug.
This should now support all stable illegal opcodes, and handles the "sweep trick" just fine, I think, so streemerz.nsf is now functional. Lemme know if you spot any other problems with it.
Last edited by rainwarrior on Fri Jul 19, 2013 4:19 pm, edited 1 time in total.
Some UI behaviour I found that's strange (at least for the Winamp plugin bit) -- this probably has existed for a while and isn't specific to 2.3 beta 2, just FYI:
1. Open Winamp, open an NSF
2. Double-click the song title area in the main Winamp window (to bring up the NSFplug UI)
3. Select a different song index number (e.g. song 3, song 6, whatever)
4. Double-click on the song title area in the main Winamp window again
5. Song index slider in NSFplug UI immediately jumps to song 1
The problem from what I can tell is that whenever the code for bringing up the UI window is run (whether the window is open or not), it always sets the song index slider position to 1. This one shouldn't be too hard to fix... I hope... :-)
I gave this a try, expecting to be unimpressed with audio (only because most retro audio emulation doesn't impress me). But it sounds good through headphones with some demanding tunes. It also worked without a hitch in Wine on Linux. Lots of options for altering soud too. Only thing that stood out is that it used around 15% CPU on a 1.8 GHz Core 2 Duo (where 100% is both cores fully occupied).
Yes, the default settings go for quality over performance, though you can change this in the options (each audio unit has a separate performance slider; I intend to replace this with a single control eventually). Aside from the noise channel, most things sound OK at lower performance (just with a bit stronger aliasing, generally).
I do plan to do a performance optimization pass eventually, especially on how oversampling is done, but it's been less of a priority. I'm more interested in getting correct emulation first, but also as I said you can sacrifice accuracy for performance in the options.
Also, right now the FDS specifically is currently in the middle of a complete rewrite, and the state it's in for this beta is a lot more performance intensive that it should be (will be fixed by the time 2.3 is ready for release).
Correctness over performance, music to my ears! It runs real-time on any machine made in the last 8 years or so. Sorry, I still need to work on being overly concerned with performance when it's already sufficient.
blargg wrote:Correctness over performance, music to my ears! It runs real-time on any machine made in the last 8 years or so. Sorry, I still need to work on being overly concerned with performance when it's already sufficient.
Any machine, or specifically any PC? Just as severe compromises were needed to run emulators on the GBA and DS, some compromise is needed nowadays for Android devices. But I agree that pursuing correctness first allows better results once it comes time to trim down the design for handhelds, just as PocketNES benefited from having been based on LoopyNES and not its competitors at the time (iNES and Nesticle). Besides, even on a PC, a music player is expected to use single digit percent of the CPU because the user expects to have cycles left to do other things while it is running in the background.
tepples wrote:Any machine, or specifically any PC?
It works fine (somewhere around 50% CPU) on my still-being-used Athlon-1333 desktop with a single expansion audio. Multi-expansion of course is too demanding.
The actual problem for a port to Android is battery, not cpu speed.
