Pic24ジェネラルボックスの作成 [PIC]
世間ではマイコンは32bit以上が主流になっていますが、私は未だに16bitのPIC24FJをメインに使っています。処理速度が適度に速くて低消費電力なことろが気に入っています。
また、PIC24ならば自作のセルフコンパイラであるpicle言語が動くのでスクリプト感覚でマシン語に近い速度の処理が容易にできることも(私にとって)PIC24を使用する上で大きなメリットになっています。
更に自作のPIC24用の世界最小(だと思います)のブートローダ(OneBitLoader)を完備しているのでPickit等の書込み器が必要になる場面もほとんどありません。
「I2Cロガーの製作」の記事で書いたようなPIC24が直ぐに動かせる状態のツールが手元にあると何かと便利です。
今月分のALLPCBさんの太っ腹クーポン(送料含めてプリント基板作成が只)で何を作ろうか考えた結果、汎用的に使えるPIC24の基板(Pic24GenBoxと命名)を作ることにしました。
下図に示すように回路は至って簡単な構成で、PIC24FJ64GA002の入出力ピンの殆どをコネクタに出すようにしました。また、USBシリアルインターフェースとして買い置きのあるPL2303SAを組み込むことで、USBケーブルを接続するだけで手軽に動かせるようにしました。基板のサイズは 66mm × 42mm です。
グランドベタ化前のパターンを下図に示します。部品数が少なく部品密度も高くないのですんなり作成できました。
「ロゴマークの検討」の記事で書いた自分専用のロゴも入れてみました。
グランドベタ化後のトップ面のパターンが下図になります。スペースもあるので使い易いようにコネクタピンに対応する信号名も書いてみました。コネクタ枠のシルクに文字が掛かっていますがLアングルのピンソケットを使用する予定なので信号名の文字は隠れないはずです。
LEDはリード付きのものを使用し、発光部の先端をケースの穴から出す予定です。
ボトム面はスペース的に余裕があるのでロゴのサイズを大きくしました。
USBコネクタの表示が変ですが3D表示も貼っておきます。CADはDesignSparkPCBを使用しています。3D表示の際の部品の高さの指定方法は、回路設計画面で部品のHeightプロパティを変更後、PCB設計画面で Forward Design Changes を実行すると変更できます。
PCB設計画面で部品プロパティを変更すると Back Annotation を実行して変更内容を回路設計側に反映する必要があります。
★追記 2021/10/29
ALLPCBさんにPCB製造を発注しました。発注と言っても無料クーポンを使ったので只ですが・・
ALLPCBさんのサイトが更新されていてクーポンを適用する方法が変わったので戸惑いました。以前はクーポン使用ボタンを押してPCB製造依頼画面に飛んでいたのですが、今回のサイト更新でクーポン使用ボタンは無くなり、PCB製造依頼すると自動的にクーポンが適用され製造費用が0円になりました。
PCB製造依頼での設定画面も貼っておきます。ほとんどの項目がディフォルトのままですが "mini Hole Soize" は 0.4mm に変更しました。
下の画面の "Related Results" 一覧の一番上の行の Prise 欄が Free になっていてクーポンが適用されていることが判ります。
"Order Now" のボンタンを押して送付先と業者の設定を Japan と DHL で指定し、"Add Cart" ボタンを押した後、最後に ガーバーファイルをアップロードしてオーダー完了です。
ガーバーファイル名はPCB製造依頼時の一般的な名称に変更すればOKです。
DesignSparkPCBの出力ファイル名とリネームファイル名の対応については「SuperSimpleController(その9)回路図とパターン設計」の記事の最後の部分を参照してください。
[TOP] >[ 前へ ] 連載記事 [ 次へ ]
また、PIC24ならば自作のセルフコンパイラであるpicle言語が動くのでスクリプト感覚でマシン語に近い速度の処理が容易にできることも(私にとって)PIC24を使用する上で大きなメリットになっています。
更に自作のPIC24用の世界最小(だと思います)のブートローダ(OneBitLoader)を完備しているのでPickit等の書込み器が必要になる場面もほとんどありません。
「I2Cロガーの製作」の記事で書いたようなPIC24が直ぐに動かせる状態のツールが手元にあると何かと便利です。
今月分のALLPCBさんの太っ腹クーポン(送料含めてプリント基板作成が只)で何を作ろうか考えた結果、汎用的に使えるPIC24の基板(Pic24GenBoxと命名)を作ることにしました。
下図に示すように回路は至って簡単な構成で、PIC24FJ64GA002の入出力ピンの殆どをコネクタに出すようにしました。また、USBシリアルインターフェースとして買い置きのあるPL2303SAを組み込むことで、USBケーブルを接続するだけで手軽に動かせるようにしました。基板のサイズは 66mm × 42mm です。
Pic24GenBoxの回路図 |
|
★変更 2021/11/12 Ver0.01a コンデンサと抵抗の値を微調整 |
グランドベタ化前のパターンを下図に示します。部品数が少なく部品密度も高くないのですんなり作成できました。
「ロゴマークの検討」の記事で書いた自分専用のロゴも入れてみました。
Pic24GenBoxのパターン(グランドベタ化前) |
|
グランドベタ化後のトップ面のパターンが下図になります。スペースもあるので使い易いようにコネクタピンに対応する信号名も書いてみました。コネクタ枠のシルクに文字が掛かっていますがLアングルのピンソケットを使用する予定なので信号名の文字は隠れないはずです。
LEDはリード付きのものを使用し、発光部の先端をケースの穴から出す予定です。
Pic24GenBoxのトップ面パターン(グランドベタ化後) |
|
ボトム面はスペース的に余裕があるのでロゴのサイズを大きくしました。
Pic24GenBoxのボトム面パターン(グランドベタ化後) |
|
USBコネクタの表示が変ですが3D表示も貼っておきます。CADはDesignSparkPCBを使用しています。3D表示の際の部品の高さの指定方法は、回路設計画面で部品のHeightプロパティを変更後、PCB設計画面で Forward Design Changes を実行すると変更できます。
PCB設計画面で部品プロパティを変更すると Back Annotation を実行して変更内容を回路設計側に反映する必要があります。
Pic24GenBoxk基板の3D表示 |
|
★追記 2021/10/29
ALLPCBさんにPCB製造を発注しました。発注と言っても無料クーポンを使ったので只ですが・・
ALLPCBさんのサイトが更新されていてクーポンを適用する方法が変わったので戸惑いました。以前はクーポン使用ボタンを押してPCB製造依頼画面に飛んでいたのですが、今回のサイト更新でクーポン使用ボタンは無くなり、PCB製造依頼すると自動的にクーポンが適用され製造費用が0円になりました。
PCB製造依頼での設定画面も貼っておきます。ほとんどの項目がディフォルトのままですが "mini Hole Soize" は 0.4mm に変更しました。
ALLPCBさんのPCB製造依頼画面1 |
|
下の画面の "Related Results" 一覧の一番上の行の Prise 欄が Free になっていてクーポンが適用されていることが判ります。
ALLPCBさんのPCB製造依頼画面2 |
|
"Order Now" のボンタンを押して送付先と業者の設定を Japan と DHL で指定し、"Add Cart" ボタンを押した後、最後に ガーバーファイルをアップロードしてオーダー完了です。
ガーバーファイル名はPCB製造依頼時の一般的な名称に変更すればOKです。
DesignSparkPCBの出力ファイル名とリネームファイル名の対応については「SuperSimpleController(その9)回路図とパターン設計」の記事の最後の部分を参照してください。
[TOP] >[ 前へ ] 連載記事 [ 次へ ]
モニターディスプレイの購入 [購入]
昨日(2021/10/18)、突然パソコンに繋いでいるモニタが表示しなくなりましたorz
電源をオンにできなかったり、オンになった場合でもメニュー表示が出ない等、どうやらモニタ内部のCPUがうまく動作していないようなので単純に電源が入らない場合よりも修理は難しそうです。
今まで使っていたパソコン環境が使えないとなると不便極まりない状態で、日常生活がどれだけパソコンに依存しているのか改めて実感させられました。
原因がモニタ側であることを確認後、すぐに予備的な環境であるノートPCを使ってAmazonで注文し、翌日に手元に届きました。
今回購入したものは27インチのBenQ GW2780(¥19.600)です。今まで LG の24インチモニタ(FLATRON W2442PA)を使っていたので表示が若干大きくなって目にやさしくなりました(表示部周辺の枠幅が極薄なので全体サイズはあまり変わらない)。
ドット落ちもなく流石にBenQと言ったところです(液晶ではなくLED式なのでドット落ちは生じにくい?)
かなり前に秋葉原で購入したLGのモニタは購入時にドット落ち対応のため、保険として千円程度追加で払った記憶があります。
LGのものにするか迷いましたが、LGはコメント欄が散々な内容だったので、無償保障対応面でマイナスコメントはありましたが評価値の高いBenQにしました(実はBenQ製品の購入は初めてです)
4K対応のものも結構安くなっていましたが、もう目の方の解像度が追い付かないのでフルHDで十分です。目も耳も高い周波数に対して感度が落ちてくるのはちょっと寂しいですが、日常生活において不便と感じることはあまりありません。
メガネをかけている人は家の中などでは眼鏡をはずした方が却ってストレスが貯まらないというようなことを聞いたことがあるので、感覚器官の感度が落ちることで寧ろ対ストレス性が高くなっているかもしれませんねw
スペックの概要も貼っておきます。
★追記 2021/10/21
Amazonでモニタを探していると製品比較表のディスプレイ方式で 液晶 と LED の二つのタイプが書かれています。
しかし、 LED と書かれている方は一般的にLEDディスプレイと呼ばれている方式のように表示ピクセル自体がLEDなのではなく、バックライトがLEDと言うことみたいです。
液晶 と書かれている方もバックライトはLEDの可能性もあり(おそらく今は殆どの液晶モニタのバックライトはLEDだと思います)、このディスプレイ方式はあまり気にしなくてもいいようです。
【参考リンク】
電源をオンにできなかったり、オンになった場合でもメニュー表示が出ない等、どうやらモニタ内部のCPUがうまく動作していないようなので単純に電源が入らない場合よりも修理は難しそうです。
今まで使っていたパソコン環境が使えないとなると不便極まりない状態で、日常生活がどれだけパソコンに依存しているのか改めて実感させられました。
原因がモニタ側であることを確認後、すぐに予備的な環境であるノートPCを使ってAmazonで注文し、翌日に手元に届きました。
今回購入したものは27インチのBenQ GW2780(¥19.600)です。今まで LG の24インチモニタ(FLATRON W2442PA)を使っていたので表示が若干大きくなって目にやさしくなりました(表示部周辺の枠幅が極薄なので全体サイズはあまり変わらない)。
ドット落ちもなく流石にBenQと言ったところです(液晶ではなくLED式なのでドット落ちは生じにくい?)
かなり前に秋葉原で購入したLGのモニタは購入時にドット落ち対応のため、保険として千円程度追加で払った記憶があります。
LGのものにするか迷いましたが、LGはコメント欄が散々な内容だったので、無償保障対応面でマイナスコメントはありましたが評価値の高いBenQにしました(実はBenQ製品の購入は初めてです)
4K対応のものも結構安くなっていましたが、もう目の方の解像度が追い付かないのでフルHDで十分です。目も耳も高い周波数に対して感度が落ちてくるのはちょっと寂しいですが、日常生活において不便と感じることはあまりありません。
メガネをかけている人は家の中などでは眼鏡をはずした方が却ってストレスが貯まらないというようなことを聞いたことがあるので、感覚器官の感度が落ちることで寧ろ対ストレス性が高くなっているかもしれませんねw
購入した27インチモニターディスプレイ GW2780 |
|
スペックの概要も貼っておきます。
項 目 | 仕 様 |
---|---|
本体サイズ | 612 x 463 x 183mm(W x H x D) |
本体重量 | 4.85kg |
モニターサイズ | 27インチ |
解像度 | 1920x1080 |
モニタータイプ | ワイド |
視野角 | (左右/上下) (CR>=10):178/178 |
輝度 | 250 |
コントラスト比 | 1000:1 |
応答速度 | 8ms、5ms(GtG) |
垂直走査周波数(Hz) | リフレッシュレート:60Hz |
インターフェイス | D-sub、HDMI 1.4、DisplayPort 1.2 |
高さ調節機能 | ティルト(上下):-5° - 20° |
対応VESA規格 | 100x100mm |
パネル種類 | IPSパネル |
ブルーライトカット機能 | 有 |
スピーカー機能 | 2 W x 2 |
壁掛け | 壁掛け対応 |
タッチパネル機能 | 非対応 |
入出力端子 | [オーディオ]ヘッドフォンジャック、Audio Line In |
消費電力 | 32 W |
付属品 | 電源 / HDMI (各約1.5m) |
★追記 2021/10/21
Amazonでモニタを探していると製品比較表のディスプレイ方式で 液晶 と LED の二つのタイプが書かれています。
しかし、 LED と書かれている方は一般的にLEDディスプレイと呼ばれている方式のように表示ピクセル自体がLEDなのではなく、バックライトがLEDと言うことみたいです。
液晶 と書かれている方もバックライトはLEDの可能性もあり(おそらく今は殆どの液晶モニタのバックライトはLEDだと思います)、このディスプレイ方式はあまり気にしなくてもいいようです。
【参考リンク】
ZSIDの制限とZ80のRレジスタ [Z80]
自作のZ80ボードであるZ80GALを使ってCP/M-80でZSIDを使用中に下記の操作ログに示すようにアセンブル機能でRレジスタの設定ができないことに気が付きました。
更にメモリ設定機能で "LD R,A" のマシンコードである ED 4F を設定し、逆アセンブルしてみるとRではなくIレジスタへのLD命令として表示されました。"LD A,R"についても同様でした。どうやらZSIDはRレジスタには対応していないようです。
因みにZSIDMはZSIDに1行ダンプ表示や小文字シンボル対応し、更にMSX-DOS対応のためにZSIDで使用するRSTをRST38からRST28へ変更したものです(Z80GALもRST38はボード側で使用しているので変更が必要)
詳細は「MSX-DOSに自作スクリーンエディタ移植」を参照してください。
何故、ZSIDでRレジスタを弄ろうとしていたかというとRレジスタのインクリメント条件に関して確かめてみたいことがあったからです。
始めにおさらいとして Z80 のフェッチサイクルを下図に示します。
Rレジスタは7bitカウンタでM1サイクル(オペコード フェッチ)毎にインクリメントされますが、プレフィックス付きの命令の場合、1命令で2回インクリメントされます。
つまりRレジスタの増分は
上記の疑問を確認するために下記のプログラムを作ってみました。
この確認試験に使っているZ80GALはシリアル通信のためにタイマー割込みを使っているので割込み処理の影響を無くすためにRレジスタ参照ループ内は割込み禁止にし、またシリアル通信の送信バッファを空にするためにプログラム先頭でwait処理を行っています。
ZSIDで実行した結果は下記のようになりました。
逆アセンブル部分の011Bと011Dのアドレスで'I'と表示されているのは前述のようにZSIDが'R'に対応していないためです。
メモリダンプの結果からRレジスタはループ内で +7 づつ増加しています。
"LD A,R"はプレフィックスが付いていてRレジスタが +2 になるので "BIT 0,(IX+0)" でRレジスタは +2 の値になるということになります。
その他、上記の結果から次のことが判ります。
★追記 2021/10/17 {
"LD R,A"実行後はRレジスタはAの値のままで"LD A,R"でRレジスタが+2された後の値がAにロードされているという考え方も成り立つがマシン語のフェッチと実行タイミングを考慮するとこれは考え辛い。上記のようにマシン語実行後リフレッシュ時にRレジスタがインクリメントされると推測する。
}
実際にM1/やRFSH/等の制御信号をロジアナで確認しようかとも思いましたが「レトロマイコンZ80ボードの構想(その10)CP/M80 BIOS検討2」のコメントに書いたサイトに命令実行時の制御信号状態のデータがあったことを思い出し、アクセスしてみたらURLが変更になっていました。新URLを確認できたのでリンクを貼っておきます。
これらのデータを見るとM1サイクル数=リフレッシュ回数であり、リフレッシュする毎にRレジスタがインクリメントされるということが良く判ります。
★追記 2022/05/02
Twitterで得た情報ですが Z80 の動作の詳細が記述されている a detailed look at Z80 instruction timings with the help of a Z80 netlist simulatio のリンクを貼っておきます。
★追記 2021/10/17
twitterで The Undocumented Z80 Documented の 6.1 R register and memory refresh にプリフィックスが2つの場合のRレジスタの増分について今回の調査結果と同様のことがかかれているとのコメントを頂きました。
同資料には
It is unclear whether the Z80 increases the R register before or after putting IR on the bus.
と書かれていますが、RESET_and_NOP.txt (リセット後最初の命令を実行開始するまでの動きを調査)を参照すると、リセットでRが0の状態の直後のNOPでのリフレッシュ時のアドレスが0なのでRレジスタのインクリメントタイミングはRをバス上に出力した後だということが判ります。
※上記のIRはIレジスタとRレジスタのペアのことでリフレッシュ中はIレジスタがアドレスバスの上位に出力されます。
★追記 2021/10/19
Web上で動作するMSXのエミュレータであるMSXPenでMSX-DOS環境を使って同様の確認を行ってみました。結果は下のキャプチャーのとおりで実機のZ-80と同様でした。
Rレジスタはゲーム等で簡易乱数として使われることもあるためかエミュレータなのに良く対応できているものですね。
更にメモリ設定機能で "LD R,A" のマシンコードである ED 4F を設定し、逆アセンブルしてみるとRではなくIレジスタへのLD命令として表示されました。"LD A,R"についても同様でした。どうやらZSIDはRレジスタには対応していないようです。
因みにZSIDMはZSIDに1行ダンプ表示や小文字シンボル対応し、更にMSX-DOS対応のためにZSIDで使用するRSTをRST38からRST28へ変更したものです(Z80GALもRST38はボード側で使用しているので変更が必要)
詳細は「MSX-DOSに自作スクリーンエディタ移植」を参照してください。
CP/M-80でのZSID操作ログ |
---|
a>zsidm ZSIDM Ver 1.4 #a 0100 LD I,A 0102 LD R,A ? 0102 NOP 0103 NOP 0104 . #l100,103 0100 LD I,A 0102 NOP 0103 NOP 0104 #s100 0100 ED 0101 47 0102 00 ED 0103 00 4F 0104 3D . #l100,103 0100 LD I,A 0102 LD I,A 0104 # |
何故、ZSIDでRレジスタを弄ろうとしていたかというとRレジスタのインクリメント条件に関して確かめてみたいことがあったからです。
始めにおさらいとして Z80 のフェッチサイクルを下図に示します。
Z80 Instruction Opecode Fetch |
※Zilog's Z80 Family Product Specifications Handbook から引用 |
Rレジスタは7bitカウンタでM1サイクル(オペコード フェッチ)毎にインクリメントされますが、プレフィックス付きの命令の場合、1命令で2回インクリメントされます。
つまりRレジスタの増分は
- "XOR A"(AF)等のプレフィックスのない通常の命令では+1
- "BIT 0,(HL)"(CB 46)や"LD (IX+0),A"(DD 77 00)等のプレフィックス付きの命令では+2
- "BIT 0,(IX+0)"(DD CB 00 46)を実行した場合のRレジスタの増分は?
上記の疑問を確認するために下記のプログラムを作ってみました。
この確認試験に使っているZ80GALはシリアル通信のためにタイマー割込みを使っているので割込み処理の影響を無くすためにRレジスタ参照ループ内は割込み禁止にし、またシリアル通信の送信バッファを空にするためにプログラム先頭でwait処理を行っています。
Rレジスタカウントアップ確認プログラム |
---|
;+++++++++++++++++++++++++++++++++++++++ ; test refresh register ; Ver 0.01 2021/10/16 by skyriver ;+++++++++++++++++++++++++++++++++++++++ 1000 BUFADR1 EQU 1000H 2000 BUFADR2 EQU 2000H .Z80 0000' ASEG ORG 0100H 0100 START: 0100 01 0000 LD BC,0 0103 WAIT: ; to be empty serial buf 0103 10 FE DJNZ WAIT 0105 0D DEC C 0106 20 FB JR NZ,WAIT 0108 AF XOR A 0109 21 1000 LD HL,BUFADR1 010C CD 0118 CALL REFTEST 010F 3E 80 LD A,80H 0111 21 2000 LD HL,BUFADR2 0114 CD 0118 CALL REFTEST 0117 C9 RET 0118 REFTEST: 0118 F3 DI 0119 06 00 LD B,0 011B ED 4F LD R,A 011D ED 5F LOOP: LD A,R 011F 77 LD (HL),A 0120 DD CB 00 46 BIT 0,(IX+0) 0124 23 INC HL 0125 10 F6 DJNZ LOOP 0127 FB EI 0128 C9 RET END |
ZSIDで実行した結果は下記のようになりました。
逆アセンブル部分の011Bと011Dのアドレスで'I'と表示されているのは前述のようにZSIDが'R'に対応していないためです。
確認プログラムの実行結果 |
---|
b>a:zsidm rregtest.com ZSIDM Ver 1.4 NEXT PC END 0180 0100 C1FF #l100,128 0100 LD BC,0000 0103 DJNZ FE 0105 DEC C 0106 JR NZ,FB 0108 XOR A 0109 LD HL,1000 010C CALL 0118 010F LD A,80 0111 LD HL,2000 0114 CALL 0118 0117 RET 0118 DI 0119 LD B,00 011B LD I,A 011D LD A,I 011F LD (HL),A 0120 BIT 0,(IX+00H) 0124 INC HL 0125 DJNZ F6 0127 EI 0128 RET 0129 #g100,117 *0117 #d1000 1000: 02 09 10 17 1E 25 2C 33 3A 41 48 4F 56 5D 64 6B .....%,3:AHOV]dk 1010: 72 79 00 07 0E 15 1C 23 2A 31 38 3F 46 4D 54 5B ry.....#*18?FMT[ 1020: 62 69 70 77 7E 05 0C 13 1A 21 28 2F 36 3D 44 4B bipw~....!(/6=DK 1030: 52 59 60 67 6E 75 7C 03 0A 11 18 1F 26 2D 34 3B RY`gnu|.....&-4; 1040: 42 49 50 57 5E 65 6C 73 7A 01 08 0F 16 1D 24 2B BIPW^elsz.....$+ 1050: 32 39 40 47 4E 55 5C 63 6A 71 78 7F 06 0D 14 1B 29@GNU\cjqx..... 1060: 22 29 30 37 3E 45 4C 53 5A 61 68 6F 76 7D 04 0B ")07>ELSZahov}.. 1070: 12 19 20 27 2E 35 3C 43 4A 51 58 5F 66 6D 74 7B .. '.5<CJQX_fmt{ 1080: 02 09 10 17 1E 25 2C 33 3A 41 48 4F 56 5D 64 6B .....%,3:AHOV]dk 1090: 72 79 00 07 0E 15 1C 23 2A 31 38 3F 46 4D 54 5B ry.....#*18?FMT[ 10A0: 62 69 70 77 7E 05 0C 13 1A 21 28 2F 36 3D 44 4B bipw~....!(/6=DK #d2000 2000: 82 89 90 97 9E A5 AC B3 BA C1 C8 CF D6 DD E4 EB ................ 2010: F2 F9 80 87 8E 95 9C A3 AA B1 B8 BF C6 CD D4 DB ................ 2020: E2 E9 F0 F7 FE 85 8C 93 9A A1 A8 AF B6 BD C4 CB ................ 2030: D2 D9 E0 E7 EE F5 FC 83 8A 91 98 9F A6 AD B4 BB ................ 2040: C2 C9 D0 D7 DE E5 EC F3 FA 81 88 8F 96 9D A4 AB ................ 2050: B2 B9 C0 C7 CE D5 DC E3 EA F1 F8 FF 86 8D 94 9B ................ 2060: A2 A9 B0 B7 BE C5 CC D3 DA E1 E8 EF F6 FD 84 8B ................ 2070: 92 99 A0 A7 AE B5 BC C3 CA D1 D8 DF E6 ED F4 FB ................ 2080: 82 89 90 97 9E A5 AC B3 BA C1 C8 CF D6 DD E4 EB ................ 2090: F2 F9 80 87 8E 95 9C A3 AA B1 B8 BF C6 CD D4 DB ................ 20A0: E2 E9 F0 F7 FE 85 8C 93 9A A1 A8 AF B6 BD C4 CB ................ # |
メモリダンプの結果からRレジスタはループ内で +7 づつ増加しています。
"LD A,R"はプレフィックスが付いていてRレジスタが +2 になるので "BIT 0,(IX+0)" でRレジスタは +2 の値になるということになります。
LOOP: LD A,R ; +2 LD (HL),A ; +1 BIT 0,(IX+0) ; +2 INC HL ; +1 DJNZ LOOP ; +1 |
その他、上記の結果から次のことが判ります。
- RレジスタのMSBは設定値が保持される
- ダンプの最初の値が02なので"LD R,A"実行後のRレジスタはA+1の値になる(プレフィックスでの+1は上書きされる)
- 同様に"LD A,R"ではこの命令でRレジスタが+1された値がAレジスタに設定される(命令実行後は+2となる)
★追記 2021/10/17 {
"LD R,A"実行後はRレジスタはAの値のままで"LD A,R"でRレジスタが+2された後の値がAにロードされているという考え方も成り立つがマシン語のフェッチと実行タイミングを考慮するとこれは考え辛い。上記のようにマシン語実行後リフレッシュ時にRレジスタがインクリメントされると推測する。
}
実際にM1/やRFSH/等の制御信号をロジアナで確認しようかとも思いましたが「レトロマイコンZ80ボードの構想(その10)CP/M80 BIOS検討2」のコメントに書いたサイトに命令実行時の制御信号状態のデータがあったことを思い出し、アクセスしてみたらURLが変更になっていました。新URLを確認できたのでリンクを貼っておきます。
これらのデータを見るとM1サイクル数=リフレッシュ回数であり、リフレッシュする毎にRレジスタがインクリメントされるということが良く判ります。
★追記 2022/05/02
Twitterで得た情報ですが Z80 の動作の詳細が記述されている a detailed look at Z80 instruction timings with the help of a Z80 netlist simulatio のリンクを貼っておきます。
★追記 2021/10/17
twitterで The Undocumented Z80 Documented の 6.1 R register and memory refresh にプリフィックスが2つの場合のRレジスタの増分について今回の調査結果と同様のことがかかれているとのコメントを頂きました。
同資料には
It is unclear whether the Z80 increases the R register before or after putting IR on the bus.
と書かれていますが、RESET_and_NOP.txt (リセット後最初の命令を実行開始するまでの動きを調査)を参照すると、リセットでRが0の状態の直後のNOPでのリフレッシュ時のアドレスが0なのでRレジスタのインクリメントタイミングはRをバス上に出力した後だということが判ります。
※上記のIRはIレジスタとRレジスタのペアのことでリフレッシュ中はIレジスタがアドレスバスの上位に出力されます。
★追記 2021/10/19
Web上で動作するMSXのエミュレータであるMSXPenでMSX-DOS環境を使って同様の確認を行ってみました。結果は下のキャプチャーのとおりで実機のZ-80と同様でした。
Rレジスタはゲーム等で簡易乱数として使われることもあるためかエミュレータなのに良く対応できているものですね。
MSXPenでのRレジスタ確認プログラム実行結果 |
|
BASICでのhex文字toバイナリ変換テクニック [その他]
twitterのTLにBASICで16進文字を2進数4文字へ変換するテクニックとして
という手法が懐かしさを込めて紹介されていました。
更に、awkを使って検証した結果も紹介されていました。ブログへのツイートの埋め込みは著作権上問題が無いようなので判り易いように該当ツイートを貼らさせて頂きます。
★変更 2021/10/06
ツイート埋め込みではなくリンクに変更
https://twitter.com/houmei/status/1444776993673957382
このような探索系の問題は興味をそそられますね。
少し考えてみると 0..F の16個の文字の順列問題のように思えます。perlであればMath::Combinatoricsを使えば順列問題を解けますが、並べる初期段階でも今回の問題の答えとして大丈夫なのかチェックすることで探索範囲を枝刈りするために再起呼び出しにより自前で順列処理するようにしました。
作成したperlのソースは下記になります。Search()内でデータチェックしつつ再起呼び出しで順列を作っています。
★変更 2021/10/06
Ver 0.02 変換元及び変換先を変更可能とし、若干高速化したバージョンにソースを差換え
★変更 2021/10/07
Ver 0.03a 最適化して高速化 32進数 ⇒ 2進数 の処理の実行時間が 22.1sec ⇒ 5.4sec
★変更 2021/10/08
Ver 0.03b 若干高速化 32進数 ⇒ 2進数 の処理の実行時間が 5.4sec ⇒ 4.6sec
★変更 2021/10/08
Ver 0.03c 15進数の場合等でエラーが発生するようになったので修正。実行時間: 4.7sec
出力結果は下記のように256通りのデータペアが検出されました。
因みに上記ソースの$MaxLenを16から8に変更すると下記のような8進数用の変換データが出力されます。
★追記 2021/10/04
$MaxLenを4に変更して調べてみると下記のように4通りのデータペアが検出されました。
このことからN進数のバイナリ変換用データペア数は 2^(N/2) と推測されますが、これを証明するのはかなり難しいと思われます。
数学での新たな難問として「N進数バイナリ変換データペア数予想」を提案させていただきますw
同様に16進数から4進数への変換の場合の検証結果も貼っておきます。データベア数は
331776 = (2^12)*(3^4)
になっています。一見すると不思議な数字ですが、先に書いた4進数から4進数への変換は4文字の順列であったことを加味して考えると、規則性が見えてきます。
つまり、変換データペア数の算出には順列計算(階乗)が関連していて、N進数からM進数への変換の場合の変換データペア数は
( M! ) ^ ( N / M )
となり、更に一般化した「N進数からM進数への変換データペア数予想」へ展開できました。最初の頃は予想の式内に '2' というマジックナンバーが何故でてくるのか気になっていましたが、今回の一般化でマジックナンバーはなくなり、簡潔で美しい式になりました。
★追記 2021/10/05
素因数分解はWindowsの電卓を使って手作業でやっていましたがweb上で高速に素因数分解できるサイトがあったのでリンクを貼っておきます。
★追記 2021/10/06
9進数から3進数への変換の場合のデータペア数を確認してみた結果を下記に示します。
予想通り 216 = ( 3! ) ^ ( 9 / 3 ) でした。
また、10進数から2進数や6進数から3進数への変換の場合は解がありませんでした。変換元の最大値を変換先進数に変換後、+1すると桁数が増える場合、つまり
N=M^L L:自然数
の時だけ解がある本予想が成立するものと推測されます。★訂正 2021/10/06
★追記 2021/10/06
変換元として2進数から16進数までを2進数に変換する場合のデータペア数を確認しましたので追記します。
★追記 2021/10/08 17~33を追加
★追記 2021/11/09
27進数から3進数への変換に関するTwiiterに投函したメッセージを貼っておきます。
P=INSTR("36DA5B7FEC924801", H$) |
B$=MID$("0011010111100100001", P, 4) |
という手法が懐かしさを込めて紹介されていました。
更に、awkを使って検証した結果も紹介されていました。ブログへのツイートの埋め込みは著作権上問題が無いようなので
★変更 2021/10/06
ツイート埋め込みではなくリンクに変更
https://twitter.com/houmei/status/1444776993673957382
このような探索系の問題は興味をそそられますね。
少し考えてみると 0..F の16個の文字の順列問題のように思えます。perlであればMath::Combinatoricsを使えば順列問題を解けますが、並べる初期段階でも今回の問題の答えとして大丈夫なのかチェックすることで探索範囲を枝刈りするために再起呼び出しにより自前で順列処理するようにしました。
作成したperlのソースは下記になります。Search()内でデータチェックしつつ再起呼び出しで順列を作っています。
変換用データ生成プログラム(perl) |
|
★変更 2021/10/06
Ver 0.02 変換元及び変換先を変更可能とし、若干高速化したバージョンにソースを差換え
★変更 2021/10/07
Ver 0.03a 最適化して高速化 32進数 ⇒ 2進数 の処理の実行時間が 22.1sec ⇒ 5.4sec
★変更 2021/10/08
Ver 0.03b 若干高速化 32進数 ⇒ 2進数 の処理の実行時間が 5.4sec ⇒ 4.6sec
★変更 2021/10/08
Ver 0.03c 15進数の場合等でエラーが発生するようになったので修正。実行時間: 4.7sec
出力結果は下記のように256通りのデータペアが検出されました。
変換用データ生成プログラムの実行結果 |
|
因みに上記ソースの$MaxLenを16から8に変更すると下記のような8進数用の変換データが出力されます。
8進数の変換用データの出力結果 |
|
★追記 2021/10/04
$MaxLenを4に変更して調べてみると下記のように4通りのデータペアが検出されました。
このことからN進数のバイナリ変換用データペア数は 2^(N/2) と推測されますが、これを証明するのはかなり難しいと思われます。
数学での新たな難問として「N進数バイナリ変換データペア数予想」を提案させていただきますw
4進数の変換用データの出力結果 |
|
★追記 2021/10/05
32進数の場合について確かめてみました。16以降の表現は16進数を踏襲して'G'から'V'までのアルファベットを割り振っています。
「N進数バイナリ変換データペア数予想」では 65536(=2^(32/2) 通りのデータペアがあるはずですが結果は下記の通り、予想と一致していました。
32進数の場合について確かめてみました。16以降の表現は16進数を踏襲して'G'から'V'までのアルファベットを割り振っています。
「N進数バイナリ変換データペア数予想」では 65536(=2^(32/2) 通りのデータペアがあるはずですが結果は下記の通り、予想と一致していました。
32進数の変換用データの出力結果 |
|
★追記 2021/10/05
今まで変換先を2進数とした場合についてのみ考えてきましたがM進数への変換を考えてみました。
4進数から4進数への変換を検証すると下記のように24通りのデータペアが出力されました。よく見てみると(考えて見れば当然ですが)0..3の4文字の順列になっていることが判ります。
今まで変換先を2進数とした場合についてのみ考えてきましたがM進数への変換を考えてみました。
4進数から4進数への変換を検証すると下記のように24通りのデータペアが出力されました。よく見てみると(考えて見れば当然ですが)0..3の4文字の順列になっていることが判ります。
4進数から4進数への変換用データの出力結果 |
|
同様に16進数から4進数への変換の場合の検証結果も貼っておきます。データベア数は
331776 = (2^12)*(3^4)
になっています。一見すると不思議な数字ですが、先に書いた4進数から4進数への変換は4文字の順列であったことを加味して考えると、規則性が見えてきます。
つまり、変換データペア数の算出には順列計算(階乗)が関連していて、N進数からM進数への変換の場合の変換データペア数は
( M! ) ^ ( N / M )
となり、更に一般化した「N進数からM進数への変換データペア数予想」へ展開できました。最初の頃は予想の式内に '2' というマジックナンバーが何故でてくるのか気になっていましたが、今回の一般化でマジックナンバーはなくなり、簡潔で美しい式になりました。
16進数から4進数への変換用データの出力結果 |
|
★追記 2021/10/05
素因数分解はWindowsの電卓を使って手作業でやっていましたがweb上で高速に素因数分解できるサイトがあったのでリンクを貼っておきます。
★追記 2021/10/06
9進数から3進数への変換の場合のデータペア数を確認してみた結果を下記に示します。
予想通り 216 = ( 3! ) ^ ( 9 / 3 ) でした。
また、10進数から2進数や6進数から3進数への変換の場合は解がありませんでした。変換元の最大値を変換先進数に変換後、+1すると桁数が増える場合、つまり
N=M^L L:自然数
の時だけ
9進数から3進数への変換用データの出力結果 |
|
★追記 2021/10/06
変換元として2進数から16進数までを2進数に変換する場合のデータペア数を確認しましたので追記します。
★追記 2021/10/08 17~33を追加
|
|
★追記 2021/11/09
27進数から3進数への変換に関するTwiiterに投函したメッセージを貼っておきます。
27進数から3進数への変換用データペア数のオレオレ予想では
— skyriver (@wcinp) October 9, 2021
10077696 = (3!)^(27/3)
プログラムで検証した結果、最後のデータは
No.10077696
QPNHOK7MEGLB6J5FI14DCA39028
22212202112102012001110100022
流石に結構時間が掛かった