Ponpoko Remake #2 - 소스없이 포팅

게임을 공식적으로 리메이크를 하게되면, 원본 소스(코드, 그래픽 등)를 포팅(이식)하게 됩니다.

근데 비공식으로 리메이크하게되면, 원본 소스가 없으니 사실상 게임을 새로 만드는 것과 비슷합니다.

게임을 새로 기획하거나, 캐릭터를 새로 디자인하는게 아니니까,

간단한 게임의 리메이크라면... 프로그래머 한명으로도 가능합니다요.

제작하는데 시간이 많이 걸리느냐, 적게 걸리느냐 정도의 차이는 있겠네요 ㅎ.ㅎ

이 경우 리메이크의 완성도를 결정하는 것은,

프로그래머가 그 게임을 얼마나 잘 알고 있느냐의 정도라고 생각되네요.

그럼, Ponpoko 리메이크는 어떻게 진행하면 좋을까요?

늘 하던대로 눈카피? ㅎ.ㅎ

먼저 아래 스샷을 보시죠. MAME에서 실행하면 처음에 나타나는 게임정보입니다.

먼저, 리메이크를 만들 때 가장 중요한 부분은 비디오쪽입니다.

아무래도 게임에서 그래픽이 차지하는 비중이 높은데, 이게 쉽게 되면 좋죠 ㅎ.ㅎ

제가 지난글에서도 그래픽부터 언급한 이유가 그 때문입니다.

사실 이게 안되면 걍 포기해야됩니다요~~ㅋ

사운드 정보는 간단하게 남코의 96KHz H/W로 나오는데요.

보드 내부적으로는 파형샘플을 주파수에 맞춰 3개 채널을 믹스해서 최종 모노 오디오를 만듭니다.

결국 3채널짜리 SCC를 보드로 만들었다고 생각하시면 되겠네요.

SCC는 샘플램에 데이터를 매번 로딩해야하지만, Ponpoko는 롬샘플이라 CPU가 로딩할 필요가 없습니다.

지난글에서 구동환경을 MSX2 최소사양으로 잡았는데요.

만약 PSG 3채널로 그럭저럭 괜찮은 소리가 나온다면 좋겠네요 ㅎ.ㅎ

보통은 여기까지 생각하고 넘어갑니다만, 이번엔 하나를 더 봅시다요!

CPU 정보를 보니, 3MHz짜리 Z80 하나만 나와있네요?!

보통 오락실 기판에 Z80이 박혀있으면, 사운드 컨트롤 전용으로 쓰이는게 대부분인데요.

그게 아니면 여러개의 Z80 CPU가 들어있거나요.

근데 Ponpoko는 MSX의 3.58MHz 보다 느린 CPU입니다 ㅎ.ㅎ

이걸로 추측해볼 수 있는 것은...

CPU 로드가 낮다 -> H/W에 의존하는 그래픽, 사운드 외의 S/W 테크닉은 사용하지 않음!

네, 그냥 게임 로직을 돌리는거 외엔 별로 하는 일이 없다는 얘기입니다.

게임을 만들다보면 CPU 로드가 늘어나서 사양을 높이거나 다른 처리(그래픽, 사운드)를 삭제하게 되는데요.

Ponpoko 리메이크는 진짜 MSX2만으로 충분할 것 같은 느낌이라는거죠.

자! 그럼 작업을 시작합니다!!

너구리의 숏점프, 롱점프 움직임을 스샷으로 한프레임씩 잡고 데이터를 테이블로 정리!

적들(애벌레, 오리)의 프레임당 이동량을 확인! (참고로 애벌레는 속도가 다른 3종류가 나와요.)

이것만으로 힘들다면...?

MAME 디버그 창을 띄워놓고 프레임을 끊어서 변수값을 보거나,

소스를 수정해서 데이터를 직접 로그(파일)로 저장 등의 방법을 씁니다.

.

.

.

근데, 이번엔 이렇게 안했어요ㅋ

사실 로직이 워낙 단순해서 이렇게 해도 금방 만듭니다만...

방금 Ponpoko의 메인 CPU가 Z80이라고 했잖아요?

보통 게임을 눈카피하게 되면, 원작과 미세하게 차이가 나는 부분들이 생기게 마련입니다.

적 또는 아이템 충돌 범위가 다르거나, 점프할 때 적용되는 중력 가속도가 다르거나 등등이요.

