nesdev.com

I'm experimenting with some song and one project has one that is so big, that the size is unfortunately a little bit bigger than 8k (one is 35k but I will forget about this one for now ).

With the way the mmc3 handles banks, and the fact that you need 1 for the driver, I guess it makes it quite hard to play songs bigger than 8k since 2 banks are fixed? Have anybody tried to do so for a music disk or something?

Thanks in advance for any pointer on the subject.

I don't know about FamiTracker driver, but I know of other drivers that have been used with bank switching.

• FamiTone spinoffs used in MMC3-clone games by Retrotainment support putting the driver and shared data (sound effects, etc.) in $8000-$9FFF and music sequence data in $A000-$BFFF.
• Pently in Nova the Squirrel (MMC1) puts music sequence data in one 16K bank and the driver in the fixed bank.

_________________
Pin Eight | Twitter | GitHub | Patreon

In my Vigilante Ninja 2 project, the music data was, like yours, just a little bigger than 16k and didn't fit nicely in movable banks.

I compiled all the music code and music data separately, and included them in the project as 3 binary files. 2 8k peices in 2 movable banks, and 1 small one that always lived in the beginning of the $c000-dfff fixed bank.

And then some DMC samples after that.

When the game swapped the music code into place, it formed 1 big contiguous music segment.

35k is a little more problematic.

_________________
nesdoug.com -- blog/tutorial on programming for the NES

@tepples

Right now I'm looking for a possible solution with famitracker so switching to famitone/pently is not an option for this project. Maybe I can test pently on a new one, someday

@dougeff

my current engine actually bank switch the driver and the song in the nmi so this part is already done. All songs are split to avoid size issue. The problem is more subtle and may have not been clear from the message: one song is actually 9k It's not something that would be used during game play but for that specific case, I'm trying to find a way to play it without having it to be edited in some way. I need to recheck the mmc3 specs but since I cannot really put the driver in the fixed bank, I guess I won't be able to play that one, or the 35k medley ^^;; (I'm not joking, it's that big, so that one is out of the question haha).

So the only way would be to put the driver in the fixed bank to allow the song to be played, or a way to play compressed data but.. that would means to adapt the driver for that and I don't think I have the time or knowledge to update it. Hmmm... If the data is set at $a000, it would spill a little bit in $C000.. That's one possibility.

I'm not in rush yet for that edge case so I will look at all solutions that can be done before doing that The cause of the size is because it's a cover and to make it as accurate as possible, the data became quite huge. Not much I can do for now.

You could possibly use mapper 31 instead of MMC3, which would support the Famitracker driver's built-in banking methods.

Otherwise, though, you'll probably have to modify both the driver and the Famitracker exporter to prepare data for a different kind of banking.

I was afraid that it was going to be that answer Still, at the least now I know what I can do from that point and decide what to do next.

Thank you for confirming!

If this is just about the 9KB song, you could put the majority of it into an 8KB bank, and the extra 1KB in an adjacent bank, either fixed or switchable (the one with the music engine) so that the song appears as a contiguous 9KB block. It's ugly, but if you don't want to modify the driver and it's only one song, this might solve the problem.

Another option which I gave privately but would have been better said here:

You can split a large song into separate songs, and detect the condition of end of song. (I think the C00 effect leaves an easy to check variable.) You can check for that and load the second song immediately to splice the two together.

Yes, the answer was better written here I was waiting to test it more before talking about it.

Regarding the halt command (ft_cmd_halt), when it occurs, it change the content of var_PlayerFlags, which means that for a jukebox scenario, since there is no real processing, I could check on every NMI event if the flag changed to stop and react to it. The value change test was done, was is left is to test connecting multiple song and see no issue occurs but it should be working.

That is a lot simpler than editing the driver to support mmc3 banking and adding the feature to famitracker, which was one of the many solution on my list ^^;;

edit:

tested and working fine