If my goal it to be able to mute some channel so I can play some sound effects, would it make sense to:
- Make a variable that contain status of every channels
- 1 bit = 1 channel
- If channel square1 is off, in apu.s, it would jump to square2 label without the need to do anything (or may need to shut off channel at least once)
It's a quick hack but maybe that could be enough? The only thing is the music data would still be processed anyway but that channel would not be played.
This is just a conceptual hack, I still have to learn your code. Do you think that it would work?
I really wish at least ONE of the NES game making companies would release the source code to one of their games. It would answer so many questions. I think you'd be best off asking this question in the NESdev forums.
banshaku: Yes that is how I would do it, the music is still being played in the background but not updating the APU. All APU register writes are in apu.s so that is the only file you need to modify.
I really wish at least ONE of the NES game making companies would release the source code to one of their games. It would answer so many questions. I think you'd be best off asking this question in the NESdev forums.
I don't think releasing their code would solve my current issue since every game company had their own way to play music on the nes, with their own format.
I did ask on the nesdev forum but this question is specific to JSR's nsf player code so I had to ask him directly. This is why the question is in the source and development forum too.
The nesdev community does use his driver but doesn't know how to make sound effects with it. This is one limitation (from a game perspective) and I want to fill that gap and explain it to them after. If I make it work, this could increase the use of this sound driver, which is always a good thing.
jsr wrote:
banshaku: Yes that is how I would do it, the music is still being played in the background but not updating the APU. All APU register writes are in apu.s so that is the only file you need to modify.
So my educated guess what good. Thanks for confirming it, I really appreciate it. Once I can make it work, I will let you know.
I did ask on the nesdev forum but this question is specific to JSR's nsf player code so I had to ask him directly. This is why the question is in the source and development forum too.
Just to let you know that I did the experiment and it worked. I was able to make a proof of concept. The targeted channel was disabled and I was able to play some sound and the music continued after.
So I should be able to make my sound fx engine soon.
Great! I can use the FT driver for my projects and I'm more than happy about that. That's quite a time saver.
By the way, since you seems to implement VRC6 in the newest version of FT, does that imply a big impact in the driver source code?
I should also point out that some special care is needed for the square channels, as those has a bug that resets the pulse phase when anything is written to the register that holds the high part of the period. To get around this, the hight part is buffered and only written when needed. The variable var_ch_PrevFreqHigh is used for that so you might want to write it manually after the channels are enabled again.
For square 1: var_ch_PrevFreqHigh should be written to $4003
and for square 2: var_ch_PrevFreqHigh + 1 written to $4007
Otherwise you might get some notes off pitch until it synchronizes again.
banshaku wrote:
By the way, since you seems to implement VRC6 in the newest version of FT, does that imply a big impact in the driver source code?
All VRC6 code is optional and is excluded with assembler if-statements if not used, so the size will remain the same.
I should also point out that some special care is needed for the square channels, as those has a bug that resets the pulse phase when anything is written to the register that holds the high part of the period.
I guess that must be the little issue that I found while testing. If I just close the channels, no problem. If I update all registers on a channel, sometime the song doesn't recover properly (noise was not an issue). So my first guess was that some registers state needs to be saved before playing the fx and then recovered.
I will try to test it and let you know how it went. If what you pointed out was the issue then all the issues for playing fx are fixed. Thanks for pointing it out, this will save me some time.
Good to know that VRC6 will have no impact and you can remove it. My question was more related about if you had plans to re-factor the code or it will stay in the same state as v2.0?
Thanks again!
Edit:
After applying your recommendation regarding square channels, it is now working 100%. Great!
Good to know that VRC6 will have no impact and you can remove it. My question was more related about if you had plans to re-factor the code or it will stay in the same state as v2.0?
It's mostly the same, but there are minor changes and fixes in all files and music data from the new tracker won't be binary compatible in older versions of the player. But I believe any custom code will be easy to adopt to the new version.
It's mostly the same, but there are minor changes and fixes in all files and music data from the new tracker won't be binary compatible in older versions of the player. But I believe any custom code will be easy to adopt to the new version.
Great, thanks for the information. I will use it as soon as it is available publicly.
I have one question regarding the ft_music_addr. You seems to save the address of this memory location just after the label with the instruction .word * + 2. I'm sure there is a reason behind it and I want to know why.
The reason I want to know this is that I'm porting the code to other assembler so the nesdev community can benefit from it. Some assembler doesn't support the command so you have to hard code the address.
It's already working with nesasm and I will try to port it to other assembler soon. If you have any interest in this, I can give you back the resulting code once my tweaking are over.
edit:
I was able to remove it and now the user can specify where the data is located. Removing it didn't seems to have any impact. I will still wait for your comment about it.
Sorry for the waiting. (It's exam times here right now)
banshaku wrote:
I have one question regarding the ft_music_addr. You seems to save the address of this memory location just after the label with the instruction .word * + 2. I'm sure there is a reason behind it and I want to know why.
The idea was to have a pointer table with pointers to different music data files, making it easy to add multiple songs into a single NSF. But it's not complete, the ft_load_song function needs some modification, so right now it's just reading the first address.
Funny that you're porting it to nesasm though, as that was what I started writing it in.
And I really appreciate your work, but I wonder if it's worth it considering it has to be ported again for each new version. (Right?) A method I believe is a little more convenient is to write some notes on how to compile it into a binary file that can be included with any assembler. (But I don't know, if porting can be automated then maybe it'll save more time)
Sorry for the waiting. (It's exam times here right now)
Don't worry about it, exams are more important right now so you should focus on that
jsr wrote:
The idea was to have a pointer table with pointers to different music data files, making it easy to add multiple songs into a single NSF. But it's not complete, the ft_load_song function needs some modification, so right now it's just reading the first address.
I see. Then for now the impact is none, good. What I had in mind is the game would have somewhere a table of pointers since music could be in different banks. You would feed this address to one zero page variable that would contains the address of the current music.
You lose a little a bit of performance since the address is not immediate but it remove one dependency to the driver. I will need to evaluate someday if this is worth it or not.
jsr wrote:
Funny that you're porting it to nesasm though, as that was what I started writing it in.
As for myself I started with ca65 right away and it was not an easy ride but I like it The reason I tried to do it is because many beginners start with nesasm and there is no easy way to play music/sound fx. I wanted to see how hard it would be to port it so I tried the one that seemed the most common. That make me learn more about the different assembler's force and weaknesses and make me learn more 6502 on the way too. I hope my "research" will contribute to other people someday.
jsr wrote:
And I really appreciate your work, but I wonder if it's worth it considering it has to be ported again for each new version. (Right?)
Yes, it would requires to be ported again for every new version and adding the new functionality at the same time too but it's not like you release 60 versions of the driver a year, right? So if you have an official maintainer, it wouldn't be an issue.
jsr wrote:
A method I believe is a little more convenient is to write some notes on how to compile it into a binary file that can be included with any assembler. (But I don't know, if porting can be automated then maybe it'll save more time)
If you do it that way, how can you specify to that binary where is the location of the pointer tables? I guess it must be hard coded to a specific address or something.
My guess is with a little bit of scripting, it could be automated. I'm sure it could be possible with perl or something similar.
Now I need to learn more about the APU's inner working because I want to be able to make my own sound fx and understand more about the driver. I checked the wiki but it seems quite overwhelming with all the tech talk. I will figure it out soon, once I can put more time into it.
If you need some help with the driver, let me know. I love music so I wouldn't mind to give some time once it a while. I already started to work on it anyway so I'm starting to understand it more little by little.
If you do it that way, how can you specify to that binary where is the location of the pointer tables?
It could either be hardcoded (easiest would be just to include the music data right after the driver code and get a complete binary file that's ready for play), or you could use the pointer table that was right now just pointing to the music data. It could be excluded from the binary file and defined right after it's included in the other program (The label ft_music_data will still point correctly).
banshaku wrote:
If you need some help with the driver, let me know. I love music so I wouldn't mind to give some time once it a while. I already started to work on it anyway so I'm starting to understand it more little by little.
Yes I will, and also if you get any different design ideas or anything you'd like to see improved then make sure to tell me.
My sample that show how to use the driver with sound fx is almost over. Works fine in ca65 and nesasm. The bug I have right now is with the square channels. I did restore register $4003/$4007 like you mentioned and it fixed most issues. But in certain circumstances, if you use some sweep in a sound fx, the square channel pitch is not restored properly. I didn't figure out the reason yet.
jsr wrote:
Yes I will, and also if you get any different design ideas or anything you'd like to see improved then make sure to tell me.
I don't have any issue with designing software, my problem right now is that my knowledge of the 6502 language, the APU and your code base is still too small to provide any useful design ideas or improvement. Once I know more about famitracker driver work flow, I should be able to provide some feedbacks
Edit:
Found the cause with the square channel. If sound fx use sweep, you must kill the sweep channel to restore it properly. Then the song is working fine.
Now what is left is with the noise channel. For some reason, the previous sound affect the next sound fx on this channel. It could be something similar. Will continue to analyze the APU.s source code.
I really wish at least ONE of the NES game making companies would release the source code to one of their games. It would answer so many questions. I think you'd be best off asking this question in the NESdev forums.
One problem with that is it'd probably still technically violate an NDA or something. Nintendo would have no real cause to punish a company for doing so, especially if that company doesn't even work with Nintendo anymore, but companies tend to be very reluctant to do that sort of thing.
.png){kind=avatar}
