Currently the following restrictions apply (to method 1, currently the only method available):

The source files must not use bankswitching.

You may not combine NTSC and PAL files together unless some files are compatible with both NTSC and PAL, and the other files (if any) are NTSC-only, or PAL-only, but not both.

The only expansion chips usable are Namco 163 and MMC5. (The reason is that others will conflict with FDS RAM. If the input uses FDS, then it might use $6000-$7FFF, and this program requires that memory for its own use, so FDS cannot be used in the input either.)

The output will use Famicom Disk System, so the output of this program cannot be given as input to this program. (The FDS audio is not used; but the memory range $6000-$7FFF will be used, four bytes of which are being used as RAM, although these four bytes of RAM are also used as instruction operands!)

The output will use bankswitching, which is another reason that the output cannot be given as input to this program.

Method 1 uses up 3 clock cycles of the play routine, unless all the inputs have the same play address in which case it does not use up any clock cycles.

Thanks for the suggestion; I too want it to be able to combine NSFs using any expansion chips; however, I am unsure how to implement this. I have some ideas (execution tracing to decide what area of ROM and RAM is unused and can be used for the combiner), and if you have any other ideas you can tell those to me as well, please. (This can be called "method 2"; the current version is "method 1", and method number zero is reserved to try each method until one of them does not result in an error, and use that one.)

Do you know what other features the VRC6 NSFs use? Bankswitching? NTSC/PAL? Multiple songs in the input files? Do they ever execute code from RAM?

Perhaps if you know what kind of algorithms can be used too; I posted my ideas above, but don't know if there is some better way.

Quote:

Is there any way around the FDS RAM usage?

Probably if the execution tracing I wrote about above is done, then it could work without FDS. (The current method is very simple and has to be careful not to overwrite the rest of the song.)

I'm afraid I know bugger all about any sort of programming, so I wouldn't be able to help. :<

I can tell you the files I need to merge use bankswitching and that they have the NTSC flag only (no dual NSFs). That's all I can say, I'm afraid. I am but a musician...

Then, if this idea of execution tracing is used, it would also have to trace all bankswitching and then recompile the program to use different bank numbers! If the bank numbers are being calculated, or the bank numbers are being used for things other than bank numbers, then it would have to add instructions, and might interfere if exact CPU clock timing is required.

Another simpler idea (probably not relevant to what you are doing, though): If no more than one input file uses bankswitching: Set a high bank number used for the init routine which sets up everything and calls the input file's init routine (it could copy a part of itself into RAM and execute there before switching the initial banks). If the play addresses differ, then it should also ensure no input files use MMC5 ExRAM, so that the jump to play routine could be stored there.

rainwarrior wrote:

NSFPlay intentionally blocks FDS ram writes from conflicting locations if other expansions are enabled, so VRC6/VRC7/5B should not cause a problem for that player.

All bets are off for other players. Implementations of FDS RAM for NSF players differs widely.

Yes I know, the implementation can differ widely and that the specification says about those things. (If you know you are using it only with players that block FDS RAM writes from conflicting locations, you could modify CombiNSF to ignore that error.)

If you want to know about CombiNSF working you can look at the source-codes! Even modify if you like to do so; it is designed that methods can be added, and method 0 to try each method until finding one which is not error. (If anyone send a patch, I might add it; if I figure out the algorithms myself, I will program them myself.)

You may not combine NTSC and PAL files together unless some files are compatible with both NTSC and PAL, and the other files (if any) are NTSC-only, or PAL-only, but not both.

No input files can use MMC5 unless the play routine addresses for all input files are the same.

If any input file uses FDS, then none of the input files without FDS can use VRC6, VRC7, and Sunsoft.

The output will use bankswitching and MMC5.

The play routines for the input files must exceed $5C0A.

Method 2 uses up 3 clock cycles of the play routine, unless all the inputs have the same play address in which case it does not use up any clock cycles.

I intend also to add an option, for both method 1 and method 2, which tells it to ignore some of these restrictions, and continue anyways (possibly resulting in an invalid .NSF but this is your fault for selecting this option in cases when it doesn't work).

Who is online

Users browsing this forum: Yahoo [Bot] and 3 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum