1P by GN⁺ 2일전 | ★ favorite | 댓글 1개
  • 게임보이 카트리지를 직접 제작하기 위해 수년간의 연구와 설계 과정을 거침
  • 이 글은 커스텀 게임보이 카트리지를 만드는 데 필요한 주요 기술적 정보를 초심자 관점에서 체계적으로 정리함
  • 게임보이는 간단하면서도 확장성이 뛰어난 하드웨어 구조 덕분에 레트로 게임 개발 및 하드웨어 해킹 커뮤니티에 매력적인 플랫폼임
  • 카트리지는 게임 데이터와 추가 하드웨어(예: RTC, 센서 등)를 내장할 수 있어 게임보이에 새로운 기능을 부여함
  • 메모리 뱅크 컨트롤러(MBC) 회로를 통해 용량 확장 및 선택적 메모리 접근이 가능해지며, 다양한 방식으로 게임 실행이 이루어짐

소개 및 목표

  • 저자는 개인적으로 게임보이 카트리지를 완전히 새로 제작하는 목표를 세움
  • 게임보이 카트리지 내부 구조와 작동 원리에 대한 지식을 오픈 소스로 정리해 공개함
  • 글의 목적은 난이도 있는 기술 정보를 초보자 시각에서 누구나 따라올 수 있도록 재구성하는 데 있음
  • 하드웨어의 내부 동작 원리가 아닌, 외부에서 관찰되는 행동(behavior) 중심으로 설명함
  • DMG(초기형 게임보이)의 SoC를 기준으로 설명하며, 게임보이 계열 기기의 기본적인 카트리지 인터페이스는 유사함

게임보이 플랫폼의 특별함

  • 게임보이는 단순함과 설계의 직관성 덕분에 하드웨어와 소프트웨어 구조를 머릿속에서 파악하기 쉬움
  • 이식성과 저전력 특성, 복잡한 보호장치나 지역 락이 없는 구조로 누구나 개발 가능함
  • 기술 문서, 하드웨어 도면, 커뮤니티 기반 자료가 풍부하게 축적되어 있음
  • 공식/비공식 게임 라이브러리가 방대하며, 오픈소스 개발 툴체인 및 시각적 스크립팅 툴 등이 활발하게 관리되고 있음
  • 하드웨어 구동기뿐 아니라 정확한 에뮬레이터 및 FPGA 구현 등 확장성 높은 생태계가 조성됨

게임보이 카트리지 기본 구조

  • 과거 콘솔 기기는 소프트웨어와 하드웨어의 경계가 불명확
  • 게임보이에는 운영체제나 내장된 비휘발성 저장장치가 없음. 모든 실행 코드와 추가 하드웨어가 카트리지에 내장됨
  • 이로 인해 카트리지가 완전히 작동해야만 게임보이가 부팅 및 작동
  • 카트리지 하단의 32핀 '엣지 커넥터' 는 본체와 신호를 주고받는 중심 인터페이스임
  • 카트리지와 본체 사이에는 전원, 제어(읽기/쓰기/칩선택), 주소버스(16비트), 데이터버스(8비트) 로 신호가 분류됨

버스(Bus) 및 동작 원리

  • 버스란 여러 부품이 하나의 신호선을 공유해 데이터를 동시에 전달할 수 있는 구조임
  • 게임보이의 CPU는 원하는 주소를 주소버스에, 데이터를 데이터버스에 전달
  • 버스 구조가 병렬(parallel) 이다 보니, 각 비트에 해당하는 핀이 실제로 존재함
  • 속도 면에서 유리하지만, 버스가 공유되는 만큼 충돌/컨텐션(동시쓰기) 위험이 있음
  • 여러 개의 IC가 동시에 데이터를 출력할 경우, 쇼트(과열 및 고장 위험) 가 발생하므로, 항상 하나의 IC만 활성화되어야 함

게임보이의 주요 메모리 분류

  • 게임보이는 최대 4종류 메모리 IC(내장 RAM, 비디오 RAM, 카트리지 ROM, 카트리지 RAM)를 장착 가능
  • 실제로 비디오 RAM은 독립된 버스를 사용하므로 일반적인 설명에선 제외
  • 내장/카트리지 RAM/ROM 셋은 같은 주소버스와 데이터버스를 공유
  • 반드시 한 번에 하나의 칩만 데이터버스에 쓰기/읽기 작업을 수행함
  • 실무적 용어로 내장RAM(WRAM), 카트리지RAM(SRAM), 비디오RAM(VRAM), 고속RAM(HRAM) 으로도 지칭됨

