SPC data upload

Bregalad · Post by **Bregalad** » Wed Feb 24, 2010 3:15 pm

As far I know this is the only song that can't be played with .spc because it relies on constant SPC updates from the CPU (the SNES equivalent to constant $4011 writes hehe).

Post by **tepples** » Wed Feb 24, 2010 3:33 pm

Bregalad wrote:As far I know this is the only song that can't be played with .spc

That and Wario's Woods (and the rest of this list), including a lot of games that use the ARDI music engine. These rely on the host CPU to send NoteOn messages and the like. Or were you talking about rewriting its music engine from 65C816 to SPC700?

Post by **Memblers** » Wed Feb 24, 2010 3:43 pm

There's also stuff like my NSF player, and Sid Mania by Censor. I can't imagine why anyone wouldn't want to write an SNES demo with NES or C64 sound.

But the main thing is that it is absurd to have to load 64kB of data to play even a sound effect. Other than the general-purpose RAM, there's probably only a few bytes real difference between a lot of SPC files.

Post by **tepples** » Wed Feb 24, 2010 3:50 pm

Memblers wrote:But the main thing is that it is absurd to have to load 64kB of data to play even a sound effect.

You mean from the perspective of a generic SNES program, or from the perspective of an SPC player? As I understand it, a generic SNES program can load a couple instruments and start the SPC700 playing an opening drum fill while the rest of the instruments load, but most don't.

Other than the general-purpose RAM, there's probably only a few bytes real difference between a lot of SPC files.

Which is why SPC sets are distributed in a solid archive such as .rar or .7z: compression recognizes this and stores the majority of each file as references to the previous file in the set.

Post by **Memblers** » Wed Feb 24, 2010 6:50 pm

I mean from the perspective of an SNES program. Trying to play a set of SPC files is just painful. There would be too much load time, even if there was solid RAR type compression on SNES.

tepples wrote:As I understand it, a generic SNES program can load a couple instruments and start the SPC700 playing an opening drum fill while the rest of the instruments load, but most don't.

That's interesting, what games do that?

mic_ · Post by **mic_** » Fri Feb 26, 2010 9:05 am

I'm relieved to say that after a lot of BSNES tracing, looking at SPC files in hex editors, reading eKid's and Anomie's documentation, and good old-fashioned trial and error my loader now works with every single one of the songs in my test set (currently 19). I still need to do hardware tests with my latest code and clean things up a bit.

bunnyboy · Post by **bunnyboy** » Fri Feb 26, 2010 9:23 am

That is great news! Can't wait to see what I am doing wrong

Did you look at any production games to see what they were doing?

mic_ · Post by **mic_** » Fri Feb 26, 2010 9:34 am

If you mean which songs I'm testing with, they're all from production games.

But for the loading code I don't think it'd be useful to look at how the games were doing it, because they obviously weren't loading .SPC files.

blargg · Post by **blargg** » Fri Feb 26, 2010 11:27 am

I could put together the code I use. What is your test set (so I can be sure they work)?

mic_ · Post by **mic_** » Fri Feb 26, 2010 2:21 pm

Here is my code: http://jiggawatt.org/badc0de/spcplayer-1.zip
I've verified it on a real PAL SNES. If you don't get any audio output at first (occasionally happens on HW); press the reset button.

And here's my test set of .SPC files: http://jiggawatt.org/muzak/spctestset.zip

bunnyboy · Post by **bunnyboy** » Fri Feb 26, 2010 2:39 pm

Looks like we started from the same flawed sample code

Good idea putting F0/F1 in the init code. Just a couple questions:

How did you decide on $FF70 for init code?

Where do the io port init values come from?

Any idea why it sometimes doesn't start playing on real hardware? I noticed this too on files I knew worked.

mic_ · Post by **mic_** » Fri Feb 26, 2010 2:49 pm

How did you decide on $FF70 for init code?

It was $FFA0 in the original code, but I looked at some .SPC files in a hex editor and saw that at least one didn't have padding (all 00/FF) in that area. But all seemed to contain padding at $FF70..$FF8F, so I picked $FF70 as my starting address.

Where do the io port init values come from?

From $1F4..$1F7 in the .SPC file.

Any idea why it sometimes doesn't start playing on real hardware? I noticed this too on files I knew worked.

Who the hell knows..

It seems to happen a lot with songs from Squaresoft games, but not with songs from e.g. Capcom or Konami games.

bunnyboy · Post by **bunnyboy** » Fri Feb 26, 2010 3:01 pm

From $1F4..$1F7 in the .SPC file.

OK duh

blargg · Post by **blargg** » Fri Feb 26, 2010 3:46 pm

Wow, your test set kicked my player's ass. These either sometimes played as silence, or always as silence:

bof2-10.spc
ff6-307.spc
gp-20.spc
gp-32f.spc
Map.spc
smw-12a.spc
Wild-F.spc

I'll have to go through my code and post it in a day or so.

Bregalad · Post by **Bregalad** » Sat Feb 27, 2010 2:01 am

Just an idea for the startup code... games usually have an echo buffer where the SPC stores output samples to be feed-back later to create an echo effect. Since this buffer will never by used to store code, variables or samples, it should work to place the init code here - but maybe a click will be heard on the start of the song.

I'm pretty sure Squaresoft games uses $fc00-$ff00 to store variables - as I have partially reverse engineered Secret of Mana's sound engine, and the other games uses a variant of it. Secret of Mana uses $ff00-$ffff to store repeat stacks or something, so if you alter anything here it will go crazy, fetch incorrect sound data etc... so no wonder it don't work !

The problem would be for SPC files which doesn't use, such as Super Castlevaia IV.