13장 소리 ① 슈퍼 패미컴 사운드 구조

소리는 따로 도는 작은 컴퓨터가 냅니다 쉽게

지금까지 본 65c816(S-CPU)은 게임 코드를 돌리고 화면을 그리게 하지만, 소리를 직접 내지는 못합니다. 슈퍼 패미컴 안에는 소리만 맡는 작은 컴퓨터가 따로 있습니다. 이 묶음을 흔히 APU(오디오 처리 장치)라고 부르고, 안에는 셋이 들어 있습니다.

• SPC700: 소리 쪽 CPU입니다. 칩 이름은 S-SMP이고, 1.024MHz로 돕니다. 6502를 닮은 8비트 CPU이지만 명령의 바이트 값은 65c816과 다릅니다.
• ARAM(오디오 RAM) 64KB: SPC700의 메모리 전부입니다. 소리 프로그램, 곡 데이터, 악기 소리(샘플)가 모두 여기 들어가야 합니다. S-CPU는 이 메모리를 직접 읽거나 쓸 수 없습니다.
• S-DSP: 실제로 소리를 만드는 음원 칩입니다. ARAM에 있는 샘플을 정한 높이로 읽어, 음성 여덟 개를 섞고 메아리(에코)를 더해 1초에 32,000번 스테레오 값을 내보냅니다.

그래서 게임은 소리를 이렇게 냅니다. 먼저 SPC700에서 돌 사운드 드라이버(음악을 연주하는 프로그램)와 곡 데이터, 샘플을 롬에서 꺼내 ARAM으로 보냅니다. 그다음부터는 "3번 곡", "11번 효과음"처럼 번호만 보냅니다. 악보를 읽고 S-DSP의 레지스터를 매 순간 바꾸는 일은 드라이버가 혼자 합니다. 오케스트라에 비유하면 S-CPU는 무대 밖에서 쪽지로 곡 번호를 넣어 주는 사람이고, 지휘는 SPC700이 합니다.

롬 해킹에서 소리를 건드릴 일은 생각보다 많습니다. 원하는 곡이 나오게 하거나 효과음을 끄려면 S-CPU가 곡 번호를 보내는 곳을 찾아야 하고(14장), 화면을 고치다 소리 쪽과 주고받는 순서를 깨뜨리면 게임이 멈춥니다. 그 주고받는 길이 다음 절의 포트입니다.

포트 네 개로 주고받기 쉽게

S-CPU와 SPC700 사이에는 1바이트짜리 칸이 네 개 있습니다. S-CPU에게는 $2140–$2143이고, SPC700에게는 $F4–$F7입니다. 칸마다 방향이 둘이라서, 실제로는 쪽지함이 여덟 개라고 보면 됩니다.

• S-CPU가 $2140에 쓰면, SPC700이 $F4를 읽을 때 그 값이 보입니다.
• SPC700이 $F4에 쓰면, S-CPU가 $2140을 읽을 때 그 값이 보입니다.
• 내가 쓴 값을 내가 다시 읽을 수는 없습니다. $2140을 읽으면 언제나 상대가 쓴 값이 나옵니다.

fullsnes는 두 CPU가 주고받는 길이 이 네 칸뿐이고 인터럽트 같은 다른 방법은 없다고 적습니다. 그래서 상대가 값을 읽었는지 알려면 "받았으면 같은 값을 되돌려 줘"라고 약속하고, 그 값이 돌아올 때까지 포트를 계속 읽으며 기다립니다. 이렇게 값을 주고받으며 맞추는 것을 핸드셰이크라고 합니다. 소리 쪽은 S-CPU와 따로 돌기 때문에, 이 기다림이 없으면 상대가 읽기 전에 다음 값으로 덮어써 버립니다.

어떤 포트에 무엇을 쓰고 무엇을 기다리는지는 게임마다 다릅니다. 정해진 것은 전원을 켠 직후, 드라이버를 올리기 전의 약속 하나뿐입니다.

사운드 드라이버 올리기 쉽게

전원을 켜면 SPC700은 칩 안에 들어 있는 64바이트짜리 프로그램, IPL 롬을 실행합니다. IPL은 ARAM의 앞쪽을 지우고 $F4–$F5에 AA BB를 써서 "준비됐다"고 알린 뒤, S-CPU가 시작 신호 CC를 보내기를 기다립니다. 그다음 순서는 이렇습니다.

1. S-CPU는 받을 주소를 $2142(아래 바이트)와 $2143(위 바이트)에 씁니다.
2. $2141에 0이 아닌 값을 쓰고 $2140에 CC를 씁니다. IPL이 CC를 되돌려 주면 시작입니다.
3. 한 바이트마다 데이터를 $2141에, 그 바이트의 번호(0부터, 아래 8비트만)를 $2140에 씁니다. IPL은 번호가 바뀐 것을 보고 데이터를 저장한 뒤 같은 번호를 되돌려 줍니다.
4. 블록이 끝나면 다음 받을 주소를 쓰고, $2140에 마지막 번호보다 2 이상 큰 값(0이면 안 됩니다)을 씁니다. $2141이 0이 아니면 다음 블록을 받고, 0이면 그 주소로 건너뛰어 실행합니다.

