Download: 20261025_WAU_BIOS_Tool_v1.02.zip
--------------------------------------------------
WAU(tm) - BIOS & Tool
By Yeongman Seo <sharksym@hitel.net>
--------------------------------------------------
[ BIOS & Tool v1.02 ]
- RTC 설정 시 10월(Oct) 값이 0으로 입력되는 문제 수정
[ 업데이트 가이드 ]
1. WAU.COM, WAU_BIOS.ROM 두개 파일을 디스크에 복사.
기존 파일을 덮어쓰면 됩니다.(예:UTILS 디렉토리)
2. WAU WAU_BIOS.ROM 명령 실행.
3. 다운로드 완료 후 재부팅.
4. 끝
탭-탭-레볼루션 (TTR)
이름만 봐도 알 수 있는 짭 DDR입니다.
메인 프로그램은 DOS 코드이구요. 메가롬 빌드로 출력된 결과물이 되겠습니다.
지난번 Ponpoko에서는 스크린2,4의 212라인 모드 출력을 주로 사용했는데요.
TTR에서는 스크린5,8을 사용합니다.
화살표 노트가 스크롤되는 게임의 메인 화면은 스크린5를 사용하구요.
속도와 팔레트 애니메이션 때문이라는 건 당연히 아시죠? ㅎ.ㅎ
그 외는 모두 스크린8을 사용합니다.
노래는 원곡 그대로 출력할 수 있도록, 8bit PCM 출력(로컬 DMA + DAC)을 H/W로 넣었구요.
화살표 노트 데이터는 원본 게임영상에서 데이터를 추출하는 프로그램을 자작해서 사용했습니다.
개발 초기에는 주로 에뮬레이터에서 테스트를 하구요.
PCM 사운드와 동기를 맞춰야 하는 부분은 실기에서 확인하는 방식이죠.
실기 테스트는,
MSX2에 PCM 출력 사운드 카드 환경에서 DOS 프로그램(TTR 게임)을 구동하는 방식입니다.
최종 카트리지에는
프로그램도 ROM 빌드로 들어가니까, 카트리지 한개에 S/W + H/W가 모두 포함됩니다.
지난번에 "TTR을 일반 DOS2 프로그램과 외부 사운드 카트리지 처리로, TTR 스테이지를 늘려주세요."
정도로 얘기하신 분이 있었는데요.
요즘에는 OPL4 샘플램 2MB를 쓰는 분들이 있으니까, OPL4 용으로 만들어도 가능하긴 할 겁니다요.
이건 관심있는 다른분들이 만들어주시면 좋겠습니다.
짭-DDR은 제가 만들어봤으니, 짭-비트매니아 게임이 나오면 재밌겠네요! ㅎ.ㅎ
심심하시면 아래 플레이 영상도 ㄱㄱ
그럼, 다음 편에서 이어집니다요~
그래픽 라이브러리의 모든 기능을 테스트하려면, 실전을 치루는 게 제일 편합니다.
그래서 ASO 리메이크를 제일 먼저 해봤던 것이었구요.
스크린7,8,12 인터레이스 관련 루틴은 M 파일매니저에 모두 사용이 되었구요.
turboR을 쓰면서 스크린2,4의 패턴맵 그래픽을 쓸 필요가 있을까? 그런 생각을 해보다가 말았는데요.
그렇게 10년쯤 잊고 지내는 중, 게시판에 너구리 게임 얘기가 나왔습니다. Ponpoko!
오리지널 그래픽, 사운드 구조를 확인해보니, MSX2에서 비슷하게 구현이 가능하겠더라구요.
Ponpoko 리메이크는 포팅 수준으로 작업이 진행됩니다.
그리고, 잘 쓰이지 않던 ROM 빌드를 활용해봅니다.
DOS 프로그램을 롬으로 만들 때엔 디스크롬과 롬디스크 이미지를 합치면 간단히 만들 수 있는데요.
제가 만든 ROM 빌드 환경은 오리지널 디스크롬을 쓰지 않습니다.
대신 BDOS의 루틴 일부를 구현해서 최종 ROM에 포함이 되구요.
사용자의 실행파일(*.COM)은 별로의 로더로 메모리에 로딩되어 자동실행되는 방식입니다.
한줄로 요약하면,
메모리 매니저 + BDOS 에뮬 + COM 파일 로더 + 사용자 COM 파일이 하나의 ROM으로 변환된다고 보심 되겠습니다.
기존 DOS 빌드에 쓰였던 코드, 라이브러리를 쓰는 프로그램을 그대로 쓸 수 있다는 게 장점이겠네요.
나중에 다른 글에서 또 설명하겠지만, 메가롬 등의 대용량 롬을 쓰는 것도 가능합니다.
Ponpoko 리메이크는 8MB 플래쉬롬이 들어간 Oraksil 보드를 사용합니다.
처음 기동 시 오프닝 영상이 나오도록 해봤구요.
빠른 사운드 처리를 위해 숫자 계산루틴 대신 결과값을 롬에 테이블을 넣어버렸습니다.
... 넓은 롬 용량을 마구마구 써버렸다는 소리입니다요ㅋ
그래픽을 프로그래밍으로 구현하는 것은 그리 큰 작업은 아니었는데요.
새로운 타이틀 도트 작업이나, 스프라이트 도트 작업이 제일 귀찮았네요. 시간도 많이 걸렸구요 ㅎ.ㅎ
오리지널 Ponpoko 보드가 오락실 기판 치고는 성능이 안좋은 편이라서,
화면 전체 캐릭터를 V9938의 스프라이트2 모드로 구현이 가능합니다.
스프라이트 패턴 2개만 겹치면 되는데, 가로 라인에 캐릭터 최대 4개만 나와요.
문제되는 부분은 타이틀에서 너구리 7마리가 달려오는(?) 애니메이션인데...
걍 위아래로 캐릭터를 강제로 나눠서 보여줬습니다. 아래 스샷처럼이요.
이거 깜빡임으로 처리해서 한줄로 표시하면 너무 그지 같더라구요 ㅎ.ㅎ
메인 그래픽은 스크린4의 패턴맵 그래픽을 사용합니다.
오리지널 해상도는 288 x 224 도트로 되어있어서, 스크린4의 256 x 192 그대로 옮기는 건 안되겠더라구요.
근데 실제 게임에서는 수평 256도트만 사용하고 있어서 스크린4로 가능했습니다. 유후~
세로는 212라인 모드를 써도 아래쪽의 상태표시 라인을 보여주지 못합니다. 12라인이 부족하죠.
이걸 오버스캔 모드를 써야하나 고민했었는데...
그냥 상태표시 라인(남은 너구리 개수)을 우측 상단으로 옮기는 걸로 타협했습니다.
원작 게임에서는 2P SCORE가 표시되는 부분이지만, 이번 MSX 버전은 1P 전용이라 2P 영역은 삭제!
음... 근데 스크린4에서 212라인 모드를 쓰면, 패턴맵 4장이 표시된다는 거 알고 계시나요?
기본 192라인에서는 패턴맵 3장이죠. 256개 패턴 x 3 = 768 패턴
참고로 BIOS에서는 패턴맵 4장을 처리하는 기능이 없습니다.
그냥 스프라이트만 모드2가 쓰이도록 되어있어요.
패턴맵 4장을 쓰려면 VRAM 맵을 조절하면 됩니다. 스프라이트 영역도 당연히 옮겨야겠구요.
참고로, 스페이스 맨보우가 스크린4의 212라인 모드를 사용했습니다. 아마 다른 게임도 있을 듯 한데, 기억이 안나네요.
이렇게 Ponpoko 리메이크가 제작되었습니다.
이제 표준 MSX로 나왔던 기능들은 모두 써본 것 같네요.
안써본 기능이 MSX-Audio의 ADPCM 정도겠군요. 요놈은 조금 계륵 같은 존재지만... 훗날을 기약합니다~
그럼, 다음 편에서 이어집니다요~
국딩 시절 잼나게 했던 슈팅게임이었는데, 아마 해보신 분들이 많으실 듯요.
아이큐2000의 비트맵 그래픽으로 멋진 슈팅을 만들어보는 것이 당시 어린이들의 꿈이었는데요.
BASIC으로는 스프라이트만 움직이는 것도 버거웠고, 최소한 어셈은 써야되었죠 ㅎ.ㅎ
ASO 같은 슈팅 게임을 만들어보려다 포기한 결정적인 이유는 이거였습니다.
컴파일에서 만든 자낙EX, 알레스트 같은 슈팅 게임을 본 후였죠.
상용게임 제작사도 MSX로는 오락실 수준의 슈팅게임은 무리였구나 ㅠ.ㅠ
그렇게 시간은 흘러, GT를 쓰게 되고 기본적인 주변기기들과 DOS2 프로그래밍 환경이 준비되었네요.
이제 다시 국딩 어린이의 꿈을 이뤄봅시다! ASO 리메이크 ㄱㄱㄱ
ASO 같은 세로 슈팅 게임들은 모니터를 90도 돌려서 사용합니다. 세로 해상도가 높아요.
VDP의 오버스캔 트릭을 쓰면 212라인이 아닌 240라인을 출력할 수 있습니다.
이렇게 해도 화면이 조금 잘려서 답답합니다만, 이게 최선이니...ㅋ
VDP가 블랭킹 없이 계속 디스플레이를 출력하면, VDP 커맨드가 가속되는 구간도 함께 사라집니다.
최대한 60프레임으로 게임을 구현하려면,
VDP 커맨드로 비트맵 복사하는 것과 CPU가 직접 VRAM을 R/W하는 것을 잘 섞어야합니다.
특히 turboR의 고속모드에서는 VRAM R/W에 WAIT가 걸리니까, 이걸 최소한으로 줄여야죠.
스프라이트 컬러, 어트리뷰트 테이블만 업뎃(복사)하는 것도 부하가 꽤 됩니다.
이 테이블들은 VRAM에 더블버퍼로 넣어놨는데요.
처음 설계할 때, 60fps가 불가능하면 30fps로 구현하려고 계획했던 것 때문이었습니다요.
스프라이트도 페이지 플립을 할 수 있으니까요.
근데 실제로 돌려보니, 60과 30프레임의 차이가 하늘땅 차이 수준이라서 60fps 최적화로 갔습니다.
스프라이트 32개로는 화면에 움직이는 캐릭터(총알 포함)를 모두 표시하는 게 불가능합니다.
지상에서 움직이는 적들은 모두 비트맵이구요.
모든 총알들은 홀짝 프레임에 맞춰서 절반씩 교대로 표시합니다.
깜빡임으로 두배의 스프라이트를 쓰는 거죠.
공중에서 움직이는 적들은 모두 스프라이트 2장으로 처리합니다.
주인공 기체는 스프라이트 3장이구요.
보스는 화면의 절반을 덮을 정도로 큰 사이즈입니다.
이 녀석은 스프라이트나 비트맵 복사로는 60프레임으로 움직이는 게 불가능합니다.
그래서 보스의 움직임을 V9958의 H/W 스크롤로 처리하고,
나머지 스프라이트(주인공, 레이저, 총알 등)를 반대로 위치 보정해서 표시합니다.
게이머가 봤을 때에는 보스가 움직이는 것으로 느껴지겠죠?
마지막으로 사운드는 MAME 소스를 수정해서, 채널별 데이터를 덤프 후 가공해서 사용합니다.
오리지널이 OPL 사운드라서, MSX-Audio 또는 MoonSound 호환 카트리지로 구동할 수 있죠.
조이메가 지원도 넣어서, 기본 3버튼 + START 버튼(PAUSE 용도)으로 동작합니다.
ASO를 처음 해본 게 1986년으로 기억하는데요.
2012년이 되어서야 비슷하게 구현을 해보게 되었네요.
국딩 어린이의 꿈을 실현ㅋ turboR이 없었다면 시도도 안해봤을 작업이었습니다.
아래는 2022년에 출격씬을 추가한 버전의 영상입니다 ㅎ.ㅎ
그럼, 다음 편에서 이어집니다요~
테트리스, 누구나 아는 게임이죠?
문자 출력, VDP 커맨드, SPRITE, BGM 등의 기본 라이브러리를 테스트하기 위해 만들어봤습니다.
사실은...
라이브러리 문서를 만들다가 '어차피 보는 사람도 없는데 왜 시간낭비를 하고 있을까' 생각이 들어서,
문서를 폐기하고 참고용 샘플 코드를 넣기로 했거든요. 그 결과입니다 ㅎ.ㅎ
그래픽은 스크린 5를 쓰고 있구요. 패턴 데이터는 코드로 내장됩니다.
사운드 데이터는 MML을 쓰도록 되어있어서, 별도의 컨버터는 필요하지 않습니다.
바꿔말하면 DOS 프로그램인데 외부 데이터 파일을 하나도 안쓴다는 얘기죠.
이 때문에 ROM 빌드 샘플에도 활용이 됩니다. (이 부분은 나중에 따로 글을 써야겠네요)
아래는 테트리스의 동작 모습입니다.
DOS2용 기본 코드는 아래를 참고하세요.
https://github.com/sharksym/CPMEMU_HI-TECH_C/tree/master/EXAMPLE/2TETRIS
ROM 빌드는 아래를 참고하세요.
32KB 롬에 맞추느라 PSG BGM라이브러리만 사용했습니다.
FM BGM을 쓰려면 48KB 롬으로 빌드하면 될 듯요.
https://github.com/sharksym/CPMEMU_HI-TECH_C/tree/master/EXAMPLE/0HELLO.ROM
그럼, 다음 편에서 이어집니다요~
DOS2에서는 서브디렉토리, 환경변수를 쓸 수 있어서 편리합니다.
메모리매퍼용 확장 BIOS가 포함되어서, 여러 프로그램들이 충돌없이 메모리를 활용할 수 있죠.
시스템 세그먼트에 로딩되면 램상주가 가능하니까, 용량 큰 프로그램을 제작할 때도 편리합니다.
초기 로딩 한번이면 이후는 빠르게 구동할 수 있어요.
예전 ST가 처음 나왔을 때에는 가용 메모리가 적어서 사실 DOS2가 그닥 활용되지 않았지만,
지금은 넉넉한 메모리를 쓰는 분들이 많아서 걱정없는 코딩이 가능합니다 ㅎ.ㅎ
그럼, DOS2용으로 쓸만한 파일매니저를 만들어봅니다.
90년대 MS-DOS 시절, Mdir과 NC를 써보셨으리라 생각됩니다.
Mdir은 하나의 디렉토리 내에서 필요한 여러가지 작업하거나 파일 확장자에 따른 메뉴 처리가 편하구요.
NC는 두개의 디렉토리를 비교하거나 같이 작업할 때, 또는 DOS 출력과 파일목록을 동시에 볼 때 편리하죠.
M 파일매니저의 이름에서 눈치를 채셨겠지만, 기본적으로 Mdir의 장점을 많이 가져왔습니다.
대신 NC의 듀얼 패널 형태의 디스플레이를 사용합니다.
디렉토리 복사 시, 재귀로 동작하니까 서브디렉토리를 함께 복사할 때도 편리합니다.
인터레이스 모드에서 한글폰트(16 x 16) 출력을 위해, 영문폰트도 8 x 16 사이즈를 사용했구요.
기본 영문,한글 폰트는 프로그램에 내장됩니다.
폰트팩이 존재하는 경우는 폰트팩의 데이터를 우선으로 사용하도록 되어있어요.
기본 디스플레이 영역은 512 x 424입니다만,
H/W 스크롤로 아래 영역의 VRAM도 모두(512 x 512) 사용합니다.
메모리매퍼와 VRAM을 마구마구 써버리는 프로그램이 되었죠 ㅎ.ㅎ
그 외, IMS, MP3 플레이어와 LED 비주얼라이저가 들어갑니다. 간단한 그래픽 파일 뷰어도 내장했구요.
M의 메인 화면을 유지한 상태에서 외부 프로그램을 백그라운드로 실행하는 기능도 있습니다.
초기에는 인터레이스 모드 전용이었는데, 넌인터레이스 영문 디스플레이 전용 옵션도 들어갔습니다.
고속모드가 없는 일반 MSX2에서도 그럭저럭 쓸 수 있게 되었죠.
최근에는 개선된 LFN 모드와 WAU용 MP3 스트리밍과 간이 브라우저 기능도 들어갔네요.
앞으로 새로 나오는 주변기기가 있다면, 내장기능도 계속 추가되겠습니다.
첫 버전이 2010년에 나왔으니까 참 오랫동안 개발중인 프로그램입니다요.
아마 제가 실기 사용을 멈추는 날까지 버전업이 되겠죠? ㅎ.ㅎ
아래는 LFN 모드에서 MP3 플레이어가 동작하는 모습입니다.
그럼, 다음 편에서 이어집니다요~
그래픽 라이브러리는 인터레이스 모드에서 쓸 수 있도록 만들었습니다.
참고로, 인터레이스 관련된 기능은 BASIC에 구현이 안되어 있는데요.
이게 VDP의 인터레이스 출력은 단순히 두개의 VRAM 페이지를 홀짝 필드에 맞춰 전환하는 기능뿐이거든요.
따라서 VDP 커맨드도 인터레이스 출력과는 무관하게 VRAM에서만 동작합니다.
결국 소프트로 다 처리해야한다는 얘기죠.
사실 80,90년대에는 인터레이스 모드를 쓸 생각을 전혀 안했습니다.
2000년대 들어서니, 대부분의 TV/모니터에 디인터레이서가 탑재되고, 100Hz/120Hz 같은 기능도 들어갔죠.
이제는 GT에서 CALL KANJI2 등의 인터레이스 모드를 써도 깔끔하게 볼 수 있습니다.
480i를 활용해도 좋은 시절이 되었습니다요~ ㅎ.ㅎ
인터레이스 테스트용으로 한글 문서를 볼 수 있는 프로그램을 만들게 되었구요. 이름이 HV입니다.
한글 폰트는 844 조합형을 내장했습니다. 용량이 작으니까 부담이 없죠.
문제는 KS C 5601 전체를 지원하려면, 특수문자 37KB, 한자 153KB를 로딩하는 부담이 있었네요.
결국, HV는 아스키, 한글폰트만 내장하도록 했습니다.
대신 특수 문자와 한자 폰트가 메모리로 로딩되어 있으면 활용 할 수 있도록 구성했죠.
폰트는 메모리매퍼의 시스템 세그먼트로 로딩해서 계속 램상주가 되니,
다른 프로그램에서도 활용할 수 있는데요. M 파일매니저에서도 이용하고 있습니다 ㅎ.ㅎ
예전에 이걸 공개했을 때에도 관심을 보인 분이 1명도 없어서, 폰트 인터페이스는 따로 오픈안했어요ㅋ
지금은 폰트팩이 있으니 따로 로딩할 필요도 없어졌구요. SLT-Turbo는 폰트팩 V2가 내장이라~ ㅎ.ㅎ
암튼, 램상주 폰트는 아래 링크를 참고하세요.
순정 GT에 로딩하면 메인램 절반이 날아가는 마법! ㅎ.ㅎ
특수문자 폰트는 메모리매퍼 64KB를 점유합니다.
https://sharksym.blogspot.com/2014/10/ksspe-v10-ks5601.html
한자 폰트는 메모리매퍼 160KB를 점유합니다.
https://sharksym.blogspot.com/2014/10/kshanja-v10-ks5601.html
현재 HV는 폰트팩이 있으면, 해당 폰트를 우선으로 사용하구요.
폰트팩이 없으면 프로그램 내장 한글과 램상주 폰트(특수문자, 한자)를 사용합니다.
UTF-16 유니코드도 지원하니까, 예전 윈도에서 쓰이던 유니코드 문서를 활용할 때도 좋습니다.
아래는 최신 버전의 HV입니다.
https://sharksym.blogspot.com/2022/01/hv-v16-hangul-viewer-for-msx-dos2.html
그럼, 다음 편에서 이어집니다요~
이번 글 부터는 제가 만들었던 프로그램들과 그에 관련된 툴, 라이브러리 설명을 붙여보겠습니다.
대략 시간순으로 등장한다고 보시면 맞습니다~ ㅎ.ㅎ
그럼, 'IMS 플레이어'부터 시작합니다.
IMS 파일 아시죠? PC의 애드립, 사운드블라스터에서 OPL2를 이용한 음악파일인데요.
이걸 MSX-DOS2에서 연주해주는 프로그램을 만들어봤습니다.
기본적으로 MoonSound를 위해 만든 플레이어지만, OPLL만으로도 플레이 가능합니다.
BNK로 쓰이는 악기 이름과 비슷한 OPLL 내장 악기를 선택해주는 방식입니다.
이 프로그램은 메모리매퍼를 활용하는 가장 기본적인 프로그램입니다.
OPL4, OPLL을 위한 플레이어 루틴이 서로 다른 뱅크에 배치되어있습니다.
플레이 시, 어차피 하나의 칩만 사용할테니까 모든 코드를 하나의 뱅크에 넣으면 뱅크 용량만 커지겠죠?
일반적인 IMS 파일은 32KB ~ 128KB 정도입니다.
이 IMS 파일을 한번에 로딩하기 위해 메모리매퍼 세그먼트를 동적으로 할당하여 사용합니다.
만약 제가 90년대에 아이큐2000용으로 플레이어를 만들었다면?
아마 IMS 데이터를 VRAM에 로딩하는 방식을 썼을 것 같네요.
이제는 넉넉한 메모리로 편하게 프로그래밍을 할 수 있습니다. 역시 목마른 사람이 우물을 파는 게 좋아요.
그리고, turboR의 고속모드를 활용하려면 적극적으로 내장 메모리을 이용해야합니다!
아래는 IMSP 초기버전의 동작영상이니 구경하셔요~ ㅎ.ㅎ
아시다시피, M 파일매니저에 OPL4 전용의 IMSP 기능이 내장되어 있어서, 이젠 저도 안쓰는 프로그램이 됐지만...
만약 OPL4 사운드 카드가 없으시면 OPLL도 지원되니, 한번 트라이해보세요 ㅎ.ㅎ
아래 페이지에서 다운받을 수 있습니다.
https://sharksym.blogspot.com/2019/04/imsp-v06-ims-player-for-msx-dos2-2019.html
그럼, 다음 편에서 이어집니다요~
디스크롬의 뱅킹을 얘기하려는 것은 아니구요.
확장 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
그럼, 다음 편에서 이어집니다요~
조용한 일요일 오후입니다. 밥먹고 잠깐 글을 적어봅니다요 ㅎ.ㅎ
국딩 때 아이큐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년을 그림자처럼 따라다니고 있습니다요.
즐거운 오후되셔요~ ㅎ.ㅎ/
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 프로그램을 만들게 되었네요.
그럼, 다음 편에서 이어집니다요~
MSX-DOS 얘기입니다만, MS-DOS도 잠시 나오니 당황하지 마시고~ ㅎ.ㅎ
옛날 얘기부터 나갑니다요~
국딩 때는 MSX-DOS의 명령어와 Disk BASIC의 명령어가 비슷해서 머리가 어지러웠던 기억이 나네요.
예를 들면요.
COPY 명령은 BASIC과 DOS가 똑같은 복사를 의미하지만,
BASIC에서는 VRAM 데이터를 디스크에 저장/로드가 가능합니다.
물론 DOS에서는 DEVICE로 복사도 가능하죠.
파일을 삭제하는 명령은 BASIC에서는 KILL을 쓰고, DOS에서는 DEL을 쓰죠.
근데 어린이의 머리를 가장 복잡하게 한 것은...
BASIC으로는 DOS용 프로그램(*.COM)을 만들지 못한다는 거였습니다.
그 시절엔 파스칼, C 등의 컴파일러가 존재한다는 것도 몰랐고,
그냥 파워업 테크닉, 기계어 입문 등의 책을 보면서 어셈블리를 하게 되었는데요.
Disk BASIC으로 만든 BASIC 코드에 어셈 코드를 섞어서 만드는 식으로 프로그래밍을 했었죠.
VDP 커맨드 등의 어려웠던 부분은 BASIC 명령을 쓰고, 간단한 루틴만 어셈을 쓰는 구조로...ㅋ
드디어 중딩 때 'MSX-DOS 슈퍼핸드북' 번역본을 사서 DOS 프로그래밍에 도전을 했습니다.
아래의 책입니다. 아마 갖고 계신 분이 많을 듯요.
뒷장을 열어보니 제일서적에서 구매했었네요 ㅎ.ㅎ
DOS에서는 전체 64KB 메모리(물론 WORKAREA는 제외하구요)를 쓸 수 있다는 장점이 있습니다.
근데 공부를 해보니,
일단 FCB로 파일 입출력도 어렵고, BASIC의 도움을 받던 코드를 모두 어셈으로 코딩해야하니...
결국 간단한 코드만 테스트해보고, DOS 프로그래밍은 포기했네요 ㅠ.ㅠ
BASIC + 어셈 스타일로 다시 돌아가서 고딩시절까지 쭈욱~ 지나왔습니다.
대학 입학 후에는 486 PC를 쓰면서 C를 공부하기 시작했구요.
486의 어마어마한 속도과 컴파일러의 힘으로 MSX Z80 시절의 코딩과는 멀어졌습니다.
대학 시절에는 MS-DOS용 FEEDBACK도 만들어보고, DJGPP로 fMSX를 포팅해서 놀다가 입대를 했네요.
98년에 제대하고 돌아왔더니, 이젠 윈도 PC가 대세였고 부두2의 3D 그래픽으로 난리였던 시절이 됐습니다.
그렇게 DOS 프로그래밍에서 멀어졌네요.
생각해보니 제가 DOS용 프로그래밍을 했던 기간이 3년정도 되더라구요.
.
.
.
시간은 흘러 2003년이 되었습니다.
무작정 '터보알을 써보자'라는 생각이 들어 파나소닉 A1GT를 구했는데요.
이리저리 테스트를 해보니 생각보다 성능이 꽤 좋더라구요.
게다가 DOS2 내장에 롬디스크, 램디스크를 활용하니까 너무 편하구요.
근데 터보알에서 FDD를 써야한다면 죽도 밥도 안되겠더라구요.
나중에야 알게 됐지만, 일본에서는 이미 80년대에 MSX-DOS2 카트리지와 HDD 인터페이스를 팔았더라구요.
90년대에는 MEGA-SCSI 등의 자작 인터페이스도 유행했었구요.
물론 저는 구경도 못 해봤다는 거ㅋ
먼저 SD카드로 대용량 고속 디스크 기기를 만들어야겠다는 결론에 도달합니다.
다시 MSX-DOS 프로그래밍을 해야되니, 이제는 C를 쓰면 편하겠지? 라고 생각도 했구요.
여기까지가 서론이었네요.
그럼, 다음편에서 이어집니다~ ㅎ.ㅎ
87년에 나온 FM 사운드 기기입니다.
외부 디자인은 86년식 파나소닉 MSX2 FS-A1에 맞춘 걸로 알고 있어요.
Y8950칩으로 구성되어, OPL(YM3536)의 FM 사운드와 4bit ADPCM 32KB(256KB 확장가능)를 가집니다.
MSX의 기본 사운드칩인 PSG에 비하면 어마어마한 사양이죠.
한가지 문제라면...
MSX2 본체 FS-A1 = 29800엔
MSX-Audio FS-CA1 = 34800엔
본체랑 사운드카드 가격이 바뀐 것 같은 느낌입니다 ㅎ.ㅎ
결국 나중에 나온 저가형 MSX-Music가 성공하면서 MSX-Audio는 이름만 남았습니다.
그래도 아스키, 컴파일에서 나온 S/W가 MSX-Audio를 지원하는 경우가 조금 있었어요.
Y8950은 필립스의 NMS-1205 (Music Module)으로 유럽에서 유행했습니다.
Audio BIOS가 빠진 기기라서, 사실 MSX-Audio라고 부를 수는 없지만요.
개조용 보드를 붙여서 Audio BIOS와 샘플램 256KB 확장해서 쓰는 것도 유행했습니다.
저는 샘플램만 256KB로 개조해서 썼던 추억이 있네요 ㅎ.ㅎ
이제 21세기가 되어서, 예전의 MSX-Audio 사운드를 쓰려는 분들이 많이 나왔습니다.
오리지널 FS-CA1은 덩치가 커서 실사용하기엔 좀 불편하구요.
호환 기기(뮤직모듈 등)를 쓰거나 제가 만든 MoonBase랑 선라이즈의 MoonSound를 조합하는 걸 추천합니다.
MoonBase와 MoonSound (또는 호환 OPL4 카트리지)를 연결하면,
본체에서는 MSX-Audio로 인식해서 사용가능합니다. 물론 샘플램은 256KB 최대치로 되어있어요.
MSX S/W는 FM 사운드 사용 시, 대부분 아래의 4가지 시나리오를 따릅니다.
MSX-Audio 전용
MSX-Music 전용
MSX-Music + MSX-Audio
OPL4 전용
MoonBase는 내부에 OPL 칩이 없지만,
MSX-Audio 포트를 OPL4의 2번 FM 사운드 포트로 연결해서 구동합니다.
참고로 OPL4의 FM 사운드는 OPL3로 되어있구요.
OPL3는 OPL2 x 2개를 합친 기능이죠.
결국 MoonBase + MoonSound (OPL4) 구조에서
MSX-Audio 전용, MSX-Music + MSX-Audio 조합, OPL4 전용
시나리오를 커버할 수 있게 됩니다.
슬롯 1개만 쓰는 환경으로 가장 편한 방법이에요 ㅎ.ㅎ
그리고,
MoonBase는 OPLL용 드럼 사운드를 PCM 사운드로 출력하는 기능도 있으니,
MSX-Music을 쓰는 경우에도 강력한 드럼 사운드를 즐길 수 있습니다.
부팅 시 M을 눌러 PCM 드럼 사운드 모드로 전환하거나,
MMCSD.COM 에서 /Mxx 옵션을 사용하면 됩니다.
예) /M04 드럼셋 1번, 볼륨 4
/M15 드럼셋 2번, 볼륨 5
그럼, 21세기 MSX 활용편은 이번 MSX-Audio로 마무리합니다.
MSX 표준기기로 포함되지 않은 기기들도 많이 있습니다만,
해당 기기를 갖고 계신 분들은 이미 용도를 잘 아실테니 넘어갑니다요~ ㅎ.ㅎ
-> SCC, SCC-I, SFG (YM2151), MoonSound (OPL4), V9990, Sec-PSG, DCSG, T-Wave, Darky, NeoTron, MIDI-PAC 등
[서론]
이름은 익숙하지만 의외로 기능을 잘못 알고 계시는 분들이 있으세요.
제대로 알고 계신다면 [본론]으로 건너뛰세요! ㅎ.ㅎ/
슬롯 한개를 여러개로 나눠주는 것으로 이해하시는 분들이 많더라구요.
'본체의 기본슬롯에 확장슬롯을 꽂으면 4개의 서브슬롯으로 나눠집니다'
이 설명을 오해하면 다음에 이런 질문도 하게 됩니다요.
'그럼, 확장슬롯에 확장슬롯을 꽂으면 슬롯이 팍팍 늘어나겠네요! 맞죠?' ㅎ.ㅎ
일단 잊으시고, 이렇게 생각해보세요.
MSX의 슬롯은 16개의 서브슬롯(SUB0,1,2,3)으로 구성되고, 4개씩 묶어서 기본슬롯 번호가 붙어있습니다.
이름은 SLOT 기본슬롯번호-서브슬롯번호 순으로 붙입니다.
SLOT 0-0, 0-1, ... 3-3 까지 16개가 존재하게 됩니다요.
만약 서브슬롯이 존재하지 않는다면, 기본슬롯 1개로 동작이 됩니다.
예를들어 기본슬롯인 SLOT 0가 있다면, 서브슬롯인 SLOT 0-0,0-1,0-2,0-3은 없다는 얘기입니다.
대부분의 본체에서 상단/전면에 노출된 슬롯 커넥터는 SLOT 1입니다.
두번째 노출된 슬롯은 보통 SLOT 2 또는 3이 됩니다.
SLOT 0는 BIOS 롬이 탑재되니까 본체에 내장됩니다.
원래 슬롯 배치는 본체 제작사가 맘대로 결정할 수 있지만, MSX2+부터는 비슷하게 정해져있습니다.
SLOT 0-0,0-1,0-2,0-3 -> 본체 내장
SLOT 1 -> 외부 노출 슬롯
SLOT 2 -> 외부 노출 슬롯
SLOT 3-0,3-1,3-2,3-3 -> 본체 내장
슬롯을 설명할 때 기본슬롯, 서브슬롯 순으로 설명하는 것이 정석이지만,
이번에는 반대로 설명을 해봤습니다.
[본론]
확장슬롯 기기는 본체에 노출된 기본슬롯에 꽂아서, 기본슬롯을 서브슬롯 4개로 바꾸는 역할을 합니다.
SLOT 1에 확장슬롯을 꽂으면 SLOT 1은 없어지고, SLOT 1-0,1-1,1-2,1-3 이렇게 생성되겠죠?
서브슬롯 2개 또는 3개만 들어있는 제품도 있으니 참고하시구요.
A1GT처럼 전원부가 빵빵한 기종은 괜찮을 수 있지만,
대부분의 기종에서는 확장슬롯을 고를 때 외부 전원을 입력받는 제품을 추천합니다 ㅎ.ㅎ
확장슬롯 중에는 서브슬롯 4개 외 I/O 슬롯이 추가된 경우도 있는데요.
원래 MSX에서는 이런 I/O 슬롯은 표준이 아닙니다만...
I/O 포트만으로 동작되는 기기를 쓰거나, 카트리지 내의 S/W를 강제로 OFF하고 I/O 기능만 쓸 때도 사용할 수 있죠.
이런 확장슬롯을 쓰려면, 내가 어떤 의도로 사용하는지를 명확히 알고 있어야하겠습니다.
만약 주변기기가 많지 않다면, 일반적인 확장슬롯(4SLOT) 하나만 있으면 충분한데요.
상단/전면의 슬롯은 게임 카트리지 등을 잠깐 꽂는 용도로 비워두고,
후면 슬롯에 확장슬롯을 장착하고 주변기기들을 주르륵 꽂아두면 대부분의 사용 시나리오를 커버할 수 있겠습니다.
제가 예전에 서브슬롯 4개 + 본체개조 SLOT 0-1 + I/O 슬롯으로 구성된 확장슬롯(슬롯 커넥터 6개)을 이렇게 썼습니다.
본체의 상단 SLOT 1에는 SCC-I 카트리지를 꽂아서 쓰다가, 가끔 게임팩을 꽂을 때 SCC-I랑 맞교대를 했었죠 ㅎ.ㅎ
만약 본체의 기본슬롯 2개에 확장슬롯 2개 꽂아서 쓰면, 공간도 많이 차지하고 케이블 관리도 귀찮게 되는데요.
제가 지난 20년간 여러 종류의 확장슬롯을 만들어서 쓰다보니, 최종으로 결정된 방식은 SLT-X V2입니다.
SLT-X가 뭔지 모르시는 분은 아래 글을 참고하시면 되겠습니다.
https://sharksym.blogspot.com/2026/07/slt-x.html
두 슬롯의 예약핀인 16번과 /SLTSL 핀 4번을 서로 교차하도록 개조를 하면,
SLT-X는 케이블 하나만으로 2개의 기본슬롯 신호를 받게 되니까, 서브슬롯 8개로 동작하게 됩니다.
확장슬롯을 쓰다보면 가끔 난감한 경우가 발생하는데요.
서브 슬롯에 장착된 기기를 인식 못하는 S/W가 가끔 있습니다.
유저가 자작한 프로그램에서 종종 발생하구요. 대충 만든 상용 프로그램들에서도 발견됩니다.
또는 카트리지 내부에 확장슬롯이 포함되어 있어서, 확장슬롯에 꽂으면 제대로 못 쓰는 경우도 있죠.
SLT-X에서는 이런 경우를 잠깐 회피하기 위해,
서브슬롯 1개를 기본슬롯으로 전환하고, 나머지 서브슬롯 3개는 I/O 슬롯으로 동작하도록 만들 수 있습니다.
본체의 리셋 버튼을 눌러도 이 설정은 유지되기 때문에, 서브슬롯 인식 문제를 피할 때 유용하게 쓸 수 있어요.
전원을 완전히 OFF 후 다시 ON 하면, 설정이 초기화되어 일반 서브슬롯로 돌아갑니다.
SLT-Turbo v2.1을 쓸 때에도 SLT-X V2를 연결하면 같은 방식으로 사용가능합니다.
사실 SLT-X 만들 때, SLT-Turbo를 고려해서 단순한 구조를 맞추려다 보니 그렇게 되긴 했네요. 흐...
암튼, 확장슬롯은 본인의 사용 환경에 맞춰 구성하시면 되겠습니다.
그럼, 다음 편에서 이어집니다...
40년전 MSX1,2에 내장된 한글은 N바이트, 2바이트 조합형 한글이었습니다.
80년대 후반부터 PC에서는 완성형 한글인 KS C 5601 (KS X 1001)가 쓰였고,
윈도95에서는 기존 완성형에서 빠진 한글을 채워넣은 CP949가 쓰였지요.
지금은 대부분 유니코드가 쓰이고 있습니다.
결국 이제 MSX에서 한글을 제대로 쓰려면 CP949, 유니코드를 지원하는 기기가 필요하다는 얘기겠죠?
MSX의 디스크의 최대 강점이라면, DOS의 FAT12, FAT16을 그대로 쓸 수 있다는 점인데요.
주변 기기의 도움을 받으면 LFN (Long Filename)에 쓰이는 UCS-2 (유니코드 BMP)도 쓸 수 있습니다.
윈도 SD카드의 폴더, 파일명을 한글로 길게 만들더라도, MSX에서도 똑같이 표시 가능합니다.
약간의 문제라면,
일본 내수 모델인 MSX2+, turboR에는 일어, 한자 입력기가 내장되어 있고,
DOS2에서 파일/폴더명의 마지막 문자가 ASCII 코드가 아니면 액세스 에러가 되는 경우가 생길 수 있습니다.
LFN을 쓰는 경우는 8.3 파일명의 끝이 ~1, ~2 등의 숫자로 끝나도록 바뀌므로, DOS2에서 문제가 생기지 않습니다.
한글을 활용할 때 필요한 주변기기로는 FontPack과 WAU 카트리지가 있습니다.
@ FontPack
FontPack의 ANSI 스크린은 64컬럼, 85컬럼을 지원합니다.
한글 폰트 사이즈는 16 x 16 및 12 x 12입니다.
한글/한자 입력기는 조합형, 완성형 모드를 지원합니다.
그 외 문자 코드 변환과 스크린 5,6,7용 컬러 데이터 출력 기능이 있어서, 빠른 처리가 가능합니다.
BASIC에서는 한글 출력 전용의 FNP: 디바이스가 추가되어있어서,
프로그램에서 일제 본체에서 기본 일어 출력(GRP:)과 한글 출력(FNP:)을 병행할 수 있습니다.
MSX2+,turboR 등에서 대우의 아이큐교실, X-II 튜터, 과일 데모 등의 예전 프로그램을 활용 가능합니다.
FontPack V2의 유니코드 폰트롬이 필요한 경우는,
M 파일매니저에서 LFN을 쓰거나, MP3의 ID3v2 tag를 사용할 때
HV (한글 뷰어)에서 유니코드 텍스트(UTF-16)를 처리할 때
SLT-Turbo v2.1에는 고속처리를 위해 FontPack V2가 내장되어 있으니,
외장형 FontPack 카트리지를 함께 사용하면 안됩니다!
@ WAU
80 x 25 터미널 모드 전용의 CP437, CP949 폰트롬이 들어있습니다.
한글 폰트 사이즈는 12 x 16이며, 스크린 5,7용 컬러 데이터 출력 기능이 있어서, 빠른 처리가 가능합니다.
WTERM의 뷰어 모드를 사용하면 텍스트문서를 보는 용도로 쓸 수 있습니다.
그럼, 다음 편에서 이어집니다...
DSK 에뮬은 디스크 이미지 파일(*.DSK)을 일반 디스크(2DD, HDD)처럼 구동하는 것을 의미합니다.
상용 디스크 게임들은 대부분 1DD, 2DD 등의 3.5인치 디스켓으로 출시가 되었죠.
이런 게임 S/W들의 특징이 하나 있는데요.
파일 단위의 데이터 액세스를 하는 것이 아니라 절대 섹터 단위로 테이터 액세스를 하는 경우가 많습니다요.
결국 대용량의 디스크가 있더라도, 이런 S/W를 복사해서 실행하는 것 자체가 불가능하다는 얘기입니다.
게임을 만드는 입장에서 FCB 등의 파일핸들을 쓰지 않고 섹터를 직접 R/W하면, 속도는 빠르겠죠.
데이터를 연속으로 저장해놓으면 당연히 액세스 효율도 좋겠죠.
결국, 대용량 디스크를 쓰면서 2DD 게임을 실행하려면, 디스크 이미지 파일을 이용하는 방법뿐입니다.
실제로 구현하는 방법은 여러가지가 있겠지만,
저는 멀티 파티션 방식과 DSK 파일 방식을 썼습니다.
@ 멀티 파티션 방식
주 작업 환경이 MSX-DOS인 경우 쓰기 쉽도록 만들어졌는데요.
대용량 디스크에 수천개의 2DD 파티션을 만들고, 각 게임 DSK 파일을 복사해서 리스트를 만들어둡니다.
이걸 드라이브 A:의 파티션을 교체하는 식으로 게임을 실행하도록 했었죠.
파티션 관리를 위한 DISKMAN 이라는 전용 프로그램을 사용합니다.
일반 작업용 부팅 파티션에서는 일반 프로그램으로는 2DD 저장용 파티션에 접근할 수가 없어요.
드라이브 리스트에는 보이지 않습니다.
파티션의 섹터들을 순서대로 나눈 거라서, 에뮬하는 S/W쪽에서는 굉장히 안전하게 쓸 수 있는 장점이 있죠.
이 방식은 MMC/SD V1, V2 시절에 쓰였습니다.
당시에는 램 64KB뿐인 기본 MSX2를 쓰는 분이 많아서, MSX-DOS를 기준으로 기기를 만들어야하는 숙제(!)가 있었지요.
@ DSK 파일 방식
여러분들이 MMC/SD V2를 수년간 쓰면서, MSX-DOS2의 편리함과 FAT16 대용량에 익숙해졌습니다.
그러면서 본체램 512KB 증설 개조도 유행했지요.
M 파일 매니저 같은 MSX-DOS2 전용 프로그램도 많이 쓰이게 되었구요.
DOS2의 서브디렉토리, FAT16의 대용량 드라이브가 있다면...?
DISKMAN으로 파티션 교체하는 방식 보다는, *.DSK 파일들을 디스크롬에서 직접 에뮬을 해주는 것이 편하겠더라구요.
사용자 입장에서는 SD카드를 윈도에 연결해서 파일,폴더를 관리하는 것도 훨씬 편하게 느껴지겠죠.
DSK 파일이 크니까 실기에서 직접 복사하는 것도 꽤 인내가 필요합니다ㅋ
DSK 파일 에뮬의 가장 큰 걸림돌은,
S/W에서 물리 섹터 R/W 요청이 왔을 때, 흩어진 클러스터에서 파일 연결을 찾고, 실제 섹터로 R/W 해주는 부분이 되겠습니다.
원래는 DOS에서 처리하는 작업이겠지만, 에뮬이니까 MMC/SD 디스크롬 내에서 처리를 해야겠죠.
암튼 그렇게 구현이 되어서 지금까지 십여년간 잘 쓰이고 있습니다요 ㅎ.ㅎ
@ 현재 MMC/SD V3, V4의 DSK 에뮬은 이렇게 지원되니 참고하세요.
- 1DD/2DD 디스크 이미지 최대 10장 (멀티디스크 전환 가능)
- HDD 이미지 최대 32MB (FAT12 기준)
- ONE-Drive 기능 지원 (본체에 내장된 FDD를 무력화)
- 디스크롬 전환 (DOS1 또는 DOS2)
그럼, 다음 편에서 이어집니다...
HRA! 아자씨가 FPGA MSX2++, MSXtR을 만들고 있다는 건 다들 아실텐데요.
어제 엑스에 MSXtR의 고속모드의 기본 타이밍을 확인한 글이 올라와서 긁어왔습니다 ㅎ.ㅎ
디스크롬을 끈 상태라서, BASIC에서 별도의 고속모드 전환 코드를 실행 후 테스트 코드를 돌렸군요.
참고로, 저의 GT에서 SHIFT키를 눌러 디스크롬을 해제하고 돌린 모습입니다.
BASIC 코드도 똑같이 타이핑했어요 ㅎ.ㅎ
아래는 SLT-Turbo에서 SLT-X를 끄고, SHIFT 눌러서 부팅 후 디스크롬을 해제한 상태입니다.
세 기기에서 결과가 비슷하게 나오네요.
사실, 이 테스트 에서는 CPU, RAM, ROM(BIOS), PPI, PSG, VDP I/O 정도만 사용되니까,
전체적인 turboR 타이밍 비교랑은 약간 거리가 있긴 합니다만...
제일 중요한 기본 회로의 타이밍 확인으로 볼 수 있습니다요 ㅎ.ㅎ
이번에는 MMC/SD Drive V4의 메가램 및 GameRunner II에 관한 내용입니다.
2015년 MMC/SD V3를 만들기 전까지는 메가롬 게임을 실행할 때, 아래 기기를 조합해서 썼습니다.
MMC/SD V2 멀티롬, 코나미 SCC-I 128KB, 디럭스박스
근데 대부분은 MMC/SD V2 멀티롬을 쓰게 되더라구요.
아무래도 메가램 기기들은 게임을 로딩 후 일반 DOS2로 재부팅 시 번거롭기 때문이었는데요.
메가램 내의 램 내용이 지워지도록 전원 OFF 상태로 10초 이상 기다려야했죠.
특히 롬 테스트 용도로 사용하기엔 너무 귀찮아서...ㅎ
MMC/SD V2는 기본 부팅이 디스크롬이라서, 멀티롬 상태에서 리셋되면 바로 디스크로 돌아갑니다.
그래서 MMC/SD V3,V4의 메가램을 넣을 때에도 V2의 멀티롬처럼, 기본 부팅은 디스크롬으로 되도록 했죠.
디스크롬으로 부팅된다는 것을 바꿔말하면,
시스템에서는 메가램이 보이지 않게 된다는 의미입니다.
MMCSD.COM 프로그램에서만 롬파일 로딩 시, 내부 모드를 바꿔서 메가램쪽으로 로딩할 수 있습니다.
V4에서는 디스크롬에서 SD카드의 파일을 바로 메가램의 SRAM으로 바로 전송합니다.
DOS2의 DISK I/O 루틴을 쓰지 않기 때문에 로딩이 꽤 빠릅니다.
MSX-DOS와 MSX-DOS2는 디스크 액세스 시 큰 차이가 하나 존재하는데요.
MSX-DOS는 디스크와 다른 슬롯의 메모리로 직접 R/W가 가능합니다만,
MSX-DOS2는 무조건 메모리매퍼(데이터 세그먼트)를 쓰도록 되어있습니다요.
기기(슬롯)간의 다이렉트 전송이 불가능한 대신 일정한 전송속도을 얻게 되었죠. 빠릅니다!
참고로, MSX-DOS는 메모리 영역(주소)에 따라 전송 속도가 제각각입니다.
아마 turboR을 주로 쓰시는 분들은 아시겠지만,
MSX1에서만 동작하는 게임도 있고, 확장슬롯에서는 오동작하는 게임도 있고 그렇죠.
국산 아이큐1000,2000 전용 프로그램도 있구요.
그래서, paraMSX-R에서 구현했던 머신 에뮬의 기본 슬롯 처리만 V4에 살짝 넣었습니다.
본체를 MSX1, MSX2, MSX2+ 하위 기종처럼 보이도록 해주는 것이죠.
여기에 MSX1,2 모드에서는 JP,KR,EU BIOS도 선택가능합니다.
여기에 BIOS, 메가램과 디스크롬, 메인램이 모두 기본슬롯에 배치됩니다.
슬롯 구조에 따른 호환성에 문제가 있는 프로그램을 커버하기 위함이죠.
이 기능이 GameRunner II입니다.
수년을 거쳐 MMC/SD V4까지 오게 되니, turboR에서 불편했던 것들이 한방에 해결되었습니다요.
MMC/SD의 메가램, 멀티롬(FlashROM) 기능을 요약하면,
V1,V2 = 멀티롬 384KB (2메가롬 가능)
V2 Multi-ROM II = 멀티롬 512KB x 15개 (7.5MB)
V3 = 메가램 1MB + 서브롬 1MB
V4 = 메가램 2MB + 서브롬 4MB
마지막으로 하나 더 적어봅니다.
코나미 SCC, SCC-I 칩의 롬매퍼 기능인데요.
SCC 매퍼 -> 최대 512KB 롬
SCC-I 매퍼 -> 최대 128KB 램
으로 구성됩니다.
에뮬레이터(S/W 에뮬 및 CPLD,FPGA 구현)에서는
8K 매퍼의 최대용량인 2048KB 메모리를 SCC, SCC-I 매처로 설정하는 경우가 있습니다.
2000년 이후에 만들어진 게임 중에 이런 에뮬을 활용하는 경우가 있으니 참고하세요.
반대로, SCC-I의 경우는 128KB를 넘는 메모리를 쓰면 오동작하는 프로그램(예: SCMD)도 있습니다.
MMC/SD V4와 T-Wave의 SCC-I 매퍼에는 128KB, 512KB 등으로 제한하는 기능이 들어간 것도 이 때문입니다.
다음 편은 DSK 에뮬 이야기로 이어집니다...
카트리지 중 주변기기로 제작된 것들을 제외하면, 순수 S/W로 된 ROM 카트리지가 남습니다.
이런 카트리지의 롬을 덤프하면 대략 아래의 4가지 종류가 나옵니다.
- 유틸리티 16KB, 32KB
- BASIC 게임 16KB
- 게임 16KB, 32KB, 48KB, 64KB
- 게임 메가롬 (128KB ~ )
MSX1 용 프로그램(유틸, 게임 등)은 램 요구사항이 8KB 또는 16KB입니다.
BASIC 게임은 코드가 Page 2로 매핑되도록 정해져 있어요.
용량이 16KB, 32KB, 48KB인 롬들은 램 64KB 기종에서 쉽게 에뮬을 할 수 있습니다.
주의 할 부분은, 여기서 램 64KB는 단일 슬롯에 장착된 램을 의미한다는 건데요.
만약 램 32KB 달린 MSX1의 외부 슬롯에 32KB 확장램을 장착하면?
MSX-DOS를 쓸 수는 있지만 게임롬 에뮬은 불가능합니다.
보통 게임 코드는 자신의 코드가 같은 슬롯에 있기 때문에 기동 시, Page 1,2의 슬롯을 맞춰주게 되는데요.
슬롯이 서로 다른 경우는 엉망이 되면서 실행이 불가능하게 됩니다.
물론 게임별로 하나하나 패치롬을 따로 만들면 되긴 하겠지만, 시간낭비겠죠?ㅋ
만약, 램 64KB인 기종의 Page 0,1,2 (0000H ~ BFFFH) 램에 롬을 로딩 후 재부팅하면 어떻게 될까요?
그 컴퓨터는 램 16KB 기종에 롬 카트리지를 꽂은 것처럼 동작하게 됩니다.
이런 이유로, 램 64KB 또는 128KB 기종이 주류였던 국내는 복돌이 천국이 될 수 밖에 없었죠.
물론 게임 제작사가 이걸 막으려고 카피프로텍션 코드를 넣었지만, 크랙은 뭐 금방이죠 ㅎ.ㅎ;
그럼, 남은 건 64KB 용량의 롬과 메가롬인데요.
16K 롬매퍼를 쓰는 64KB 롬 -> 메모리 매퍼로 에뮬가능
롬매퍼가 없는 64KB 롬 -> Page 3의 데이터 접근 코드를 별도로 구현하거나
8K 롬매퍼의 메가롬 -> 메모리 매퍼로 분할 로딩 시 속도저하 발생 (실사용 불가능)
16K 롬매퍼의 메가롬 -> 메모리 매퍼로 에뮬가능
메모리 매퍼로 에뮬을 하려면, 본체의 메모리 용량이 롬 사이즈 보다는 커야합니다.
자낙EX처럼 롬 사이즈가 112KB인 경우는 아이큐2000의 램 128KB에서도 에뮬이 가능합니다.
수퍼람보 스페셜은 타이틀 그래픽을 제거해서 용량을 줄여놓은 버전도 나오고 그랬네요.
문제는 MSX2 본체만으로 에뮬이 불가능한, 8KB 매퍼를 쓰는 메가롬인데요.
ASCII 8K, KONAMI 8K, KONAMI SCC 류의 매퍼를 쓰는 롬이 되겠습니다요.
이건 딱히 방법이 없죠.
롬 대신 램 카트리지에 매퍼를 넣어서 에뮬을 하는 방식을 사용했습니다.
80년대에 나왔던 블랙박스, 디럭스박스 류의 기기입니다요.
TTL 로직칩으로 범용 매퍼를 간단하게 구현해서 넣고,
게임롬에서 해당 매퍼를 쓰도록 패치해서 램 카트리지에 로딩하면 끝!
언제부터인지 이런 기기를 MegaRAM이라고 부르고 있는데, 저도 걍 그렇게 부르고 있네요.
코나미의 스내처, SD스내처에 들어있는 SCC-I 사운드 카트리지는 램이 64KB가 들어있는데요.
보드의 램을 128KB로 증설하면 1메가전용 메가램 카트리지로 쓸 수 있습니다.
SCC-I가 SCC 사운드 하위호환이 되기 때문에 사라만다, 파로디우스 같은 게임을 구동하는 용도죠.
그 외, SCC롬팩을 개조해서 512KB FlashROM을 넣으면, 현존하는 코나미의 게임은 다 실행가능한데요.
2000년대에는 이런 SCC플래쉬롬팩을 만드는 게 유행이었네요.
써놓고 보니 서론이 좀 길군요 ㅎ.ㅎ
롬 에뮬을 요약하면,
- 메인램 64KB 또는 메모리 매퍼 사용
- 메가램 카트리지 사용
- 플래쉬롬 카트리지 사용
나머지 롬 에뮬 얘기는 다음 편에서 이어집니다...
