2020年5月26日火曜日

XPAC2解析(続き)

XPAC2解析の続き
パソピアの個体によっては、XPAC2のデータ化けが発生する場合があるとのこと。

うちにあるパソピア7と700達で試してみましたが再現できず...

XPAC2のコードと資料を追いかけてみたので、データ化けの可能性をまとめてみます。
結構、自分自身も忘れていたので備忘録も兼ねて。

パソピアのPAC SLOT2のピンと信号の関係を下の図にまとめました

パソピアでポート18h~1Bhに対してIN/OUT命令が実行されると、Pin#14(nCSEL2)がLowになります
IN命令の場合はPin#15(nCRD)がLow、OUT命令の場合はPin#16(nCWR)がLowです
Pin#12(CAD0)とPin#11(CAD1)の組み合わせでポート番号がわかります。(図左下の表を参照)
Pin#10,#9,#8,#6,#5,#4,#2,#1の8本のピンで、8bitデータを入出力します。

上画面のロジアナ波形は、左側のくぼみがOUT命令、右側がIN命令なので、
OUT &H19,&H00 ' 上位アドレスを00hに指定
IN &H1A ' 指定したアドレスのデータを読み込む
が実行され、&HAAが返答されている、という状況だと思われ

XPAC2はPollingしながらPin#14(nCSEL2)がLowになるのを待っています。
nCSEL2がLowになったら、Pin#15(nCRD) or Pin#16(nCWR)どちらがLowになっているかチェック。nCWRがLowだった場合はパソピアから8bitデータを読み込み、指定されたポート番号に応じて処理を行います。nCRDがLowだった場合はパソピアに対してデータを出力します

データ化けの可能性はいろいろ考えられますが、
nCRDでデータ要求が来た際にXPAC2はMRAM/SRAMの値を8bitデータで返答しますが、その返答がパソピアの読み込みまで間に合わない、という可能性を考えてみます。
その場合の対策としては、
・XPAC2のnCSEL2チェックのPolling間隔を短くしてみる
・nCSEL2とnCRDがLowになってから、XPAC2がデータを応答するまでの時間を短くする
とか。
多少パソピアのクロックが安定していない場合でも、追従できる効果が期待できます。

上記の対策を入れたテスト用ROMを用意してみましたが、再現環境がないと確認できないので、まったく効果ないかもしれません...
更に今回の修正はフラッシュROM側なので、フラッシュROM書き込み用のデバイスが必要になります。
(2020/5/31追記)
先日用意したテスト用ROMは、初代パソピアで動かなそうだったので見直してみました
(初代パソピア実機で確認してないですが、たぶん動作しなかったはず)

以下はパソピア700の波形で、nCSEL2(B5)とnCRD(B6)の差は10ns程度です
パソピア7/700はどちらも同じようなタイミングで、先日のテストROMは問題なかったのですが、以前とった初代パソピアの波形をみるとCWR(B0)、CRD(B1)とCSEL2(B2)のタイミングが200ns程度ずれています。
先日のテストROMではCSEL2チェックのPolling間隔を短くしたため、初代パソピアの200nsのタイミングずれには対応できなかったはずです...

方針を変えてテスト用ROMを作り直してみました
・パソピアからのデータ書き込み(out &H1A, xx)に対する処理の高速化(SRAM/MRAM)
・ポーリング間隔やIN命令に対するデータ応答時間は現状維持(高速化処理は入れましたが、以下の処理を入れたら同じになってしまいました...)
・AVR側データ入力をプルアップ指定(パソピア側の信号が弱い場合に効果があるか...?)それに伴い、応答データはAVRのレジスタに保持するように切り替え
・SRAMサイズ以上のアドレスが指定された場合に、データは明示的に0xFFを返答
・コードサイズが増えてROM領域オーバーしたので、Joystick周りのコード最適化
など

見直したテスト用ROM(2020/06/06更新)を置きました。 初代パソピア(T-BASIC1.1)、パソピア7、700で動作確認してます。
これで改善すると良いのですが...
(2020/06/14更新)改善しなかったということなので、別な対策を考えてみました。ブログに解析の続きをまとめてみました

0 件のコメント:

コメントを投稿