MSU-1

Flain
Posts: 7
Joined: Mon May 25, 2020 1:29 am
Has thanked: 2 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: 13
Joined: Sun May 24, 2020 7:29 pm

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
Posts: 29
Joined: Sun May 24, 2020 10:28 pm
Been thanked: 1 time

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
Posts: 29
Joined: Sun May 24, 2020 10:28 pm
Been thanked: 1 time

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: 2
Joined: Sat Oct 17, 2020 3:13 am

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: 2
Joined: Wed Sep 16, 2020 1:55 pm
Has thanked: 1 time

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: 2
Joined: Sat Oct 17, 2020 3:13 am

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: 2
Joined: Wed Sep 16, 2020 1:55 pm
Has thanked: 1 time

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: 114
Joined: Sun May 24, 2020 3:33 pm
Has thanked: 1 time
Been thanked: 14 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: 22
Joined: Sun May 24, 2020 6:53 pm
Been thanked: 1 time

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: 18
Joined: Sun May 24, 2020 7:02 pm
Has thanked: 1 time

Re: MSU-1

Unread post by Mr^O^BIG »

I say yes :)

Mr BIG
User avatar
aberu
Posts: 230
Joined: Tue Jun 09, 2020 8:34 pm
Location: Longmont, CO
Has thanked: 24 times
Been thanked: 26 times

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.
dentnz
Posts: 29
Joined: Sun May 24, 2020 10:28 pm
Been thanked: 1 time

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: 22
Joined: Sun May 24, 2020 6:53 pm
Been thanked: 1 time

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
Posts: 230
Joined: Tue Jun 09, 2020 8:34 pm
Location: Longmont, CO
Has thanked: 24 times
Been thanked: 26 times

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