2026년 10월 12일 월요일

21세기 DOS 프로그래밍 #3 - DOS2 뱅킹

디스크롬의 뱅킹을 얘기하려는 것은 아니구요.

확장 BIOS로 지원되는 메모리매퍼의 뱅킹 이야기입니다~


메모리매퍼 세그먼트는 16KB입니다.

저의 프로그램에서 원하는 뱅킹은 Page 0,1의 32KB 영역입니다.


프로그래밍을 안해보셨으면 text, data, bss 등의 단어가 생소하실 수도 있는데요.

대충 보고 넘어가셔도 괜찮습니다요 ㅎ.ㅎ


메모리맵은 이런식으로 구성됩니다.

0000H ~ 00FFH = DOS2 Zero page

0100H ~ 7FFFH = text + data + bss + local heap

8000H ~ 93FFH = Mapper table, Banking stack, ISR 등의 Helper area

9400H ~ FFFFH = global var. + global bss + global heap + WORKAREA


전역변수(global var.)는 MAP파일에서는 comm으로 표시됩니다.

여러 뱅크에서 공통으로 접근하는 변수들을 쓸 때 필요합니다.


뱅킹 영역(0000H ~ 7FFFH)은 시스템 메모리매퍼 세그먼트 2개를 묶어서 사용합니다.

메모리매퍼 최대용량(4080KB)에서 127개의 뱅크를 사용할 수 있습니다.


프로그램 내에서 사용되는 뱅크번호는 논리(logical) 세그먼트가 되겠구요.

프로그램 로더는 필요한 용량만큼 실제 세그먼트를 할당 받아서 논리 뱅크와 연결합니다.

로더는 뱅크 0번으로 고정되고 실행파일(*.COM)으로 빌드됩니다.

나머지 뱅크들은 빌드 후 하나의 파일(*.OVL)로 묶여집니다.


malloc() 등의 heap을 사용하는 경우는 뱅킹 영역의 local heap이 사용됩니다.

bl_malloc() 등의 함수를 쓰면 global heap을 할당 받을 수 있습니다.

여러 뱅크에서 전역으로 접근이 필요한 경우에 쓰면 됩니다.


유저 ISR 루틴도 뱅킹이 지원됩니다.

따라서 외부 인터럽트, VDP H-Blank, V-Blank 등의 루틴을 여러 뱅크에 나눠 놓을 수 있어요.


뱅킹과 상관없이 매퍼 세그먼트를 이용하여, 대용량의 메모리를 할당할 수 있습니다.

bl_lmem_alloc() 등의 함수로 이루어져있습니다.

큰 데이터를 한번에 로딩할 때 쓰면 되겠습니다. (예: IMS 플레이어 등)


그 외,

시스템의 세그먼트가 부족한 경우는 특정 뱅크를 동적으로 로딩할 수도 있습니다.

설계 초기에는 디스크의 스왑파일(*.SWP)로 가상 메모리를 쓰는 것도 고려했는데,

거북이 MSX를 달팽이 속도로 만들 이유는 없어서, 가상 메모리는 제외되었어요 ㅎ.ㅎ


HI-TECH C 자체는 일반 CP/M의 TPA(64KB) 영역만 쓰는 프로그램만 컴파일이 가능합니다.

이걸 소스 파일을 뱅크로 나눠서 빌드 후 뱅킹 함수로 연결 하거나,

전역 변수를 처리 등의 부가 작업은 별도의 툴을 제작해서 썼습니다.


전체 툴체인은 로컬 git으로만 작업 후 릴리스 파일만 파라동 자료실에 올렸었는데요.

나중에는 귀찮아서 github에 그대로 올려버렸습니다. 흐...

아마 살짝 써보신 분들도 계실 듯요. 아래 링크는 참고만 하셔요 ㅎ.ㅎ

https://github.com/sharksym/CPMEMU_HI-TECH_C


그럼, 다음 편에서 이어집니다요~


2026년 10월 11일 일요일

New MSX와 CPU 성능의 중요성

조용한 일요일 오후입니다. 밥먹고 잠깐 글을 적어봅니다요 ㅎ.ㅎ


