mgba 딥다이브
— C 코드로 작은 게임기의 시간을 재현하다

1프로젝트 한줄 요약

mGBA는 게임기의 부품과 그 부품이 움직이는 순서를 코드로 구현한 프로그램입니다. 게임 파일에 들어 있는 기계어를 해석하고, 가상 메모리를 읽고 쓰며, 화면과 소리를 만들어 컴퓨터의 출력 장치로 전달합니다. 에뮬레이터의 핵심은 그림을 비슷하게 그리는 것보다, 하드웨어의 상태가 언제 바뀌는지 재현하는 데 있습니다.

게임 하나를 열면 일어나는 일

1. src/core/core.c의 mCoreFindVF()가 파일 내용을 판별해 GBA 또는 GB 코어를 고릅니다.
2. GBA의 경우 GBACoreCreate()가 공통 함수표를 채우고, init 호출이 CPU·보드·렌더러를 준비합니다.
3. 프론트엔드가 ROM과 설정을 연결하고 reset을 호출합니다.
4. 코어가 명령어와 하드웨어 이벤트를 진행하고, 프론트엔드가 픽셀·오디오를 출력합니다.

이 흐름은 src/platform/example/client-server/server.c의 _mExampleRun()에서 특히 잘 보입니다. 입력을 받아 setKeys를 호출하고, runFrame 뒤에 화면 버퍼를 보냅니다. 이 예제의 네트워크 연결은 화면 전송 학습용이며, 게임기의 통신 케이블을 인터넷으로 구현했다는 뜻은 아닙니다.

2왜 주목받는가

2-1. 순위는 관심을 보여 주고, 코드는 공부할 이유를 보여 줍니다

2026-10-23 분석 대상 선정 기준은 TrendShift Repositories #2입니다. 같은 날 GitHub 기준 스타는 7,521개, 포크는 1,139개입니다. 다만 이 수치와 순위만으로 특정 영상·사건·기능이 유행의 원인이라고 단정할 수는 없습니다. 여기서는 소스와 문서에서 드러나는 학습 가치에 초점을 맞춥니다.

첫째, 하나의 엔진을 여러 제품 형태로 재사용합니다. Qt GUI, SDL 프론트엔드, Libretro 연동과 Python 바인딩이 공통 코어 주변에 놓입니다. 둘째, CPU뿐 아니라 센서·저장·영상·디버거까지 이어져, 낮은 수준의 구현이 사용자 기능으로 바뀌는 과정을 볼 수 있습니다.

셋째, 오래된 기계를 다루면서도 이식성과 유지보수를 계속 다룹니다. CHANGES의 개발 버전 항목에는 Qt 6 지원, DMA 경계 동작 수정, 헤드리스 프론트엔드 등이 있습니다. 이는 분석 커밋의 변경 기록이며, 모두 0.10.5에 들어 있다는 의미는 아닙니다.

2-2. 다른 에뮬레이터와 비교하면 보이는 위치

비교 근거: VBA-M 공식 저장소, SameBoy 공식 소개. 지원 범위와 구성 방식의 비교이며, 같은 조건의 성능·정확도 측정 결과는 아닙니다.

mGBA를 공부할 가치는 여러 화면과 플랫폼이 같은 에뮬레이션 엔진을 공유하도록 만든 경계에서 드러납니다. SDL로 바꾸어도 ARM 명령어의 의미를 다시 구현하지 않는 이유를 이해하는 것이 좋은 출발점입니다.

2-3. README의 목표와 검증 가능한 구현

3기술 스택 전체 지도

웹 서비스의 용어를 빌리면 백엔드는 로컬 에뮬레이션 코어, 프론트엔드는 Qt·SDL 화면입니다. 일반 실행 경로에 HTTP 서버나 클라우드 DB가 필요한 구조는 아닙니다. SQLite도 사용자 계정 서버가 아니라 게임 데이터베이스 기능에 쓰는 선택 의존성입니다.

3-1. 백엔드에 해당하는 부분: C11 코어

3-2. 프론트엔드: C++14·Qt와 SDL

