http://www.retropc.net/mm コメントスパムがひどいのでコメント欄を閉じています。ご用の方はTWITTER(@morian)へ Mon, 30 Mar 2026 14:28:56 +0000 ja hourly 1 http://wordpress.org/?v=3.0.4 http://www.retropc.net/mm/archives/1640 http://www.retropc.net/mm/archives/1640#comments Sat, 28 Feb 2015 04:58:25 +0000 moriyan http://www.retropc.net/mm/?p=1640 > X68000とRaspberry Piをシリアル接続してX68000にネット環境を構築する]]> http://www.retropc.net/mm/archives/1640/feed 0 http://www.retropc.net/mm/archives/1078 http://www.retropc.net/mm/archives/1078#comments Tue, 11 Jun 2013 14:14:21 +0000 moriyan http://www.retropc.net/mm/?p=1078 http://www.retropc.net/mm/archives/1078/feed 3 http://www.retropc.net/mm/archives/1033 http://www.retropc.net/mm/archives/1033#comments Fri, 07 Jun 2013 15:17:23 +0000 moriyan http://www.retropc.net/mm/?p=1033 越えられない壁>X68000という意味）とはいえ、ライバル機が活発に活動しているのを見過ごすわけにはいきませんから、ここは何か仕掛けねば！と一人勝手に思い立ちました。 とはいっても、当日に何かするには仕込み時間が無さ過ぎたので、1年後の2013年6月8日を目標日に定めました。変化の激しい時代になんと気の長い話。でもこの不安定なご時世（※2012年）に1年後のネタを考えるくらいの心のゆとりがあってもいいよね。 何をつくろか まず最初に思いついたネタが、X68000の代表的なソフトをPC-6001に移植することです。 え、何言ってんのコイツと思われそうな妄想ですが、PC-6001には「タイニー移植テクニック」があるのです。つまり、どんな大作であってもタイトル名に「タイニー」を付ければ誰もが納得してしまう、そんなテクニックです。 例えば「タイニーグラディウス」とか「タイニーファイナルファンタジー」とかなら、グラフィックが物足りなくても速度が遅くても、なんだか許せてしまう雰囲気になるのです。（※1） ※1 タイニーという言葉をどうとらえるかは人それぞれですが、私はPC-6001らしさを表すとても良い意味の単語だと思っています。ばかにする意図はないです。 X68000の名作がP6でも動いちゃってるモンネーというのは愉快そうです。X68000のゲームで有名なものとなると、ジェノサイドやファランクス、魔神宮でしょうか。「タイニー魔神宮」なんてキャッチーじゃん！BASICでいいし！と思うのですが、このネタのギリギリ感を理解出来る人がPC-6001陣営どころかX68000組にも少ない気がします、ザイン。 そんな感じで、何を移植しようかなーとネットでX68000のタイトルを調べながらツイッターのTL眺めていたところ、「侵略！」の文字が目に飛び込んできました。2012年頃まだアニメイカ娘ブームの余韻があったのですね。・・・そっか、X68000のソフトをPC-6001に持ってくるより、積極的に侵略的な攻めの姿勢として、PC-6001のタイトルをX68000に移植して侵略すればいいんじゃね？と発想をひっくり返したのです。 PC-6001の雰囲気をX68000に持ち込むというよくわかんない移植ですが、これなら作業的にも趣味プログラムの範疇で無理がなさそうです。 移植するタイトルは・・・うん、PC-6001の代表的なソフトといえばタイニーゼビウスです。元々はアーケードの移植作ですが、PC-6001らしくアレンジされてますし、ネームバリューもあります。 移植作のタイトルは68秒だけ悩んで「タイニーゼビウスPRO68K」に決めました。 移植をするにあたっては2つの大きな問題がありました。 まず、タイニーゼビウスの内部的な作りがよくわかっていないことです。雰囲気移植（目コピー）でも充分だとは思ったのですが、グラフィックデータを目コピーするのは面倒ですし、グラフィックデータの吸い出すついでにマップデータの解析もすることにしました。 次の問題が、X68000での開発です。X68000は20年ほど前に色々といじっていたので、漠然と『68000アセンブラをHASとHLKを使ってなんかするんだよ』程度の記憶はあるのですが、スプライトコントローラのレジスタなどの資料を集める必要が出てきました。今の時代に68000アセンブラを書くのもなんですが、普段、PC-6001のプログラムを書くために使っているZ80に比べたら、豊富なレジスタと命令の直交性に優れている68000アセンブラは天国なはずです。 とはいっても、データやプログラムのタスク管理はC言語を使った方が断然ラクですし、タイニーゼビウスを動かすくらいであれば実行速度はそれほど必要じゃないので、GCCの開発環境を整えました。速度やファイルサイズに不満があったらコンパイラで生成されたアセンブラソースを手動で最適化すればいいですし。 なんでも世の中には、クロス開発できるX68000をターゲットマシンにしたGCCがあるようです。すごく興味深いのですが、開発環境上の問題にあたるのは避けたかったので、今回は充分に枯れているHuman68K上で動くGCCを使いました。 ざっと開発環境を説明すると、X68000エミュレータ上で動いているHuman68KにGCC環境を構築して、WindowsのドライブをHuman68Kから見えるようにWINDRV.SYSを使ってマウントして、Windows上でソースを書いてエミュレータでコンパイルしています。 資料集めですが、X68000でC言語による開発といえば、C MagazineでX68000のGCC言語でゲームを作る連載記事があったことを思い出しました。たしか、その連載をまとめたような本が出ていたような気がしたので検索して「GCCによるX680x0ゲームプログラミング」という書籍にたどり着き、さっそくAmazonで注文しました。書籍代は1円で送料の方が高くなるというよくあるAmazonっぽい本の買い方です。 その他は、昔から持っていた「INSIDE X68000」と「プログラマーのためのX68000環境ハンドブック」、それと、「ぷにぐらまーずまにゅある」を参考にさせてもらいました。 開発環境を整えながら、タイニーゼビウスのグラフィックデータとマップデータの解析を進めたのですが、ここでいきなり誤算が発生しました。タイニーゼビウスのプログラム解析作業が楽しくなってしまったのです。マップデータの展開ルーチンを読むにはスクロール処理や画像データの転送処理なども理解しなければならなかったのですが、その延長で他の処理も読みたくなり、結果的に、逆アセンブルした全プログラムを読み終えてしまいました。 当初の目的から外れた副産物であるタイニーゼビウスの解析結果は、@Hashiさんが執筆されているPC-6001の同人誌、PC6000NOTE No.5に収録されています。タイニーゼビウスの処理内容や様々な疑問点への解答など、一通り網羅しています。 現時点では通販はされていませんが、定期的にコミケやゲームレジェンドなどのイベントでTinyProjectというサークルとして頒布されています。→2015年にWebで公開しました。タイニーゼビウス 完全解析＆解説 どう移植するか タイニーゼビウス解析した結果としては、X68000への完全移植は無茶な課題だなと思いました。一般論というか常識として、PC-6001とX68000の大雑把な意味でのスペック比較はPC-6001 >> 越えられない壁 >> X68000なのですが、まぁ、そのへんの事はひとまず脇に置いておくとして、完全移植が難しい理由の一つが、PC-6001のタイニーゼビウスは同期を取らずに全力で動作しているという点です。 同期というのはテレビの垂直同期とか音楽の再生時間などですが、そういったものに依存せずに背景のスクロールやキャラクタの移動処理を常に全力で行っています。ですので、表示するキャラクタの増減、つまり処理量によってゲームの進行速度や音の再生速度が微妙に変化しているのです。これを再現するにはZ80のクロック数やPC-6001の各種割り込みタイミングを考えないといけなくなるのですが、こうなるとX68000上で動作するPC-6001エミュレータを作った方が手っ取り早くなってきます。ただ、X68000にはそこまでのCPUパワーはありません。コードコンバートしてクロック数を数えながら調整して動かすという方法もありますが、その労力に見合わないネタ企画なので、雰囲気が似てれば細かいところはいいやと早々に割り切りました。 スプライトとBGを試す X68000の特徴の一つはスプライトです。家庭用向けのパソコンにスプライトを搭載しているというのは今からみても尖った仕様ですね。シャープやるね！ ゲーム機ではなく、16bitどころか32Bitといわれてもおかしくない高価なパソコンに搭載されているスプライト機能ですから、タイニーゼビウスのキャラクタならゴッソリとキャラ定義できる、と思っていたのですが・・・X68000のスプライトって定義できる数が足りない・・・なんてこと・・・。こんなんだっけ？ 特にBG面への割当数制限が厳しいです。タイニーゼビウスのキャラクタ数くらいなら余裕と思っていたのに。 これなら、スプライトを使わないでグラフィック面に全部描画してもいいんじゃないかなーと思いました。処理速度は間に合いそうですし。 でも、せっかくのX68000のゲームでスプライトを使わないのも残念すぎるので、キャラクタ管理をするということで。XSPとかのスプライトドライバを使うことも考えましたが、そこまでじゃないかなと思ったので、それなりに自前で管理します。 画面モードの話 タイニーゼビウスの画面モードは256×192です。VRAM上のドット数は128×96なのですが、表示する時に拡大されます。 X68000でスプライトが扱える画面モードは256×256か512×512で、PC-6001横方向の解像度を収めるには512×512ということになるのですが、このモードだとドットが細かすぎるので、裏技的な384×256モードに設定します。この辺のCRTC設定値とかはネット上の資料がほとんどなかったのですが、X68000programingというページに書かれていて助かりました。ありがたや。 CRTC周りの設定はアセンブラで記述して、ゲーム本体のC言語のプログラムとリンクしたかったのですが、えっと、C言語とアセンブラのコード呼び出しってどうやったっけ？というレベルから思い出しプログラミングです。最近では、アセンブラ混じりのC言語を使う機会はないのでしょうがないよね。 久々のC言語 マップなどのデータを外部ファイルに持ち、それらのファイルをメモリに読み込むのにfread()とかmalloc()といったCのライブラリを使う事には多少の抵抗がありました。というのも、昔、X68000のプログラムを書いていた頃はアセンブラを使っていて、DOS CALLかIOCS CALLが基本だったので、メモリや処理速度にオーバーヘッドのあるライブラリを使うのはやだなぁと。あと、当時はGCCのコンパイル速度が遅くて、X68000ではC言語自体が使いにくいなぁと。 今ではエミュレータのメモリを12M一杯まで載せて、MPU速度を無制限ぶんぶん回せばあっという間にコンパイルできちゃうのでラクラクです。 それにしても、平成が20年も過ぎるとさすがにC言語でmalloc()してメモリ確保なんていうプログラムを書く機会はほぼないので、懐かしさと自前でメモリ管理をする不安感とで不思議な感じがしました。 BG面を表示する X68000の仕様を確かめつつテストプログラムを書いて、背景の表示とスクロール処理ができました。 [...]]]> http://www.retropc.net/mm/archives/1033/feed 0 http://www.retropc.net/mm/archives/285 http://www.retropc.net/mm/archives/285#comments Tue, 18 Aug 2009 02:27:22 +0000 moriyan http://www.retropc.net/mm/?p=285 http://www.retropc.net/mm/archives/285/feed 0