2P by GN⁺ | ★ favorite | 댓글 1개
  • Game Boy 계열은 낮은 전력 예산 안에서 DMG-CPU SoC, PPU, APU, 부트 ROM, Game Pak을 결합해 휴대용 콘솔의 CPU·그래픽·오디오·호환성·복제 방지를 한 시스템으로 묶음
  • CPU는 Sharp의 SM83 코어를 기반으로 약 4.19 MHz에서 동작하고, Game Boy Color의 CPU CGB는 같은 계열을 유지하면서 듀얼 속도 모드에서 약 8.38 MHz까지 올림
  • 그래픽은 160×144 LCD와 VRAM 기반 PPU가 타일·배경·스프라이트·윈도우를 조합하는 방식이며, Color 모델은 16 KB VRAM, 32,768색 팔레트, 추가 DMA로 표현력을 넓힘
  • 오디오는 4채널 APU가 담당하고, Game Pak은 32 KB 기본 주소 공간을 넘기 위해 Memory Bank Controller를 사용하며, Link 케이블과 Color의 적외선으로 외부 통신을 지원함
  • 부트 ROM은 Nintendo 로고와 ROM 헤더 체크섬을 검사한 뒤 게임을 실행하며, 이 로고 요구는 저작권·상표권을 활용한 배포 통제 장치로 작동함

Game Boy 계열의 범위와 설계 방향

  • Game Boy 시리즈는 NES의 휴대용 버전처럼 볼 수 있지만, 단순 축소판이 아니라 자체 기능과 확장 방향을 갖춘 구조임
  • Game Boy 브랜드는 두 세대에 걸쳐 이어짐
    • 4세대에는 흑백 Game Boy와 Game Boy Pocket, Light 같은 개정판이 포함됨
    • 다음 세대에는 Virtual Boy 이후 출시된 Game Boy Color가 포함됨
  • 분석의 초점은 흑백 Game Boy의 기본 구조와, 이 구조가 Color 모델에서 어떻게 확장됐는지에 있음

CPU와 메모리 구조

  • Nintendo는 여러 범용 칩을 메인보드에 배치하는 대신, CPU와 주요 구성요소를 담은 단일 칩 설계를 선택함
    • 이 SoC는 DMG-CPU 또는 Sharp LR35902로 불림
    • Sharp Corporation이 제조했으며, Nintendo 요구에 맞춘 전력 효율, 복제 방지, 추가 I/O 구현에 유리했음
    • 소매 카탈로그에서 구할 수 없는 칩이어서 경쟁사가 그대로 복제하기 어려웠음
  • SM83 CPU 코어

    • DMG-CPU 내부의 주 프로세서는 Sharp SM83
    • Zilog Z80과 Intel 8080을 섞은 형태로, 약 4.19 MHz에서 동작함
    • SM83은 Z80과 8080의 일부 기능만 유지함
      • Z80의 IX, IY 레지스터와 8080의 IN, OUT 명령이 없음
      • I/O 포트를 사용할 수 없어 구성요소가 메모리 매핑되어야 함
      • Intel 8080의 레지스터 세트만 갖고 있어 범용 레지스터는 7개임
      • Z80 확장 명령 중 비트 조작 명령 일부만 구현됨
    • Sharp는 Z80이나 8080에 없는 새 명령도 추가함
      • LDH$FF00부터 시작하는 메모리 맵 마지막 256바이트 접근을 위해 설계됨
      • 명령 크기가 1바이트 줄어 약간 더 빠르게 동작할 수 있음
  • Game Boy Color의 CPU 변화

    • Game Boy Color에는 새 SoC인 CPU CGB가 들어가지만, SM83 CPU 코어는 대체로 유지됨
    • 가장 큰 예외는 클록 속도로, 약 8.38 MHz까지 두 배가 됨
    • 같은 CPU 코어를 유지하면 개발자가 기존 프로그래밍 지식을 재사용할 수 있고, 새 아키텍처 재설계 비용과 하위 호환성 구현 부담도 줄어듦
    • CPU CGB는 두 동작 모드를 제공함
      • Normal mode: SM83이 약 4.19 MHz로 동작함
      • Dual-speed mode: SM83이 약 8.38 MHz로 동작함
    • 이 선택은 1990년대 후반 기준으로 오래된 기술을 계속 쓰는 대가도 남김
  • 주소 공간과 RAM

    • SM83은 8비트 데이터 버스16비트 주소 버스를 유지해 최대 64 KB 메모리를 주소 지정할 수 있음
    • 메모리 맵은 Game Pak 공간, WRAM, HRAM, VRAM, 조이패드·오디오·그래픽·LCD 등 I/O, 인터럽트 제어 영역으로 구성됨
    • 원래 Game Boy 메인보드에는 범용 메모리인 8 KB WRAM이 탑재됐고, 이는 NES의 4배 용량임
    • SoC 안에는 127 B HRAM도 있음
      • LDH 명령으로 더 빠르게 접근할 수 있는 작은 공간임
      • HRAM 버스 자체가 WRAM보다 기술적으로 빠른 것은 아니지만 CPU에 우선권이 있음
      • DMA 동작 중 CPU가 외부 메모리에 접근하지 못하는 상황에서 중요함
    • Game Boy Color는 WRAM을 32 KB로 늘림
      • CPU 주소 지정 능력은 그대로라 전체 메모리를 한 번에 연결할 수 없음
      • 추가 24 KB WRAM 접근에는 뱅크 스위칭을 사용함
      • 기존 8 KB 공간의 마지막 4 KB를 7개 뱅크 사이에서 교체함
      • SVBK 레지스터가 WRAM 뱅크 선택에 사용됨