src/platform/qt/CMakeLists.txt는 C++14를 요구하며, QT_VERSIONS 6 5 순서로 Qt를 탐색합니다. Core·Widgets·Network를 찾고 Multimedia는 선택 모듈로 취급합니다. FORCE_QT_VERSION에 5 또는 6을 지정하는 분기도 있습니다.

SDL은 src/platform/sdl/CMakeLists.txt에서 SDL_VERSION "3"이 기본입니다. SDL 3을 찾지 못하면 2, 그다음 1.2를 찾습니다. 이는 버전 번호를 하나로 고정한 잠금 파일이 아니라 사용 가능한 라이브러리를 선택하는 탐색 정책입니다.

3-3. 의존성에 기록된 버전: 고정 값과 최소 조건을 구분하기

동봉 버전은 저장소 안의 사본에 대한 값입니다. CMake가 시스템 라이브러리를 찾는 경우 실제 링크 대상 버전은 달라질 수 있습니다. FFmpeg는 녹화, libpng·zlib는 이미지와 압축, libzip은 압축 ROM, Lua는 스크립트 기능과 연결됩니다.

3-4. 인프라·빌드: 기능을 조합하는 CMake

# CMakeLists.txt의 기본값 일부를 간추린 구성 지도
M_CORE_GBA=ON      M_CORE_GB=ON
BUILD_QT=ON        BUILD_SDL=ON
BUILD_SHARED=ON    BUILD_STATIC=OFF
BUILD_LIBRETRO=OFF BUILD_PYTHON=OFF
BUILD_SUITE=OFF    BUILD_CINEMA=OFF

ON은 기능을 요청하는 기본값이지, 모든 환경에서 반드시 포함된다는 보장은 아닙니다. Qt·SDL 라이브러리를 찾지 못하면 해당 프론트엔드가 제외될 수 있습니다. LIBMGBA_ONLY 분기는 프론트엔드를 끄고 정적 라이브러리 중심으로 구성합니다.

CMakePresets.json의 clang·gcc 프리셋은 Ninja, Debug, CMAKE_EXPORT_COMPILE_COMMANDS=ON을 설정합니다. 이름만 보고 컴파일러 실행 파일까지 고정한다고 해석하면 안 됩니다.

테스트 구성은 src/platform/test/CMakeLists.txt에 있습니다. BUILD_SUITE는 cmocka 기반 단위 테스트, BUILD_CINEMA는 화면 결과 비교 도구를 만듭니다. README는 외부 Buildbot 배지와 Docker 이미지를 안내하지만, 이 커밋의 프로젝트 .github/에는 후원 설정만 있으며 GitHub Actions 워크플로는 없습니다. 서드파티 libpng의 워크플로를 mGBA 자체 CI 설정과 혼동하지 않아야 합니다.

4아키텍처 심화 분석

4-1. 시스템 전체를 한 장으로 보기

먼저 두 종류의 시간을 구분합시다. 가상 게임기의 시간은 CPU 사이클로 흐르고, 실제 컴퓨터의 시간은 화면 갱신과 오디오 장치의 소비 속도로 흐릅니다. 코어는 전자를 계산하고, 동기화 계층은 후자와 보조를 맞춥니다.

연결선은 주된 데이터·제어 경로를 요약합니다. BIOS와 게임 저장 파일은 각각 별도의 loadBIOS·loadSave 호출로 연결합니다. Libretro나 단순 예제까지 모두 같은 스레드 구성을 쓰는 것은 아닙니다. Qt 경로에서는 CoreController가 코어 스레드를 관리하고, src/core/thread.c의 _mCoreThreadRun()이 실행 상태에서 core->runLoop(core)를 반복합니다.

4-2. 설계 패턴 ① 함수표와 팩터리: C로 만드는 다형성

include/mgba/core/core.h의 struct mCore에는 init, runFrame, step, busRead32 같은 함수 포인터가 있습니다. 호출자는 같은 이름으로 요청하지만, 실제 실행되는 함수는 코어에 따라 달라집니다.

