[MiSTer FPGA] MiSTer를 사용해 오면서 MiSTer에 아쉬운 점들

MiSTer를 사용한지 얼추 만 3년이 넘었다. MiSTer를 열정적으로 사용하시는 다른 분들에 비해 능숙하고 세련되게 잘 사용했다고 하기는 어렵지만, FPGA 재구현 방식이 레트로 게임 콘솔들 또는 레트로 컴퓨터들을 현재에 사용하기 위한 훌륭한 솔루션이라 생각해서 나름 관심을 가지고 사용해 왔던 것 같다. 실제로 그동안 사용해 오면서 소프트웨어 에뮬레이터보다 더 정교한 것에 좋은 인상을 받았고, 현재의 환경에서 실기보다 더 간편하게 사용할 수 있음에 편리함을 느꼈다.

그러나 한편으로는 MiSTer를 사용하는 중에 레트로 게임 콘솔이나 레트로 컴퓨터의 실기를 다시 구매한 것도 사실이다. MiSTer를 처음 구성하여 사용할 때는 '이 정도면 실기 없이 레트로 게임을 잘 플레이 할 수 있겠다'고 생각했었는데, 시간이 지나면서 실기를 정리하기는 커녕 추가 구매했던 것이다. 그 원인은 실기와 MiSTer 간의 어쩔 수 없는 간극 때문이기도 했겠지만, MiSTer의 구조나 구동방식에서 좀 아쉬운 점들을 느꼈기 때문이기도 한 것 같다.

그 동안 MiSTer를 사용하면서 MiSTer에서 느꼈던 아쉬운 점들 몇 가지를 열거해 보고자 한다.

 

(1) 카트리지나 디스크 등의 물리적 매체가 아닌 바이너리 이미지 파일을 사용하는 방식

MiSTer에서 구현된 레트로 게임 콘솔이나 레트로 컴퓨터 구현물은, 소프트웨어를 구동할 때 카트리지나 디스크 등의 물리 매체가 아닌 소프트웨어의 바이너리 이미지 파일을 사용한다. 예를들어, SNES 코어는 북미의 SNES 또는 일본의 슈퍼패미컴 카트리지가 있어도 직접 읽을 수 없으며 대신 이에 대한 추출 롬 이미지 파일(sfc, smc 파일 등)을 로드해서 게임을 구동한다. C64 코어에서도 Commodore 64용 플로피 디스켓이 있어도 (디스크 드라이브 연결이 안되니) 직업 읽을 수 없고 디스크 이미지 파일을 사용해 게임을 구동한다.

사실 이유는 명확하다. DE-10 nano 보드에서 카트리지 등의 물리 매체를 연결해 데이터를 읽어들일 수 있는 추가 IO 포트 수가 모자라서 카트리지 슬롯 등을 연결하기 어렵기 때문이다. DE-10 nano의 GPIO는 RAM 모듈과 연결에도 사용되어야 하고, I/O 보드 연결에도 사용되어야 하며, SNAC이나 MIDI 연결에도 사용되어야 한다. 롬 카트리지 연결이나 디스크 드라이브 연결에 사용할 여유는 없는 것이다.

물리 매체 대신 바이너리 이미지 파일을 사용하는 방식은 마치 에버드라이브(Everdrive) 기기를 사용하는 것 같이 대단히 편리한 방식이기도 하지만, 개인적으로 보기에 두 가지 정도의 문제점을 가지고 있는 방식이기도 하다.

첫째로, 과거 실기 사용의 추억을 가진 사용자에게 기기 사용의 감성적 측면을 손상시킨다. 과거에 레트로 게임을 플레이 하던 사용자는 카트리지를 골라 기기에 꽂고 전원을 올리는 그 느낌을 갖고 있기 때문에, 소프트웨어 에뮬레이터에서 처럼 메뉴에서 롬 이미지 파일을 골라 게임을 로딩하면 실기를 사용한다는 느낌을 가질 수 없다. 단순히 사용자의 감성적 문제로 치부하기 쉽지만, 이런 소소한 요소들이 실행 중인 게임에 대한 태도를 바꾸게 하여 게임의 감각을 다르게 하고, 사용하는 MiSTer 기기에 대한 호감도에도 영향을 준다고 생각한다. 예를 들어 메가드라이브 게임을 플레이 할 때 유사한 FPGA 기술 기반이라고 해도, Mega Sg에 실물 카트리지를 꽂아서 플레이 하는 것과 MiSTer의 Genesis 코어에서 롬 파일을 골라 플레이 하는 것은 다른 느낌을 준다. 그래서 일부 MiSTer 사용자들은 손수 제작한 NFC 카드로 카트리지를 삽입해서 플레이 하는 것 같은 느낌을 재현하는 TapTo('Zaparoo'로 이름 변경)라는 프로젝트를 활용하기까지 한다.

