TL866II Plus用VPP:21V/25V対応アダプタの製作（その３）2732の書込み問題

　多機能なロムライター（TL866II Plus）での旧 ROM（Vpp電圧が 21V 以上）対応関連の情報をネットで見ていると 2732 への書込みに問題があるという情報が見つかります。

　この問題についての情報が豊富な 2732 will not program TL866ii plus のフォーラムでは

1. 書込み中（Vpp=18V）に CE/（18 ピン）が ハイレベルになり、ROM への書き込みが失敗する
   
2. この問題を回避するために CE/（18 ピン）と GND（12 ピン）を外部結線した状態で書込むことで ROM への書込みが成功する
   
3. 旧タイプのロムライタである TL866A ではこの問題は発生しない
   
4. TL866II Plus と TL866A の ROM 書込み時の Vpp と CE/ の波形比較も掲載されている
   
5. TL866 用のソフトウェアのブランチ開発での ROM タイプに関するパラメータが提示されていてこの中の protocol_id で書込み時のシーケンスが決まる
   

と言うようなことが書かれています。

　この 2732 問題に関しては上記のフォーラムの参加者が TL866 の開発元のフォーラムに Issue with programming 2732 eprom due to incorrect logic の表題で問題報告とソフトウェアでの対応を要求しています（2022-5-27 に最新版でも同様の問題が発生することも報告済み）。

　参考として NEC の uPD2732 と uPD2716 のプログラム時のシーケンス図を貼っておきます。

uPD2732 の書込みシーケンス

uPD2716 の書込みシーケンス

　上記フォーラムでは 2716 は書込み中に CE/ はハイレベルのパルスが必要で 2732 はローレベルのパルスが必要であるけれど、TL866II Plus のソフトに移行する際に 2732 用のシーケンスが 2716 のもののままになってしまったのではないかとも書かれています。

　この情報を基に少し調査してみました。以降は今回行った独自調査の内容になります。また、調査対象のソフトのバージョンは現時点で最新の Ver. 12.01 です。

　最初に、上記フォーラムにあったROM パラメータの情報がどこにあるかの特定です。ROM ライタのプログラムがあるフォルダを見渡すとある程度のサイズ（6.6MB）があるファイルとして InfoIC2Plus.dll がありました。ファイル名もそれっぽい感じですね。

　ダンプ表示してみるとROM 名称を含むパラメータのテーブルがありました。比較のために 2732 問題が発生しない TL866A 用のソフトもダウンロード＆解凍し、対応する DLL ファイルもダンプしてみました。

TL866II Plus の InfoIC2Plus.dll 内 ROM パラメータテーブル（抜粋）

TL866A の InfoIC.dlll 内 ROM パラメータテーブル（抜粋）

　この中から protocol_id を特定したいのですが、上記フォーラムの情報から

• TL866II Plus では 2716 と 2732 で同じ値である
• TL866A では 2716 と 2732 で異なる値である

と言う条件で探してみました。上図のダンプで赤マークが 2716 と 2732 で異なる値のパラメータです。上記の条件に該当するのは TL866II Plus 側では黄色でマークした 0x0B が protocol_id と言うことになりそうです。TL866A では 0x38 と 0x31 がそれぞれ 2716 と　2732 用の protocol_id のようです。

　次に TL866II Plus で 2732 に対応する protocol_id を決定するために TL866A で 0x31 の protocol_id を使用している他の ROM を探してみました。例えば下図の ST2764A のテーブル内のカーソル部になります。

TL866A で protocol_id が 0x31 のパラメータ例

　下図から対応する TL866II Plus の protocol_id は 0x07 であることが判ります。

TL866II Plus での対応する protocol_id 値

　以上から TL866II Plus の 2732 問題に対しては 2732 のパラメータテーブル内の protocol_id を0x07 に変更すれば解決するのではないかという期待が湧いてきます。
　試しに Intel の 2732 のパラメータを覗いてみると下図のようになっていました。

TL866II Plus の Intel 2732 のパラメータ

　あれ、2732 の protocol_id は 0x0b ですが、2732A の protocol_id は既に 0x07 になっていますね。それならば 2732A で書込んだ時には 2732 問題 は発生しないのでしょうか？

　まずはディバイスを Intel 2732 で選択して書込み時の波形を確認してみました。ch1（黄色）が Vpp でch2（水色）が CE/ の波形です。