만약 원본 코드를 가져다 쓸 수 있으면, 이 부분을 똑같이 구현할 수 있습니다.

공식 리메이크라면 소스를 가져와서 컴파일했겠지만,

이번 Ponpoko 리메이크는 비공식이니, 그냥 롬에 들어있는 Z80 머신코드를 가져다 쓰는거죠. (Z80 만세!)

그리고 이게 쉽게 되는 이유 중 하나가 더 있는데요.

Ponpoko의 주변 I/O는 모두 메모리맵 I/O이고 포트맵 I/O를 쓰지않습니다.

반대로 MSX는 대부분 주변 I/O가 포트맵 I/O이고 메모리맵 I/O들은 이미 슬롯으로 보호받고 있습니다.

그러니까 메모리맵 I/O만 잘 분리해주면, MSX에서 충돌하지 않는다는 얘기에요.

관련된 코드는 잘 정리(패치)를 해서 오동작하지 않도록 해주면 됩니다.

인터럽트 관련 코드도 마찬가지겠구요.

뭔가 일반적인 리메이크 작업과는 상당히 다르게 진행되는데요.

저도 이런식으로는 처음 해보는거라 꽤 재미있었습니다.

그럼, Ponpoko의 메인코드를 초간단 그래픽 에뮬을 넣어서 테스트해봅니다.

걸음마 떼는게 쉽게 되면, 나머지 구현은 시간문제니까요.

아래 스샷의 왼쪽은 MAME, 오른쪽은 MSX입니다.

MSX쪽은 스크린1을 212라인 모드로 전환해서 돌렸구요. 패턴 데이터는 BIOS 폰트 기본값입니다.

오른쪽 스샷을 매트릭스 네오의 눈으로 보면, 왼쪽이랑 똑같죠?ㅋㅋ

지난글의 댓글에서 제가 "느낌이 아케이드랑 99% 같을거에요. 이건 제가 보장합니다."라고 적었는데요.

왜 그런건지 이제 이해되시죠? ㅎ.ㅎ

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

Ponpoko Remake #1 - 너구리 게임을 아시나요?

[서론]

80년대 오락실에 있던 너구리 게임을 아시나요?

원제는 Ponpoko입니다.

단순한 그래픽, 사운드에 너구리의 스킬이라고는 숏점프, 롱점프 뿐이지만...

적들을 피하면서 고득점 보너스를 받으려고 발악(?)하는 재미가 있었지요 ㅎ.ㅎ

실력이 늘면 클리어 속도도 빨라집니다만, 그만큼 실수할 확률도 올라가서... 흐~

사실 이 게임을 한동안 잊고 있었는데요.

한달전에 게시판에서 Ponpoko 게임얘기가 나와서, 뭔가 팍 머리를 스쳐지나갑니다! 응?

여태 이 게임이 정식으로 리메이크가 나온적이 없더라구요.

이거 한국에서만 인기가 있었나? 뭐 그런 생각도 들었습니다.

심지어 그 흔한 ZX Spectrum 용 포팅도 없네요.

그럼, 뭔가 동기부여가 되는 느낌이죠? MSX용 Ponpoko 리메이크 제작에 대한 동기부여욤 ㅎ.ㅎㅋ

[본론]

Ponpoko는 이미 수십년(?) 전에 MAME에서 에뮬이 되고, 비디오, 오디오에 대한 분석도 끝난 게임이라...

지금와서 리메이크를 만드는 데에 별 어려움은 없습니다.

늘 그랬지만, 한가지 문제라면... 역시 MSX의 게임성능이겠죠?

구동 환경을 어느정도의 선에서 그어야 할지 일단 좀 살펴보아요~

12년 전에 ASO 리메이크를 만들 때는 turboR 외엔 답이 없는 게임이었지만,

Ponpoko는 조금 저사양을 타겟으로 만들어도 괜찮을 것 같습니다요.

80년대 흔했던 5층 아파트 구조입니다ㅋ 옥상을 포함하면 총 6층이네요.

각 층은 32라인으로 그려지고, 옥상도 동일합니다.

화면의 필수영역(빨간 박스)은 32라인 x 6 = 192라인(많이 보던 숫자?!)입니다.

가로 화면은 256픽셀이니까, 이거 최소 256 x 192 픽셀이 필요하다는 얘기죠.

