슈퍼 닌텐도 비디오 시스템 설계 이해

 (fabiensanglard.net)
1P by GN⁺ | ★ favorite | 댓글 1개
  • SNES 비디오는 1990년대 초 CRT TV와 NTSC 신호의 한계 안에서 256x224 화면, 60.098Hz 프레임레이트, 블랭킹 구간을 맞춘 설계였음
  • CRT는 픽셀 격자가 아니라 전자총과 RGB 신호, HSYNC/VSYNC로 주사선을 그리며, 프로그레시브와 인터레이스도 동기 신호 위치 차이에서 갈림
  • 별도 비디오 오실레이터를 둘 수 없었던 SNES는 21.47727MHz 마스터 클록을 나눠 5.3693175MHz 도트 클록을 만들고, 262라인·341도트 조합으로 NTSC 표준 59.94Hz와 다른 60.098Hz에 도달함
  • 기본 모드는 262라인 중 224라인 표시와 38라인 VBLANK, 341도트 중 256도트 표시와 85도트 HBLANK로 구성되어 PPU의 스프라이트 라인 버퍼 작업 시간을 확보함
  • PAL SNES는 50Hz·312.5라인 환경에 맞춰 다른 오실레이터와 240라인 오버스캔 모드를 제공했지만, 대부분의 게임은 224라인 기준이라 검은 띠와 17% 느린 실행이 흔했음

CRT TV가 설계를 제한한 지점

  • SNES가 영상을 출력하는 기본 대상은 표준 CRT TV였고, 당시 TV는 안테나로 NTSC 아날로그 방송을 받거나 AUX 입력으로 외부 영상을 받음
  • 일반 TV의 보조 입력은 노란색 컴포지트 비디오 단자와 흰색·빨간색 스테레오 오디오 단자로 구성됨
  • CRT는 초당 약 15,000개 선을 그릴 수 있는 15kHz급 선 그리기 장치로 볼 수 있음

CRT는 픽셀이 아니라 주사선과 신호로 동작함

  • CRT 내부에는 세 개의 전자총이 있고, 전자는 수직·수평 자석에 의해 위아래와 좌우로 꺾임
  • 전자 자체에는 색이 없으며, 마스크가 각 전자총의 전자를 올바른 색 형광체 스트립에 닿게 함
  • CRT에는 픽셀이 없고, 슬롯도 픽셀이 아님
    • 고해상도 TV는 슬롯이 더 작아 같은 색 신호를 수평 방향으로 더 충실하게 표현할 수 있음
  • CRT는 다섯 신호를 네 가닥 선으로 받음
    • Red, Green, Blue 신호는 각각 전자총에 직접 연결됨
    • 세 RGB 선에 신호가 없으면 전자가 발사되지 않아 검은색이 표시됨
    • 흰색 선은 Composite Sync(CSYNC) 로 HSYNC와 VSYNC를 함께 전달함
  • CRT는 VSYNC를 만들지 않고, 외부 시스템이 보내는 동기 신호를 받아 전자총 위치를 맞춤

프로그레시브와 인터레이스의 차이

  • CRT는 한 줄을 왼쪽에서 오른쪽으로 그리고, HSYNC를 받으면 화면 왼쪽 X=0으로 돌아감
  • VSYNC를 받으면 화면 위쪽 Y=0으로 복귀함
  • 전자총은 오른쪽으로 이동하는 동안 아래쪽으로 기울어진 경로를 따라가며, HSYNC 뒤의 다음 줄은 이전 줄 아래에 그려짐
  • VSYNC가 마지막 HSYNC와 같은 시점에 발생하면 같은 위치에 필드가 그려지는 프로그레시브 스캔이 됨
  • VSYNC가 두 HSYNC 사이에서 발생하면 다음 필드의 선들이 이전 필드 사이에 들어가는 인터레이스가 됨
    • 인터레이스는 수직 해상도를 두 배로 만들지만 각 줄의 갱신률은 절반으로 떨어짐
  • NTSC는 약 30Hz로 두 필드를 내보내므로 CRT는 인터레이싱을 위한 선 간격을 확보했고, 프로그레시브로 그릴 때는 검은 스캔라인 간격이 보임