국딩 때 아이큐2000의 화려한 그래픽과 VDP 커맨드를 보며, 이런 생각을 해보셨을 겁니다.

'MSX2의 VDP는 너무 느려!', '게임 만들기에는 VDP가 병목이구나!'

이런 생각이요. 사실 저도 그랬어요 ㅎ.ㅎ


어른이 되고 학교에서 전자공학, 컴퓨터 구조 등의 공부를 하게 되니 알게 되더라구요.

본체를 저가로 만들려면 낮은 CPU 클럭을 써야했는지를요.

주변 기기들도 낮은 클럭(느린 속도)으로 동작하는 싸구려 칩, 회로를 쓸 수 있어서 그렇거든요.


Z80, MOS 6502 같은 70년대 CPU를 쓰는 컴퓨터는 주변 장치(램, 롬, I/O 칩 등)의 속도도 고려해야 했습니다.

예를 들어 저가 컴퓨터의 대표 MSX의 3.58MHz, 애플II의 1MHz도 그걸 벗어나지 못했죠.

참고로 Z80의 메모리 사이클은 T3이구요, I/O 사이클은 T4입니다.

6502 계열은 메모리 사이클이 T1으로 끝이죠.


클럭효율이 대략 3.5배니까, 6502 1MHz랑 Z80 3.5MHz 동급이라고 보면 되겠습니다.

그래서 애플II랑 MSX는 CPU 성능이 비슷하다는 얘기가 있었지요.


근데 MSX2는 위치가 애매합니다.

1983년의 MSX는 Z80 성능에 딱 맞는 VDP, PSG 등으로 저가형으로 잘 맞췄는데요.

MSX2는 기존 MSX 주변기기의 호환성을 유지한다는 목적으로, Z80 3.58MHz 설계를 그대로 둡니다.

함께 개발된 V9938도 TMS9918 I/O 호환성을 그대로 갖고 있어요. 게다가 디스플레이 출력도 240p, 480i 등으로 똑같죠.


참고로 VDP의 I/O는 Z80의 OTIR, INIR 같은 I/O 전송에 딱 맞는 구조입니다.

심지어 OTIR을 OUTI x N개로 언롤링한 코드도 제속도로 동작합니다요.

그러니까 VDP의 VRAM 액세스가 느리다거나, 병목이 된다는 얘기는 잘못된 얘기라는 거죠.

물론 turboR에서 VDP가 병목이 된다는 얘기는 완전히 틀린 말은 아니지만...

다른 칩들도 모두 느린 I/O에 맞춰져 있어요. 그렇게 보면 주변 애들이 전부 병목이라는 소리입니다.

VRAM 데이터가 용량이 크니까 V9938 혼자서 매를 다 맞고 있는 느낌? ㅋ


스크린2의 VRAM 데이터는 다 합쳐봐야 12KB + 패턴네임 768바이트인데요.

Z80으로 초당 3KB 전송이니까, 전체 데이터를 한번에 변경해도 초당 15프레임이 나옵니다.

게임에서 패턴네임만 변경하는 거라면, 60fps으로 처리해도 CPU 로드가 25%면 충분합니다.

그래서 MSX1 전용 게임들이 죄다 60프레임으로 부드럽게~


MSX2 설계 시점에서의 문제라면...

기존 MSX 호환에 가격은 안비싸게 멀티미디어 성능을 높인다. 이거겠죠?

이게 당시 엔지니어들이 머리를 쥐어뜯으며 맞춘 설계인데요.

V9938의 경우는 DRAM 가격을 생각하면, 128KB를 넣어서 스크린8을 구성해준 것도 감사를~ ㅎ.ㅎ


스크린8의 비트맵 한장이 53KB니까, 화면 전체를 업데이트한다면 3fps짜리 게임을 만들 수 있겠죠.

스크린5라면 6fps가 되겠구요 ㅎ.ㅎ

아이큐2000을 보면서 VDP 성능에 한탄했던 국딩들(저도 포함이요)은,