전체 스크린은 256 x 224픽셀으로, V9938의 오버스캔 트릭을 쓰면 손실없이 모두 출력가능합니다만,

이번에는 오버스캔없이 정식 출력을 쓸 계획입니다.

1층의 하늘색 바닥을 그리지 않고, 스크린 테두리(Border)로 표현하면 1라인 여유가 있으니까...

여기에 스코어를 표시하면? MSX1의 스크린2 (256 x 192)에서도 대충 그려볼 수 있겠구요.

하단(녹색 박스)부분은 제외하고, 상단(노란색 박스)를 포함하면 256 x 208라인이 되는데요.

만약 V9938의 스크린4(그래픽3) 모드에서 212라인출력을 써서 구현하는 방법도 있겠습니다.

이 경우는 하단의 남은 너구리 표시는 우측 상단에 넣어도 되겠네요.

오리지널 Ponpoko는 2인 플레이 시 우측상단에 2P 스코어가 표시 되지만, MSX에서 굳이 넣을 필요는 없으니까요.

다음으로, 아이템과 움직이는 캐릭터를 봅시다.

과일 아이템은 16 x 16 그래픽인데, 내부적으로는 8 x 8 패턴 4개를 붙여서 만들어져있습니다.

그 외 작은 압정, 사다리 등도 8 x 8 패턴입니다.

Ponpoko의 아케이드 보드도 패턴 데이터를 출력하는 방식이라서,

VDP의 패턴 그래픽 모드를 비슷하게 활용해도 될 것 같네요.

아이템은 화면상의 8픽셀 단위로 그려집니다. 더이상 움직이지도 않구요. 패턴 그래픽에 딱맞는 그림이죠?

물론 VDP의 패턴모드에서는 수평 8픽셀에 컬러 2개 밖에 못 쓰니까, 실제 구현 시 안이쁘게 나올 여지는 있습니다.

사실 말이 컬러 2개지, 실제로는 1개랑 마찬가지에요. 배경에 다른색 하나 찍는거니깐ㅋ

참고로 Ponpoko 보드는 패턴에 4컬러를 쓸 수 있습니다.

검정 배경을 제외하면, 3개의 컬러가 한 패턴에 나올 수 있습니다.

주인공 너구리와 적 캐릭터(애벌레, 뱀)는 모두 1픽셀 단위로 이동이 되구요.

컬러는 패턴과 동일한 4컬러 출력을 사용합니다. 역시 투명색을 제외하면 3컬러가 출력되겠네요.

참고로, TMS9918에서 스프라이트로 3색을 구현하려면, 레이어 3개를 겹쳐야합니다.

TMS9918, V9938 모두 스프라이트 레이어가 32개 있으니...

캐릭터 하나당 3개씩 쓰면 화면상에 총 캐릭터 10개까지는 가능합니다.

사실 MSX의 스프라이트는 레이어 갯수 보다는, 수평 출력 제약때문에 구현이 좀 어렵습니다.

TMS9918처럼 같은 수평라인(Scanline)에 4개밖에 출력이 안되는 경우엔, 프레임을 나눠서 스프라이트 레이어를 섞어야하죠.

결과적으로 레이어 우선순위에 따라 캐릭터가 깜박거리게 됩니다만,

아예 안보이는 것 보다는 나으니까, 이렇게라도 해야겠지만요 ㅎ.ㅎ (사실 MSX1용 게임 99%가 이런식이죠.)

전체 스테이지 20개를 모두 스샷으로 잡아서 확인해보니,

수평라인에 스프라이트가 최대 4개까지만 나오네요 ㅎ.ㅎ

애벌레, 뱀이 각 층에 분산되어 최대 3마리만 나옵니다. 너구리까지 포함하면 수평으로 최대 4개가 표시되는거죠.

만약 이걸 MSX2의 스프라이트 모드2를 쓰게 되면, 라인 제약인 스프라이트 8개로 모든 컬러를 구현할 수 있겠습니다!!

사실 캐릭터가 빠르게 움직이는 경우(슈팅 게임)는 스프라이트가 좀 깜박이더라도 봐줄만 합니다만,

Ponpoko는 죄다 느리게 움직이는 애들이라, 실제로 깜박이면 상당히 짜증이 날거에요.

1982년산 허접해보이는 Ponpoko 스프라이트도, MSX1으로 구현하려면 ㅠ.ㅠ

