画像を選択（クリック)すると大きくなります。2002年8月から9月頃です。上から下へ 並んでいます。
一番下に追加しました。
またしても、細かいバグを見つけてしまいました。
PC-6601SR のTV予約の画面ですが、表示される曜日がおかしいみたいです。（汗） なんというか、一日ずれてしまっています。
これは、テクニカルコレクションでは、0が日曜日となっていますが、実際は 0は月曜日みたいです。 何故こうなっているかは、キャラクターコード表を見れば、すぐに分かります。
このバグは、あまり致命的というわけではないので、次のリリースには 取り込まれる予定です。
ちなみに、PC-6601SRの曜日って 98x1の様に自動計算はしないんです。人間がいちいち設定しないと行けないようです。(^^;;;; しかも、date$では設定できず、TV予約の画面で設定するみたいです。
ということは、毎週金曜日に予約を入れて置いても、曜日がずれていたら、意味が無いという・。（爆） その代わり、2000年問題が無いので、よしとしましょう。(^^;;
ちょっと、気分転換に、iP6を、Windowsに移植していました。（汗）
移植といっても、ベタ移植です。基本構造やGUIは C++Builder で作成して、コアのエミュレータ部分は C言語のままという、すごい状態です。(^^;
最低限動かせるぐらいまでの作業は、３日ぐらいで終了しました。 初めの頃は、とにかくコンパイルを 通るようにするのがしんどかったです。 一番、いじったのは、やはり Unix.c でした。（汗） これだけは、#ifdef の嵐になっています。(^^; ゆくゆくは、依存部分を win32.c というファイルに、切り出さないと行けません。
画面描画処理(Refresh部分)は ほとんどそのまま使用しています。そのため、拙作のiP6 改造版パッチとほとんどおなじ動きをします。（バグも同等です。）
キーボードは、最初全くサポートしてなかったのですが、かなり強引に サポートしました。しかし、この辺は、かなりいい加減なので、まだまだです。 （まだ、入力できないキーが有りますし・・。（汗））
あと、設定パネルがないので、機種を変えたり、ディスクを入れ替えるたびに、ソースリストをいじっては、コンパイルし治さないと行けません。（汗）
ちなみに開発環境は、Windows 2000 上の C++Builder 5 です。
画像を選択（クリック)すると大きくなります。
モード５も この通り。
ミッドナイトマジックも動作します。
とはいえ、とても公開できる代物になっていないです。もっとまともにしないと、公開できないですね。(^^; そのころには、Windows版の SR対応エミュレータが、競合各社からリリースされているかも知れません・・。(^^;;;
あと、できれば、Unix版と Windows 版で、ソースリストを統合出来れば良いんですが。 そうすれば、Unix版と Windows 版で、別々にメンテナンスしなくてもいいし、一つのパッチで、どっちもサポートするので楽なんですが・・。(^-^;
最近は、移転だなんだと、忙しいのですが、久しぶりに、バグを治しました。(^^;
SRの画面(320x200）から、N60 MODEの画面 (256x192)になるときに、画面の大きさが変わるので、画面がくりぬかれたようになってしまう問題ですが、あっさり治ってしまいました。（汗）
簡単に言うと、CRTコントローラのところで、画面を消してないのが原因ですが、 SRモードを監視して、変わっていれば、画面を消去するようにしました。（汗） 今日、ふと思いついたんですが、何で今まで 思いつかなかったんだろう・・。（謎）
しかし、Windows 版でも同じ問題があるので、全く同じ修正をしないと行けないのが、ちょっとつらいところだったりします・。（汗）
なんだか、降って湧いたように、Windows版なんてものを作り出しましたが、Unix版の方も変わらず更新する予定ですので、よろしくおねがいします。（＿） というか、ゆくゆくは、Unixと Windowsを こっそり両対応にして、パッチファイルを公開するのが、夢だったりするんです。(^^;
しかし、それをするなら、CVSサーバーみたいな奴が欲しいけどなぁ・・・・。 自動的に、文字コードの変換までやってくれる奴とか。(^^; まぁ、私のスキルでは 無理でしょう。(^^;
Windows版は、C++BuilderとVCLを駆使した奴がなんとか動いています。 しかし、これがすごい状態になっています。
C++ とVCLで土台を作って、その上に C言語のエミュレータコードが載っかっている感じです。C++とCの間は、接ぎ木をしています。
そして、極めつけが、Z80 CPUの実行方法・・。本来は Z80 CPUは無限ループなのですが、出来ないので、WM_TIMERメッセージを使用して、繰り返し駆動し治しています・・。（汗） もっと他の方法はなかったのでしょうか？（汗）
WindowsのDelphi の TBitmapって、メモリー上の bitmapのイメージに直接アクセス出来るんです。 これは、本当に有りがたく使わせてもらっていました。(^^;
これが何故重要かというと、元々のiP6も、ビットマップに直接アクセスするようになっているので、これを利用すれば、ほとんど変えなくても良くなるんです。
しかし、VCLに頼らないコーディングの場合も、考えておかないと行けません。大部分は、エミュレータのコードなので、C++Builder で作るほどじゃないですもんね。 VCLのソースリストを見たら、やっぱり、Pascalでした。Pascalをやっていて良かったです。(^^; うーん。なんとなく、分かったような・・・。そうでないような・・。（^^;;
って、もしかすると これって、Windows界の常識だったりしません？(^^;（汗） ただ、もちろんこうすることで、今の仕様に依存してしまいますけどねぇ・・。
Windows SDKだけによる、プログラミングも 一応勉強中なんですが、 それで最初の一歩というべき、プログラムが なんとか出来ましたので、スクリーンショットを公開します。（＿） ここまでくるのは、かなり大変でしたが、ちょっとだけ嬉しいです。(^^;
例によって、VRAMの中身を表示するだけのプログラムです。
プログラム的には、CreateDIBSectionというAPI関数を使っています。 それで、昨日書いた様に、ビットマップのイメージに 直接アクセスしています。 ということで、直接アクセスの方法が分かりました。(^^;
あれ？ そういえば、上下逆ですよね？(^^; これは、Windowsのビットマップは ボトムアップだからです。 これを治そうとすると、ｙ座標を上下逆にしないと行けません。（汗） って、なんで治さないかというと、たまにはこういうのもないと、どれも同じに見えるからです。（汗）
ちなみに、ソースリストをおいておきます。 （但し、あくまでテストプログラムなので、無保証ですが・・。（汗）
それにしても、SDKプログラミングの 肩の凝ること凝ること(^^;; 本当に、面倒くさいですね。
ついに、動き出しました。(^^; iP6 の Windows 版 (SDK Version) です。(^^;
まぁ、普通の人からすると、８月２５日の分と、どこが違うの？と思われるかも知れませんが、８月２５日の分は、C++Builderに 強く依存していました。だから、コンパイルするには、C++Builderを買ってくる必要があったのです。
しかし、これなら、一般的なC言語と WindowsのAPI関数だけしか使ってないので、色んなコンパイラでも、コンパイルできると思います。 出来れば、これから、これを拡張していきたいです。(^^;
参考までに、ソースリストの一部をおいておきます。 とはいえ、これだけでコンパイルできるわけでありませんが・・。（汗）
Z80 CPUは、相変わらず WM_TIMER で駆動し治していますが、メッセージ処理の合間に入れるか、悩み中です。(^^; 他の方は、どこに入れられているんでしょうか？
あと、ビットマップが上下逆になるのは、トップダウンにして、対処していますが、これって、Windowsのバージョンによる制限とか無いですよね？（汗）
あと、例によって キー入力はまだです。(^^; （当然、音も・・。） ちなみに、これが出来たことによって、だんだん方向性が見えてきました。(^^;
方向性としては、現状のiP6 をあまり変えないということです。 あとで、本家がバージョンアップしてしまうと、付いていくのが大変になりますし・・。 あくまで、現状の iP6 改造版が Windows で動いたらどうなるかな？ということになるとおもいます。
Windows版 (SDK Edition)ですが、キー入力も出来るようになったので、だんだんエミュレータぽくなってきました。(^^; これで、パッチをリリース・・。と思ったけど、エラー表示が全くなされないことに気づきました。（汗）
Unix版 ではこういう情報は すべて printfで シェルに対して表示しているんですね。しかし、Windowsの場合、全く表示されないんです。（汗）
これは、Unix系は、たとえGUIを持つプログラムでも、標準出力はシェルに繋がっているんですが、Windows系は、winmainで始まるプログラムだと、繋がっていないためのようです。（汗）
うーん。なんでつなげておかないんでしょうか？(^^; 確かに、その分オーバーヘッドが増えるけど、どうせシェルから起動する人なんか、ほとんどいないのにねぇ・・。
ちなみに、コンソールを扱うAPIをコールしておけば、一応使えるんですが、あくまで、専用のコンソールが立ち上がるだけなので、プログラムが終了するとともに、消えてしまいます・・。って、エラー表示としては使えないじゃんこれって・・(^^;
というわけで、一番エラーがおきやすい、StartP6() でエラーが起こった場合は、MessageBoxを 表示するようにしました。（汗） これで、一応エラーが発生したことが分かります。 とはいえ、詳しいエラーの内容までは分からないです。 もっと詳しい内容を知りたい方は、シェルを起動して、下記のように打ち込んでください。
あとで、log の中身を見てください。 これで、どこでエラーが起こったのか、詳しい内容が分かります。(^^;
これは、プラットフォーム共通のお話です。 パレット処理を改善しました。これで、モード6の画面の描画処理が速くなりました。 今までなら、フレーム落ちの危険性すらありましたが、改善されると思います。
今までは、１ドット書き込むたびに、いちいちパレット変換をしていたんですが、それではあまりにも遅すぎるので、（当たり前。）あらかじめ変換しておいて、そのカラーコードをそのまま 描画に使うようにしました。
具体的には、デフォルトのカラーコードの配列に対して、パレット用のカラーコードの配列を新設。あらかじめ デフォルトのカラーコードから、パレット用にコピーしておき、それを描画で使用。パレットの変更指令が来たら、パレット用のカラーコードに変更を加える。という具合です。
まぁ、今までの実装は なんとか動くようにしたという実装だったので、こっちのほうが本物のパレット処理だと思います。(^^;;
これも共通のお話です。 通常、ディスクなしで起動して、FILESを実行すると、Error になるんですが、 PC-6601SR の場合は、Okが返ってきていました。（汗） これは、ディスクなしのときも、ディスクのSEEKなどが出来ていたからのようです。（オイオイ
PC-6601SR の場合は、ディスク初期化のときに リキャリブレートという処理をPD765に行います。 0番シリンダーに移動したなら、ディスクありと認識しているので、ディスクなしなら、0番に移動しないようにしました。
最近は、Windows と Unixの両方対応しないといけないので大変ですね。(^^; Windowsでいじって コンパイルが上手くいっていても、Unixでコンパイル出来るとは 限らないので、Unix環境 へソースをコピーして、改行コードを変換して、コンパイルして、バグをつぶして、パッチを作り、最終的に、Windows環境でも パッチ＆コンパイル出来るか確認して・・。という 非常にまどろっこしいことをやっています。(^^;;
そこまでやるのは、やっぱり Unix版を捨てられないからです。 Windows版が、まだまだだからというのも有りますが。(汗）
これからも、両対応で進めます。(^^;
Windows 環境で、PSG音源を鳴らしたくて、Sound.c をいじっていました。 Sound.c を WinSound.c にコピーして、単体のテストプログラムを作ります。 まぁ、初めはPCMファイルを作るだけなので、それ自体に鳴る機能があるわけでもなく、エミュレータで 鳴るわけでもないのですが・・。（汗）
鳴らした音は、A (440k)の音です。 (Windows の wav ファイルです。)
ちなみに、Unix版の Sound.c を解析してみると、初期化のとき、Unix独特のシステムコールである、forkで子プロセスを作っています。子プロセスにデータを送ると、子プロセスが無限ループ内で波形を作って、オーディオデバイスに出力してくれます。
しかし、Windowsには、forkも、killも pauseもない！ということで、普通に考えれば、マルチスレッドという話になるんですが、マルチスレッドって作ったことがないので、上手くいくか不安です。（汗） その上、作られた波形データを、途切れないように順次 オーディオデバイスに出力しなければなりません。
うーん。やっぱりこの辺は かなりかかりそうな予感ですねぇ・・。(^^; って、本当に出来るんだろうか・・・・。(汗)
マルチスレッドといえば、M88は Z80 CPUを 違うスレッドで動かしているみたいですね。やっぱりその辺も、考えないといけないのかなぁ・・(^^;; ちなみに、今のところ Windows版は、シングルスレッドで作られています。(汗)