MiSTer FPGA Forum

Yes, the looping audio is pretty tricky really, particularly when you have to take into account the fifo buffer. Say the loop point in the msu audio file puts the loop point *byte offset* some way into the file... The algorithm goes something like so:

- Work out the SECTOR offset from the loop byte offset
- Determine if the END of the audio file falls on a complete sector or not
- Wait until we have read in the final FULL SECTOR, then read the remaining bytes of the partial sector if required
- Ask the HPS to send across the final (Partial) SECTOR as per the loop point converted from a byte offset
- If the loop point is not on a SECTOR boundary (likely) then keep reading the (partial) sector until we get to the remaining byte offset - don't write these unnecessary bytes to the FIFO, as those would be the start of the audio file
- Once we have reached the byte in the sector where the loop point is, re-enable FIFO writes

The above needs to cope with:

- Topping up the fifo - We need to ensure that the fifo is full enough with PCM audio data
- Audio Pause - MSU1 also supports the ability to PAUSE the audio at any point
- Audio Stop - reset everything
- Track changes - Everything needs to change to a completely different file whenever the MSU1 says so
- Repeat on or off at any point - MSU1 allows you to loop an audio file for any amount of time, then turn off the looping mechanism and either stop the file or restart the same audio file from the very beginning
- MSU1 header - need to read and store loop points when a new track is selected. We don't want that header to go into the audio output, else we might get a clicking sound in the audio output

My current MSU1 code implements this algorithm and copes with all features mentioned FOR AUDIO.

The algorithm is much the same for the data file... However, DMA is typically used in the video player implemented in the MSU1 hacks (e.g Chronotrigger). MSU1 data does NOT support 'sector' handshaking - IT IS NOT a CD. It seeks ONCE, then starts to pull down data immediately. When it reads the MSU1 data register, it expects the next byte to be there on the next read. I must add additional tricks to cope with the speed required by DMA:

- Pre-cache the data file into a RING buffer on the Linux side. However, the MSU1 data file can be several gigabytes in size, and we have only 512mb of available DDR3 RAM. This is why a ring buffer is required
- Increase the size of the FIFO buffer on the FPGA side
- During MSU_SEEK, Pre-fill the FIFO with as much of the data file, from the seek byte on
- Whenever there is a MSU_SEEK, clear the FIFO and RING buffer UNLESS the new MSU_SEEK point is already loaded in the FIFO. In which case, we don't have to clear the FIFO and can jump to the appropriate SECTOR, then 'skip' over the bytes until we get to the appropriate byte offset

This is how I did things previously when it comes to the data file... With a 16kb FIFO for data, another FIFO for the Audio, all the special chips cannot fit. So, I have to try something else instead...
-

dentnz wrote: ↑Thu Feb 11, 2021 1:47 am With a 16kb FIFO for data, another FIFO for the Audio, all the special chips cannot fit. So, I have to try something else instead...

I'm admittedly not an FPGA resource expert, but after looking around for some optimization possibilities I don't understand why this would be the case. I found a couple places where it might be possible to merge internal special chip memories, but it looks like there is already about 1.5Mbit of block RAM free. Do these FIFOs not use block RAM?

Honestly - I'd still be pretty happy if only the audio side of MSU-1 was working. The Video/FMV side of it is less important, IMO.

Rahzadan wrote: ↑Thu Feb 11, 2021 6:06 pm Honestly - I'd still be pretty happy if only the audio side of MSU-1 was working. The Video/FMV side of it is less important, IMO.

I agree completely with you. The audio is the real bread and butter. I've seen the Link To The Past cartoon and the Chrono Trigger cut scenes but we all know the music is really what it's all about

Yeah the latest hack for Street Fighter Alpha 2 is fantastic and has fixed many things wrong with the original release.
It's only using MSU-1 though so I'm glad to hear it's come to MiSTer

msimplay wrote: ↑Tue Apr 13, 2021 3:21 pm Yeah the latest hack for Street Fighter Alpha 2 is fantastic and has fixed many things wrong with the original release.
It's only using MSU-1 though so I'm glad to hear it's come to MiSTer

If you have a Mister then why are you choosing to play SF2 Alpha on the snes when the Cps versions are available!

city909 wrote: ↑Sun Apr 18, 2021 8:44 am

msimplay wrote: ↑Tue Apr 13, 2021 3:21 pm Yeah the latest hack for Street Fighter Alpha 2 is fantastic and has fixed many things wrong with the original release.
It's only using MSU-1 though so I'm glad to hear it's come to MiSTer