그래픽: PPU, LCD, 레이어 구성

  • Game Boy 그래픽은 CPU가 계산을 수행하고, DMG-CPU SoC 안의 별도 PPU가 화면을 렌더링하는 구조임
  • 내장 LCD는 160×144 픽셀 해상도를 제공함
    • 흑백 Game Boy LCD는 흰색, 연회색, 진회색, 검은색의 4단계 회색만 반사함
    • 녹색 톤 LCD 때문에 화면은 약간 녹색으로 보임
  • 모든 Game Boy는 지역별 전원 주파수에 의존하는 가정용 콘솔과 달리 AA 배터리 4개로 동작함
    • CPU 클록과 새로고침률이 지역별로 달라지지 않음
    • 새로고침률은 59.7 Hz
  • VRAM과 타일 기반 렌더링

    • PPU는 8 KB VRAM에 독점적으로 연결되고, 렌더링에 필요한 데이터 대부분을 이곳에서 읽음
    • 더 빠른 접근이 필요한 일부 자료는 PPU 내부에 저장됨
    • CPU의 VRAM 접근은 PPU가 중재하며, 게임은 VRAM 영역에 올바른 데이터를 채워야 함
    • 기본 렌더링 단위는 타일
      • 타일은 8×8 픽셀 비트맵임
      • 각 타일은 16바이트를 차지함
      • VRAM의 Tile set 또는 Tile pattern table 영역에 저장됨
    • 색은 팔레트를 통해 4단계 회색 중에서 선택됨
    • 흑백 Game Boy는 최대 3개 팔레트를 정의할 수 있지만, 렌더링되는 레이어 종류에 따라 사용이 제한됨
  • 배경, 스프라이트, 윈도우

    • 최종 프레임은 세 개의 겹치는 레이어로 구성됨
    • 배경 레이어는 256×256 픽셀, 즉 32×32 타일 맵임
      • 실제 화면에는 160×144 픽셀만 보임
      • 게임은 표시할 배경 영역을 선택하고 이를 이동시켜 스크롤 효과를 구현함
      • 배경 레이어에는 팔레트 1개만 사용됨
    • 스프라이트는 독립적으로 움직일 수 있는 타일임
      • 서로 겹치거나 배경 뒤에 배치될 수 있음
      • 표시 우선순위는 priority 속성으로 결정됨
      • 투명색이 추가되어 실제 표시 가능한 회색은 3단계임
      • 전용 팔레트 2개 중 하나를 선택할 수 있음
    • 스프라이트 정의는 PPU 내부의 OAM(Object Attribute Memory) 에 저장됨
      • 게임은 보통 OAM DMA를 호출해 RAM 또는 ROM에서 OAM으로 데이터를 복사함
      • DMA가 활성화된 동안 CPU는 외부 메모리에 접근할 수 없음
      • 각 OAM 항목에는 타일 인덱스, X-Y 위치, 팔레트, 우선순위, 상하·좌우 반전 플래그가 포함됨
    • PPU의 스프라이트 렌더링에는 한계가 있음
      • 스캔라인당 최대 10개
      • 프레임당 최대 40개
      • 한계를 넘으면 일부 스프라이트가 그려지지 않음
    • 윈도우 레이어는 160×144 픽셀 맵으로 화면 전체를 덮을 수 있음
      • 배경과 스프라이트 위에 렌더링됨
      • 스크롤되지 않음
      • 남은 타일 맵 하나만 윈도우 레이어에 할당될 수 있음
      • 배경과 같은 팔레트를 공유함
      • 투명하지 않아 아래 레이어를 완전히 가리지만, 타이밍 기반 래스터 효과와 함께 부분적으로 사용할 수 있음
      • 게임은 생명 카운터, 점수, 지속 표시 정보에 윈도우 레이어를 주로 사용함
  • 프레임 갱신과 래스터 효과

    • CPU는 PPU가 VRAM을 읽는 동안 테이블을 수정할 수 없음
    • 시스템은 PPU가 유휴 상태일 때 발생하는 인터럽트를 제공함
      • Horizontal Blank는 한 스캔라인이 끝난 뒤 시작되며, 아직 그려지지 않은 프레임 부분을 조정할 수 있음
      • Vertical Blank는 모든 스캔라인이 끝난 뒤 시작되며, 다음 프레임의 그래픽을 업데이트할 수 있음
      • OAM search는 스캔라인 시작 시점에 발생하며, PPU가 해당 라인의 스프라이트를 결정하는 동안 OAM을 제외한 영역을 업데이트할 수 있음
    • 윈도우 레이어와 추가 인터럽트 덕분에 화면이 모두 그려지기 전에 프레임 일부를 바꿀 수 있음
    • 스캔라인마다 다른 스크롤 값을 적용하면 각 행이 다른 속도로 이동하는 wobble effect를 만들 수 있음

