I'd like to test out a small computer I am building from a NES 2A03, and would like to test out the ALU. Trying to figure out the way the NSF format is setup, but it seems you need to basically have the whole NES memory map available to you.
My computer is setup as this: $0000-$1FFF SRAM, $E000 - $FFFF ROM, $4000-(w/e the end of the ALU and joystick address is).
I'd like to rip out just one song, so it can fit on the 8kb chip.
Turn the NSF into a NES file, then use FCEU's Code Data Logger to make a stripped rom, then turn it back into a NSF.
But I don't know if that will work very well, since NSF files are programs, not just data. You'd need to do a lot of hacking to make it fit within the E000-FFFF area, unless 8000-FFFF is also mirrors. If it's mirrors, then you can separate the music code and the data, and hope they don't overlap.
I have songs that I made that are under 8kB, they load at $C000 or $C080 though. You'll have to mirror your ROM space at $8000+ to have much of a chance. I can re-upload those and post a link if it will help. And there probably are very few NSFs that are under 8kB (even with a single song, they might be far apart in the address space).
Just to understand NSF a bit more:
The load address is where to start copying data to after the header correct?
Not sure what the init address does. It's a subroutine I assume, that takes what is in the accumilator. What it does to it I am not sure.
Play Address is the code that runs every song frame?
The load address tells you where in emulated memory to load the NSF data into. I think it's a waste to have that kind of system, it just makes hex editing much harder, and it just doesn't make any sense when you use bankswitching.
The init address is very important, it initializes the music engine, and selects the song. Set register A = song number before calling INIT.
The Play address is what you call every frame after INIT has finished, usually called once per vblank. You can use APU Frame IRQ instead, as long as you hack the game to not disable them.
Dwedit wrote:
Turn the NSF into a NES file, then use FCEU's Code Data Logger to make a stripped rom, then turn it back into a NSF.
But I don't know if that will work very well, since NSF files are programs, not just data. You'd need to do a lot of hacking to make it fit within the E000-FFFF area, unless 8000-FFFF is also mirrors. If it's mirrors, then you can separate the music code and the data, and hope they don't overlap.
A small song like the Mario theme should still fit in 8k though, right?
Yes. The entire soundtrack for any NROM game, including the first Super Mario Bros., would probably fit in 8 KiB.
Stripped SMB1 ROM (music only):
Download
Vital stats of SMB1's music:
Total code: 0x399 (921) bytes
Total data: 0x890 (2192) bytes
And yes, the music code and data does overlap when mirrored into an 8K block of memory, so you can't use it directly. You'd instead need to use a disassembly of the game (which exists for SMB1), and relocate everything to be in one 8K bank.
Dah, the code and data indeed do not overlap, I was looking at a hacked up NSF file which had added code to start playback... The added code overlaps, not the original code.
Anyway, I made a music only version of SMB1...
Download.
This is 4k in size, repeating 4 times to fill 16k. Code origin address is $8000, hope you have mirrors there.
http://4x86.com/mm9-sm.zip
Mega Man 9.5 files edited to be smaller than 8K, hope you can test with these
Thanks for the help, will test em once I have time. Exam week coming up so I got to cram lol.