If you have a Mister then why are you choosing to play SF2 Alpha on the snes when the Cps versions are available!

I just enjoy comparing different versions of games in particular for this game I like to see how close they can get the port considering how much weaker than the Arcade the SNES.
Gizaha's hack is also fascinating in the way it fixes slowdown and adds support for MSU1 Arcade or Arranged sound track.

My favourite version is actually the Sega Saturn version because of the Sega Saturn Controller and the additions in the game such as playable Shin Akuma .

Sometimes I even prefer the home version of a game for example Ghouls and Ghosts I prefer the changes they made to the game on the Mega Drive version for example if you die on the boss you start at the boss.

msimplay wrote: ↑Sun Apr 18, 2021 6:16 pm My favourite version is actually the Sega Saturn version because of the Sega Saturn Controller.

FYI Retro-Bit make a mean Sega Saturn USB controller which places near the top of the input latency league table.

Comes in 2.4GHz and 3-meter wired USB varieties, with the choice of a number of colours.

https://www.amazon.com/s?k=retrobit+sat ... _sb_noss_1

Any more progress to report, @dentnz?

@rahzadan... Unfortunately not. Recently I spoke with Rysha on Discord, and she indicated that I would need to change the approach I have used before it would be accepted into the main code by Sorgleig. The bad news is that it's basically a rewrite... The good news is that it will be a much better solution in the long run. It would also be more likely that I could get video working.

On a side note, I am currently working on REU for the c64 core. I started it thinking it would be relatively easy, but as with most hardware development, looks can be deceiving it seems. It's been a number of months since I started on that project, and frankly, I want to finish it before I move back onto SNES. It's close-ish though, so I don't imagine it will be too much longer.

One advantage that working on the REU has given me is a MUCH deeper understanding of the SDRAM board and controller. It could be possible to leverage that extra space for more than just cartridge data in the SNES core. Setting up a much larger buffer for audio and video is definitely an approach I might investigate as well.

Sorry to be the bearer of bad news, but it is what it is. I have every intention of returning to it, just wish I had more free time to do this stuff!!!

If anyone wants to pick up where I left off, I can supply code and assistance. I Will be able to get back onto it fully as soon as I can.

@dentnz

No worries dude, just glad to hear that you plan on revisiting it! Please do let us know when you start working on it again!

Cheers!

Sometimes one needs to do something else for a while to come back with a fresher perspective. Good luck with both projects!

dataDave wrote: ↑Thu Apr 22, 2021 6:26 pm

msimplay wrote: ↑Sun Apr 18, 2021 6:16 pm My favourite version is actually the Sega Saturn version because of the Sega Saturn Controller.

FYI Retro-Bit make a mean Sega Saturn USB controller which places near the top of the input latency league table.

Comes in 2.4GHz and 3-meter wired USB varieties, with the choice of a number of colours.

https://www.amazon.com/s?k=retrobit+sat ... _sb_noss_1

I have one of the retrobit controllers and it has a serious fault in it on windows 10 it will press one of the face buttons if i press right on the dpad doesn't matter if its in x-input or d-input.

Although on MiSTer if I switch it to X-input it work's fine but it's very annoying that I have to do this every time I switch the console on or reset it.
It would have been better if they had a physical switch or better if the controller didn't have this fault.

Which leads me onto another issue finding low latency controllers in general I heard the latest versions of 8bitdo controllers are not the same as the older ones in terms of latency. If a new version of the controller comes out there's no guarantee that it will be low latency

I am thinking that snac should be better supported officially but that's a whole other topic

msimplay wrote: ↑Mon Apr 26, 2021 5:40 pm

dataDave wrote: ↑Thu Apr 22, 2021 6:26 pm

msimplay wrote: ↑Sun Apr 18, 2021 6:16 pm My favourite version is actually the Sega Saturn version because of the Sega Saturn Controller.

FYI Retro-Bit make a mean Sega Saturn USB controller which places near the top of the input latency league table.

Comes in 2.4GHz and 3-meter wired USB varieties, with the choice of a number of colours.

https://www.amazon.com/s?k=retrobit+sat ... _sb_noss_1

I have one of the retrobit controllers and it has a serious fault in it on windows 10 it will press one of the face buttons if i press right on the dpad doesn't matter if its in x-input or d-input.

