NES Elite - NES용 Elite의 문서화된 소스 코드

 (github.com/markmoxon)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Ian Bell과 David Braben의 NES용 Elite 소스 코드로, 모든 줄에 문서화가 붙어 있고 대부분 설명이 제공되며 원본 게임 바이너리의 disassembly에서 수작업으로 재구성함
  • 최신 컴퓨터에서 소스로부터 완전히 동작하는 게임을 빌드해 실제 NES 또는 에뮬레이터에서 로드할 수 있는 iNES ROM image 생성 가능함
  • 지원 변형은 Imagineer PAL variant와 Ian Bell 개인 웹사이트의 NTSC variant이며, 기본 빌드는 PAL variant임
  • 소스 탐색 방식은 elite.bbcelite.com에서 사람이 읽기 쉬운 형태로 보거나 IDE에서 주석 달린 소스를 여는 방식이며, 웹사이트와 소스 파일의 내용은 동일함
  • 빌드 요구사항은 BeebAsm, Python, Mac/Linux의 make이며, Python 빌드는 3.x에서만 테스트됐고 Windows에는 make.exe가 포함됨
    • Windows는 make.bat, Mac/Linux는 make로 빌드하며 기본 출력은 5-compiled-rom-images 폴더의 elite-pal.NES임
    • variant=ntsc로 elite-ntsc.NES 생성 가능함
  • 빌드 옵션은 변형 선택, 최대치에 가까운 테스트 commander 사용, 원본 바이너리 매칭 생략, crc32 검증 비활성화 등을 제어함
    • 대표 예시는 make variant=ntsc commander=max match=no verify=no임
    • crc32.py는 생성 파일과 원본 소스에서 추출한 기준 파일의 체크섬과 파일 크기를 나란히 비교함
  • PAL과 NTSC 변형은 NMI handler 사이클 수, Start screen의 Imagineer/Nintendo heading, combat demo auto-play 대기 시간, save slot checksum 알고리듬, 내부 버전 번호, 숨겨진 copyright message, scroll text, y-coordinate 상수 등에서 차이가 있음
  • NTSC variant는 실제 NTSC 기기에서 동작하지 않으며, 일부 에뮬레이터의 NTSC mode에 맞게 NMI timing이 바뀐 NTSC emulation임
  • 라이선스 파일이 없으며 기본 저작권법 적용으로 읽기와 fork만 허용되고, 재생산·배포·파생 저작물 생성은 허용되지 않음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 오래전 Frontier에서 일할 때 David Braben에게 NES Elite에 관한 재미있는 일화를 들었는데, 처음엔 NES의 하드웨어 타이머로 실제 시간을 추적해 프레임률이 달라도 물리가 일정하게 진행되게 했다고 기억했음
    Nintendo 사전 출시 검사에서 초기 NES 일부는 그 타이머가 제대로 동작하지 않는다며 사용 불가 판정을 내려서, Bell/Braben이 각 함수가 해당 프레임에서 몇 클록 사이클을 썼는지 자체 추정치를 유지하고 프레임 끝에 합산해 경과 시간을 추정하게 만들었다고 들었음
    그런데 GitHub 소스를 보니 내가 잘못 기억했거나 Braben의 말을 제대로 이해하지 못했던 듯함. elite-source-bank-7.asm에는 “NES가 지원하지 않는 하드웨어 타이머 대신 사용할 수 있는 NMI 타이머를 갱신한다”는 주석이 있고, 마스크 불가 인터럽트를 세어 유사 실시간 시계를 구현한 것으로 보임

    • 아마 기억이 섞인 것 같음. 출시된 NES 어느 리비전에도 하드웨어 타이머는 없었음
      초기 NES CPU 다이에는 버그가 있고 비활성화된 프로그래머블 인터벌 타이머의 잔재가 있었음: https://www.nesdev.org/wiki/RP2A03_Programmable_Interval_Tim...
      이후 리비전에서는 완전히 제거됐고, 개발 키트 같은 데서만 켜졌을 가능성은 있음. 소비자 기기에서 동작하지 않는 기능에 의존했다면 Nintendo 테스트에서 거절되는 게 당연했을 것임
      설령 출시 콘솔에 프로그래머블 인터벌 타이머가 있었다 해도, 정밀 래스터 효과 같은 서브프레임 측정에나 유용했을 것임. 실제 시간 측정에는 NMI 카운트가 훨씬 타당함. NMI는 매 비디오 프레임 시작에 발생하고 60.0988Hz로 매우 일정하며, 게임 엔진이 느려져 프레임률이 변해도 CPU 쪽 처리는 비디오 신호 타이밍에 영향을 주지 못함
      참고로 오디오 하드웨어도 타이머 인터럽트를 만들 수 있고, 많은 확장 칩에는 렌더링 동기화를 위한 스캔라인 카운터가 있음. NES에서 시간을 재는 방법은 부족하지 않음
    • BEAM Software(Melbourne House)의 Andrew Davie에게도 비슷한 얘기를 들었음. 그는 Super Glove Ball을 개발했는데, Nintendo가 의미 있는 문서를 거의 제공하지 않아 프레임률 계산 같은 부분에 여러 해킹을 써야 했다고 함
      어떤 게임을 Nintendo에 승인받으려 할 때, 미국판 NES의 특정 버전 하나에서 동작하지 않거나 시스템 과열을 일으켰다고 들었음. 출시 일정이 빡빡해서 Nintendo 본사까지 날아가 해결해야 했고, 그 특정 버전은 유통량이 100대 미만이었다고 기억함
      나중에 미출간 책의 메모를 찾았는데 실제로는 조금 달랐음. 게임 테스트는 게임플레이에만 국한되지 않았고, 실행될 수 있는 모든 NES 콘솔 변형에서 테스트해야 했음. Beam Software의 Andrew Davie는 “The Three Stooges”가 Washington의 Nintendo 사무실 테스트용 NES에서 문제를 일으켜 직접 갔다고 회상했음
      그는 게임이 통과하려면 서로 다른 칩 제조사 조합 등 “기계 변형이 23종쯤” 있었다고 했고, 공식 문서 부족 탓에 자신이 스프라이트 데이터를 공식 권장처럼 RAM에 쓰지 않고 2초마다 직접 쓰게 만들어 NES가 너무 뜨거워지고 게임 전체에서 스프라이트 깜박임이 생겼다고 함. 수정 후 출시 승인을 받았고, 문제의 NES 조합은 미국 전체에 약 5대뿐이라며 Nintendo 테스트 라인업에서 제거됐다고 들었음

  • 최근 후속작인 Elite: Dangerous를 시작했는데, 문제가 없진 않지만 꽤 놀라운 경험임
    1984년판에서 이어지는 게임 요소들을 보는 게 묘하게 감동적이었음. 당시 최신이던 16K 메모리 매핑 화면의 벡터 그래픽으로 보던 함선과 특히 Coriolis 정거장이 4K/60fps의 완전한 3D 렌더링으로 바뀐 걸 보니 예상보다 감정적으로 다가왔음
    광고판, 식물, 도킹 장비까지 갖춘 자세한 Coriolis 내부를 마침내 보게 된 건 솔직히 눈시울이 살짝 젖을 정도였음. 현재 어려움이 있더라도 이 게임은 소중한 유산이고, 어떤 형태로든 계속 남았으면 함

    • Elite Dangerous를 정말 즐겼음. 콘솔 지원이 중단된 뒤로는 안 했지만, 반복 작업과 얕은 콘텐츠에도 불구하고 친구들과 함선을 조종하던 시간이 그리움
      Blue Danube를 들으며 우주선을 수동 도킹하는 건 늘 편안한 경험이었음
      우주 시뮬레이터와 우주 게임은 왜 항상 이렇게 문제가 많아지는지 궁금함. Elite Dangerous는 아무 데도 못 가는 것처럼 보이고, Star Citizen은 영원한 베타 같으며, KSP2도 실망스러웠음
    • 오픈 베타 때부터 Elite: Dangerous를 오래 플레이했음. 아름다운 게임이고, 사운드 디자인이 굉장함
      9년 전에 쓴 생각: https://hypertexthero.com/elite-dangerous-education/
      Odyssey 확장팩도 재미있고, 언젠가 선외 활동 우주 유영과 무중력 임무가 추가되면 좋겠음

  • 원작에 거의 충실한 C 버전인 Elite - The New Kind도 있음: https://github.com/fesh0r/newkind
    Christian Pinder가 만들었음: https://www.christianpinder.com/games/
    Ian Bell의 Elite 홈페이지도 볼 만한데, 원본 버전들이 여러 개 있음: http://www.ianbellelite.com/

    • Ian Bell과 그의 웹사이트는 확실히 언급할 가치가 있음. BBC Micro 버전 원본 소스 코드를 찾을 수 있는 곳이고, 그 원본 디스크들이 NES 프로젝트를 포함한 내 모든 Elite 주석 작업의 기반임
      1991년 NES 버전의 핵심, 즉 128K ROM의 약 30%는 본질적으로 1986년 BBC Master 버전이고, 그 자체가 1984년 원래 BBC Micro 버전의 발전형임. Commodore 64와 Apple II 버전도 같은 계보이고, 개발도 BBC Micro에서 이뤄졌음
      뱅크 0, 1, 2의 대부분 코드는 원래 BBC 버전에서 직접 가져왔고, 뱅크 7에도 일부 더 있음. 앞단에 새 그래픽, 사운드, 컨트롤러 루틴이 붙었지만 뛰는 심장은 여전히 Beeb 버전임

  • Elite의 저자인 Ian Bell은 NES 버전을 자신이 가장 좋아하는 8비트 Elite 버전이라고 했음
    전체적으로는 32비트 Archimedes 이식을 가장 좋아했다고 함

    • 원문 인용은 이렇다: “기술적으로 내가 출판한 가장 큰 성취는 화면까지 포함해 BBC 카세트판 ‘Elite’를 32K RAM에 넣은 것, 그리고 문자 매핑 디스플레이와 단일 NES 컨트롤러를 사용한 Nintendo Entertainment System판 ‘Elite’ 변환이다. NES는 내가 가장 좋아하는 출판된 변환이며, 우리가 해내기 전까지는 기술적으로 가능하다고 여겨지지 않았다.”
      전체 인터뷰는 http://www.elitehomepage.org/archive/b5081501.htm에 있음
      이 말은 그가 가장 좋아하는 버전은 BBC Micro 카세트판이고, 가장 좋아하는 변환판은 NES판이라는 뜻으로 해석함. 다만 BBC 팬보이라서 희망적으로 해석하는 걸 수도 있음
    • 하지만 노예와 마약 거래를 빼버렸잖아 :)
    • Arch Elite가 확실히 정점임
    • 최근 Oric Atmos 팬 제작판도 꽤 괜찮음: https://www.youtube.com/watch?v=kC1cJGLGlxo

  • 각 뱅크 시작에 이런 뱅크 전환 심이 들어 있는 게 마음에 듦
    SEI / INC $C006 / JMP BEGIN
    공간 절약을 위해 이렇게 한다는 설명이 자세히 나오지만, 내 눈에는 JMP가 필요한 유일한 이유가 명령어 파이프라인 때문이고, NOP만으로도 플러시할 수 있을 것 같음
    그래서 내 2바이트 최적화는 이렇다: SEI / INC $FFFD ; 명령 벡터 안의 C0을 대신 사용 / NOP

    • “JMP가 필요한 유일한 이유가 명령어 파이프라인 때문”이라는 말도 맞지만, 사람에게도 의미가 통함. 실행은 뱅크 7에서 시작하니 뱅크 7로 점프하는 것임
      곁가지로 Game Boy에서는 진입점이 고정 뱅크인 ROM0에 있어서, 적어도 흔한 MBC에서는 애초에 이런 문제가 없음

  • 비교 대상으로 Objective-C로 작성된 오픈소스 Elite 클론 Oolite의 소스 코드가 있음: https://github.com/OoliteProject/oolite
    https://oolite.space
    https://news.ycombinator.com/item?id=7894145

  • 8살 때 C64에서 이걸 플레이했음. 30년이 지난 지금도 이 코드는 이해가 안 됨

  • 뱅크 0만 어셈블리 18,305줄이라니, 이걸 어떻게 머릿속에 유지했는지 감도 안 옴

    • 6502를 쓰던 시절엔 전부 머릿속에 넣는 게 아니라, 트랙터 급지 도트 매트릭스 용지 뭉치에 보관했음. 보통 연필로 적은 메모와 수정도 잔뜩 있었음
    • 현대에 8비트 기기용 임베디드 개발을 조금 해봤는데, 80년대에 이걸 하던 엔지니어들에게 진심으로 경의를 표함
      최고 수준의 도구가 있어도 코드를 추적하려면 엄청난 조직력과 규율이 필요했을 것임. 80년대 초 Hitachi 6303[0]/Motorola 6800[1]용 어셈블러를 조사했는데, 이런 도구 제약 속에서 사람들이 해낸 일이 놀라움
      예를 들어 아래 두 어셈블러는 라벨이 6글자까지만 가능했고, 서브루틴 내부 전용 지역 라벨도 없었음. 내 작업에서는 설명성을 위해 라벨을 40글자로 제한했는데도 그랬음
      다만 이런 아키텍처의 상대적 단순함은 현대 시스템 임베디드 작업에 비해 정말 신선함. 전체 시스템 상태를 대략 머릿속에 담을 수 있다는 건 분명 장점이 있음
      0: http://www.bitsavers.org/components/hitachi/_dataBooks/U24_H...
      1: http://www.bitsavers.org/components/motorola/6800/exorciser/...
    • 그때의 우리는 더 나은 우리였음. 진지하게 말하면, 어느 정도 규모가 있는 프로젝트는 거의 반드시 많은 코드를 종이에 쓰거나 출력해야 했음. 정말 많은 종이가 필요했음
    • 이 코드는 극도로 잘 정리되어 있고 문서화도 잘 되어 있음. 원래 코드의 문서화 수준이 어땠는지는 모르겠지만, 출력물에 손글씨 메모 같은 게 많이 있었을 것 같음
      전반적으로 어셈블리 프로그래밍도 고수준 언어와 크게 다르지 않음. 코드를 함수와 블록 등으로 조직함. 점프가 얽히고설킨 초장문의 코드 벽을 하나 쓰는 건 심각한 문제를 자초하는 일임
    • 현대 엔지니어 입장에서는 왜 이걸 머릿속에 담아야 하는지 잘 모르겠음

  • 자유 소프트웨어가 아니라 아쉬움. 내가 Elite 창작자였다면 모든 게임 이식을 자유 라이선스로 풀었을 것임
    어쨌든 요즘은 저렴한 넷북에서 Oolite를 플레이할 수 있고, 방대한 애드온 목록 덕분에 똑같거나 더 큰 재미를 얻을 수 있음

    • 그건 Braben이 저작권 문제에서 까다롭게 굴었기 때문임. 반면 Bell은 좋은 사람이었고, 자신이 직접 쓴 대부분을 공개했음
    • 이 공개를 둘러싼 역사는 수십 년 전까지 거슬러 올라감
      Braben 쪽은 Elite 4/Elite: Dangerous를 만들고 있었으니 저작권을 약화시키고 싶지 않았던 것 같음

  • 모든 소스 코드는 이 정도로 문서화되어야 함

답변달기