ひしだまの変更履歴

ひしだまHPの更新履歴。
主にTRPGリプレイの元ネタ集、プログラミング技術メモと自作ソフト、好きなゲームや音楽です。

M.T.GODDESSとMSXエミュレーター改造の話

2011-10-29 23:53:51 | プログラミング

昔作ったものを思い出していたら懐かしくなったので、ちょっとフォローしておくw

M.T.GODDESSはMSX-FANに載っていたゲームで、戦闘シーンがハイドライドやボコスカウォーズのように体当たりで戦うアクションになっている。敵味方はお互い複数居るが、操作できるのは自分のキャラ1人で、味方もコンピューターが動かす。
このうち味方2人分をプレイヤーがジョイスティックで操作できるように改造した。(要するに3人で協力して戦えるようにした)

戦闘シーンはマシン語で書かれている(BASICのDATA文で数値だけ書かれていたはず)ので、手で逆アセンブルして、ジョイスティックで操作できるように書き換え、ハンドアセンブルし直した。
こういった改造をしたのに、マシン語部分のバイト数が改造前と一切変わらなかった!
我ながら感動して、今でも覚えているのだw


MSXエミュレーターは今ではMSX MAGAZINE永久保存版が定番だと思うが、当時はfMSXをいじっていた。
当時のマシンスペックのこともあって実行速度が遅かったので、なんとかしたいと思った。

採ろうとしたアプローチは、対象プログラムをホストマシン上のプログラムに変換してコンパイルして実行するというもの。
プログラムはZ80のマシン語なので、逆アセンブルしてC言語に変換し、コンパイルしてfMSXとリンクするという発想。(fMSX自体がC言語で書かれているので)

しかしマシン語(Z80)というものはプログラム部とデータ部がきっちり分かれている訳ではないので、どこがプログラムとして実行されるかを全て追うのは困難。
また、マシン語ではプログラムの自己書き換えが出来るので、コンパイルするならその部分を判別してエミュレートする必要がある。
ROMのプログラムならそういうことは無さそうに思えるが、メガロムの場合はページ毎にアクセスできる場所を切り替える仕組みになっており、その実現方法はROMによってまちまち。あるROMでは特定アドレスに書き込むとページが切り替わるようになっている(ROMはread onlyなのに、そこへ書き込む!)が、汎用的な決まりなど無い。

大体のところは、メモリーにアクセスする時に直接読み書きするのでなくfMSXのアクセスルーチンを使うようにすれば解決すると思うが、それだとスピード面で全然改善にならない(苦笑)

という訳で、立ち消えになった。


MSXエミュレーターのことはさて置き、MSXでプログラムを勉強するというのは、環境面でも非常に良かったと思う。

フロッピーディスクも普及してなかった頃なので、プログラムは雑誌の紙面に載っているものを全て手打ち(笑)
何かエラーが出たら、基本的には自分が何か打ち間違えているということなので、デバッグの勉強になる。
ソースも全部見られるし全部入力するので、何をやっているのか・どういう書き方をするのか・何が定石なのかという勉強になるし、気になる部分の改造も出来る。

当然の様に、雑誌には初心者プログラマーへの解説もあった。
インターネットなんか無い時代であり、雑誌自体も種類が限られているので、MSXでプログラムを作る人はほぼ全員同じ知識を共有できていたと思う。
(たぶんMSXでプログラムを作っていた人なら、ビット演算のXORなんて常識だと思うw)

今の時代、「インターネットで情報は何でも手に入る」とか云うけれど、個別の事はともかく、全員が共有できる知識なんてものはウェブ上には無いんじゃないか。

もうちょっと言うと、自分はMSX-BASIC→Z80アセンブラ→C言語→VC++JavaScalaと勉強してきた。
技術要素的には、BASICで基礎を覚え、アセンブラでメモリーアクセスを覚え、C言語で構造体を覚え(ポインターはアセンブラをやってれば難しくない)、VC++でクラスとイベントドリブンを覚え、Javaでオブジェクト指向を覚え、Scalaで関数型の考え方を勉強中という感じになる。
つまり新しい言語を勉強すると言っても、今まで覚えてきたことに新しい要素を追加するだけという感じ。

ところがこれを今の人がJavaやScalaから入るとなると、覚えることが多くて、そりゃ大変だろうなぁと思う。
(MSX-BASICなら、パソコンの電源を入れたらBASICの画面になるので、PRINT "hello"って書けばもうプログラミング完了だよ。インストールもコンパイルもツールの起動も何も要らない。初心者にとってどれほど楽かw)
まぁ逆に今の時代は入門書もいっぱい出ているから、なんとかなるのかもしれないけど。(どの入門書が良いのか探すのも一苦労かもしれないけど^^;)


プログラミングのどの分野に興味があるか?

2011-10-29 17:18:29 | プログラミング

ある人に「プログラミングのどの分野に興味があるか?」と聞かれ、とっさに「プログラミング全般」と答えたけれども、あまりにも漠然としているorz (頭が悪いので臨機応変なやりとりって苦手でして…)
ので、もうちょっと詳しく考えてみた。


そもそも自分は物を作るのが好き。

小学生時代はずっとレゴブロックで遊んでいたし、プラモデルやタミヤの模型に手を出していた時期もある。
そうこうしている内にファミコンが出てゲームにハマったが、ナッツ&ミルクロードランナーの自作ステージを作るのも好きだった。(ファミコンじゃないけど、アクションパズルΦ自作ステージを一番多く作ったのも自分だなw)

そして友人がパソコンを買って 見せてもらったのをきっかけにプログラミングを知り、それ以来ずっとプログラムを作ってきた。