Game Boy Color의 그래픽 확장

  • Game Boy Color의 PPU는 원래 PPU의 상위 집합처럼 동작하며, 호환성을 위해 두 동작 모드를 제공함
    • CGB mode: Game Boy Color 타이틀의 시각적 개선을 제공함
    • DMG mode: 확장 기능을 비활성화한 전통 모드임
  • Game Boy Color 메인보드에는 16 KB VRAM이 있음
    • 기존보다 두 배 용량임
    • CPU 주소 제한 때문에 8 KB 뱅크 2개로 구성됨
    • VBK 레지스터가 VRAM 뱅크 전환에 사용됨
  • PPU는 두 VRAM 뱅크에 동시에 접근할 수 있음
    • 개발자는 VBK로 VRAM 뱅크를 채움
    • 타일 맵에서 타일이 어느 뱅크에 있는지 지정하면 PPU가 처리함
  • 추가 VRAM은 두 배 많은 타일 저장, 더 많은 팔레트 저장, 타일 메타데이터 확장, 추가 팔레트와 효과 참조에 쓰임
  • 색상과 추가 DMA

    • Game Boy Color의 새 PPU는 32,768색 중에서 팔레트를 정의할 수 있음
    • 개발자는 Palette Memory에 최대 16개 색상 팔레트를 저장함
      • 배경·윈도우용 8개, 스프라이트용 8개임
      • 각 팔레트는 4색을 인코딩함
      • 각 항목은 16비트 값이지만 실제로는 15비트만 사용됨
      • Palette Memory는 CPU가 직접 주소 지정할 수 없고, 새 레지스터가 쓰기 버퍼 역할을 함
    • 배경과 윈도우 타일은 8개 팔레트 중 하나를 참조할 수 있음
    • 스프라이트 타일도 8개 팔레트를 참조할 수 있지만, 한 항목은 여전히 투명색으로 예약되어 3색 팔레트 제약이 남음
    • 타일 세트는 두 배 커져 VRAM에 두 배 많은 타일을 저장할 수 있음
    • 배경·윈도우 타일 맵도 확장되어 메타데이터를 더 담을 수 있음
    • 배경과 윈도우 타일은 상하·좌우 반전이 가능해 중복 그래픽을 VRAM에 저장할 필요를 줄임
    • CPU CGB에는 VRAM으로 데이터를 복사하는 추가 DMA 유닛이 있음
      • Game Pak 또는 WRAM에서 VRAM으로 복사 가능함
      • General-purpose DMA는 언제든 전송할 수 있지만, 전송 중 메모리 접근 우선권을 가져 화면 찢김이 생길 수 있음
      • H-Blank DMA는 H-Blank 동안만 전송해 화면 아티팩트를 피하지만, 16바이트 단위로 제한되고 LCD 스캔 중에는 멈춤

