MSU-1

Mr^O^BIG
Posts: 22
Joined: Sun May 24, 2020 7:02 pm
Has thanked: 1 time
Been thanked: 1 time

MSU-1

Unread post by Mr^O^BIG »

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

Mr BIG
brunosilva
Posts: 9
Joined: Mon May 25, 2020 5:39 pm

Re: Msu-1

Unread post by brunosilva »

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

but author is taking an hiatus
Mr^O^BIG
Posts: 22
Joined: Sun May 24, 2020 7:02 pm
Has thanked: 1 time
Been thanked: 1 time

Re: Msu-1

Unread post by Mr^O^BIG »

It's not working well

Mr BIG
ExCyber
Posts: 133
Joined: Sun May 24, 2020 3:33 pm
Has thanked: 2 times
Been thanked: 27 times

Re: Msu-1

Unread post by 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
Posts: 44
Joined: Sun May 24, 2020 10:28 pm
Been thanked: 5 times

Re: Msu-1

Unread post by dentnz »

ExCyber wrote: Mon May 25, 2020 8:01 pm 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.
User avatar
Sorgelig
Site Admin
Posts: 560
Joined: Thu May 21, 2020 9:49 pm
Has thanked: 1 time
Been thanked: 52 times

Re: Msu-1

Unread post by 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.
User avatar
Oliver_Twist
Posts: 2
Joined: Wed May 27, 2020 7:30 pm

Re: Msu-1

Unread post by Oliver_Twist »

interesting information ! thanks !
dentnz
Posts: 44
Joined: Sun May 24, 2020 10:28 pm
Been thanked: 5 times

Re: Msu-1

Unread post by dentnz »

Sorgelig wrote: Wed May 27, 2020 4:58 pm 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.
User avatar
Sorgelig
Site Admin
Posts: 560
Joined: Thu May 21, 2020 9:49 pm
Has thanked: 1 time
Been thanked: 52 times

Re: Msu-1

Unread post by 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
Posts: 2
Joined: Sun May 24, 2020 11:14 pm

Re: Msu-1

Unread post by 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
Posts: 8
Joined: Mon May 25, 2020 1:29 am
Has thanked: 2 times
Been thanked: 2 times

Re: Msu-1

Unread post by 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
User avatar
James-F
Posts: 20
Joined: Mon May 25, 2020 7:46 am

Re: Msu-1

Unread post by James-F »

MSU-1, Hi-Def Sprite Packs, etc...
These are game altering hacks and belong to emulators.
Raistlin77
Posts: 3
Joined: Fri May 29, 2020 12:57 am

Re: Msu-1

Unread post by 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).
User avatar
darksakul
Posts: 70
Joined: Mon May 25, 2020 4:34 pm
Has thanked: 18 times
Been thanked: 3 times

Re: Msu-1

Unread post by darksakul »

James-F wrote: Fri May 29, 2020 4:29 am 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.
From a cycle inaccurate emulation of Baltimore ciria 41st Millennium .
User avatar
James-F
Posts: 20
Joined: Mon May 25, 2020 7:46 am

Re: Msu-1

Unread post by James-F »

darksakul wrote: Fri May 29, 2020 5:59 am WUT?
Do you consider support of translated roms to MSU1 roms equivalent in terms of core implementation?
User avatar
darksakul
Posts: 70
Joined: Mon May 25, 2020 4:34 pm
Has thanked: 18 times
Been thanked: 3 times

Re: Msu-1

Unread post by 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.
From a cycle inaccurate emulation of Baltimore ciria 41st Millennium .
dentnz
Posts: 44
Joined: Sun May 24, 2020 10:28 pm
Been thanked: 5 times

Re: Msu-1

Unread post by 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?
User avatar
Sorgelig
Site Admin
Posts: 560
Joined: Thu May 21, 2020 9:49 pm
Has thanked: 1 time
Been thanked: 52 times

Re: Msu-1

Unread post by 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
Posts: 8
Joined: Mon May 25, 2020 1:29 am
Has thanked: 2 times
Been thanked: 2 times

Re: Msu-1

Unread post by 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?
User avatar
Sorgelig
Site Admin
Posts: 560
Joined: Thu May 21, 2020 9:49 pm
Has thanked: 1 time
Been thanked: 52 times

Re: Msu-1

Unread post by 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
Posts: 8
Joined: Mon May 25, 2020 1:29 am
Has thanked: 2 times
Been thanked: 2 times

Re: Msu-1

Unread post by 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
Posts: 44
Joined: Sun May 24, 2020 10:28 pm
Been thanked: 5 times

Re: Msu-1

Unread post by 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
Posts: 44
Joined: Sun May 24, 2020 10:28 pm
Been thanked: 5 times

Re: Msu-1

Unread post by 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
Posts: 44
Joined: Sun May 24, 2020 10:28 pm
Been thanked: 5 times

Re: Msu-1

Unread post by 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
Posts: 2
Joined: Sat May 30, 2020 2:14 am

Re: Msu-1

Unread post by daverhodus »

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