TL866II Plus での 2732 書込み時の波形

　2732 問題が発生している状態（Vpp が 18V の時、CE/ が high）ですね。
　次に 2732A を選択して書き込んだ際の波形が下図になります。ch と信号の対応は上図と同じです。

TL866II Plus での 2732A 書込み時の波形

　うっ、2732 と全く同じですね ^^;
　 protocol_id が 0x07 でも 2732 問題が発生するという結果になりました orz
　結論としては ROM 毎のパラメータが原因ではなく、protocol_id 0x07 の実装自体に問題があるということになるかと思います。

　念のために CMOS 版の NMC27C32B の書込み時の波形を確認して見ました。

TL866II Plus での NMC27C32B 書込み時の波形

　Vpp （黄色） が high の時に CE/ （水色）も High になり 2732 問題が発生しています。物が無いので試せてはいませんが TL866II Plus では Vpp 電圧が 18V 以下の CMOS版の 2732 でも書き込みができないということのようです。

　参考としてデータシートに載っている MNC27C32B の書込み時のシーケンスも貼っておきます。

MNC27C32B の書込み時のシーケンス

【 最後に】
　対応ディバイスが 15000 程度あり、ソフトウェア開発は想像以上に大変なのでしょうが、対応を謳っているディバイスが書込めないというのは日本製では考えられないことです。せめてユーザー側でもっとフレキシブルにシーケンスの変更／追加が出来るようにしてくれたらなぁと思います。
　製品情報の守秘と言う点ではあまり公開したくないかもしれませんが（でも既に回路図やVppを上昇させる内部基板の改造方法等がネットに上がっている）ソフトウェアのメンテ工数の削減という点では上記のことは有効なのではないかと思います（製品価値も上がると思います）


★追記　2022/07/02
　ST の M2732A を入手できたので確認結果を追記します。
　結論から先に書くと TL866II Plus で Vpp の外部注入や CE/ の強制 low を行わなくても書込みができベリファイも通りました。
　書込み時の Vpp（仕様では 21V で TL866 では 18V で設定されている） と CE/ の波形を下図に示します。ch1（黄色）が Vpp で ch2（水色）が CE/ です。

ST M2732A 書込み時音の Vpp と CE/ 信号

　上図の波形を見る限りでは Vpp onの時に CE/ が High であり 2732 問題が発生している状態です。下図にデータシートに記載されている書込みシーケンスを貼りました。一部赤書きで仕様時間を記入しましたが、ライト時の CE/ パルス幅は 最小値でも 45ms になっていますが上図のシンクロで観測した信号を見てみると CE/ のパルス自体が無いのですが、Vpp のパルス幅でも 600us 程度ですので仕様を全く満たしていません。

ST M2732A の書込みシーケンス

　書込み後の TL866II Plus の画面が下図で書込み自体は 9 秒程度で完了しており、容量の 8K バイトから逆算すると 1 バイト当たり 1ms 程度で完了していることになり（画面にある通りブランクスキップは実施していない）、上記のシンクロでの観測結果と一致します。

ST M2732A の書込み後の画面表示

　個体差がある可能性もありますが、今回の確認結果として ST M2732A への書込み＆ベリファイ動作は正常に完了するが、実際の波形では 2732 問題が発生している状態であることから

• ST M2732 は書込み時に CE/ が High でも書込み可能である（らしい）
  
• 仕様上のライトパルス幅の 1/100 程度の Vpp パルスでも書き込みが可能である

と言うことになり、デバイス側のこれらの仕様外の動作が今回の 2732 問題を混乱させる一因になっているように思います。


★追記　2022/09/01
　TL866II Plus の現時点での最新のソフトウェア（Ver12.15）で 2732 問題の対応を確認してみました。結果は下図（ch1（黄色）がVpp、ch2（水色）が CE/ ）のように Vpp が 18V の時に CE/ が high レベルであり、2732 問題の対応はなされていませんでした。

Ver12.15 での 2732 問題（改善無し）

[TOP] [ 前へ ] 連載記事 [ 次へ ]

タグ：TL866II Plus Vpp変換 VppAdaputer TL866 TL866CS Vpp変換アダプタ 旧ROM対応 UV-EPROM

TL866II Plus用VPP:21V/25V対応アダプタの製作（その２）パターン設計

