SRAMの初期状態

前々々回の記事で電源投入直後のSRAMの中身が全部ゼロだと思ってCPUの動作確認したことを書きましたが、実際に確かめてみました。

  1. Z80ボードをON
  2. Arduinoをアタッチ(即BUSRQ)
  3. PCでRAM全領域を吸い出してdump
  4. バイナリエディタで内容確認

結果は…

f:id:marlesan:20170512001555p:plain:w400

どう見ても不定状態です。本当にありがとうございました。全体俯瞰した時にパターンが見えるのは、シリコン層のレイアウトによるものでしょうか。M1の周波数で1MHzピッタリ出たのは、偶然HALTが実行された時だったのかも(NOPがリピートされるらしい)。

ついでにRAMを0xFFでクリアし、前回のFizzBuzzプログラムを転送→実行した直後でもダンプ取ってみました。 0000Hから77バイトのプログラムがあり、C000Hから100バイトのFizzBuzz結果があり、F000Hから上方向にスタックデータが…って

f:id:marlesan:20170512002141p:plain:w400

あれ、ちょっと違うぞ……? 全く身に覚えのない位置に謎データがあります。

確認のためもう一度同じ手順でダンプ。

f:id:marlesan:20170512002630p:plain:w400

最後のCANDIVからのリターンアドレス(0036H)とFIZBUZからのリターンアドレス(000FH)が積まれているので、これが正しいはず。

よく見ると謎結果のダンプは、プログラムの先頭がBB 00 F0になっています。 LD SP,F000Hに対応するマシン語31 00 F0なので、書き込みに何かバグがあるかもです……。

ちょっとBB 00 F0...がどう実行されるか追いかけてみます。

BB       CP   E
00       NOP
F0       RET  P
3E 00    LD   A,0 ;この行以降は正常

レジスタは基本、電源投入直後は不定のよう。CP EでPが0にセットされるなら、SPが不定なままLD A,0以降は元のFizzBuzzが実行されます。 P=1だとRET Pで…どこに戻るんだ。SP不定ならどこかからFFFFHをPCにPOPする可能性が高いはず。FFFFHのデータもFFHだからRST 38HでFIZBUZルーチンの中途半端な位置に飛んで……って、FFFFHにはなぜかBBHがダンプされてました。……これはちょっとお手上げですね。 スタックらしき領域に36 00 0F 00以外の値があるので一旦暴走してからFizzBuzzに戻ってるようには見えます。

この先Z80の動作がわけのわからないことになったら、今回の現象を念頭に置こう……。