자기들이 바라던 성능의 MSX2는 i386에 EGA 그래픽이 달린 컴퓨터였다는 걸 몰랐을 겁니다ㅋ


그냥 Z80 7.16MHz를 넣고, 본체 내장 칩들도 다 바꾸고, SLOT 클럭도 두배로 갔으면 어땠을까요?

참고로 turboR의 R800은 MSX2 Z80의 대략 8배 빠릅니다만,

기존 주변기기 호환성(BUS 속도) 때문에 실제로는 MSX2의 5배 정도의 성능이 나와요.

만약 호환성 포기하고 주변기기도 다 새로 만들도록 했다면 기본이 8배 성능이라는 얘기입니다.


여담이지만, SLT-Turbo V2를 Z80 28.6MHz로 만들다가 포기하고 클럭은 낮춘 이유가...

기존 주변기기인 SLT-X, PAC-V, 사운드 기기 등의 호환성 문제 때문이었죠.


설계하는 입장에서는 이지선다겠죠.

A) 주변장치 호환을 포기하고, CPU 및 BUS 클럭을 올려서 새로운 MSX를 만들기

B) 명령어 사이클이 빠른 CPU를 써서, 반쪽짜리 고성능 MSX를 만들기

C) B)에 기능이 향상된 주변기기용 칩을 내장


A는 현실적으로 불가능합니다. 기존 주변기기 호환을 버릴 수 없는 상태니까요.

B는 turboR에서 현실이 됐지만, 이것도 일부 S/W 호환성을 포기한 결과입니다. 그래서 카세트 인터페이스가 없죠.


C가 중요한데요. OPL3, V9978가 들어갔으면 좋았겠지만 세상에 나오진 않았죠 ㅎ.ㅎ

지금까지도 V9978 (이후의 V9990) 얘기를 하는 것도, VDP의 듀얼 레이어, 스프라이트 개수 때문인데요.

다들 게임 성능에만 관심이 있어서ㅋㅋ


만약 MSX를 Z80 7.16MHz로 만들었다면, 이후에도 호환성을 유지하고 쓸만한 성능의 MSX2,2+를 볼 수 있었을 듯.

MSX가 비싸서 안팔렸으면, MSX2도 못 본다는 게 함정이지만요 ㅎ.ㅎ


게임 얘기가 나왔으니 하나 더 적어보자면요.

구닥다리 8비트 CPU에 고성능 VDP를 장착한 게임기가 있었습니다. PC엔진이요.

근데요 그 PC엔진의 CPU가 HuC6280 7.16MHz입니다. 6502기반의 고클럭 CPU죠.

Z80으로 비교하자면 3.5배 클럭으로 계산할 수 있으니까... Z80 25MHz 성능이라는 얘기입니다.

CPU가 느려도 VDP만 빠르면 게임을 만들 수 있지않느냐? 라고 생각하시는 분이 계실텐데요.

CPU랑 BUS가 빠르면, 그래픽 성능이 형편없어도(예: 386, 486 PC) 빠른 게임을 만들 수 있는데요.

반대로 느린 시스템에 아무리 좋은 VDP가 있어도 꽝입니다요. i3-2100에 RTX 5090을 달아놓은 느낌이죠.


.

.

.


글이 길어졌지만, 원래 글을 쓰게 된 이유는 그냥 CPU, 주변기기 칩 때문은 아니었구요.

다른 분들과 '새로운 MSX'에 대한 얘기를 하다보면, 방향이 상반되는 경우가 있어서 글을 한번 써보았습니다요.

물론 제 말이 100% 맞다는 건 아닙니다 ㅎ.ㅎ


만약 제가 새로운 MSX를 만들어야 한다면,

주변장치 호환을 포기하구요. MSX3처럼 "기존 S/W만 에뮬레이션 + 새로운 고성능 주변기기 내장"하는 게 정답입니다.

니시도 20년 넘게 똑같이 외치고 있지만, 상업성이 없는 'New MSX'를 만들겠다는 회사가 어딨겠어요?

집에 널린 구형 노트북에 blueMSX, openMSX 같은 에뮬도 돌아가고, 인터넷, 유투브 등등 다 되는데 말이죠.


