某プログラマが某有名ファミコンゲームのソースをgitに公開したの巻

ツイッターでポロっとつぶやいたのだけど、ここでも記事をば。
某プログラマが34年前に発売された某有名ファミコンゲームのソースをgitに公開したので、以下にリンクを置いておく。

GitHub - omuanko/nnjhtrkn: Famous Ninja game for NESFamous Ninja game for NES. Contribute to omuanko/nnjhtrkn development by creating an account on GitHub.
GitHub - omuanko/nnjhtrkn: Famous Ninja game for NES github.com
GitHub - omuanko/nnjhtrkn: Famous Ninja game for NES

某プログラマからの箴言は以下。

■某プログラマ
ちなみに びるど とおりますうご(www
act65 を cpm86 エミュで 試してみた
ソース見られるの恥ずかしい
いまさらおそいか
ちなみに act65は つけてないよ
どっかで ひろってね

ところで、イマドキな方には全く理解できないことがいろいろあるだろうから、ちょいとgitの中身を説明。

■どうして半角アルファベットのファイル名ばかりなの?

当時、開発されていた環境は、シャープのX1+岡田さんがアメリカで買ってきたハードディスク+中本さんが当てたパッチつきCP/Mだったから…と書いたら、某プログラマから連絡が!w

■某プログラマ
開発環境はPC98のMS-DOS上でCP/Mエミュレータ? でact65を動かしてた。テキストエディタは PMATEだったはず。と某プログラマが言ってました(笑)

とのことなので、中本さんたちが作った次の世代の開発システムで、この有名ゲームは、野沢さんがV30の8080エミュレーション機能を使って、ACT65を動かしていた実例だったらしい。
某有名野沢さんにもうちょっと詰めて確認しておきたい。

CP/Mのファイル名は8+3で、しかもアスキーコードだけのファイル名だ。
だからそーなっている。
MS-DOSになると半角カタカナとかファイル名で使えるようになるが、ツールでは日本語ファイル名はトラブルのモトでしかなかったので、使わないのが常識だった。
もう一つ書いておくと、ソースに日本語を書くのもトラブルのもとにしかならなかったので、書かないのが常識だった。

■どっからビルドするの?

CP/Mが実行可能な環境で、かつact65が手元にある状態で、A.BATを実行。

asm65 hat h=test

中身が上1行しかなくて、腰を抜かすかも知れないがアブソリュートアセンブラとはそういうものだったのだ。
アブソリュートアセンブラは簡単に書けば、中間ファイルを出力せず、直接バイナリファイルを出力するアセンブラだ(内部的には複数パスのものと1パスのものがある)。
中間ファイルが出力されない(つまりリンカがない)世界なので、プログラムを最初から最後まですべて1つのソースとして読み込んで解決しなければならない。
だから更新管理なんて全然ナイわけだ。
え? じゃ、この沢山あるファイルはなに? という疑問が出てくるだろうが、そこで HAT.A65 のソースの一部を読んでいただきたい。

link hmain.a65
link hatmov.a65
link ninpou.a65
link hatenm.a65
link hatbou.a65
link hattil.a65
link rechat.a65
link hatmus.a65
;
link HTCLEAR.SCR
link HTBGM.SCR
link HTOVER.SCR
link HTCOMP.SCR
link HTCAT.SCR
link HTFIRE.SCR
link HTTOJO.SCR
link HTBONUS.SCR
link HTWARP.SCR
;
link hatmap.a65

ここで次々ファイルを読み込んで、一つのファイルとして扱っていくわけだ。
当時のエディタには一度に編集できるファイルサイズに制限があるものも普通にあり、こんな風に出来るのはSorcimのact 65の優秀なところだったらしい。それを示す1982年のusenetのポストが以下。簡単な英語だ。翻訳するほどのテキストではないだろう。

1982年のusenetのpost

usenetはネットニュースで当時は掲示板のように使われていたもの。
今のwikiとかのご先祖様、と思えばいいだろう。これまた今ではほぼ40年前のポストで歴史的な代物だが。
また、80年代半ばはちょうどマイコンの開発環境が8ビットから16ビットに移動し始めるとき、言い換えるとMS-DOSの時代がきつつあるときで、そろそろ”obj”といったリロケータブルな中間ファイルを言語が出力して、それをリンカがつなぐ時代だ。
だけどまた6502のような8ビット環境だとまだまだこういったアブソリュートな環境も普通にあった時代だ。恐ろしく原始的に見えるだろうが、これでもハンドアセンブルよりはもちろん全然楽だったのだ。

あと、当時の環境は横は80桁、縦はファンクションキー表示なしで25行、ありなら24行の固定だ。その程度しかソースが見えない前提で、画面を見ると少々ビビると思う。

■某プログラマ
ソース自体は disasm すれば すぐ作れんだけどね

と言っているが、disasmしで出来上がったソースと、実際に当時の開発環境で作られたソースは出来上がるバイナリは同じでも、もちろん意味はまるで違う。
コンソールの開発環境としてはほとんど最古の時代のもの(VCSから数年経ってない)の実際のソース、いわば開発環境の考古学的資料なのだから、とても大事なものなのだ。

というわけで、某プログラマの有名ファミコンゲームのソースがgitで公開されていますよ、というお話であった。

LinkedIn にシェア
Pocket

1件のコメント

  • 統合環境なんて夢のまた夢という時代なわけですがアブソリュートアセンブラの比較対象が(ニモニック表を見ながらの)ハンドアセンブル、というあたり想像を絶する時代感ですね。

    私は47歳ですがMSX-DOS上でのアセンブラがこの方面では一番古い記憶ですし。さすがにハンドアセンブルは知識としてはありますが実際にやっているところを見たことはないです。

    あ、そういえば、モニタ画面上でいきなり修正してパッチを当ててるところは1回だけ見たことがあるぞ……。
    当時何がどうなってそれでバグが修正されたのか理解できませんでしたが。

コメントは現在停止中です。