　前回の記事で基本的な確認は取れたので下図のように回路図を整理しました。
　前回のシミュレーション回路では 2SA1015/2SC1815 を使っていましたが、ほぼ同じ特性の表面実装タイプのトランジスタ （2SA1162/2SC2712）を使い全体的に表面実装部品を多用しました。また、昇圧用 IC の電流制限部の抵抗値はデータシートに掲載されている回路の値である 0.22 Ωはセメント抵抗などの大きなサイズのものしか見当たらなかったため、手持ちの１Ω 1/4W の抵抗を2個パラ付けにする（電流制限値がサンプル回路の約 1/2 になる）ようにしました。外部電源は スマホ用バッテリーを想定し、USB mini-B コネクタで受けるようにしています。

VppAdaputer の回路図

★追記　2022/07/03　{
　2732 問題をハードで対応するために回路を更新しました。詳細はこちらを参照してください。
}
　下図はグランドベタ化前のパターン図です。表面実装部品をボトム面に実装することで基板サイズを小型化しました。右上の USB コネクタと昇圧回路部分のパターンが結構込み合っています。金属のコネクタの下側にはビアを打たない方がいいようなのですが、今回は小型化のためにビア打ちは勿論、コネクタ固定用のホールの裏側まで使っています。

VppAdaputer 基板のパターン図（グランドベタ化前）

　下図がトップ面のパターン図です。左上の黄色い枠が 3M TEXTOOL の ZIF ソケットを実装した場合にソケットの占める面積になります。
　5V から昇圧した 21V/25V 用の平滑コンデンサは手持ちの SMD 部品では電圧上限が足りなかったので電解コンデンサを使っています。

VppAdaputer 基板のパターン図（トップ面）

　下図がボトム面のパターン図です。ROM ソケットの裏側に SMD 部品を実装していますが、ロムライタへの接続用のピンヘッダで基板自体が 2mm 程度浮くので問題ないはずです。

VppAdaputer 基板のパターン図（ボトム面）

　下図が基板設計 CAD で３Ｄ表示したトップ面になります。前述のように 3M TEXTOOL の ZIF ソケットは白枠の面積を占めます。手前側に伸びている朱色のものはロムライタへの接続用のピンヘッダを 2764 部品のデータをカスタマイズして作成したために付いた色です。

VppAdaputer 基板の３Ｄ表示（トップ面）

　下図はボトム面の３Ｄ表示です。トランジスタが整然と並んでいますね。子供の頃はラジオの回路等で６石だと高級感がありましたが表面実装だとそんな感じは無いですねｗ

VppAdaputer 基板の３Ｄ表示（ボトム面）

[TOP] [ 前へ ] 連載記事 [ 次へ ]

タグ：DesignSparkPCB TL866II Plus Vpp変換 VppAdaputer TL866 Vpp変換アダプタ 旧ROM対応 UV-EPROM

TL866II Plus用VPP:21V/25V対応アダプタの製作（その１）

　手持ちの NEC 製の uPD2716 を書き込もうとしましたが、使用している ロムライタ（TL866II Plus、以降 TL866 と記す）が対応していないためディバイス選択を intel M2732 にして書き込んだところ下図のようなベリファイエラーが発生しました。

NEC 製 uPD2716 書込み時のベリファイエラー

　TL866 の Vpp 電圧は 18V までしか対応していませんが、uPD2716 の Vpp は 25V の電圧が必要なのです。

NEC 製 uPD2716 の Vpp 電圧仕様

　Vpp の電圧が足りないなら昇圧するアダプタを作ろうという発想で考えたものが下図の回路です。Vpp の端子は 2716、2732 及び 2764/27128 で異なるので ROM のタイプによる切替え設定が楽なように TL866 からのロジック信号はそのまま通し、Vppとして 18V が来た場合には 21V または 25V に変換するように考えました。
　この部分の回路をシミュレータで検証してみました。下図が TL866 からの 18V の Vpp を 25V に変換している際のシミュレート結果です。

18V から 25V への変換機能のシミュレート結果

　上図では変換後の Vpp が 25V よりも低くなるので昇圧後の電圧を 25.7V でシミュレートした結果が下図になります。ほぼ 25V になっていますね。

18V から 25V への変換機能のシミュレート結果（昇圧電圧が 25.7V の場合）

　ロジックレベルの信号の場合はそのまま通過して欲しいのですが、下図のシミュレーション結果を見ると問題無さそうです。

5V 信号の通過状況のシミュレーション結果

