SPCcog - The sound of the Super Nintendo in a cog!
![Wuerfel_21](https://forums.parallax.com/uploads/userpics/693/n8QPDN86LL3XG.png)
And once again I appropriate @Ahle2's brand...
This is an emulation of the Nintendo/Sony sound module used in the Super NES / Super Famicom (consisting of an SPC700 processor and a custom audio DSP) that runs in one P2 cog.
Features:
• 8 channels of BRR sample playback
• 32kHz sample rate, accurate to real S-DSP
• SPC700 CPU emulation with instruction timings
• SPC file metadata parsing library (SPCmeta.spin2)
No fancy videos or demos this time, just a simple SPC file player. That functionality is positively "idiot-proof", just load the file into memory and off you go. Doing anything more complex requires writing some SPC700-side code, so, uhh, have fun with that.
Temporary Notice: You can't actually build the example with DEBUG enabled under flexspin right now. >_< Will probably be fixed soon, stand by. Until then, no metadata for you. No longer applies, but I think there's a different bug now...
Update V1.1: Fixed BRR decode clamping and added another sample file.
Update V1.2: Fixed BRR decode even more and added even more sample files.
Update V1.2.1: Fixed some files not playing due to uncalled-for echo RAM clearing and added an affected example file.
Comments
Yet another sound chip emulator... Compiles and works but SPCCog.spin2 file opens in Flexprop with this famous "every second char is space" character coding bug.
Huh.... works for me. The wonders of UTF-16.
![](https://forums.parallax.com/uploads/editor/tn/72anumwgu5x5.png)
Probably because it is a unicode file. If you have VIM you can load it and convert it to regular 8 bit text with the
:set fileencoding=utf-8
command then save it back with:wq
.For me it didn't - I recoded the file (and reduced its size x2) . This was Windows 11 - I will check this in Linux, maybe it is Windows only problem in Flexprop. The next thing to add this to the Propplay, which was not updated for a long time as I wanted to fully debug and add PSRAM support to the video driver first
(1) The file UTF16 coding error is WIndows only. Linux opens it properly. What caused the problem was probably ä in the comment.
to get the file info printed instead:
(2) I tried do do something with the SPCMeta in Basic to get the metadata printed, no success at all, and what was worse, there were very strange side effects.. I gave up and used retro old style programming mode
That, and the box drawing characters. It works fine on Windows 7 for me with latest FlexProp. I blame Win11.
There is a reason that file is so complex - there's two different ways the basic metadata can be encoded (though "text" mode is the more common) and then there's xid6 extended metadata (only way to get Publisher and Year fields and also where you need to get the basic fields from when they exceed 32 characters).
All the string functions in SPCmeta return ptr+length type strings and you have to check that length isn't zero.
The strange problem was:
If I called
it printed the name, so OK, I added
Now, nothing was printed at all. Then I tried to print also the length returned by GetSongTitle - which was called first. It was 2, or 65, or 0, with the same file, it depended on how many of these functions I called after
I think I did something wrong with pointers and addresses. Maybe tomorrow. I have a description of the file format including all these format variants.
No that just sounds like flexsploop. Have only tested the metadata reader on proptool because there's the aforementioned flexspin DEBUG bug wherein you can't actually pass multireturns into DEBUG (and I'm too dum dum to figure out how to fix it)
Just posted a V1.1 because I noticed a bug. Apparently decoded BRR samples need clamping. Makes the decode code a bit less nice / slower, but oh well. None of the gamerip files seem to rely on this behaviour, but one (1) drum sample in someone's Broken Moon chiptune cover SPC does (thanks youtube recommend algorithm lmao). Added that one to the examples to demonstrate. Sounds like this without fix:
yea....
Should probably mention @pik33 because I know he actually uses SPCcog.
It turns out there is yet more nuance to BRR decoding... It seems like the particular precision of the decoder matters when going near the maximum values, as the clamping is weirdly buggy (clamp values are double of what they should be? At least that's what looking at the blargg SPC core used in many emulators would suggest). Previous versions of SPCcog had an additional bit of precision in the decoding stage, which was causing overflows when decoding some samples. The weird clamping is still needed though, see example above, so some extra instructions had to be inserted![:( :(](https://forums.parallax.com/resources/emoji/frowning.png)
Uploaded V1.2 in first post.
Finally, somebody has made something tailored specifically for me. If I can't break it, nobody can.
But seriously, this is mighty impressive. Thanks for sharing.
Updated to V1.2.1 to fix a bug with initializing SPC file dumps. Some files have garbage in the echo RAM area that needs to be cleared out. This obviously shouldn't be happening if echo write is disabled through the FLG register and doing so anyways breaks some tunes.
EDIT: oops, uploaded bad file, fixed now.