오디오: 4채널 APU

  • 오디오는 APU(Audio Processing Unit) 가 담당하며, Programmable Sound Generator 방식으로 총 4채널을 제공함
  • APU는 Game Boy 개정판 전반에서 변하지 않은 구성요소 중 하나임
    • CPU처럼 가속할 수 없음
    • 오실레이터 속도를 바꾸면 음질이 좋아지는 것이 아니라 음높이가 바뀜
    • 기능을 늘리려면 회로를 추가해야 하며 비용도 증가함
  • 채널 구성

    • 펄스파 채널은 2개이며, 주로 멜로디와 효과음에 사용됨
      • 펄스 폭을 바꿔 4가지 톤을 제공함
      • 첫 번째 채널은 전용 sweep control을 가짐
      • 채널 수가 제한되어 게임 중 효과음이 나올 때 멜로디가 끊길 수 있음
    • 세 번째 채널은 사용자 정의 파형을 지원함
      • 32개의 4비트 샘플로 구성된 파형을 wavetable에 저장함
      • 볼륨과 주파수를 제어할 수 있음
    • 노이즈 채널은 1개임
      • 백색 잡음처럼 들리는 임의 파형 모음임
      • 게임에서 타악기나 주변 효과에 주로 사용됨
      • clean static과 robotic static 두 톤을 제공하고 주파수 조정도 가능함
  • 믹서와 확장 오디오 핀

    • 믹서는 스테레오 출력을 제공해 채널을 좌우에 배치할 수 있음
    • 내장 스피커는 모노라 팬닝은 헤드폰 출력에서만 들림
    • 믹서 하드웨어는 카트리지의 전용 핀에도 연결됨
      • 카트리지가 추가 하드웨어로 아날로그 사운드를 출력하면 추가 채널을 스트리밍할 수 있음
      • 시장에 나온 게임은 이 기능을 사용하지 않았음
      • 이 기능은 Game Boy Advance 시기에 제거됨

