Communication protocol with S-SMP over $2140

Discussion of hardware and software development for Super NES and Super Famicom. See the SNESdev wiki for more information.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Communication protocol with S-SMP over $2140

Post by rainwarrior »

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?)
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Communication protocol with S-SMP over $2140

Post by lidnariq »

rainwarrior wrote:How do SPC players on the SD2NES/PowerPak manage to switch tracks without a reset?
Super PowerPak has the ability to drive /RESET.
Revenant
Posts: 462
Joined: Sat Apr 25, 2015 1:47 pm
Location: FL

Re: Communication protocol with S-SMP over $2140

Post by Revenant »

That's what the sd2snes does, as well.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Communication protocol with S-SMP over $2140

Post by tepples »

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
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Communication protocol with S-SMP over $2140

Post by tepples »

Bumping because of something NovaSquirrel dug up in the SNESdev Discord server.
93143 wrote: Tue Jul 25, 2017 5:45 pm To be blunt, I don't expect SNES homebrew to ever get within an order of magnitude of the combined quantity and quality of the commercial library.
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?
calima
Posts: 1745
Joined: Tue Oct 06, 2015 10:16 am

Re: Communication protocol with S-SMP over $2140

Post by calima »

If targeting a game, just use GSS. No need to expend effort remaking a protocol.
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: Communication protocol with S-SMP over $2140

Post by 93143 »

tepples wrote: Fri Feb 04, 2022 10:23 pm
93143 wrote: Tue Jul 25, 2017 5:45 pm To be blunt, I don't expect SNES homebrew to ever get within an order of magnitude of the combined quantity and quality of the commercial library.
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.
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.

What exactly would you be trying to accomplish with a common standard at this point?

That's all I'm saying.
User avatar
Nikku4211
Posts: 569
Joined: Sun Dec 15, 2019 1:28 pm
Location: Florida
Contact:

Re: Communication protocol with S-SMP over $2140

Post by Nikku4211 »

93143 wrote: Sat Feb 05, 2022 6:20 pm
tepples wrote: Fri Feb 04, 2022 10:23 pm
93143 wrote: Tue Jul 25, 2017 5:45 pm To be blunt, I don't expect SNES homebrew to ever get within an order of magnitude of the combined quantity and quality of the commercial library.
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.
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.
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 pm And there's been a lot of homebrew and chiptunes made already, also without a standardized audio protocol.
What do you mean by 'a lot'?
93143 wrote: Sat Feb 05, 2022 6:20 pm What exactly would you be trying to accomplish with a common standard at this point?

That's all I'm saying.
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.
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: Communication protocol with S-SMP over $2140

Post by 93143 »

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.
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.

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...
none
Posts: 117
Joined: Thu Sep 03, 2020 1:09 am

Re: Communication protocol with S-SMP over $2140

Post by none »

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.
KungFuFurby
Posts: 275
Joined: Wed Jul 09, 2008 8:46 pm

Re: Communication protocol with S-SMP over $2140

Post by KungFuFurby »

tepples wrote: Fri Feb 04, 2022 10:23 pm Bumping because of something NovaSquirrel dug up in the SNESdev Discord server.
93143 wrote: Tue Jul 25, 2017 5:45 pm To be blunt, I don't expect SNES homebrew to ever get within an order of magnitude of the combined quantity and quality of the commercial library.
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.
Yup, and I compiled that info myself, too, with both my own research and a few other sources.

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.
calima wrote: Sat Feb 05, 2022 2:51 am If targeting a game, just use GSS. No need to expend effort remaking a protocol.
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.
Post Reply