좀 제대로 보이게 하려면, 스프라이트 모드2를 써야겠네요.

그럼 답은 나왔네요.

수직, 수평 스크롤이 필요한 게임도 아니니까, MSX2 기본사양(램 64KB)을 타겟으로 리메이크를 시작합니다!

최종 S/W는 카트리지로 구동이 되며, 디스크롬은 사용하지 않을 예정입니다.

.

.

.

일단 시작했으니, 타이틀 화면부터 만들어보아요~ ㅎ.ㅎ/

참고로, 화면에 나오는 "The 80s REVIVAL"은 이번 Ponpoko 리메이크를 제작한 팀 이름입니다.

그럼, 이만~

지난 20년 개발의 추억 #2 - 램상주 폰트로의 여정

#1편의 기억이 잊혀질 때 쯔음, #2편이 시작됩니다 ㅎ.ㅎ

이전글을 보시려면, 아래 링크를 눌러주세요~

https://sharksym.blogspot.com/2023/07/20-1.html

[서론]

2004년 ~ 2008년,

그 동안 MMC/SD Drive V1, V2 보드가 제작되면서, 다시 파라동으로 돌아온 분들이 꽤 계셨습니다.

물론 다시 돌아오신 분들은 'MSX 게임들을 실기로 다시 해보고싶다'의 바램이셨겠지요? 아마 맞을겁니다ㅋ

어쨌든 동호회 내에서 MSX를 갖고 노는 아자씨들이 늘어나려면, 공통 분모가 될만한 것들이 생겨야하는데요.

제가 만드는 것들을 다른 분들도 원하느냐? 아니냐?가 중요한게 아니라...

만들어진 것들 중 하나라도 그 분들의 관심을 끌어서, 같이 얘기할 수 있는 것들이 되어야합니다.

저한테만 필요한 것들을 만들어서 혼자만 놀면 어떻게 되나구요? 음... 조금 덜 재밌습니다. 그리고, 외롭구요 ㅎ.ㅎ

오락실에서 원코인 클리어를 하더라도, 뒤에서 구경하는 친구들이랑 같이 떠들면 더 신나는 것과 비슷한 느낌?ㅋ

[본론]

4. 개발환경을 MSX-DOS2로 옮겨보자

MMC/SD V2를 쓰시는 분들이 많아지니까, 이젠 DOS 정도는 대충 익숙해지셨다고 판단됩니다.

FAT16에 대용량 파티션(4GB)를 쓰려면 DOS2가 필수니까, 반강제로 본체 메모리도 많이 증설하셨을테구요ㅋ

이제 앞으로 개발하는 프로그램들은 DOS2용으로 가도록 합니다.

일단 좀 편하게 시작하기 위해, 구글링을 해봅니다. 쓸만한 DOS2용 툴이 있으면 가져오면 되니까욤~

.

.

.

없네요 없어... -_-

4.1 메모리 매퍼에 프로그램을 올리자

메모리 매퍼는 MSX2와 함께 등장했습니다.

근데, Main BIOS에서 지원되는 기능도 없고, '개발자가 알아서 잘(?) 사용하세요!'의 개념이라 좀 애매했습니다.

나중에 DOS2가 등장하면서 메모리 매퍼용 확장 BIOS가 추가되었는데요.

시스템 세그먼트, 유저 세그먼트 등으로 메모리를 구분해서 할당하고 사용할 수 있도록 되었습니다.

하지만 관련 개발툴이 하나도 없다보니... '개발자가 알아서 잘(?) 사용하세요!'의 개념은 여전합니다.

90년대 메모리 매퍼를 활용하는 자작 프로그램들이 몇몇 있었는데,

결국 이것들은 모두 개발자가 잘(!) 사용한 경우라고 봐야겠네요 ㅎ.ㅎ

사실 "메모리 매퍼에 프로그램을 올리자"를 구현하는 방법은 여러가지가 있겠지만,

일반적인 메모리 뱅킹 구조로 개발하는 툴을 만들어서 DOS2 메모리 매퍼에 맞추는 것이, 가장 좋은 방법이라고 생각되었습니다.

(혹시 메모리 뱅킹이 뭔지 모르시면 구글링 해보셔요~ ㅎ.ㅎ)

