MSU-1

[Mr^O^BIG]

I wanna ask if it's possible to add the msu-1 capability to the snes core???

Mr BIG

[brunosilva]

there is already a beta version (non oficial one) for msu1...

but author is taking an hiatus

[Mr^O^BIG]

It's not working well

Mr BIG

[ExCyber]

From what I remember of the original spec (which seems hard to find now), it's tricky to properly implement MSU-1 in hardware without independent storage devices for data and audio. Performing a data seek does not stop audio streaming, and vice-versa. So for full compatibility you need to be able to perform any pattern of seeking and streaming operations without being able to block a stream once it's no longer "busy". Even SD2SNES apparently can't handle this if the SD card seeks too slowly or the file system is too fragmented (see https://sd2snes.de/blog/card-list ).

[dentnz]

From what I remember of the original spec (which seems hard to find now), it's tricky to properly implement MSU-1 in hardware without independent storage devices for data and audio. Performing a data seek does not stop audio streaming, and vice-versa. So for full compatibility you need to be able to perform any pattern of seeking and streaming operations without being able to block a stream once it's no longer "busy". Even SD2SNES apparently can't handle this if the SD card seeks too slowly or the file system is too fragmented (see https://sd2snes.de/blog/card-list ).

Yes, this is very true. In the end, I was able to get fifo buffers setup on both the ARM and FPGA (a ring buffer) that allowed me to play video and audio. Unfortunately, it required a relatively large buffer for video... This meant that I had to disable all the special chips just so I had enough space. And yes, audio and video are two separate things in MSU1 - the SNES does NOT have the capability to decode video and audio from a single file. We need two separate streams, SRAM and Cheats require their streams too I believe, MiSTer supports 4 'streams' only.

MSU1 does support a seek operation, where it will pause on the initial file position seek. But from there, it will just keep pulling data without waiting. This makes it quite different to a CD/SD/HDD read operation, since those usually have sector reading work flows, where a sector is requested and waited for.

Also, a lot of MSU1 video player implementations (Chronotrigger FMV MSU1 for instance) use DMA to copy the data from the MSU1 registers to video ram. DMA operations like this were pulling data much faster than I could stream across. A significant block of data needed to be available to the DMA, I think about 32kb if I recall correctly. I implemented a system of filling my fifo buffers as much as I could during the initial seek - this included loading as much of the MSU1 data file as I could into the ARM DDR ram. Remember that those files can be 4gb in size and we have less than 512mb to play with there, hence why I used a ring buffer. It got quite complicated in terms of handling additional seeks in quick succession. Video players often use a look up table in the MSU1 data file, so there would be a seek to the table, and another seek to a location in the file. This was problematic for knowing when to clear the fifo and ring buffers, so I added smarts to it to only flush if the seek was to a position not in the fifo.

Even after I got video and audio working fine in Zelda and Chronotrigger, there were issues:

- Opening the OSD would destroy video - audio would stutter, but would recover. This is because the configuration for the core is communicated between the ARM and FPGA as the OSD is opened. That transaction during a streaming operation is just not possible with the current HPS <-> FPGA bridge. I know that some of this process has changed in newer versions of the SNES core, so perhaps this issue isn't as bad now?
- No special chips - so some MSU1 hacks that make use of those chips became unusable
- Roadblaster would not work at all. Loading the ROM presented an error message, something about the device being not capable of streaming, and to use a faster SD card? I was really hoping this game would work, since it's a MSU1 hack that even the purists can appreciate

I had a few things I wanted to look at from there:

- A different mechanism for communication between the ARM and the FPGA - ElectronAsh had done some experiments with using a different bridge mechanism which would allow for LARGE blocks of RAM to be 'shared' between the ARM and FPGA.
- Moving the FIFOs into SDRAM - this would require a custom FIFO (non-Altera) and rely on the latency of SDRAM being low enough to actually work
- My branches for Main_MiSTer and SNES are way behind origin/master. Also, I know the code is quite untidy and would need to be cleaned up before I even tried to present it to Sorg.

