SuperSimpleController(その11)HexLoaderの制作 [OriginalCPU]
前回の記事でシリアル通信ができたことを書きましたが、たまに文字化けが発生する状態でした。
今回開発しているSimple8Z側の問題なのか調査したところ、PICで生成しているSIO(MC6850)用のクロック精度が悪いことが原因だということが判ったのでPIC内蔵クロックから外付けの8MHzクリスタルに変更したところシリアル通信が安定しました。
PICのソースも変更したので貼っておきます。
今回の自作CPU(Simple8Z)には割込み機能は無いので連続した受信データ(9600bsp)の処理は難しいですが、TeraTermの設定でキャラクタ間に時間を設けてやれば処理できるはずです(TeraTermの設定は5ms/char、20ms/lineにしました)。Simple8Zのクロックも1MHzに上げてみました(上限はもっと高いと思う)。
★2021/04/03 追記 {
不安定だった原因はJP関連の命令でクリティカルなタイミングがあったためでuCODEを見直したことで安定になりました。1MHzのクロックで動作時にTeraTermの設定が9600bpsで文字毎のウェイト無し(0ms/char)でも取りこぼしが発生しない状態になりました。また、シリアル通信用クロックもPIC内部発信で154.6KHz(=9600x16)付近のクロックを生成することで文字化けもなくなりました。
}
今後の作業のことも考慮して、まずはヘキサファイルのローダーを作成してみました。前回の記事にマシン語コード表を書きましたが一通りのマシン語を実装したつもりなので、現状のマシン語セットである程度の規模の処理を記述できるかの確認の意味もあります。
ジャンプ命令でR1レジスタが壊れる等、癖がありますが結果としては何とかできました。メモリ上のワーク領域にある2バイトのアドレスデータの示すメモリにレジスタの内容を書込む処理ができなかったので、ワーク領域の直前にWR_RO命令のオペコードを書いてそこをコールするという方法で対応しましたw
作成したHexLoaderのリストは下記になります。処理内容としては「Z80GALの構想(その4)簡易モニタの製作」の記事に書いたHexファイルローダーとほぼ同様で、この時はZ80で約120バイトでしたが、今回は約290バイトなので2倍以上のサイズになってしまいました(但し、今回は自動実行の処理を追加している)。
Simple8Zはレジスタ数が少ない(R0,R1の2個)のでメモリアクセスが多くなることがサイズが大きくなった主な原因だと思います。
HexLoader試験のために作成したテストプログラムはHelloを表示する単純なものです。
上記の試験用プログラムをアセンブル&リンクすることで下記のヘキサファイルが生成されます。
今回作成したHexLoaderはhexFileを1行読む度にレコードタイプを表示するようにしているのでデータ行数分'0'を表示後、終了レコードのレコードタイプである'1'を表示し、ロードしたアプリケーションを実行します。この時の実行アドレスは先頭のデータ行のアドレスにしています。
HexLoaderを起動し、上記の試験用プログラムのHexFileをロードしている様子が下図の画面キャプチャーです。
★追記 2021/03/25
Twitterにポストした動画付きメッセージを貼っておきます。
[TOP] [ 前へ ] 連載記事 [ 次へ ]
今回開発しているSimple8Z側の問題なのか調査したところ、PICで生成しているSIO(MC6850)用のクロック精度が悪いことが原因だということが判ったのでPIC内蔵クロックから外付けの8MHzクリスタルに変更したところシリアル通信が安定しました。
PICのソースも変更したので貼っておきます。
8MHzクリスタルでの9.6KHz生成ソース(PIC12F683) |
|
今回の自作CPU(Simple8Z)には割込み機能は無いので連続した受信データ(9600bsp)の処理は難しいですが、TeraTermの設定でキャラクタ間に時間を設けてやれば処理できるはずです(TeraTermの設定は5ms/char、20ms/lineにしました)。Simple8Zのクロックも1MHzに上げてみました(上限はもっと高いと思う)。
★2021/04/03 追記 {
不安定だった原因はJP関連の命令でクリティカルなタイミングがあったためでuCODEを見直したことで安定になりました。1MHzのクロックで動作時にTeraTermの設定が9600bpsで文字毎のウェイト無し(0ms/char)でも取りこぼしが発生しない状態になりました。また、シリアル通信用クロックもPIC内部発信で154.6KHz(=9600x16)付近のクロックを生成することで文字化けもなくなりました。
}
今後の作業のことも考慮して、まずはヘキサファイルのローダーを作成してみました。前回の記事にマシン語コード表を書きましたが一通りのマシン語を実装したつもりなので、現状のマシン語セットである程度の規模の処理を記述できるかの確認の意味もあります。
ジャンプ命令でR1レジスタが壊れる等、癖がありますが結果としては何とかできました。メモリ上のワーク領域にある2バイトのアドレスデータの示すメモリにレジスタの内容を書込む処理ができなかったので、ワーク領域の直前にWR_RO命令のオペコードを書いてそこをコールするという方法で対応しましたw
作成したHexLoaderのリストは下記になります。処理内容としては「Z80GALの構想(その4)簡易モニタの製作」の記事に書いたHexファイルローダーとほぼ同様で、この時はZ80で約120バイトでしたが、今回は約290バイトなので2倍以上のサイズになってしまいました(但し、今回は自動実行の処理を追加している)。
Simple8Zはレジスタ数が少ない(R0,R1の2個)のでメモリアクセスが多くなることがサイズが大きくなった主な原因だと思います。
作成したSimple8Z用HexLoaderのソース(アセンブリ言語) |
|
HexLoader試験のために作成したテストプログラムはHelloを表示する単純なものです。
ローダー試験用プログラム |
|
上記の試験用プログラムをアセンブル&リンクすることで下記のヘキサファイルが生成されます。
試験用プログラムのアセンブル&リンクで得られたヘキサファイル |
:2080000010255034806034803D50348080804F2FC31380FFB01980C004804098C03A3A2F37 :15802000C5198090C1E048656C6C6F2C776F726C640D0A00005D :00000001FF |
今回作成したHexLoaderはhexFileを1行読む度にレコードタイプを表示するようにしているのでデータ行数分'0'を表示後、終了レコードのレコードタイプである'1'を表示し、ロードしたアプリケーションを実行します。この時の実行アドレスは先頭のデータ行のアドレスにしています。
HexLoaderを起動し、上記の試験用プログラムのHexFileをロードしている様子が下図の画面キャプチャーです。
HexLoader実行画面例 |
|
★追記 2021/03/25
Twitterにポストした動画付きメッセージを貼っておきます。
ROMとGALを使ったオリジナルCPUを検討中
— skyriver (@wcinp) March 25, 2021
MC6850を接続してシリアル通信ができるようになったのでヘキサファイルのローダーを作成しました
これでアセンブルしたAPのロード作業が楽になり、いよいよCPUらしくなってきた^^https://t.co/lb2uduYhmj#Simple8Z #オリジナルCPU pic.twitter.com/6A4AjXq71B
[TOP] [ 前へ ] 連載記事 [ 次へ ]