Deprecated: mysql_connect(): The mysql extension is deprecated and will be removed in the future: use mysqli or PDO instead in /storage/content/49/145849/famitracker.com/public_html/forum/classes/dbHandler.php on line 29
FamiTracker
What is the BPM value that is equivalent to the NES's APU speed? I'm making a NES game, so I need to know what is the correct value. It would make it a lot easier when I'm going to convert the songs for the game because I can just count a row as one APU cycle.
I mean the speed that the APU is clocked at. I read somewhere once that the APU runs different speed when compared to the CPU, however I don't remember whether it was faster or slower.
Both the APU and CPU are using the same clock speed, but the music update rate is typically clocked by the video refresh rate, which is 60Hz for NTSC or 50Hz for PAL.
Keep the tempo setting at 150 for NTSC or 125 for PAL to avoid unnecessary tempo calculations.
I'm assuming based on what you said and your signature that you are actually doing this for the console so...
There is a difference due to how the [url=http://wiki.nesdev.com/w/index.php/APU_Frame_Counter]APU Frame Counter operates. It only really matters if you use any of the built-in hardware features, like the envelope, sweep units or the triangle linear counter, because these can operate faster than the 60/50Hz video refresh rate. It also has two different speeds for the hardware features.
At first it was interesting to use these automated controllers for sound but it's very limiting. You can't restore the sound when it's interrupted by a sound effect, and it only makes sense to use them in a game if you're on a limited NROM cart. Oh, and also be sure you never enable the Frame Counter IRQ because it's not in synch with the PPU, and its only use is if you used the 2A03 for audio-only purposes.
The sound changes at 60/50Hz because the sound engines calculate and prepare the current state of the APU registers every frame, and put it in a buffer, which is then copied to the real APU registers when the PPU goes into Vertical blanking and fires the NMI interrupt (whic happens 60/50 times a second) At least that's how I do it. You just have to make sure you keep a copy of $4003 and $4007 from the previous frame, because you should only write to the high pulse periods when they change, otherwise you will keep resetting the phase every frame. You can keep writing to the triangle and the noise registers every time safely.
[quote=jsr]Both the APU and CPU are using the same clock speed, but the music update rate is typically clocked by the video refresh rate, which is 60Hz for NTSC or 50Hz for PAL.
Keep the tempo setting at 150 for NTSC or 125 for PAL to avoid unnecessary tempo calculations.[/quote]
So that is 60 rows per second. It seems like 900 BPM is the correct speed (or at least very close).
[quote=za909]I'm assuming based on what you said and your signature that you are actually doing this for the console so...
[/quote]
Not sure if for real console, but at least for emulator. It depends on if the game is a success and worth putting on a cart.
[quote=za909]
Oh, and also be sure you never enable the Frame Counter IRQ because it's not in synch with the PPU[/quote]
Yeah, that's not a good idea. I'm using IRQs to make the background wobble (kinda like in RECCA), and enabling the IRQ by the APU would trigger the IRQ unnecessarily and cause a glitched wobble, because the flag telling the NMI to reset the IRQ variables in not set.
Yes, by deafult it's 60 rows per second, but obviously you want to have notes longer than a single video frame... This format was suggested to me at the nesdev forums, but the Capcom sound engines also work like this, that's what I mainly got inspired by:
The notation format is this for a single byte:
If the byte is less than $20, it's an effect command (vibrato, arpeggio, whatever)
LLLN NNNN
5-bit value N = Note value
3-bit value L = Note length, 0 means it's an effect command
I take the 5-bit number N and add 12 to it (because 12 semitones per octave!) based on another RAM value I use to determine the current octave of the channel. As N can be way more than just $0C, you can access "two and a half" octaves at a time without switching to a different octave (which is also done with an effect command)
Then I calculate how many video frames the note will last, by taking a RAM byte meaning the speed of the song, which I load into the Accumulator and ASL "L minus 1" times, this will basically mean that at speed 7, if you shift it 0 times, it will last for 7 frames, which is exactly 1 row at speed 7. If you shift once, it's going to be 2 rows = 14 frames, or shift twice, then it's 4 rows = 28 frames, and so forth... it's a good idea to devote two bytes to storing this calculated value, because you might end up with something that has a duration longer than 255 frames. Then you decrease this duration once per frame, and when it is zero, you read the next note...
This doesn't allow for alternating speeds though, but is fairly easy to program.
Now in my program I also made a "half-row" configuration, which of course should not be used with odd speeds, that's why I do it a bit differently here: [url=http://pastebin.com/d2Gbt7bP](My ASM6 example)
The correct NTSC video rate is 59.94 Hz, but the NES actually outputs at a rate closer to 60.099 Hz. However it doesn't matter much.
[quote=Baka94]So that is 60 rows per second. It seems like 900 BPM is the correct speed (or at least very close).[/quote]
Ok I see now what you meant in your first post. Yeah 900 BPM (speed = 1, tempo = 150 and default highlight settings) is equal to one row / update cycle, but it's not very practical to use. How did you intend to convert the music to your game?
From my work on NSFPlay Synthesia, it runs NSFs at exactly 60fps (if I used a number slightly lower or higher, even by 0.001fps, it would eventually desync) and outputs wav as though the fps was 60.0024. I don't know where the difference comes from.
Similarly, Famitracker also tries to run at exactly 60fps, and I measured the wav output and it was more like 59.994fps.
In any case, 60fps is the 'correct' number. Even though NTSC NESes run at 60.0988fps (source: [url=http://tasvideos.org/PlatformFramerates.html]http://tasvideos.org/PlatformFramerates.html ) .nsfs created by Famitracker are at exactly 60fps.
(By the way, the reason why NTSC TVs and NTSC NESes can have different fpses but still look silky smooth, is because TVs have an ability to lock onto a framerate that is very close to their intended one, and use that instead.)
As I understand it, FT can use arbitrary interrupt speeds as long as the frequency is a whole number. By default it's set to exactly 60hz to match closely (not exactly) to the hardware's 60.0988 refresh rate. As a result, FT NSFs also play at the slightly slow exactly 60hz.
[quote=Patashu]is because TVs have an ability to lock onto a framerate that is very close to their intended one, and use that instead.[/quote]
Ah, that's why the picture in the beginning like goes down and comes down from the top and like wraps around (yes, fantastic explaination, I know).
