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?
Go for it. MD+ is great. A true MSU1 equivalent for the Mega Drive.
MSU-1
Re: Msu-1
Re: MSU-1
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.
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.
Re: MSU-1
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".
-
aberu
- Core Developer
- Posts: 1192
- Joined: Tue Jun 09, 2020 8:34 pm
- Location: Longmont, CO
- Has thanked: 247 times
- Been thanked: 411 times
- Contact:
Re: MSU-1
Is there anything different between this and the MegaCD release of the same game?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
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~
Re: MSU-1
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.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.
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.
Re: MSU-1
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.aberu wrote: ↑Tue Jan 12, 2021 11:08 pmIs there anything different between this and the MegaCD release of the same game?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
The SNES, OTOH, makes the game shine.
-
aberu
- Core Developer
- Posts: 1192
- Joined: Tue Jun 09, 2020 8:34 pm
- Location: Longmont, CO
- Has thanked: 247 times
- Been thanked: 411 times
- Contact:
Re: MSU-1
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.dentnz wrote: ↑Thu Jan 14, 2021 10:36 pmNot 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.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.
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.
birdybro~
Re: MSU-1
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.
Re: MSU-1
I didn't think MSU was possible on this core. Have you had the time to do any testing? I'm dying to know
-
tontonkaloun
- Posts: 354
- Joined: Sun May 24, 2020 7:38 pm
- Has thanked: 153 times
- Been thanked: 52 times
Re: MSU-1
Hello
A little test with an old version
without msu1
https://youtu.be/CtcXSOJO95I
with msu1
https://youtu.be/RoddIhHvrvI
A little test with an old version
without msu1
https://youtu.be/CtcXSOJO95I
with msu1
https://youtu.be/RoddIhHvrvI
Re: MSU-1
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.
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.-
teknomedic
- Posts: 18
- Joined: Sat Jan 30, 2021 1:17 pm
- Has thanked: 1 time
- Been thanked: 2 times
Re: MSU-1
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??
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??
-
SwedishGojira
- Posts: 64
- Joined: Sun May 24, 2020 7:26 pm
- Location: Sweden
- Has thanked: 26 times
- Been thanked: 28 times
- Contact:
Re: MSU-1
The MegaCD core already support MD+/MSU-MD for a while now. Just check here for more info.teknomedic wrote: ↑Wed Feb 10, 2021 8:05 am Is anyone working on MD+ / MSU-MD support for the Genesis core??
Check out my MiSTer scripts on Github.
Re: MSU-1
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.SwedishGojira wrote: ↑Wed Feb 10, 2021 10:04 amThe MegaCD core already support MD+/MSU-MD for a while now. Just check here for more info.teknomedic wrote: ↑Wed Feb 10, 2021 8:05 am Is anyone working on MD+ / MSU-MD support for the Genesis core??
Re: MSU-1
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...
-
- 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...
-
Re: MSU-1
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?
Re: MSU-1
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
Re: MSU-1
If you have a Mister then why are you choosing to play SF2 Alpha on the snes when the Cps versions are available!
Re: MSU-1
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.
Re: MSU-1
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
Re: MSU-1
@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.
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.