Is it possible to put "road blasters" on a real cart?

[Near]

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.

[qwertymodo]

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.

[lidnariq]

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

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

[Near]

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

[MottZilla]

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?

[juef]

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.

[qwertymodo]

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.

[qwertymodo]

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

[lidnariq]

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.

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

[Greg2600]

I'd just rather see more games ported using MSU1/sd2SNES...

[Near]

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.

[Markfrizb]

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.

[MottZilla]

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.

[Near]

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

[MottZilla]

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.