MSU-1

Flain
Posts: 25
Joined: Mon May 25, 2020 1:29 am
Has thanked: 17 times
Been thanked: 5 times

Re: Msu-1

Unread post by 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
Posts: 105
Joined: Sun May 24, 2020 7:29 pm
Has thanked: 7 times
Been thanked: 38 times

Re: Msu-1

Unread post by Optiroc »

Flain wrote: Sat May 30, 2020 3:46 am 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
Core Developer
Posts: 54
Joined: Sun May 24, 2020 10:28 pm
Been thanked: 14 times

Re: Msu-1

Unread post by dentnz »

Flain wrote: Sat May 30, 2020 3:46 am 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
Core Developer
Posts: 54
Joined: Sun May 24, 2020 10:28 pm
Been thanked: 14 times

Re: Msu-1

Unread post by dentnz »

One thing we could definitely reuse this for is the MD+... but I know there’s some real aversion to that one ;)
Rahzadan
Posts: 25
Joined: Sat Oct 17, 2020 3:13 am
Has thanked: 1 time
Been thanked: 4 times

Re: Msu-1

Unread post by 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?
Relikk
Posts: 13
Joined: Wed Sep 16, 2020 1:55 pm
Has thanked: 4 times

Re: Msu-1

Unread post by Relikk »

Rahzadan wrote: Sat Oct 17, 2020 3:15 amAny 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?
As a contributor to the MSU1 scene I'm interested in this, also. Is there a way to get any of previous cores I've seen used in some YouTube videos or have they been private?
dentnz wrote: Sat Jun 06, 2020 3:10 amOne thing we could definitely reuse this for is the MD+... but I know there’s some real aversion to that one ;)
Go for it. MD+ is great. A true MSU1 equivalent for the Mega Drive.
Rahzadan
Posts: 25
Joined: Sat Oct 17, 2020 3:13 am
Has thanked: 1 time
Been thanked: 4 times

Re: MSU-1

Unread post by Rahzadan »

So, is the work on MSU-1 currently at a standstill or has there been any recent progress? I'm guessing due to the lack of responses in this thread, that it is the former :(

Really hoping to see this officially implemented. I understand it's an "unofficial" thing (i.e it did not exist in SNES' hayday), but since it's supported on FXPAK/SD2SNES and works on real hardware, I think it's 100% worth it to include if it can be done properly.

I've used a very old core built by dentnz, but it still had quite a few bugs, and required that the main MiSTer binary be swapped out to use it.
Relikk
Posts: 13
Joined: Wed Sep 16, 2020 1:55 pm
Has thanked: 4 times

Re: MSU-1

Unread post by Relikk »

I see it the same way. It's equivalent to any special chip enhancement such as SA-1 etc. Just because it came out after the SNES' production lifespan doesn't make it any different.
ExCyber
Posts: 217
Joined: Sun May 24, 2020 3:33 pm
Has thanked: 11 times
Been thanked: 66 times

Re: MSU-1

Unread post by ExCyber »

Relikk wrote: Sun Dec 13, 2020 10:58 am I see it the same way. It's equivalent to any special chip enhancement such as SA-1 etc. Just because it came out after the SNES' production lifespan doesn't make it any different.
That's true as far as it goes. What makes MSU-1 different is that it's demanding on the hardware in ways that chips designed for real-world early-'90s mass production aren't. The interface was designed to be straightforward to program and able to saturate the SNES cartridge bus, not so much to be easy/cheap to build. I guess it's fairly tractable if you're designing your own purpose-built MSU-1 cartridge, but it's a lot more challenging to adapt it to a memory architecture that wasn't designed for it. Especially one where the underlying storage specification is effectively "nonexclusive best-effort access to whatever microSD card was on sale at Walmart recently".
vanfanel
Posts: 119
Joined: Sun May 24, 2020 6:53 pm
Has thanked: 9 times
Been thanked: 20 times

Re: MSU-1

Unread post by vanfanel »

Only for this, I think the MSU-1 should make it's way into the SNES core:

https://www.youtube.com/watch?v=BvIXUOr4yxU
Mr^O^BIG
Posts: 35
Joined: Sun May 24, 2020 7:02 pm
Has thanked: 1 time
Been thanked: 9 times

Re: MSU-1

Unread post by Mr^O^BIG »

I say yes :)

Mr BIG
User avatar
aberu
Core Developer
Posts: 1144
Joined: Tue Jun 09, 2020 8:34 pm
Location: Longmont, CO
Has thanked: 244 times
Been thanked: 388 times
Contact:

Re: MSU-1

Unread post by aberu »

vanfanel wrote: Mon Dec 21, 2020 3:12 pm Only for this, I think the MSU-1 should make it's way into the SNES core:

https://www.youtube.com/watch?v=BvIXUOr4yxU
Is there anything different between this and the MegaCD release of the same game?

