HD64180Compact（その４）ディバッグモニタ [Z80]
前回の記事で書いたように手配線で製作した開発機がハード的には動いているようなのでディバッグモニタを入れることにしました。
GAME言語で自作した簡易モニタのGAMON入れてみたところ、ブレークが動作しない場合があるので少し悩みましたが、Z80を使用したZ80PicCompactでも同様の現象が発生することが判り、GAMONを修正し正常動作を確認しました。ブレーク機能のディバッグにはブレーク機能が使えないので机上ディバッグですｗ。
ついでにHD64180でも使えるようにI/O入出力のコマンドのアドレスを16bit対応しました。「GAME言語で作った簡易モニタ」のページでアップデート版を公開しています。
HD64180関連の情報をネットで眺めていたところ、敏雪さんの「Ｓｏｆｔいろいろ」のページでHD64180用のモニタであるH18MONを見つけ、インストールしてみました。アセンブルには IR80.EXE 相当のアセンブラが必要なようなのですがネットでは見つけられなかったのでperlを使ってローカルのテンポラリラベルを自動変換する等してアセンブルしました。HD64180固有の命令は前回の記事で書いたマクロで対応しました。
コンソール入出力部分を変更しただけでは動かなかったのですが、メモリチェック部分を変更することで動作するようになりました（ROMでの運用を想定しているため、RAM上にロードした状態では動かなかった）。
起動画面のキャプチャが下図になります。今回作成したHD64180Compactではブート時にPICからロードされるHexLoaderを0xff00に配置していて、この領域をH18MONがデータ領域として使用しているので、GAMONを使ってロードしています。
上図のヘルプ表示にもあるようにH18MONは逆アセンブルやトレース機能もあり、このような高機能なモニタを公開されている作者に感謝致します。
ブレーク機能の試行として「メモリ上で実際に動くプログラム（その２）」の記事で書いたフラグの未使用ビット設定確認のソフトを実行した際の画面キャプチャが下図になります。Hexファイルは'^Z'で終端されている必要があるようです。実行結果として"Ok"が表示されているのでHD64180でもフラグの未使用ビットに値を設定できることが判ります。
因みにGAMONで同様にブレークした際の画面が下図です。
逆アセンブル機能はいいとしてトレース機能には食指が動きますが、暫くは手に馴染んだGAMONを使っていきたいと思います。
[TOP] [ 前へ ] 連載記事一覧 [ 次へ ]
GAME言語で自作した簡易モニタのGAMON入れてみたところ、ブレークが動作しない場合があるので少し悩みましたが、Z80を使用したZ80PicCompactでも同様の現象が発生することが判り、GAMONを修正し正常動作を確認しました。ブレーク機能のディバッグにはブレーク機能が使えないので机上ディバッグですｗ。
ついでにHD64180でも使えるようにI/O入出力のコマンドのアドレスを16bit対応しました。「GAME言語で作った簡易モニタ」のページでアップデート版を公開しています。
HD64180関連の情報をネットで眺めていたところ、敏雪さんの「Ｓｏｆｔいろいろ」のページでHD64180用のモニタであるH18MONを見つけ、インストールしてみました。アセンブルには IR80.EXE 相当のアセンブラが必要なようなのですがネットでは見つけられなかったのでperlを使ってローカルのテンポラリラベルを自動変換する等してアセンブルしました。HD64180固有の命令は前回の記事で書いたマクロで対応しました。
コンソール入出力部分を変更しただけでは動かなかったのですが、メモリチェック部分を変更することで動作するようになりました（ROMでの運用を想定しているため、RAM上にロードした状態では動かなかった）。
起動画面のキャプチャが下図になります。今回作成したHD64180Compactではブート時にPICからロードされるHexLoaderを0xff00に配置していて、この領域をH18MONがデータ領域として使用しているので、GAMONを使ってロードしています。
| H18MON起動画面 |
|
|
| ※2024/02/29 最新版に差し替え |
上図のヘルプ表示にもあるようにH18MONは逆アセンブルやトレース機能もあり、このような高機能なモニタを公開されている作者に感謝致します。
ブレーク機能の試行として「メモリ上で実際に動くプログラム（その２）」の記事で書いたフラグの未使用ビット設定確認のソフトを実行した際の画面キャプチャが下図になります。Hexファイルは'^Z'で終端されている必要があるようです。実行結果として"Ok"が表示されているのでHD64180でもフラグの未使用ビットに値を設定できることが判ります。
| H18MONでのブレーク動作 |
|
|
| ※2024/02/29 最新版に差し替え |
因みにGAMONで同様にブレークした際の画面が下図です。
| GAMOMでのブレーク動作 |
|
|
| ※2024/03/02 最新版に差し替え |
逆アセンブル機能はいいとしてトレース機能には食指が動きますが、暫くは手に馴染んだGAMONを使っていきたいと思います。
[TOP] [ 前へ ] 連載記事一覧 [ 次へ ]
HD64180Compact（その３）MBASICでASCIIART [Z80]
HD64180 と USB 機能を有する 20 ピンの PIC を使った 3 チップ構成のボードの開発の続編です。
前回の記事でジャンプ命令によるループができたことを書きましたが、後述するように Hello 表示と HexLoader も動いたので「CP/M-80でのBIOSエミュレートによるMBASICの起動」の記事で書いたように CP/M の BIOS をエミュレートして MBASIC を起動し ASCIIART を動かしてみました。
今回開発の HD64180Compact と類似の構成で Z80 を実装した Z80PicCompact との実行時間比較も行ってみました。
最初にソフト制御可能なメモリと I/O アクセス時の WAIT 設定を行わず（リセット直後の状態では WAIT ステート数がメモリ：3、IO：4）実行したところ（上表のNo2）かなり遅い結果でしたが、WAIT を最小の設定（メモリ：0、IO：1）にした結果（上表のNo3）、Z80PicCompact のクロックから比例計算した Z80 の速度の 1.15(=95.4x2/165.2)倍になり、ASCIIART.BAS の実行では HD64180 は Z80 より 1.15 倍速いことになります。尚、リフレッシュは禁止の設定にしています。HD64180 には 8bit の乗算命令もあるのでこれを活用できる場面では速度差が更に大きくなると思います。
WAIT を最小に設定して ASCIIART.BAS を実行した際の画面のキャプチャーが下図です。PIC に実装した BootROM 機能により Z80 側で HexLoader が起動し、その後 BIOS エミュと MBASIC の Hex ファイルを読み込ませています。
上記の比較表のエビデンスとして HD64180Compact（最大 WAIT）と Z80PicCompact での ASCIIART 実行時の画面キャプチャーも貼っておきます。
CP/M の BIOS エミュレートのソースも短いので貼っておきます。HD64180 の拡張命令は macro 定義して使いました。
［補足］
以降に Hello 表示の際のデータをメモとして記録しておきます。下記は Z80 側のソースです。EnPic で PIC が提供するサービスが有効になり、DisPic で無効になります。
下記が初めて Hello 表示した際の画面です^^
Z80PicCompact の環境を若干変更することで動作しました。
下図が Hello 表示時のロジアナ波形のサンプルです。1文字を PIC に送信するのに 60us 程度の時間がかかっています。突発的に時間がかかっている部分は PIC 側が USB 関連の処理をしているためだと思います。
下図は Puts をコールする部分を拡大したもので WR/ が２回アクティブになっている部分（マーカー：0）がスタックへのリターンアドレスの書込み部分です。
その後、毎回テストプログラムを PIC に書き込むのは面倒なので、PIC に HexLoader を書き込んだ状態で冒頭に書いた MBASIC と ASCIIART.BAS で実行速度の評価を行いました。
[TOP] [ 前へ ] 連載記事一覧 [ 次へ ]
前回の記事でジャンプ命令によるループができたことを書きましたが、後述するように Hello 表示と HexLoader も動いたので「CP/M-80でのBIOSエミュレートによるMBASICの起動」の記事で書いたように CP/M の BIOS をエミュレートして MBASIC を起動し ASCIIART を動かしてみました。
今回開発の HD64180Compact と類似の構成で Z80 を実装した Z80PicCompact との実行時間比較も行ってみました。
| No. | machine environment | clock | time | ratio |
|---|---|---|---|---|
| 1 | Z80PicCompact | 12MHz | 95.4s | 1.00 |
| 2 | HD64180Compac(maximal Wait) | 6MHz | 314.1s | 3.29 |
| 3 | HD64180Compact(minimal Wait) | 6MHz | 165.2s | 1.73 |
最初にソフト制御可能なメモリと I/O アクセス時の WAIT 設定を行わず（リセット直後の状態では WAIT ステート数がメモリ：3、IO：4）実行したところ（上表のNo2）かなり遅い結果でしたが、WAIT を最小の設定（メモリ：0、IO：1）にした結果（上表のNo3）、Z80PicCompact のクロックから比例計算した Z80 の速度の 1.15(=95.4x2/165.2)倍になり、ASCIIART.BAS の実行では HD64180 は Z80 より 1.15 倍速いことになります。尚、リフレッシュは禁止の設定にしています。HD64180 には 8bit の乗算命令もあるのでこれを活用できる場面では速度差が更に大きくなると思います。
WAIT を最小に設定して ASCIIART.BAS を実行した際の画面のキャプチャーが下図です。PIC に実装した BootROM 機能により Z80 側で HexLoader が起動し、その後 BIOS エミュと MBASIC の Hex ファイルを読み込ませています。
| HD64180Compact での ASCIIART 実行画面（ WAIT 最小設定時） |
|
|
上記の比較表のエビデンスとして HD64180Compact（最大 WAIT）と Z80PicCompact での ASCIIART 実行時の画面キャプチャーも貼っておきます。
| HD64180Compact での ASCIIART 実行画面（WAIT 最大設定時） |
|
|
| Z80PicCompact での ASCIIART 実行画面 |
|
|
CP/M の BIOS エミュレートのソースも短いので貼っておきます。HD64180 の拡張命令は macro 定義して使いました。
| CP/M BIOS エミュレーター（Z80 アセンブラ） |
|
［補足］
以降に Hello 表示の際のデータをメモとして記録しておきます。下記は Z80 側のソースです。EnPic で PIC が提供するサービスが有効になり、DisPic で無効になります。
| Hello 表示プログラム（Z80 アセンブラ） |
|
下記が初めて Hello 表示した際の画面です^^
Z80PicCompact の環境を若干変更することで動作しました。
| Hello 表示画面 |
|
|
下図が Hello 表示時のロジアナ波形のサンプルです。1文字を PIC に送信するのに 60us 程度の時間がかかっています。突発的に時間がかかっている部分は PIC 側が USB 関連の処理をしているためだと思います。
| Hello 表示時のロジアナ波形例 |
|
|
下図は Puts をコールする部分を拡大したもので WR/ が２回アクティブになっている部分（マーカー：0）がスタックへのリターンアドレスの書込み部分です。
| ロジアナ波形の CALL 部の拡大図 |
|
|
その後、毎回テストプログラムを PIC に書き込むのは面倒なので、PIC に HexLoader を書き込んだ状態で冒頭に書いた MBASIC と ASCIIART.BAS で実行速度の評価を行いました。
[TOP] [ 前へ ] 連載記事一覧 [ 次へ ]
HD64180Compact（その２）開発機完成 [Z80]
前回の記事で書いた HD64180Compact の構想での開発用基板（以降、開発機と記す）が完成しました（下の写真）。自作のワイヤリングペンを使ってポリウレタン線で結線しています。
赤いフッククリップは PIC 書込み用の PICKit3 を接続するためのもので、接続用の PIC に被せるピン台を今回作りました。動作確認するのに必要最小限の信号を中央のピンソケットから取り出し、ロジアナに接続しています。下側で接続されているのは USB ケーブルでボードへ給電とパソコンとの通信（現時点では動作未確認）に使います。
共立エレショップさんから購入した新品の HD64B180R0P もあるのですがもったいないので以前、海外通販で購入した HD64180RP8 のリユース品を実装しています。メモリは CPU の上限の 512KB です。クロックは PIC 側の USB 用の 12MHz を流用しています（HD64180 は 6MHz 動作）。
開発機完成記念として結線チェック用の回路図も貼っておきます。動作モニタ用のトランジスタを使った LED 回路の部分は未結線ですが、動作確認後に結線する予定です。
実装した USB 機能付きの 20 ピンのPIC（PIC18F14K50）は BootROM と 通信／SPI インターフェースとして機能します。通信インターフェースはパソコンとは USB、HD64180 とはパラレル I/F で接続なので高速です。SPI は EEPROM もしくは SD カードに接続する予定です。Z80PicCompact 用のソフトをほぼそのまま持ってきて動作確認してみました。若干の変更は行ったものの最初の一歩であるジャンプ命令でのループ動作ができました。
実施手順はZ80PicCompact の時とほぼ同様で下記のようになります。
下図がジャンプループに成功した際のロジアナ波形例です。右端のウェイト無しで実行している部分がジャンプループです。１周期が 3us で 6MHz 動作なので遅い（JPは 9 ステート）感じですが、リセット直後の状態なのでソフト制御のウェイトがかかっているためだと思います。
★追記 2024/02/26 {
CPUは6MHz動作なので1クロックは(1/6)usでリセット直後は１回のメモリアクセスに３クロックのウェイトが入るので
3（=(1/6)*(9+3*3)）us
となり下図の実測値と一致します。
}
尚、LIR/ は Z80 の M1 相当の信号でオペコードフェッチの際にアクティブになります。
★追記 2024/02/22 {
HD64180 には内蔵の I/O レジスタがあり、今回のブート時のメモリ書込みに使用する INI 命令で I/O アドレスを明示的に外部アドレスにするために初期化コードの末尾に C-reg の設定を追加しました。追加後のロジアナ波形例を貼っておきます。但し、他のロジアナ波形は追加前のままです。
}
以降に自分へのメモの意味も込めてジャンプループ実現までに発生した問題とその対処の概要を記録しておきます。
［補足］
メモリ設定データを HD64180 へ渡すために INIR 命令を使用していましたが、このコード自体は PIC がデータバスに出力しているので B-reg がゼロになっても繰り返されることから B-reg を設定していません。
しかし厳密にいうと B-reg がゼロになった場合とそれ以外の場合で実行ステート数が異なる（ゼロの場合が速い）ことから B-reg の影響を受けない INI 命令（ステート数は常に B-reg がゼロの場合と同じ）を使用することにしました。
ロジアナ波形例を下記に示します。INI の方が若干早くなったようにも見えますが次の INI では時間がかかっているようなので今回の処理ではウェイトが掛かっていることから処理時間はほぼ同じと言えそうです。
[TOP] [ 前へ ] 連載記事一覧 [ 次へ ]
赤いフッククリップは PIC 書込み用の PICKit3 を接続するためのもので、接続用の PIC に被せるピン台を今回作りました。動作確認するのに必要最小限の信号を中央のピンソケットから取り出し、ロジアナに接続しています。下側で接続されているのは USB ケーブルでボードへ給電とパソコンとの通信（現時点では動作未確認）に使います。
共立エレショップさんから購入した新品の HD64B180R0P もあるのですがもったいないので以前、海外通販で購入した HD64180RP8 のリユース品を実装しています。メモリは CPU の上限の 512KB です。クロックは PIC 側の USB 用の 12MHz を流用しています（HD64180 は 6MHz 動作）。
| 完成した HD64180Compact の開発機 |
|
|
開発機完成記念として結線チェック用の回路図も貼っておきます。動作モニタ用のトランジスタを使った LED 回路の部分は未結線ですが、動作確認後に結線する予定です。
| 結線チェック用回路図 |
|
|
実装した USB 機能付きの 20 ピンのPIC（PIC18F14K50）は BootROM と 通信／SPI インターフェースとして機能します。通信インターフェースはパソコンとは USB、HD64180 とはパラレル I/F で接続なので高速です。SPI は EEPROM もしくは SD カードに接続する予定です。Z80PicCompact 用のソフトをほぼそのまま持ってきて動作確認してみました。若干の変更は行ったものの最初の一歩であるジャンプ命令でのループ動作ができました。
実施手順はZ80PicCompact の時とほぼ同様で下記のようになります。
- 初期化コード実行
PIC が下記のコードを HD64180 がフェッチするタイミングでデータバス上に出力し、HD64180 が実行します。LD HL,StartAdr XOR A OUT (00H),A ; set RTS0 to low OUT (36H),A ; set refresh disable LD C,0FFH ; set external I/O address
※2024/02/22 Creg設定を追加
- INI 命令でのメモリ書込み
PIC からデータバス上に INI 命令のオペコードを出力し、HD64180 が I/O リードするタイミングでメモリに設定するコードを出力する。これを繰り返すことで上記１項で HL レジスタに設定したメモリ上にジャンプ命令のコードを書き込む。今回は 0100H から C3H, 00H, 01H の３バイトのデータを書き込んだ。
- メモリ展開したコードへジャンプ
上記２項でメモリに設定したコードの開始アドレスへのジャンプ命令を PIC が出力し、HD64180 が実行する。
下図がジャンプループに成功した際のロジアナ波形例です。右端のウェイト無しで実行している部分がジャンプループです。１周期が 3us で 6MHz 動作なので遅い（JPは 9 ステート）感じですが、リセット直後の状態なのでソフト制御のウェイトがかかっているためだと思います。
★追記 2024/02/26 {
CPUは6MHz動作なので1クロックは(1/6)usでリセット直後は１回のメモリアクセスに３クロックのウェイトが入るので
3（=(1/6)*(9+3*3)）us
となり下図の実測値と一致します。
}
尚、LIR/ は Z80 の M1 相当の信号でオペコードフェッチの際にアクティブになります。
| ジャンプループ実行時のロジアナ波形例（サンプリング：32MHz） |
|
|
★追記 2024/02/22 {
HD64180 には内蔵の I/O レジスタがあり、今回のブート時のメモリ書込みに使用する INI 命令で I/O アドレスを明示的に外部アドレスにするために初期化コードの末尾に C-reg の設定を追加しました。追加後のロジアナ波形例を貼っておきます。但し、他のロジアナ波形は追加前のままです。
| ジャンプループ実行時のロジアナ波形例（サンプリング：32MHz） |
|
|
以降に自分へのメモの意味も込めてジャンプループ実現までに発生した問題とその対処の概要を記録しておきます。
- IORQ 待ちで停止
［現象］
INIR 命令でメモリ設定時に IORQ/ が読み取りできず PIC 側の処理が停止した（下図）。
［原因と対処］
今回追加した IORQ を RTS0 でマスクする部分で、RTS0 のリセット後の値が High（マスク状態）だったので初期化コードに RTS0 をlow にする制御を追加した。
IORQ 待ちで停止
- INIR 後に停止
[現象]
実行コードをメモリに展開するための INIR 命令実行後 HD64180 が停止する。
［原因と対処］
INIR でコード出力後のウェイト解除時間が短すぎて HD64180 がウェイト解除にならないのでウェイト解除時間を長くした。
ウェイト解除ができない（赤カーソル部分）
- メモリ書込みで停止
[現象]
HD64180 が INIR で読み込んだデータをメモリに書き込み時にウェイトが解除されず、そのまま停止してしまう。
［原因と対処］
PIC 側が INIR に対してメモリに設定するデータを送った後、HD64180 がメモリ書込みできるように一定期間ウェイトを解除する。メモリライト直前のリフレッシュにより MREQ/ がアクティブになり、メモリライト用のウェイト解除が発動した為。対処として初期化コードにリフレッシュ禁止設定を追加した。
メモリライト直前のリフレッシュ動作（赤カーソル部分）
下図はリフレッシュ禁止設定後のロジアナ波形例で緑のカーソル部分が INIR の１回分の時間です。
リフレッシュ禁止後のロジアナ波形例
［補足］
メモリ設定データを HD64180 へ渡すために INIR 命令を使用していましたが、このコード自体は PIC がデータバスに出力しているので B-reg がゼロになっても繰り返されることから B-reg を設定していません。
しかし厳密にいうと B-reg がゼロになった場合とそれ以外の場合で実行ステート数が異なる（ゼロの場合が速い）ことから B-reg の影響を受けない INI 命令（ステート数は常に B-reg がゼロの場合と同じ）を使用することにしました。
ロジアナ波形例を下記に示します。INI の方が若干早くなったようにも見えますが次の INI では時間がかかっているようなので今回の処理ではウェイトが掛かっていることから処理時間はほぼ同じと言えそうです。
| INIR から INI に変更後のロジアナ波形例（赤カーソル部分が INI １回分） |
|
|
[TOP] [ 前へ ] 連載記事一覧 [ 次へ ]
メモリ上で実際に動くプログラム（その３） [Z80]
メモリ上で実際に動き（移動し）通過した後にはNOP命令のみを残してひたすらメモリ上を駆け回る自走プログラムで新たな案を思い付いたので記録しておきたいと思います。
前回の記事で書いた PUSH によるコード生成方式は自走プログラムの移動量が究極の１バイトであり、自走プログラムの移動量という点ではこれ以上小さくするのは不可能ということになります（プログラムの仕掛けという観点でも素晴らしいと思う）。
本連載の初回記事「メモリ上で実際に動くプログラム」に PUSH を使わずブロック転送のみを使用した自走プログラムを追記しましたが、同様にブロック転送のみの場合でも移動量をもっと小さくできないか考えてみました。
インクリメント方式のブロック転送である LDIR 命令では次のブロック転送のために１６ビットの減算をする必要があり、キャリーのクリア等が必要になることを考えるとデクリメント方式の LDDR を使いたいものです。ブロック転送を利用した場合の最小移動量は２バイトになりそうですが、ブロック転送命令（LDDR＝EDH,B8H）を二つ並べてブロック転送命令をブロック転送命令で上書きすることでブロック転送を中断しないようにするとブロック転送終了直後にコピーしたブロック転送を実行してしまうのでうまくいきません・・・
しかし、巧妙な仕掛けを思い付きました^^
方式のアイディアさえ固まれば、ブロック転送を利用した自走プログラムには慣れてきたのでほぼ机上コーディングのみで完成しました。完成したソースが下記で移動量は２バイトです。このソースを見て今回のアイディアの仕掛けが判りますか？
★追記 2024/02/09
X（Twitter）に投稿した自走状況を可視化した動画を貼っておきます。
★追記 2024/02/10
X での書込みメッセージに対して返信を頂きました。LDIR を使用し、移動量が１バイトというものです。コピー後の LDIR を再利用する部分とキャリーによる条件ジャンプの部分が味わい深いですね。LDIR で検討してみました（下記）が DI を除けば同じサイズになりました。
[TOP] [ 前へ ] 連載記事一覧 [ 次へ ]
前回の記事で書いた PUSH によるコード生成方式は自走プログラムの移動量が究極の１バイトであり、自走プログラムの移動量という点ではこれ以上小さくするのは不可能ということになります（プログラムの仕掛けという観点でも素晴らしいと思う）。
本連載の初回記事「メモリ上で実際に動くプログラム」に PUSH を使わずブロック転送のみを使用した自走プログラムを追記しましたが、同様にブロック転送のみの場合でも移動量をもっと小さくできないか考えてみました。
インクリメント方式のブロック転送である LDIR 命令では次のブロック転送のために１６ビットの減算をする必要があり、キャリーのクリア等が必要になることを考えるとデクリメント方式の LDDR を使いたいものです。ブロック転送を利用した場合の最小移動量は２バイトになりそうですが、ブロック転送命令（LDDR＝EDH,B8H）を二つ並べてブロック転送命令をブロック転送命令で上書きすることでブロック転送を中断しないようにするとブロック転送終了直後にコピーしたブロック転送を実行してしまうのでうまくいきません・・・
しかし、巧妙な仕掛けを思い付きました^^
方式のアイディアさえ固まれば、ブロック転送を利用した自走プログラムには慣れてきたのでほぼ机上コーディングのみで完成しました。完成したソースが下記で移動量は２バイトです。このソースを見て今回のアイディアの仕掛けが判りますか？
| ブロック転送での自走プログラム例（Z80 アセンブラ） |
|
★追記 2024/02/09
X（Twitter）に投稿した自走状況を可視化した動画を貼っておきます。
メモリ上で実際に動き（移動し）通過した後にはNOP命令のみを残してメモリ上を駆け回る自走プログラムでブロック転送方式で移動量が2byteのものができました
— skyriver (@wcinp) February 9, 2024
動画はEmyuZ-2200で自走の様子を可視化したものですhttps://t.co/ZtFauNTAdM#Z80 #自走プログラム pic.twitter.com/kXaYLmE6Q9
★追記 2024/02/10
X での書込みメッセージに対して返信を頂きました。LDIR を使用し、移動量が１バイトというものです。コピー後の LDIR を再利用する部分とキャリーによる条件ジャンプの部分が味わい深いですね。LDIR で検討してみました（下記）が DI を除けば同じサイズになりました。
| LDIR による1バイト移動の自走プログラム例（Z80 アセンブラ） |
|
[TOP] [ 前へ ] 連載記事一覧 [ 次へ ]
HD64180Compact（その１）構想 [Z80]
Ｘ（旧Twitter）のタイムラインで日立製の Z80 系 CPU である HD64B180ROP が共立エレショップさんで販売されていることを知り２個確保できました。
パッケージは 64 ピンのシュリンク DIP なので秋月さんからシュリンク DIP のソケットと 1.778mm ピッチの汎用基板を購入しました。
かなり前に 旧Twitter のタイムラインで HD64180 はハーフピッチの汎用基板に斜めに刺さるという情報を見た覚えがあります。しかし、今回購入した基板には逆に通常の DIP IC を斜めに刺すことができます。PIC を使って使用 IC 数を少なくすれば 大きな HD64180 をきれいに収めた方が作り易いと思ったからです。秋月さんでは通常ピッチとシュリンクピッチが縦横で混在している汎用基板も販売していますが最大でＣ基板サイズなので HD64180 を搭載するには残念ながら小さすぎます。
今回開発するワンボードを HD64180Compact と命名します。使用 IC 数を最小限にするように設計したいと考えていて、CPU 以外の IC としては SRAM と USB 機能を有した 20 ピンの PIC（PIC18F14K50）の３チップ構成にする予定です。以前に同様の構成でほぼ Z80 のチップサイズの CP/M が動くワンボードマイコンの Z80PicCompact を開発しましたが、今回は下記の課題についても対処したいと思います（まったく同じ仕掛けではつまらないですからね）。
下表に Z80Compact での PIC のピンアサインを再掲します。
HD46180ROP には RTS0/ のような Z80 にはなかった出力ピンがあるので、これを PIC アクセス用のコントロール信号として利用することで PIC を I/O アクセスする時のみ、 IORQ/ で wait 状態になるようにします。
初めに考案したトランジスタを使った回路をシミュレータで検証してみました。CNT がコントロール信号です。
想定通り CNT が low の時は WAIT/ はマスクされ、CNT が high の時に IORQ/ により、WAIT/ がアクティブになります。しかし、WAIT/ の low レベルが 0.8V 程度であり、HD64180 の規格である 0.8V 以下に対してマージンがありません。
下図はベースとエミッタの抵抗を小さくした場合のシミュレーション結果です。今度は WAIT/ の low レベルは規格を満たせていますね。
別の案としてショットキーバリアダイオードを使った OR 回路構成の案もシミュレートしてみました。これも WAIT/ 信号の low レベルが高すぎますね。
プルダウン抵抗の値を小さくしてシミュレートした結果が下図です。これなら行けそうですね。
部品数から考えてまずはショットキー案２で行こうかと思います。PIC の RB7 が抵抗を介して R2 へ接続することになるかと思います。
今回はプライオリティを下げて気が向いた時に開発を進める予定なので進捗はゆっくりになりそうです。
[TOP] [ 前へ ] 連載記事一覧 [ 次へ ]
| 入手した HD46B180ROP |
|
|
パッケージは 64 ピンのシュリンク DIP なので秋月さんからシュリンク DIP のソケットと 1.778mm ピッチの汎用基板を購入しました。
| HD64180 と汎用基板とソケット |
|
|
かなり前に 旧Twitter のタイムラインで HD64180 はハーフピッチの汎用基板に斜めに刺さるという情報を見た覚えがあります。しかし、今回購入した基板には逆に通常の DIP IC を斜めに刺すことができます。PIC を使って使用 IC 数を少なくすれば 大きな HD64180 をきれいに収めた方が作り易いと思ったからです。秋月さんでは通常ピッチとシュリンクピッチが縦横で混在している汎用基板も販売していますが最大でＣ基板サイズなので HD64180 を搭載するには残念ながら小さすぎます。
今回開発するワンボードを HD64180Compact と命名します。使用 IC 数を最小限にするように設計したいと考えていて、CPU 以外の IC としては SRAM と USB 機能を有した 20 ピンの PIC（PIC18F14K50）の３チップ構成にする予定です。以前に同様の構成でほぼ Z80 のチップサイズの CP/M が動くワンボードマイコンの Z80PicCompact を開発しましたが、今回は下記の課題についても対処したいと思います（まったく同じ仕掛けではつまらないですからね）。
- I/O の拡張性
Z80PicCompact では I/O 空間に PIC だけを配置していて、PIC はアドレスの A0 だけを見ており、コマンド／データのポートの識別に A0 を使っていたので I/O 空間に空きがなかった
- 割込み対応
Z80 は IORQ/ をアクティブにすると自動的に wait するようにしていたので割込み（Z80Compactでは未使用）時に wait してしまうので PIC が割込みの都度 wait を解除する必要がある
下表に Z80Compact での PIC のピンアサインを再掲します。
| Z80Compactのピンアサイン |
|
|
HD46180ROP には RTS0/ のような Z80 にはなかった出力ピンがあるので、これを PIC アクセス用のコントロール信号として利用することで PIC を I/O アクセスする時のみ、 IORQ/ で wait 状態になるようにします。
初めに考案したトランジスタを使った回路をシミュレータで検証してみました。CNT がコントロール信号です。
想定通り CNT が low の時は WAIT/ はマスクされ、CNT が high の時に IORQ/ により、WAIT/ がアクティブになります。しかし、WAIT/ の low レベルが 0.8V 程度であり、HD64180 の規格である 0.8V 以下に対してマージンがありません。
| トランジスタ案１ |
|
|
下図はベースとエミッタの抵抗を小さくした場合のシミュレーション結果です。今度は WAIT/ の low レベルは規格を満たせていますね。
| トランジスタ案２ |
|
|
別の案としてショットキーバリアダイオードを使った OR 回路構成の案もシミュレートしてみました。これも WAIT/ 信号の low レベルが高すぎますね。
| ショットキー案１ |
|
|
プルダウン抵抗の値を小さくしてシミュレートした結果が下図です。これなら行けそうですね。
| ショットキー案２ |
|
|
部品数から考えてまずはショットキー案２で行こうかと思います。PIC の RB7 が抵抗を介して R2 へ接続することになるかと思います。
今回はプライオリティを下げて気が向いた時に開発を進める予定なので進捗はゆっくりになりそうです。
[TOP] [ 前へ ] 連載記事一覧 [ 次へ ]
)
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}