(Link to AcmlmWiki) Offline: thank ||bass
Register | Login
Views: 13,040,846
 Main | Memberlist | Active users | Calendar | Chat | Online users
Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album 		04-29-24 05:21 PM
0 users currently in ROM Hacking.
Acmlm's Board - I3 Archive - ROM Hacking - N-SPC and BRR sample frequency New poll | |
Add to favorites | Next newer thread | Next older thread
User Post
Keitaro

Mole


 





Since: 11-18-05
From: Massachusetts

Last post: 6438 days
Last view: 6438 days
Posted on 02-10-06 12:08 AM Link | Quote
Yeah...basicly, I know that instruments in N-SPC are set up of two parts, a pointer table with pointers to the actual BRR samples, and a table with the instrument data itself, consisting of 0x6 bytes per sample. I also am fully aware that the last two bytes controll the frequency, or tuning, of the sample.

Now my question is this--it is dire that I know how this works. How in the hell does this frequency format work? I've tried everything to decifer it, and no matter what, I have come up fruitless. Seriously, is it some sort of weird mathematical formula that I'm missing? Are the bytes to be read as is and the samples are really stored at that low of a frequency? Actualy, I did figure out one thing, that its really just the playback frequency of the sample. An example can be seen when in SMAS, instruments 18 and 19 are the same trumpet sample, but one is set to a lower playback frequency to allow for a lower note range.

What I want to know is how to get a legitimate frequency out of these two puzzling bytes. It's absolutly dire that I do so, as I have my reasons for needing that I'll be seriously appreciative of any help any of you can offer. I'm seriously out of ideas here.

(edited by Keitaro on 02-09-06 11:09 PM)
MathOnNapkins

1100

In SPC700 HELL


 





Since: 11-18-05

Last post: 6280 days
Last view: 6279 days
Posted on 02-10-06 06:34 AM Link | Quote
Since I've been trying to work on the N-SPC lately, I thought I'd give it a go. Here's some commented code from the Zelda 3 version of N-SPC:


...
; quite note: the value at $0220-$0221 + X is the word value you are referring two, but
; with the bytes reversed.
; I'm not quite sure what addresses $14-$17 do yet but they are important in this bit
; of code.
09B9: C4 14 MOV $14,A
09BB: CE POP X
09BC: F5 20 02 MOV A,$0220+X
09BF: EB 15 MOV Y,$15
09C1: CF MUL YA ; YA = ($15 * $0220+X)
09C2: DA 16 MOVW $16,YA
09C4: F5 20 02 MOV A,$0220+X
09C7: EB 14 MOV Y,$14
09C9: CF MUL YA ; YA = ($14 * $0220+X)
09CA: 6D PUSH Y ; Save Y for later.
09CB: F5 21 02 MOV A,$0221+X
09CE: EB 14 MOV Y,$14
09D0: CF MUL YA ; YA = ($14 * $0221+X)
09D1: 7A 16 ADDW YA,$16
09D3: DA 16 MOVW $16,YA ; $16 += YA
09D5: F5 21 02 MOV A,$0221+X
09D8: EB 15 MOV Y,$15
09DA: CF MUL YA ; YA = ($15 * $0221+X)
09DB: FD MOV Y,A ; Y = A
09DC: AE POP A ; A = the old Y above.
09DD: 7A 16 ADDW YA,$16
09DF: DA 16 MOVW $16,YA ; $16 += YA
09E1: 7D MOV A,X ; A = X
09E2: 9F XCN A
09E3: 5C LSR A
09E4: 08 02 OR A,#$02 ; 0,2,4,6, ... -> 0x02, 0x12, 0x22, 0x32, ...
09E6: FD MOV Y,A
; hint hint, we're going to write to Pitch Low and
; Pitch High on the DSP for whatever voice this happens to be.
09E7: E4 16 MOV A,$16

09E9: 3F EF 09 CALL $09EF

09EC: FC INC Y
09ED: E4 17 MOV A,$17

09EF: 2D PUSH A
09F0: E4 47 MOV A,$47
09F2: 24 1A AND A,$1A ; Probably a check to see if this voice is enabled.
09F4: AE POP A

09F5: D0 06 BNE $09FD ; If it's not enabled then we end the call.

WriteToDsp(A,Y):

; A = value to write
; Y = address of the DSP register to write to.

09F7: CC F2 00 MOV $00F2,Y
09FA: C5 F3 00 MOV $00F3,A
09FD: 6F RET


So.... that may or may not be helpful depending on what you have figured out yourself. But once you know what value is loaded into the Pitch Registers, the SpcToDo.txt file I have describes the following formula to find the new frequency: 




      With f as the frequency of the reproduced sound, f0 ( f sub zero ) 

      as the frequency of the original sound (sound at the time of 

      recording), and p as the value expressed by the upper level 

      fourteen bits of P(H) and P(L), the following formula is formed :



                                P

                      f = f0 * ----

                                 12

                                2