　Vpp 用の 21V/25V は秋月電子さんで見つけた昇圧機能のある TJ34063 を使って 5V から生成することにしました。
　生成したVpp 用の平滑コンデンサを 4.7uF にした場合の立上り部分の実測波形が下図で CH1（黄色）が 5V 入力で CH2（水色）が昇圧回路の出力です。電源が供給されてから 4ms 程度で立ち上っています。これなら TL866 が供給する ROM 用の Vcc が使える可能性が出てきました。

21V の立上り時間（コンデンサ：4.7uF）

　立上り時間を更に短くするために 21V 用の平滑コンデンサを 4.7uF から 1.0uF に変更した場合の立上り波形が下図です。0.9ms 程度で立ち上っていますね。

21V の立上り時間（コンデンサ：1.0uF）

　しかしながら、TL866 から ROM に供給される Vcc はドライブ能力はそれほど高くないと思われるので 100 Ωの抵抗を介して 5V を給電した場合は下図のように昇圧できない状況でした。

100Ω経由で 5V 給電した場合

　実際に TL866 に昇圧回路を接続した状態で 2716 の読込み動作を実行したところ、下図のように電流制限が掛かってエラーが発生しました。

昇圧回路接続状態での ROM リード時のエラー

　以上より、昇圧用の 5V は外部からの給電とし、ROM（2716/2732/2764/27128）の切替え設定は Vpp 電圧の選択と GND ピン切替えの２つだけで行けそうです。 Vpp 端子は ROM の違いにより 3 箇所になるので上記のシミュレーションで使った回路を３組使うことになります。ブレッドボードでの確認は上記の昇圧回路だけにしてプリント基板化を進めていきたいと思います。

　最後にネットで検索してみると下記のようにいろいろ情報がありました。ネット上の Vpp 切替え回路は上記のシミュレーションで使ったものとほとんど同じで驚きました。まぁこの手の切替え回路は一般的な思考では同じような回路になるということなのでしょう。

1. TL866 Adapter
   　UV-EPROM 書込み時の TL866 からの Vpp 電圧を 25V に変更するアダプタ
   
   
2. Adapter für höhere Programmierspannungen am Universalprogrammer TL866
   　上記と同様のアダプタの記事
   
   
3. How to program EPROM M2732 21V with TL866?
   　TL866 で Vpp が 21V 以上の ROM の書き込み方法について議論している掲示板。上記 1) も紹介されている。書込み時間を 100us から 1ms に変更するとエラーが少なくなるという裏技的な応急対応も紹介されている。
   
   
4. TL866II PLUS 25V/21V アダプターを作った(2716/2732版)
   　プリント基板を作られている方が日本にいらっしゃいました。2716/2732 対応版と 2764/27128 対応版の 2 種類のプリント基板があるようです。
   

[TOP] [ 前へ ] 連載記事 [ 次へ ]

タグ：VppAdaputer Vpp変換アダプタ TL866 Vpp変換 旧ROM対応 LTSpice UV-EPROM TL866II Plus

WaterSkirtでバズった

　Twitter でペットボトルの蓋の部分に蛇口の水を当てると球形の水膜（勝手に WaterSkirt と命名）ができ、手を触れると大きくなる現象が紹介され、原理の説明を求めているツイート（後述）がバズっていました。
　添付されている動画から WaterSkirt 内に密閉された空気と大気との圧力差による現象のように思えたのでストローを使った簡単な実験を思い付き、動画にしてコメントしてみました。
　下図はコメント投稿から 90 分後の状態で動画再生回数が既に 10 万回を超えています。

書込みから 90 分後の状態（動画部分は省略）

　スマホへのいいね通知頻度も段々上がっていき、投稿から 1 時間後位には１秒間に数回程度に達したので買い物の時と寝る時にはスマホを機内モードにしていましたｗ

　ついでに 24 時間後の状態が下図になります。

書込みから 24 時間後の状態

　元ネタのバズりに乗っかった形でのバスりではありますが、いいね取得数が自己最高記録だったのでブログにメモしておきます。

原因が密閉された空気の圧力であることを検証しました
指で膨らませた後、ストローで中の空気を抜き小さくしてから再度指で膨らませました pic.twitter.com/LdW5l7ASnO

— skyriver (@wcinp) June 12, 2022

