재미있기도 하지만 OCM 클론에서 이상하게 동작하는 MSX BASIC 프로그램 - 뿌띠 까미용 (PUTTY CAMIYON)

예전 잡지 '컴퓨터학습' 1988년 8월호의 '소프트웨어 뱅크' 코너에 '뿌띠 까미용'으로 공개되었던 MSX BASIC 프로그램이다(코드 뒷쪽에 주석으로 'original', 'remaking' 같은 문구가 있는 것으로 보아 원작이 있는 소스 코드의 개정판으로 보인다). 프로그램된 게임은, 낙하하는 비행기를 전후로만 조종하여 날라오는 풍선에 맞추어 튕겨 올리면서 지상 바닥에 떨어지지 않게 하는 것이다. 

굉장히 작은 분량의 BASIC 코드이기 때문에 당시 잡지를 보던 사람들이 많이 타이핑/실행해 봤을 것 같다. 작은 분량이지만, 지금 봐도 기발한 아이디어와 정교한 구현이 빛나는 코드라는 생각이 든다. 풍선에 닿았을 때 반발력이나 중력에 의한 낙하 같은 것이 굉장히 그럴 듯 하게 구현되어 있으며, 풍선의 개수나 배치도 게임이 너무 단조롭지 않도록 잘 구성한 것 같다. 롬 데이터를 폭파 이미지 스프라이트로 사용한 아이디어도 기발했다.

공개되었던 소스 코드는 다음과 같다.

40 SCREEN 1,3,0:WIDTH 29:KEYOFF:COLOR7,1,1:DEFINTA-Z:POKE-851,1 
50 FORI=259TO727:V=VPEEK(I):VPOKE I,VORV/2ORV/4:NEXT
60 ON SPRITEGOSUB 220
70 FORI=0TO39:READA$:VPOKE&H3800+I,VAL("&h"+A$):VPOKE &H3840+I,PEEK(I):NEXT 
80 VPOKE &H2004,&H21:VPOKE&H2005,&H8C:VPOKE&H2006,&HB0:VPOKE&H2007,&HB0:VPOKE&H2010,&H9F
90 LOCATE 14,0:PRINT"PUTTY CAMIYON'":X=90:Y=24:PY=-3:FORI=0TO3:X(I)=239:Y(I)=I*40+4 
100 VX(I)=-RND(1)*10-8:C(I)=-VX(I):NEXT:C=0:SPRITEON
110 S=STICK(0):X=X+7*((S=7ANDX>10)-(S=3ANDX<220)) 
120 PY=PY+3:Y=Y+PY\3:IFY>130THENGOTO180ELSEPUTSPRITE10,(X,Y),5,0 
130 FOR I=1TO3:Z=X(I):H=Y(I):Z=Z+VX(I):IFZ<0THENZ=239:VX(I)=-RND(1)*10-8:H=I*40+4+RND(1)*20:C(I)=-VX(I) 
140 PUT SPRITE 1,(Z,H),C(I)MOD14+2,1:X(I)=Z:Y(I)=H:NEXT:SPRITEON 
141 POKE-851,1 
150 C=C+1:LOCATE0,21:PRINTMID$("+++++++++++++++++++++++++++++++",C*2MOD9+1,29);
160 LOCATE0,20:PRINTMID$("%%%%%=%%%%%:%%%%%=%%%%%:%%%%%=%%",CMOD9+1,29); 
170 LOCATE2,0:PRINTUSING"SCORE:####0";C:GOTO110
180 SPRITEOFF:SOUND6,255:SOUND7,247:PLAY"T44SM60000C1":PUTSPRITE10,(X,Y),5,0 
190 FORI=0TO50:PUTSPRITE6+1MOD3,(X+RND(1)*28-9,Y+RND(1)*28-9),9,2:PUTSPRITE7+IMOD3,(X+RND(1)*28-9,Y+RND(1)*28-9),8,3:NEXT
200 LOCATE10,10:PRINT"GAME OVER"
210 FORI=0TO1:I=-(STRIG(0)):NEXT:CLS:FORI=0TO31:PUTSPRITEI,(0,209):NEXT:GOTO90
220 SPRITEOFF:SOUND1,6:SOUND7,254:SOUND12,120:SOUND13,1:SOUND8,16:PY=-23:RETURN 
230 DATA E0,F0,10,E8,19,79,7E,7F 
240 DATA FF,F8,E7,5F,63,3C,1F,07 
250 DATA 30,78,C8,BC,AC,AC,FA,06 
260 DATA F7,77,97,D6,BA,7C,F8,C0 
270 DATA 3C,7A,FD,FD,FF,7E,3C,08 
280 ' Original* EMS 
290 ' Remaking: PINPEST

해당 프로그램을 X-II (CPC-400) 기기에서 실행한 모습은 다음과 같다.

 