Chip Select(칩 선택)과 회로 구성

  • 각 메모리 칩에는 칩 선택 신호(CS/CE, Chip Select/Chip Enable) 핀이 존재
  • 칩 선택 신호 상태에 따라 특정 칩만 데이터버스에 접근 가능
  • 게임보이는 칩 선택을 위해 주소버스의 상위 3비트(A15, A14, A13) 와 CPU의 _CS 핀을 재활용함
  • 이러한 연결은 동시에 두 칩 이상이 활성화되지 않게 보장
  • 예를 들어, A15가 0일 때만 ROM 칩이 활성화되며, RAM은 별도의 논리로 활성화됨

메모리 맵(Memory Map)과 프로그래머 관점

  • 하드웨어적 주소/핀 상태는 추상화되어, 프로그래머는 논리적 메모리 맵만을 인식함
  • 16비트 주소 공간 내에서 0x0000–0x7FFF주소 구간은 카트리지 ROM, 0xA000–0xBFFF는 카트리지 RAM, 0xC000–0xDFFF는 내장 RAM으로 매핑됨
  • 특정 주소 접근 시 자동으로 원하는 메모리 범위가 활성화되고 나머지는 비활성화됨
  • 메모리 맵 자료는 게임보이 문서에서 중요한 참조 자료로 활용됨

메모리 뱅크 컨트롤러(MBC; Memory Bank Controller)

  • MBC는 게임보이 카트리지에서 32KB 이상의 ROM 용량 및 추가 RAM/주변기기 연결을 가능하게 하는 핵심 회로
  • 다양한 종류의 MBC가 시판되었으나, 여기서는 비교적 단순하고 범용적인 MBC5 기준으로 설명함
  • MBC5는 스위칭(banking) 기법을 통해 최대 8MB ROM, 128KB 카트리지 RAM을 지원
  • RAM의 접근 제어, 외부 센서/RTC 등 별도 하드웨어 제어도 가능
  • 카트리지의 ROM 주소핀 중 상위 비트(A22~A14)는 MBC5에서 동적으로 제어하며, 하위 비트만 본체의 주소버스에 직접 연결함

ROM 뱅킹(Banking) 원리

  • 게임보이 CPU는 최대 64KB 주소 공간, 실제로는 ROM 접근에 32KB(16KB+16KB)만 사용
  • MBC5는 ROM 칩의 상위 주소(뱅크 선택) 를 직접 제어해, 16KB 단위로 원하는 구간을 CPU 주소 공간에 매핑함
  • 하드웨어적으로는, CPU의 주소버스 하위 14비트(A0~A13)가 직접 ROM 칩에 연결되고, 나머지는 MBC5에서 입력받음
  • 실제 게임 실행 중 소프트웨어가 특정 메모리 주소에 값을 쓸 때, MBC가 이를 감지해 내부적으로 선택 뱅크 값을 갱신함

MBC 프로토콜 및 메커니즘

  • MBC5는 특정 주소/제어 신호 조합을 감지해서 ROM 뱅크 선택, RAM 뱅크 선택, 기타 기능 활성화/비활성화 등의 작업 수행
  • 예를 들어, A15=0, A13=1, A14=0(0x2000~0x3FFF) 구간에 쓰기 동작 시, 데이터버스에 실린 값을 ROM 뱅크 번호로 기록
  • 프로그래머는 실제로 뱅크 전환 작업이 저수준 회로 제어가 아닌, 특정 주소에 데이터를 기록하는 것처럼만 코딩
  • 카트리지 RAM 사용, 센서, RTC 등도 비슷한 패턴으로 제어됨
  • 이러한 버스 리유즈(재활용) 기법은 부품 수를 줄이고 가격을 낮추는 효과를 줌

결론 및 커뮤니티 활용

  • 게임보이 카트리지 구조의 특이점은 저가·고신뢰성·확장성에 있음
  • 직접 카트리지 제작 시, 위 구조와 프로토콜에 대한 정확한 이해가 필수적임
  • 커뮤니티와 풍부한 문서를 적극 참조하면, 하드웨어-소프트웨어 통합 개발 과정의 진입 장벽을 크게 낮출 수 있음

