본인은 내 연배 사람들의 평균 이상으로, 심지어 나보다 나이가 더 많은 사람들 이상으로 레트로 컴퓨팅에 관심이 많다. 그 이유는.. 글쎄, 그 시절 당대엔 너무 비싸서 만져 볼 엄두를 못 냈던 최신 최고급 최첨단 하드웨어와 소프트웨어들이 지금은 너무 값싸지고, 싸구려를 넘어 역사 속의 퇴물이 된 게 경이롭고 신기하게 느껴지기 때문인 것 같다.
어린 시절에 굶주림을 겪었던 기성세대들이 지금 이렇게 먹거리가 싸고 풍부해진 뒤에도 늘 절약하고 비상시를 생각하고 많이 쌓아 놓는 습관을 평생 못 버리는 편이라지 않는가?
그런 것처럼 본인은 어린 시절에 저런 식으로 최신 문물의 이기에 대한 욕구불만(?)을 겪었던 게 지금 이런 추억과 집착으로 표출되는 것 같다. 나 자신에 대해 스스로 생각해 보니 그렇게 느껴진다.
1. 메모리
16비트 컴퓨터는 8비트보다야 훨씬 더 풍족한 환경이다. 특히 한글· 한자 같은 복잡한 문자까지 실용적인 해상도로 표현할 수 있을 정도로 성능이 받쳐 주는 마지노 선이기도 하다. CPU 속도뿐만 아니라 메모리(폰트..)나 그래픽(해상도)에서도 말이다.
하지만 컴퓨터 성능이 좀 더 향상되자 16비트도 금세 한계를 보였다. 16비트는 그 특성상 가깝게는 64KB, 그리고 x86 PC 기준 거시적으로는 1MB / 640KB의 한계에 매여서 이걸 극복하느라 온갖 지저분하고 복잡한 편법이 동원되어야 한 암울한 환경이기도 했다.
세그먼트가 어떻고 메모리 모델이 어떻고 far 포인터가 어떻고..;; 그리고 EMS는 뭐고 XMS는 뭐냐. x86 PC 말고 다른 16비트 CPU 동네에서는 상황이 어땠는지 개인적으로 매우 궁금하다.
EMS는 뭔가 특수한 방법으로 접근하는 부가적인 메모리를 장착해서 1MB 이상의 물리 메모리를 확보하는 방식이었다. 글쎄, EMM386이라는 도스 드라이버 이름이 암시하는 것과는 달리, 얘가 XT 시절부터 먼저 등장했다.
그러다가 80286 CPU의 기능을 활용해서 XMS라는 규격이 추가로 등장했다. 얘가 진짜로 더 자연스럽고 직관적인 방식으로 주 메모리의 연장선상으로 메모리를 더 확장해 준다.
MS-DOS 5.0에서 himem.sys라는 드라이버가 추가됐는데 이건 그냥 이유 불문하고 필수 로딩 드라이버였다. 그리고 DOS=HIGH니 LOADHIGH (LH)니, 뭔가 HI/HIGH가 붙은 게 그야말로 640KB 기본 메모리를 확보하기 위한 마법의 주문인 것처럼 컴퓨터 잡지에서 소개되곤 했다.
1MB 이상 메모리를 확보하는 것 자체는 가능했지만 현실에서 컴퓨터가 정보를 직통으로 취급하는 최소 단위는 여전히 64KB였고, 그나마도 접근성이 제일 좋은 영역은 1MB에서 그나마 384KB를 떼어낸 하위 640KB였기 때문이다. 뭐가 이리 복잡해..
정리하자면 EMS가 먼저 등장했고, 그 다음이 XMS이다. EMS는 확장 메모리를 반쯤 파일처럼 취급하는 방식인 반면, XMS에서는 같은 16비트이지만 286 CPU의 기능을 활용해서 확장 메모리에 CPU가 직통 접근 가능해졌다. 그리고 기존 도스용 프로그램이나 드라이버를 640KB 이후의 상위 영역에다가 올려 놓는 기법도 XMS와 함께 등장했다.
메모리 운용 방식이 까탈맞은 게임 중에서는 emm386 구동 절대 금지, 또는 반대로 EMS 필수.. 이러는 경우가 있었다. 이러니 config.sys 내용이 걸레짝처럼 복잡해질 수밖에 없었다. 도스 6.0에서는 멀티부팅이라는 기능까지 등장했고 말이다.
물론 어떤 경우에든 640KB 이전 기본 메모리를 최대한 많이 확보해 놓는 건 필수였다. 이게 마치 Windows 3.x 리소스 퍼센티지와 비슷한 개념이었다. 부팅 직후에 580~600KB 정도 남아 있으면 최적화를 아주 잘 한 것이었는데.. 한글 바이오스, 씨디롬, 디스크 캐시 같은 것들을 띄우다 보면 메모리가 금세 뚝뚝 줄어들었다.
이런 복잡한 메모리 삽질은 386 이상 CPU에서 제공하는 보호 모드, 가상 메모리 기능과 함께 역사 속으로 사라졌다. DPMI는 EMS/XMS 따위보다 더 상위 기술을 명시하는 규격이다. 32비트 도스 extender가 그 시절엔 정말 구세주 소리를 듣지 않을 수 없었다. 1990년 중반대의 도스용 게임을 실행할 때 DOS/4G 시그널이 뜨는 게 정말 간지 그 자체였다. ^^
2. 도스용 디바이스 드라이버(sys)
도스 시절에는 컴퓨터에 어떤 하드웨어를 인식시키기 위해서 해당 장치의 드라이버를 실행해서 올리는 절차가 있었다. config.sys라는 시작 스크립트에다가 DEVICE=어쩌구저쩌구 드라이버 파일 경로를 지정해 주면 됐다. 이건 무려 MS-DOS 2.0 시절부터 있었던 전통이라고 한다.
여기서 개인적으로 의문이 들었다. DEVICE로 로딩되는 *.sys 드라이버들은 분명 컴파일된 기계어 코드가 들어있는 실행 파일의 특수한 형태일 텐데.. 얘는 어떻게 만드는 걸까?
옛날 자료를 뒤져 보니 1980년대에 MS C 4.0 (!!! Visual C++ 4가 아님!)과 매크로 어셈블러를 써서 빌드하고 만든 경우가 있었다고 한다. ㄲㄲㄲㄲㄲㄲ
com과 비슷한데 그래도 자그마한 헤더가 들어있으며, 나름 한 sys 파일 안에 2개 이상 여러 드라이버가 있을 수도 있었나 보다.
config.sys는 부팅 때 단 한 번만 실행됐다. 부팅이 끝난 뒤에 얘들을 다시 실행하거나, 실행된 디바이스 드라이버를 제거할 수 없었다. 그러니 다루기가 좀 불편하다.
그 시절엔 부팅 후에 sys 파일을 실행해 주는 별도의 유틸리티가 있었다. 얘는 어떤 원리로 동작했는지 모르겠다만, 개인적으로 유용하게 썼던 기억이 남아 있다.
그리고 시스템을 건드리는 유틸이 처음엔 sys 형태로 개발되었지만 나중에 exe 형태로 바뀐 경우도 종종 있었다.
emm386 드라이버가 대표적인 예이고(DOS 4.0에서는 sys, 5.0 이후부터 exe), 디스크 캐시라든가 램 드라이브, 각종 한글 바이오스 소프트웨어도 1980년대엔 sys이다가 나중에 com/exe 기반의 램 상주 프로그램으로 바뀌었다.
마우스 드라이버는 sys였던 적이 없이 전통적으로 mouse.com이었던 것 같고..;; 그때는 msherc나 simcga처럼 그래픽 카드를 흉내 내는 램 상주 드라이버도 있었다.
나중에 Windows 9x 시절에는 vxd라는 드라이버가 있었는데 NT 계열부터는 소리 소문 없이 사라졌다.
도스용 아래아한글이나 이야기(PC통신!!)에서 쓰였던 덧실행 프로그램도 뭔가 특수하게 빌드된 프로그램이지 싶은데..
이렇게 기계어 코드를 생성하는 계층이랑, 껍데기 실행 파일을 생성하는 계층이 같지 않으니 컴파일러와 링커의 계층이 구분되었던 것 같다. 마치 압축 알고리즘과 컨테이너 구조의 차이와 비슷하다.
3. PC 스피커로 현실 사운드 흉내 내기
오늘날 우리가 사용하는 PC의 원조인 IBM PC라는 건 원래 업무용으로 개발됐다. 이 때문에 그래픽이나 사운드 쪽 지원은 원가 절감을 위해 우선순위에서 밀렸으며, 당대의 타 컴퓨터들에 비해 스펙이 뒤쳐졌다.
그래픽이야 초창기 CGA니 EGA니 하던 IBM 보급품이 얼마나 열악했는지는 더 설명이 필요하지 않고.. 사운드도 상황이 다르지 않았다. PC 스피커라고 불리던 IBM 보급품은 그냥 삑삑 띡띡거리면서(beep) 오류가 발생했을 때 최소한의 자기 상태만 청각 피드백으로 전달할 수 있는 정말 원시적인 물건이었다.
자연에서 발생하는 소리는 아무래도 부드러운 삼각함수 곡선의 합성으로 표현된다. 허나, 이 PC 스피커는 얼마나 단순했으면 생성 가능한 소리의 파형이 최대값 아니면 최소값으로 이산적-_-이었다. 음량을 나타내는 진폭조차 조절이 안 되고.. 진짜 그 특유의 날카롭고 투박한 비프음밖에 내지 못한 것이다. 자연스러운 삼각함수이면 소리굽쇠나 전화기 신호음 비슷한 소리라도 났을 텐데, 그렇지도 않다. ^^
그런데 1980년대 말에는 RealSound라고 PC 스피커를 극한까지 튜닝해서 얘만으로 최소한 단음 멜로디보다는 더 정교한 소리를 내는 기법이 개발되어 쓰였다고 한다. 단순투박한 비프음이라도 다양한 주파수로 아주 잘게 쪼개고, 이것들을 합성해서 또 다른 소리를 만들어 내는 거다. 이미지에서 디더링의 사운드 버전이나 마찬가지다.
이렇게 해서 표현 가능한 음질은 채널은 당연히 모노 한정이고, sampling rate는 11khz와 22khz의 중간인 18khz 남짓이었다고 한다. 그 시절 컴퓨터 사양을 감안하면 나쁘지 않았다.
다만, 문제는 표현 가능한 음색이랄까 이거 구분이 6비트밖에 안 됐다는 거..
아까 오리지날 PC 스피커는 최대값 아니면 최소값 2단계뿐이니 1비트인데, 이걸 딱 32배까지 늘리는 게 한계였다.
실용적인 사운드 카드에서는 최저 음질이 8비트부터(256) 시작이고 CD급 음질이라면 16비트가 보통인데 6비트는 확실히 자연스러운 소리를 재현하기에는 부족한 음질이었다.
이걸로 청취 가능한 사람 목소리를 낼 수는 있었다. 하지만 칙칙한 금속 기계음이 섞인 저음 남자 목소리 정도나 내며, 유선 전화기보다도 음질이 안 좋았다. 그냥 전용 사운드 카드로 음질 더 좋은 사운드를 내보내는 것보다 CPU에 걸리는 부하도 더 컸을 것이다.
하지만 비싼 사운드 카드 없이 보급 PC 스피커만으로 삑삑 단음이 아니라 사람 목소리 비스무리한 거, 툭툭 소리, 비트가 가미된 테크노 BGM이 흘러나오는 것만으로도 어디냐. (☞ 예시 1 / 예시 2)
PC 스피커로 사운드 카드 흉내를 내는 기술은 소수의 게임이나 유틸에서 알음알음 전수되어 쓰였던 것 같다. 그래픽 분야로 치면 VGA mode X라든가 CGA 160*100 16컬러 같은 꼼수와 비슷해 보인다.
4. 텍스트 모드 폰트
1980년대에 PC의 그래픽 카드는 CGA, EGA를 거쳐 VGA로 업그레이드 됐다. 그 과정을 거치면서 그래픽 모드의 해상도가 올라가고 지원되는 색깔 수가 늘었다.
덕분에 그래픽이 아닌 텍스트 모드에서도 자그마한 8*8 폰트를 동원해서 종전의 25줄이 아니라 43/50줄을 표시할 수 있게 됐다.
하긴, 요즘이야 큼직한 화면에서 70~80줄도 한번에 보면서 코딩을 하는데.. 꼴랑 25줄은 화면이 작아도 너무 작다.;;;
이렇게 색깔과 해상도가 올라간 거야 수긍이 가는 변화인데, 이것 말고 EGA/VGA가 과거의 CGA에 비해 향상된 게 더 있었다. 바로 텍스트의 폰트를 customize할 수 있게 된 것이다.
CGA에서는 그 알량한 폰트가 ROM에 박혀 있었던 반면, EGA/VGA에서는 이게 가변적인 RAM 영역으로 옮겨졌다. 정확하게는 자기네 ROM으로부터의 복사본이겠지만..
이 덕분에 몇몇 창의적인 프로그램들은 비록 텍스트 모드에서 돌아가지만 128번 이후의 특수문자들을 마개조해서 GUI 비주얼을 얼추 구현할 수 있었다. 도스용 Norton 유틸리티가 대표적인 예다.
체크나 라디오 버튼, 스크롤바 버튼을 그럴싸하게 그려 넣는 건 기본이고, 더 압권인 건 마우스 포인터까지 그래픽 모드처럼 구현했다는 것이다. 당장 위의 스샷을 보시라~! 지금 저건 텍스트 모드인데도 말이다!!
마우스 포인터가 차지하는 4개 영역에는 기존 문자에다가 마우스 포인터를 위치별로 합성한 4개 문자를 실시간으로 생성해서 그때 그때 바꿔 준 것이다. 이게 그 당시 하드웨어로 어떻게 가능했는지 모르겠다.;;
이런 비디오 마개조는 한글 바이오스 같은 프로그램과는 당연히 상극이었기 때문에 같이 사용할 수 없었다. 그러고 보니..
- VGA에서 텍스트 모드의 해상도는 640*400이 아니라 720*400이었다. 폰트는 8*16 것을 쓰지만 글자 사이에 1픽셀 여백이 있었다. 단지, 몇몇 선문자는 예외적으로 그 여백 부분까지 픽셀을 채웠기 때문에 선이 한데 이어져서 보였을 뿐이다.
- VGA 텍스트 모드에서는 글자색은 16개가 지원됐지만 배경색은 기본적으로 어두운 계열 8개만 지원됐다. 그러고 글자색을 깜빡거리게 하든지, 아니면 깜빡이지 않는 대신 밝은 계열 배경색 8개를 추가로 사용할지를 무슨 API를 통해 지정할 수 있었다. 참 신기한 형태의 설계이다.
- VGA가 아니라 모노크롬 MDA 시절에는 색깔이 없는 대신 글자에 진하게, 밑줄 같은 속성을 줄 수 있었고..ㄷㄷㄷ
- 그런데 개인적으로 텍스트 모드에서 이런 색깔 장난질을 할 수 있었던 언어는 베이식밖에 없었다. C/파스칼엔 텍스트 색깔 지정과 관련된 표준 API가 없었기 때문이다. (3rd party 라이브러리를 써야..)
Posted by 사무엘