게다가 기존에 나왔던 H/W, 예를 들어 OPL4, V9990 같은 외장 카트리지를 호환해야 한다면?

이것도 에뮬에 내장하는 게 더 의미가 있다고 보니다.

외장 H/W 호환성을 유지하려면, 아무리 발악해도 turboR 수준으로 밖에 못 만들어요.

호환성 문제가 지난 25년을 그림자처럼 따라다니고 있습니다요.


즐거운 오후되셔요~ ㅎ.ㅎ/


2026년 10월 10일 토요일

21세기 DOS 프로그래밍 #2 - HI-TECH C

2003년 MSX에서 쓸 수 있는 C 컴파일러를 찾아보니 너댓개 정도 나오더라구요.

MSX-C, z88dk, HI-TECH C 등.


일단 MSX-C는 구닥다리 K&R 스타일이라서 그닥 관심이 없었는데요.

DOS2 전용 버전도 파일 입출력만 겨우 구현된 거라서 딱히 장점은 없었습니다.


이리저리 살피다가 결국 CP/M용 HI-TECH C를 선택했습니다.

89년에 나온 v3.09 버전인데, 이게 일단 ANSI C입니다.

나중에 제작사가 퍼블릭으로 풀어버렸더라구요. (이미 CP/M이 시장에서 사라졌)

사후지원을 안하는 대신 라이브러리는 소스로 포함해줬네요.

CP/M보다는 DOS/DOS2쪽으로 개발하는 게 목적이라서, 제게 딱 맞는 툴이었습니다 ㅎ.ㅎ


테스트 해보니,

스택의 로컬 변수 접근은 IX, IY 레지스터를 사용하는 방식이었구요.

라이브러리는 CP/M 스타일의 레코드 단위(128바이트) 처리라서 MSX에서는 손해를 보는 구조.

옵티마이저는 근거리 JR 선택해주는 기능 뿐이라서, 이건 버리고 따로 툴을 만들면 되겠더라구요.


컴파일러를 구동하는 환경은 처음에는 paraMSX를 이용했습니다.

에뮬의 CPU 속도를 올리면 그럭저럭 쓸만했어요.


나중에는 윈도용 에뮬레이터인 CP/M EXEcutor를 이용했습니다.

윈도의 폴더를 CP/M의 드라이브로 매핑해주는 기능이 있어서, make나 기타 툴을 사용할 때도 좋았죠.


최종 목표는

- DOS2 메모리매퍼

- R800 최적화

- 비트맵 그래픽 및 각종 사운드

등의 구현입니다.


MSX의 BDOS는

CP/M 2.2의 기본 호환에 MSX-DOS 전용 콜을 덧붙인 모습이구요.

이후 MSX-DOS2가 나오면서 전용 콜이 추가되었죠.

전체적으로 구버전의 MS-DOS랑 비슷합니다.


1차 목표는,

당시 MMC/SD 개발 관련으로 필요한 것들로 선정했습니다.

- 실행중인 DOS 버전에 따른 BDOS 콜 처리 (DOS2의 파일 핸들러가 더 좋죠)

- VDP 기본 기능 (VRAM R/W 등)

- SLOT R/W


ATLOAD -> 플래쉬롬 다운로더

DISKMAN, FLASHMAN -> MMC/SD 툴

MPXP -> MPX용 MP3 플레이어

등의 필요한 프로그램들을 하나씩 만들었네요.


당시 MMC/SD V1, V2 관련 툴은 기본 사양을 DOS용으로 만들어야해서 많이 힘들었어요.

램 64KB의 압박 ㅎ.ㅎ


2008년 MMC/SD V2.2 때, 많은 분들이 램을 늘려서 DOS2를 쓰게 됩니다.

'램은 기본 512KB로 늘리세요', 'DOS2가 좋아요', '터보알 ST는 램업 안하면 무쓸모'

등의 잡설로 제가 좀 압박을 했었지요ㅋ


2003년 ~ 2008년은 주로 MSX-DOS 프로그램을 만들게 되었네요.


그럼, 다음 편에서 이어집니다요~