火災

住んでいる所が火事になり、すべてが失われました。
数ヶ月作業していたリレーコンピュータがもう少しのところだったのが非常に悔やまれます。
火元等不明ですが、消防士によると、もちろんリレーコンピュータではなく、電気式のコンロから出火していたようです（ただし、私はその３日前から使っていません・・・）
ラップトップはバックアップを取っていましたが、バックアップも同時に焼けてしまったため復活の見込みはありません。すべての情報をクラウドへ、違う場所にバックアップをとることが大切ということが身にしみてわかりました。

再度、一から作り出す気力は今のところ失われました（そもそも子供の頃から揃えてきた工具とかを0から買い直さないといけないし、回路図の元データや一部の図はないので再設計の必要もあります）。

動作中の動画だけでもどこかにアップロードとしておけばよかったのですが、今では一部の写真と記憶に残っているのみです。唯一残ったのはこのブログのアップロードしていた図や写真だけなので、それだけでも手前のメモではなくブログとしてアップロードしてきた意味はありました。

記憶に残っている、リレーコンピュータの到達地点を列挙すると、
・ROMからのインストラクションのロード、解釈
・ジャンプ命令
・即値(Im=>X/Y)
・ADD(X+Y=>X)
・Incr(X+1 => X)
・mov
・load/store(RAMへの書き込み・読み込み)
までは動作していました。メモリも全bit動作良好でした。後は、ifの分岐命令と、NOPの動作調整・確認で完成だったのですが・・・

自分にとっては生涯で一番部品点数の多いプロジェクトでした。コンピュータ(バス/CPU/メモリ)についての理解も深まりました。どう早く計算させるか、ではなくどう部品点数を減らすか、の観点ですが、非常に勉強にはなりました。いつの日か、やる気がチャージされたときに再開できるよう祈ります。

Operation Decoder(3)

PC(プログラムカウンタ)のloadPC出力にバッファが抜けてるのを発見。バッファがないと信号が逆流してしまうのだ。
ということで、バッファ追加後、JMP命令の動作を確認。データをオペレーションレジスタに保持し、JMPと解釈し、PCを上書き、次のサイクルではPCに書き込まれたアドレスを読みに行っている。
0x00からJMPさせて、その先でもまたJMPさせて0x00に戻す動作も確認した。いよいよCPUらしくなってきたぞ。

Operation Decoder(2)

オペレーションデコーダのテスト中。なぜかデータ6bit目が1だと回路全体がリセットする問題があり、解決に一昼夜費やした。原因はハンダブリッジでVdd(リレーだからVrrか？)がGNDに落ちてたようだ。配線以前の問題だったか。

機能に関係しないリレーを取り外しテストしている様子。

他にもselROMのタイミングを遅らせる必要があり、ディレイを追加。載せているリレー数が足らなくなってきたので、0検出は別基盤対応とする。

0x01以降はRAMなため、0x00はJMPにしROM領域に飛ばなければならない。データをオペレーションレジスタに読み込み、保持し、JMPと解釈し、PCレジスタを書き換えようとするところまでは動作させた。JMPさせる番地にPCレジスタの値が足されてしまう問題があるようだ。タイミングの問題だと思うが。ここまでで出張前の作業は時間切れ。各部のタイミングを一度きちんと考え直さないといけないようだ・・・

Operation Decoder(1)

オペレーションデコーダの設計図が下記。SPDTのリレー数が足らなくて、できるだけDPDTに置きかえてなんとか足りた。画像大きいので注意。

他のユニットと違って、同じ回路は少なく、ほぼランダム。各リレーに番号を振って配線を管理。しかしどこかで間違うだろうな・・・

基本的に論理だけだが、STATE周りでタイミングもあるので、この回路のテストは大変である。

とりあえず実装した写真。やはり表の見た目重視で同じリレーをまとめてみた。ここらへんの実装・配線はかなり突貫作業となったが、この時点で、今年のMaker Fair World応募は不可能になった。Call for makerにはまだ時間があるが、明日から出張で作業できないためである。というか仕事が忙しすぎてテストしている時間がなかったのだ。うむー、協力を申し出てくれたJingも転職してしまうし。

