Z80GALの構想（その８）Blocking/Deblockingの実装 [Z80]
前回の「Z80GALの構想（その７）hexローダーでのCP/M-80ブート」の記事の最後の方で「Blocking/Deblocking処理を追加してSDアクセスを高速化したい」と書いたように、今回はBlocking/Deblocking処理の実装について書いてみたいと思います。
その前に、前回記事に追記しましたが、"dir *.z"のようにファイルが一致しないdirコマンドで固まる現象が発生することが判明しました。割込み処理で引き継いだスタック上へのpushを無くし、スタックを切りなおすことでこの問題が解消しました。
この為、割込み処理の先頭と末尾にSPストア／リストア等が追加になったことから実行速度が少し遅くなりました。
下表が今回の割込み処理の変更とBlocking/Deblocking処理を追加前後において、いくつかのパターンの処理時間を測定した結果です。
純粋にメモリ上のみの処理のASCIIART.BASの実装速度を16MHzで動作するPic24CPMと比較すると、従来はほぼ同じ速度だったのが、速度が約1割減となり14.5MHz(=16x75/83)相当の速度ということになりました。
SDカードのアクセスはPic24CPMよりも早くなり、全体的にはPic24CPM相当のパフォーマンスと言えるのではないでしょうか？（シリアル通信の速度がPic24CPMは38400bpsでZ80GALは9600bpsなので画面表示はZ80GALの方が遅い）
SPIインターフェースやシリアル通信をソフトで実装した割にはまずまずの結果だと思います。
話をBlocking/Deblocking処理に戻すと、処理自体は「3チップ構成68Kマイコンの構想（その１２）Blocking/Deblocking」の記事に書いたものとほぼ同じロジックです。この時はsector read時に無条件にバッファをFlushしていましたが今回はバッファ内にリード対象のデータがある場合にはFlushしないようにしました（この変更による速度的な効果は未確認でほとんど効果は無いと思いますが少しでも速くなるように変更した）
上記の記事の時と同様にSDカードのブロックサイズは512byteでCP/Mのブロックサイズが2Kbyteです。CP/Mのセクタサイズは128byteに固定なのでSDカードの1ブロックリード／ライトで4セクタ分のリード／ライトができるようになります。また、CP/Mの新ブロックへの書込み時にはSDブロックの先読みが4回分省略できます。
動作を確認するために、連続的なリード処理とライト処理のテストプラグラムを作成し、ロジアナで確認しました（ファイルアクセスの直前でポーズ（キー入力）することでディレクトリ処理が観測されないようにしています）。
また、ライト処理は新規に作成したファイルに対しての連続書込みになるようにしています。
今回の変更（Blocking/Deblocking処理の実装と割込み処理の変更）前の確認結果が下図になります。
変更後のロジアナでの確認結果が下図になります。
上図での4回分のリード／ライトがBlocking/Deblocking処理により1回に集約されています。また、新ブロックへの書込みでは想定通り、先読み無しでSDカードへのライト処理のみになっています。
ライト時のデータ送信完了からSDからの応答までの時間が上図よりも短いのはSDカードの応答速度の違いによるものです。
★追記 2020/11/15 {
本確認作業で使用したSDカードは下記になります（いずれもmicroSDです）
・変更前：ShanDian micro SD HC1 8GB
・変更後：SAMSUNG EVO Plus 32GB
}
twitterにポストしたBDS Cでのコンパイル動画付きコメントを貼っておきます。
[TOP] [ 前へ ] 連載記事 [ 次へ ]
その前に、前回記事に追記しましたが、"dir *.z"のようにファイルが一致しないdirコマンドで固まる現象が発生することが判明しました。割込み処理で引き継いだスタック上へのpushを無くし、スタックを切りなおすことでこの問題が解消しました。
この為、割込み処理の先頭と末尾にSPストア／リストア等が追加になったことから実行速度が少し遅くなりました。
下表が今回の割込み処理の変更とBlocking/Deblocking処理を追加前後において、いくつかのパターンの処理時間を測定した結果です。
純粋にメモリ上のみの処理のASCIIART.BASの実装速度を16MHzで動作するPic24CPMと比較すると、従来はほぼ同じ速度だったのが、速度が約1割減となり14.5MHz(=16x75/83)相当の速度ということになりました。
SDカードのアクセスはPic24CPMよりも早くなり、全体的にはPic24CPM相当のパフォーマンスと言えるのではないでしょうか？（シリアル通信の速度がPic24CPMは38400bpsでZ80GALは9600bpsなので画面表示はZ80GALの方が遅い）
SPIインターフェースやシリアル通信をソフトで実装した割にはまずまずの結果だと思います。
|
||||||||||||||||||||||||||||
|
※1 今回のbiosソースをM80でリストファイル出力付きでアセンブルした際の時間(m80 =bios/l) ※2 hello.cをHiTech Cでコンパイルした場合の時間(c -v hello.c) ★追記 2020/11/29 CP/M側のスタック制限により10%弱遅くなるのはもったいないのでCP/M側のCCP用スタックを拡張してBIOS内の割込み処理ではStackを再設定しないように改善してみた結果を追記しました（improveカラム）。処理速度は16MHz相当に戻りました。 ★追記 2021/10/03 タイマ割込み内のシリアル送受信処理を見直し「push hl」の範囲を最小化することで高速化し、実行時間測定結果を上表のimpeove2のカラムに追記しました。 |
||||||||||||||||||||||||||||
話をBlocking/Deblocking処理に戻すと、処理自体は「3チップ構成68Kマイコンの構想（その１２）Blocking/Deblocking」の記事に書いたものとほぼ同じロジックです。この時はsector read時に無条件にバッファをFlushしていましたが今回はバッファ内にリード対象のデータがある場合にはFlushしないようにしました（この変更による速度的な効果は未確認でほとんど効果は無いと思いますが少しでも速くなるように変更した）
上記の記事の時と同様にSDカードのブロックサイズは512byteでCP/Mのブロックサイズが2Kbyteです。CP/Mのセクタサイズは128byteに固定なのでSDカードの1ブロックリード／ライトで4セクタ分のリード／ライトができるようになります。また、CP/Mの新ブロックへの書込み時にはSDブロックの先読みが4回分省略できます。
動作を確認するために、連続的なリード処理とライト処理のテストプラグラムを作成し、ロジアナで確認しました（ファイルアクセスの直前でポーズ（キー入力）することでディレクトリ処理が観測されないようにしています）。
また、ライト処理は新規に作成したファイルに対しての連続書込みになるようにしています。
今回の変更（Blocking/Deblocking処理の実装と割込み処理の変更）前の確認結果が下図になります。
| ファイルの連続リード処理（変更前） |
|
|
| ファイルの連続ライト処理（変更前） |
|
|
変更後のロジアナでの確認結果が下図になります。
上図での4回分のリード／ライトがBlocking/Deblocking処理により1回に集約されています。また、新ブロックへの書込みでは想定通り、先読み無しでSDカードへのライト処理のみになっています。
ライト時のデータ送信完了からSDからの応答までの時間が上図よりも短いのはSDカードの応答速度の違いによるものです。
★追記 2020/11/15 {
本確認作業で使用したSDカードは下記になります（いずれもmicroSDです）
・変更前：ShanDian micro SD HC1 8GB
・変更後：SAMSUNG EVO Plus 32GB
}
| ファイルの連続リード処理（変更後） |
|
|
| ファイルの連続ライト処理（変更後） |
|
|
twitterにポストしたBDS Cでのコンパイル動画付きコメントを貼っておきます。
GALを使ったZ80ボードを構想中
— skyriver (@wcinp) November 15, 2020
ソフト実装のSPIではSDカードのアクセスが遅いのでCP/MのBlocking/Deblocking処理を実装し、SDアクセスが違和感がないくらい速くなった
BDS Cのコンパイルも爆速で完了します^^https://t.co/8kcLcFLiia#Z80GAL #CPM80 #BlockingDeblocking #BdsC pic.twitter.com/Xeht27hkct
[TOP] [ 前へ ] 連載記事 [ 次へ ]
)
){kind=link}
){kind=link}
){kind=link}
){kind=link}