TTL でCPUを作成、16bitの手作りコンピューター TANACOM-1 誕生

もしも、今からもう一度コンピューターを作るとしたら

2011年、現在進行形で、TTL-CPUを作られている TTLコンピュータRETROF のサイト様より、素晴らしい、ご質問が投げかけられました。

Ｑ１．今、同じ物を作れますか？

Ａ１．ケースバイケースです。
前提条件　：　同じ部品や線材が揃う事

ケース①「配線方法が当時と同じワイヤリングペン方式」ならば

体力と根気の点で、今の私には絶対無理と思われます。
当時、ワイヤリングペンでの配線は、とてつもなく地獄の毎日でした（自分の好きで始めた事なのに地獄と言うのは変ですが）。
配線をやれどもやれどもゴールが見えてきません。そこで完成直前、最後の３週間は、毎日２時間配線するノルマを自分に課しました。そのお陰で何とか、1978年6月にCPU完成に至りました。
もちろん配線が完了しても、一発で動く事はあり得ません。ハードウェア上のデバッグ工程が待っています。
面白いですよ、１個デバッグする度に、目的通りに働く「命令」が１個づつ増えていくのです。
作業途中、その段階で動く命令だけで、デモプログラムを作り、動く様子を見て「大はしゃぎ」です。
そして「いかん、いかん、デバッグを進めよう」と我に返る日々の繰り返しでした。
これを５０歳台でもう１回やるとなると、私にはやはり無理です。
たぶん、当時の私でも「もう１回」は、「ＮＯ」と答えていたと思います。

ケース②「プリント基板方式」ならば

これだったら、やってみたい気がします。回路は当然デバッグ済ですから、プリント基板させ間違いなく作れば、一発完成でしょう。
但し、現実に考えると色々な問題が出てきます。
127個のTTLを何枚の基板に実装するのか、大きい基板となると、フリーの自動配線ソフトは対応できないから、配線から描画しなければならないとなると、その作業量を考えると、体力と気力の点で怪しくなって来ます。
もし各ロジックICを表面実装タイプにすればコンパクトに出来ますので、部品が入手可能であれば、使いたいと思います。たまたまTSSOPクラスの手ハンダには慣れましたので、行けると思います（拡大鏡とルーペは必需品ですが）。

Ｑ２．作るとしたら、どこを改良しますか？

もともと持ち続けている夢は、TANACOM-1 とは、まったく違うアーキテクチャの16bit マシンを、TANACOM-2 として作る事、です。
16bit の次なら32bit とも思ったのですが、作って何をさせたいのか、の目的を考えたときに、やはり16bit が丁度小気味よい大きさかなと考えます。大昔は、24bit CPUとかも在りましたので、ほんの少しちょっと24bit にも惹かれます（少数派が好きなもので）。
もちろん、TANACOM-1 の流れを汲むTANACOM-1A を作るのも楽しいかと想像していました。
当然、コンパチ・マシンになりますので、従来のソフトはそのまま動かせる魅力があります。

と言うことで、ここは、もし「TANACOM-1A」を作るとしら、どこを改良するか、を考えてみたいと思います。
もちろん、空想みたいな改良ではなく、実現可能な改良を前提とてみます。

メインメモリに高速SRAMを採用

TANACOM-1 に搭載したSRAMは、アクセスタイムが 450 nS でした。
CPUの命令実行スピードを決めていたのは、全てこいつでした。
RAMへの読み書きは、ベースクロック 300 nS の２波で、600 nS を形成しアクセスしていました。
よって、このSRAM を高速なものにすれば、命令実行スピードを相当上げる事が可能になります。
SRAMの候補としては、秋月電子通商の「４Ｍビット　ＣＹ７Ｃ１０４１ＤＶ３３」です。
いつの日か夢の実現のために、既に購入済みです（笑）。
このSRAM は16bit 幅の256Kwordメモリですから、メインメモリはこれ１個で済みそうです。
そして、注目のアクセスタイムは、何と10 nS なのです。
これにより、一番足を引っ張っていたRAMへのアクセスタイムが、ロジックICの数段の遅延速度程度に収まってしまうという、高速な環境が期待されます。
但し、このRAMは電源が 3.3V ですから、自ずと、TTL マシンと称しながらも、74HCシリーズを使ったマシンにならざるを得ません。
それでも、汎用ロジックで作ったCPU に変わり在りませんから、意地でもTTL マシンと称したいと思います（笑）。

カラーグラフィックディスプレー

これは、ご指摘どおり、ぜひ新しいマシンには、欲しい所です。
３０年前は、メーカー製のパソコンにはカラーのキャラクタディスプレーが存在するものありました。
また、マイコン雑誌にも、カラー化に挑戦した製作記事がよく出ていました。
TANACOM-1 のVRAM は残念ながら、白黒オンリーでしたから、カラーには本当に憧れます。
今回のご質問を発せられたサイト様には、TTL で作るVGA の計画があられるようです、実はとても楽しみにしているのです。