// src/gba/core.c: GBACoreCreate()의 함수표 연결 중 일부
core->init = _GBACoreInit;
core->reset = _GBACoreReset;
core->runFrame = _GBACoreRunFrame;
core->runLoop = _GBACoreRunLoop;
core->step = _GBACoreStep;

src/core/core.c의 _filters[]는 GBAIsROM과 GBACoreCreate, GBIsROM과 GBCoreCreate를 짝짓습니다. mCoreFindVF()는 판별 함수가 맞는 항목의 생성 함수를 호출합니다. 팩터리는 어떤 구현을 만들지 결정하고, 다형성은 만들어진 구현을 같은 방식으로 사용하는 성질입니다.

배울 점: C++의 상속 문법이 없어도 역할을 분리할 수 있습니다. 대신 함수표 초기화, 객체 수명, 포인터 형식의 일관성을 개발자가 책임져야 합니다. _GBACoreInit()과 _GBACoreDeinit()를 짝지어 읽으면 자원 소유권도 드러납니다.

4-3. 설계 패턴 ② 이산 이벤트: 다음 일이 생길 때까지 진행하기

src/arm/arm.c의 ARMStep()는 opcode의 비트를 뽑아 _armTable에서 실행 함수를 고릅니다. ThumbStep()는 _thumbTable[opcode >> 6]을 사용합니다. 명령어 실행으로 사이클이 누적되고, ARMRunLoop()는 cpu->cycles < cpu->nextEvent인 동안 진행합니다.

이벤트 시각에 닿으면 GBAProcessEvents()를 거쳐 mTimingTick()으로 넘어갑니다. mTimingSchedule()은 이벤트를 시각순 연결 리스트에 넣습니다. 시각이 같으면 priority 값이 작은 항목이 앞섭니다. 힙이나 OS 타이머를 쓰는 구현은 아닙니다.

# 스케줄러 규칙을 손으로 따라가는 예: 값은 학습용
현재 시각: 100
등록 순서: A(시각 130, 우선순위 8)
           B(시각 120, 우선순위 9)
           C(시각 130, 우선순위 3)
정렬 결과: B -> C -> A
시각 132에 처리: B는 12, C와 A는 2 사이클 늦음

mTimingTick()은 이미 지난 이벤트를 꺼내 콜백에 지연량을 넘깁니다. 영상 콜백 _startHblank()와 _startHdraw()는 다음 예약에서 cyclesLate를 뺍니다. 늦게 처리된 만큼 매번 다음 예약까지 밀리면 오차가 계속 쌓이므로 이를 보정하는 것입니다.

가상 시간을 정확히 계산하는 일과 실제 화면·소리의 재생 속도를 맞추는 일은 서로 다른 문제입니다. 이 구분이 있어야 빠른 감기, 일시정지, 디버깅을 넣어도 하드웨어의 내부 시간 관계를 설명할 수 있습니다.

4-4. 설계 패턴 ③ 어댑터: 파일의 출처를 숨기는 VFile

include/mgba-util/vfs.h의 VFile은 read, seek, map, close 등의 함수 포인터를 묶습니다. 디스크 파일, 메모리 블록, 압축 파일 내부 항목을 코어가 비슷한 방식으로 다루도록 하는 계약입니다.

// src/core/test/core.c의 findEmpty 테스트를 간추린 흐름
struct VFile* vf = VFileMemChunk(NULL, 0);
struct mCore* core = mCoreFindVF(vf);
// 빈 데이터이므로 ROM 판별 결과는 NULL이어야 합니다.
vf->close(vf);

src/core/core.c의 mCoreFind()는 압축 디렉터리를 열 수 있으면 내부 항목을 순회해 코어를 찾습니다. mCoreLoadFile()은 로딩이 실패하면 열린 ROM을 닫습니다. 단순히 파일 경로만 추상화한 것이 아니라, 열린 자원의 처리 책임까지 함께 읽어야 합니다.

배울 점: 파일을 메모리로 대체할 수 있으면 작은 테스트가 쉬워집니다. 네트워크·스토리지 코드를 배울 때도 실제 외부 서비스 없이 경계 조건을 확인하는 설계로 연결할 수 있습니다.