So it would appear that the data at $0220-1+X is fairly static, but I don't know what determines $14-7 but the formula is spelled out in the SPC code pretty clearly.
blackhole89
Moronic Thread Bodycount: 17
(since 2006-08-21 09:50 EST)
F5 F5 F5 F5 F5


 





Since: 12-31-69
From: Dresden/SN/DE

Last post: 6281 days
Last view: 6279 days
Skype
Posted on 02-10-06 10:05 AM Link | Quote
Well, why we are at it... do you have any idea how the N-SPC panning set command (E1 xx) works? I seem to get entirely random results when changing the hex parameter (0x0F: all left channel, 0x00: all right channel, 0x80,0x81: all right channel, 0xDF: all left channel, 0xEF: all right channel, 0xFF: all right channel etc.), so I am quite confused now.

Thanks in advance.
~blackhole89
Keitaro

Mole


 





Since: 11-18-05
From: Massachusetts

Last post: 6438 days
Last view: 6438 days
Posted on 02-10-06 04:05 PM Link | Quote
Thanks MathOnNapkins. I'll have to read that over a few times since I'm still a little shaky on assembly, but from what I got out of it so far, it seems to be exactly what I'm looking for. Thanks again

blackhole89: Hrm, I also have noticed that it gives pretty random results. Usualy, I'll listen to another song with a similar panning to what I'm looking for and just base it off what they use when I need to use that command I have noticed that 0x08 seems to be centered pan, though.
MathOnNapkins

1100

In SPC700 HELL


 





Since: 11-18-05

Last post: 6280 days
Last view: 6279 days
Posted on 02-11-06 08:59 AM Link | Quote
I've attached what I have documented so far of the engine. Due to my own bungling, and a bug* in Byuu's spc disassembler, the code in it is not fully accurate. Though, I have tried to revamp it as much as possible.

*3 byte branch destinations are always off by one byte. I have been correcting these manually as I go. e.g. 0C05: 6E 54 02 produces DBNZ $54,$0C09, but $0C09 should be $0C0A. This is probably the result of some generalized code he wrote to handle branches.

As for my own bungling, all branches were initially $0800 bytes lower than necessary. I remedied this somewhat with regular expressions and find/replace but some areas have not been fixed yet.

Blackhole: I'll look into your problem soon. I know what you mean by command, it's in the track data, I just haven't looked at that one yet.

edit: attachment didn't seem to work. trying to upload to webspace.

(edited by MathOnNapkins on 02-11-06 08:00 AM)
blackhole89
Moronic Thread Bodycount: 17
(since 2006-08-21 09:50 EST)
F5 F5 F5 F5 F5


 





Since: 12-31-69
From: Dresden/SN/DE

Last post: 6281 days
Last view: 6279 days
Skype
Posted on 02-11-06 08:59 AM Link | Quote
Ah.

Yeah, it seems to go clearly from right to left from 0x0 to 0xF... higher values appear to be setting DSP flags randomly, so I suppose there's something like an overflow at hand... *updates N-SPC documentary file*

Yeah, fitting Cave Story's panning range (0x2...0xC for some reason) to this did the trick.
http://twilightro.kafuka.org/~blackhole89/cs_lastbattle3.spc
There we go, this one uses panning, in case you are interested~
MathOnNapkins

1100

In SPC700 HELL


 





Since: 11-18-05

Last post: 6280 days
Last view: 6279 days
Posted on 02-11-06 01:10 PM Link | Quote
Um.... it appears to me that the byte argument for the "Pan" command go as follows on the bit level:

abuccccc

a = sign bit for volume left
b = sign bit for volume right
u = unused
ccccc = 5 bit value used to determine how much volume goes to either speaker.

From testing, it appears that 0A is actually the centered pan setting, and that 14 would probably be all the way to the right. I base this off the observation that volume right is #$1400 minus the calculated Left Volume.

The sign bits are also what is likely throwing off your examples in your earlier post, blackhole89 +. Docuementation says giving a negative amount reverses the phase. Though I don't know exactly what the hell that means, it sounds like it's a source of the problem.

(edited by MathOnNapkins on 02-11-06 12:19 PM)
Add to favorites | Next newer thread | Next older thread
Acmlm's Board - I3 Archive - ROM Hacking - N-SPC and BRR sample frequency |


ABII

Acmlmboard 1.92.999, 9/17/2006
©2000-2006 Acmlm, Emuz, Blades, Xkeeper

Page rendered in 0.015 seconds; used 388.73 kB (max 474.37 kB)