둘째로, 이런 구조로 인해 MiSTer 사용자들은 MiSTer를 사용할 때 플레이 하고 있는 게임의 합법적 사용 여부에 대해 계속 의심받게 된다. 많은 게임들의 롬 이미지 파일이 온라인 상에서 쉽게 획득 가능하기도 하고 롬이나 디스크 등의 매체에서 이미지 파일로 일일히 추출하는 것도 쉽지 않은 일이기에, MiSTer로 게임을 플레이 하는 것은 다운로드 등의 경로로 확보한 게임 롬 이미지를 사용하는 것으로 비춰질 것이다. 자신이 보유한 게임에서 롬 이미지를 추출해서 플레이 하는 MiSTer 사용자라 하더라도 대중은 의심의 눈초리로 바라볼지도 모른다.

 

(2) USB 인터페이스를 사용하는 컨트롤러와 키보드

MiSTer에 SNAC(Serial Native Accessory Converter)을 사용하지 않는 경우라면 보통 USB 인터페이스를 가진 컨트롤러를 사용할 것이다. 하지만 USB 컨트롤러는 대체로 레트로 게임 콘솔 또는 레트로 컴퓨터의 컨트롤러와 같은 응답성을 보장하지 못한다. MiSTer의 옵션 설정을 통해 USB polling rate를 높이고 입력지연이 낮은 제품의 컨트롤러를 사용해도 여전히 실제 기기의 컨트롤 품질에는 미치지 못한다는 것이 개인적 의견이다('fast USB polling' 옵션을 켜고(on) 'MiSTer Input Latency' 측정에서 1위를 차지한 Buffalo classic USB gamepad를 사용하고 있다). MiSTer에서 리듬 액션 게임들을 해 보면 좀 더 체감하기 쉽다.

SNAC으로 실제 컨트롤러를 사용하면 되지 않느냐고 반문할 수도 있겠다. 그런데 SNAC은 코어 별로 별도의 어댑터를 사용하므로 여러 개의 코어를 사용하는 사람에게 매우 번거로우며, 모든 코어가 SNAC 입력처리를 지원하는 것도 아니다. 더구나, SNAC을 사용해도 MiSTer의 기본 조작은 USB 인터페이스의 컨트롤러를 사용해야 하기 때문에 USB 컨트롤러가 필요없어지는 것도 아니다.

USB 인터페이스로 키보드를 사용하는 것도 불만스러운 경우가 있다. 예를 들어, 일반적인 USB 키보드는 USB 프로토콜 구조상 동시에 입력되는 키 숫자에 제한이 있으며, 모든 키에 대해 동시 입력 지원 처리를 하지 못하는 대중적인 USB 키보드의 경우에는 동시 키 입력이 더 제한된다. 따라서, MSX의 경우 실기의 키보드는 누르고 있는 키가 몇 개가 되든지 모두 동시 입력되지만 MiSTer의 MSX 코어나 MSX1 코어에서는 이런 처리가 되도록 구성하기 쉽지 않다. 아래 글은 그런 환경 구축의 노력 중 하나에 대한 내용이다.

MSX 게임 'Aleste 2' JAM(José Ángel Morente) 패치 버전의 치트키 수정

 

(3) 중추적인 역할을 하면서도 한쪽에서 바쁘게 움직이는 HPS

DE-10 nano는 FPGA 로직을 움직이는 PL(Programmable Logic) 파트와 Linux를 구동하는 ARM CortexA9 코어의 HPS(Hard Processor System) 파트로 구성되며, MiSTer는 두 파트의 협업으로 동작한다.

fast USB polling의 on/off는 MiSTer의 Linux 쪽에서 설정하는 것으로 보아 USB 컨트롤러 입력은 HPS의 Linux가 처리하는 것으로 보인다. fast USB polling을 켜면 Linux 커널은 1000Hz(1초에 1000번)로 USB 신호를 확인하는데, 이러한 polling 주기는 HPS 프로세스 쪽에 큰 부담이 될 수도 있다고 한다.

Mouse polling rate - ArchWiki