각 코드(오브젝트)가 분배되는 뱅크의 번호만 지정해두면, 개발툴이 자동으로 코드를 만들어주는 것이죠.

보통 작은 MCU에 대용량 코드롬을 붙여서 개발되는 제품에서 흔히 볼 수 있습니다.

(물론 사용자는 알 수 없고 개발자들만 알겠지만요)

그렇게 시작된 프로젝트가 이겁니다.

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

기존 DOS1을 위해 사용하던 HI-TECH C 환경에 'MSX-DOS2 Banking toolkit'을 만들어서 붙이는 것이죠.

요약하면, 개발자가 순수 C코드만 만들고 Makefile에 뱅크 번호만 붙여주면, 툴이 알아서 빌드해줍니다.

아래는 예제 프로그램인 테트리스의 설정 중 일부입니다. 참고하셔요~

조금 설명을 붙여보면요,

뱅킹 영역은 32KB(0100H ~ 7FFFH)입니다.

각 뱅크별로 코드와 Heap(~7FFFH)을 쓸 수 있고, 전역 변수(데이터)를 위해 공용 Heap(9400H ~)도 사용가능합니다.

Stack은 Page 2, 3 남은 영역을 모두 쓸 수 있구요.

뱅킹 Stack은 별도의 메모리 영역을 쓰기 때문에, 함수(Function)에서 스택으로 인수를 전달할 때 문제가 생기지않습니다.

큰 데이터를 사용할 수 있도록 메모리 매퍼 용 함수들도 들어있습니다.

기존 DOS TPA(64KB)에서 개발하던 방식 그대로 코딩하더라도, 큰 용량의 프로그램을 제작할 수 있게 되었죠.

최대 2048KB 크기의 프로그램을 만들 수 있습니다. 각 뱅크가 32KB를 넘지않도록 잘 나눠주기만 하면 Ok!

초기에는 툴을 MSX-DOS용으로 만들어서, 실기에서도 빌드를 할 수 있게 했는데요.

이게 옵티마이저 코드가 계속 늘어나다보니, 실기에서는 무리라고 판단.

결국 윈도 용으로만 남게되었습니다.

CP/M 에뮬, make, 뱅킹 툴은 윈도(win32) 프로그램이구요.

HI-TECH C의 컴파일러, 링커는 그대로 사용됩니다. CP/M 에뮬을 통해서요.

4.2 그래픽 라이브러리도 넣자

이제 메모리 제약이 없어지니, 굳이 Main/Sub BIOS를 호출할 필요가 없네요.

그냥 DOS2 램에서 실행하는게 짱입니다.

특히 turboR의 고속모드를 사용하는 경우라면 더욱 효과적이죠.

예전엔 BASIC, 어셈블리로 힘들게 코딩했는데...

그냥 C 라이브러리로 용량 제약없이 만들 수 있게되니 좋네요.

필요한 거 다 때려넣어요~ 인터레이스 모드 그래픽, 스프라이트 페이징 등등

특히 그래픽 함수들이 인터레이스를 지원하도록 다 만들고나니 너무~너무~ 좋네요.

사실 인터레이스 출력은 MSX2 시절 V9938부터도 되었는데, BIOS에서 전혀 지원이 안되었습니다.

개발자가 아니라면 건드리지도 못했다고 봐야죠. 이건 MSX2, MSXturboR 시절에도 마찬가지였죠.

아래는 그래픽 데모입니다. 오래되서 화질이 안좋지만 대충 봐주셔요~ ㅎ.ㅎ

4.3 사운드 라이브러리도 넣자

MML 데이터를 사용하는 BGM 플레이어와 효과음 출력루틴을 만들어봅니다.

평소에는 BGM을 출력하다가, 효과음이 필요할 때 한채널의 BGM을 끄고 효과음으로 전환하는 방식입니다.

아래는 예제 프로그램인 테트리스의 사운드 코드의 일부입니다. 참고하셔요~

4.4 R800 곱셈도 넣어보자

R800에서는 곱셈 명령어가 추가되어있습니다.

C로 프로그램을 만들게 되면, 테이블 주소 계산 시 곱셈이 꽤 사용되는데요.

turboR 전용 프로그램을 만들 때는 이걸 R800 전용 명령어로 교체하면 좋겠죠?

Makefile에 빌드 옵션도 넣고, 이리저리 삽질을~ㅋ

