what games had samples at 32khz?

[Señor Ventura]

Hello again...

Lately I've been searching for games that could have samples (sound effects, music) at 32Khz, but for now all i achieved are examples with 11025hz, or 16000hz (if i'm not remembering bad).

There is some information about this?, or i have to continue searching one by one (forever xD).


The thing is... how much memory can have a sample at this kind os rate? (32Khz and 16 bits).


Thank you. Greetings


edit:
Another question... can the SPC700 read/write in the work RAM?.

[tepples]

BRR takes 4.5 bits per sample. For example, a 1-second 32 kHz sample takes 18000 bytes.

[Señor Ventura]

BRR takes 4.5 bits per sample. For example, a 1-second 32 kHz sample takes 18000 bytes.

That is the size at the lowest compressing rate?.

Are in somewhere info about the rates and sizes about the samples?.


Thank you

[koitsu]

edit:
Another question... can the SPC700 read/write in the work RAM?.

No. The SPC700 has its own physically dedicated 64KBytes of RAM ($0000-00FF is for direct page, $0100-01FF is for stack, $0200-7FFF are available for common use, and $FFC0-FFFF is IPL ROM so don't touch that; I don't know about $8000-FFBF. See Section 8.2 (Memory Space) in official docs). The main 65816 CPU can't access this RAM directly either -- the way you "get data" between the two is through the APU I/O registers at $2140 to $2143. There's a communication protocol involved as well (it's documented; see Appendix D (Data Transfer Procedure) in official docs).

[tepples]

BRR takes 4.5 bits per sample. For example, a 1-second 32 kHz sample takes 18000 bytes.

That is the size at the lowest compressing rate?.

There is only one compression rate for BRR (4.5 bits per sample), unless you store another format in the ROM and then decompress it to BRR on either the S-CPU or the S-SMP. I have had some ideas about how to go about that, but I haven't had a chance to put them into practice.

[Revenant]

$FFC0-FFFF is IPL ROM so don't touch that; I don't know about $8000-FFBF

8000-FFBF is also normal RAM, and FFC0-FFFF can be switched between ROM and RAM at will. The amount of that space that's actually usable by a driver depends on the current size of the DSP echo buffer.

[Bregalad]

No. The SPC700 has its own physically dedicated 64KBytes of RAM ($0000-00FF is for direct page, $0100-01FF is for stack, $0200-7FFF are available for common use, and $FFC0-FFFF is IPL ROM so don't touch that; I don't know about $8000-FFBF. See Section 8.2 (Memory Space) in official docs). The main 65816 CPU can't access this RAM directly either -- the way you "get data" between the two is through the APU I/O registers at $2140 to $2143. There's a communication protocol involved as well (it's documented; see Appendix D (Data Transfer Procedure) in official docs).

The official docs are hillariously wrong when it comes to the SPC, they state it has 32kb RAM when in fact it has 64kb. Also, we're not supposed to have access to them, so using them as reference is a terrible idea.

@ Señor Ventura : I do not understand what you're asking. Plenty of games have samples at 32khz just like plenty of them have samples at lower rate in order to save RAM and make room for more samples simultaneously. I even think some games have samples at higher than 32khz, such as Chrono Trigger. Just use a graphical tool such as SPCtool (now require Dosbox since Windows 7) in order to see the replay rate in real time.

[koitsu]

The official docs are hillariously wrong when it comes to the SPC, they state it has 32kb RAM when in fact it has 64kb. Also, we're not supposed to have access to them, so using them as reference is a terrible idea.

Official documentation states it has 64KB RAM ("Memory Space"), and that the SPC700 can address all 64KBytes ("It is possible to access and address space of 64Kbytes ..."). What *is* ambiguous in the docs is the SPC700 memory layout which doesn't clearly state what $8000-FFBF is, hence my comment, hence Revenant's useful answer. Attached is proof that backs up these statements, because nobody around here can just take someone's word; you're welcome. The latter half of your paragraph begs the question.

[Revenant]

I guess they expected/recommended people to leave the latter 32kb free to avoid other code/data getting clobbered by the echo buffer. I think the buffer is usually a lot smaller in practice, though, so you can avoid that with a bit of caution.

[tepples]

How small are echo buffers in practice? I know they're 128 bytes per millisecond (32 samples/channel/ms * 2 channels * 2 bytes per sample), but how many ms?

[ikari_01]

the DSP echo buffer (which always ends at FFFF).

AFAIK you can set the start of the echo buffer to any multiple of 256 bytes and the length to 4 bytes or any multiple of 2048 bytes up to 32768, so it doesn't necessarily end at FFFF.

[Revenant]

You're right. For some reason I misremembered only being able to set the start position (with the length being based on that, rather than being controlled separately).