Register | Login | |||||
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
| |
0 users currently in ROM Hacking. |
User | Post |
MathOnNapkins Posts: 240/1106 |
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. |
blackhole89 Posts: 65/427 |
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 Posts: 239/1106 |
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. |
Keitaro Posts: 175/373 |
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. |
blackhole89 Posts: 62/427 |
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 |
MathOnNapkins Posts: 231/1106 |
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:
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:
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. |
Keitaro Posts: 172/373 |
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. |