★追記　2022/06/14
　水の膜ができ易いように専用のキャップを作成してみました。角度を色々変えて実験しましたが、残念ながら顕著な効果はありませんでした。
　ペットボトルのキャップのネジは一回転で 3 mm 動くようにすれば簡単に作れるので今後色々応用できそうですね（TPUフィラメントでパッキンも作れるだろうし）。

水膜作成用キャップ（CAD画面）

タグ：WaterSkirt ペットボトル Twitter ツイッター バズリ

Z80での１バイトのビット順反転処理

　今回はみんな大好き？な Z80 のマシン語ネタです。Twitter のタイムライン（以降、TLと記す）で 8bit データの MSB-LSB の順番を反転する処理についてのコメントを見かけました。
　この話題の発端は内藤さんのマニアックなブログ「Code Knowledge」の「Z80 超高速ビット左右反転」の記事です。因みに内藤さんのブログの「Z80 数値の加算と減算」の記事で拙作の「Z80での10の高速除算方法」の記事を紹介して頂いています。

　話をビット順の反転処理に戻すと 256 パターンのテーブルを作成し、テーブルから引っ張るのが最も高速ですが、メモリを大食いしてしまうので普通に考えると A-reg ともう一つのレジスタを使ってキャリーフラグ経由でローテートを８回実施する方法を直ぐに思い付きます。
　しかし、A-reg のローテートは４ステートですが A-reg 以外のローテートは８ステート必要でそれなりにコストが掛かります。

　改善案として下記の処理が上記の TL で提示されました。

reverse (original method)

Original: 47 ld b,a ; 76543210 4 E6 55 and 55h ; 7 4F ld c,a ; _6_4_2_0 4 78 ld a,b ; 4 E6 AA and 0aah ; 7_5_3_1_ 7 0F rrca ; 4 0F rrca ; 1_7_5_3_ 4 B1 or c ; 16745230 4 47 ld b,a ; 4 E6 99 and 99h ; 1__45__0 7 0F rrca ; 4 4F ld c,a ; 01__45__ 4 78 ld a,b ; 4 E6 66 and 66h ; _67__23_ 7 07 rlca ; 4 07 rlca ; 4 07 rlca ; __23__67 4 B1 or c ; 01234567 4 C9 ret ; 4+7+4+4+7+4+4+4+4+7+4+4+4+7+4+4+4+4 = 84

　最初の AND 命令の部分は C-reg を減算した方が効率がいいので下記の処理を提案してみました。

reverse (improvement method)
Improve: 47 LD B,A ; 76543210 4 E6 55 AND 55H ; _6_4_2_0 7 4F LD C,A ; 4 78 LD A,B ; 4 91 SUB C ; 7_5_3_1_ 4 0F RRCA ; 4 0F RRCA ; 1_7_5_3_ 4 B1 OR C ; 16745230 4 47 LD B,A ; 4 E6 66 AND 66H ; _67__23_ 7 07 RLCA ; 4 07 RLCA ; 4 07 RLCA ; 4 4F LD C,A ; __23__67 4 78 LD A,B ; 4 E6 99 AND 99H ; 1__45__0 7 0F RRCA ; 01__45__ 4 B1 OR C ; 01234567 4 C9 RET ; 4+7+4+4+4+4+4+4+4+7+4+4+4+4+4+7+4+4 = 81

　これに対して XOR により直前の LD も省略し、更には後半の 2bit ペアの処理にも同様の改善手法を適用した改善案が提示されました。素晴らしいですね。

reverse (further improvement method)
Fimprov: 47 ld b,a ; 76543210 4 E6 55 and 55h ; _6_4_2_0 7 4F ld c,a ; 4 A8 xor b ; 7_5_3_1_ 4 0F rrca ; 4 0F rrca ; 1_7_5_3_ 4 B1 or c ; 16745230 4 0F rrca ; 01674523 4 47 ld b,a ; 4 E6 CC and 0cch ; 01__45__ 7 4F ld c,a ; 4 A8 xor b ; __67__23 4 07 rlca ; 4 07 rlca ; 4 07 rlca ; 4 07 rlca ; __23__67 4 B1 or c ; 01234567 4 C9 ret ; 4+7+4+4+4+4+4+4+4+7+4+4+4+4+4+4+4 = 74

　上記の処理より高速な手法は中々見つかりません。1bit 毎と 2bit 毎の2回の順番入れ替えが必要なことはすぐに判るのですが（2bit 入れ替えの方から先にやってもいい、と言うか順番のリバース処理なので末尾処理から逆に実行してもリバースになる）、例えば次の例のように命令数は削減できても同じステート数になってしまいます。

