As far as I know, the only way to play road blasters is on the SD2Snes flash cart. Just wondering g what it would take to get it on a real cart. Is it possible? I suppose it is since the SD2Snes can load the game on the Snes. Just curious what it would take.
http://www.dforce3000.de/
You'd need to build an FPGA that implements the MSU1.
tepples wrote:
You'd need to build an FPGA that implements the MSU1.
But what if you used a MSU1 cart? What then? Is it just a boat load of memory or a lot of other stuff going on? I don't really understand what the MSU1 is .......
This is pure curiosity. No intention of making one. Just want to learn why this is possible.
Thanks
Markfrizb wrote:
tepples wrote:
You'd need to build an FPGA that implements the MSU1.
But what if you used a MSU1 cart? What then?
There's no such thing
The SD2SNES is the only MSU-1 cart in existence. The MSU-1 was invented by byuu, and didn't exist during the lifetime of the SNES, and was never actually produced in hardware until ikari_01 implemented it on the SD2SNES. If you want to take his HDL files and build your own MSU-1 cart, then you could do exactly what you're suggesting, but it'd be rather expensive...
EDIT: Now that you have me thinking about it, I get the sneaking suspicion the MSU-1 could be implemented with a CPLD and an external DAC, rather than needing a full-on FPGA. If so, it actually wouldn't be too bad price-wise.
I know that you meant a singular cart as opposed to a "dev" or memory card-based tool, but I think its important to note that the SD2SNES is very real. Besides the engineering exercise of getting it onto a cart, how would getting it onto a cart be "more" real?
I didn't realize that MSU carts didn't exist. So my question about putting it on a "real cart" is a fallacy.
The sd2snes is a real cart, I get that. Very interesting. Is road blaster the only msu1 game?
Thanks
benjaminsantiago wrote:
the SD2SNES is very real. Besides the engineering exercise of getting it onto a cart, how would getting it onto a cart be "more" real?
It's more real in two senses: 1. being able to sell repros, and 2. being able to develop an original homebrew game using this coprocessor and sell it.
Markfrizb wrote:
Is road blaster the only msu1 game?
No, there's also a Mario world hack that utilizes the MSU-1 for digital cd-quality audio.
getafixx wrote:
Markfrizb wrote:
Is road blaster the only msu1 game?
No, there's also a Mario world hack that utilizes the MSU-1 for digital cd-quality audio.
Humm, I didn't know that. Where can that be had?
IT seems like if there were a CLPD device that could function as a MSU (or maybe a blank dev cart), then the home brewers would have another tool at their disposal. The Road Blasters is very impressive!
Markfrizb wrote:
Humm, I didn't know that. Where can that be had?
I think it's still in demo stages, but its called Super Mario Odyssey. You can probably find it on SMW Central.
I'd like to see someone build a MSU-1 add-on cartridge stand-alone. Think a Game Genie pass-thru sort of device but adds MSU-1. Infact you could take that a bit further, and actually have a Game Genie type of device so you could actually use it to add CD quality music to games while using the original game cartridges.
But at the very least a pass-thru to use MSU-1 on other Flash Carts would be handy.
So bypassing the game's built in audio for an external audio source, but using a passthrough cart with an MSU-1...That would be pretty cool to see. I wonder if it's even possible without having some kind of code on the original game to tell the digital audio when to play/change tracks?
Maybe I can make it more clear. Imagine a cartridge that is like a Game Genie or Action Replay. It plugs into the SNES cartridge port and has a cartridge port on top of it for another cartridge to go into. Similar to a Game Genie it would have hardware inside it to intercept ROM accesses to patch ROM reads in real time, but ofcourse having a much higher capacity than a Game Genie or Action Replay. Those devices can only patch a few bytes of ROM at a time. This would need to be able to patch alot more.
Ideally the device would be able to handle a significantly large amount of patched or expanded data so you could use it to play translations of games such as Final Fantasy 4 or Seiken Densetsu 3. But also so you could patch games to use MSU-1.
So here is an easy example. You have this device with the MSU-1 which is like a Game Genie. You plug in a real Rock 'n Roll Racing cartridge on top and put in your SD card for the game. The MSU-1 data could actually contain ROM patch data for a BIOS in this cartridge to read to know how to patch the ROM for the MSU-1 features. So you'd just turn your system on and your game could have CD quality music, using the original cartridge. And ofcourse nothing would stop you from using it with another flash cart like the PowerPAK. You wouldn't need Game Genie style ROM patching in that case, just the MSU-1 support.
byuu actually proposed exactly such a pass-thru device, or possibly an expansion-port device (though IIRC the final MSU-1 design wouldn't support that, where the original 21FX draft spec did). It could be done, but one of the big pains is obtaining the female socket for the pass-thru functionality :/
qwertymodo wrote:
or possibly an expansion-port device
That shouldn't be that hard to obtain. Even the pitch is non-standard, something close should do the trick quite nicely. I remember a post in this forum about the expansion port.
The MSU1 was always designed to be possible on real hardware. A lot of the power we could have added was intentionally left out, so that a hardware version could be cheaper to produce. It now exists in physical form and hundreds of people have the sd2snes carts in their possession, and it is even still available for sale. So in my eyes, it's perfectly real, and perfectly usable for homebrew. But it isn't cheap (in hardware form), and it isn't officially approved by Nintendo.
Initially I wanted to have this on the expansion port. But that port only exposes the B-bus. This means you cannot transfer directly from the expansion port into video RAM. You have to transfer into WRAM first, which may be limited, and it doubles the total transfer time. There are also a lot of annoying clone systems, and the SNES Jr, which lack the expansion port.
So the decision was made to design it as a cartridge port passthru, where we could put it on the A-bus. Envisioned as a small, half-gamecart-height cart with a universal shell to connect to any SNES, and an SD card slot on the side. You would then run any flash cart on the top to run an MSU1-patched game. Add CD audio and/or FMV to any existing game. Having it patch the game connected was proven too difficult/expensive. Such a device would literally already be a full-fledged flash cart (imagine a "patch" that changes every single byte of the ROM ... now it's any game you want.)
The only design to actually be made and sold thus far had it integrated into the flash cart, which is perfectly fine of course. Sleeker in fact since you can have multiple MSU1 games on the same SD card.
As qwertymodo says, it should be cheap to produce. The hardest part is going to be the female connector. If you were willing to ignore support for the side pins (SuperFX games and the like), you could probably cut another connector to size. The audio feeds through the SNES cart pins, so there's no need for an audio output jack. The protocol has wait states on everything, so you don't need super-efficient parts here nor lightning-fast memory.
The main thing holding such hardware back is a dearth of games for it. We have Super Road Blaster, Super Mario Odyssey (demo), and Chrono Trigger FMV intro (not updated to MSU1 yet.) We desperately need people to make new games, to patch existing games to support CD-audio and/or FMV, etc.
It takes about 20 minutes to patch a game to use CD-audio: trace out writes to $214x, walk up the stack until you find it loading a track# and calling the "play track" function (every game I've looked at had one), and modify that routine to test if MSU1 is present. If so, play with MSU1. If not, call original function so the game still works just with the regular audio.
Get the content out there, and the emulators will support it, and the hardware will be made.
If I understand correctly, the MSU-1 is basically just a 32-bit mapper with a stereo PCM WAV DAC to play back audio on the cart pins, right? Though, I'm not really clear on how the audio track start offsets are determined for $2004/5 writes... I'm really curious to see if this is doable in a CPLD.
qwertymodo wrote:
If I understand correctly, the MSU-1 is basically just a 32-bit mapper with a stereo PCM WAV DAC to play back audio on the cart pins, right?
Looks like a read-only data FIFO plus audio. Not clear if both can be used at the same time. If they can't, this is a fairly simple microcontroller project, since streaming in-order data at 176kB/sec is quite simple. (If they can be used simultaneously, it might still be simpler on a microcontroller than anything else. Just not "easy".)
Quote:
Though, I'm not really clear on how the audio track start offsets are determined for $2004/5 writes...
It looks like that's not specified, so that implementors can do it however they wish. For emulation, each track is a separate file; if it were a CD it'd probably be a separate track. Nowadays, I'm hard pressed to think of something cheaper SD cards, given that it's storing uncompressed audio. (Whether as files on a FAT32 volume, or as raw partition data, or whatever...)
MSU1 is two portions.
The first is a data stream. You set an address, wait for a data seek to complete (if the implementation needs to seek), and read a continuous stream, 8-bits at a time. Needs to be fast enough to read 3.58Mbyte/s.
The second is an audio stream. You set a track number, wait for a seek if needed, and then tell it to play. You can adjust the volume linearly (for clean fade-outs and other uses), and pause/play. The actual format used by higan for the audio is 44.1KHz 16-bit stereo PCM (redbook), with a header that contains "MSU1" as the file format identifier, followed by a 32-bit repeat sample# (8+sample*4=file offset to seek to.) The repeat value allows you to have seamless looping. But the actual audio format isn't defined by MSU1 itself, it just needs to be able to play tracks and repeat them. It could be an actual music CD. There are no audio seek / position commands.
It is possible to stream data and audio at the same time. The cheapest way to handle it would be one SD card for data, one SD card for audio tracks. But the nicer way is to buffer enough data and audio before starting each stream that you can fill up the buffers as the device runs. The audio bandwidth is very low compared to the max data bandwidth. (~160Kbyte/s.)
byuu wrote:
Get the content out there, and the emulators will support it, and the hardware will be made.
It's kind of the opposite for me. I could help with the MSU-1 patching, but since I don't own a SD2SNES I have less interest in doing so. I am curious, did anyone actually manage to add FMV to a game such as Chrono Trigger? Also did anything ever happen with Der Langrisser?
MottZilla wrote:
I am curious, did anyone actually manage to add FMV to a game such as Chrono Trigger?
Yes, back in the day when MSU1 was called 21fx. I can't find the relevant posts on byuu's forums, only
this video.
MottZilla wrote:
byuu wrote:
Get the content out there, and the emulators will support it, and the hardware will be made.
It's kind of the opposite for me. I could help with the MSU-1 patching, but since I don't own a SD2SNES I have less interest in doing so. I am curious, did anyone actually manage to add FMV to a game such as Chrono Trigger? Also did anything ever happen with Der Langrisser?
IIRC, only the intro video was ever added, and the 21FX draft spec used different registers than the final MSU-1. byuu had the whole patch uploaded to his site at one point, but a lot of the content is still missing since he started his site redesign awhile back. As for Der Langrisser, that's been on hold while byuu works on his debugger, since he needs the debugger in order to work on it.
byuu wrote:
MSU1 is two portions.
The first is a data stream. You set an address, wait for a data seek to complete (if the implementation needs to seek), and read a continuous stream, 8-bits at a time. Needs to be fast enough to read 3.58Mbyte/s.
Well, I can see right there that a microcontroller won't be able to keep up there, and a CPLD wouldn't be able to handle the overhead of a file system for the audio tracks. However, now that I can see that the data and audio streams are separate, I envision a slightly different approach. Use a CPLD like a Xililx XC9500XL for the data stream, and a microcontroller for the audio stream, each with its own SD card. The data card would be raw and unformatted to make interfacing with the CPLD simple (no need to deal with a file system, just read raw addresses), and the audio data could be on a FAT-formatted card to allow each track to be a separate file. Too bad NOR Flash doesn't come in anywhere near the memory densities of NAND...
byuu wrote:
The first is a data stream. You set an address, wait for a data seek to complete (if the implementation needs to seek), and read a continuous stream, 8-bits at a time. Needs to be fast enough to read 3.58Mbyte/s.
Other than the legacy nature of compactflash, this seems almost like an ideal application for it: it's already 8 bits wide and intrinsically capable of that kind of cycle time. The only tricky part is injecting the IDE commands to load each new block of sectors as the SNES reads past what's in the CF read buffer.
byuu wrote:
It is possible to stream data and audio at the same time. The cheapest way to handle it would be one SD card for data, one SD card for audio tracks. But the nicer way is to buffer enough data and audio before starting each stream that you can fill up the buffers as the device runs. The audio bandwidth is very low compared to the max data bandwidth. (~160Kbyte/s.)
Since all the bulk storage NAND flash requires injecting periodic "give me the next block" commands, it's not clear whether once you have to juggle that how much harder it is to juggle streaming audio also...
I'd just rather see more games ported using MSU1/sd2SNES...
I was absolutely blown away that we got Super Road Blaster. d4s is just really amazing.
There's always been an extreme dearth in homebrew on the SNES. For being arguably the most popular retro gaming system ever, it sure doesn't get much programming love. And of course I know all too well many of the reasons why.
Why?
For me, I'd like to see a MSU1 "adapter" or cart or whatever form it may appear as, as a single purpose cart and hopefully inexpensive too.
I blame the SPC for some of the lack of homebrew. But what reasons do you think are related to the lack of homebrew? There have been some projects. That Donkey Kong remake, someone was working on a Kung Fu Master remake. Then there were older SNES homebrews too, though I guess most are just demos. It probably loses some of the potential to the NES which is probably easier to homebrew for in some ways.
The major reasons:
a) the APU. Producing music and sound effects requires the rare breed of programmer + musician combined. Very custom architecture. Have to program a communications bridge with the CPU, a new program in an obscure instruction set that lacks interrupts of any kind (especially timer and communication interrupts), work with the bizarre Sony DSP to do BRR-encoded samples and deal with all the crazy registers and their issues (KON/KOFF, etc.) You're extremely constrained for both bandwidth and memory, leading to gross and unstable hacks like HDMA audio transfers.
b) the CPU. It's far too slow, and the instruction set does not in any way lend itself to generating decent code from C. Sure there's been some C compilers for it, but nothing remotely usable for a serious, large-scale game like you'd get with the GBA. The SNES isn't even fast enough to just write the speed critical parts in assembly, unless you are writing yet-another-Tetris-variant.
c) the PPU. It's a bit-blender. The NES PPU has eight registers, the SNES PPU has 64 registers, and most of them pack 2-8 settings per register. And almost every setting interacts with every other setting. All of this results in one of the most complicated rendering processes imaginable. We only just recently figured out some missing hires blending details thanks to AWJ, in 2013. It's so complicated for someone just coming in ... try and do color blending. You get to mess with two windows and their positions, main and sub pixels, main/sub window enable flags, color enable flags, color blend and halve settings, window inside or outside settings, two-window overlap settings (and, or, xor, xnor), add or subtract mode from fixed or subscreen source, lores vs hires differences, direct color mode, and lots, lots more. Even something as simple as the sprite X position requires two separate tables, with crazy gotchas like "don't ever put a sprite at X=256" (it counts all tiles against your max tiles per frame in that case, leading to bad sprite flickering.)
I believe the NES gets a lot more attention because it's tiny enough that you can still mostly create great little games as an individual. It's hard, sure, but it almost hearkens back to the Atari 2600 garage coding days. But the SNES adds so much complexity that you really need a decently sized team and a long development process to create compelling software. Or a savant master of all trades. And all of it has to be done in arcane '90s-era assembly.
Once you get to the GBA - available space, C compilers, and nice libraries finally start to make things manageable. The PPU is still a bit batty there, but it's quite a bit simplified aside from adding much-desired sprite rotation, and the sound system is back to something manageable (albeit far too limited, as it's basically GB audio + a tiny PCM buffer.)
I think there was one attempt at it, but I think a reasonable open-source SNES music and sound effects engine and either tracker or mod module converter would really help out. While the CPU is slow so you will need ASM, and the graphics setup can be complicated, I think those are things someone can get over with some effort. But I think when it comes to the sound problem people usually just throw in the towel.
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.
I guess (in light of all the above) this makes the road blaster game even more incredible than we knew.
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.