It is currently Wed Oct 18, 2017 8:51 pm

All times are UTC - 7 hours



Forum rules


Related:



Post new topic Reply to topic  [ 52 posts ]  Go to page Previous  1, 2, 3, 4  Next
Author Message
PostPosted: Mon Aug 08, 2016 11:15 pm 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3071
Location: Nacogdoches, Texas
93143 wrote:
Well, there's the S-DD1, which is supposed to be able to handle 256 MB in theory.

Isn't that the chip used in Street Fighter Alpha 2?

93143 wrote:
The Super Game Boy does the same thing - what you hear is real DMG sound output.

I never actually knew that...

I can't help but find it funny though that the audio hardware is probably the most advanced (compared to other systems about how advanced their audio hardware was to their video hardware) part of the system, yet the easiest to bypass. :lol:

93143 wrote:
Did you forget to pan them?

I'm not entirely sure what panning in the context of audio means, but I think I messed up. When I split the audio in two, they were set as "right" and "left" instead of "mono" and brr_encode said that it had to convert two audio channels into one, but I didn't think about how all that really means is it's muffling it, so I went back and made sure that both tracks said "mono" and brr_encode didn't complain about there being too tracks. The results are so similar now, that I actually had to go and look at a hex editor to make sure the final outputted file was even any different.

Attachment:
Fair Comparison (WAV vs. BRR).zip [1.58 MiB]
Downloaded 40 times

I wonder though, is this just not a good sample to try and see quality loss? I might want to try a song with vocals or something, but considering this turned out next to flawless, I can't imagine anything will even sound as muffled as most SNES soundtracks.

It seems the 32KHz demo of this song using uncompressed audio was really just to show off more than anything. :lol: (Not that it's not impressive.)

Edit: I tried it with a couple more samples that I thought were about the polar opposite of this, and still, it doesn't make a difference in that they sound exactly the same. Even songs with vocals don't make a difference. I bet only something deliberately designed to screw this up would make a difference, but it probably wouldn't even qualify as music.


Top
 Profile  
 
PostPosted: Tue Aug 09, 2016 9:45 pm 
Online

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 782
Espozo wrote:
Isn't that the chip used in Street Fighter Alpha 2?

Yes. The largest ROM it has been demonstrated to work with is 48 Mbit (Star Ocean). Anything higher is apparently speculation, though it seems reasonable to expect at least 64 Mbit...

Quote:
I'm not entirely sure what panning in the context of audio means

It means positioning in the stereo field.

https://en.wikipedia.org/wiki/Panning_(audio)

With a stereo recording or mix, the stereo distribution can be very complex in terms of frequency and phase, but ultimately it consists of one signal on the left channel and one signal on the right channel. If you take those signals and mix them in equal amounts on both channels, the result is a mono track; the stereo information is lost.

And apparently that's what BRRTools does if you feed it a stereo input...

Quote:
I wonder though, is this just not a good sample to try and see quality loss? I might want to try a song with vocals or something, but considering this turned out next to flawless, I can't imagine anything will even sound as muffled as most SNES soundtracks.

Did you use the -g option when encoding/decoding? It's the Gaussian anti-aliasing interpolation that causes muffling, not the BRR compression; BRR just adds noise. Even with a treble boost filter applied before encoding (that's what -g does in the encoder), the result won't sound as good as a straight encode/decode with no Gaussian, partly due to the boost filter not exactly mirroring the effect of the interpolator and partly (I imagine) due to the boosted treble consuming more of the BRR format's limited bandwidth than it deserves... (I wonder if this second effect wouldn't be significantly worse with my heavy-duty high-precision prefilter than with the simple 8-tap one in BRRTools, since mine boosts a lot more up near the Nyquist - this could be bad with a DPCM relative, however distantly related...)

I should also mention that even the Gaussian interpolator isn't the whole story; a lot of the "characteristic SNES muffling" is due to lower-rate samples used to save memory. You're using 32 kHz, which can be noticeably less sharp than 44.1 kHz on some material if you've got good ears, but isn't really what you'd call "muffled" (and it's as good as the SNES can do anyway). The vocal samples in Street Fighter Alpha 2 seem to be 22 kHz in the original, which is perfectly adequate, but between 4 and 6 kHz in the SNES version, which really isn't...


