改良日誌

改良日誌

2004/02/25
Kamadaさんのご指摘でnegxのZフラグ変化のバグが判明した。この命令のＺフラグ変化は手持ちのマニュアル（ＴＨＥ福袋Ｖ2.0に付属のアセンブラマニュアル）にも「演算結果が0なら1、さもなければ0」などと書いてあるし見落とし易い個所である。WinX68030のMPUコアでもnegxのC・Xフラグ変化にバグがあるので（Ｚフラグ変化は問題ない）修正しておいた方が良さそうだ。
2004/02/23
高速版を久しぶりに更新した。その間にKamadaさんのX68000 Emulator in Javaが発表された。実は高速版でもＪａｖａ版を考えていただけに先を越されたようだ。
2003/09/19
画面の部分書き換え処理を改良し無駄な書き換えをより少なくした。さらにFlip・Overlay Flip時にも部分書き換えを行なうようにした。これでSX-WINDOWでマウスカーソルを動かした時やふしぎの海のナディアのオープニング、悪魔城ドラキュラのSOUNDモードなどで劇的にCPU使用率が下がった。
2003/09/13
XakでMPUクロック21MHｚ以上の時のグラフィック高速クリアにまつわる不具合を修正すると、今度はナイアスでMPUクロック15MHz以下の時にグラフィック画面にゴミが残るようになってしまった。そこでクリア用ビットの設定が有効になるタイミングを色々変えてみると、画面にゴミが残らない条件がXakとナイアスで全く逆であることが判明して行き詰まってしまった。クリア用ビットをセットするタイミングを計るのにXakではMFPのGPIP4を使用しているのに対し、ナイアスでは
$00723c: bset #1,($481,A0)
$007242: beq $723c
としていたので、クリアが2垂直期間連続で行なわれる可能性が高いと考え2垂直期間連続でクリア可能なように修正すると画面にゴミが残らなくなった。v0.83までのように、クリアをラスター毎ではなく一括で行なっていた時にXak・ナイアス両方で不具合が出なかったのは、一括クリアのタイミングが偶然マッチしただけのことだろう。
2003/09/07
FM音源部分をfmgenに変更した。fmgenの最新バージョンでは不具合が生じるので006を組み込んだ。組み込むのは簡単だが、以前のFM音源エンジンとの互換性（状態セーブ・ロード関連）を保つのに苦労した。
2003/08/17
悪魔城ドラキュラでADPCMの一部のパートが強調されてしまう原因を調べた。DirectSound,ADPCM,DMACといろいろな部分を調べていく内にどうすれば不具合が発生しなくなるかは判明したが、修正方法はいくつもありどれもいまいち整合性がなかった。結局最後にADPCMの再生動作を忠実に再現していないことが原因であることが判った。例えば、現在X68000のエミュレータで次のような再生動作を再現できるものはない。
デバッガ（db.x）を起動して、
SR <-- $2000　（スーパーバイザーモードに移行、高速版では必要なし）
$E9A005 <-- $08　（ADPCMパン左右ON）
$E92001 <-- $02　（ADPCM再生開始）
$E92003 <-- $1F　（ADPCMにデータ送信）
とデータを書き込めば実機ではピーという音が発生する。
今回の修正でこのピーと言う音も再現できるようになった。ただ、忠実に再現するとどうしてもノイズが乗る場合があるので（悪魔城ドラキュラのBloody Tearなど）、再現性を多少犠牲にして音質を改善するモードも用意した方が良さそうだ。
2003/08/01
熱血高校ドッジボール部サッカー編でボールの軌道や動きがおかしい原因を調べた。ボールがラインを割っていないのにいきなりサイドアウトになったり逆サイドからのスローイングになったりする症状から最初neg命令のバグかと思い調べてみたが特に問題なかった。この症状は高速版だけでなくWinX68030やEX68でも起こるのでMPUコアのバグか割り込みのタイミングによるものと推測できたが、MPUコアのバグが原因である場合３つの異なるMPUコアで似た症状が起こる事から考えて余程ミスを犯しやすい部分があるのだろう。そこで以前実験的に作ってみたMusashiコアバージョンのWinX68030で動かしてみると問題なく動いたので原因は完全にMPUコアのバグであることが判ったのだが、MPUデバッグ機能を使ってトレースしてもどの命令にバグがあるのか全く判らなかった。高速版で使用しているMPUコアのバグはほぼ取れているのでもしバグがあるとすればかなり使用頻度の低い命令ではないかと考え、命令表を見ながらabcd,movep,roxlと熱血高校ドッジボール部サッカー編で使用されている命令を順番に調べていくとnegxでこの命令をx86命令のnegとsbbに分けて計算している個所を見つけた。計算結果自体は問題ないが、これではキャリーフラグの変化がおかしくなるので1回の演算で済むように修正した。それにしてもこのバグを見つけるのに非常に苦労した。キャリーフラグ変化のバグなんてトレースしてもまず気づかないだろう。
2003/07/27
キャメルトライでマウスが効かなくなっているということなのでSCCチャンネルBの動作を修正した。と言っても元々SCC周りは簡易実装なので少し処理を変更・追加しただけだ。これでおそらくキャメルトライでの不具合も直るだろう。今回はSCCのデータシートがザイログのホームページから入手可能だったので動作の詳細を把握することが出来た。やはりデータシートは原文をそのまま読むのが一番良い。日本語訳されたものでは、意味が違ってきたり意味がはっきりしない場合があるからだ。
2003/07/26
32ビットカラーモードでの表示に対応した。さすがにSavage/IXだと、16ビットから32ビットに変換する処理よりもテクスチャの拡大処理やビデオメモリからビデオメモリへのブリットに処理時間を食われてかなり遅くなってしまうが、最近のビデオチップならコアクロックもかなり高いのでそれ程遅くはならないだろう。
2003/07/25
v0.85をリリースした。今回の修正で、普段動作確認に使用しているゲーム・アプリで不具合の出るものは遂になくなった。実機と動作が異なる部分は探せばいくらでもあるが、通常の使用時にはほぼ問題ないレベルまで来たようだ。
2003/07/22
Moon Fighterをけろぴー最終版で動かしてみると動いた。DMAC周りを変更したのだなと思いソースを見ると、割り込み優先順位はループするようになっていた。つまり、例えばチャンネル２の割り込みベクタをMPUに渡したとすると次はチャンネル３・０・１・２という順番で割り込みチェックする方式だ。Moon Fighterが動く条件は、「DMACの複数チャンネルから割り込み要求がある場合にチャンネル３の割り込みが連続して発生しない」なので、高速版の方式でもけろぴー最終版の方式でも動くのだが、この辺りのことはHD63450のデータシートを手に入れない限りわからない。
2003/07/21
Moon Fighterが途中で止まってしまう原因を調べていて、DMACの複数チャンネルから割り込み要求があった場合の不具合を発見した。割り込み要求が重なった場合、どういう順番で割り込みベクタをMPUに渡すか不明だったので、CPRに設定されている優先順位に従うバージョンや割り込み発生の時間順序に従うバージョンなどを作ってみたがいずれも動かなかった。よく考えてみるとMFPですら各デバイスの割り込み優先順位は変更できないので、DMACも単純に優先順位固定ではと思い、チャンネル０・１・２・３順にするとあっさり動いた。
2003/07/18
前々から修正したいと思っていたTWIN COPYでの不具合の原因をMPUデバッグ機能を使用して調べてみた。トレースしてみるとどうも直前に読み書きしたディスクのシリンダ番号が一致しないために先に進めなくなっているのが判り、その原因を調べていてSENSE INTERRUPT STATUSコマンドの不具合を発見した。けろぴーのソースを見ると、このコマンドの動作が実際と異なるのは解っているが修正すると動かなくなるので、動くように辻褄合わせしたようだ。SENSE INTERRUPT STATUSコマンドのようにかなり頻繁に使用されるコマンドに不具合あるとは思わなかったが、多くのゲームなどではプロテクトチェック以外でFDCを直接操作することは少ないので不具合が表面化しにくかったようだ。
2003/07/13
v0.84からスキャンライン表示時に偶数・奇数ラインどちらに描画するか選択できるようにした。このオプションはWide Stretch時にスキャンライン表示で縦を1.5倍するような場合のためにある。縦を1.5倍する時、BackBuffer設定やビデオカードの種類によって、偶数ラインを2倍に拡大して奇数ラインをそのままにする場合と、逆に奇数ラインを２倍に拡大して偶数ラインをそのままにする場合があるようなので、このオプションがないと描画しないラインの方が2倍になってしまい非常に暗い画面になってしまう場合がある。デスクトップの解像度が1024x768の時に、このオプションを適切に設定してWide Stretchでスキャンライン表示させると、描画されているラインの方が2倍に拡大されるので今までのようにスキャンライン時に画面が暗くなることはなくなり、実機の表示により近づく。
2003/07/10
グラフィック高速クリアとテキストのラスタ・コピーが同時に実行されるのかどうか確かめるために、実機でテスト用プログラムを動かしてみた。同時に実行可能だった。さらに詳しく調べてみると、けろぴーではグラフィック高速クリアの対象プレーンは$E80481のビット１に１を書き込んだ時点の$E8002Bの設定が有効としているが、実際にはラスタごとのクリア直前の$E8002Bの設定が使用されることが判明したので、結局高速版ではラスタごとにクリアするように処理を変更する必要があった。
2003/06/30
今回のバージョンからMPUデバッグ機能を搭載した。トレース・ステップ実行、ブレークポイント設定、メモリダンプ、逆アセンブルなど一通りの機能は搭載しているが、メモリダンプ・逆アセンブルウィンドウでスクロールボタンを押しても現在表示可能な範囲の前後部分の表示が出来ないなど使いにくい部分が多々あるので改良する予定だ。それから周辺デバイスの情報も表示できるようにするつもりだ。
2003/06/22
画面表示周りの修正が終わった。ビデオコントローラレジスタR2($E82600)の下位4ビットに特殊な値を設定した時の256色・65536色モードの通常色・透明色の扱いを修正したのだが、すべての色について確認した訳ではないのでまだ実機とは異なる部分もあるかもしれない。この辺りのことは忘れないうちにドキュメントに残して置いた方が良さそうだ。
2003/02/08
随分前に立花さんから不具合報告のあったBFINS命令の修正を行なった。MPUコアのビットフィールド命令部分はマクロを多用していて非常にバグを見つけ難くなっているので苦労した。このコアはかなり無駄も多いので高速化したくなるのだが非常に書き換え難い構造になっているので、やはり別のコアに変更した方が良さそうだ。
2003/02/06
他のSCSIドライバとしてHSCSIを組み込んでみると無限ループに陥ってしまった。調べてみると先日の応急処置部分と不具合の原因が同じだったので、応急処置ではなく正確にエミュレーションするように書き直した。これで問題なくなった。今のところディスク領域が破壊されることもなく動いているが、実装しているSCSIの機能は必要最低限のものだけなので特殊な機能には対応できない。
2003/02/03
SCSIを実装してみた。XVICompact以前の機種ではSCSI-ROM部分は無償公開されていないので、WinX68030でSCSIのテストを行なった。SCSIのトレース結果を見ると一応問題なく動いているのになぜかエラーが出て起動できない。けろぴーでは即席の外付けSCSI-ROMを置いていたのを思い出してこれを置かないようにするとあっさり起動した。読み込みに関しては問題なくできた。そこで起動時の領域選択（HELPキーを押しながら起動）が動くか試してみると選択画面は出るが起動が出来ない。原因を調べてみると書き込みが出来ないで止まっていたのでとりあえず応急処置を施して書き込み出来るようにした。これで標準SCSIドライバとSUSIEでは問題なく読み書き出来るようになった。ただ応急処置なので他のSCSIドライバでは問題があるかもしれない。
2003/01/29
バスエラー処理部分のバグを修正したついでに、バスエラー・アドレスエラー時のスタックフレームに積まれるデータの中で今までスタックに書き込まれていなかった現行サイクルのアドレスや命令レジスタなどを書き込むようにした。v0.76でまだ書き込まれていないデータは詳細のわからないアクセスタイプとファンクションコードだ。これでMPU周りの改良もほぼ完了した。現在問題があるのは、メインメモリ・GVRAM・TVRAM・ROMなど異なる領域の境界線を跨いで（あるいは相対ジャンプで飛ぶ）プログラムが実行される場合だ。こういうことは通常はないがプログラム暴走時などには十分可能性がある。この場合、ページ違反で高速版自体が落ちてしまう。対策を施すにはソースのかなりの個所を書き換える必要があり、処理速度もがた落ちしてしまう。
2003/01/27
最後の細かい調整を行いv0.75をリリースした。今回のバージョンの目玉は半透明処理の再現性の飛躍的な向上だ。例としてはファランクス（無償配布中）の2面の水中の半透明処理をv0.68以前と比べると違いがわかるはずだ。今回で画面表示周りの改良は一応完了した。かなり特殊な設定にも対応できるようになり、いつも動作確認に使用しているゲームやアプリなどで表示に問題のあるものは1つを除きもうない。（その1つは微妙なタイミングのズレで表示がおかしくなるだけでタイミングの取り方に問題がある）　実機と違うところですぐに思い付くのは、1ライン上にスプライト表示32個までの制限（高速版では128個まで表示可能）とパレット指定による半透明・特殊プライオリティに未対応の２点ぐらいだ。
2003/01/26
トレース機能の実装とアドレスエラーに対応したことで1.1GHｚ（最新バージョンでは1.3GHz）出ていたもので600MHｚ台しか出なくなっていたので、高速化できないものかと思ってソースを書き換えて1.1GHzちょっとまで上げることが出来た。ただし、ここまで速度が出るのは処理時間のほとんどが時間待ちループ内のわずか数命令の実行に費やされているからだと思う。
2003/01/25
今まで高速版では768x512までしか（Flip時は800x600まで）表示できなかったが、横1536ドット・縦1024ラインまで表示可能にした。これでSX-WINDOWを1024x848で起動して使用することも可能になった。ただし、ウィンドウモード時は現在のWindowsのデスクトップの解像度までしか表示は出来ない。すべての領域を表示できない場合（例えばデスクトップの解像度が1024x768でX68000の画面モードが1280ｘ1024の場合）は左上の領域を表示する。フルスクリーンモード時はX68000の画面が入りきるDirectDrawフルスクリーンモードを探し、ない場合は存在する最大のフルスクリーンモードを使用して左上の領域を表示する。
2003/01/19
スプライト・BG画面の描画方法を少し変更した。速度的に限界だと思っていた電波Ysで10％以上高速化された。さらに速そうな描画ルーチンを思い付いたので試してみたくなったが、描画部分をすべて最初から書き直す必要があるのでとりあえず止めて置くことにする。
2003/01/16
けろぴーでは半透明時のRGBの演算をR,G,Bまとめて行なえるようにR,G,Bの最下位ビット（場合によっては下から2番目のビット）を０にした上で加算を行なう。しかしこの方法だと半透明処理を行なう２つの色コードの最下位ビットが共に１だった場合に演算結果が違ってしまう。通常はR,G,Bの最下位ビットが多少違っても表示される色の区別はつかないと思われるので問題ないが、例えばグラフィック画面同士の半透明で２つの色コードが00000_00000_00001_0と00000_00000_00001_0（G_R_B_I）だった場合、実機では半透明処理後0000_00000_00001_0となるが、けろぴーでは00000_00000_00000_0となってしまいグラフィックの後ろにテキストやスプライトが存在する場合透明色になってしまう。そこで演算を正確に行なうように変更した。当然処理が重くなるが思った程ではなかった。
2003/01/15
描画部分を完全に新描画ルーチンに移行した。これでwindraw.cはかなりすっきりした。半透明時の再現性・速度がかなり上がったが、さすがにPenIII600MHzではあらゆる場面で55fpsをキープすることは無理だった。「解像度512ｘ512＋テキスト・スプライト・BG・グラフィック画面すべて表示＋テキスト・スプライト・BGとグラフィックページ０とページ１の半透明を画面のすべての点で行なう」という最高に重い状況では40fpsを切ってしまうようだ。
2002/12/31
前々から変更したいと思っていたラスターコピーの動作タイミングを変更した。今までは一度の水平同期期間中に何度でもラスターコピーが可能だったが、実機と同じようにラスターコピーを指示した次の水平同期期間中に一度だけ動作するようにした。これでサンダーブレードで黒い横線が入るバグが修正された。しかしED.Rで画面が崩れるようになったので原因を調べていて、MFPのGPIPの最上位ビット（H-SYNC)の変化タイミングにバグがあることに気づいた。
2002/12/27
領域指定のない半透明・特殊プライオリティについて実機で調べてみた。Kamadaさんの日記で紹介されていたソースを実行すると半透明処理されたが、こちらで用意したものではなぜか同様の設定をしたにも関わらず半透明処理されなかったのでいろいろ設定を変えてみた。最初65536色モードを使用していたのだが、こちらで用意したものではグラフィックパレットを書き換えていた（通常65536色モードではグラフィックパレットは書き換えないことが多い）のでパレットの色コードを変えると半透明処理された。そこでパレットに様々な色コードを設定して調べてみると、どうも$E82001の最下位ビット（Iビット）が１だとパレット０と１の点が半透明・特殊プライオリティ処理され、$E82005の最下位ビット（Iビット）が１だとパレット２と３の点が半透明・特殊プライオリティ処理され、・・・・・となるようだ。さらに256色2面時に特殊プライオリティを行なうと該当パレットが描画されているページ（ページ０かページ1か）に関係なく指定されたパレットはすべて手前に表示された。つまり「パレット指定による半透明・特殊プライオリティ」のようだ。
2002/12/21
65536色モードでのパレットの内部構造を変更した。これで 65536色モードでのパレットの扱いが少し楽になり高速化にも貢献する。
2002/12/15
ADPCM周りを多少変更してみた。音質はほとんど変わらないが、ADPCMの音量設定を最大にした時に音がブチブチ切れなくなった。ローパスフィルタも導入してみたが音質にほとんど影響がないので導入は見合わせることにした。
2002/12/08
MPUのトレース機能を実装した。高速版での動作を確認していてWinX68030のトレース機能のバグに気づいた。命令自体に例外処理が含まれているtrap,trapv,chkなどでトレース機能が働かないというものだ。原因は１つの命令実行で2回以上の例外処理が起こる事を考えていなかった為だ。ソース(68kem.asm)を見ていて、ジャンプ先のアドレスが奇数アドレスの場合のアドレスエラーに対応していないことに気づいたので、ついでに対応した。
2002/11/30
オーバーテイクでADPCMの音が出なくなっている原因を調べていて、v0.20での「DMAC動作不具合に対する応急措置」が原因であることが判った。この応急措置というのはADPCMの再生を停止したときにDMACのACTビットも落としてやるというもので、これでネメシス’９０改やスーパーストIIなどが途中で止まらなくなり一応他のゲームでも問題なさそうだったのだが、オーバーテイクで不具合が出ていた。そこでもう一度DMACの動作を色々修正していて、結局転送タイミングを少し変更すれば問題なくなることを突き止めた。
2002/11/24
ぶたさんで不具合のあるBG画面の透明色の扱いを変更した。この変更により、けろぴーでテキストとBG画面のプライオリティによってBG画面の透明色の扱いが異なっていたのが統一された。この変更が正しいのかどうかはわからないが、プライオリティに関わらず統一した方が整合性は良い。
2002/11/23
MPUのクロックを1MHｚ刻みで自由に設定できるようにした。PenIII600MHｚでも軽いゲームだと最高で1.1GHｚ出たりするが、処理時間のほとんどは時間待ちのループだと思われるしゲームで１GHｚ出ても全く意味はない。
2002/11/10
垂直帰線割り込みのタイミングを変更した。垂直帰線割り込みは通常ここだと思われるタイミングで発生させるとクレイジークライマーやアルゴスの戦士など電波のゲームで止まってしまうので、けろぴーではタイミングを多少ずらしている。しかしこのタイミングだとニュージーランドストーリーでスプライトがちらつく場合があるので、両方のゲームで不具合が出ないように通常のタイミングから１ラスター分ずらして垂直帰線割り込みを発生させるようにした。これで一応問題はなくなる。
2002/11/09
「半角/全角」キーでキーを離したと言う情報が正確なタイミングで得られないという問題があったが、「ひらがな」と「英数」キーにも同様の問題があることが判明した。これらのキーではキーを押したと言う情報をX68000に送った直後にキーを離したと言う情報も送ってやればLHESなどでは問題なくなるのだが、こうすると逆にキーチェックの間隔が長いものやキー押しっぱなしが必要なときに問題になるので、用途に応じてキーを離したと言う情報を直後に送るかどうかをキーごとに設定できるようにした方が良さそうだ。
2002/11/01
HELLHOUNDでADPCMの基本クロック設定がおかしくなる原因を調べていて、ADPCMステータスレジスタの動作不具合を見つけた。ADPCM再生中はADPCMステータスレジスタの最上位ビットが0になるはずだが1になっていた。こんな単純なバグがまだ残っているとは思わなかった。けろぴーで以前から問題になっていたADPCMが再生されないバグはこれが原因かもしれない。今までデバッグにはEX68を使用していたが、今回デバッグにXM6を使用した。EX68はコマンドラインしか使えないが、XM6では複数のウィンドウを開ける上、エミュレーションも正確なので非常に使い易い。
2002/10/31
768×512 16色モードで画面の横スクロール時に表示にバグがあるという報告があったので調べてみる。動作確認する適当なゲームを持っていないので、琥珀色の遺言でグラフィック画面を強制的に横スクロールさせてみると確かに表示がおかしい。バグの原因が判ったので修正した。
2002/10/29
最近、高速版リリース直後にバグを見つけることが多いので、今回はリリース前に入念な動作確認を行なった。普段動作確認用に動かしているゲームについては問題ないようだ。
2002/10/20
異なるバージョン間で状態セーブ・ロードしたときの致命的なバグを修正した。v0.70以降ではv0.68以前で状態セーブしたx68ファイルを読み込むことはできなくなる。
2002/09/26
グラフィック画面16色1面モードの表示不具合のバグがやっと取れた。バグがありそうな個所を何度見直してもバグは見つからないので困っていたが、結局まったく別の個所にバグがあった。
2002/09/01
グラフィック画面とテキスト画面のワークエリアの構造を2度ほど変更した。これで少し高速化されたようだ（画面モードによってはかなり高速化）。さらに面倒な処理が必要なくなりコーディングし易くなった。電波Ysの高速化は遂に限界に達したようだ。
2002/08/30
MMX2で新設された命令の中には高速版で有効そうな命令（maskmovq,movntq,pextrw,pmovmskb）があったので試しに使用してみたが、僅かに高速化されただけだった。
2002/08/25
コントラスト変更を実機のように段階的に変化していくようにした。これで実機っぽくなった。
2002/08/24
ぶたさんに画面不具合があるということなので調べてみた。どうもBG画面の透明色の扱いに問題があるようだ。透明色の扱いについてはもう大丈夫と思っていたのだが・・・。ぶたさんで画面不具合が出ないように修正すると悪魔城ドラキュラで画面不具合が出るので困った。BG画面の透明色の扱いについて一度実機で詳しく調べる必要がありそうだ。
2002/08/20
旧描画ルーチンで半透明・特殊プライオリティ時のバグを見つけたので修正した。今日Kamadaさんのページの数ヶ月前の日記で領域指定のない半透明というのを見つけたが、領域指定のない半透明があるということは領域指定のない特殊プライオリティもある可能性が高いと思うのだがどうだろうか。
2002/08/16
グラフィック・テキスト・スプライト画面間のプライオリティについては、設定値が禁止されている値の場合、けろぴーのソース中の記述が正しいものと思っていたがどうも違うようなので実機で調べてみた。やはり違っていた。グラフィックのプライオリティ設定値が最優先されるようだ。
2002/08/11
修正版をすぐにリリースしようと思っていたのだが、いきなりWindows2000が起動不能になってしまったのでWindows98で開発環境を再構築しなければならなくなった。起動不能の原因が１週間前に換装したHDDにあるのかWindows2000ServicePack3にあるのかわからないが、Windows2000をインストールしているドライブにソースファイルを置いていなくて助かった。
2002/08/10
v0.60をリリースしてすぐに、悪魔城ドラキュラを状態ロード後に高速版を終了させるとエラーが出ることに気づいた（Windows2000のみ）。状態セーブ・ロード機能に関係した不具合は他にもあるはずだ。
2002/08/08
スプライトスクロールレジスタ、PCGエリア、BGデータエリアのバイトアクセス時の動作を修正したのでHELLHOUNDを動かしてみた。スプライトが画面に残るバグは修正されているが、エラー（$1D5)・エンディングの最後の画面のテキスト表示の不具合・ゲームの2週目以降で一部のスプライトが白い四角になってしまう不具合は直っていなかった。エラー（$1D5)はIOCSコール$D5を呼び出しているのだが、X68030より前のROMではこのコールはサポートされていない為にエラーが出るようで、X68030からサポートされた（？）のでWinX68030ではこのエラーは出なく、残りの２つの不具合もWinX68030では出なかった。どうもこのゲームはX68030のROMに依存するようだ。（後日HIOCS.Xの組み込みが前提であることに気づく）
2002/08/07
状態セーブ・ロード機能で使用するファイルの拡張子を"x68"、ファイルヘッダの最初の３バイトを"X68"にする。他のファイルに同じような仕様のものがあるかどうかはわからないがこれで良いだろう。それから、セーブするメインメモリの大きさをどうしようか考えたが常に12MBにするとファイルが大きくなるので、SRAMの内容と同じ大きさだけセーブするようにする。よって、SWITCH.Xでメインメモリの大きさを変更した後、リセットする前はSRAMの内容と実際のメインメモリの大きさが一致しなくなるので注意が必要だ。（特にメインメモリを減らした場合）
2002/08/03
状態セーブ・ロード機能を高速版に搭載してみた。機能自体は単純であるが、セーブ・ロードすべき変数の多くが構造体になっていない為に変数を１つ１つ扱わなければならなく非常に面倒だった。一応問題なくセーブ・ロードできているようだが、特殊な状況での動作は保証できない。
2002/05/05
特殊プライオリティ時のバグに気づいたので新描画ルーチンを修正した。旧描画ルーチンやけろぴーにも特殊プライオリティ時のバグがあるのだがとりあえずそのままにしておく。
2002/04/19
VIEWPOINTでコンティニューができないということなので調べてみると、ロボットコンストラクションと同じでDMACのエラー処理の未実装が原因であることがわかった。それにしても、動作確認するのに時間がかかった。VIEWPOINTでコンティニューができるかどうか確かめるためには最低１面はクリアーしないといけないのだが、１面のボスでやられたりするとまた最初からなのでわざと重い設定にして速度を落として（7〜8MHｚ程度）クリアーした。動作確認のために「どこでもセーブ機能」のようなものの必要性を感じた。
2002/04/18
グラフィックが256色X2面で2面共表示ONの場合と16色X4面の一部の場合（ただし共に半透明なし）を新描画ルーチンに置き換えた。グラディウス・ゼビウス・コットンなどもそこそこ高速化されているようだ。特に、特殊プライオリティを使用していて重かったコットンがだいぶ軽くなっている。
2002/04/13
グラフィックが256色X2面で2面共表示ONの場合（ただし半透明なし）をすべて新描画ルーチンに置き換えるために数ヶ月前に書いた新描画ルーチンのソースを見たが、自分で書いたにも関わらず忘れている個所があり思い出すのに時間がかかった。
2002/04/07
ロボットコンストラクションを動くようにしてほしいという要望があったので、数ヶ月ぶりに高速版のソースをいじった。タイトル画面で止まってしまうので調べてみるとDMACの処理待ちの部分で無限ループに陥っているようだ。デバッグしてみるとどうもチェインなしモードでMTC=0としてDMACの動作開始を行なう部分があり、その直後のDMAC処理がACTビットがセットされているために動作タイミングエラーになって動作開始できないことがわかったので、カウントエラー処理を追加してACTビットをリセットするようにした。
2002/01/09
WinX68030のメモリアクセスを少しでも高速化しようとして書き換えた部分にメインメモリの奇数アドレスからのワード・ロングアクセスのバグがあった。しかし、CPUコアが余りにも重いため高速化の効果はあまりない。メモリアクセスのバグ以外に大きな不具合報告が今のところないということは、とりあえず他に致命的なバグはないということだろうか。WinFelloｗのCPUコアにはバグがいくつかあったのでWinX68030に採用する際に修正したのだが、他にもバグがあるかも知れない。（特に68020以降の新設命令で）
2002/01/06
WinX68030をリリースした。もっと早く11月中にリリースしておくべきだった。動作周波数は68000の各命令のクロック数を5/8倍して算出しているだけなのであまり当てにはならないが、Duel Fighter2起動時に実行されるベンチマークでは実機（25MHz、キャッシュオン）で3068、WinX68030（25MHｚ）で3086とかなり近い値を出している。
2001/12/31
最近どうもモチベーションが下がってきている。新描画ルーチンを使用していないときはかなり遅いので、描画部分をすべて新描画ルーチンに置き換える必要があるのだが。とりあえず細かい修正を行なってv0.45をリリースすることにした。
2001/11/29
v0.41をすぐにリリースしたが、v0.40でBackBuffer切り替えに失敗して起動できなくなった場合でも起動できるように、起動時BackBuffer設定がSystem以外でDirectXの初期化に失敗した場合にBackBuffer設定をSystemにしてもう一度DirectXの初期化を試みるようにしておくべきだった。それにしても掲示板の書き込みを見る限り、Overlay Flipに切り替えられない環境の人が予想外に多いようだ。よほど昔のビデオカードでない限りOverlay Flipをサポートしていると思ったのだが。あるいはビデオメモリが足りないのだろうか。Savage/IXはOverlay Surfaceを作るのになぜか大量のビデオメモリを消費するようだし。
2001/11/27
BackBuffer設定にOverlay Flipを追加したので、最終的な細かい調整を行なってv0.40をリリースした。Overlay Flipについてはv0.10の頃から採用を考えていたが、当時はオーバーレイの扱いにあまり慣れていなかったので採用を見送っていた。こちらの環境では、スクロールタイプのゲームのように毎フレーム全画面書き換えを行なわないといけないようなものの場合、Windows2000ではBackBuffer設定をOverlay Flipにした時が最速である（Flipを除く。Overlay FlipとFlipはほぼ同じ速度のはず）。ただし、オーバーレイは動画を表示するときに使われるため、多くのビデオカードでは拡大表示したときに強制的にフィルタがかかってしまうはず。
2001/11/13
最近ずっとWinX68030にかかりっきりだったが、WinX68030のCPUコアがあまりにも遅いのでメモリアクセス部のルーチンを高速化し、WinX68k高速版にも組み込んだ。全体としてはそれ程高速化されていないが、メモリアクセス部だけでみれば結構高速化されているようだ。
2001/10/31
新描画ルーチンを次のバージョン用に組み込んで動作確認を行なった。スーパーハングオンのレース中の画面がおかしい。画面上部が黒くなっていて（EX68や昔のけろぴーと同じ症状）、BG画面表示にバグがあるようだ。原因がわかった。数日前に高速化したBG画面描画ルーチンの透明色の扱いの部分にバグがあったので、すぐに修正した。
2001/10/29
新描画ルーチン使用時、電波Ysで遂に10MHｚを達成した（一番重い所では一瞬9.8MHｚまで落ちるが）。平均でも10〜12MHｚ台出ている。
2001/10/21
オートフレームスキップの精度を向上させた。これで充分実用に耐え得るようになったはずだ。
2001/10/20
15kHzモードの256ライン時にラスター抜き表示（Auto Stretch,Auto w/X68 SizeおよびFlip時のみ）を行なうようにした。ついでに、大魔界村やスーパーストIIのCRT MODE ２でBG・スプライト画面が縦長に表示されるバグを修正した。
2001/10/17
けんじょさんからデバッグコンパイル時に必要なファイルをいただいたので、早速エアーマネージメントのマウス不具合を調べ直した。原因がわかった。タイマCの不具合だった。この不具合によってタイマ割り込みが入らなくなっていたようだ。他のタイマA・B・Dにも同様の不具合がある。
2001/10/15
パロディウスを動かしているときに、グラフィック画面の左右の継ぎ目が正しく表示されないバグ（WinX68k高速版固有のバグ、当然けろぴーにはこのバグはない）を見つけた。このバグは以前修正したはずだったが、１箇所だけ修正できていないところがあった。
2001/10/10
現在の描画部分の骨格は基本的にけろぴーとまったく同じであるが、高速化も限界に近づいてきたので、グラフィックが256色X2面でプライオリティが　テキスト > スプライト > グラフィック　そして特殊プライオリティなしの場合について新しい描画ルーチンを実験的に作ってみた。PenIII600MHｚのノートで電波Ysは、v0.22では最低4.5MHｚ最高6.4MHｚ程度であるが、新しい描画ルーチンでは最低7.8MHｚ最高9.5MHｚ程度まで高速化された。しかし、新しい描画ルーチンをWinX68k高速版に組み込むには描画部分をほとんどすべて書き換える必要がある。
2001/10/06
一部のゲームで半透明処理時に遅くなる（特にwindows95/98/Meで、また、Flip時には極端に遅くなる）のを高速化した。Genocide2の最初のデモの中の横スクロールしながら主人公がヘルメットをかぶる所は512X512で半透明処理を行ない非常に重いが、Windows98で平均3.7MHz（ｖ0.22）から平均5.6MHzに高速化した。Flip時にも遅くならなくなった。他にも描画部分を少し高速化した。現在のバージョン（ｖ0.30 近日リリース予定）の高速化もそろそろ限界のようだ。高速化出来たとしてもあと１０％くらいか。
2001/10/03
エアーマネージメントのマウス不具合について調べた。不具合はゲーム開始時だけで一旦ゲームを始めると問題ないようだ。不具合の原因がつかめない。やはり、Traceが使えないときつい。けろぴーのソースはデバッグオプションを付けてコンパイルするとTraceできるようだが、ダウンロードできるソースにはデバッグコンパイル時に必要なd68k.hが含まれていないのでコンパイルできない。けんじょさんにけろぴーの不具合報告のメールを送った時にd68k.hを提供願えないか頼んだが、お仕事の方がお忙しいようでまだお返事がもらえない。d68k.hが手に入るまでエアーマネージメントのマウス不具合修正は保留することにした。
2001/09/25

Clockwise氏からの強い要望によりBackBufferにFlipを追加する。Flip自体の実装はすぐに済んだが、細かい調整に手間取った。
2001/09/13

とりあえずｖ0.10をリリースした。本当はもう少し高速化してからリリースするつもりだったが、けんじょさんのページの掲示板で悪魔城ドラキュラが快適に動作する環境を手に入れるためにPCの買い換えをするつもりという人がいたのでリリースを早めた。けろぴーを最初に高速化しようと考えたのは1ヶ月くらい前だったが、最初は正直ここまで速くなるとは思わなかった。BackBufferをNonlocalVideoMemoryにとること自体は1年ほど前から行なっていてこれだけでもかなり速くなった。
counter