ダブルワード命令

TANACOM-1 のメモリ参照命令系は、

15	14	13	12	11	10	9	8	7	6	5	4	3	2	1	0
0	OP Code			R1/ R0	Ix	Id	M/ im	Address or  immediate

なのですが、これを頭の8bit をオール1 にし、頭にあった8bit をそっくり下位8bit に移動。
そして、次のワードに、ページAddress 値や immediate 値をフル16bit で指示すれば、

15	14	13	12	11	10	9	8	7	6	5	4	3	2	1	0
1	1	1	1	1	1	1	1	0	OP Code			R1/ R0	Ix	Id	M/ im
Address  or  immediate

のように、16bit アドレス空間を直接指定したり、０～65535の即値を指定できるダブルワード命令が実現します。
もちろん、Ｂｒａｎｃｈ命令系も同じ仕組みで拡張されます。

実は、この仕組みは３０年前のノートにメモ書きしておりました。
１ワード目の上位8bit のオール1を先に検知し、オール1であれば、SN74157 x 2 を使って、１ワード目の下位8bit を命令レジスタIR にセレクトしてやれば、簡単にダブルワード化が実現します。
当時のノートには、追加部品代は400円 程度と書いていました。

この、ダブルワード命令があれば、256word の狭いページ空間に縛られずに16bit のアドレスを直接指定出来るのが、超魅力的です。

多重化したループカウンタ

TANACOM-1 で採用した２個の74161を使ったループカウンタは、プログラムを組む上で、どても便利な機能でした。
但し、欠点としては、ループカウンタは１組しか無く、入れ子の様に多重には、使えなかったのです。
そこで、改良するなら、ぜひ多重化したループカウンタを持たせたいです。
これを実現するには、16段か256段の FIFO を使うか、スタック的な仕組みで、メインメモリを利用するのかなと思います。

相対ジャンプ命令

Ｂｒａｎｃｈ命令系に於いて、TANACOM-1 は絶対アドレスだけで、相対ジャンプはありませんでした。
本当は、喉から手が出るくらい、相対ジャンプが欲しいところです。
但し、命令セットのコンパチ維持の点から、TANACOM-1Aへの相対ジャンプは追加の余地がありません。
しかし、コンパチを無視すれば、搭載可能です。

Ｂｒａｎｃｈ命令系のbit8 は、カレントページかゼロページかを、1/0 で指示していますが、それを廃止し、代わりに、絶対か相対かの1/0 指示とします。
そして、相対の時は、命令の下位8bit を符号＋7bit として -128 ～ +127 の相対値とさせます。
相対ジャンプが可能になれば、局所的な小さなプログラムは全て相対ジャンプで書いておけば、アロケーションが自由自在で、とても便利になると思われます。

増やしたい命令

TANACOM-1 をプログラミングしていて、こんな命令があったらと思うことが、しばしばありました。
命令コードの空きと、他命令との整合性を踏まえて、欲しい命令を列挙すれば、

SWP Rn ・・・ Rnの上位byteと下位byteを入れ替える

TANACOM-1 には、byte単位の操作がまったく装備されていませんでした。この上位byteと下位byteを入れ替える機能は、ぜひほしいところです。

MOV R0,R1 ・・・ R1の内容を、R0にコピー（ MOV R1,R0は既存 ）

SETCF n ・・・　コンディションフラグ Carry,Minus,Zero へ値をセットする。

LOADCF  ・・・　コンディションフラグ Carry,Minus,Zero をR0へロードする。

TANACOM-1 の割り込み処理の仕組みは、とても原始的でした。
すなわち、割り込み信号が受理されると、現在のプログラムカウンタPCをメモリの0x0000番地に退避し、メモリの0x0001番地にジャンプするだけです。
もちろん、0x0001番地には割込処理のプログラムを準備しておくのですが、そこで最初にやらなければならないのは、コンディションフラグの待避です。
TANACOM-1 には、コンディションフラグを待避する命令が無いため、今のフラグの状態を自分で調べて、その状況をどこかへ保管させなければなりません。
また、割込処理から、復帰する際のコンディションフラグの再現も、プログラムでやるしかありません。
そこで、上記「SETCF」、「LOADCF」は、ぜひ欲しい命令です。


もしも、命令コードの空きを無視して良いなら、

OR 命令  ・・・　Rx　←　Rx OR  □

NOT 命令  ・・・　Rx　←　~Rx

ただし、命令コードの空きを無視というならば、命令セット自体を組み直したくなり、一挙に TANACOM-2 構想に気持ちが引っ張られそうです。

また、アイディアが出てきたら、追記しますねー