그런데 이 BASIC 프로그램은 다른 면에서 좀 특별한 점이 있다. 과거 MSX 실기와 OCM 클론에서 BASIC 프로그램 실행 결과 차이가 발생했던 것에 대해 글을 올린 적이 있는데(#1, #2, #3), 이 프로그램이 당시 그런 차이를 인식하게 해 준 프로그램이었기 때문이다.

MSX 실기와 OCM 클론에서 BASIC 프로그램 구문의 실행 결과 차이 발생

MSX 실기와 OCM 클론(MiSTer MSX 코어)에서 BASIC 실행 차이 두번째 분석

MSX 실기와 OCM 클론(MiSTer MSX 코어, IQ3 000 큐티)에서 BASIC 실행 차이 세번째 분석

보유하고 실기(X-II CPC-400, FS-A1WSX, FS-A1 mk II)에서 이 소스 코드를 구동시키면 정상적으로 동작하는데, 보유하고 있는 OCM 클론들(IQ 3000 큐티, MiSTer MSX 코어, SX-LITE)에서 이 소스 코드를 구동시키면 비정상적으로 동작한다.

우선 실기 쪽에서 구동했을 때의 동작 모습은 다음과 같다. 현재 실기에서 출력되는 영상을 녹화할 방법이 마땅치 않아 openMSX 에뮬레이터를 이용해서 화면 영상을 캡쳐했다(에뮬레이터에서도 실기와 동일하게 동작하는데, 풍선 스프라이트의 깜빡임은 좀 이상한 것 같다). 비행기는 기본적으로 낙하하고 있으며 비행기가 풍선에 닿았을 때 튕기는 것 처럼 약간 상승하게 된다.

다음은 OCM 클론 쪽에서 구동했을 때 동작 모습이다. 영상 캡쳐가 가장 쉬운 MiSTer의 MSX 코어에서 실행 모습을 캡쳐했다. OCM 클론 쪽에서는 비행기가 풍선에 부딪히지 않아도 땅으로 떨어지지 않고 계속 상승하며, 맨 위로 간 비행기가 화면 가장 아랫쪽에서 다시 올라온다. 비행기와 풍선이 부딛혔을 때 발생되는 효과음이 계속 발생하고 있다. OCM 쪽의 현상을 프로그램 관점에서 보면, 실제 스프라이트 간 충돌이 없어도 계속 스프라이트 충돌로 인식하여 'ON SPRITE GOSUB' 구문이 계속 호출되는 것이다.

우스개 소리지만 나는 이 BASIC 프로그램을 실행해 봄으로써 이 프로그램이 구동되는 MSX 기기가 실기인지 OCM 클론인지 파악할 수 있을 것 같다. 이런 차이가 발생하는 이유가 무엇일까?

 

우선, OCM 클론에서 이 프로그램의 로직이 돌아가도록 코드를 수정하는 방법을 찾기는 했다. 그것은 BASIC 코드에서 80번 라인을 삭제하거나 주석처리하는 것이다.

80 ' VPOKE &H2004,&H21:VPOKE&H2005,&H8C:VPOKE&H2006,&HB0:VPOKE&H2007,&HB0:VPOKE&H2010,&H9F

VDP 0x2004, 0x2005, 0x2006, 0x2007, 0x2010 주소 영역은 컬러 영역이라고 하는데, 일단 이 영역에 값을 넣는 부분을 실행하지 않으니 상단 스코어 숫자 색깔 등이 다르게 기본 코드와 다르게 나오지만 기본 동작은 OCM 클론에서도 잘 동작했다. 이를 통해 OCM 클론의 VDP 모듈쪽 특정 영역에 데이터를 쓰는 것이 스프라이트 충돌처리 기능을 이상하게 동작하게 했을 것이라는 짐작을 할 수 있다.

 

둘째, MiSTer의 MSX1 코어에서는 이 BASIC 프로그램이 정상적으로 잘 동작하는 것을 확인할 수 있다. MSX1 코어는 HDL 구현이지만 OCM 코드 기반이 아닐 뿐 아니라 VDP로 V9958 구현 모듈이 아닌 TMS9918A/28A 구현 모듈을 사용한다. 재미있는 사실은, MSX1 코어 개발자가 MSX2 호환을 목표로 개선하고 있는 MSX2test 브런치 구현에서는 또 OCM 클론과 동일한 현상이 발생한다는 것이다. MSX2test 브런치 구현물은 V9938 구현 모듈을 사용하고 있는 것으로 알려져 있다.

 

이상 두 가지의 상황을 고려했을 때, 이 현상의 문제는 역시 OCM 클론 쪽 VDP 모듈이 실제 V9938/V9958과 동일하게 동작하지 않기 때문이 아닌가 싶다. VDP의 특정 주소에 데이터를 입력했을 때의 내부 처리가 다른 것으로 보이며, OCM 클론들이 사용하는 VDP 모듈의 구현에 오류가 있는 것이 아닐까 싶다.