2006年10月29日

フロッピーアクセス速度 3

再びフロッピーアクセス速度に注目

シリンダをまたがって読み込む場合、ディスク1回転分の待ちが発生している模様。ヘッドが最終セクタを読み終わってから、先頭セクタに到達するまでの間に、シリンダの移動(に関するコマンド発行やそのプログラム実行など含めて)が完了せずに、再び先頭セクタがやって来るのを待っているものと思われる。
posted by Shinra at 23:17| Comment(0) | TrackBack(0) | EMU | このブログの読者になる | 更新情報をチェックする

2006年10月24日

音源9

サウンドポートアクセスのウェイト機能

ポート19Ch/19Eh (ウェイト有無の指定)含めてとりあえず実装。
posted by Shinra at 23:42| Comment(0) | TrackBack(0) | EMU | このブログの読者になる | 更新情報をチェックする

2006年10月23日

音源8

サウンドポートアクセスのウェイト機能

http://www.pc88.gr.jp/inside88va/wiki/index.php?%A5%B5%A5%A6%A5%F3%A5%C9%B5%A1%C7%BD#ee47c0de

実機でウェイト時間を測定

>OUT 0044H/0046H ライト後 4.25μs以内

というのは、ライト後4.25μs以内にサウンドポートにアクセスしようとすると、ライト後4.25μs経つまで待たされる、ということらしい。

> OUT 0045H/0047H ライト後 20.75μs以内

こっちも同様。

今のVA-EGの実装は45H,47Hにライトすると無条件に20μsのウェイトを入れているし、44H,46Hのほうは全くウェイトを入れていないので、正しくない。

posted by Shinra at 20:48| Comment(0) | TrackBack(0) | EMU | このブログの読者になる | 更新情報をチェックする

2006年10月22日

r061022公開

r061022を公開しました。

posted by Shinra at 16:18| Comment(0) | TrackBack(0) | EMU | このブログの読者になる | 更新情報をチェックする

2006年10月21日

マルチプレーンモード13 / ガゼルの塔 3

> 実機だと何かの操作がきっかけでf0hにリセットされるところが、VA-EGでは
> リセットされないままffhのままとなり異常な動作になっていると思われ
> る。

実機ではパターンレジスタを8bitにするとポート550hの値がf0hにリセットされる。

VA-EGでもそう実装していたつもりだったのだけれど、条件式の記述誤り。