4-5. 설계 패턴 ④ 생산자·소비자: 오디오가 차면 코어도 기다린다

코어는 오디오 샘플을 생산하고, 실제 오디오 출력 쪽은 이를 소비합니다. src/util/audio-buffer.c는 mCircleBuffer 위에 샘플 버퍼를 만듭니다. mAudioBufferAvailable()은 바이트 수를 채널 수와 sizeof(int16_t)로 나누어 샘플 프레임 수로 바꿉니다.

src/core/sync.c의 mCoreSyncProduceAudio()는 동기화가 켜져 있고 버퍼가 상한 이상이면 조건 변수로 기다립니다. mCoreSyncConsumeAudio()는 소비 후 대기 중인 쪽을 깨웁니다. 초기 audioHighWater는 512이지만, 이것을 모든 환경의 지연 시간으로 환산해서는 안 됩니다.

// CoreController::updateFastForward()의 정상 속도 복귀 분기 일부
if (isChange) {
    mCoreSyncLockAudio(&m_threadContext.impl->sync);
    mAudioBufferClear(
        m_threadContext.core->getAudioBuffer(m_threadContext.core));
    mCoreSyncUnlockAudio(&m_threadContext.impl->sync);
}

커밋 fd9dc5c의 메시지는 빠른 감기 종료 시 쌓인 오디오로 잠깐 멈출 수 있던 문제를 설명합니다. 실제 코드도 src/platform/qt/CoreController.cpp에서 정상 속도 복귀 시 버퍼를 잠그고 비웁니다. 커밋 설명의 최대 약 500ms는 해당 문제의 맥락이며, 일반 사용 시 항상 그만큼 지연된다는 뜻은 아닙니다.

배울 점: 처리량이 높아도 오래된 결과가 큐에 남으면 반응성은 나빠집니다. 버퍼 용량만 늘리는 대신, 속도 전환 때 어떤 데이터를 버려도 되는지 결정하는 일이 필요합니다.

4-6. 명령 하나가 메모리와 화면으로 이어지는 경로

메모리는 하나의 거대한 배열로만 취급되지 않습니다. include/mgba/internal/gba/memory.h는 0x02000000을 EWRAM, 0x04000000을 I/O, 0x06000000을 VRAM, 0x08000000을 ROM 시작 주소로 정의합니다. 같은 읽기 명령도 주소에 따라 다른 하드웨어 규칙을 거칩니다.

영상 시각을 관리하는 코드와 픽셀을 만드는 렌더러도 나뉩니다. GBAVideoAssociateRenderer()가 렌더러를 연결하고, _GBACoreInit()는 더미·소프트웨어 렌더러와 조건부 GL 렌더러를 준비합니다. 화면 출력의 구현을 바꾸는 일과 CPU 명령을 바꾸는 일을 분리한 구조입니다.

4-7. 상태 저장은 화면 캡처보다 더 많은 것을 요구합니다

src/gba/serialize.c의 GBASerialize()는 버전·체크섬뿐 아니라 CPU 레지스터, prefetch, 현재 사이클 등도 기록합니다. GBADeserialize()는 버전, 게임 정보, 사이클 값 등의 일관성을 검사합니다.

화면이 같아도 다음 명령이나 예약된 이벤트가 다르면 이후 결과가 달라집니다. 영상 코드가 콜백 전에 상태를 일관되게 맞추라고 주석으로 강조하는 이유도 여기에 있습니다. 저장할 상태를 정의하는 일은 시스템의 실제 상태가 무엇인지 정의하는 일이기도 합니다.

주요 근거: 이벤트 스케줄러 · ARM 실행 루프 · Qt 코어 제어.

5디렉토리 구조 해부

5-1. 폴더 경계에서 읽을 수 있는 책임

5-2. 코드 규모: 외부 라이브러리를 빼고 보기

커밋 fd9dc5c의 해당 확장자 파일을 줄 단위로 집계한 값입니다. .git/과 src/third-party/는 제외하고 주석·빈 줄·테스트는 포함했습니다. 헤더는 C/C++가 공유하므로 별도 분류했습니다. 전체 파일 수나 실행 문장 수를 뜻하지 않습니다.