부트 ROM과 운영 방식

  • Game Boy는 NES/Famicom처럼 바로 게임으로 부팅하지 않고, 내부 256바이트 ROM에서 먼저 부팅함
  • 기본 부트 절차는 다음과 같음
    • 전원이 켜지면 CPU가 주소 0x0000에서 읽기 시작함
    • RAM과 APU가 초기화됨
    • 카트리지 ROM의 Nintendo 로고 그래픽을 Display RAM으로 복사해 화면 위쪽에 그림
    • 카트리지가 없거나 제대로 삽입되지 않으면 로고가 깨진 타일로 보일 수 있음
    • 로고가 아래로 스크롤되고 상징적인 소리가 재생됨
    • 게임의 Nintendo 로고를 콘솔 ROM 안의 로고와 비교함
    • 카트리지 ROM 헤더에 빠른 체크섬을 수행함
    • 검사 실패 시 콘솔은 멈춤
    • 콘솔 ROM이 메모리 맵에서 제거됨
    • CPU가 게임 실행을 시작함
  • 화면에 표시된 Nintendo 로고는 VRAM에서 지워지지 않아, 게임이 이 로고에 애니메이션이나 전환 효과를 적용할 수 있음
  • Game Boy Color의 부트 변화

    • Game Boy Color의 ROM 크기는 2 KB로 증가함
    • 부트 시퀀스는 삽입된 게임이 Game Boy 전용인지 Game Boy Color 게임인지 확인함
    • 카트리지 ROM의 특정 메타데이터를 검사하고, 결과에 따라 DMG 또는 CGB 모드 활성화 레지스터를 설정함
    • DMG 게임이 삽입되면 부트 프로그램이 Palette RAM을 계산된 팔레트로 채움
      • 게임 메타데이터에 의존하는 단순한 알고리듬을 사용함
      • 흑백 게임이 Game Boy Color에서 색이 입혀져 보이는 원리임
      • 사용자는 부팅 중 버튼 조합으로 선택된 팔레트를 바꿀 수 있음
    • Nintendo 로고는 HRAM에도 복사됨
    • 체크섬 단계는 HRAM의 로고 앞 절반만 검사함

Game Pak, 게임 제작, 외부 통신

  • 당시 성능이 중요한 게임은 고수준 언어 컴파일러 성숙도가 충분하지 않아 주로 어셈블리 언어로 작성됨
  • 상용 게임은 Nintendo의 Game Boy용 카트리지인 Game Pak으로 배포됨
  • 기본 저장 공간은 주소 공간 제약 때문에 최대 32 KB
    • Memory Bank Controller, 즉 mapper를 사용하면 더 큰 게임이 가능함
    • 시장에 나온 가장 큰 Game Pak은 원래 Game Boy에서 1 MB ROM, Game Boy Color에서 8 MB ROM을 탑재함
  • 일부 Game Pak은 실시간 시계, 추가 SRAM, 저장 유지를 위한 외부 배터리를 포함함
  • Color 시대의 카트리지 유형

    • Game Boy Color의 동작 모드가 추가되면서 게임은 세 가지 유형으로 구분됨
      • Game Boy: 모든 Game Boy 모델과 완전히 호환되며 항상 DMG 모드로 실행됨
      • Game Boy Color enhanced: 흑백 모델과 호환되면서 Game Boy Color에서는 CGB 모드로 시각적으로 향상됨
      • Game Boy Color exclusive: Game Boy Color에서만 호환되며 해당 하드웨어를 활용하도록 최적화됨
    • 세 유형에는 구분을 돕는 공식 색상이 있었음
    • Pokémon과 Donkey Kong 같은 일부 게임은 다른 디자인을 사용함
  • Link 케이블과 적외선

    • Game Boy 게임은 처음으로 Game Boy Link 케이블을 통해 외부 하드웨어와 통신할 수 있었고, 멀티플레이와 액세서리 사용이 가능해짐
    • Link 케이블은 콘솔의 6핀 서브커넥터에 연결되며, 인터페이스는 SPI(Serial Peripheral Interface) 프로토콜을 사용함
      • 한 Game Boy가 master로 클록 신호를 구동하고 다른 쪽은 slave가 됨
      • 각 전송에서 master와 slave가 8비트 패킷 1개를 교환함
      • 원래 Game Boy의 전송 속도는 8 Kbit/s, 즉 1 KB/s임
      • Game Boy Color는 high speed 모드에서 최대 512 Kbit/s, 즉 64 KB/s까지 도달할 수 있음
    • Nintendo는 최대 4대 Game Boy가 동시에 데이터를 교환하도록 4-Player Adapter도 출시함
      • 기본 SPI는 유지됨
      • 어댑터가 master로 동작하며 게임이 따라야 하는 추가 통신 계층을 구현함
    • Game Boy Color에는 적외선 송수신기가 포함됨
      • LED와 포토트랜지스터로 구성됨
      • Pokémon Gold 같은 타이틀에서 무선 데이터 교환에 사용됨
      • 시스템 자체는 통신 프로토콜을 구현하지 않음
      • RP 레지스터 하나가 IR 센서 동작, 전송 비트, 마지막 수신 비트를 인코딩함
      • Nintendo는 공식 Game Boy Developer Manual에 참조 구현을 제공함