Although on MiSTer if I switch it to X-input it work's fine but it's very annoying that I have to do this every time I switch the console on or reset it.
It would have been better if they had a physical switch or better if the controller didn't have this fault.

Which leads me onto another issue finding low latency controllers in general I heard the latest versions of 8bitdo controllers are not the same as the older ones in terms of latency. If a new version of the controller comes out there's no guarantee that it will be low latency

I am thinking that snac should be better supported officially but that's a whole other topic

Kinda getting a bit off topic.. Might that discussion be better from another thread? This is the MSU-1 thread

I've started to get somewhere with the EXT_BUS change. Basically, I have copied the MegaCD changes into the SNES core AND Main_MiSTer relating to using the EXT_BUS. From there, I setup some keyboard listening in the FPGA to detect and send a 'command' across the EXT_BUS. The Linux side detects a command request, and responds with a 'status'. The FPGA detects this 'status'.

The next step would be to start streaming data across other than a status update... This data would then go into my audio fifo buffer and the existing player (thanks ElectronAsh) would start piping the audio out.

*IF* this works and I can stream data into the fifo fast enough for audio to work, I should be in a pretty good place to sort out the audio MSU1 side of things and get something into the official core. I'd need to hook up the MSU1 registers to a new track selector/player/looper of course, but it should be far easier than all the LBA handling I was doing previously.

From there, it would be a matter of seeing what else I can fit in the EXT_BUS pipe... MSU1 datafile-wise. Maybe there would be enough bits to send both the audio and video data? Anyway, that can come later.

dentnz wrote: ↑Fri May 21, 2021 1:40 am I've started to get somewhere with the EXT_BUS change. Basically, I have copied the MegaCD changes into the SNES core AND Main_MiSTer relating to using the EXT_BUS. From there, I setup some keyboard listening in the FPGA to detect and send a 'command' across the EXT_BUS. The Linux side detects a command request, and responds with a 'status'. The FPGA detects this 'status'.

The next step would be to start streaming data across other than a status update... This data would then go into my audio fifo buffer and the existing player (thanks ElectronAsh) would start piping the audio out.

*IF* this works and I can stream data into the fifo fast enough for audio to work, I should be in a pretty good place to sort out the audio MSU1 side of things and get something into the official core. I'd need to hook up the MSU1 registers to a new track selector/player/looper of course, but it should be far easier than all the LBA handling I was doing previously.

From there, it would be a matter of seeing what else I can fit in the EXT_BUS pipe... MSU1 datafile-wise. Maybe there would be enough bits to send both the audio and video data? Anyway, that can come later.

I don't understand any of it but thank for your hard work on this. It sure doesn't sound easy

That sounds like a promising approach, good luck and thank you.


--------------------------------------------------------------------------------------------------------------------
Never underestimate the bandwith of a Truck full of Magnet Tapes speeding down the highway.

Thanks for the progress update @dentnz Awesome to hear progress is being made. If you need testers please give me a shout!

Thank you for everyone working on the snes core to get msu-1 working. Really looking forward to it.

Hello!
Any updates on the MSU1?

My hope is that integrating MSU-1 into MiSTer SNES core can now be seen as kind of a tribute to its designer, Near. May they rest in peace...

Rahzadan wrote: ↑Mon Jun 28, 2021 3:11 pm My hope is that integrating MSU-1 into MiSTer SNES core can now be seen as kind of a tribute to its designer, Near. May they rest in peace...

He was the creator of MSU? Wow, now I really hope this gets completed someday

Yeah.
Once the MSU1 hopefully has been implemented to MiSTer I will put aside my SNES with the SD2SNES. There are soooo many good MSU1 conversions.

Can't wait for this addition as I have a huge collection of Snes Msu-1 games.

Are there any updates to the MSU-1 implementation? How are you Dentnz?

Hi dentnz,
any progress in msu1 for snes core. Hope you will find time to make this real.

It sounds so fantastic

Have fun

Any more progress on this recently? Anyone know? @dentnz ? Even if not, any news is better than no news...

I don't think anyone is working on this, I haven't heard any news in so long. This is one of the reason I keep a SD2SNES around. I really enjoyed the Earthbound MSU my last playthrough.

yes any info will be great and MSU Sound will be so great and can sell my SD2SNES
Thanks

So I was looking around on github, and it does seem like @dentnz is still working on MSU-1 support. If you look at this branch:

https://github.com/dentnz/SNES_MiSTer/c ... gain_debug

He has commits to it as recently as March 6, 2022!

Don't give up @dentnz!