그러고보니, 초기 M 파일매니저에는 R800 전용 빌드도 따로 있었네요.

참고로, R800 코드로 변경하는 부분은,

컴파일러가 생성한 어셈코드를 옵티마이저가 파싱해서 패치하는 방식입니다.

곱셈 라이브러리를 2벌로 만들어도 되긴한데, 어차피 속도 때문에 넣은거니 걍 소스를 고치는 식으로ㅋ

5. DOS2에서 돌아가는 프로그램을 만들자

이제 어느정도 준비가 되었으니, 머리에 떠오르는 것들을 하나씩 만들어보아요~

5.1 한글 뷰어를 만들자

인터레이스 모드에 대용량 메모리도 가능하니, 조합형(8x4x4) 한글 폰트를 넣어봅니다.

마치 486 화면을 보는 것 같네요 ㅎ.ㅎ

십여년이 흘러 지금은 FontPack의 도움으로 유니코드도 표시가 됩니다요~

5.2 파일 관리자를 만들자

이미 90년대에 일본에서 DOS2 전용으로 제작된 파일관리자(MultiMente)가 있었습니다.

근데 제가 섬나라 감성과는 안맞네요. 화면을 보기만해도 표정이 (-_-) 이렇게 되서...ㅋ

MS-DOS에서 널리쓰이던 NC, Mdir을 적당히 섞어봅니다.

역시 본인 입맛에 맞게 만드는 게 제일입니다요~ㅎ.ㅎ

이름은 'M File Manager'로 붙였습니다.

처음부터 turboR 용으로 만든거라 프로그램이 꽤 무겁습니다.

초기에는 기본 빌드를 R800 전용으로 만들고, MSX2/2+를 위해 일반 Z80 빌드를 따로 추가했습니다.

그러니까 프로그램이 2개였죠 ㅎ.ㅎ

나중에는 메모리가 적은 환경을 위해 Lite 모드도 넣고,

넌인터레이스 모드도 지원하도록 되어서, MSX2에서도 조금 쾌적하게 만들었는데요.

그래서, 프로그램이 3개가 되었습니다요.

.

.

아마 MMC/SD V3,V4에 기본으로 넣어놔서, 반강제적으로 쓰고 계신 분들이 많을 걸로...ㅋ

참고로, 지금은 다 통합되어서 프로그램 1개입니다.

메모리 매퍼 여분이 부족하면 Lite로 런타임 전환됩니다~ ㅎ.ㅎ

5.3 IMS 플레이어를 만들자

메모리 매퍼를 코드뱅킹뿐만 아니라, 일반 대용량 데이터를 처리하는 용도로 쓸 수 있습니다.

lmem으로 16KB 세그먼트를 최대 64개, 1024KB까지 쓸 수 있습니다.

근데 이걸 어디에 쓰나구요?

MS-DOS 시절 OPL2로 만든 ROL/IMS 음악들이 한창 유행하던 시절이 있었습니다.

가사(ISS)를 보여줄 수 있는 IMS 파일들이 마구마구 쏟아져 나왔어요.

MSX에서 놀고있는(?) OPL4 사운드카트리지(MoonSound)를 이용해서 IMS 플레이어를 만들어봅니다.

IMS 데이터가 대게 64KB ~ 128KB 근처니까 테스트 용으로 딱 좋은거죠~ ㅎ.ㅎ

오래된 영상이라 화질이 안좋으니, 대충 소리만 들으셔요~

5.4 테트리스를 만들자

그래픽 테스트에는 역시 게임이 최고아닐까요?

간단하게 테트리스를 만들어봅시다.

아래 영상에서는 FM 사운드 테스트와 테트리스 BGM 테스트가 나옵니다.

화면 밝기가 엉망이네요, 대충 구경하셔요~ ㅎ.ㅎ

5.5 ASO 리메이크를 해보자

때는 2011년 여름...

회사에서 개발하던 제품(은하S2)의 출시가 끝나고 잠깐 여유가 생겨서, 좀 더 확실한 테스트 코드를 만들어보기로 합니다.

본격적으로 비트맵 그래픽을 활용하는 게임이 되겠네요.

화면에 등장하는 캐릭터가 워낙 많아서 스프라이트를 분할(홀짝 프레임 나누기)해서 처리해도 빠듯합니다.

- 지상에서 움직이는 물체는 S/W 스프라이트로 구현