MSU-1 won't happen on the official normal SNES core unless someone forks the SNES core and rips out all the addon chips and makes a SNES-MSU-1 separate core. The core is using 90% of the FPGA's space basically as is, without MSU-1. It's the second largest behind ao486.
birdybro~
dentnz
Core Developer
Posts: 54
Joined: Sun May 24, 2020 10:28 pm
Been thanked: 14 times

Re: MSU-1

Unread post by dentnz »

MSU-1 won't happen on the official normal SNES core unless someone forks the SNES core and rips out all the addon chips and makes a SNES-MSU-1 separate core. The core is using 90% of the FPGA's space basically as is, without MSU-1. It's the second largest behind ao486.
Not necessarily. It's entirely possible that a smaller FIFO buffer could be used *IF* I can fill it fast enough for the DMA that occurs in some players. There have been a number of additions to the framework by Sorg, including additional HPS bus space (32 bits?). It might be possible to utilise this additional bandwidth to transfer data from the ARM to the FPGA without having to fill a larger FIFO buffer on the the FPGA itself. It would also have the added benefit of not being affected by other actions on the HPS bridge, i.e opening the OSD causes audio skipping, and ruins video entirely.

There's also the possibility of putting more of the audio/video into SDRAM or even into DDR. However, I would need to make the SNES core capable of writing to SDRAM, which is only currently used for ROM data, and therefore read only. I started to look at sourcing an open source FIFO with a flexible storage backend, but it started to get complicated with regards to changing the SNES cores utilisation of SDRAM/DDR.

One day I will have another look at it. The SNES core is pretty much 'done' now as far as I am aware.
vanfanel
Posts: 119
Joined: Sun May 24, 2020 6:53 pm
Has thanked: 9 times
Been thanked: 20 times

Re: MSU-1

Unread post by vanfanel »

aberu wrote: Tue Jan 12, 2021 11:08 pm
vanfanel wrote: Mon Dec 21, 2020 3:12 pm Only for this, I think the MSU-1 should make it's way into the SNES core:

https://www.youtube.com/watch?v=BvIXUOr4yxU
Is there anything different between this and the MegaCD release of the same game?

The only thing that can be different in this kind of game: HUGE difference in video quality. I love the MegaDrive, but it's color palette isn't suited for FMV games.
The SNES, OTOH, makes the game shine.
User avatar
aberu
Core Developer
Posts: 1144
Joined: Tue Jun 09, 2020 8:34 pm
Location: Longmont, CO
Has thanked: 244 times
Been thanked: 388 times
Contact:

Re: MSU-1

Unread post by aberu »

dentnz wrote: Thu Jan 14, 2021 10:36 pm
MSU-1 won't happen on the official normal SNES core unless someone forks the SNES core and rips out all the addon chips and makes a SNES-MSU-1 separate core. The core is using 90% of the FPGA's space basically as is, without MSU-1. It's the second largest behind ao486.
Not necessarily. It's entirely possible that a smaller FIFO buffer could be used *IF* I can fill it fast enough for the DMA that occurs in some players. There have been a number of additions to the framework by Sorg, including additional HPS bus space (32 bits?). It might be possible to utilise this additional bandwidth to transfer data from the ARM to the FPGA without having to fill a larger FIFO buffer on the the FPGA itself. It would also have the added benefit of not being affected by other actions on the HPS bridge, i.e opening the OSD causes audio skipping, and ruins video entirely.

There's also the possibility of putting more of the audio/video into SDRAM or even into DDR. However, I would need to make the SNES core capable of writing to SDRAM, which is only currently used for ROM data, and therefore read only. I started to look at sourcing an open source FIFO with a flexible storage backend, but it started to get complicated with regards to changing the SNES cores utilisation of SDRAM/DDR.

One day I will have another look at it. The SNES core is pretty much 'done' now as far as I am aware.
Wow this is all amazing. Last I had heard it was just too full, but you have opened my mind. I love how this project has so many hardworking people with great ideas like this.
birdybro~
dentnz
Core Developer
Posts: 54
Joined: Sun May 24, 2020 10:28 pm
Been thanked: 14 times

Re: MSU-1

Unread post by dentnz »

I've manually merged a reasonably new set of MSU-1 code into the latest master code. It compiled, but am yet to test. I'd like to tidy it up and maybe see if I can get the audio side of it into the main branch.
djsquare
Posts: 117
Joined: Mon May 25, 2020 3:29 pm
Has thanked: 15 times
Been thanked: 16 times

Re: MSU-1

Unread post by djsquare »

dentnz wrote: Fri Jan 22, 2021 4:29 am I've manually merged a reasonably new set of MSU-1 code into the latest master code. It compiled, but am yet to test. I'd like to tidy it up and maybe see if I can get the audio side of it into the main branch.
I didn't think MSU was possible on this core. Have you had the time to do any testing? I'm dying to know
User avatar
tontonkaloun
Posts: 354
Joined: Sun May 24, 2020 7:38 pm
Has thanked: 152 times
Been thanked: 51 times