NTSC 사양과 단순 설계안의 한계

  • SNES 설계는 NTSC TV가 처리할 수 있는 값에 가까워야 했음
    • 화면비: 4:3
    • 필드당 라인 수: 262.5
    • 한 줄의 도트 수: 341.25
    • 필드 주파수: 59.94Hz
  • 흑백 NTSC는 원래 60Hz였지만, 컬러 NTSC는 하위 호환성을 유지하며 색을 추가하는 과정에서 아티팩트를 피하기 위해 주파수를 0.1% 낮춤
  • 단순하게는 262라인 프로그레시브, 350도트, 59.94Hz를 골라 5,496,498Hz 도트 클록을 요구할 수 있음
  • 하지만 이 설계는 실제 SNES에 맞지 않았음
    • 비용 제약 때문에 비디오 시스템 전용 오실레이터를 둘 수 없고, 서브시스템은 마스터 오실레이터를 분주해 써야 함
    • CRT는 화면 복귀 중에도 전자총이 계속 발사될 수 있어 오버스캔과 블랭킹 처리가 필요함

블랭킹과 수직 해상도 선택

  • 전자총 위치가 수평 또는 수직으로 리셋될 때 계속 전자를 쏘면 보이는 아티팩트가 생김
  • TV는 화면보다 약간 큰 그림을 표시하는 오버스캔을 하며, 그 정도는 TV마다 다름
  • VSYNC와 HSYNC 뒤에는 전자총 위치가 잠시 흔들리므로 안정된 직선을 얻기까지 전자 발사를 멈추는 시간이 필요함
    • VSYNC 뒤 전자 발사 중지 구간은 VBLANK
    • HSYNC 뒤 전자 발사 중지 구간은 HBLANK
  • 당시 경쟁 시스템도 블랭킹을 사용함
    • Capcom CPS-1: 262라인, VBLANK 38라인, 표시 224라인, 59.6294fps
    • Sega Genesis: 262라인, VBLANK 38라인, 표시 224라인, 59.9227fps
    • Neo-Geo AES: 264라인, VBLANK 40라인, 표시 224라인, 59.18fps
  • SNES는 262라인을 224 표시 라인 + 38 블랭크 라인으로 나눔
    • 224는 16으로 나누어떨어져 16x16 타일 기반 그래픽 파이프라인과 잘 맞음

수평 해상도와 60.098Hz

  • SNES는 21.47727MHz 마스터 클록을 4로 나눠 5.3693175MHz 도트 클록을 사용함
  • 프레임레이트, 라인 수, 한 줄의 도트 수, 도트 클록은 서로 연결됨
  • 목표 프레임레이트 59.94Hz와 262라인을 넣으면 한 줄당 약 342도트가 나오지만, 컴포지트 출력의 캐리어 아티팩트 때문에 Nintendo 엔지니어는 341도트를 사용해야 했음
  • 이 조합에서 SNES의 프레임레이트는 5.3693175MHz / (341 * 262) = 60.098Hz가 됨
  • 60.098Hz는 NTSC의 59.94Hz와 다르지만 CRT의 허용 범위 안에서 동작함

256x224 기본 화면이 된 이유

  • 한 줄 341도트 전체를 표시 영역으로 쓸 수는 없고, 흔들림·아티팩트·TV 오버스캔을 숨기기 위한 HBLANK가 필요함
  • 224라인에서 4:3에 가까운 표시 폭은 224 * 4/3 = 298도트임
  • 타일맵 파이프라인은 16x16 타일을 쓰므로 가능한 값은 304, 288, 272, 256, 240 등임
    • 304도트는 화면 왜곡이 거의 없는 값에 가까움
  • PPU가 HBLANK 동안 스프라이트 라인 버퍼를 채워야 하는 제약도 있었음
    • 304도트 표시를 선택하면 HBLANK가 37도트, 약 7µs에 그침
    • 최대 128개 스프라이트 데이터를 가져오기에는 더 긴 시간이 필요했을 가능성이 있음
  • 최종 선택은 256 표시 도트 + 85 HBLANK 도트였음
    • PPU는 HBLANK 동안 약 16µs를 확보함
    • 표시 영역의 종횡비는 4:3이 아니라 8:7이어서 CRT 표시 시 약간의 왜곡이 생김

