Sound effects are sort of loading. As I was hoping, they're basically just a single-channel version of the music data, so I can use the same code to process them.
Not sure how the sampling works for them yet, but the music samples start at 0x20, so I'd have to imagine 00 through 1F are reserved for these. There are 5F3 bytes loaded into SPC RAM at 0x4800 from 31AE2 in the ROM, that appear directly before the music samples (which are swapped in and out dynamically as songs are loaded, whereas this block is loaded on game startup along with the effects themselves) -- I'd guess this block has the samples I'm looking for.
Thursday, January 10, 2013
Wednesday, January 9, 2013
SPC Stuff
Checking out how the game organizes SPC700 memory so I can do stuff like allowing sample expansion and warn if the samples you chose won't all fit into memory for a given song.
Looks like the DSP code runs until SPC address x4DF1, so I have about 70% of the RAM (45K) left to play with for samples and music data.
Edit: Meh, on second glance, the music data sits at 1A00, and runs until 2C00, between two blocks of code. Some of the larger songs (like the mana beast fight theme) take up almost this entire block. I'm going to have to do some reorganizing before longer songs are doable.
Edit2: Ah ha; the 2C00 block that appears after the music data (from C32137 in the ROM) seems to be the sound effects, something I hadn't found much on until now. Nice I guess, but moving it elsewhere would be nice... optimally I'd stick that stuff at 1A00, followed by the music, followed by the samples (which currently start at 4DF1 and run through pretty much the rest of the SPC RAM), that way all the dynamic stuff is in one big block, and I can shift it around as I please. I'm pretty sure all the static stuff (code, and presumably the sound effects) gets uploaded once when the game starts then never again. Music is also tricky because all of the offsets and jumps it uses are 16-bit ROM addresses, so I'm guessing it applies some static offset (like 1A00) to them to figure out where in SPC RAM to actually jump.
Kind of wish I had Tales of Phantasia's code that streams samples in and out as needed. That would be a hell of a project to import...
Looks like the DSP code runs until SPC address x4DF1, so I have about 70% of the RAM (45K) left to play with for samples and music data.
Edit: Meh, on second glance, the music data sits at 1A00, and runs until 2C00, between two blocks of code. Some of the larger songs (like the mana beast fight theme) take up almost this entire block. I'm going to have to do some reorganizing before longer songs are doable.
Edit2: Ah ha; the 2C00 block that appears after the music data (from C32137 in the ROM) seems to be the sound effects, something I hadn't found much on until now. Nice I guess, but moving it elsewhere would be nice... optimally I'd stick that stuff at 1A00, followed by the music, followed by the samples (which currently start at 4DF1 and run through pretty much the rest of the SPC RAM), that way all the dynamic stuff is in one big block, and I can shift it around as I please. I'm pretty sure all the static stuff (code, and presumably the sound effects) gets uploaded once when the game starts then never again. Music is also tricky because all of the offsets and jumps it uses are 16-bit ROM addresses, so I'm guessing it applies some static offset (like 1A00) to them to figure out where in SPC RAM to actually jump.
Kind of wish I had Tales of Phantasia's code that streams samples in and out as needed. That would be a hell of a project to import...
Tuesday, January 8, 2013
Trying to catch up
Yes, I'm still around. No, I haven't answered your emails. I have a bunch of them to go through. Hopefully get to it soon.
Lots of stuff still needs finishing and improvement. I've been touching up the MIDI importer, which has always worked like shit at best.
Lots of stuff still needs finishing and improvement. I've been touching up the MIDI importer, which has always worked like shit at best.
Tuesday, June 5, 2012
Stats and stuff
Playing around with numeric data.
Also, added editing capabilities to the title screen stuff.
Tile editor:
Also, added editing capabilities to the title screen stuff.
Tile editor:
Placement of tiles on the title screen:
Saturday, June 2, 2012
Friday, June 1, 2012
Thursday, May 31, 2012
Getting closer.
Suspicion confirmed. SOM is processing 16x16 JPEG blocks one at a time from almost the time you load the ROM. The Y channel is stored at $1600 (upper left 8x8 block), $1700 (lower left), $1800 (lower right), and $1900 (upper right). At $1A00 and 1B00 you find the downsampled Cb and Cr, respectively.
I wrote a little MATLAB script to generate an RGB image from data I found at these locations for the first block to test my theory. Here's the result compared against a zoomed-in screenshot of the game:
The colors are slightly off; I attribute this to one of three possible things.. one, the most likely, I fucked something up. Two, the game uses an 8-bit palette in the end (haven't gotten that far yet) and these color shifts are an artifact of paletting. Three, it's a difference between 16-bit and 24-bit color. I'd call three unlikely.
Anyway, it shouldn't be long before the editor can load this image, because (with minor bugs) the processing up to this point, including the Huffman tree lookup from the ROM data, Quantization matrix processing, and DCT are all implemented. Dropping a new image in as the title screen background will be interesting to implement.
I wrote a little MATLAB script to generate an RGB image from data I found at these locations for the first block to test my theory. Here's the result compared against a zoomed-in screenshot of the game:
The colors are slightly off; I attribute this to one of three possible things.. one, the most likely, I fucked something up. Two, the game uses an 8-bit palette in the end (haven't gotten that far yet) and these color shifts are an artifact of paletting. Three, it's a difference between 16-bit and 24-bit color. I'd call three unlikely.
Anyway, it shouldn't be long before the editor can load this image, because (with minor bugs) the processing up to this point, including the Huffman tree lookup from the ROM data, Quantization matrix processing, and DCT are all implemented. Dropping a new image in as the title screen background will be interesting to implement.
Subscribe to:
Posts (Atom)