이렇게 올라간 프로그램이 사운드 드라이버입니다. 드라이버가 돌기 시작하면 포트의 뜻은 드라이버가 정합니다. 아래는 각성편이 실제로 이 순서를 밟은 기록입니다. 화면의 표시 번호, 바이트 값, 기다리는 값이 모두 기록 그대로입니다.

기록의 PC는 포트에 쓴 명령의 다음 명령 주소입니다. 예를 들어 pc=8380F5는 $83:80F2의 STA $2140 다음입니다. 이 값으로 롬에서 올리기 함수를 찾아 5장처럼 역어셈블하면, 포트를 읽고 비교하며 기다리는 반복이 보입니다.

곡 번호와 효과음 번호 보내기 쉽게

드라이버가 돌기 시작하면 S-CPU는 짧은 명령만 보냅니다. 위 기록의 뒤쪽이 그 모습입니다. 각성편에서는 이렇게 나뉩니다.

• 곡 바꾸기: 곡 재생 함수 $83:8200이 곡 번호로 곡 표를 찾아, 드라이버를 IPL로 돌려보내고 그 곡의 데이터와 샘플을 새로 올린 뒤 명령 FD를 보냅니다. 곡 하나를 바꾸는 데 149프레임부터 187프레임까지 38프레임, 0.6초쯤 걸렸습니다.
• 효과음: 효과음 함수 $83:8023이 $2141에 효과음 번호 하나를 씁니다. 곡 명령을 보내는 $2140과 다른 포트입니다.
• 바쁜지 확인: 두 함수 모두 쓰기 전에 $2143이 0이 될 때까지 기다립니다. 드라이버가 이 포트로 "지금은 받을 수 없다"를 알리는 것으로 보입니다.

다른 게임은 포트를 다르게 나눠 씁니다. 그래도 찾는 방법은 같습니다. $2140–$2143에 쓰는 순간을 기록해(12장), 곡이 바뀌는 장면에서 어떤 값이 어느 포트로 갔는지 보고, 그 값을 쓴 PC에서 거꾸로 올라가 곡 번호를 넘겨받는 함수를 찾습니다. 그 함수를 찾으면 곡 번호를 바꾸거나, 효과음 함수 첫 바이트를 RTL로 바꿔 효과음을 막을 수 있습니다(6장). 14장에서 실제로 그렇게 합니다.

S-DSP: 음성 여덟 개 쉽게

S-DSP는 동시에 소리 여덟 개(음성)를 냅니다. 음성마다 "어느 샘플을, 어떤 높이로, 얼마나 크게, 왼쪽·오른쪽에 얼마씩"을 정하는 레지스터가 있고, 드라이버가 악보를 따라 이 값을 바꿉니다. 음성 하나가 피아노 건반 하나를 누르는 손가락이라고 보면, 화음과 드럼과 효과음을 합쳐 손가락 여덟 개로 연주하는 셈입니다. 그래서 효과음이 나는 동안 곡의 음성 하나가 잠깐 끊기는 게임도 있습니다.

• 샘플: ARAM에 있는 악기 소리 한 토막입니다. 압축된 BRR 형식입니다.
• 피치: 샘플을 읽는 빠르기입니다. 14비트 값이고 $1000이면 1초에 32,000샘플, 곧 녹음한 그대로의 높이입니다. $2000이면 두 배 빠르게 읽어 한 옥타브 높아집니다.
• 엔벨로프: 소리가 시작해서 사라질 때까지의 크기 변화입니다. 건반을 누르면 커졌다가(어택) 조금 줄고(디케이) 유지되다가(서스테인) 떼면 사라집니다(릴리스). 이 네 단계를 정하는 방식을 ADSR이라고 합니다.
• 에코: 소리를 ARAM의 에코 버퍼에 써 두었다가 조금 늦게 다시 섞어 울림을 만듭니다. 음성마다 에코에 보낼지 정합니다.

S-DSP의 레지스터는 128개이고, SPC700은 $F2에 레지스터 번호를, $F3에 값을 써서 바꿉니다. S-CPU는 이 레지스터에 손댈 수 없습니다. 소리를 바꾸려면 언제나 드라이버를 거쳐야 하는 이유입니다.

64KB 안에 모두 들어가야 합니다 쉽게