복제 방지 구조

  • 콘솔은 게임을 바로 실행하지 않고 먼저 여러 검사를 수행해, 승인되지 않은 카트리지 실행을 막고 카트리지가 제대로 삽입됐는지도 확인함
  • 게임은 ROM 헤더 안에 Nintendo 로고의 사본을 타일 형태로 포함해야 검사를 통과할 수 있었음
    • Nintendo는 이를 통해 저작권과 상표권 법을 배포 통제에 활용할 수 있었음
  • 이후 Sega v. Accolade 사건은 이런 요구를 충족하기 위해 저작권 로고를 사용하는 것이 공정 이용이라고 판단해 기업에 권리를 부여함
  • 게임 내부에서도 추가 복제 방지 조치를 구현할 수 있었음
    • 부트레그에서 보통 더 큰 SRAM 크기를 검사함
    • 게임플레이 중 임의 시점에 ROM 체크섬을 수행해 코드 변경을 감지함

댓글과 토론

Hacker News 의견들
  • 원래 Game Boy 개발에서 정말 뛰어났던 점은 당시 Gunpei Yokoi 팀이 큰 불신을 받는 상황이었다는 것임
    “버스나 화장실에서 왜 게임을 하냐, 불편할 텐데. 집에서 가족·친구와 TV 앞 소파에 앉아 하거나, 최신 경험은 오락실에서 하면 되지. 건전지 갈아 끼우고 회색 몇 단계만 보는 걸 누가 원하냐”는 식이었음
    그들의 비전은 시든 기술을 가져와 쓰기 쉬운 기기와 단순하고 짧은 게임으로 포장하는 것이었고, 그 팀이 사실상 모바일 게임을 시작했다고 봄

    • 그건 수정주의적 역사관에 가까움
      1970년대 아이들은 이미 Mattel의 휴대용 LED 게임을 버스와 화장실에서 하고 있었고, 나도 최소 6개, 어쩌면 8개쯤 갖고 있었음. 가장 이른 예가 1976년의 https://en.m.wikipedia.org/wiki/Mattel_Auto_Race
      더 인기 있던 건 미식축구, 야구, 농구 같은 스포츠 게임이었고 Auto Race보다 규칙도 훨씬 복잡했음: https://www.ebay.com/p/2255363696
      1980년대 초에는 Dungeons and Dragons 같은 휴대용 LCD 게임도 많이 나왔음: https://en.m.wikipedia.org/wiki/Dungeons_%26_Dragons_Compute... (1981)
      “Mattel stated that the game immediately sold out.” 카트리지를 쓰진 않았지만 특히 LCD 게임은 싸고 작아서 여러 개 가져도 부담이 없었음
      요즘은 Game Boy 세대의 휴대용 기기와 구분하려고 이런 것들을 “handhelds”라고 부르지만, 당시에는 그렇게 부르지 않았던 것으로 기억함. 요지는 1970년대와 1980년대 초에 이미 성공한 시장이 있었고, Nintendo는 그걸 만든 게 아니라 이미 성공한 카트리지 기반 콘솔과 휴대용 게임 시장을 결합해 발전시킨 것임
    • Game & Watch가 먼저였고, 역시 Gunpei Yokoi였음. 적어도 내 기억으로는 그걸 모바일 게임의 시작으로 봐도 될 듯함
    • Game Boy가 나오기 6년쯤 전에 이미 자동차 경주 게임이 들어간 시계를 갖고 있었음
  • Game Boy Color가 추가된 건 봤는데, 카트리지 크기가 1MB뿐이라는 부분은 고치지 않은 듯함. 일부 GBC 게임은 4MB까지 감
    추가로 짧은 동영상과 하이컬러 이미지가 들어간 기차 게임은 8MB짜리도 있음

    • 맞음, 電車でGO!2 高速編 aka Densha de Go! 2 Kōsoku-hen임
      https://www.youtube.com/watch?v=S62dSVmLPU0
    • 공정하게 말하면, DMG 게임이 4MB에 도달하는 걸 막는 것도 딱히 없었다고 봄
      팩의 창 크기는 어느 쪽이든 기본적으로 32KB로 같고, 4MB든 1MB든 뱅크 전환은 카트리지 쪽에서 처리함
  • Game Boy는 지금까지 나온 콘솔 중 단연 가장 좋아하는 기기임. 지금 어셈블리어로 Game Boy 게임을 만들고 있고, 핀볼 던전 크롤러임
    하드웨어를 이해하기 쉽고, 제약 덕분에 창의적으로 만들 수밖에 없음

  • Florent Gorges가 Game Boy만 다룬 책을 냈는데, 아쉽게도 영어 번역은 없는 것 같음. 스페인어판으로 샀고, 제작자들의 독점 인터뷰가 들어 있음
    https://www.amazon.es/Historia-Nintendo-Vol-4-1989-1999-INCR...

  • 지금 정도의 민주화된 하드웨어 수준이면 적절한 부품과 배선된 PCB를 사서 Game Boy를 다시 만들 수 있을까?

    • 해본 사람들은 있지만, 최소한 원본 CPU는 옮겨 심어야 함. 그 칩들은 다른 용도로 만들어진 게 아님: https://www.reddit.com/r/Gameboy/s/FEAH2VhBRT
      FunnyPlaying이 최근 합리적인 가격의 FPGA 기반 버전을 냈음: https://funnyplaying.com/products/fpgbc-kit?variant=40858870...
      Game Boy Advance용으로 부품이 실장된 새 메인보드도 있는데, 여기에 CPU와 RAM을 옮겨 심어야 함
    • 출시 당시의 슈퍼컴퓨터만큼 빠른 GameBoy여도 괜찮다면, ARM 단일 보드 컴퓨터에서 Linux로 GameBoy 에뮬레이터를 돌리고 OLED 화면에 출력하는 구성을 150달러 미만과 약간의 정신력으로 만들 수 있을 것 같음
      하드웨어 충실도를 원한다면, 손에 들 수 있는 크기의 단일 기기를 만드는 비용은 “민주화된” 가격대에 들어가기 어려울 듯함
    • 지금 접근법은 FPGA를 쓰는 것임. Analogue Pocket을 보면 되고, 다른 키트들도 있음
    • 기껏해야 오래된 Game Boy에서 떼어낸 부품을 사서 다시 조립하는 정도일 듯함. 어딘가에서 FPGA Game Boy 구현을 본 것 같은데, 그게 가장 가까운 방법일 수 있음
  • Game Boy 구조를 배워서 뭘 하려고, 지구를 해킹할 건가?

    • 운영체제 없이 하드웨어와 직접 맞닿아 동작하는 단순한 구조라서 임베디드 프로그래밍으로 들어가는 좋은 관문이고, 재미도 있음