더 안좋은 상황은 HPS 쪽 Linux가 처리할 작업이 그것만이 아닌 경우이다. Ethernet이나 무선랜 모듈이 연결된 경우 Linux는 TCP/IP 네트워크를 처리해야 하고, 블루투스 모듈을 사용하는 경우 그 블루투스 처리도 해야 하며, SAMBA나 FTP 등 서비스를 켠 경우 그에 따른 서비스 처리도 해야 한다. SAMBA를 통해 파일을 게임 파일을 DE-10 nano 쪽의 마이크로 SD로 옮기는 중에 게임을 시작해 컨트롤러를 사용한다면, Linux 커널은 정밀하게 USB 컨트롤러 신호를 1/1000초 단위로 잘 처리할 수 있을까? 확실한 것은 MiSTer의 Linux 커널이 엄격한 수준의 RTOS 커널은 아니라는 것이다(MiSTer의 shell에서 'uname -a' 해 보니 현재 Linux의 버전은 5.15-1). MiSTer 쪽에서 SAMBA 서버를 켜고 PC에서 MiSTer의 마이크로SD카드로 대용량의 파일을 옮기면서 MiSTer의 코어를 구동하는 실험을 해 보면 상황을 짐작할 수 있다.

MiSTer는 Analogue가 판매하는 FPGA 전용의 디바이스들과 다르게 ARM 기반 프로세서 위에 Linux 운영체제를 사용할 수 있어 갖가지 추가적 요구사항에 유연하게 대응할 수 있었다. 하지만 네트워크 처리 및 각종 서비스를 Linux에서 실행되도록 하면서 게임의 조작감과 밀접하게 관련된 USB 컨트롤러의 입력 처리도 Linux 쪽에 넘긴 것은 좋은 설계 선택이 아닌 것 같다.

 

(4) 일부 개발자의 이해할 수 없는 개발 방식

'오픈 소스 (open source)'라는 의미가 정확히 어떤 것인지 알 수 없으나 MiSTer 프로젝트는 오픈 소스 프로젝트이다. '오픈 소스 소프트웨어'라는 개념에 비춰 생각해 보면 아마도 개발자가 만든 결과물이 공개되어 누구나 사용할 수 있고 누구나 수정할 수 있는 체계를 따른다는 것으로 보인다.

하지만 예전에 한번 언급한 적이 있듯이, 일부 MiSTer 개발자들의 개발 방식은 오픈 소스 소프트웨어의 공유 정신과 비교할 때 이해하기 어렵다.

[MiSTer FPGA] "MiSTer 프로젝트가 진짜 '오픈 소스' 프로젝트인가"에 대한 개인적 생각

Patreon을 통해 개발 활동에 후원을 받는 것은 그럴 수도 있겠다 싶지만, 중간의 개발 결과물을 후원자에게만 공개하는 형태는 법적으로 하자가 없을지라도 '오픈 소스'라는 수식어를 붙이기 민망하다고 생각한다.

또 하나 최근들어 부정적으로 보게 된 것은, 특정 개발팀이 여러 개의 프로젝트의 시작을 동시에 발표하여 각각의 개발 진도는 떨어뜨리게 하면서 다른 개발자들의 진입을 막아버리는 현상이다. 예를 들어 FPGAzumSpass(Robert Peip)는 과거 네오지오 포켓 코어 개발에 관심이 있다고 인터뷰를 한 적이 있는데, 네오지오 포켓 코어는 Jotego(Jose Tajada)가 진행한다고 발표가 되었다. 그후 FPGAzumSpass는 PSX 코어 제작을 완료하고 현재 Nintendo 64 대응 코어 제작 까지 발표한 상태지만, Jotego는 그의 수많은 다른 개발 진행 프로젝트들(여러 개의 arcade 코어들, Analogue Pocket용 다수 코어들 등)에 밀려 이 글을 작성하는 시점에야 처음으로 스크린 화면이 표시되었음을 발표했다. 그가 실력이 대단하다는 것은 알겠지만 너무나 여러가지 프로젝트를 펼쳐 놓았기 때문에 다른 개발자들과 분담해서 개발하는 것 보다 개발 시간이 너무 느리기도 하고 다른 실력 있는 개발자들의 진입을 막는다는 느낌도 든다. 게다가 Patreon 후원까지 연계되다면 금전적인 오해도 불러일으킬 수 있어 보인다.

 

(5) 일부 부족한 퀄리티

AO486의 OPL 사운드가 실제와 다르다는 의견이 많지만 개선이 이루어지지 못하고 있다. Apple II 코어에서는 이 글의 작성 시점에 아직도 플로피 디스크 쓰기가 되지 않는다. MSX 코어는 OCMC에 기반한 구조로 인해 SRAM 저장 지원이나 SNAC 지원이 안된다. 물론 이런 점들은 개발자들의 관심과 수고들에 의해 시간이 지나면서 극복될 수도 있는 부분이라고 생각되기는 한다.