メモリ設計に時間をとられたのが敗因か。その後のMini Maker Fair in Oaklandか、粘って来年のSan Mateoに応募しようか。とにかくここまで来たら動くものを作るしかない。

出張中、時間があれば、秋葉でSPDTリレーを大量購入しよう。ラッピングワイヤはハンダののり的に今使ってる方がよいし、基盤もDigiKeyのが頑丈でよい。DPDTはこの前eBayで安く買ったし、秋葉でしか買えないパーツが減ってきた・・・というかラッピング周りの品揃えが悪すぎる。

Architecture

とうとう最後のユニットであるオペレーションデコーダにとりかかる。この時点で、全体のアーキテクチャを決めなくてはならない。設計に際して変更あると思うが、現時点での構成は下図のとおり。

ALUは現時点でAdd,Thru, Incrだけだが、追加しても基本的な構成は変わらない。

条件分岐はALUからのCarryと、Xレジスタの0検出だけである。条件分岐で次の命令をスキップするのはアドレスを2個進める方法と、次の命令をNOPに変える方法があると思うが、後者を採用する。

後は、いかに命令セットをアーキテクチャに合わせてリレー数を減らすか、だが、拡張性も考慮してある程度クリーンな設計にしたい。考え中の命令セットは下記のような感じ。

01 [8bit] Im => X

10 [8bit] Im => Y

11 [8bit] JMP (Im => PC)

00 0000 [4bit] NOP

00 0001 [4bit] loadRAM => X

00 0010 [4bit] loadRAM => Y

00 0011 [4bit] store X => RAM

00 0100 0001 if zero skip next

00 0100 0010 if carry skip next

00 1000 0000 mov X => Y

00 1000 0001 add X+Y => X

00 1000 0010 Incr X => X

00 1000 [0011 - 1111] reserved for additional operator

最上位2bitで、Im(即値)かJMPかオペレーションかが判断でき、

もしオペレーションであれば、中位4bitでメモリアクセス系か、ifか、ALUか判断できる。

もしメモリアクセス系であれば、下位4bitで指定したアドレスに直接アクセスできる。逆に言うとRAMのアドレス空間は16byteだが、0x00はJMPなので実質15byte。実際は3byteしか作ってないが。

全部0ならNOPで、実装していないアドレスをアクセスしても安全である。

リレーはうるさいので（寿命の問題もあるし）、HALTとリスタートの割り込みも必要かもしれないがまだ未定。

Memory Unit

RAMとROMができたのでアドレスデコーダに接続して動作テスト。

上がアドレスデコーダ、真ん中が10WORDのROM、下が1WORDのROM+3byteのRAM。RAMは0x00-0x03に、ROMは0x20-0x29にマッピングされている。

実は設計ミスでアドレスデコーダの配線をやり直してるので、ここまでくるのに結構苦労したのだ。とにかく、メモリはリレーを消費する・・・

それから、eBayでDPDTのリレーを59個調達した。$0.6/DPDTなので激安だと思う。これで10WORD追加できる

Address decoder

次はアドレスデコーダである。トーナメント的にリレーを組めばいいのだが、例えば6bitをフルアドレッシングするには1+2+4+8+16+32=63ものリレーが必要になってしまう。そこで、下位3bit(8WORD)を1blockとして、上位3bitでblock enableを指定する。こうするとリレーは(1+2+4)x2=14個ですむ。
回路図には描いていないが、データバスに接続するかどうかのselSのリレーもある。

SRAM用にはセンスアンプ（とは名ばかりの単なるリレーコイル入力）と、R/W切り替えのリレーが回路図の下半分。SRAMはまだ構想段階だが。

アドレスデコーダとROMを接続して動作確認中。左が以前作った10WORD ROM、右がアドレスデコーダ。上の8LEDがアドレス、下の10LEDが読み出したデータ。次はこれに接続するRAMを作ることにする。どうやらSRAMは半導体のstaticRAMを意味するっぽい.

この場合リレーなので、RRAMと呼ぶことにする。