Top
 Profile  
 
PostPosted: Tue Aug 09, 2016 10:07 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2286
How much does your prefilter boost the frequencies above the nyquist frequency?


Top
 Profile  
 
PostPosted: Tue Aug 09, 2016 10:10 pm 
Online

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 782
It doesn't. It's designed to be used on audio that's already at the final sample rate, so there's nothing above the Nyquist to boost.


Top
 Profile  
 
PostPosted: Tue Aug 09, 2016 11:00 pm 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3071
Location: Nacogdoches, Texas
93143 wrote:
Yes. The largest ROM it has been demonstrated to work with is 48 Mbit (Star Ocean). Anything higher is apparently speculation, though it seems reasonable to expect at least 64 Mbit...

I wonder if byuu knows if it can hold more data. I'm not too keen on the fact that really only two things support the MSU-1 (and I don't like how it completely bypasses the audio hardware) so that's why this seems more appealing to me, but it would be handy to know how it works first. :lol:

93143 wrote:
Did you use the -g option when encoding/decoding? It's the Gaussian anti-aliasing interpolation that causes muffling, not the BRR compression

No, I didn't use it. If all it does is just muffle the thing and (I assume) not lower the sample size like BRR does by itself (assuming again), then what's the point, unless this is specifically for samples less than 32KHz in that it tries to smoothen them out, but I didn't need to do that.

93143 wrote:
I should also mention that even the Gaussian interpolator isn't the whole story; a lot of the "characteristic SNES muffling" is due to lower-rate samples used to save memory.

Isn't the Gaussian interpolator only used because of lower rate samples? I imagine that just because a sample is lower rate doesn't mean it's muffled, doesn't that just mean it's choppy or distorted?

93143 wrote:
You're using 32 kHz, which can be noticeably less sharp than 44.1 kHz on some material if you've got good ears

I didn't know a 17 year old could have a hearing deficit then, because I don't hear the slightest difference. It could be my cheap laptop speakers too.

93143 wrote:
but between 4 and 6 kHz in the SNES version, which really isn't...

That really is shit. The reason I wanted to stream audio in the first place is not because I don't believe 8 channels aren't sufficient or something, but if I wanted as many things in audio ram as possible (different instruments and sound effects) it would have to be at sub 8KHz levels unless some miracle happened. I got to thinking about streaming audio samples out so much that I figured it might actually just be easier and be less data to push through (why send data for 4 instruments to audio ram when you can send two tracks for less?). The problem now is that because the bandwidth going to audio ram is maxed out, there is no way to replace sound effects during a level or something, if I can even get them all in there to begin with.

Edit (before even releasing this for the first time, because I now realize this is even more of a stupid idea):

