すいません、エミュレータもドラクエも進んでません。 止めたわけじゃないんですが。 技術的問題ではなくて余裕の問題です。 いつもチェックしてくださっている方々、すみません。
p6editのファイルメニューに最近使ったファイルを追加。 ついでに、いつまでもバージョン0.xではかわいそうなので、1.0にしました。 他にも盛り込む機能のアイディアはありますが、一応実用の域には達したと思いましたので。 また、テンキーの記号部分にA〜Fを割り当てて16進入力できるようにしようとしたのですが、キーが少ないのでうまくいかないね、ということで止めました。
フレームバッファのサイズ変更に対応。 やっぱり真夜中にモノを考えようとしちゃいけません。 次の日に考えたら自然と分かっちゃったんですから。 ともかく、これで200ラインと400ラインだけでなく、横320ドットと640ドットもおっけーさっ。 まだやらないけど。 192ドットと200ドットも、フレームバッファを変更するのがスジかも知れませんが、もう面倒臭いので200ドットで通します。 オーバヘッドだってあるわけだし。
他はタイミングとか色管理とか、やることはあるんですが今日はもうこれで満足してしまいました。 根性なし。
インタレースに再び対応。 ウィンドウの上下左右のマージンも一時的にカットしてたんだけど復活。 ついでに4倍まで拡大可能にしてみた。さすがに遅い。 ただまだ問題があって、動作中のインタレースON/OFF切り替えがうまくいかない。 原因は分かってて、フレームバッファを実行中に200ラインと400ラインで切り替えてるからなんだけど、対処すると別のところでひっかかって。 常に400ライン確保しておくという手もあるのだけど。
音が出なかったのは/dev/audioでなく/dev/dspを開こうとしてたからでした。 でも別のLinuxでは/dev/dspのまま動くんだよなぁ、どっちもVineの2.0なのに。 謎。
今はインタレースを省略してしまったりしているので、その辺やらないとな。
iP6 0.6.4の画面周りだけをfMSX 2.2のものに入れ換えてみた。 かかった時間は4時間くらい。 なぜが音が出なくなったのは原因不明のまま明日以降に持ち越し。 若干やっつけ仕事的にやってしまった部分があるのでどうせ整理しないといけないしね。 最近はごく一部の変更だけだったので、これだけエミュレータのコードを読み書きしたのは久々。 楽しかった。ホントはそんなにヒマじゃないハズなんだけど。
最近使ったファイル機能は何か特別なAPIでも用意されてないかなと期待してみたけど、なさそうだね。 テンキー部にある記号は、キーボードによってビミョーに違ってたりする?
SRの画面周りの調査。
- N66SR-BASICにはSCREEN 1〜3までしかない
- N66SR-BASICマニュアルとMr.PCテクニカルコレクションでは、SCREEN 3のVRAMの説明でB0〜B7の並びが逆になっているが、マニュアルの方が正しいようだ(R0〜R7も同様)
- ハードウェアスクロールをエミュレータ上で実装するときは、フレームバッファからVRAMに転送する際に処理するといいかもしれない
先日p6editを使って思ったこと。 テンキーで16進入力が出来るとラクそう、ファイルメニューに最近使ったファイルが表示されると良さげ。
SR用のsaver2で、実はCGROMが全部出力できていないことに気付いた。 出てないのはモード6の25桁のときのフォントなんだけど、画面を25桁状態にしてみてからセーブしてもダメで、更に試してたらN60-BASICでsaver(1)を使うとN60用フォントの後ろに出力されていることが判明。 おや? ということはSCREEN2はCGROMを使わずにハードウェアで描いてるわけですか。 ということはiP6をSRのROMで起動してやると、N60-BASICのSCREEN2が狂うってことですか。 ...ホントだ。直そう。
というわけで、上記のバグと、6601のKANJIが使えないバグを直したバージョン0.6.4を公開しました。 1年ぶりのバージョンアップがただのバグフィックスってのも淋しいですが。
Macintoshプログラマ募集中。
p6editをバージョンアップしました。 ステータスバーが付いて、ファンクションキーの内容が表示されます。 もちろんShiftキーを押すとF6〜F10になります。 かなりエミュレータくさくなってきてるんですけど...。
オニオンハウス、うちでは動いてまっせとゆみたろさんが教えてくれたので(いや、「まっせ」とは言ってないけど)調査。 分割ロードするようになっているんだけど、前のファイルの末尾のゴミが影響していたのと、P6DatRec2でなくP6DatRecにしてみたら変換ミスが1バイトだけ発覚。 ちゃんと動きました。
PC-6601SRの内蔵ドライブはCHINONのF-353。
オニオンハウスとスパルタンXを手に入れたので、早速6601で動かしてみる。
うん、どっちもちゃん遊べるね。ふーん、こんなゲームだったんだ。
じゃ次はエミュレータ上でね。
オニオンが動いてスパルタンは動かないんじゃないかな、というのがなんとなくの予想だったのだけど、なんと結果は逆になってしまった。
A面とB面で2回ずつ試してみたけど全部同じファイルになってしまったし、6601では動いているので、テープの読み取りミスではなさそう。
iP6でもPC6001Vでも同じ症状だったので、ちょっと変わったことをしているソフトなのかも知れない。
PC-6001を譲っていただきました。 今まで持ってたのって動かなかったんですよね。 早速、6001専用のグラフィックモードを使っているAX-7のデモを起動。 うむ、確かにこれだと正常に表示されるね。mk2以降だと違うんだけど。 で、そのまま動かしてると...あれ? BGMが違うよ? mk2以降だと、宇宙人の音楽のようになってしまっていて(もちろんエミュレータでも)、これはどうなってるんだろうと思ってたんだけど、6001だとちゃんとした音楽になってるではないですか。 こんな所にも初代機独特の仕様があったのか。 うーん、サウンドLSIに与える初期値が違うとか?
mk2以降での挙動を再確認する為に66SRを起動したら、うげ、なんかハードの挙動がヘンですよ?
最初のメニュー画面が思いっきり乱れてて、それでも操作はできるので使うとまた元に戻って...。
どうも、0〜7fff番地のRAMにアクセスすると妙なデータが返ってきてるみたい。
そういやこの前、ちょっと衝撃を与えちゃったからなぁ。
おかしいのはメモリICか、メモリコントローラなのか。
それが分かったとして修復できるのか...。
一度蓋を開けて中の掃除でもするかなと思って開けようとしたのだけど、上面と前面が繋がってるのでなかなかスムーズに開けられず、途中でバキッと言われるとかなわんので中止。
はうぅ。
ハードを入手したら、壊れる前にとっととエミュレータを作らないと危険、ということがよく分かりましたです。 ええ。
今日はこんな感じ。フィールド画面のサイズもちょっと変わってます。
フォントはどこにあるかすぐに分かったのでコンバートしました。
ウィンドウの配置については、そもそも画面のサイズが違うので同一にはできないけど、それぞれのウィンドウの幅と高さは同じ。
だからちょっと窮屈だね。
GB版のスクリーンショットを見せてもらったけど(さんくすっ!)、FC版とあまりに違うので「こんなんDQ1じゃないやいっ」と却下、なるべくFCに似せる方針。
ウィンドウは表示されるけど、まだ機能はしない。
戦闘画面も、歩いてると勝手に敵が出てくるわけじゃなくてキーを押すと切り替わる。
でもちゃんと中央からぐるんぐるんと出てくるゾ!
あと、フィールド画面のBGMがメロディーだけ鳴るようになった。
そろそろシステム部分のプログラムを書かないといけない気配。
どうも、プログラムのサイズさえ気にしなければ作れるんじゃないかという気がしてきた。
もちろんサイズってけっこう重要な問題なんだけどね。
こう言ってはなんだけど、所詮FC時代のソフトであって、そんな無茶なことはやってないわけだし、アクションではないのでスピードはそんなに要求されないし。
それにしても、いや〜楽しいわ。もー他のことが手につかなくて。
世間はDQ7なのにね。
堀井雄二さんが作ってくれないので、こんなん作ってたりします。
フィールド上を歩き回ることはできますが、まだ街や洞窟の中には入れません。
敵も出てきません。コマンドウィンドウも出てきませんしBGMも鳴りません。
本当に歩き回るだけですが、歩行可能領域のチェックだけはしてます(岩や海の上は歩けない)。
ファミコンのようなスクロールはせずに、キャラクタ単位で書き換えてますので、速度もまずます。
木が黒すぎたり、平地と砂漠の区別がつかなかったり、キャラクタの抜きがまだとかいうのはあるけど、この辺は後で。
白黒だし画面はちょっと狭いけど、けっこう雰囲気出てると思いません?
本当は、ファミコン版のROMを逆アセンブルして敵の出現確立や戦闘ダメージの算出アルゴリズムなども全く同じにして、グラフィックもコンバートしたかったんですが、とても手に負えそうにない(真似をすることが、ではなくて調べることが)ので、外から見て分かるところだけでそれらしくしていく方針。
グラフィックもマップデータも、ファミコンの画面を見て手作業で移してます。
かっこ悪いですね。
一番心配していた速度が思ったほど悪くなかったので、次に心配しているのは容量。
今は地上のマップデータ(128x128)だけで8KB。
理想は64KBに一括ロードで後はオンメモリ、だけど、厳しいよねぇ。
真面目に計算した訳じゃないけど。
もし本格的に開発が進めば、ディスクを使うことになるでしょう。
ROMカートリッジにしてしまえば、バンク切り換えが使えるしアクセス速度は向上するしFDDレスのマシンでもOKだしで、いいことずくめなんだけど、さすがにね。
もうひとつ心配しているのはテキスト表示用ウィンドウのレイアウトで、ファミコンのままというのはまず無理。
GB版はどうなってるのかなー。
部分を作ってみてから考える方針なので、全体像は未定。
当初はこのフィールド画面だけ作ってみて、動かしてみて、その時点で実用にならず終わりかなと思ってたのに、意外と行けそうな気がしてきて逆に困ってたり。
何より問題なのは、もしこれが完成したとしても配布できないってことだね。
これを作った理由のひとつに、DREAM 6000の存在があります。
DREAM 6000はとても面白いページなんだけど、プログラムを作る人としてはハメコミ合成なスクリーンショットだけじゃなくて、曲がりなりにも実際に動くものを作ってやろうじゃないの、というキモチ。
fMSX2.2の画面の拡大縮小について追加。 拡大縮小はX11ScaleImageで処理していて、これを呼び出しているのはX11DrawPort。 但し、等倍時はX11ScaleImageを呼ばないようにしているのと、既にあるものをわざわざカットすることもないので現状でいくことになりそう。 倍率の指定は、コマンドラインオプションではatoiを使っており(つまり整数倍のみ)、かつ1倍から4倍に制限しているが、実行中のウィンドウリサイズによる拡大縮小は縦横別に1/4倍から4倍まで、ピクセル単位で変更可能。
iP6 ver.0.7(予定)で、さしあたって目標にしていることはfMSX2.2ベースへの移行。 MSXとP6で共通の、Z80部やサウンド部も改善されてはいるけれど、主とおしてMSX固有の部分の改善がされているので、移行してどれだけメリットがあるのか? と言われるとちょっと困る。 でも、本家がバージョンアップしてるのにこっちはいつまでも1.5ベースというのが気分として嫌というのもあるし、特に画面表示まわりは、fMSX1.5用の拡大表示や複数depth対応のパッチを真似していてかなり読みづらくなっているのが、2.0以降では最初から組み込まれていて、しかも整理されているのでそれだけでもメリットはあるかな、と。
Z80エミュレート部ではCPUクロックのカウントはされていて、割り込みのタイミングに使われているけど、2.2でも相変わらず、実時間とのシンク(どう言えばいいのだ? ウェイトで通じる?)はされていない。 ただサウンド出力については少し改善されているようで、音がぶちぶち切れていたのがなくなった。 それでも拡大表示しているとき(処理が遅い)としていないとき(処理が速い)でテンポが変わってしまうので、やはり不完全。
fMSX2.2のZ80部についての調査結果。
- IFFの各ビットの意味
- bit 0 : 割り込み許可(1:可、0:不可)
- bit 1,2 : 割り込みモード(00:0、01:1、10:2)
- bit 3,4 : 不使用
- bit 5 : EI命令で1になり、その直後にICount<=0になると0になる。詳細不明。
- bit 6 : RETNで使用。詳細不明。
- bit 7 : 1:HALT中、0:HALT中でない
- IBackupはEI命令実行時のICount値を一時的に保存する
- IAutoResetは1ならIRequestをリセットするが、fMSX2.2では0のまま
- IRequestは割り込み処理のアドレスまたはそのポインタ
- Z80.cのCodesFDでswitch内のdefaultにif(R->TrapBadOps)がないのはバグ?
- InPort/OutPort配列(関数へのポインタの配列)が用意され、ポート番号ごとに違う関数にすることが可能。ただしfMSX2.2では全ての要素がInZ80/OutZ80を指している。
fMSXの、たぶん2.0以降では実行中にウィンドウサイズを1倍から4倍まで変え ることができて、しかも整数倍だけでなく小数倍も可能だし縦と横の倍率が同 じでなくてもよい。たぶん、フルスクリーンができないXでの苦肉の策のよう に思う。ただ、これはこれで面白いのだけど必要かと言われるとそうは思えな いので、整数倍のみ、縦と横の倍率は同じにするつもり。
fMSXではfMSX.cのmain関数内でコマンドラインオプションの解析をしているが、iP6の現行バージョンでは一部をXtで、一部をmain関数で解析している。 これはモデル指定やsound/nosoundのようにたいてい同じ指定をするものはXt(リソースファイルで指定できるから)、helpのように毎回指定する意味のないものをmainというつもりで分けた。 でもこれは中途半端なので、次では全部リソースにする予定。 勝手に解釈してくれるから楽だし。
使用ライブラリおよびGUIについては、iP6の現状がメイン部がXlib、設定部のみXt。 実際、設定部を除けばボタンやリストボックスのようなUIは不要なわけで(メニューバーはあってもいいか)、設定部はXlibで書こうとすると大変なのでXtだけど、ファイル選択ダイアログがないのが難点と言えば難点。 自分ではxterm辺りからコピーしたらいいじゃん? と思ってるのだけど。 GTK+とかを使えば見映えば良くなるしファイルダイアログも使えるけど、どのUNIXでも使えるのか不安なのと、この程度のエミュレータの為にライブラリからインストールしてねっていうのも大袈裟かなぁとか。 Linuxのみの機能をがしがし使ってるなら、UNIX汎用はとっとと諦めてしまうだろうけど、現状は全然そんなことないと思ってるので他のUNIXでも使って欲しいし、ライブラリもXが使えるなら間違いなく入っているor使えるものがいいと思っている。 よって現状通りのつもりだけど、何か意見があれば送ってください。
そんなわけで、0.7は内部的な変更が主で、新機能はあまりないと思います。 ごめんなさい。
BASICコンパイラを作るつもりで、でも命令の解釈はコンパイル時に済ませても、命令の実行はどうせインタプリタROMを使うんだから、インタプリタROMをもっと知っとかないとダメよね、と思ってしばらく逆アセンブルリストを読んでました。
でも、こりゃ手に負えないな、というか、少なくとも1週間やそこらで理解できそうにないと思いだしたので、一旦保留することにした。
もちろんエミュレータを作るときにROMは読んでたんだけど、エミュレータ作りにおいて必要なのは、キー入力やテープ入出力、画面出力といった周辺機器との通信の仕方などが中心で、CPUと主記憶だけで完結してしまう部分(それこそBASICプログラムの実行など)については、Z80部をちゃんとエミュレートしていれば深くつっこまなくても動いてしまう。
だからロクに読んだことのない部分というのが結構存在するワケ。
どんなコンパイラにしようと思っていたか、忘れないうちにメモ代わりに残しておく。
動作するのはUNIX/DOS上。入力はCSAVEされたファイル。
出力はたぶんアセンブリ言語で書かれたプログラムで、これをZ80クロスアセンブラにか
けた上で更にCLOAD可能な形式にする。
モードやページ数によってプログラムの格納されるアドレスやワークエリア、それと各命令の処理アドレスが変わりうるので、これはコンパイル時に指定しておく。
具体的にどの辺をコンパイルするか。
- まず前提として、入力したBASICプログラムは入力した時点で中間言語に変換した上でメモリに格納される。 テープやディスクにセーブするときもこの状態で保存される(アスキーセーブのときは別)。 で、プログラムを実行するときはインタプリタがこの中間言語を見て処理アドレスを求め、そのルーチンをコールする。 基本的にはこれだけ。 ただ、この「処理アドレスを求める」というのだってちょっとした処理をしているわけで、でもコンパイラならコンパイル時にアドレスを埋め込んでおいて、実行時にいきなりコールすることだってできるよね、そしたら少し速くなるよね、というのがひとつ。
- GOTOは、行番号がアスキー文字のままメモリに格納されていて、もし現在の行番号より目的の行番号が小さけばプログラムの先頭から、大きければ現在の行から該当する行番号を探していくんだけど、これもコンパイル時に決定できるよね。
- BASICの各命令を1つずつマシン語に変換していくだけで、最適化は考えない。
- FA00H以降のワークエリアは、基本的にBASICインタプリタが使っているのと同様の使い方をするつもり。 変数の格納法も同様。
- N6*-BASICの変数は浮動小数と文字列しかなくて、もし整数型を導入すると変換後のプログラムは速くてコンパクトになるだろうけど、変数宣言が必要になるだろうしそうなるとBASICの仕様を変更することになるので、これは変えない。
例えばGOTOという命令は、後に続く数字(行番号)を読み取って、該当する行が格納されているアドレスを見付けたら「次に実行する命令のアドレス」をそこに書き換えて戻る。 これみたいな簡単な命令ばっかりだったらいいんだけど、OUTやPOKEだと数字だけでなく変数も使えるので、インタプリタROMによる変数処理ルーチンがどんなものか知っておくべきだと思うのだけど、この辺りからややこしくなってくる。 INPのように値を返す関数になると、引数の解釈の仕方だけでなく値の返し方も知る必要があるし、A=INT(RND(1)*10)+1のような数式をどのように解釈しているか、なんていうのもまだ読めていない。 数値を扱うだけならまだしも、グラフィック関係の命令も当然処理が複雑。 結局ほとんど読めていないことになるなぁ。
で、コンパイラを諦めて今度は久々にiP6に手を入れることにした。 fMSXの1.5を基にしてたんだけど、fMSXも2.1になっちゃったし。 と思ってたのに、今日見たら2.2になってますね。 でも、今日はfMSX2.1のソースを眺めただけ。
こんなところにMC6847の説明が。 PC-6001のVideo Display Generator、M5C6847P-1はこのMC6847コンパチです。
P6 software listを更新しました。 4月に入手したPCマガジンから得た情報を追加しています。
ネットオークションでは結構高値でP6本体や周辺機器、ソフトがやりとりされているようですが、何万円も払って商品を買った人達は一体何をしているんでしょうかね。 何もみんながP6用のプログラムを作ったり、解析してエミュレータを作ったりすることはないけど、こんなことして遊んでまーす、っていうのを各自のホームページであれこれ書いてくれるといいのになぁ、と思うわけですよ。
Cコンパイラを作るよりは、BASICコンパイラの方がインタプリタを見ながら作れそうだし、使える人も多そうだしで現実的かなと思う。 BASICコンパイラは当時市販のものが出てたので、そういう意味では同じものを作るよりもCを作った方が面白いけど。
解析マニュアルのシステムルーチン解説、N60拡張とN60mもついでに入力してしまった。 でもPC-6001mk2とPC-6001ではROMに微妙に差があるから、TechknowのROM内ルーチン一覧も欲しいなぁとか。
今日発売のSoftware DesignでiP6とPC6001V for Linuxが紹介されました! 事前に編集部の方からメールを頂いていたので知ってはいたんですが、一応発売日まで黙っておいてみました。 SDを見てこちらにいらっしゃった方々、以後お見知りおきを。
p6editで、折り返しが有効になっているときにAuto機能が誤作動するバグを修正しました。 CaretPosがsoft line breakも1行で数えてしまうのが原因だったので、SelStartを使うように書き換えています。
学習機能で、よく使う順に補完されるってのもいいかもね。
コロニーオデッセイのページに、一部(オープニングとEsperanceのみ)ですが画像を入れてみました。 あまり見映えは良くありませんが勘弁してやってください。
解析マニュアルの打ち込みはN60部だけ完了。 入力はプレーンテキストなので、適当にHTMLに変換して...おぉ、なかなか良いですな。 6001にも対応したプログラムを書くだけならここだけで十分だなぁ。 しかし我ながらよーやるわ。 もちろん、あくまで著作物なので自分用のものであり、ここで公開したりはしませんから悪しからず。
実はここ3日間ほど、久々にZ80で遊んでました。
何をしてたかというと、LightsOutに続くパズルゲームを作ってました。
今回もゲームの内容自体は借り物で、MIAのストン・ボールの移植です。
今回もグラフィックは使わずにテキストで済ませていますが、タイトル画面などでメッセージが多量に表示されるので少しそれらしくなっています。
メッセージの表示くらいはBASICでやった方がいいんじゃないかという気もしますが、自分では「マシン語であることに意義がある」ということでがんばってみました。
LightsOutのリストから使えるところは流用したのと、elからの移植だったというおかげで開発は非常に速く進み、本体は1日で出来たのでした。
p6softのページにあるので是非遊んでみてくださいませ。
実はこのゲームは2年ほど前にEmacsLispで書いたことがあって(何故?)、そのときは88版のBASICリストを見ながらだったのですが、今回はそのelを見ながら作っています。
このelもそのうち公開しようかな。
で、なぜ今になってこれをやったかというと、前からその気はあったのですが、次はスワンでやろうかなというのがあって、その前に思い出す意味も含めて、と。
LightsOutのときに書いたんだけど、Cで開発できたら面白いよね。 コンパイラ自体はP6上で動かなくても、UnixやWindows上でクロスコンパイルできれば十分だと思うんだけど、コンパイラそのものよりライブラリの構築が大変かな?
マシン語プログラムを書くときは、エミュレータの開発にも使っている解析マニュアルという本を参照して、インタプリタROM内で使えるルーチンは遠慮なく使うようにしているのですが、「これがオンラインで参照できたらいいのになぁ」と思った次の瞬間には、入力を始めている私が居たのでした。 さすがにしばらくすると阿呆らしくなって中断しましたが、こういうときこそT-codeなのかも知れませんね、と思った次の瞬間にはT-codeの練習を始めている私が居たのでした。 んー、こりゃ素直にSKKで頑張るのとT-codeが身に付くのとどっちが早いか分からんな。
p6edit、ちょっとだけバグ修正しました。 画面のプロパティでスクロールバーが太いときにRichEditがウィンドウに収まりきらないことがあった点です。 ワードラップについては、EditWordBreakProcをいじってたんですがどうも理解できなかったのでしばらく手を付けないと思います。 ごめんなさい。
PCマガジンのスクリーンショット、ローカルのファイルを編集しただけでサーバに転送してませんでした。 おまぬけ。 今日は更にリバーサルを追加してあります。 しかもウィンドウのタイトルバーがまた変わっています。 NeXTを使っていたものとしてはやっぱりクローズボタンはこうなっていた方が落ち着くわけで。
1D(として使っている2DD)のフロッピーから、エミュレータ用のテープイメージを作ろうと、バイナリエディタでディスクイメージとにらめっこしながら「ここだ!」という所を抜き出してみたり、リバーサルを打ち込んだはいいが実行方法が分からなくて、ダンプリストから「ここだ!」という所を見付けてEXECしたら当たったり。 どうもみょ〜な技術だけ身に付いていってる気がする。
p6edit 0.6を公開しました。
変換結果の確認ができるようになった他、フォント、背景色、ウィンドウサイズなどを保存するようになりました。
次はワードラップを直したいところ。
フォント設定の保存で困っていたというのは、フォント名、サイズ、スタイル、色を保存しておいて読み込むところまでは何も問題ないのだけど、RichEdit1->Font->Nameは設定されているのに文字を入力するとそれが反映されないという現象が起きていた。
おそらく、コントロールに設定されているフォントとコントロール内の選択部分のフォントは別物ということなのだろう。
それでいくつかの手を試した結果、先にSelectAll()しておいてからフォントの設定をするということにした。
PCマガジンのスクリーンショットのページにQUIX、沙悟浄、倉庫番を追加しました。 ウィンドウの枠が変わっているので一発で分かりますね。
もーしわけないっ! p6edit 0.5に重大なバグがありました。 テキストがプレーンテキストとしてセーブ*されません*。 急拠差し替えて0.5.1としました。本当にすみません。
もうひとつごめんなさい。
昨日書いたパイプは子プロセス側も書き直す必要があるというのは嘘です。
私がサンプルを読み間違えてたみたいです。
そんなわけでコンバータ呼び出しの部分は解決したので、フォント設定の保存ができたら0.6としてリリースします。
背景色の保存はもう出来てるんだけどね、フォントがどうも厄介なのよ〜。
ちなみにコンバータ呼び出し部は、元々はsystem()を使っていて、これをCreateProcess()にするとパスが長くても大丈夫になりました。
次に第三形態としてAllocConsole()してからCreateProcess()して、子プロセスの終了後にGetExitCodeProcess()で終了コードを取得してMessageBox()で正常終了かエラーかを表示した後にFreeConsoleするという形にしました。
GetExitCodeProcess()はAlloc/FreeConsole()を使わない場合でも使えるけど、先にAllocConsole()を使っておくとFreeConsole()するまではウィンドウが残るのが利点。
でもこれでも不満だったので、最終形態はCreatePipe()してからCreateProcess()することで子プロセスの標準エラー出力を取得し、終了コード(正常/エラー)だけでなくエラーの内容まで親プロセス側からMessageBox()するようにしました。
今回の場合、エラーメッセージったって長さは知れてるしね。
ついでにDOSプロンプトのウィンドウも出さないようにしました。
バグレポートや新たな要望を頂いたので、今日も引き続きコーディング。 背景色設定、検索の実装は割とすぐ終わり、メールで指摘された以外に自分で発見した小さなバグもすぐ取れた。 ここからが問題で、変換結果を確認できないというのと設定内容を保存したいというのが課題だったのだが、どっちも一から勉強しないといけないので時間がかかるかかる。 結局、設定の保存は設定画面の内容のみでフォントなどは見送り。 レジストリは使わずiniファイルにした。 変換については更に勉強が必要そうなのでこれも先送り。 そんなver.0.5です。
変換はですね、今はsystem()関数で呼び出してるんですが、現状だとMS-DOSプロンプトが一瞬現れてすぐ消えてしまい(環境設定による?)、エラーの有無が確認できないのと、パスが長いか何かの条件で呼び出しすら行われないことがあるのが問題です。 パイプを使うという案もあったのですが、どうもそれだとコンバータ側も書き直す必要があるらしくて(何の為のパイプなんだか)、そんなんやったら組み込んだ方が早いわい! と却下になりました。 ま、もう少し調べてみます。
昨日、ver.0.3を公開した後更に色々いじってたら、AUTOとKEYがいつの間にかできてしまってこっちがビビッたり。 一休みしてから更にcsave/txt2basの呼び出しを作った。 よってver.0.4として公開。ver.0.3は短い命でした。 後は補完の拡張かな〜。
p6edit ver.0.3を公開しました。 前に書いた通り補完がTabキーになったのと、補完中にTab以外を押すと確定されるようにしたことが大きな変更点です。 AUTOについては、アルゴリズムは大したことないと思うんですけどインタフェースが決められなくってねぇ。 やりたいんですけど。
p6editのEsc補完は某所で猛烈な反対にあってしまったので(誇張表現)、次のバージョンでTabキーに変更になります。 あと、行の折り返しができるようになる予定です。 ところがVisual BasicだとTabキーを拾えなかったり、テキストボックスのスクロールバーの有無を実行時に制御できなかったりするので(いや、頑張れば出来るのかも知れないけど)、とっととCに移行することにしました。 わざわざこのソフトの為にVisual Basicのランタイムをインストールされた方はすみません。 今度は別のランタイムが必要になる予定です。 その代わりではないですが、フォントをいじれたり「変更を保存しますか?」の確認も出ます。 どーだ、すごいだろ(嘘)。
ヨソで話があった、BASIC入力支援エディタを製作中。
ファンクションキーと補完機能ができたので公開。
行番号とかはこれから。誰か使ってくれるんなら、ね。
VBで作ってしまったのでランタイムやらの問題があってちょっと嫌。
結局、ランタイムは別で用意してもらうことにしました。
面倒でごめん。
作る前は、EmacsLispでやろうかとか、WZのマクロでもそれなりになるんじゃないかとか思いはしたのですが、イヤな予感がしたのでおとなしく単独のアプリケーションとして作ることにしました。
また、Cで作るとまたあれこれ面倒そうなのでここはVBで手っ取り早く、ということにしました。
ランタイムの問題があるのは分かってたんですが、んじゃお得意のVBAで、って訳にもいかないでしょうし。
今後の追加機能として、Enterを押してもカーソルが次の行に行くだけでテキストはそのままとか、P6のフォントで表示されるようにするとかいうのもチラッと頭に浮かびましたが、そこまでするならエミュレータ上で入力した方がいいよね。
そっちの方向で行くとしたら、補完機能をZ80上に実装したらOK?
PC6001V for Linuxは、予想通り全然反応がないです。わはは。 マ、テープが読めないんじゃ使い物にならないというのもありますし。 ただ、エミュレータニュースのページではちゃんとチェックされてたりしてて、みなさんご苦労様です。 なお、パッケージに含まれているバイナリは、Vine Linux 2.0上でコンパイルしたものです。 もしlibcだかglibcのバージョン問題で動かないときはコンパイルし直してください。
最近ツールばかり作ってる気がするので、いい加減エミュレータ本体に手を入れたいなぁ。 まぁエミュレータもツールと言えばツールですが。
Yahoo!オークションでPC-6601が3000円というのがあって、しばらく様子を見ていたんですが、終了1日前になって急に値が上がっていき、最後は2万円近くで終わったようです。予想はしてましたけどね〜。
毎年6月1日は6001にちなんでP6の日です。私が決めました。
PC6001V for Linuxについて、テープファイル選択時にセグメンテーションフォールトになるのは、(1)該当ディレクトリに.p6ファイルか.casがあるとき、(2)..(親ディレクトリ)にアクセスしようとしたとき、の2つです。 それ以上詳しいことはまだ調べていませんが、Allegro for LinuxはあくまでWIPなので仕方ないかなという気もしますね。
数日前からちょっと浮気して、商売敵(?)のはずのPC6001VをLinuxに移植。 P6Vが使っているAllegro、SEAL、libGIF、libiniといったライブラリはどれもLinuxに移植されている/移植可能で、各ライブラリをインストールしてP6V本体にちょちょっと手を加えるだけでとりあえず動くようになってしまった。 手を加えたのは、改行コードの変更やdjgppのnot ANSI, not POSIXな関数の置き換えとか、AllegroのDOS onlyな最適化コードの削除といった程度ものがほとんど。 この程度の修正でユーザのプログラムを移植可能にしてしまうライブラリってものは偉大だなぁと実感。
はっきり言っときますが、iP6をやめるっていうんじゃないです、ええ。 手軽に移植できそうだったのでやってみただけですから。ご心配なく。
txt2basなんですが、前から気になっていた濁音・半濁音に対応しました。 思ったよりカンタンでした。今までやってなかったのはタイマンですな。 ごめんなさい。これでやっと「使える」ツールになったかな?
http://www.6001.com/というものがあるという話は以前聞いてたんですが、いろいろ調べてみたら、6001は.netも.orgも取得済みだそうです。 で、6601は.comのみ取得済みで.netと.orgは空き、PC6001, PC6601, PC-6001, PC-6601は.com, .net. .org全て空いてるそうです。 6001.com以外は「取ってあるだけ」っぽいですけどね。 以上、お名前.comで調べました。
SONYがバイオノートSRってのを発表したそうで、NECがケチつけたりしないかなと勝手に期待。
NEC「SRと名前を付ける以上は、CMキャラクタは武田鉄矢にしてもらわないと困る」
SONY「武田鉄矢はちょっと苦しいので、なんとか他の人にしてもらえないか」
NEC「じゃあ斉藤由貴で手を打とう」
とか。しないよね、やっぱり。
iP6で、キーボードによって刻印通りに入力されなかったり、入力できない文字があったりします。 他にも、ファンクションキーがウィンドウマネージャのショートカットと衝突したりするんですよね。 さて、どうしましょうかねぇ。
PCマガジンの、持っていなかった号を譲っていただきました。 冷静に考えれば今更入手したところで何になる、という話になるわけですが、もはやそういう論理の通用しないレベルなので考えても無駄です、ハイ。 実はPCマガジンはthe MICRO Communicationという前身があって、これが季刊、隔月刊となった後に月刊のPCマガジンになったんですが、...さすがにこっちの方は手に入らないだろうなぁ。 それはそうと、入手した分にはまだ知らなかったソフトが沢山載ってるので、これを見ながらソフト一覧のページを更新しなきゃいけませんね。
作る作ると言っておきながらそのままだったコロニーオデッセイのページを公開しました。 後編は...?
X68000のソフトウェアが公開されたことに刺激を受けたのか、MSXフリー化プロジェクトというのがあるそうです。 実現は難しいでしょうが、もし実現したらP6も...と思っているのは私だけではないはず。 どっちもMicrosoftが絡んでますからね。
更に更新しました。今回はバグ修正というより機能追加です。 大したことじゃないけど、PRINTの代わりに?が使えるようになりました。
N6*-BASIC の仕様で1行は行番号を含めて71文字となっていますが、txt2basではこのチェックをしていません。 で、もしこれを超える行を作るとどうなるかというと、ちゃんと変換もロードも実行もできる「みたい」です。 BASIC上で行を入力する際のバッファに制限があるだけで、実行に関しては制限がないか、もしくはあってももっと緩いんでしょうね。 考えてみれば実行するときには中間言語になってるんだから不思議でもないですね。 これについては保証はしませんし、どのくらいの長さまでなら大丈夫かも知りません。 少なくとも、変換については行バッファのサイズがあるのでこれを超えると誤動作します。 71文字以内なら当然オッケーですよ。
完全に思い付きなんだけど、この辺のツールって個別のソフトにするんじゃなくて、エミュレータ本体にPlug-inの形で統合できるようにすると、エミュレータが直接Waveファイルからロードできたり、テキストファイルからロードできたり...あ、コア作るの大変そう。 やっぱりいいや。
前から疑問なんですけど、シフトJISの837F(「ミ」と「ム」の間)ってどうして空いてるんでしょうね。 てゆーか、これ以外にも言いたいことだらけなのでシフトJIS決めた奴出てこい! って感じ。
txt2bas、早速バグが見付かったので修正して置き換えました。 DATAとREMの扱いを修正してます。
SJISサポート、いくつか方法は思いついていたのだが、どれにするかに悩んだだけで、決めてからは意外と早かった。 文字列から中間言語への変換もSJISからP6キャラクタセットへの変換も、最初はエレガントにやろうと思っていたのだが結局strncmpで線形探索とかいう一番ローテクな手法になってしまった辺りちょっと嫌だけど、こういうちょっとしたツールは使えればいいからいいや。
というわけで、txt2basを公開。 例によってエラーチェックや動作テストはあまりやってないので、おかしかったらその時言ってくださいということで。
コロニーのマップ画像をちょちょっと。 Windows上でちょっとしたドローソフトってのが見当たらなかったので、Linux上でTgifにした。 これも使い易いとは思わないけど、そんなに複雑な絵を描くわけでもないのでいいや。
テキストファイルを読み込んでテープイメージを作るプログラムを開発開始。
ASCII文字セットでの入力はとりあえず出来た感じ。
でもかな文字やグラフィックキャラクタがあるからやっぱり2バイト文字に対応しないとダメよね。
2バイト文字っても1種類じゃないし、Unicodeなんてのもあったりするから、あんまり関わりたくないのだけど。
Unicodeはともかくとして、EUC, SJIS, JISについてはnkfかなにかで変換してもらって、プログラム側では1種類だけサポートして、EUC(or SJIS)→P6キャラクタセット、P6キャラクタセット→中間言語、中間言語→テープイメージと段階を分けて作っとくと、どこかで再利用が効くかなと考えてるところ。
P6キャラクタセット→EUC/SJISってのがあると、RAMダンプやテープイメージ中のひらがながバイナリエディタで読めるようになるので嬉しいかなとか。
データを2バイト化するのではなくて、1バイトのままP6キャラクタセットを表示できるアプリケーションを作るってのも手だけど、こっちの方がしんどいよね。
あ、コロニーは前編の各シーンについてのメモは揃ってるんですがHTML化がまだなのと、マップ画像をまだ作ってないのとで未公開です。 ごめんね。
アレを手に入れてしまいました。むふふ。
Yahoo! オークション、P6関連のブツがけっこう流通してるようですねぇ。 なかなかいい値がついていることが多いのでまだ手を出してはいないのですが、チェックだけはときどきするようにしてます。 本体はPC-6001が多くてPC-6601やPC-6601SRは滅多にお目にかかれないという印象ですが、これは普及台数の差でしょうか?
攻略ページを作るとか言っときながら、全然更新してません。すみません。 ある程度準備はしていて書きかけになっているのですが、時期が時期なので、2月の試験が済むまでは身動きが取れそうにないです。 うぅ。
他にも、
- P6に関するドキュメント作り(特にキー割り込みのようなハードとソフトにまたがる部分。エミュレータ作り始めの頃に調べた内容を既に自分でも忘れちゃってるのだ)
- PC6001VのLinux移植(AllegroのLinux版が開発中だからできるかも?)
- サターンのジョイパッドを改造してP6用にする(ここ参照)
- iP6のディスク対応、音声対応(まずはP6の調査から始めないといけないけど)
なんてことをやりたいなと思ってはいるのですが。 あと、もうすぐカウンタが10000になるので、それ記念というのもなにかできればいーんだけどねぇ。
代わりと言ってはナンですが、P6日記じゃない日記をやってますのでそれでも見てやってくださいな。 geocitiesって全然更新せずに放置しとくとそのうち削除されちゃうというのもあるし、更新してなくてもカウンタが少しずつ増えてるのを見ると、見に来てくれた人達に申し訳ないというのがあってやってるの。
というわけで、コロニーの前編を終えました。 正確に言うと「後編に行ける状態になった」というだけで、前編にもやり残したイベントがあるかも知れないけど。 初プレイから15年くらいかな? 長かった...。
実家から持ってきたPCマガジンの「アドベンチャー見栄講座」(コロニーオデッセイのヒント集)を見ながら、十何年ぶりにゲームを進める。 マニュアルが無いので途中セーブの方法が分からなかったのだけど、ディスクイメージから単語一覧を抜き出して発見する。 なんだ、SAVE GAMEかよ、簡単じゃん。気付けよ、自分。 昔プレイしたときは前編クリアしてないと思うんだけど、今なら英単語も昔より知ってるし、当時分からなかった部分でも今なら分かるかも。 攻略ページが出来る日は近い?
少し模様がえしました。