제외한 서드파티의 C만 따로 세면 397,425줄입니다. 이를 코어 구현량에 합치면 외부 라이브러리가 프로젝트의 자체 코드보다 크게 보일 수 있습니다. 규모를 비교할 때는 집계 범위를 먼저 맞추는 습관이 필요합니다.

6학습 포인트 (기술별)

6-1. C: 함수 포인터·수명·고정 폭 정수

struct mCore를 읽을 때는 함수 이름보다 인자와 반환형을 먼저 보세요. void (*step)(struct mCore*)는 코어 상태를 받아 한 단계를 진행하는 계약입니다. bool (*loadROM)(struct mCore*, struct VFile*)에는 실패 가능성과 열린 파일의 수명 문제가 함께 붙습니다.

명령어·레지스터·주소에는 uint32_t, 샘플에는 int16_t 같은 형식이 등장합니다. 데이터 폭이 곧 하드웨어 규칙이기 때문입니다. 포인터 주소 자체를 저장 파일에 쓰는 방식이 아니라, 복원할 값과 형식을 명시하는 방식에 주목하세요.

6-2. 컴퓨터 구조: 주소와 비트에 의미 붙이기

GBALoad32()는 address >> BASE_OFFSET으로 영역을 고릅니다. BASE_OFFSET은 24입니다. 주소의 상위 8비트가 어떤 장치를 가리키고, 아래 비트가 그 안의 위치를 뜻하는지 먼저 구분하세요.

# 주소 영역을 읽는 연습: 실제 장치 접근은 하지 않습니다.
0x02000000 >> 24 = 0x02   EWRAM
0x04000130 >> 24 = 0x04   I/O 영역
0x06000000 >> 24 = 0x06   VRAM
0x08000000 >> 24 = 0x08   ROM 영역

다음으로 비정렬 접근을 보세요. GBALoad32()의 마지막에는 주소 하위 비트로 회전량을 계산해 ROR(value, rotate)를 반환하는 코드가 있습니다. 호스트 언어의 자연스러운 배열 접근과 가상 CPU의 동작 규칙이 다를 수 있음을 보여 줍니다.

6-3. 자료구조와 시뮬레이션: 연결 리스트를 선택한 이유 생각하기

mTimingEvent 안에 next 포인터가 있어 이벤트 자신이 연결 리스트의 노드가 됩니다. mTimingSchedule()은 삽입 지점을 순회하므로 이벤트 수에 따라 비용이 늘어납니다. 매번 전용 노드를 새로 할당하지 않는 구성도 함께 읽을 수 있습니다.

이것이 모든 상황의 최적 선택이라는 뜻은 아닙니다. 하드웨어 이벤트 수가 작고 정해진 환경과, 수십만 작업이 등록되는 서버 환경은 다릅니다. 같은 규칙을 배열·최소 힙으로 표현하면 어떤 연산이 쉬워지는지 비교하는 것이 좋은 실습입니다.

6-4. 동시성·오디오: 숫자의 단위를 맞추기

mCoreSyncProduceAudio()의 대기 조건을 읽고, 버퍼 값의 단위부터 적어 보세요. 바이트 수, 채널별 값의 수, 샘플 프레임 수는 서로 다릅니다. mAudioResamplerProcess()에서는 sourceRate / destRate가 보간 위치의 증가량으로 쓰입니다.

손계산 연습: 가정한 출력이 48,000Hz·스테레오·16비트라면 100ms 분량은 48,000 × 0.1 × 2 × 2 = 19,200바이트입니다. 이는 단위 변환 예시이며, mGBA의 기본 출력 설정이나 측정 지연을 뜻하지 않습니다.

6-5. Qt·Lua·Python: 경계를 넘는 호출 이해하기

Qt의 CoreController는 UI에서 발생한 요청을 코어 실행·설정과 연결합니다. 빠른 감기 처리를 읽은 뒤에는 같은 클래스의 setFastForward(), setSync()를 찾아 버튼 상태와 실제 실행 설정이 어떻게 연결되는지 추적해 보세요.

