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
I'm trying to figure out how to add Famitracker exports to prg code for NES using Bob Rosts's Nbasic.
Famitracker gives us NES NSF PRG and iNES exports but I don't know which one to use, and can't .incbin them in the assembly.
Can someone help me understand how to .incbin the binary music data into a .bas source code file in Nbasic?
Level data is at $8000 and game data is at $C000, but when I try to .incbin the binary music data at $ADDA like Famitracker says is the load address, no music appears in the NES rom image.
I'm not sure what I'm doing wrong. Does famitracker not make NES compatible music files? We need prg data without a header or padding or NMI's. Evidently the binaries are corrupted because they have some sort of interrupts going or fail to load at the address $ADDA that it says to use.
Can we get PRG music data without the cell padding? I don't need 32KB each time I export. I don't want the export as a solid prg bank on its own.
If possible, could you explain how to incbin the .bin music binary into a bas file. What address do I need to .org to before I incbin it?
How do we shave off the 0 padding?
Next release of Famitracker, can you let us export prg binary music data without padding or headers so we have 100% assembly to use in Nbasic instead of only getting a 32k complete rom image. I don't need an entire prg rom bank dedicated to music. I need the prg code to add to my code for incbinning the binary data in the rom I am making.
I don't know what Nbasic is, but there's not reason to use the .prg export for what you're doing. That's intended to build a stand alone ROM to play music, not integrate with other code.
I mean, you could put the PRG in one 32k bank in AxROM or something, and bankswitch into it to play music, but this is a very difficult way to go about it, I think. You will need to make sure your program is not trying to use any of the RAM famitracker's NSF driver needs to operate.
If you really want to integrate with your game code you should export as .bin or .asm, and also assemble the NSF driver directly as part of your program. It is written in ca65, though, and I don't know how well you can combine that with whatever nbasic is. Maybe you want to consider switching over to ca65?
The other thing is that Famitracker's NSF driver is not really designed to be used in games. It's okay for programs that just play music and not much else (here's an example I wrote that does this: [url=http://rainwarrior.ca/music/moon8.nes]moon8.nes / [url=http://rainwarrior.ca/music/moon8romsrc.zip]moon8romsrc.zip). If you want to use it in a game, I suggest you look up Shiru's Famitone, which supports a limited set of Famitracker's features and is designed to be used in games.
Thanks. I tried including the binary inside my programming code loading it in the $ADDA address it said was the loading address but there was still no sound.
The binary should be machine code, but the export doesn't work as a binary when we include it in assmebler.
Nbasic is a programming environment for making games for the NES console. It allows including binary data, but .bin Famitracker export isn't working, even at the correct loading address Famitracker says to load the binary at.
There's several 6502 disassemblers that will convert NSF to ASM, but I don't know why you want one. (cc65 comes with a disassembler is called da65).
cc65 is a collection of command line utilities for compiling/assembling/linking 6502 code. If you want a GUI, maybe try cpow's NESICIDE project? Also, there is documentation for cc65 on its website, and you can download it. It's in a separate zip from the compiler package.
Thanks, I'm taking a look at it right now. The odd thing is, I just made a hex editor and stripped the header from the NSF, and still no go with 100% binary data.
So, the NSF files contain no program data in any way. They just tell teh emulators what mode to run in.
I attached a screenshot of the NSF header from a quick program I threw together showing the load addresses.
The load address should have been $ADDA as Famitracker output said it was, but it isn't. It threw in two extra addresses, $AF40 and $AF43
These two additional addresses are not load addresses. Perhaps whoever made Famitracker can correct this in their next release.
ADDA is the load address, AF40 and AF43 are the location of the INIT and PLAY routines. This is described in the NSF spec document you have open in that picture.
What are you proposing should be fixed in the next release? This looks like a properly formed NSF header.