- 사운드는 오리지널 OPL1 사운드를 MAME로 덤프해서 활용

- 기본 화면은 수직 스크롤을 쓰고, 거대 보스를 움직일 때는 수평 스크롤 트릭을 사용

- VDP의 수직 오버스캔 트릭으로 256 x 240 스크린 처리

오버스캔을 쓰면 블랭킹 구간이 짧아서, 배경화면 처리가 꽤 힘듭니다.

결국 이걸 60fps로 구현했죠. 물론 turboR 전용으로요. 흐흐~~

아래는 AREA1 구현 완료 후 올린 영상입니다.

5.6 16KB/32KB 게임 러너를 만들어보자

아마 ODO 같은 DOS의 TPA 메모리에 16KB/32KB의 롬 이미지를 로딩해서 구동하는 프로그램을 많이 써보셨을거에요.

이것과 비슷한 프로그램을 한번 만들어보아요~

차이라면... 상태저장이 된다는 것과 게임 중 다시 DOS로 복귀가 가능하다는 것?

이름은 GRUN입니다.

https://sharksym.blogspot.com/2012/04/grun_16.html

32KB 이하의 롬 카트리지들은 BIOS의 ISR 루틴을 그대로 활용합니다.

특별히 슬롯 전환을 하는 부분도 없구요. 구조가 간단한 프로그램들이죠.

Page 0에 Main BIOS를 복사해서 특수 키 처리를 넣으면 되겠구요. (DOS 복귀 등)

DOS 복귀할 때는 Page 3의 메모리만 원복해주면 되겠습니다.

사실 간단한 프로그램이에욤.

참고로, 이 프로그램은 나중에 MMC/SD V3의 GameRunner로 업그레이드됩니다 ㅎ.ㅎ

MMC/SD V4에서는 GameRunner II로 진화합니다.

사실 GRUN, GameRunner, GameRunner II 모두 이름은 같은데 내부 동작은 많이 다르긴해요.

암튼 그렇습니다요~

6. Scanline Eraser

MSX랑 직접적인 관계는 없지만, 제가 자작한 H/W 중에서는 가장 히트했던 물건이라 적어보아요~ ㅎ.ㅎ

https://sharksym.blogspot.com/search/label/_Scanline%20Eraser

아날로그 RGB 출력의 홀수(또는 짝수) 스캔라인을 지우는건데요.

LCD 디스플레이를 CRT처럼 스캔라인 사이의 검은 공간을 만들어주는 기능입니다.

외국에서 Scanline Generator로 개명당해서 많이 팔렸었죠.

알리익스프레스에서는 아직도 팔고 있...ㄷㄷ

7. MMC/SD V2 Multi-ROM II

때는 2012년 가을...

MMC/SD V2는 SCC 칩이 들어있어서, 내장 멀티롬 기능으로 코나미 게임을 즐기는 용도로도 꽤 쓰였습니다.

조금 아쉬운 점이라면, 멀티롬 용량이 최대 384KB라서요. 메탈기어2 같은 512KB 롬을 구동을 못한다는거죠.

SCC 사운드를 좋아하시는 분들에게 납땜 연습(?)거리를 만들어드리기로 합니다.

MMC/SD V2를 개조해서, 512KB 플래쉬롬 15개를 추가하는겁니다.

기본 멀티롬 용량 384KB에서 멀티롬II로 용량이 7680KB로 바뀌는거죠.

아래는 테스트용으로 플래쉬롬 7개를 추가한 모습입니다.

롬 용량은 커졌지만, SCC 매퍼의 한계 512KB 어드레싱은 넘을 수 없으니...

1024KB 등의 큰 롬은 다운로드가 불가능합니다.

16KB ~ 512KB 사이즈의 롬을 여러개 채워넣는 것만 가능합니다요.

요렇게요~

V2의 부트메뉴에서 진입하면 아래처럼 롬 선택 메뉴가 나옵니다.

나중에 V4에서도 비슷한 UI로 구현된 SUB-ROM이 들어갑니다 ㅎ.ㅎ

.

.

.

2010년에서 2012년까지 또 미친듯이 달렸던 기억들을 모아봤습니다.

이번에도 "램상주 폰트" 얘기는 못 넣었네요. 다음편에서는 꼭 나옵니다. 진짜루요 ㅎ.ㅎ

긴 글 읽어주셔서 감사합니다요~