참고 자료 및 추가 학습 경로

  • Rodrigo Copetti의 Game Boy/Game Boy Color Architecture
  • gbdev.io, Pan Docs의 기술 문서
  • 다양한 오픈소스 카트리지 설계도 및 툴체인(예: GBDK, RGBDS 등)
  • 직접 제작 프로젝트 예시: abc.decontextualize.com

(해당 글의 후반부에서는 MBC 디자인 변형, EEPROM/플래시 메모리, 입출력 IC, 주변기기 통합 등 추가적으로 복잡한 요소가 다뤄지나, 상기의 항목은 게임보이 카트리지 동작 원리에 대한 핵심 내용에 해당함)

Hacker News 의견
  • TI의 TXB0108 사용 경험을 공유하고 싶음, 자동 방향 감지 기능 덕분에 방향 논리를 따로 추가할 필요가 없음처럼 보이지만 실제로는 사용을 권하지 않음, 전기적 노이즈가 있을 경우 방향이 바뀌어 입력이 출력이 되는 경우 발생, 그럴 때마다 기기가 잘 견디거나 심할 땐 소위 '마법의 연기' 현상 발생, 운이 정말 나쁘면 산업 현장 사고로 이어질 수 있음, 이런 부품은 전문가용으로 숨겨진 위험이 많아서 너무 광고되어선 안된다고 생각함, 실패 모드 정확히 알거나 다른 대안 없을 때만 사용해야 함

    • 이 부품들은 진짜 예측 불가임, 출력 단에 트레이스 한두 인치나 혹은 커넥터만 있어도 출력 링잉 때문에 자동 방향 반전이 자주 발생함, 전문가 아니면 사용 불가능한 수준임, 주로 사용하고 싶어질 상황에서 오히려 쓰기 어려움

    • 실제로 엄청 빠른 속도로 방향이 계속 바뀌면서 심각한 노이즈와 진동 발생한 경험 있음, 풀다운 관련 제약도 꽤 있지만 두 쪽 모두 같은 방향으로 풀 때는 그나마 괜찮았음

  • 딴 일 미루는 김에 abc-pcb.pdf 설계 첫인상에서 몇 가지 짚어봄

    • U6, U8 주위에 디커플링 캐패시터 필요함, LVC 로직이 전환 시 전력 소비 심하니 게이트 가까이에 배치 필요
    • 16와이드 WideBus 레벨 트랜슬레이터엔 각각의 전원 입력핀마다 캐패시터 달아야 함, 여러 전원 핀이 달린 이유가 있어서임
    • U6 출력 버스 방향이 잘못된 것처럼 보임, 내 경험상 Altium만 주로 써서 KiCad는 잘 모르겠으나 문제 아닐 수도 있음
    • VBUS는 신뢰성 원할 때 로직 신호로 쓰면 안 되고, 구동 속도가 느릴 때 변환 타이밍 달라져서 이상동작 위험 있음, Schmitt trigger로 신호 정리 추천
    • USB 포트에 ESD 보호 회로 없음, 오래 쓰고 싶다면 ECMF02-4CMX8 같은 부품 써보길 제안, 납땜은 살짝 귀찮을 수 있음
    • Q1 회로도가 직관적이지 않음, 그냥 MOSFET 두 개 평범하게 그리고 구분자 붙이면 훨씬 직관적으로 읽기 쉬움
    • IC2 칩(왜 U2 아니고 IC2인지?)의 4, 5, 6, 7선이 교차구동 중인데, 양쪽을 모두 그라운드하면 안 됨, 입력 쪽만 그라운드 처리, 출력은 연결하지 말고 저항으로 풀링하던가 해야 함
    • U7 SENSE 핀은 전류 거의 안 먹으니 저항분압에 전력 낭비 필요 없음
    • PDN(전원분배망) 댐핑을 위해 대용량 전해 캐패시터도 한두 개 넣어주면 좋을 듯함
  • 이 글이 내가 커스텀 카트리지 만들던 시절에 있었으면 참 좋았을 거라는 생각임
    내 게임 Cubeat에서는 GB의 오디오인 핀에 OPL3-L 칩을 달아서 FM 음악 구현함, MBC 로직은 7400 시리즈 단일 논리칩만 사용
    언젠가 꼭 완성해서 출시하고 싶은데, GB에 이런 신기한 트릭을 구현해보는 것도 정말 즐거운 경험임
    Cubeat 정보

  • 바로 이런 수준으로 Game Boy 카트리지 구조에 대해 알고 싶었던 것임

  • Game Boy 카트리지는 RAM과 디스크 공간을 앱과 함께 제공하는 아이디어가 신선함, 생각해보면 논리적으로도 맞음
    만약 핸드폰도 이런 식으로 동작했다면, 몇 년마다 칩 기술이 개선될 때마다 새로운 카트리지 사서 고성능 앱을 실행하거나, 새로운 안테나를 꽂는 식으로 업그레이드가 가능하지 않았을까 상상해봄

    • 모듈형 핸드폰은 예전부터 제안됐으나 실용적이지 않거나 유용하지 않았음, 모든 부품을 소켓으로 연결하면 칩 간 레이턴시는 늘고 신뢰성도 떨어짐, 주머니에서 하루 종일 흔들리는 제품이라 더더욱 취약함
      실제로 휴대폰에서 한 가지만 구식되는 게 아니라 카메라, 화면, CPU, RAM, 배터리 등 거의 모든 부분을 동시에 업그레이드하고 싶어함, 그렇다면 낱개로 바꾸는 것보다 그냥 새 폰을 사는 게 나음, 굳이 개별적으로 바꾸면서 얻는 건 케이스 값 아끼는 정도임

    • 마이크로컨트롤러 ROM 핫패치 시스템 논의 중인데 이런 이유로 칩에 앱을 다 실어서 바로 구동하는 구조의 장점이 확실함, 다만 사용자 요구는 점점 바뀌니 더욱 복잡해지는 것 같음

    • 좋은 아이디어인 건 확실하지만, 꽂는 기기 하드웨어 성능이 한계가 되지 않을까 고민이 있음
      카트리지에 더 빠른 RAM을 넣을 순 있어도, 기존 보드가 이를 제대로 활용할 수 있을지 의문임
      더 빠른 저장장치 부착이 가능하더라도 받쳐주는 하드웨어가 그대로라면 실질 효과가 얼마나 있을지 확실하지 않음

    • 심지어 카메라도 꽂는다는 상상도 해봄

  • Game Boy 커스텀 소프트웨어 제작 시 복제 방지나 리전락 하드웨어를 우회할 필요가 없다는 말에 대해, 실제로는 로고 체크를 통과해야 하는 거 아닌지 질문함

    • 아마 이 말은 하드웨어 개조나 해킹이 필요 없고 ROM 헤더에 특정 블롭만 포함시키면 된다는 의미로 설명함, RGBDS 툴체인(RGBFIX) 사용 시 자동으로 삽입 가능
      그리고 Sega v. Accolade 판결 이후로는 사실상 타이틀 체크 방식이 더이상 법적으로 강제되지 않으니 실질적인 우회 장벽이 없음
  • 예전에 즐겨 찾던 GB 개발 자료 사이트인 http://www.devrs.com/">devrs.com이 더이상 운영되지 않아 아쉬움, 이미 대부분의 링크가 죽었지만 영감을 주는 프로젝트가 많았던 곳임

  • Ultimate Game Boy Talk(33c3 발표) 영상도 참고할 만함
    Ultimate Game Boy Talk - 33c3

  • 내 Pokemon Blue 버전은 20년 전 세탁기 돌리고 건조기까지 들어갔는데 지금도 정상 작동함, 진짜 튼튼한 하드웨어임, SD카드가 이런 고생 버틸 수 있을지 궁금함

    • 건조기의 열이 물보다 더 큰 문제일 거라고 생각함
  • 이번 달 KiCad랑 PCB 설계를 재미삼아 입문했는데, 혹시 오리지널 Game Boy PCB 전체를 직접 만든 후 오픈소스로 공개한 사례가 있는지 궁금함

    • FunnyPlaying이라는 업체가 GBC, GBA PCB를 직접 제작해서 판매함, 오픈소스 버전은 찾아보기 어려움
      nataliethenerd의 GitHub에는 CGB 리버스 엔지니어링 프로젝트가 있지만 라이센스가 비상업임
      "CGB-CPU-04 보드를 사용해 스캔, 연마, 재작성해서 CGB 회로도를 정리함, 값 등은 원본 회로 참조함" 설명함

    • PCB 설계에 참고할 만한 자료 추천도 궁금함