ARAM 64KB에는 드라이버, 곡 데이터, 그 곡이 쓰는 모든 악기 샘플, 에코 버퍼가 함께 들어가야 합니다. 1초짜리 소리를 16비트 그대로 두면 32kHz에서 64,000바이트라, 악기 하나로 ARAM이 거의 찹니다. 그래서 샘플은 BRR이라는 방식으로 줄여 넣습니다. 16샘플(16비트로 두면 32바이트)을 9바이트에 담아, 크기가 3.5분의 1쯤으로 줄어듭니다.

에코도 자리를 먹습니다. 에코는 지나간 소리를 ARAM에 적어 두었다가 다시 읽는 것이라, 울림이 길수록 버퍼가 커집니다. 가장 길게 잡으면 30KB, 64KB의 절반 가까이입니다. 곡마다 샘플을 바꿔 올리는 게임이 많은 이유가 이 좁은 공간입니다. 각성편도 곡을 바꿀 때마다 그 곡의 샘플만 $A000부터 새로 올렸습니다.

SPC 파일 쉽게

게임 음악을 모아 듣는 사람들은 SPC 파일을 씁니다. 곡이 연주되는 한순간에 소리 쪽 전체를 그대로 떠 둔 파일입니다. ARAM 64KB, S-DSP 레지스터 128바이트, SPC700 레지스터, 그리고 곡 이름 같은 꼬리표가 들어 있습니다. 플레이어는 SPC700과 S-DSP만 흉내 내어 그 순간부터 드라이버를 계속 돌리므로, 게임 없이 곡이 끝없이 연주됩니다. 소리 쪽이 S-CPU와 포트로만 이어진 덕분에 이렇게 떼어 낼 수 있습니다.

이 블로그의 배경음악은 SPC 파일로 만들지 않았습니다. 처음에는 Mesen 2의 Lua로 소리 쪽 상태를 떠서 SPC 파일을 만들려 했지만, emu.getState()가 내주는 S-DSP 상태에는 음성마다의 엔벨로프·샘플 주소·피치와 에코 길이 같은 값만 있고 DSP 레지스터 128바이트를 그대로 담은 항목이 없었습니다. 그래서 에뮬레이터가 내는 소리를 그대로 녹음하는 길로 바꿨습니다(14장).

실제 패치에서 실제 패치에서

각성편: 곡 표와 곡 재생 함수

