It is currently Wed Jun 26, 2019 8:56 pm

All times are UTC - 7 hours



Forum rules





Post new topic Reply to topic  [ 40 posts ]  Go to page Previous  1, 2, 3
Author Message
 Post subject: Re: Sonic MSU
PostPosted: Tue Sep 15, 2015 7:36 am 
Offline
User avatar

Joined: Thu Dec 25, 2014 10:26 pm
Posts: 311
Location: Canada
Thank you very much for the reply! I'm using the SD card that came with my SD2SNES. I will make a note to check it's timing when I get home. Though your answer does sound plausible - it screwed up during the first attempt at playback after sitting unused for a long time and then was fine after that.

I'm assuming if one were to implement an MSU1 configuration for a dedicated single-game cartridge in the future, you wouldn't want/need an SD card involved and this problem would theoretically be eliminated...?


Top
 Profile  
 
 Post subject: Re: Sonic MSU
PostPosted: Tue Sep 15, 2015 8:16 am 
Offline
User avatar

Joined: Sat Jul 04, 2009 2:28 pm
Posts: 141
Location: Wunstorf, Germany
That might be a solution. With raw NAND flash you can run into the same problems though. You could minimize random access by using separate chips for audio and data. Sadly there is no kind of flow control with the MSU1 spec which would help alleviate this.

About volume - the sd2snes audio output is rather quiet when compared to bsnes which mixes in MSU audio at full level. It is probably an oversight on my part. A possible hardware mod would be to run the DAC at 5V instead of 3.3V. I recommend normalizing all audio files to 0dB for use with sd2snes, ideally after decompression to avoid clipping in case they are to be shipped in a lossy compression format. That is the most you can get out of the sd2snes without the help of a soldering iron ;)


Top
 Profile  
 
 Post subject: Re: Sonic MSU
PostPosted: Tue Sep 15, 2015 10:43 am 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1477
> Sadly there is no kind of flow control with the MSU1 spec which would help alleviate this.

The idea was incompatible with the goal of simplicity, and wouldn't have been practical. I sacrificed a lot of stuff I really wanted, too, like multiple audio streams so you could do CD BGM+voice acting, enhanced sound effects, etc.

A single DMA can run for up to ten seconds, but even a realistic DMA can transfer a full 64KB of data through MSU1 in one shot. You're not gonna be able to take control of the flow to write back SRAM on a reset button press, or to fetch more audio samples, in the middle of a DMA.

The data was initially intended to be separate: I envisioned something like a giant NAND ROM for the data, and a CD (or another NAND ROM) for the audio tracks. The delays allowed for seeking, but sequential access was presumed after that.

