I will agree with byuu about the sound. There's enough documentation about the CGRAM, and the basics of how all the backgrounds work, but the sound is some weird mystery land.
Even if you are a programmer and musician, you have to use trackers with the existing tools, which I assume for many non nerds is pretty weird territory.
I'm learning the 65816 ASM again and hit a crazy wall with just getting sound to output.
I think with a little bit better documentation in a few years there could be some doooope stuff coming from the SNES homebrew world.
Is it possible to put "road blasters" on a real cart?
Moderator: Moderators
Forum rules
- For making cartridges of your Super NES games, see Reproduction.
-
benjaminsantiago
- Posts: 84
- Joined: Mon Jan 20, 2014 9:40 pm
- Location: Astoria, NY
- Contact:
Re: Is it possible to put "road blasters" on a real cart?
I guess (in light of all the above) this makes the road blaster game even more incredible than we knew.
Re: Is it possible to put "road blasters" on a real cart?
d4s was considering the possibility to put the game on a cartridge: viewtopic.php?p=88039#p88039 that, in a MSU1-less fashion - which might be making things much easier and cheaper.
Data transfer could be similar to MSU1 data transfer, but it might be a whole lot easier when directly using compact flash protocol (or whatever memory card/chip is used) instead of using the MSU1 protocol.
Audio hardware could be completely omitted since the SNES is containing that hardware anyways (there isn't too much use in having additional D/A converters, volume regulators, sample address counters, and sample rate generators in the cartridge). One could as well use normal data transfer for audio data, and then forward the audio data to APU in whatever way (only downside is that it steals some CPU time, which shouldn't matter for purposes like movie playback (unless the movie would require software decompression, of course)).
I don't know what d4s has meant by using HDMA for audio (maybe realtime streaming with one single sample per scanline, but that won't work too well during vblank). I guess it would be best to do audio streaming via normal BRR sample blocks. BRR format is also having the advantage that it's smaller than raw PCM.
Data transfer could be similar to MSU1 data transfer, but it might be a whole lot easier when directly using compact flash protocol (or whatever memory card/chip is used) instead of using the MSU1 protocol.
Audio hardware could be completely omitted since the SNES is containing that hardware anyways (there isn't too much use in having additional D/A converters, volume regulators, sample address counters, and sample rate generators in the cartridge). One could as well use normal data transfer for audio data, and then forward the audio data to APU in whatever way (only downside is that it steals some CPU time, which shouldn't matter for purposes like movie playback (unless the movie would require software decompression, of course)).
I don't know what d4s has meant by using HDMA for audio (maybe realtime streaming with one single sample per scanline, but that won't work too well during vblank). I guess it would be best to do audio streaming via normal BRR sample blocks. BRR format is also having the advantage that it's smaller than raw PCM.