각성편의 곡 재생 함수 $83:8200은 A에 든 곡 번호를 8배 해 곡 표 $83:83DE에서 항목을 찾습니다. 곡은 20개이고 항목 하나는 8바이트입니다. 곡 번호를 받는 $83:8203의 명령은 29 FF 00(AND #$00FF)으로, 곡 번호의 위 바이트를 지웁니다.

위 도구의 기록에서 150–186프레임에 올라간 곡은 데이터 2,194바이트와 샘플 14 15 16 18 19 1A로, 곡 표 3번 항목과 크기·샘플 번호가 모두 맞습니다. 효과음 함수 $83:8023은 첫 명령이 STA $B3(85 B3)이고, 이 기록에서 $2141에 0B, 0A, 80을 보냈습니다. 14장은 이 두 함수의 첫 바이트를 고쳐 원하는 곡만 나오는 롬을 만듭니다.

제절초: 대본의 소리 코드에서 부르는 함수

제절초는 대본 속 제어 코드로 음악과 효과음을 냅니다. 소리 코드 {39}를 처리하는 게임 코드가 A에 소리 번호를 넣고 $00:CD60을 부릅니다. 9바이트마다 놓인 $00:CD69, $00:CD72, $00:CD7B, $00:CD84도 같은 모양(PHP, REP #$30, PHA, LDA #값, BRA)의 입구로, 각자 다른 16비트 값을 A에 넣고 뒤쪽 코드로 건너뜁니다. 멈추는 코드 {3B}·{3C}는 $00:CD45·$00:CD4E를 부릅니다.

$00:CD60과 $00:CD45가 실행될 때마다 A와 돌아갈 주소를 적으며 타이틀까지 돌린 기록은 네 줄이었습니다. 툴킷 이전 스크립트로 남긴 것이라, X·Y와 뱅크까지 적는 calls.lua와는 형식이 조금 다릅니다.

352 00CD60 A=0001 ret=D58C
425 00CD60 A=0092 ret=D4B3
583 00CD45 A=0092 ret=D4F5
583 00CD60 A=0092 ret=D4FB

352프레임의 첫 줄이 타이틀 음악입니다. 돌아갈 주소 D58C는 JSR이 스택에 넣은 값(명령의 마지막 바이트 주소)이라, 부른 곳은 $00:D58A의 JSR $CD60이고 그 바로 앞 $00:D587이 LDA #$0001입니다. 곡 번호 1이 롬의 $00:D588(파일 0x5588)에 그대로 적혀 있다는 뜻입니다. 583프레임에서는 같은 번호 $92를 멈췄다가 다시 냅니다.

한글판은 이 소리 코드들을 후킹해 지금 반복 중인 음악·환경음을 기억합니다. 장으로 바로 옮기는 기능을 처음에는 게임을 다시 시작하는 방식으로 만들었는데, 사운드 드라이버가 이미 돌고 있으면 다시 올리는 단계에서 멈췄습니다. 포트를 IPL이 아니라 드라이버가 맡고 있으니, 켤 때처럼 AA BB를 기다리는 올리기 코드가 답을 받지 못했을 것으로 봅니다. 그래서 게임 자신의 대본 점프로 옮기고, 음악은 기억해 둔 상태로 다시 켜도록 바꿨습니다.

슈퍼 마리오 RPG: 음성 여덟 개가 쉬는 시간

슈퍼 마리오 RPG의 오프닝 데모를 녹음하다, 두 번 녹음한 소리가 조금씩 달랐습니다. 효과음이 섞였는지 보려고 voices.lua와 같은 방식으로 6프레임마다 음성 여덟 개의 엔벨로프를 15,096프레임 동안 적었습니다.

1800 1190 1190 1190 1190 1190 1602 1749 1190
1806 1185 1185 1185 1185 1185 0 1742 1185
1812 1175 1175 1175 1175 1175 1270 1728 1175

한 줄은 프레임과 음성 0–7의 엔벨로프(0–2,047)입니다. 기록 전체에서 엔벨로프가 0이 아닌 칸은 음성 0–4가 60–65%, 5와 6이 53–56%, 7이 33%였습니다. 다른 음성보다 훨씬 적게 울리는 음성 7, 짧게 켜졌다 꺼지는 5·6은 효과음일 수 있다는 단서입니다. 다만 곡 자체가 그 음성을 드물게 쓸 수도 있어, 이것만으로 효과음이라고 단정하지는 않았습니다. 포트 기록에서 효과음 명령이 몇 번 갔는지와 함께 보는 것이 순서입니다.

직접 해 보기 직접 해 보기

kr-patch-toolkit 0.2.0에는 이 장의 기록을 남기는 Mesen 2 Lua 스크립트 세 개가 들어 있습니다. 모두 버튼 입력은 boot.lua로 처리하므로, 게임을 켜고 정한 프레임(MAXF, 기본 1500)까지 돌린 뒤 SHOT_DIR에 결과를 씁니다.

$ L=$(krpatch snes lua)
$ mkdir -p out/apu
$ LIBDIR=$L SHOT_DIR=$PWD/out/apu MAXF=600 EVERY=0 \
    Mesen --testrunner $PWD/game.sfc $L/probe/apuports.lua
$ head -4 out/apu/apuports.txt

EVERY=0은 스크린샷을 끕니다. 올리기가 수만 줄을 남기므로, 명령만 보고 싶으면 APUPORTS="1,3"처럼 포트를 고르거나 APUF로 기록을 시작할 프레임을 늦춥니다. 곡이 바뀌는 장면의 프레임은 EVERY=60으로 1초마다 찍은 화면에서 찾습니다. 줄 형식은 프레임 주소 값 PB:PC이고, PC는 위 도구에서 본 것처럼 쓴 명령의 다음 주소입니다. 그 주소로 롬을 역어셈블합니다.

$ krpatch snes dis game.sfc 838000 20

곡 번호를 넘겨받는 함수의 주소를 찾았다면 calls.lua로 불릴 때마다 A를 적어 봅니다. 여러 주소는 쉼표로 잇습니다.

$ LIBDIR=$L SHOT_DIR=$PWD/out/calls MAXF=3000 EVERY=0 CALLS=838200,838023 \
    Mesen --testrunner $PWD/game.sfc $L/probe/calls.lua
$ LIBDIR=$L SHOT_DIR=$PWD/out/voices MAXF=3000 EVERY=0 VSTEP=6 \
    Mesen --testrunner $PWD/game.sfc $L/probe/voices.lua

calls.txt의 ret=은 스택에 있는 돌아갈 주소입니다. JSL로 들어왔을 때만 뱅크 바이트가 의미가 있습니다(6장). voices.lua는 Mesen 2가 상태에 담는 이름(spc.dsp.voices[0].envVolume)을 읽으므로, 이름이 다른 판에서는 그 사실을 알리며 멈춥니다. 스크립트마다 받는 환경 변수는 파일 첫 줄들에 적혀 있고, 전체 목록은 툴킷 README의 snes lua 절에 있습니다.

이 장의 기록은 Mesen 2.1.1에서 툴킷 스크립트와 같은 방식의 이전 스크립트로 남긴 것입니다. 롬 주소는 각성편·제절초 일본판 기준이고, 주소를 CPU 주소로 바꾸는 법은 4장에 있습니다.