Putting both streams on the SD card is incredibly convenient (and essential), but that complicates things and requires buffering. And of course, you have the save issue. My advice on the save issue would be to store a flag stating the currently loaded game name, hold the SRAM data via battery back-up until next power-on, and have the BIOS write back the SRAM when the system is turned on again and then clear that "SRAM write needed" flag. However, I understand if you don't want to special case just MSU1, or if that design isn't possible for some reason (eg maybe the SRAM isn't battery-backed?)

> That is the most you can get out of the sd2snes without the help of a soldering iron

Damn, so it really is impossible to fix in software, then =(

This is a really tough issue for me. There's only a few people making MSU1 hacks, and they all target sd2snes first.

The problem is that reducing the volume by 1/3rd throws away information that cannot be recovered just by amplifying volume back.

And I can't change the MSU1 spec to say volume should play at 66% max, because some games may have sound effects loud enough that MSU1 can't properly mix with them at that volume (I know, rare for SNES games that are notoriously quiet.)

Plus, matching a spec to a specific hardware implementation will only work once. If anyone else ever releases a flash cart with this support (I know, another long shot), I will be unable to compensate for two conflicting hardware implementations at the same time.

So I guess the solution remains that we need a tool to produce per-implementation MSU1 games. Generate XML for bsnes, BML for higan, or 1/3rd quieter audio for sd2snes.

...

By the way, while you're here ... would you be able to tweak the audio playback rate to 44100hz? The goal was to match redbook audio playback frequency, and it needs to be precise for some of the Satellaview hacks that expect audio to match up to in-game events, where the audio can be up to an hour long.


Top
 Profile  
 
 Post subject: Re: Sonic MSU
PostPosted: Wed Sep 16, 2015 12:26 pm 
Offline

Joined: Tue May 05, 2009 6:12 pm
Posts: 164
byuu wrote:
So I guess the solution remains that we need a tool to produce per-implementation MSU1 games
...
would you be able to tweak the audio playback rate to 44100hz?

I might have missed something, but... If a tool like that is created to adjust the volume (depending on MSU1 target), why not adjust the sample rate too ?


Top
 Profile  
 
 Post subject: Re: Sonic MSU
PostPosted: Wed Sep 16, 2015 8:54 pm 
Offline
User avatar

Joined: Sat Jul 04, 2009 2:28 pm
Posts: 141
Location: Wunstorf, Germany
I'm going to provide a volume boost option for MSU1 audio. Just tried it out and it works better than expected (quite some headroom before clipping).


Top
 Profile  
 
 Post subject: Re: Sonic MSU
PostPosted: Wed Sep 16, 2015 9:18 pm 
Offline
User avatar

Joined: Thu Dec 25, 2014 10:26 pm
Posts: 311
Location: Canada
ikari_01 wrote:
I'm going to provide a volume boost option for MSU1 audio. Just tried it out and it works better than expected (quite some headroom before clipping).

I for one am excited by this development! Thank you!


Top
 Profile  
 
 Post subject: Re: Sonic MSU
PostPosted: Wed Sep 16, 2015 10:29 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1477
> why not adjust the sample rate too ?

Certainly also a possibility. But the audio boost idea sounds extremely promising, so hopefully adjusting the clock rates could get the sample rates closer together (perhaps as an option as well?), in which case we'd have wonderful feature parity :D

Just need to extend icarus to handle importation of MSU1 games in a format compatible with sd2snes (game.sfc+game.msu+game-#.pcm), and I think we'd have a definitive distribution method!


Top
 Profile  
 
 Post subject: Re: Sonic MSU
PostPosted: Wed Sep 16, 2015 10:34 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21461
Location: NE Indiana, USA (NTSC)
For the Satellaview games with hour-long soundtracks, is there a reason they can't be split up into individual 1-minute tracks?

Incidentally, even though the MSU ought not to need it, what's the tolerance on the Super NES sound module's oscillator? I'm told it's wider than that for the 21.47 MHz master clock because it doesn't have to feed a color modulator.

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
 Post subject: Re: Sonic MSU
PostPosted: Thu Sep 17, 2015 9:21 am 
Offline

Joined: Thu Aug 28, 2008 1:17 am
Posts: 591
Khaz wrote:
Uploaded a demonstration to Youtube. Long overdue but meh, better late than never. Wish I could have gotten a better quality video of the TV screen but I think it gets the point across...


Nice :D

Quote:
The video was rendered into SNES format by a python script that I invented, which you can also find on my github page (under SNESTools). The script takes in a simple bitmap file, breaks it down into tiles, quantizes a palette of 16 colors to represent each tile, and then merges similar palettes together until you have 8 remaining - the maximum number of color palettes the SNES can have at a time for "backgrounds".


Care to share info on your algorithm for the sub-palette merge section?

_________________
__________________________
http://pcedev.wordpress.com


Top
 Profile  
 
 Post subject: Re: Sonic MSU
PostPosted: Thu Sep 17, 2015 9:41 am 
Offline
User avatar

Joined: Thu Dec 25, 2014 10:26 pm
Posts: 311
Location: Canada
tomaitheous wrote:
Care to share info on your algorithm for the sub-palette merge section?

Well, if you can read Python the source is on my github linked in my first post here (file is "Quantomatic.py").

It works like this: Each palette has a variable of how well it represents its tiles, measured simply as the sum "distance" of each actual pixel color from the closest palette color. The program then compares a block of N palettes to each other (N defaults to 20 I think but can be adjusted), and merges the two that are the closest together before comparing the next block.

The comparison tests two palettes by checking what the sum "distance" would be if each palette's tiles were rendered in the other palette. The lowest sum distance found is declared the best fit, the two sets of tiles are merged into one, and a new palette is quantized out for the merged set.

Been a while so I'm rusty on the fine details, but if you want to know more I can look at the source code and explain. I'm sure it's probably possible to improve on my method; if you have a proposal how to I'd be interested to hear it.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 40 posts ]  Go to page Previous  1, 2, 3

All times are UTC - 7 hours


Who is online

Users browsing this forum: Google [Bot], topspoon and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group