I might try to do something like vram slots where if the sample isn't being used, it can be overwritten, (some data will be reserved for variables and the code for running the audio, but the data for the composition of the song could be overwritten.) but this might be insane for multiple reasons, like if you're trying to stream more data than you're supposed to, with vram, you just bring a little bit of black down the screen for a frame, but you can't even do that here, you'll be missing data, and it won't be nothing, it will be the remnants of the sample under that slot unless you programmed it to where the SPC700 wouldn't make the DSP play there. You could also use code at the beginning of them that tells the SPC700 how they want to be played. What I mean by this is that although this: https://www.youtube.com/watch?v=aeXT5ma3_so is one sound effect, it is clearly a sample being looped multiple times, so you could have the self modifying code (because it's all in ram) that This whole scheme is probably crazy though because of the limited processing power of the SPC700 (mainly due to the fact that you're crippling it by streaming) but I really don't like programming for the worst case scenario, because the worst case scenario almost never happens in games unless you deliberately try and break them by doing something like luring all the enemies in a level into one area. This also eliminates the chance of streaming one long audio sample for a song, but I probably would have been screwed anyway. I don't even know what I'm going to do, but I have other things to worry about.


Top
 Profile  
 
PostPosted: Wed Aug 10, 2016 2:15 am 
Online

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 782
Espozo wrote:
93143 wrote:
Did you use the -g option when encoding/decoding? It's the Gaussian anti-aliasing interpolation that causes muffling, not the BRR compression

No, I didn't use it. If all it does is just muffle the thing and (I assume) not lower the sample size like BRR does by itself (assuming again), then what's the point, unless this is specifically for samples less than 32KHz in that it tries to smoothen them out, but I didn't need to do that.

The S-DSP runs an anti-aliasing interpolator on decoded BRR data before playback. It does not recover the original audio when it's 32 kHz. In fact it always produces a muffling effect which is uniform when normalized to the input sample rate - for example, at 70% of the Nyquist folding frequency (that is, 35% of the sample rate), the attenuation is about 8 dB, meaning if you play your sample back at 32 kHz, the attenuation will reach 8 dB a little past 11 kHz in the output spectrum, and if you play it back at 8 kHz, you'll get 8 dB of attenuation a little below 3 kHz. (The interpolator also produces a slight brightening effect at 32 kHz in the output spectrum, but it's probably cancelled out by the analog filtering downstream of the DAC, so I wouldn't worry about it.) The fact that the muffling is basically constant in the input frequency domain means that you can counter it with a static treble boost baked into the sample, even if the sample is expected to be played back at lots of different pitches.

What the -g option does depends on whether you're encoding or decoding. When you're decoding, it simulates the effect of the S-DSP's interpolator so you can hear what your sample will sound like on an actual SNES (except that it assumes your sample is at 32 kHz, so it includes the secondary brightening effect). When you're encoding, though, what it does is boost the treble before converting the sample to BRR so as to somewhat counteract the muffling effect of the S-DSP's anti-aliasing.

Quote:
Isn't the Gaussian interpolator only used because of lower rate samples?

Yes. But the way it's designed, it affects 32 kHz playback too.

Quote:
I imagine that just because a sample is lower rate doesn't mean it's muffled, doesn't that just mean it's choppy or distorted?

You imagine wrong. Lower sample rate means you're chopping off high-frequency information, which muffles the sound. On a system without anti-aliasing, like the Mega Drive or Game Boy Advance, the output waveform is more jaggy, and this manifests as ugly high-frequency noise that can somewhat compensate for the lack of real treble information. But the SNES was specifically designed to eliminate that noise, so it just sounds muffled. Extra muffled if the input wasn't treble-boosted to compensate for the Gaussian anti-aliasing...

Also, some Mega Drive audio engines have trouble feeding the DAC at a consistent rate, so the audio gets choppy and distorted.

Here, have an example. Original is at 22 kHz. I converted it to 6.5 kHz to show you what that sounds like (through your PC's interpolator, which is generally pretty good). Then I truncated the 6.5 kHz version to 8-bit (which is a basically inaudible change in this case) and upped it to 26 kHz with sample-and-hold (the equivalent of nearest-neighbour in graphics) to show you roughly what it would sound like on the Mega Drive with a good, stable audio engine. Then I ran the 6.5 kHz version through BRRTools (without -g) and used my own implementation of the S-DSP's anti-aliasing interpolator to resample it to 32 kHz, to show you what it would sound like on the SNES. You will note that the SNES version is even more muffled than the baseline 6.5 kHz version; this is because I didn't use any sort of treble boost prefilter...

Attachment:
koryuken.7z [130.04 KiB]
Downloaded 39 times

Quote:
It could be my cheap laptop speakers too.

I think we've identified the problem.

...

What I figured I'd do with streaming was plan the song so that it never exceeds a certain streaming budget, which would be lower than the maximum available bandwidth so as to leave room for any sound effects that might need to be streamed at the same time. (This isn't as restrictive as it sounds; just about nothing actually needs to be at 32 kHz in terms of individual instruments, and if you're replacing whole samples that aren't playing at the moment, they don't even need to be streamed at their desired playback speed.) This somewhat limits the application of streaming to sound effects, since you have to make sure you can never have more of them playing than will fit in the reserved bandwidth, but (a) you might want to limit them anyway so as to minimize interruptions in the music channels, and (b) not every sound effect needs a long high-fidelity sample that won't fit in audio RAM alongside the music.

This would use far, far less memory than trying to fit whole songs in ROM as massive BRR streams, while still potentially sounding much better than the usual ARAM-bound fare. Especially coupled with advanced techniques like pitch modulation and KungFuFurby's loop switching trick...

But we're getting ahead of ourselves. The state of the art is nowhere near the bandwidth I'm talking about, not without a severe hit to S-CPU time. I need to get my method actually assembled and tested in context before bragging about how much it can do...


Top
 Profile  
 
PostPosted: Wed Aug 10, 2016 9:23 am 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2286
Why was the sound quality in SFA so bad?, and why did it take so long to load?


Top
 Profile  
 
PostPosted: Wed Aug 10, 2016 9:45 am 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3071
Location: Nacogdoches, Texas
93143 wrote:
The S-DSP runs an anti-aliasing interpolator on decoded BRR data before playback. It does not recover the original audio when it's 32 kHz.

That's unfortunate... :( Could this be why they have the "32KHz, Uncompressed" demo, or does this also affect the echo buffer trick thing?

Well, anyway, here's a comparison of the same track from earlier, but encoded and or decoded:

Attachment:
(Hopefully) The Final Comparison.zip [2.32 MiB]
Downloaded 40 times

Honestly, it's still hard for me to tell the difference. If I had to pick between Decoded or Encoded And Decoded, I'd go with Encoded and Decoded though, because I think it might be marginally better.

I guess the uncompressed demo is still unjustified... :lol:

psycopathicteen wrote:
Why was the sound quality in SFA so bad?

I heard the music in SFA is pretty good: http://www.music.sfasu.edu/


Top
 Profile  
 
PostPosted: Wed Aug 10, 2016 7:44 pm 
Online

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 782
psycopathicteen wrote:
Why was the sound quality in SFA so bad?, and why did it take so long to load?

Because they jammed both fighters' vocals into ARAM alongside the music and SFX samples, and their loading code wasn't very good. That's why the game freezes every time the announcer says something. With the original 22 kHz samples, even BRR compressed, Dan Hibiki alone would be on the order of 300 KB.

For this game, if I were trying to do an audio hack with streaming (assuming my streaming engine pans out as hoped), I'd probably stream the vocals and store everything else in ARAM. Unique instrument sets for each track, with a smart loading engine to avoid freezing the game when switching tracks. I imagine the music would sound a lot better without the memory pressure from the vocals, even if nothing else changed, and the vocals would certainly sound a lot better (it would of course require a ROM expansion).

Reading old reviews, it seems the port wasn't well regarded for gameplay or animation quality either - everyone was damning it with faint praise, talking about how it was such a heroic effort on such a primitive system, how the SNES was really showing its age, etc. Perhaps a wholesale remake with a 64 Mbit ROM is in order...

...say - how does the S-DD1 hook up to the cartridge slot? Might it be possible to exceed the chip's addressable memory limit the same way as with the Super FX, by simply having ROM in parallel with it that the SNES knows about but the special chip doesn't?

Espozo wrote:
does this also affect the echo buffer trick thing?

No, I'm pretty sure it only gets applied to decoded BRR data. The echo buffer is known to always be uncompressed 32 kHz 16-bit stereo, so it would be a waste of circuitry to anti-alias it, besides which the muffling effect would compound during echo feedback...

Quote:
Honestly, it's still hard for me to tell the difference.

That could be the laptop speakers. I can hear the difference pretty clearly on headphones, but honestly it is fairly modest. The sample rate is high, and the material isn't especially ear-piercing, so it's not really a glaringly obvious difference.

How'd you like my examples? The actual SNES version was only 4 kHz or so, and was considerably quicker; it might have been a re-recording... EDIT: if there's a loud buzz when you play this sample, it's not Capcom's fault. Some (old?) media players seem to dislike it, and I have no idea why...


Attachments:
koryuken_SNES.7z [5.77 KiB]
Downloaded 36 times


Last edited by 93143 on Wed Aug 10, 2016 9:27 pm, edited 4 times in total.
Top
 Profile  
 
PostPosted: Wed Aug 10, 2016 8:13 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6277
Location: Seattle
93143 wrote:
...say - how does the S-DD1 hook up to the cartridge slot? Might it be possible to exceed the chip's addressable memory limit the same way as with the Super FX, by simply having ROM in parallel with it that the SNES knows about but the special chip doesn't?
Should always be able to do that (e.g. stuffing in 1MiB from $6000-$7FFF in banks $00-$3F and $80-$BF), but with only two games that used the S-DD1 we don't have much in the way of good documentation about it.

Here's what little I've found.
* http://problemkaputt.de/fullsnes.htm#sn ... ssionchips
* http://romlaboratory.dbwbp.com/romlab/sdd1.htm
It looks like siudym had a more useful pinout for it, but didn't bother drawing it publicly:
* http://romlaboratory.dbwbp.com/romlab/sdd1dev.htm

Byuu has a memory map somewhere in higan, but I only found the one for SFA2:
Code:
cartridge sha256:910a29f834199c63c22beddc749baba746da9922196a553255deade59f4fc127
  :board region=ntsc
  :  sdd1
  :    map address=00-3f,80-bf:4800-480f
  :    rom name=program.rom size=0x400000
  :      map address=00-3f,80-bf:8000-ffff
  :      map address=c0-ff:0000-ffff
  :
  :information
  :  serial:   SNS-AUZE-USA
  :  board:    SHVC-1N0N-01
  :  revision: 1.0
  :  name:     Street Fighter Alpha 2
  :  title:    Street Fighter Alpha 2


Top
 Profile  
 
PostPosted: Sun Aug 14, 2016 8:22 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6277
Location: Seattle
I just noticed that byuu had quite recently rechecked the S-DD1's memory map.

Byuu observed that there seems to be four bits for banking, so 16 MiB is addressable, most likely as four 4MiB ROMs.

So I've also re-re-labelled siudym's pinout with a combination of known things and suspected things:
Attachment:
sdd1.png
sdd1.png [ 6.54 KiB | Viewed 1084 times ]


So, in summary: for an S-DD1 game WITHOUT cart RAM, the entire 3.9 MiB in banks $40-$7D are available for a S-CPU dedicated ROM, plus all the random things one can map in the normally open bus regions of banks $00-$3F and $80-$BF. For a game WITH cart RAM, the practical range is "just" banks $40-$5F or -$6F.


Top
 Profile  
 
PostPosted: Sun Aug 14, 2016 9:57 pm 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3071
Location: Nacogdoches, Texas
lidnariq wrote:
for an S-DD1 game WITHOUT cart RAM, the entire 3.9 MiB in banks $40-$7D are available for a S-CPU dedicated ROM

Isn't that not any better than Mode 25? I don't know how much the now non open bus stuff will be. Isn't that just any part of the lower $8000 of those banks that isn't being used by hardware registers?

lidnariq wrote:
so 16 MiB is addressable

So, wait, this is extra, right? Even if the SNES can only have access to the data through DMA or HDMA (?) transfers, tile data and sound samples are the only things big enough you'd ever need this for and that's all you need to do to them 99.9% of the time. Now we're talking! :)

Yeah, so if I am correct, that's you have the SNES's original 8MB, plus the 16MB from the SDD1 for an SNES game that (if I'm not mistaken,) is the largest SNES game by about a factor of 4x (wasn't the largest, aside from Super Road Blaster of course, 6MB and used the SDD1?). There's also the decompression this chip can do to effectively give you even more space. I'm not sure how effective it is though, but I heard it can decompress graphics at the speed of DMA. Is there actually a way to turn off the decompression though, because I imagine all you would do is end up making a BRR sample bigger if you tried to compress it though.

Edit: Actually, it appears this is still kind of lame for streaming audio, if BRR compressed audio is 2MB per minute...


Top
 Profile  
 
PostPosted: Sun Aug 14, 2016 11:54 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6277
Location: Seattle
Espozo wrote:
Isn't that not any better than Mode 25? I don't know how much the now non open bus stuff will be. Isn't that just any part of the lower $8000 of those banks that isn't being used by hardware registers?

So, wait, this is extra, right? Even if the SNES can only have access to the data through DMA or HDMA (?) transfers, tile data and sound samples are the only things big enough you'd ever need this for and that's all you need to do to them 99.9% of the time. Now we're talking! :)
S-DD1:
Banks 0-$3F and $80-$BF: first 2 MiB of first ROM behind S-DD1 (unless you use the bizarre disable that Byuu discovered, which limits it to just the first 1 MiB)
Banks $C0-$FF: four 1 MiB swappable banks, any 1 MiB of 16 MiB available. Can be DMAed from to use the built-in streaming decompression of tile data.
Banks $40-$6F and $74-$7D: could be available for an extra ROM on the cart that could only be used by the S-CPU, not available to the S-DD1's bankswitching or decompression.
Banks $70-$73: mapped to RAM by the S-DD1 if RAM is available.

Quote:
Yeah, so if I am correct, that's you have the SNES's original 8MB
No, the Mode 25h layout overlaps the S-DD1 layout in a not-useful way. The simplest combination only makes 19.9 MiB available, of which 14 MiB has to go via a bankswitching mechanism.

This is more than the simple “psychotic granularity” map with its 14.8 MiB, but not tremendously so. And because so much of the "useful" space address is already used by the S-DD1, you can't usefully combine the “psychotic granularity” map with the S-DD1 to get enough more data (22.8 MiB).

In practice, there is no "authentic contemporary" way to do better. The MSU1 is about as good as you could ask for, when using modern tools.

Quote:
I'm not sure how effective it is though, but I heard it can decompress graphics at the speed of DMA.
It seems to be good enough to compress the data for Star Ocean by approximately 50%.

Quote:
it appears this is still kind of lame for streaming audio, if BRR compressed audio is 2MB per minute...
Do keep in mind that when 128 kbit/sec MP3 was the new hot thing, that was 1 MB per minute... streaming prerecorded soundtracks wasn't an option until you could have lots of storage.


Top
 Profile  
 
PostPosted: Mon Aug 15, 2016 9:09 am 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3071
Location: Nacogdoches, Texas
lidnariq wrote:
The MSU1 is about as good as you could ask

Yeah, I was mostly reluctant to use it because only two things support it, (although the accuracy of some emulators seems questionable that I'm not sure they'd run my game anyway) and I'm not a fan of how it completely bypasses the audio hardware, although I could just not use that feature and maybe advertise it as such... It would also keep the file size down, but with the MSU1, that doesn't seem to be an issue... :lol:

I did find out though, that a non "GIGA POWER" Neo Geo game is at most 330 mega bits, so divide that by 8 to get 41.25 MB, then half that, assuming it will compress as well as Star Ocean, and you get 20.625 MB out of 22.8 MB. Because I think it's pretty safe to say that we'll never be able to draw enough artwork to fill a Neo Geo game, (unless, of course, you're trying to port a Neo Geo game) this is more than enough for if you're not streaming audio.


Top
 Profile  
 
PostPosted: Mon Aug 15, 2016 5:34 pm 
Online

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 782
lidnariq wrote:
Byuu observed that there seems to be four bits for banking, so 16 MiB is addressable, most likely as four 4MiB ROMs.
Quote:
for an S-DD1 game WITHOUT cart RAM, the entire 3.9 MiB in banks $40-$7D are available for a S-CPU dedicated ROM, plus all the random things one can map in the normally open bus regions of banks $00-$3F and $80-$BF. For a game WITH cart RAM, the practical range is "just" banks $40-$5F or -$6F.

Sweet. That sounds like "no effective limit", at least in the context of Street Fighter Alpha 2: SFC vs. Capcom...

The arcade version seems to have 4 MB of audio data and 20 MB of graphics. It also has 3 MB of CPU code and 256 KB of APU code, but I can't imagine it actually needed that much...

Assuming the QSound samples are uncompressed 8-bit PCM, that's a little over 2 MB of BRR, which could easily fit in the CPU-only area regardless of the presence or absence of save RAM. I suspect the game code could fit in there too. That leaves 16 MB for graphics, and 20 MB of CPS2 graphics rescaled to SNES resolution should be well under 16 MB before S-DD1 compression... The CPU-only ROM doesn't look especially necessary in this case, unless one were to run into problems trying to make all resources available simultaneously...

I'd say about 9-10 MB should cover everything nicely, depending on how well the graphics compress. By the time this game came out, the Nintendo 64 was already on the market with an 8 MB standard cartridge size, so perhaps it could even have managed a halfway credible retail price...


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: 93143 and 4 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