About audio in rom bandwidth capabilities, and a external cpu...
Moderator: Moderators
Forum rules
- For making cartridges of your Super NES games, see Reproduction.
- Señor Ventura
- Posts: 233
- Joined: Sat Aug 20, 2016 3:58 am
About audio in rom bandwidth capabilities, and a external cpu...
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.
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.
-
- Posts: 611
- Joined: Mon Jan 23, 2006 7:47 am
- Location: Germany
- Contact:
Re: About audio in rom bandwidth capabilities, and a external cpu...
No, since (as you said) it shares the data bus with the rest of the system.
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
-
- Posts: 1565
- Joined: Tue Feb 07, 2017 2:03 am
Re: About audio in rom bandwidth capabilities, and a external cpu...
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...
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...
Re: About audio in rom bandwidth capabilities, and a external cpu...
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.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...
Re: About audio in rom bandwidth capabilities, and a external cpu...
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)
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)
- Señor Ventura
- Posts: 233
- Joined: Sat Aug 20, 2016 3:58 am
Re: About audio in rom bandwidth capabilities, and a external cpu...
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
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
-
- Posts: 611
- Joined: Mon Jan 23, 2006 7:47 am
- Location: Germany
- Contact:
Re: About audio in rom bandwidth capabilities, and a external cpu...
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
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
Re: About audio in rom bandwidth capabilities, and a external cpu...
You just described a mp3 cart like exist for SNES and Gen. Chip decodes mp3s and outputs analog audio to the cart pins.
Re: About audio in rom bandwidth capabilities, and a external cpu...
Afaik it's actually the other way around:creaothceann wrote: ↑Sun Apr 11, 2021 1:56 pm That's how the SGB does its extra audio effects with Donkey Kong, afaik.
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.
- Señor Ventura
- Posts: 233
- Joined: Sat Aug 20, 2016 3:58 am
Re: About audio in rom bandwidth capabilities, and a external cpu...
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.
Re: About audio in rom bandwidth capabilities, and a external cpu...
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)?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.
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.)
Re: About audio in rom bandwidth capabilities, and a external cpu...
I think the reference to "blanking" comes from the known way to run such background transfers.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.)
Re: About audio in rom bandwidth capabilities, and a external cpu...
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.