About audio in rom bandwidth capabilities, and a external cpu...

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.
Post Reply
User avatar
Señor Ventura
Posts: 233
Joined: Sat Aug 20, 2016 3:58 am

About audio in rom bandwidth capabilities, and a external cpu...

Post by Señor Ventura »

According to various diagrams, the spc700 appears to share the bus data as a slave cpu, but using an external cpu for audio seems to bridge the spc700.

If this is correct, Could be used a mapper to separate audio in a rom, and graphics+program in another rom, and through an audio cpu have two effective ways to transfer data to audio ram from a side, and wram or vram from another side?.

The goal is to get two simultaneous transfers (samples and graphics), without delays or waitings.
creaothceann
Posts: 611
Joined: Mon Jan 23, 2006 7:47 am
Location: Germany
Contact:

Re: About audio in rom bandwidth capabilities, and a external cpu...

Post by creaothceann »

My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
Oziphantom
Posts: 1565
Joined: Tue Feb 07, 2017 2:03 am

Re: About audio in rom bandwidth capabilities, and a external cpu...

Post by Oziphantom »

the SPC700 only has the 8 data lines and 4 address lines exposed to the rest of the system. Also the SPC700 can not drive the external bus and has no way to control the external bus. It can't fetch data itself.

although I wonder if you can control the B bus form the cart and let the CPU run code from the A bus just as long as you don't touch the B bus with anything while it does its transfer...
Dartan
Posts: 8
Joined: Sat Apr 10, 2021 9:55 pm
Location: Germany

Re: About audio in rom bandwidth capabilities, and a external cpu...

Post by Dartan »

Oziphantom wrote: Sun Apr 11, 2021 4:09 amalthough I wonder if you can control the B bus form the cart and let the CPU run code from the A bus just as long as you don't touch the B bus with anything while it does its transfer...
No, since the A and B bus share the same datalines. Furthermore, as nobody else is supposed to control the B bus, I would assume that the C-CPU permanently drives at least the control lines of the B bus, and possibly also its address lines.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: About audio in rom bandwidth capabilities, and a external cpu...

Post by lidnariq »

During access to addresses $21xx, the B bus is a copy of the bottom 8 bits of the A bus. During DMA it's driven according to the DMA registers.

The rest of the time, it does random weird things. I don't think it's ever undriven (although looking at the die shot would let us tell), but it seems to generally like to count up slowly (Mclk/32).

(Even if it were undriven, it wouldn't be particularly useful, because nothing else in the SNES would be listening when the control strobes are high)
User avatar
Señor Ventura
Posts: 233
Joined: Sat Aug 20, 2016 3:58 am

Re: About audio in rom bandwidth capabilities, and a external cpu...

Post by Señor Ventura »

From a ROM, physically there are two audio channels outside the data bus. Theoretically, we could get audio without interfering any kind of simultaneous data streaming on the data bus, and with a mapper it can achieve some big data fount to send audio data while can be transferred graphic and other audio data simultaneously.

Dividing a ROM in two ROMS, one with its 60 pinout, and the other with its 2 pinout under, could do the work with a mapper connecting both of these.

The thing is that these two channels appears to be analog audio, and it occupies a lot more space than the regular sample based audio to the spc700.


So, What about if the second rom with 2 pins is controlled with a mapper/audio cpu/dsp that process samples to build a theme, and then convert it to analog audio?. Potentially, that ROM would occupie a lot less space, right?, and could let transfer audio and graphics simultaneously.



Edit: oh... i just described some kind of a MSU1 xD
creaothceann
Posts: 611
Joined: Mon Jan 23, 2006 7:47 am
Location: Germany
Contact:

Re: About audio in rom bandwidth capabilities, and a external cpu...

Post by creaothceann »

That's how the SGB does its extra audio effects with Donkey Kong, afaik.
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
calima
Posts: 1745
Joined: Tue Oct 06, 2015 10:16 am

Re: About audio in rom bandwidth capabilities, and a external cpu...

Post by calima »

You just described a mp3 cart like exist for SNES and Gen. Chip decodes mp3s and outputs analog audio to the cart pins.
Dartan
Posts: 8
Joined: Sat Apr 10, 2021 9:55 pm
Location: Germany

Re: About audio in rom bandwidth capabilities, and a external cpu...

Post by Dartan »

creaothceann wrote: Sun Apr 11, 2021 1:56 pm That's how the SGB does its extra audio effects with Donkey Kong, afaik.
Afaik it's actually the other way around:

All regular audio of the Super Gameboy is using these analog audio cartridge pins (directly fed by the analog audio outputs of the GB CPU contained in the SGB module) and only these SGB-only extra audio effects like in Donkey Kong are using the typical SNES audio subsystem (SPC700 etc.) at all.
User avatar
Señor Ventura
Posts: 233
Joined: Sat Aug 20, 2016 3:58 am

Re: About audio in rom bandwidth capabilities, and a external cpu...

Post by Señor Ventura »

calima wrote: Sun Apr 11, 2021 11:48 pm You just described a mp3 cart like exist for SNES and Gen. Chip decodes mp3s and outputs analog audio to the cart pins.
Not exactly, i'm talking about using those analog channels for sample based audio, like the spc700, in order to get the whole frame time to transfer data instead the actual tiny window to do it.
Dartan
Posts: 8
Joined: Sat Apr 10, 2021 9:55 pm
Location: Germany

Re: About audio in rom bandwidth capabilities, and a external cpu...

Post by Dartan »

Señor Ventura wrote: Mon Apr 12, 2021 3:21 am Not exactly, i'm talking about using those analog channels for sample based audio, like the spc700, in order to get the whole frame time to transfer data instead the actual tiny window to do it.
Of course you can put whatever sound-source you want in front of these analog audio channel, be it a mp3 decoder, some sample-base audio generator like the SPC700/S-DSP, some FM generator like the NES or something completely else. But if you are designing a custom cartridge anyways, why bother with something as limited as the SPC700 (nowadays)?

But what exactly do you mean with "transfer data" in this context? The audio on these pins directly gets mixed into the audio output of the SNES, no data gets "transferred" in the classical sense. You can't use these pins to transfer samples that the SPC700 can later use, or something fancy like that. Furthermore the S-CPU can actually transfer data to the SPC700 whenever it wants, frame timing or blanking periods have no relevance here.

(Because the interface between the S-CPU and the SPC700 is *very* basic, the tricky part is performing these transfers in an efficient way, especially in the background while the normal gameloop is running.)
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: About audio in rom bandwidth capabilities, and a external cpu...

Post by tepples »

Dartan wrote: Mon Apr 12, 2021 4:20 amFurthermore the S-CPU can actually transfer data to the SPC700 whenever it wants, frame timing or blanking periods have no relevance here.

(Because the interface between the S-CPU and the SPC700 is *very* basic, the tricky part is performing these transfers in an efficient way, especially in the background while the normal gameloop is running.)
I think the reference to "blanking" comes from the known way to run such background transfers.
coto
Posts: 102
Joined: Wed Mar 06, 2019 6:00 pm
Location: Chile

Re: About audio in rom bandwidth capabilities, and a external cpu...

Post by coto »

Dartan wrote: Mon Apr 12, 2021 4:20 am (Because the interface between the S-CPU and the SPC700 is *very* basic, the tricky part is performing these transfers in an efficient way, especially in the background while the normal gameloop is running.)
That's correct. And would sumarize the thread and the reason why SPC700 can't access ports through any other hardware than the SNES CPU since it's wired to it.
Post Reply