reverse (sample method)
Sample: 47 LD B,A ; 76543210 4 E6 AA AND 0AAH ; 7_5_3_1_ 7 4F LD C,A ; 4 A8 XOR B ; _6_4_2_0 4 0F RRCA ; 0_6_4_2_ 4 CB 01 RLC C ; _5_3_1_7 8 B1 OR C ; 05634127 4 47 LD B,A ; 4 E6 99 AND 99H ; 0__34__7 7 4F LD C,A ; 4 A8 XOR B ; _56__12_ 4 0F RRCA ; 4 0F RRCA ; 4 0F RRCA ; 4 0F RRCA ; _12__56_ 4 B1 OR C ; 01234564 4 C9 RET ; 4+7+4+4+4+8+4+4+7+4+4+4+4+4+4+4 = 74

　ローテート処理だけでは限界が見えてきたので加減算処理をうまく利用できないか考えてみたところ・・・・若干ではありますが更に高速な手法に辿り着きました (^^)/

reverse (fastest method at the moment)
Fastest: 47 LD B,A ; 76543210 4 E6 55 AND 55H ; _6_4_2_0 7 4F LD C,A ; 4 80 ADD A,B ; 4 1F RRA ; 4 81 ADD A,C ; 67452301 4 47 LD B,A ; 4 E6 CC AND 0CCH ; 67__23__ 7 07 RLCA ; 4 07 RLCA ; __23__67 4 4F LD C,A ; 4 78 LD A,B ; 67452301 4 E6 33 AND 33H ; __45__01 7 0F RRCA ; 4 0F RRCA ; 01__45__ 4 B1 OR C ; 01234567 4 C9 RET ; 4+7+4+4+4+4+4+7+4+4+4+4+7+4+4+4 = 73

　前半の 1bit の入れ替え部分が若干トリッキーですが、256 通りの全ての入力パターンに対して従来の処理と同じ結果になることを確認しました。

　素晴らしい処理方法を直ぐに思いつけばいいのですがいろいろな組み合わせがあるので、処理手法については散歩中等の空き時間を利用してアイディアを考えて頭の中で思考実験し、行けそうであれば紙に書いて確認し（当然最終確認はプログラムですが）メモを残すというやり方をしています。

　メモと言っても下の写真のように汚く書き散らかしたようなものなのですが・・ｗ

手法を思考中のメモ

　もし更なる改善案を思い付いた場合にはコメント頂ければ嬉しいです。


★追記　2022/06/07
　twitterのリプライで教えて頂いたのですがNET上の Retro Programming に 66 ステートでリバース処理するコードがありました。素晴らしい!!
　XOR 演算による置き換えが秀逸ですね。

reverse (Fastest method on the net)
net: 6F ld l,a ; 76543210 4 07 rlca ; 4 07 rlca ; 54321076 4 AD xor l ; 4 E6 AA and 0aah ; 7 AD xor l ; 56341270 4 6F ld l,a ; 4 07 rlca ; 4 07 rlca ; 4 07 rlca ; 41270563 4 CB 0D rrc l ; 05634127 8 AD xor l ; 4 E6 66 and 66h ; 7 AD xor l ; 01234567 4 C9 ret ; 4+4+4+4+7+4+4+4+4+4+8+4+7+4 = 66

★追記　2022/07/07
　その後も時折考えていますが七夕でもあるので現状の改善案を追記しておきますｗ
　70 ステートで上記の NET 手法よりもまだ 4 ステート遅い状況です。

reverse (Current improving method)
idea3: 47 LD B,A ; 76543210 4 E6 55 AND 55H ; _6_4_2_0 7 4F LD C,A ; 4 80 ADD A,B ; 4 1F RRA ; 4 81 ADD A,C ; 67452301 4 47 LD B,A ; 4 07 RLCA ; 4 07 RLCA ; 45230167 4 A8 XOR B ; 4 E6 33 AND 33H ; 7 4F LD C,A ; 4 0F RRCA ; 4 0F RRCA ; 4 B1 OR C ; 4 A8 XOR B ; 01234567 4 C9 RET ; 4+7+4+4+4+4+4+4+4+4+7+4+4+4+4+4 = 70

タグ：ビットリバース ビット順番反転 Reverse bit order