The alternative 'bridge' idea is not something I can implement into the core by myself. It would require a deep investment by Sorg and the like to implement a reusable solution - something that would potentially change how all HPS<->FPGA communication works in MiSTer. The thing is, no other cores require this, the CD based cores just don't have the requirements that MSU1 does, so I wonder if it's even worth it

The SDRAM option is probably my best bet, but even then, it concerns me that it won't be fast enough. I did find an opensource fifo implementation that allowed an alternative RAM backend, and I was trying to wire it up to the SDRAM controller at the time... I am acutely aware that I need to share that SDRAM with the SNES CPU, as it would potentially fetching ROM data from it. Anyway, I kind of realised quickly it would get difficult to mux the reads and writes, and ensure I didn't break the SNES core or make it less accurate. Please remember, that I am a traditional software engineer, and I started HDL programming only about 12 months ago... My C++ is also not that great, so writing Main_MiSTer code was also 'fun'. MSU1 was always just a learning exercise for me, and I feel like I might have got everything I want to from it: with the help of ElectronAsh and Qwertymodo, we were able to get MSU1 to work on the MiSTer... albeit not very well

I guess I should push all the code I have up to Github and make it public. Perhaps someone can help out? Perhaps Sorg can take a look at the general implementation I have, and redo it properly The way those guys do things, it would probably take him a few days and it would be done.

[Sorgelig]

SNES core is already quite large and take ages to compile. Adding such resource and performance hungry thing such as MSU-1 will definitely affect the overall core stability.
As i've told many times, MSU is quite useless feature. If it could be some small thing like add and don't notice it, then i would add. But such large thing as MSU - i'm pass. Get real SNES + SD2SNES and enjoy it as it's very important to you.
99.9% users don't need it. Most users just need to play original games.

[Oliver_Twist]

interesting information ! thanks !

[dentnz]

SNES core is already quite large and take ages to compile. Adding such resource and performance hungry thing such as MSU-1 will definitely affect the overall core stability.
As i've told many times, MSU is quite useless feature. If it could be some small thing like add and don't notice it, then i would add. But such large thing as MSU - i'm pass. Get real SNES + SD2SNES and enjoy it as it's very important to you.
99.9% users don't need it. Most users just need to play original games.

Exactly! It's a lot of effort for a small amount of return. Would you be open to at least having the audio functionality added to the core? As that can be accomplished without removing any special chips, or at least it used to be. I'd probably look at re-doing most of the code with the most up to date (and accurate) version of the current core. Knowing what I know now, it wouldn't take long to make something a bit tidier. Let me know, and I will take a look.

[Sorgelig]

I cannot tell in advance as i don't know how tit will look/work and how it will affect the core.
There already FFIII intro issue which has unknown origin. most likely due to tight timings..
So need to see the result then make a decision. At least it's not a problem to have a mod with stripped functionality to fit MSU1 for its fans.

[pippuz]

I agree with Sorgelig.
In my opinion there is no need for MSU-1 on the SNES core.
It emulates almost all special chips, all the chips that we need to play.
Also SPC-7110 that is not present on SD2SNES.
in my opinion it is already perfect and we don't need to take the risk to affect core stability for a feature that is not necessary.

[Flain]

There are Zelda fans that are in to MSU1 because it's the only way to play the BS Zelda Satellaview games with the voice overs (english voice overs are fan made though). https://en.wikipedia.org/wiki/Satellavi ... lda_series

Roadblaster is also quite amazing but that's only one game..
https://www.youtube.com/watch?v=BvIXUOr4yxU

SD2SNES is a good solution if MSU1 is too big for MiSTer

[James-F]

MSU-1, Hi-Def Sprite Packs, etc...
These are game altering hacks and belong to emulators.

[Raistlin77]

I think most people would be satisfied with the audio part of MSU-1. Most hacks don't even have video. Because that usually requires there to be a remake of the game to take FMV from in the first place (there are far more audio-only patches for games with special chips at this point, so that would arguably be the greater loss). I would much rather Chrono Trigger lose it's intro than Super Mario RPG lose it's orchestral soundtrack.