고해상도 모드의 타협

  • 기본 SNES 비디오 구성은 오버스캔 해상도 341x262, 표시 해상도 256x224, 프레임레이트 60.098Hz임
  • 게임의 99%는 이 구성을 사용했지만, SNES에는 수직 또는 수평 해상도를 두 배로 만드는 고해상도 모드도 있음
  • 수직 해상도 448라인은 VSYNC를 마지막 HSYNC 뒤 반 줄 지점에 내보내 인터레이스 프레임을 만들면 됨
    • 이 경우 한 줄은 60.098/2 = 30.049Hz로 갱신됨
    • 깜빡임이 생기고 보기 좋지 않지만 수직 해상도는 높아짐
  • 수평 해상도 두 배는 필요한 도트 클록이 없어서 더 어려움
    • SNES는 두 번째 필드를 수평으로 조금 이동시켜 점들이 이전 필드의 점 사이에 오도록 함
    • 결과적으로 절반 프레임레이트와 큰 색 번짐이 생김
  • fullsnes.txt는 여러 타이틀의 고해상도 사용 예를 정리함
    • Donkey Kong Country 1의 Nintendo 로고: 512x224, BgMode5
    • Seiken Densetsu 2 설정 화면: 512x224, BgMode5
    • RPM Racing: 인트로와 게임 내 512x448, BgMode5+Interlace
    • Ranma 1/2 사례는 실제로 256x224인데 인터레이스가 우연히 켜져 불필요한 깜빡임이 생김

PAL, SECAM, 유럽판 SNES의 문제

  • 유럽 TV는 NTSC가 아니라 PAL을 쓰고, 프랑스는 SECAM도 사용함
  • PAL 환경은 정확히 50Hz와 필드당 312.5라인을 기대함
  • PAL SNES는 NTSC의 21.4772700MHz 대신 17.7344750MHz 오실레이터를 탑재함
    • S-CLK 칩이 6/5 처리를 하고, 다시 /4 분주해 5.32034250MHz 도트 클록을 만듦
  • 224라인 그래픽만 쓰면 표시 영역 위아래에 큰 검은 띠가 생김
  • 이를 줄이기 위해 표시 라인을 240으로 늘리는 오버스캔 모드가 있었음
    • 추가 16라인은 타일 한 칸 높이에 해당함
    • 실제로는 대부분의 타이틀이 224라인에 맞춰 제작되어 이 모드를 거의 쓰지 않음
    • 총 12개 타이틀만 사용함
  • Super Mario World는 PAL에서 수직 시야 범위를 늘리는 방식으로 대응함
  • NTSC와 PAL 모두 4:3 화면비를 쓰므로 PAL 이미지는 NTSC보다 수직으로 조금 더 압축됨
  • 많은 게임 코드는 VSYNC가 60.098Hz가 아니라 50.00697891Hz에서 발생하는 점을 반영하지 않았고, 결과적으로 게임이 의도보다 17% 느리게 실행됨

