P/ECE研究室～S1C33分室

* Tue May 28 00:00:00 JST 2002 Naoyuki Sawa

ゴミ・欠け、治りました。

修正か所は、一行です。「C:\usr\PIECE\sysdev\pcekn\lcd.c」の310行目、

	pdwait(24);

という行を、

	pdwait(25);

に変更し、カーネルを作り直して転送すると、ゴミ・欠けはなくなります。
それでは、ゴミ・欠けがなくなった画面をご覧ください。


色           撮影
3(黒)        
1(明るい灰色) 


今回は、前述の通りカーネルを修正しただけで、実験用のサンプルプログラムには、
5月21日「シリアルコントローラ#1」の回と同じものを使用しました。
写真の通り、ゴミ・欠けは完全に消えてなくなりました。

ゴミ・欠けの原因は、タイミングの問題でした。
5月23日「シリアルコントローラ#2」の回で書いたように、pceLCDTrans()を使った場合の画面転送は、
横8ピクセル×縦88ピクセル単位の、形式変換・転送、の16回繰り返しで行われます。
S6B0741 LCDコントローラのデータシートでは、この横8ピクセル×縦88ピクセル単位のことを、「ページ」と呼んでいます。
現在のP/ECEカーネルは、画面転送の高速化のため、先行ページの転送と次のページの形式変換を、同時進行させています。
ページ0の転送とページ1の形式変換が同時進行する様子を、図解します。

１．カーネル内には、LCDへデータを転送するためのバッファがあります。

　　　　　　　　　　　　　＋－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－＋
　　カーネル内のバッファ：｜　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　｜
　　　　　　　　　　　　　＋－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－＋

２．仮想画面データから、ページ0に相当する部分を形式変換し、バッファに格納します。

　　　　　　　　　　　　　｜←－－－－－－－－－ページ０の変換済みデータ－－－－－－－－－－→｜
　　　　　　　　　　　　　＋－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－＋
　　カーネル内のバッファ：｜０００００００００００００００００００００００００００００００００｜
　　　　　　　　　　　　　＋－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－＋

３．ページ0の変換済みデータを、LCDに転送開始します。
　　LCDへの転送は、DMAコントローラによってシリアルコントローラに送られ、シリアル通信によってLCDへ送られます。
　　LCDへの転送に関しては、もうCPUがやることはありません。

　　　　　　　　　　　　　｜←ページ０（転送済み）→｜←－－－－ページ０（転送待ち）－－－－→｜
　　　　　　　　　　　　　＋－－－－－－－－－－－－＋－－－－－－－－－－－－－－－－－－－－＋
　　カーネル内のバッファ：｜　　　　　　　　　　　　｜００００００００００００００００００００｜
　　　　　　　　　　　　　＋－－－－－－－－－－－－＋－－－－－－－－－－－－－－－－－－－－＋

４．このまま全データが転送されるまで待っていては、CPUの時間が無駄になってしまいます。
　　そこで、転送済みとなって空いたバッファの領域を使って、次のページの形式変換を始めてしまいます。

　　　　　　　　　　　　　｜←ページ１（変換中）→｜　　｜←－－－ページ０（転送待ち）－－－→｜
　　　　　　　　　　　　　＋－－－－－－－－－－－＋－－＋－－－－－－－－－－－－－－－－－－＋
　　カーネル内のバッファ：｜１１１１１１１１１１１｜　　｜００００００００００００００００００｜
　　　　　　　　　　　　　＋－－－－－－－－－－－＋－－＋－－－－－－－－－－－－－－－－－－＋

５．ページ0の転送が終わったころには、既にページ1の形式変換もほとんど終わっているでしょう。
　　もう少し待って、ページ1の形式変換が終われば、すぐさまページ1の転送を始めることができます。

　　　　　　　　　　　　　｜←－－－－－－－ページ１の変換中データ－－－－－－－－→｜もう少し！
　　　　　　　　　　　　　＋－－－－－－－－－－－－－－－－－－－－－－－－－－－－＋－－－－＋
　　カーネル内のバッファ：｜１１１１１１１１１１１１１１１１１１１１１１１１１１１１｜　　　　｜
　　　　　　　　　　　　　＋－－－－－－－－－－－－－－－－－－－－－－－－－－－－＋－－－－＋

理想的には、ページ0の転送完了と、ページ1の変換完了が同時なら、最も効率が良くなります。
ところが、現在のP/ECEカーネルのタイミング調整では、ページ1の形式変換がページ0の転送を追い越してしまいます！

　　　　　　　　　　　　　｜←－－－－－－ページ１の変換中データ－－－－－－－→｜
　　　　　　　　　　　　　＋－－－－－－－－－－－－－－－－－－－－＋－－－－－＋－－－－－－＋
　　カーネル内のバッファ：｜１１１１１１１１１１１１１１１１１１１１｜１１１１１｜００００００｜
　　　　　　　　　　　　　＋－－－－－－－－－－－－－－－－－－－－＋－－－－－＋－－－－－－＋
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　｜←ページ０（転送待ち）→｜

追い越された分が、ページ0のゴミ・欠けとなります。
上の図では、わかりやすさのために、あからさまに追い越しているように描きましたが、
現在のP/ECEカーネルのタイミング調整では、ちょうど最後のライン(88ライン目)で追い越しが発生します。
よって、88ライン目に、ゴミ・欠けが発生するのです。

ただし、この振る舞い(ゴミ・欠けの発生)は、意図されたものであるようにも思えます。
先ほど修正を加えた、

	pdwait(24);

という行は、追い越しが発生しないように、形式変換の速度を下げるためのウェイトなのですが、
以前には、もっと大きなウェイトが取られていたような形跡があるのです(gfs1.s内のdisp2nsサブルーチン参照)。
ゲーム用途が大きな位置を占めるP/ECEにとって、画面転送の高速化は非常に重要な点ですので、
画面端に多少のゴミ・欠けが出ることを許容して、ぎりぎりの高速化を狙ったのかもしれません。

さて、次回こそ、シリアルコントローラとLCDコントローラの話題に入っていきたいと思います。
LCDコントローラのデータシートを見ながら、少しづつ、LCDコントローラの機能を試しています。
ハードウェアスクロールや画面反転、パレット機能なんかも備えていて、かなりおもしろいです。

(続きます...)



nsawa@piece-me.org