Lua 쪽은 src/core/scripting.c가 코어 메서드를 공개 이름에 연결합니다. 예를 들어 C의 frameCounter는 스크립트에 currentFrame으로 노출됩니다. res/scripts/input-display.lua는 callbacks:add("frame", ...) 등록을 보여 줍니다.

-- 개발 버전의 바인딩을 바탕으로 만든 학습용 예제
local frames = 0
callbacks:add("frame", function()
    frames = frames + 1
    if frames % 60 == 0 then
        console:log("프레임: " .. emu:currentFrame())
    end
end)

60프레임마다 출력하는 예제이지, 정확히 1초마다 출력하는 시계는 아닙니다. 빠른 감기나 일시정지에서는 실제 경과 시간이 달라집니다. Lua 공식 매뉴얼은 언어 학습용이며, mGBA 내장 Lua 버전을 5.4로 고정한다는 뜻은 아닙니다.

Python은 src/platform/python/setup.py의 cffi_modules와 src/platform/python/_builder.py를 이어서 읽으세요. 패키지 설치 명령보다 먼저, C 함수와 Python 객체 사이에 어떤 형식·수명 변환이 필요한지 정리하면 좋습니다.

6-6. 테스트: 통과했다는 말의 범위를 구분하기

src/platform/test/cinema-main.c의 _compareImages()는 화면 차이를 비교합니다. 테스트 준비에서는 RTC_FAKE_EPOCH로 RTC의 기준 시각을 고정하고, 프레임 진행에 따라 시간을 계산해 실제 시계에 따른 변동을 줄입니다. 좋은 테스트를 설계하려면 결과뿐 아니라 결과를 만드는 입력·시간·상태도 고정해야 합니다.

7하드웨어 / 시스템 요구사항

7-1. 가상 GBA의 수치로 시간 감각 잡기

# 소스 상수로 계산한 가상 프레임 속도
1,232 × 228 = 280,896 사이클 / 프레임
16,777,216 ÷ 280,896 ≈ 59.7275 프레임 / 초

# 32비트 픽셀 버퍼 하나를 가정한 크기
240 × 160 × 4 = 153,600 바이트 = 150 KiB

픽셀 버퍼 계산은 32비트 출력의 예시이며 프로세스 전체 메모리 사용량이 아닙니다. GUI, ROM, 렌더러, 오디오 버퍼, 되감기 상태가 추가 공간을 차지합니다. 가상 CPU가 16.78MHz라고 해서 같은 주파수의 호스트 CPU면 충분하다는 뜻은 아닙니다.

7-2. 사용자 실행 환경: README와 배포물 조건을 함께 보기

README의 시스템 요구 설명에는 Vista급 컴퓨터라는 표현도 있으나, 지원 플랫폼 목록의 Windows 하한은 7입니다. 하드웨어 성능에 대한 대략적인 설명과 현재 지원 OS 목록을 같은 의미로 읽으면 안 됩니다. macOS도 Qt CMake 분기에서 Qt 5.15는 10.13, Qt 6은 SDK 조건에 따라 10.14·10.15를 설정합니다.

7-3. 개발 환경과 추가 자원

코어 학습에는 C11 컴파일러와 CMake 3.12 이상이 기준이며, Qt 프론트엔드는 C++14 환경도 필요합니다. Python 바인딩은 기본 빌드 대상이 아닙니다. 테스트·녹화·스크립트를 다룰 때 cmocka·FFmpeg·Lua 등의 선택 의존성이 추가됩니다.

첫 학습에서는 녹화·필터·되감기를 한꺼번에 켜기보다 기능별 자원 비용을 구분하세요. 이 자료의 수치는 소스의 상수와 구조에 근거하며, 특정 기기에서의 프레임 속도나 빌드 성공을 보장하지 않습니다.

8직접 해볼 수 있는 실습 과제