출력 신호와 AV 커넥터

  • 앞서 본 RGB와 동기 신호는 CRT를 직접 구동하는 순수 신호지만, 실제 TV 대부분은 CRT에 직접 신호를 넣을 수 없었음
  • 많은 TV는 뒷면의 노란색 컴포지트 입력만 갖고 있었고, 일부 고급 모델은 S-Video 입력을 제공함
  • SNES는 CRT용 신호를 컴포지트와 S-Video로 모두 변환함
  • AV 커넥터는 신호를 버리지 않고 여러 출력 방식을 제공함
    • Red, Green, Blue
    • C-Sync
    • Luminance와 Chrominance 기반 S-Video
    • Composite Video
    • +5V DC
    • Ground
    • Left Audio, Right Audio
  • 유럽 TV, 특히 프랑스 TV는 SCART 커넥터를 갖춘 경우가 많았고, 이 방식은 CRT에 더 직접적으로 신호를 넣는 케이블 제작을 가능하게 함
  • 그 결과 유럽 사용자는 17% 느리고 검은 띠가 있는 게임을 높은 영상 충실도로 즐길 수 있었음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 224는 무작위로 고른 숫자가 아닐 가능성이 큼. 16으로 나누어떨어져서(224/16=14) 그래픽 렌더링 파이프라인의 타일맵과 잘 맞음
    어릴 때 게임 프로그래밍을 배우려고 이것저것 만지다가 한참 뒤에야 이해했는데, 그때 크게 납득됐음. CGA/EGA/VGA에는 320x200 모드가 흔했고, NES와 SNES는 256x224였으며 이는 사실상 TV 제약에 가까웠음
    반면 아케이드 Pac-Man은 288x224였기 때문에 PC의 Pac-Man 클론은 절대 “제대로” 보이지 않았고, Namco가 만든 NES판 Pac-Man조차도 맞지 않았음. 맵 타일이 작아져 캐릭터가 거대해지거나, Game Boy/Tengen판처럼 스크롤 월드가 되거나, 왜곡·비원본 맵 같은 타협이 들어가서 집에서 “아케이드” 게임을 하려 하면 이상하고 답답했음
    기계 구조와 스프라이트 동작 방식을 배우고 나니, 결국 다른 선택지가 없었다는 결론에 도달하면서 큰 깨달음이 왔음. PC의 그 해상도에서 픽셀이 정사각형이 아니라는 사실까지 들어가면 더 복잡해짐
    이후 Pac-Man 이식판이나 클론을 볼 때마다 월드 크기, 타일 크기, 스프라이트 크기를 곧장 따져보게 됨

    • NES는 실제로 256x240이고 NTSC 필드의 240줄을 모두 사용했지만, 많은 TV가 위아래 일부를 잘라냈기 때문에 대부분 TV에서 안전한 “사용 가능” 공간이 256x224였음
      다만 이 오버스캔은 TV마다 달랐고, 현대 TV나 에뮬레이터는 보통 240줄을 전부 보여줌
      SNES의 세로 해상도는 글에서처럼 224줄 또는 240줄로 설정 가능했음. 대부분 게임은 224줄을 썼는데, 세로 블랭킹 시간이 길어져 PPU로 그래픽을 전송할 시간이 더 생기기 때문임
    • 예전부터 여러 이식판이 아케이드판보다 늘어나 보인다고 느꼈는데, 왜 그런지 전혀 몰랐음. Atari 8-bit 컴퓨터용 구판이나 Ms. Pac-Man, Super Pac-Man 같은 여러 버전도 마찬가지였음

  • Rodrigo Copetti의 SNES 구조 글도 같이 볼 만함: https://www.copetti.org/writings/consoles/super-nintendo/

  • 59.94Hz가 이상한 숫자라는 건 맞지만, 아는 한 30Hz 전력망은 없음. NTSC가 설계된 북미와 몇몇 지역은 60Hz 전력망을 사용함
    https://en.wikipedia.org/wiki/Mains_electricity_by_country

    • 원래 흑백 TV에서는 초당 60필드, 즉 초당 30개의 인터레이스 프레임이었음
      흑백 TV에서 생성되는 가장 높은 주파수는 수평 주사율이었고, 이는 프레임률의 배수였음. 3.579545MHz 반송파를 쓰는 NTSC 컬러 신호가 추가되면서 TV 내부의 최고 주파수가 훨씬 높아졌고, 하드웨어를 단순하게 유지하려고 낮은 주파수들은 여전히 그 최고 주파수, 즉 컬러 반송파의 약수로 맞춰졌음. 그 결과 프레임률이 초당 59.94필드가 됨

  • PAL 지역에서 게임이 50.00697891Hz VSYNC에 맞춰 수정되지 않아 60.098Hz 기준보다 17% 느리게 돌았다는 부분이 너무 와닿음
    Super Nintendo만의 얘기는 아니지만, Mega Drive(Genesis)에서 Sonic the Hedgehog를 처음 보거나 플레이했을 때가 떠오름. Master System판보다 둔하고 느리게 느껴져서 별로 인상적이지 않았는데, YouTube가 뜬 뒤에야 NTSC와 PAL의 속도 차이가 엄청나다는 걸 알게 됨. 게임 속도뿐 아니라 음악도 PAL에서는 끔찍하게 들림
    16비트 시절에도 PAL과 “검은 박스” 필요성은 알고 있었지만, 차이가 그 정도인지는 몰랐음. 당시 콘솔 잡지들은 대부분 게임에서 차이가 작다고 했던 것 같고, 예외적으로 SNES판 DooM은 NTSC판 화면이 더 컸음
    NES판 Punch-Out을 어릴 때 잘해서 Mr. Dream 또는 Mike Tyson을 1라운드에 이길 수 있었는데, 지금 생각하면 PAL판을 하고 있었던 것임. 미국 대회에 나갔다면 1라운드에서 박살났을 테고, 누가 나를 함정에 빠뜨렸다고 확신했을 듯함

    • Super Metroid는 개발진이 PAL 콘솔에서도 올바른 속도로 플레이되도록 수정한 게임. 하지만 그런 조정도 특히 스피드런에서는 물리 상수와 애니메이션 타이밍의 미세한 차이 때문에 실제 플레이 차이를 만들어냄
      예를 들어 낮은 프레임률에서는 Samus와 발사체가 한 프레임에 더 많은 픽셀을 이동하므로 물체를 통과하기 쉬워져, 이 게이트 글리치는 PAL에서만 가능함: https://www.youtube.com/watch?v=RvyIwtO_qgM
      Samus의 물리 상수와 애니메이션 타이밍은 새 프레임률에 맞게 조정됐지만, 적·컷신·다른 환경 요소들은 조정되지 않았음. 그래서 PAL에서는 Samus는 NTSC와 같은 속도로 움직이지만 나머지 세계는 더 느리게 움직임. 이 때문에 Bombs를 집고 문이 잠기기 직전에 방을 빠져나와 미니보스를 건너뛸 수 있음: https://www.youtube.com/watch?v=R3t8TIIj7IM
      NTSC판에서 같은 스킵은 복잡한 준비와 수십 번 연속 프레임 단위 입력이 필요하고, 지금까지 단 한 명만 성공했음: https://www.youtube.com/watch?v=jcKUMk5g8Wk
      NTSC(왼쪽)와 PAL(오른쪽)의 최단 도구 보조 스피드런 비교도 있음: https://www.youtube.com/watch?v=KD_-thqcB5s 두 런은 거의 끝까지 같은 경로를 쓰고 NTSC판이 거의 모든 방에서 더 빠르지만, 임의 코드 실행 준비가 완전히 달라서 PAL이 최종적으로 먼저 끝남. NTSC 런은 문을 작동시키지 않고 통과해 경계 밖으로 나가 메모리 손상을 일으키기 위해 매우 느린 일시정지/해제 시퀀스를 해야 함. 반면 PAL판은 게임 애니메이션 시스템의 경쟁 상태를 이용해 완전히 화면 안에서 임의 코드 실행을 달성할 수 있음. 스파이크의 넉백 타이머와 Samus의 착지 애니메이션 사이의 경쟁인데, Samus의 타이밍만 PAL용으로 수정되고 스파이크는 그렇지 않아서 PAL에서는 이 문맥에서만 악용 가능한 타이밍이 나옴
    • 호주에서는 ‘Hyper’ 같은 잡지 덕분에 타이밍 차이를 알고 있었지만, 할 수 있는 일은 없었음. 차라리 모르고 행복하게 살 수도 있었을 텐데
      Dreamcast가 나오면서 처음으로 TV가 지원하기만 하면 50Hz와 60Hz를 전환할 수 있는 게임들이 생겼음. 또 이 차이를 제대로 반영하지 않은 게임에서는 50Hz로 되돌려 더 쉽게 만들 수도 있었고, Crazy Taxi는 50Hz에서 훨씬 쉬웠던 걸로 기억함
    • 에뮬레이터에서 SNES 게임을 할 때마다 타이밍이 어긋나는 이유가 이걸로 설명될지도 모르겠음. 어릴 때 PAL판으로 자랐고, 지금까지는 현대 TV의 지연 때문이라고만 생각했음
    • 미국에서 자랐는데, 나중에 PAL과 미국판 사이의 속도 차이를 처음 들었을 때 충격받았음
      그렇게 다른 게임이 그대로 팔렸다는 게 이상하게 느껴지지만, 왜 그런 선택이 나왔는지는 완전히 이해됨. 어릴 때는 Mario는 어디서나 Mario이고 Sonic도 어디서나 Sonic이라고 당연히 생각했음
      이런 차이가 끝난 건 3D 콘솔 시기였는지 궁금함. 그때부터는 렌더링과 게임 로직이 대부분 더 이상 완전히 묶여 있지 않았으니까

  • 원문에 오타가 있는 듯함. 화면비를 8:6이라고 했는데, 그건 4:3과 같고 계산상으로는 8:7이 맞음

    • 맞음. 내부 화면비는 8:7이고 Snes9x 같은 에뮬레이터도 기본값이 이쪽임. CRT에서는 동작 방식상 완전한 정사각형 픽셀을 직사각형으로 뭉개기 때문에 결과적으로 4:3에 가깝게 표시되는 것으로 이해하고 있음

  • 256x224, 즉 8:7 출력 해상도가 약 4:3, 정확히는 64:49 이미지로 늘어나는 부분이 빠진 것 같음
    SNES의 도트 속도는 약 5.37MHz로, ATSC 표준이 정의한 정사각형 픽셀 속도 약 6.13MHz보다 느림. 정확히 8/7만큼 느리기 때문에 픽셀이 가로로 8/7 늘어나고, 8:7 해상도는 (8/7)(8/7)=64/49로 늘어나 64:48=4:3에 가까워짐
    “4:3에 가까운 화면비가 되려면 224    (4/3)=298개의 보이는 도트가 필요하다”는 계산은, 위 요소를 고려하면 계수가 (4/3)/(8/7)=7/6이 됨. 그러면 224*(7/6)=261.33...개의 보이는 도트가 필요하고, 실제 선택된 256에 훨씬 가까워짐

  • 나는 RF 출력에 스위치 박스를 물려서 SNES와 TV 안테나를 번갈아 선택해 썼음

    • 그보다 더 화질을 나쁘게 하고 노이즈를 추가하는 방법은 RF 스위치 박스와 TV 사이에 2선식 UHF 나사 단자 어댑터를 끼우는 것뿐이었음. 물론 어릴 때 가진 1970년대식 Pong 짝퉁 콘솔에 딱 그렇게 썼음. 진짜 Atari는 살 형편이 안 됐음
      나중에 비디오 엔지니어가 된 뒤에는 웃을 수 있었지만, 당시의 어린 나는 그 화질이 얼마나 끔찍한지 몰랐던 게 다행임

  • 8:7 아트워크 화면비는 ROCKMANX3 / Mega Man X3 같은 SFC/SNES의 다른 플랫폼 이식판에서도 보임
    PSX/Saturn/PC판은 원본 아트를 늘리지 않고 유지한 대신, 8:7을 4:3으로 맞추기 위해 스테이지에 맞춘 세로 여백을 추가함. 원래 버전에 익숙해서 플레이할 때 꽤 거슬리고, Saturn판 스크린샷을 보면 모든 것이 살짝 너무 마르게 보이는 걸 확인할 수 있음: https://segaretro.org/Mega_Man_X3

  • Fabien이 이런 글을 쓰는 데 얼마나 걸리는지 궁금함. 세부사항이 정말 많고 정리가 깔끔함

    • 대략 일요일 하루, 오전 9시부터 밤 9시까지 걸렸음

  • SNES 해상도 중 얼마나 많은 부분이 콘솔 하드웨어에 고정되어 있고, 얼마나 카트리지가 구동할 수 있는 영역인지 궁금함
    예를 들어 자체 보조 프로세서가 있어서 스프라이트를 불러올 필요가 없고, 온보드 클럭도 있는 카트리지라면 이론적으로 한 줄에 가로 256픽셀보다 더 많이 출력할 수 있었을까?

    • 전부 PPU에 고정되어 있는 것으로 봄
      보조 프로세서가 있으면 자체적으로 프레임을 렌더링해 다음 줄의 타일이 읽힐 메모리 위치에 넣을 수는 있음. SuperFX가 대략 그렇게 했던 것 같음
      하지만 결국 실제로 픽셀을 그리고 색상 수 등을 처리하는 것은 PPU라서, 최종적으로는 PPU의 제약에 묶임
답변달기