誤 if (!dat & 0x04) {
正 if (!(dat & 0x04)) {

前者だと!dat して(結果は0or1)、それと0x04の & をとるので、常に結果が
偽となるようで。演算子の優先順序はいまだによく把握できない・・・


ガゼルの塔の画面は正常に。

gazzel4.PNG

gazzel5.PNG
posted by Shinra at 17:59| Comment(0) | TrackBack(0) | EMU | このブログの読者になる | 更新情報をチェックする

CPU 3

SHELL "a:"
PLAY "@0"
で動作異常の件。

BASICは無関係で、PC-Engineでa:とやっただけでもメモリ破壊が起きていることが判明。

ESが狂ってからstosbを実行するまでの間にRAM上にジャンプしているところがあるので、実機で、
mon pcengine.com /c a:
として、そのRAM上にブレークポイントを設定して、そこまで実行させて、そのあとt コマンドで可能な限りトレースしてみたところ、
やっぱりESが変な値(F086h)でstosbやっている。ただ、書き込み先がROMなためたまたま問題にはなっていないという状況。
ということで、根本的にはPC-Engineのバグだった。(;_;)

では、なぜ実機はES=Fxxx(ROM)で、VA-EGではES=00xx(RAM)なのか。

この値の出所を調べてみところ、intを実行したときにスタックにプッシュされるフラグレジスタの値であることがわかった。
V30だとフラグレジスタの値の上位4ビットは1なので、値はFxxxhになる。
VA-EGはPOPFでフラグを設定する場合は、フラグレジスタの上位4ビットを1にしていたが、IRET実行時とリセット時は286と共通の処理となっており、上位4ビットは0になっていた。

これらの処理をV30用に分けて、上位4ビットを1にするように修正。

問題の現象は解消。


よかった直せて・・・これは迷宮入りになるかと思った・・・
posted by Shinra at 17:49| Comment(0) | TrackBack(0) | EMU | このブログの読者になる | 更新情報をチェックする

BASIC 4

SHELL "a:"
PLAY "@0"
で動作異常の件。

Music/Sound BIOSのワークエリアが破壊されるのが直接の原因。
ワークエリアが破壊されるのはES=0016hでstosbを実行してしまう
処理があるから。ES=0016hになるのは、SPを書き換えて、すでに
開放済みのスタックからESをpopしているからで、ESにでたらめな
値が入るから。
PC-Engineのバグの可能性もないとは言い切れないけれど、
実機では現象がおきないし、バグだとしたらずいぶんお粗末というか。

ESに値を代入すべき命令でVA-EGのバグにより代入できていない、
という線を想定しているのだけれど、具体的にどういうバグがあり
うるのか全く推測できていない。

処理をおっかけては見たけれど、パッチコードへのジャンプとか
スタックの複雑な操作が多くて付いていけない(;_;)
posted by Shinra at 00:11| Comment(0) | TrackBack(0) | EMU | このブログの読者になる | 更新情報をチェックする

2006年10月17日

BASIC 3

不具合のご報告いただいたのでメモ。

BASIC起動後、
SHELL "a:" を実行
次に、play "@0" を実行

ハングするとのこと。

当方ではハングはしないものの、play "@0"では何も演奏されないはずなのに、"cccc" みたいな感じに音が出る。

posted by Shinra at 23:54| Comment(0) | TrackBack(0) | EMU | このブログの読者になる | 更新情報をチェックする

2006年10月16日

ROMの吸出しができなくてお困りの方へ

なんらかの事情でROMの吸出しができなくてお困りの方へ

VAの所有を証明していただくことを前提にROMデータをお送りする、
ということを始めたら、需要はありますでしょうか。

それなりに需要があれば検討してみますが・・・

ご意見があれば
 http://www.pc88.gr.jp/forum/viewtopic.php?t=203
へお願いします。
posted by Shinra at 22:29| Comment(0) | TrackBack(0) | EMU | このブログの読者になる | 更新情報をチェックする

2006年10月15日

マルチプレーンモード12 / ガゼルの塔 2

原因の予想。ガゼルの塔の問題は、
パターンレジスタを16bitにしていて
上位バイトから使うか下位バイトから使うかの設定の制御がうまくいっていないのではないか。


Debug UtilityにGVRAMアクセスの設定の情報を表示するための機能を追加して様子を見てみた。

debugutil.PNG

デモ経由でゲームを開始した場合(画面が変)と、DISK2で起動した場合(画面が正常)とで、ポート550hの値が違い、前者はffh、後者はf0h。
550hは、GVRAMリード時にパターンレジスタを更新する場合に上位バイトと下位バイトのどちらから更新するかを設定するところ。
予想通り。

実機だと何かの操作がきっかけでf0hにリセットされるところが、VA-EGではリセットされないままffhのままとなり異常な動作になっていると思われる。

posted by Shinra at 21:31| Comment(0) | TrackBack(0) | EMU | このブログの読者になる | 更新情報をチェックする

2006年10月14日

ガゼルの塔

DISK2はXDISK2VAでイメージ化できず。トラック154を読まずに途中終了。
make_hdで表示された情報によれば、トラック154はFMとMFMが混在していて、CRCエラーも発生する。

gazzel3.PNG

gazzel1.PNG

オープニングの途中からこんな感じ。
上位バイトと下位バイトが入れ替わっている。
問題ない画面もある。
なんだろう・・・
ソーサリアンでもこんな画面を見たような。

DISK2から起動した場合は問題なし。
これまた謎。

gazzel2.PNG

DISK3から起動したらこんな画面が。
今まで気づかなかった・・・
posted by Shinra at 00:29| Comment(0) | TrackBack(0) | EMU | このブログの読者になる | 更新情報をチェックする

2006年10月12日

脱線: ハレ晴レユカイ for 88VA

6年ぶりにVA専用ソフトを作りました。
内容はくだらないですが。

ハレ晴レユカイ for 88VA
http://www.pc88.gr.jp/forum/viewtopic.php?t=197

hare3.PNG

hare2.PNG



TVアニメーション「涼宮ハルヒの憂欝」のエンディングのアニメーションをPC-88VA上で再現します。上映時間1分7秒。

昔、ANIMAX, MASLといったパラパラアニメのソフトがありましたが、そのお化けみたいなものです。アニメーションの再生は独自のプログラムで実現しています。

現時点で公開しているVA-EGでは動作しません(10月4日と5日の記事を参照)。
posted by Shinra at 22:56| Comment(0) | TrackBack(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2006年10月08日

CPU 2

mon(デバッガ)で、t コマンドの挙動が変。
1. t=100 などとして実行開始アドレスを指定すると、その次でとまらずにとんでもないところで止まる。
2. t(パラメータなし)で実行すると、IPが進まない。

シングルステップ割り込みの実装がどこかおかしいのだろうと思って調べていたらそうだった。

2. → monのプログラムはIRETでシングルステップ割り込みのフラグを立てる。VA-EGのCPU実行のメインループは、命令を1ステップ実行して、フラグをチェックして、立ってたら割り込みの処理(CS,IPをスタックに入れた後に割り込みルーチンのアドレスにセット)する。このため、IRETしたら直ぐ割り込みが入るという状態で、結果としてIPが進まないという状態に。CPU実行のメインループの処理はnp2では#if で無効になっていた部分を有効にして使っていたので、きっとちゃんとメンテされていなかったのだと思う。(np2では問題ないはず。)

1. → np2/VA-EGでは割り込み許可フラグがoffだったらシングルステップ割り込みがかからないように実装されていた。たまたまmon起動直後のフラグが割り込み禁止状態だったため、割り込み許可されたところまでシングルステップ割り込みがかからず、変な挙動になっていた。実機では割り込み許可フラグの影響を受けない。自分が参照している文献では割り込み許可フラグによってシングルステップ割り込みを禁止できるようにも読めるのだが、実際はそうなってない。


実機でシングルステップ割り込みの挙動を調べたら、結構複雑。
まとめると、以下のとおり。

[基本]
・割り込み(外部、内部問わず)がかかると、シングルステップ割り込みフラグが降りる。(これは実機調査していないけれど、文献に書いてあるのを信じることにする。)
・シングルステップ割り込みフラグを変化させる命令は、POPF と IRET。(これも文献を信じることにする。)
・命令実行直前の時点でシングルステップ割り込みフラグが立っている場合、命令実行後に割り込みが発生する。(→当該命令でシングルステップ割り込みフラグを下ろしても、命令実行直前で立っていれば、割り込みが発生する。)
・シングルステップ割り込みは割り込み許可フラグの影響を受けない。


シングルステップ割り込みフラグをoff→onに変化させたとき、POPFで変化させたかIRETで変化させたかで挙動が違う。
・IRETでoffからonになった場合、その次の命令実行後に割り込みがかかる。(納得のいく挙動)
・POPFでoffからonになった場合、その次の命令実行後には割り込みがかからない。さらにその次の命令実行後に割り込みがかかる。(不自然な仕様。μPD9002でもV30でも同じ挙動。286だとIRETと同じ挙動になる。)

シングルステップ割り込みフラグをon→offに変化させたときの動作は、POPFとIRETで同じ。POPF/IRETの実行直後には割り込みがかかり、次の命令実行直後以降は割り込みがかからない。

では、次のようなプログラムだとどうなるか。
(1)
 ...
 ...
 POPF ;シングルステップ割り込みフラグをonにする。
 POPF ;シングルステップ割り込みフラグをoffにする。
(2)
 ...
 ...
 POPF ;シングルステップ割り込みフラグをonにする。
 IRET ;シングルステップ割り込みフラグをoffにする。

POPFでフラグをonにした場合は1命令遅れてフラグが有効になることから、シングルステップ割り込みは全く発生しないというのが予想だった。
(2)は確かにそうなった。ところが、(1)はそうならなかった。2番目のPOPFの実行直後に割り込みが発生した。(それ以降は発生しない。)

まったくわけがわからない挙動だ(;_;)。


こんな変な挙動なら、きっと誰もPOPFでシングルステップ割り込みフラグを操作するプログラムなんて作ってないっ、そう決め付けて、この変な挙動を実装するのは放棄した。(POPFもIRETと同じ挙動になるようにした。)


結局直したのは以下の2点。
・シングルステップ割り込みフラグを参照するタイミング
・割り込み許可フラグに影響を受けないようにする

monのt コマンドは正常に実行されるようになった。
posted by Shinra at 22:28| Comment(0) | TrackBack(0) | EMU | このブログの読者になる | 更新情報をチェックする

2006年10月05日

グラフィック画面8

グラフィック画面のパレット0を不透明にした場合で、
分割画面が割り当てられていない領域がある場合に、
その領域が透明にならずに、パレット0の色になってしまう。

hare1.PNG

上記画面の下部のピンク色の部分は、分割画面が割り当てられていないので
本来は透明(=結果として黒)になるべき。パレット0を不透明に設定してピンクにしているために、そちらの色が出てしまっている。

分割画面がない領域には、ピクセルのデータとして0を出力していたため、
こうなってしまった。ピクセルのデータが0なのと、ピクセルのデータが
ないのとは区別しなければならなかった。

普通パレット0を不透明にすることなんてないから、完全に盲点だった。
posted by Shinra at 21:46| Comment(0) | TrackBack(0) | EMU | このブログの読者になる | 更新情報をチェックする

2006年10月04日

CPU

# 久々にVA-EGを修正

自作のプログラムがVA-EGで動かすと動作がおかしくなった。
調べたら、callした先から呼び出し元にretしない。
スタックを操作している命令になにか怪しいのがあるのだろうと
call先のプログラムを見ていたら、POP SPをやっている。
確かにPOP SP実行後にSPが期待する値になっていない。

実機→スタックの内容がそのままSPに入る
np2(V30モード)→スタックの内容+2がSPに入る

V30とμPD9002で動作が違うのだろうか?

np2(286モード)は「スタックの内容がそのままSPに入る」なので、
V30モードでもそちらの処理が有効になるように修正した。


なお、(実機では)
PUSH SPは、SP-2がスタックに書き込まれるので、

PUSH SP
POP SP

を実行すると、SPは変化しないのではなく、2減る。
PUSHとPOPが対称になっていない。

[追記]
POP SPについてはV30もμPD9002と同じ挙動。9801VXをV30モードにして確認。
posted by Shinra at 00:56| Comment(0) | TrackBack(0) | EMU | このブログの読者になる | 更新情報をチェックする

広告


この広告は60日以上更新がないブログに表示がされております。

以下のいずれかの方法で非表示にすることが可能です。

・記事の投稿、編集をおこなう
・マイブログの【設定】 > 【広告設定】 より、「60日間更新が無い場合」 の 「広告を表示しない」にチェックを入れて保存する。


×

この広告は1年以上新しい記事の投稿がないブログに表示されております。