Re: MSU-1

Unread post by tontonkaloun »

Hello

A little test with an old version

without msu1
https://youtu.be/CtcXSOJO95I

with msu1
https://youtu.be/RoddIhHvrvI
djsquare
Posts: 117
Joined: Mon May 25, 2020 3:29 pm
Has thanked: 15 times
Been thanked: 16 times

Re: MSU-1

Unread post by djsquare »

well this is amazing. I hope we can have MSU for this core. I played Zelda on my buddies SD2SNES some years back and music was absolutely mind blowing
dentnz
Core Developer
Posts: 54
Joined: Sun May 24, 2020 10:28 pm
Been thanked: 14 times

Re: MSU-1

Unread post by dentnz »

https://www.youtube.com/watch?v=DfY3afu2rzc

Audio sounds like it is working well... Better in fact, since opening the OSD does not cause the audio to stutter. I think these are changes that were added to the OSD as part of the MegaCD and PCE CD cores.

Video is NOT working however. I have a feeling that I am not looking at the last code changes. I may have lost them :( My latest work (over 12 months ago) was on an old work laptop that I had to return once I left that job. Anyway, I have added in some debug signal tap, and will begin debugging i soon.
commander
Posts: 27
Joined: Mon May 25, 2020 6:56 am
Has thanked: 2 times
Been thanked: 2 times

Re: MSU-1

Unread post by commander »

great to hear we will have msu1 support in the future.
Thanks for you effords. Any news in developement.
It will be great if it comes into the official snes core.
Rahzadan
Posts: 25
Joined: Sat Oct 17, 2020 3:13 am
Has thanked: 1 time
Been thanked: 4 times

Re: MSU-1

Unread post by Rahzadan »

@dentnz, awesome to see you working on this again! Looking forward to progress/release!
teknomedic
Posts: 18
Joined: Sat Jan 30, 2021 1:17 pm
Has thanked: 1 time
Been thanked: 2 times

Re: MSU-1

Unread post by teknomedic »

Good news to hear for sure, sorry you may have lost some work though. Certainly looking forward to this being added to the official core.

Even if not official, an MSU fork would be welcome.

Now I just have to learn how to add an unofficial core to my MiSTer, lol. (assuming this could be added to the "update all" script? 😉

Is anyone working on MD+ / MSU-MD support for the Genesis core??
User avatar
SwedishGojira
Posts: 57
Joined: Sun May 24, 2020 7:26 pm
Location: Sweden
Has thanked: 23 times
Been thanked: 27 times
Contact:

Re: MSU-1

Unread post by SwedishGojira »

teknomedic wrote: Wed Feb 10, 2021 8:05 am Is anyone working on MD+ / MSU-MD support for the Genesis core??
The MegaCD core already support MD+/MSU-MD for a while now. Just check here for more info.
Relikk
Posts: 13
Joined: Wed Sep 16, 2020 1:55 pm
Has thanked: 4 times

Re: MSU-1

Unread post by Relikk »

SwedishGojira wrote: Wed Feb 10, 2021 10:04 am
teknomedic wrote: Wed Feb 10, 2021 8:05 am Is anyone working on MD+ / MSU-MD support for the Genesis core??
The MegaCD core already support MD+/MSU-MD for a while now. Just check here for more info.
Unfortunately it doesn't support MD+. It only supports MSU-MD which, as far as the MiSTer goes, has less appeal where I'm concerned. It's fine for flash cartridge usage where you can use it on select cartridges in tandem with a CD unit attached and a burned CD for the soundtrack. Seeing as you don't need either of those for MiSTer, implementing MD+ would make more sense with its seamless looping capability. Of course, supporting both options would be the ideal scenario for the hacks that exist for them at the moment.
dentnz
Core Developer
Posts: 54
Joined: Sun May 24, 2020 10:28 pm
Been thanked: 14 times

Re: MSU-1

Unread post by dentnz »

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...
-
ExCyber
Posts: 217
Joined: Sun May 24, 2020 3:33 pm
Has thanked: 11 times
Been thanked: 66 times

Re: MSU-1

Unread post by ExCyber »

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?
Rahzadan
Posts: 25
Joined: Sat Oct 17, 2020 3:13 am
Has thanked: 1 time
Been thanked: 4 times

Re: MSU-1

Unread post by Rahzadan »

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.
djsquare
Posts: 117
Joined: Mon May 25, 2020 3:29 pm
Has thanked: 15 times
Been thanked: 16 times

Re: MSU-1

Unread post by djsquare »

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
msimplay
Posts: 50
Joined: Tue Jun 16, 2020 6:33 am
Has thanked: 32 times
Been thanked: 2 times

Re: MSU-1

Unread post by msimplay »

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
Post Reply