각 과제에는 남겨야 할 결과물을 정했습니다. 먼저 정적 추적과 손계산을 끝낸 뒤, 실행 환경이 준비된 경우 선택 실습으로 넓혀 보세요. 함수 이름을 찾는 데서 멈추지 말고, 입력·상태 변화·예상 결과를 한 묶음으로 설명해 보세요.

고급 확장으로는 cinema/gb/acid/config.ini의 skip=15, frames=1을 읽고, src/platform/test/cinema-main.c가 어떤 프레임부터 기준 화면과 비교하는지 추적할 수 있습니다. 기준 화면을 갱신하는 일과 구현 오류를 고치는 일을 구분하는 것이 핵심입니다.

9관련 기술 심화 학습 로드맵

C의 변수·반복문·함수·기본 포인터를 알고 있다는 전제입니다. 아직 포인터가 낯설다면 1주 차를 두 번 반복하세요. 매주 소스에서 읽은 규칙, 손으로 계산한 예, 자신의 말로 쓴 설명을 하나씩 남깁니다.

9-1. 관심 분야에 따라 갈라지는 다음 단계

• 시스템 프로그래밍: VFile의 메모리·파일 구현을 비교하고, 오류 처리와 자원 반환 책임을 추적합니다.
• 게임·그래픽: src/gba/renderers/에서 타일·스프라이트·레이어가 픽셀로 합쳐지는 경로를 읽습니다.
• 오디오: src/util/audio-resampler.c와 보간기를 읽고, 샘플률 변환과 버퍼 지연을 분리해 공부합니다.
• 개발 도구: 디버거의 중단점·메모리 관찰을 따라가며, 상태를 관찰하는 기능이 실행 흐름에 미치는 영향을 분석합니다.

전체 코드를 다 읽기보다 기능 하나가 여러 계층을 통과하는 경로를 완주하는 편이 설계를 이해하는 데 도움이 됩니다. 예를 들어 되감기를 골랐다면 상태 저장, 차이 계산, 큐 용량, 복원 시점까지 연결해 보세요.

10핵심 키워드 사전

용어를 기억하기 어렵다면 실제 식별자 하나와 묶으세요. 다형성은 mCore, 이벤트는 mTimingEvent, 파일 추상화는 VFile, 역압은 mCoreSyncProduceAudio()를 떠올리면 됩니다.

11참고 링크

11-1. 공식 저장소·문서·변경 기록

• mGBA 공식 저장소 — 코드·이슈·릴리스의 출발점입니다.
• mGBA 공식 사이트 — 배포물과 프로젝트 소식을 확인할 수 있습니다.
• 0.10.5 릴리스 — 개발 버전과 비교할 정식 릴리스 기준점입니다.
• README · 분석 커밋 기준 — 기능·지원 플랫폼·빌드 안내입니다.
• CHANGES — 0.11.0의 개발 변경 항목과 과거 변경 기록입니다.
• 명령줄 사용 설명서 · Qt 사용 설명서 — 저장소에 포함된 man 문서입니다.
• 기여 지침 · 이식 지침 — 프로젝트의 규칙과 플랫폼 경계를 읽는 자료입니다.

11-2. 핵심 소스와 관련 기술

• mCore 계약 · GBA 코어 연결 — 공통 함수표와 실제 구현의 대응입니다.
• 가상 시간 스케줄러 · 영상 이벤트 — 사이클과 콜백의 연결입니다.
• 오디오·영상 동기화 · 오디오 버퍼 — 생산자·소비자와 단위 변환의 근거입니다.
• 영상 회귀 검사 · GBA 상태 직렬화 — 결과 비교와 상태 일관성의 사례입니다.
• CMake 최소 버전 선언 — 루트 구성의 버전 조건을 이해하는 공식 문서입니다.
• Lua 5.4 공식 매뉴얼 — 함수·테이블·콜백을 익힐 때 참고하되 내장 엔진 버전은 별도로 확인하세요.
• VBA-M 공식 저장소 · SameBoy 공식 사이트 — 지원 기종과 프론트엔드 비교의 근거입니다.
• TrendShift — 저장소 관심 흐름을 살펴보는 사이트입니다.

현재 상태 (2026-10-23 확인)