And while Super Road Blaster was interesting from a technical standpoint, there are probably better ways of playing old Laserdisc arcades (i.e. Daphne, though a Laserdisc arcade and movie player core might be interesting, but that's a whole other subject, I guess). But if you did decide to put out the video version as a separate core, I don't think anyone would object.

I don't agree that this belongs in the same category as a high-def sprite hack. MSU-1 was designed to work on real hardware. If it did not and could not work on real hardware, like the high-resolution Ocarina of Time and Majora's Mask hacks, James-F might have a valid argument. In this case it is a flawed comparison though.

I do agree that solving bugs like the one with FF6 take precedence, naturally.

As for it being "perfect" though, well there's still 2 competition carts and 2 Shougi games no one seems to want to touch. I can understand if the ST018 is out of the question, but from what I've read, the ST011 is not significantly more complex than the ST010 (never mind Analogue has done it).

There is also the matter of save states to consider, I think. While more games for the SNES had SRAM than it's competitors and predecessors, save states would still be a handy feature for some of those crazy hard games that did not (i.e. Super Ghouls & Ghosts). I could just enable cheats, but that would be boring. The NES and PC Engine should probably get them first though (because so many games used passwords).

[darksakul]

MSU-1, Hi-Def Sprite Packs, etc...
These are game altering hacks and belong to emulators.

WUT?

There alot of Game Roms that are altered, translated or hack and can be played on Real Hardware.
It's why people who play on a Actual Super Nintendo or Super Famicom gets a Flash cart. To play altered roms.
It's not just a "Emulation" thing.

The MiSTer is just a FPGA implementation of that Super Nintendo/ Super Famicom hardware.
I play alot of Japanese RPGs that been translated to English, and I rather do it via the MiSTer or FX PAK Pro (formerly SD 2 SNES) than to use emulation.

[James-F]

WUT?

Do you consider support of translated roms to MSU1 roms equivalent in terms of core implementation?

[darksakul]

The MSU-1 Was designed with real hardware in mind.
So I don't see it as a emulation only thing.

Its also the closest we ever get to see how the Snes CD add on would have been like (The Super Nintendo PlayStation), although not original to the era, I find it a key part of the Modern Retro Snes experience.

I also want to point out we do have cores with Emulator like functions. The GBA core has savestates and a turbo/fast mode. And the Neo Geo Core really opens up if you use the Unibios instead of an original Bios, as you can pick and chose region and MVS (Arcade) or AES (Console) modes.

[dentnz]

I can certainly look to put the audio side of the msu1 into the latest SNES core. This isn't the latest code, but it's a good indication of how audio was done at least, and highlights some of the things that need to be scrutinized.

For MiSTer_Main, I split the snes SD handling and polling out to a separate 'support' file - so glad that Sorg took up the support folder concept!:
https://github.com/dentnz/Main_MiSTer/b ... s/snes.cpp

In the core itself, there are a few things that would need to be looked at in more detail... some work around the sd card - this may have to go:
https://github.com/dentnz/SNES_MiSTer/b ... s_io.v#L69

Some SD arbitration stuff that ElectronAsh did that might need to be gone too - My MSU1 code maybe dependent on this, and it's a non-standard change to the sys folder/MiSTer framework:
https://github.com/dentnz/SNES_MiSTer/b ... _io.v#L381

The FPGA<->ARM flags for MSU1 - there's some stuff to do with data that would need to be culled, and I am not sure if it's right for audio either:
https://github.com/dentnz/SNES_MiSTer/b ... _io.v#L113

Here's the actual MSU1 register verilog - all of this needs to be tidied up - comments removed, variable names are all over the place:
https://github.com/dentnz/SNES_MiSTer/b ... DSP/MSU.sv

Here's the audio handling - i.e the 'playing' of the PCM audio data in the fifo:
https://github.com/dentnz/SNES_MiSTer/b ... ES.sv#L875

This is actually where the guts of the MSU1 audio handling happens, e.g the state machine for track selection, buffering audio, LOOPING tracks (a HUGE part of MSU1). It tells the audio player to play, it fills the fifo with data and keeps it topped up, handles missing tracks and more... Code here is not too bad, but the variable names are all over the place, particularly around the latches and state names:
https://github.com/dentnz/SNES_MiSTer/b ... su_audio.v

Here's the summing of MSU1 audio into existing SNES audio:
https://github.com/dentnz/SNES_MiSTer/b ... ES.sv#L566

So, still a bit of effort involved to get it right. It's definitely NOT pretty code...

Anyways, it's obvious that Sorg wouldn't be too keen to upset the accuracy of the core with additional MSU1 complexity, and I understand completely. But I also think that with a bit of work, audio is something that could be added to the core without hurting said accuracy. Video, not so much.

Sorg, as per my previous question, would you be open to MSU1 audio?

[Sorgelig]

Audio can be played on Linux side without sending it to FPGA.
If it's just like CD audio, then core simply can send command "play this track", and then Linux will play it independently.

[Flain]

That sounds good for BS Zelda, but can linux side audio and FPGA core side audio mix together? Usually that's software mixing, would we still get SNES sound effects?

[Sorgelig]

BSX games has nothing to do with MSU1. And so far almost all BSX games are patched to use standard mapper, so don't need any changes in core.

[Flain]

This is an example of MSU1 being used for a game (zelda) that was only on SNES satellaview https://www.youtube.com/watch?v=JqE7NwyA-MU

Before MSU1 there are rom patches that have transcribed the audio into text that overlays on the screen.

[dentnz]

I had the linux side playing cd tracks in my first experiments. It worked, but there is the problem of looping. The audio player I was working with did not support arbitrary loop points in the audio file the msu1 also supports pausing, fade in and out, it must cope with missing tracks too, with a fall back to playing the original music.

In the end the only way I could see of dealing with this was to go down the path of making all that logic in HDL...

I think I will have to get audio tidied up and into a state that we can assess things.

[dentnz]

It ends up being quite a complicated player really, games can turn looping on and off during playback too, so the song might loop 3 times, and on the last, the loop is removed and the full audio is played out. To be completely seamless, the fifo buffer needs to have the right audio data in it at the right time, else there will be a noticeable hiccup or gap in the audio. Anyway, I had all that working quite well in the end. The audio summing is also handled in the core, thanks to electronash for his help on that... this allows sound effects of the existing audio chip to be ‘mixed’ with the msu1 audio, importantly, this allows us to control the volume of the msu1 audio, which games can control... say in Zelda, link goes into his house, music will fade down to zero, then new music will fade in when link is inside. Similarly, an important moment in the game, music goes down to half volume to allow the sound effects to be heard more... all of this controlled by the msu1 hack.

[dentnz]

I do wonder though, if we can find an audio library that can handle seamless looping and volume control on the linux side. perhaps we could do all of the audio stuff in linux, leaving more fifo space for video... hmmmm

[daverhodus]

I don't have anything to add other than I would love to have MSU-1 audio support. Thanks for working on this.

[Flain]

If you did manage to do audio on the linux side i think that would make this the first software with FPGA hybrid emulation?

[Optiroc]

If you did manage to do audio on the linux side i think that would make this the first software with FPGA hybrid emulation?

Not really any more so than all the cores that do disk and other I/O via the HPS/Linux side.

[dentnz]

If you did manage to do audio on the linux side i think that would make this the first software with FPGA hybrid emulation?

I already had cd track playing, but as I said, that doesn’t allow for proper looping... the msu1 audio files have a header that can be used to specify a repeat/loop point. That loop point is a byte offset into the audio file. I suppose that could be converted to time, but in the end, I think the syncing and seemless playback with the snes core is really only going to work well in the fpga. Having the buffer there allows us to put audio data in the exact spot it needs to be, so no gaps when the audio loop occurs.

I have thought that maybe we can reuse some of this stuff in the CD32, but I guess it does data on the disc as well. Probably more like the sega cd if anything.

[dentnz]

One thing we could definitely reuse this for is the MD+... but I know there’s some real aversion to that one

[Rahzadan]

Any word on progress on MSU-1 support in the last few months? dentnz, do you have any new versions or betas/alphas you're working on?