한글 폰트 둘 자리 만들기

가나 250자면 되던 게 완성형 한글은 1,000자 안팎이 필요하다. 「메모리가 없다」는 결론에 도달했다면 대개 아직 안 본 자리가 남아 있다.

스킬 이름
msx-font-memory
먼저 볼 것
렌더러가 글자당 블릿하는가
실전 사례
골베리우스II · FF · 룬워스
가장 흔한 오판 둘
「VRAM 은 4bpp 라 글리프당 50바이트다」
틀렸다. VRAM 은 그냥 메모리다. 폰트를 1bpp 그대로 넣어 두고, 출력할 때만 훅이 읽어 4bpp 로 펼쳐 전송하면 된다.

저장 방식 9×10 한 자 1,043자
VRAM 에 4bpp 로 펼쳐 둠 50 B 52 KB
1bpp, 행당 2바이트 20 B 20.4 KB
1bpp, 비트 밀착 패킹 11.3 B 11.5 KB
폭이 8을 넘으면 행당 2바이트는 7비트를 버린다. 90비트를 연속으로 밀착시키면 44%가 줄어든다. 먼저 이것부터 한다.

「0이 아니면 사용 중이다」
틀렸다. VRAM 덤프에서 0이 아닌 바이트는 대부분 예전에 쓰다 남은 찌꺼기다. 반대로 0으로 보여도 게임이 매 프레임 다시 쓰는 곳일 수 있다. 반드시 마커 실측으로 판정한다.

먼저 이것부터 — 슬롯 하나면 되는 경우가 많다
상주 통짜 아틀라스는 함정이다
두 프로젝트가 독립적으로 같은 결론에 도달했다. 둘 다 「전체 글리프 상주」를 먼저 시도했다가 폐기하고 동적 글리프 주입으로 갈아탔다.

텍스트 루프를 역어셈블해서 글자마다 곧바로 화면 VRAM 으로 퍼가는 모양이면, 그리기 호출이 끝난 글리프는 이미 화면에 있으므로 슬롯을 즉시 재사용할 수 있다. 한 페이지에 고유 음절이 300자든 예약 슬롯은 1~2칸이면 된다.

훅 구조 — 새 렌더러를 만들지 말고 엔진을 속인다
훅: 글자코드를 받는다
한글인가?
아니오 → 그대로 통과 (원본 글리프가 그려진다)
예 → ① 마스터 폰트에서 글리프를 읽어
② 1bpp → 4bpp 언팩
③ 예약 슬롯에 심고
④ A = 슬롯코드 로 리턴
게임 자신의 블릿이 그 슬롯을 화면에 그린다
좌표 계산·블릿·줄바꿈은 전부 원본 코드를 그대로 쓴다. VRAM 안전지대 충돌 문제가 소멸한다.

실전에서 데인 것
DI 는 뱅크 전환 순간만. 언팩 루프를 통째로 감싸면 라인 인터럽트가 굶어 화면 상단에 검은 줄이 생기거나 HUD 가 깨진다.
예약 슬롯을 그래픽 타일과 겹치게 잡지 마라. 폰트 시트 칸 대부분이 UI(테두리·게이지·아이콘)다.
프린트 루프가 하나가 아닐 수 있다. 한 루프에만 제어코드 분기가 있어서 적재코드가 렌더러로 넘어가 빈칸으로 찍힌 적이 있다. 모든 진입점을 전수조사한다.
자리를 찾는 순서
VRAM 화면 밖 — SCREEN5 는 페이지당 256줄인데 화면은 212줄만 쓴다. 페이지마다 44줄 × 128B = 5,632B. 4페이지면 22KB. 여기부터 뒤진다.
표시하지 않는 페이지 — 표시 페이지가 고정이면 나머지 페이지는 화면에 영향이 없다.
원본 폰트 자리 — 한글화하면 가나·한자 글리프가 통째로 필요 없어진다.
여유 RAM — 「대충 4KB 비었다」로 세지 마라.
매퍼 세그먼트 — 64KB 호환을 포기하는 결정이므로 마지막에 검토한다.
번역으로 회수되는 공간 — 한국어는 일본어보다 짧다. 실측 11% 절약.
여유 RAM 은 반드시 실측한다
룬워스에서 0xE000~0xEFFF 4KB 로 잡았다가 실측에서 1KB 로 줄었다. 0xEE00 부터 BIOS 매퍼 지원 루틴이 앉아 있었고, 중간에도 더럽혀진 페이지가 있었다. 최종 결과는 512B + 두 조각.

64KB 기종을 포기하지 마라
매퍼를 쓰기로 하면 「64KB 기종은 확장슬롯을 전수 조사해야 한다」고 설계하기 쉽다. 그럴 필요가 없다. BIOS 가 부팅 때 가장 큰 매퍼를 메인 RAM 으로 채택하므로, 램 카트리지를 꽂으면 그것이 곧 메인 RAM 이 된다.

구성 페이지 RAM 슬롯 세그먼트4
64KB 단독 슬롯3 (내장) 없음
64KB + 램카트 슬롯1 (카트리지) 있음
512KB 본체 슬롯3 (내장) 있음
즉 128KB 본체든 64KB+램카트든 경로가 하나로 합쳐진다. 글자마다 도는 훅에서 슬롯 전환이 사라진다.