Communication protocol with S-SMP over $2140
Moderator: Moderators
Forum rules
- For making cartridges of your Super NES games, see Reproduction.
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: Communication protocol with S-SMP over $2140
SNSF does sound like it's heading in that direction.
I was thinking also of how using the Winamp plugin API works by filling out a table of function pointers. You might look at it for reference as to what a music player might need:
https://github.com/bbbradsmith/nsfplay/ ... /sdk/IN2.H
The thought was just that specifying an interface layer directly as S-SMP communication is too deep; you've got a lot more constraints down there than at the CPU level, where you have a ton of flexibility.
You could write the CPU side player protocol on top of any existing engine (this is what I was comparing the NSF INIT stub to), and that player interface code doesn't have to be directly part of the engine or its code, so it's not an encumbrance to it.
As far as IPL recovery, it seems to me that any engine that can upload arbitrary data should be able to get back to that, shouldn't it? (How do SPC players on the SD2NES/PowerPak manage to switch tracks without a reset?)
I was thinking also of how using the Winamp plugin API works by filling out a table of function pointers. You might look at it for reference as to what a music player might need:
https://github.com/bbbradsmith/nsfplay/ ... /sdk/IN2.H
The thought was just that specifying an interface layer directly as S-SMP communication is too deep; you've got a lot more constraints down there than at the CPU level, where you have a ton of flexibility.
You could write the CPU side player protocol on top of any existing engine (this is what I was comparing the NSF INIT stub to), and that player interface code doesn't have to be directly part of the engine or its code, so it's not an encumbrance to it.
As far as IPL recovery, it seems to me that any engine that can upload arbitrary data should be able to get back to that, shouldn't it? (How do SPC players on the SD2NES/PowerPak manage to switch tracks without a reset?)
Re: Communication protocol with S-SMP over $2140
Super PowerPak has the ability to drive /RESET.rainwarrior wrote:How do SPC players on the SD2NES/PowerPak manage to switch tracks without a reset?
Re: Communication protocol with S-SMP over $2140
That's what the sd2snes does, as well.
Re: Communication protocol with S-SMP over $2140
But a production Game Pak does not.
I was referring to something at roughly this level:
Command: No operation
(Must be performed between operations with the same ID number)
write NO_OPERATION to $2140
wait for $2140 to equal NO_OPERATION
Command: Start track
write track number to $2141
write START_TRACK to $2140
wait for $2140 to equal START_TRACK
Command: Play sound effect
write sound effect ID to $2141
write volume to $2142
write pan to $2143
write PLAY_SOUND_EFFECT to $2140
wait for $2140 to equal PLAY_SOUND_EFFECT
read the voice number from $2141 for later use, such as to stop a looping effect
Command: Exit to IPL
write EXIT_TO_IPL ($AA) to $2140
wait for $2140=$AA
I was referring to something at roughly this level:
Command: No operation
(Must be performed between operations with the same ID number)
write NO_OPERATION to $2140
wait for $2140 to equal NO_OPERATION
Command: Start track
write track number to $2141
write START_TRACK to $2140
wait for $2140 to equal START_TRACK
Command: Play sound effect
write sound effect ID to $2141
write volume to $2142
write pan to $2143
write PLAY_SOUND_EFFECT to $2140
wait for $2140 to equal PLAY_SOUND_EFFECT
read the voice number from $2141 for later use, such as to stop a looping effect
Command: Exit to IPL
write EXIT_TO_IPL ($AA) to $2140
wait for $2140=$AA
Re: Communication protocol with S-SMP over $2140
Bumping because of something NovaSquirrel dug up in the SNESdev Discord server.
Kankichi, the sample sound driver provided alongside the IS-Sound unit to authorized developers, establishes a communication protocol for music per sneslab.net. The S-CPU writes a value to $2140, and the driver echoes it back a couple ticks later after it has been processed.
2140=00: switch to silent track
2140=01 to nn: play track
2140=F0: pause music playback
2140=F1: continue music playback
2140=FF: load new data (basically return to IPL without clearing ZP/stack)
This protocol is adequate for a homebrew ROM containing a collection of SPCs. It would need extension for a game, as Kankichi appears to have shipped without sound effect support. Each developer was expected to add its own framework for those. Many (or perhaps most) extensions dropped compatibility with the basic music switching protocol.
Even if one were to just delegate defining the protocol to the S-CPU side, as rainwarrior suggested, this would still require someone to determine what API on the S-CPU side would be useful to a large fraction of games. What would be needed in 1. a sound effect data format and 2. a protocol to trigger sound effects? Would it be helpful for me to make a 1:1 port of one of my NES games to the Super NES just for the sake of having a baseline to start from sound-wise?
In my opinion, this attitude is among the things discouraging people from even getting started on this platform. There are things which must be solved before a game jam can succeed, and defeatism won't help solve them. With that out of the way:
Kankichi, the sample sound driver provided alongside the IS-Sound unit to authorized developers, establishes a communication protocol for music per sneslab.net. The S-CPU writes a value to $2140, and the driver echoes it back a couple ticks later after it has been processed.
2140=00: switch to silent track
2140=01 to nn: play track
2140=F0: pause music playback
2140=F1: continue music playback
2140=FF: load new data (basically return to IPL without clearing ZP/stack)
This protocol is adequate for a homebrew ROM containing a collection of SPCs. It would need extension for a game, as Kankichi appears to have shipped without sound effect support. Each developer was expected to add its own framework for those. Many (or perhaps most) extensions dropped compatibility with the basic music switching protocol.
Even if one were to just delegate defining the protocol to the S-CPU side, as rainwarrior suggested, this would still require someone to determine what API on the S-CPU side would be useful to a large fraction of games. What would be needed in 1. a sound effect data format and 2. a protocol to trigger sound effects? Would it be helpful for me to make a 1:1 port of one of my NES games to the Super NES just for the sake of having a baseline to start from sound-wise?
Re: Communication protocol with S-SMP over $2140
If targeting a game, just use GSS. No need to expend effort remaking a protocol.
Re: Communication protocol with S-SMP over $2140
Even out of context, that line doesn't amount to "defeatism". The SNES commercial library is immense and renowned. Even if everyone here managed to finish all of our dream projects, it still wouldn't erase those games, or their music. Any reasonable projection of success will still leave the top echelons of the SNES library largely populated with games like Chrono Trigger, Donkey Kong Country 2, Final Fantasy VI, Yoshi's Island and so on. And there's been a lot of homebrew and chiptunes made already, also without a standardized audio protocol.tepples wrote: ↑Fri Feb 04, 2022 10:23 pmIn my opinion, this attitude is among the things discouraging people from even getting started on this platform. There are things which must be solved before a game jam can succeed, and defeatism won't help solve them.
What exactly would you be trying to accomplish with a common standard at this point?
That's all I'm saying.
Re: Communication protocol with S-SMP over $2140
This is true. There's a difference between 'defeatism' and actually admitting the current truth about the current state of SNES homebrew. That being said, you can choose to focus on how the current state of SNES homebrew doesn't appear to have any hopes of getting to a commercial level, or you can choose to promote working towards making that goal more and more realistic.93143 wrote: ↑Sat Feb 05, 2022 6:20 pmEven out of context, that line doesn't amount to "defeatism". The SNES commercial library is immense and renowned. Even if everyone here managed to finish all of our dream projects, it still wouldn't erase those games, or their music. Any reasonable projection of success will still leave the top echelons of the SNES library largely populated with games like Chrono Trigger, Donkey Kong Country 2, Final Fantasy VI, Yoshi's Island and so on.tepples wrote: ↑Fri Feb 04, 2022 10:23 pmIn my opinion, this attitude is among the things discouraging people from even getting started on this platform. There are things which must be solved before a game jam can succeed, and defeatism won't help solve them.
What do you mean by 'a lot'?
I believe Tepples is trying to get chiptune beat producers into making music for SNES games and trying to motivate programmers to program an SPC sound engine so that SNES games can have mixtapes that live up to the fire beats of the commercial SNES games of the '90s.
I have an ASD, so empathy is not natural for me. If I hurt you, I apologise.
Re: Communication protocol with S-SMP over $2140
Why didn't he say so? What I've read in this thread seems to have more to do with playing back collections of tracks in a SNES music player than encouraging collaboration between developers.Nikku4211 wrote: ↑Mon Feb 07, 2022 4:52 amI believe Tepples is trying to get chiptune beat producers into making music for SNES games and trying to motivate programmers to program an SPC sound engine so that SNES games can have mixtapes that live up to the fire beats of the commercial SNES games of the '90s.
And from that perspective the case seemed weak, specifically because it's so late in the day and so much stuff (not only commercial stuff) has already been written without any common standard. Furthermore, there are multiple music engines in ongoing use by the community, and I don't suppose they're compatible. The implication seemed to be that all that stuff could be safely disregarded. Forcing everyone in the community to conform to an I/O standard seems like a bit of a heavy hammer if it's just for a compo cart or two...
Re: Communication protocol with S-SMP over $2140
For the purpose of playing back existing songs in a music player, maybe it could it be possible to convert the spc files into a "midi-like" format? One could modify an existing APU emulator to record which values were written to what APU registers in any frame of playback and make a series of APU instructions out of it. The resulting data should by highly compressible for example with lz4 and maybe you could decompress that on the cpu on the fly and stream the result into the APU via a custom driver (or even do some decompression on the APU itself).
The only thing which is missing would be sample data (and the echo buffer), for which you might be able to autodetect where they are located at in the RAM and maybe also move them around so that you can have a fixed place where you upload the converted sequence data.
If something like this is possible, it would allow for changing the song without reset.
I doubt it really works, because I suspect bandwidth / ROM size will become too much o an issue, but maybe it's something to think about.
The only thing which is missing would be sample data (and the echo buffer), for which you might be able to autodetect where they are located at in the RAM and maybe also move them around so that you can have a fixed place where you upload the converted sequence data.
If something like this is possible, it would allow for changing the song without reset.
I doubt it really works, because I suspect bandwidth / ROM size will become too much o an issue, but maybe it's something to think about.
-
- Posts: 275
- Joined: Wed Jul 09, 2008 8:46 pm
Re: Communication protocol with S-SMP over $2140
Yup, and I compiled that info myself, too, with both my own research and a few other sources.tepples wrote: ↑Fri Feb 04, 2022 10:23 pm Bumping because of something NovaSquirrel dug up in the SNESdev Discord server.
In my opinion, this attitude is among the things discouraging people from even getting started on this platform. There are things which must be solved before a game jam can succeed, and defeatism won't help solve them. With that out of the way:
Kankichi, the sample sound driver provided alongside the IS-Sound unit to authorized developers, establishes a communication protocol for music per sneslab.net. The S-CPU writes a value to $2140, and the driver echoes it back a couple ticks later after it has been processed.
2140=00: switch to silent track
2140=01 to nn: play track
2140=F0: pause music playback
2140=F1: continue music playback
2140=FF: load new data (basically return to IPL without clearing ZP/stack)
This protocol is adequate for a homebrew ROM containing a collection of SPCs. It would need extension for a game, as Kankichi appears to have shipped without sound effect support. Each developer was expected to add its own framework for those. Many (or perhaps most) extensions dropped compatibility with the basic music switching protocol.
I've been looking at them... and so far I've seen it both ways. Some of them keep those exact commands and add on to them, and some of them do some more radical modifications that make this practically unrecognizable externally, not so much internally.
Interestingly, from the original source code I looked up, currently I'm still trying to figure out if any extant builds used the commented out sections of code in exactly the way they were described.
If it weren't for a serious flaw that was fatal for Incognity specifically, then I would actually agree. The problem with SNESGSS in its current state is that it is vulnerable to NMI/VBLANKs on the SNES/65816 side when trying to acknowledge, as the SPC700 side clears out its output shortly afterwards.
I'm working on my own sound driver, and I've recently cleared a misunderstanding after finally listening to the video: namely, when clearing latches, only the values read by the SPC700 through $F4-$F7 are cleared, not the values sent from the SPC700 to the SNES (in those cases, you'd not use the CONTROL/$F1 register, but store zeroes directly to $F4-$F7). Interestingly, except for the music and SFX format and possibly a revision on the protocol, I think I have something that works.
Also, now that I think of it, I need to record that IPL Boot ROM protocol on the wiki. I've been using a specific hex representation format that represents the four registers. That is critical to ensuring that anyone can load a program.
Also, there are ways to lose the ability to switch out of the sound driver. I've actually been recording a list of them locally, and SimCity's the earliest one that lost the ability to load new data and subsequently, load a new sound driver. The other Kankichi cases are mostly not affected because they kept the loading code or jumped to the IPL Boot ROM.