プログラムを作るのが楽しいというのは、
(1)出来たプログラムを実行して使うのが楽しい、あるいは便利(例えばゲームとか業務システムとか)
(2)プログラムを作ること自体が楽しい(パズルを解くのと似ている)
という2つの面があるのではないかと思う。

(1)の「プログラムの目的」については、当初はゲームを作ることだった。
そしてプログラムを作っている内に「いかに綺麗に書くか」といったプログラムの作り方そのもの(つまり上記の(2))にも興味が出てきた。


仕事のプログラムの場合は、当然(1)「プログラムの目的」が重視される。「動けばいい」と言う人は、(1)しか考えていないのだろう。
実際には仕事のプログラムこそ品質(バグの少なさやメンテナンスの容易さ(後から他の人が見ても分かるようにする))、つまり(2)「プログラムの作り」が重要なんだけど。

自分の場合は、自分が関わるプロジェクト(仕事)のプログラムの品質は良くしたいと思っている。
仕事では自分一人でプログラムを全部作るなんて事は無くてチームメンバーが居るから、全員のプログラムの品質が良くないといけない。
だから(少なくとも自分程度の技術力でも分かるような)変なプログラムを作らせない為にどうすればいいかといった事を考えることもある。
(自分がウェブページで色々技術的な事を書いているのは、主要な目的は自分の記憶力が悪いのでメモしておくことだけど、メンバーに「これを見れ」と伝える目的もある。いちいち説明するの面倒だからね(爆))
スケジュール管理だのリスク管理だのも、良い仕事の為には必要だろうとは思う。

もっと言うと、SIの仕事はお客さんの問題を解決することであって、既存パッケージを組み合わせるとかコンピューターシステムを作らないとかって事もアリ。
お客さんと直接話して問題を解決する(いわゆる上流工程)のが面白いという人も居るだろう。それは分かる。人の役に立つのは嬉しいからね^^
あるいはプロジェクトをとりまとめて成功させるのが好きだという人も居るだろう。

でも僕はやっぱりプログラムを作らない仕事には意欲が湧かないなぁ…。少なくとも自分が目指したい場所ではない。
時間が経てば興味が移り変わることも自然だと思うけれど、自分は変わらなかった。


ところで、プログラミングの「分野」ってどういう分け方があるだろう?

組み込み系・業務(サービス)系・ゲーム系とか、バッチ系・ウェブ系・リアルタイム系とか、あとは理論派・実践派とか?

そういう意味だと、自分が主にやってきた分野というのは当然あるとして、他の分野にも興味自体はある。だから「興味があるのは全般」という考えになっちゃうのかな。
でも理論とか組み込みとかになると、たぶん付いていけないけど(苦笑)


では自分が一番何をしてきたか(興味がある事をやってきたはず)と考えると、プログラムの改造・改良かもしれない。

例えばM.T.GODDESSの改造は神懸かっていたし(公開してないので誰も知らないが(爆))、大学の卒業研究ではC言語の改良版を作りたかったし(さすがに無謀だったので、作ったのはLispをC言語に変換するツール)、MSXエミュレーターの拡張をしようとしていた時期もあったな(汗)

例えばHadoopに興味を持ったのは自分のプロジェクト(お客さん)の抱えている問題が「夜間バッチが遅い」なのでそれを解決できるかもと思ったからだが、Hadoopそのもののプログラミングは面倒なのでPigHiveAsakusaFWといったアプリが作られていて、そちらにもすごく興味を引かれる(笑)
(今作っているshrも、使っていると色々機能追加したくなってきて面白いw)

つまりは、「面白いソフトがある」→「使っていると改造したくなる」というのが自分の行動原理なのかも。
改めて自分が今までに作ったツールを見てみると、既存アプリを便利に使う為のものが多い。(しかもエンドユーザーをターゲットにしたものがほとんど無い^^;)


もうひとつ興味があることとして思い浮かぶのが、「良いプログラムを作りたい」ということ。

「良いプログラムって何?」って言うと、開発効率が良い(短時間で作れた)・ソースの見た目が分かりやすい(美しい)・実行効率が良い・バグが無い・使う人から喜ばれるもの、かな。
ここまで揃ったら、もはや「芸術品」だね(笑)
(たとえ綺麗に作れても、使われないシステムだったら作った意味が無いので、芸術品とは思えない)
プログラマーなら誰でも目指している物だろうから、特に自分だけが興味を持っている分野というわけでもないと思うけど。

自分が新しいプログラミング言語を勉強したいと思うのも「良いプログラム」の一環かな?
新しい考え方っていうのも興味深いし。


ここまで考えてきて気付いたけど、やっぱり自分は「何を作るか(新しいサービスを作ること)」は眼中に無い(爆)
というか、「発想する力が無いので、出来ない」っていうのが正しいのだが。

世間では“誰も作っていないサービスを発明する”ことが評価される(それは当然だと思う)けど、みんながみんなそれを出来なきゃいけないって訳でもないし、実際できないし。
発想する人と作る人と改造する人、適材適所で分担してやればいいじゃん!

(とは思うが、他人が作ったものを改造するなんて事は誰でも出来るので、自分の得意分野とか言うのは憚られる…)

あるいは、SIの仕事ならお客さんの役に立つシステムを作るのが当然だが、その為の業務分析だのなんだの…には興味は無いんだよなー。
分析された結果を、コンピューターシステム上に上手く・素早く実現(作成)させることには興味がある。


うーん。

一言で答えられるような上手い答えは出せなかったけど、色々考えを整理するきっかけになった素晴らしい質問でした。ありがとうございました。