Page 2 of 3

Re: Msu-1

Posted: Sat May 30, 2020 3:46 am
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?

Re: Msu-1

Posted: Sat May 30, 2020 7:48 am
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.

Re: Msu-1

Posted: Sat Jun 06, 2020 3:09 am
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.

Re: Msu-1

Posted: Sat Jun 06, 2020 3:10 am
by dentnz
One thing we could definitely reuse this for is the MD+... but I know there’s some real aversion to that one ;)

Re: Msu-1

Posted: Sat Oct 17, 2020 3:15 am
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?

Re: Msu-1

Posted: Sun Oct 18, 2020 1:18 pm
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.

Re: MSU-1

Posted: Thu Dec 10, 2020 2:42 am
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.

Re: MSU-1

Posted: Sun Dec 13, 2020 10:58 am
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.

Re: MSU-1

Posted: Mon Dec 21, 2020 4:04 am
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".

Re: MSU-1

Posted: Mon Dec 21, 2020 3:12 pm
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

Re: MSU-1

Posted: Sat Dec 26, 2020 7:53 pm
by Mr^O^BIG
I say yes :)

Mr BIG

Re: MSU-1

Posted: Tue Jan 12, 2021 11:08 pm
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.

Re: MSU-1

Posted: Thu Jan 14, 2021 10:36 pm
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.

Re: MSU-1

Posted: Tue Jan 19, 2021 3:24 pm
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.

Re: MSU-1

Posted: Wed Jan 20, 2021 4:41 am
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.

Re: MSU-1

Posted: Fri Jan 22, 2021 4:29 am
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.

Re: MSU-1

Posted: Sat Jan 30, 2021 8:42 pm
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

Re: MSU-1

Posted: Sat Jan 30, 2021 9:54 pm
by tontonkaloun
Hello

A little test with an old version

without msu1
https://youtu.be/CtcXSOJO95I

with msu1
https://youtu.be/RoddIhHvrvI

Re: MSU-1

Posted: Sun Jan 31, 2021 4:26 pm
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

Re: MSU-1

Posted: Mon Feb 01, 2021 4:48 am
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.

Re: MSU-1

Posted: Mon Feb 08, 2021 2:20 pm
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.

Re: MSU-1

Posted: Wed Feb 10, 2021 12:15 am
by Rahzadan
@dentnz, awesome to see you working on this again! Looking forward to progress/release!

Re: MSU-1

Posted: Wed Feb 10, 2021 8:05 am
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??

Re: MSU-1

Posted: Wed Feb 10, 2021 10:04 am
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.

Re: MSU-1

Posted: Wed Feb 10, 2021 6:38 pm
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.