1980(1) からの続きです。

６）AutoDigitizer＝図面自動読み取り装置（スキャナーシステム）

開発初期は16bitCPU Intel8086が出たばかりで、512kbyteのメモリーが１００万程度していました。A1~A0図面を画像としてそのまま入れると数10Mbyte 必要です。また画像の１ドットずつ画像処理するので8086では何日かかるか分からりません。そのため画像処理専用のハードウェアーをH氏が開発しました。また8086はメモリーとして1Mbyteまでしかアクセスできませんので64Mbyteまでアクセスする様に外部メモリ切り替え機構もH氏が追加しました。この様な工夫で最初にできたのがAutoDgitizer330でした。

電気メーカ用に作っていたAutoDigitizer330ですが、どこで漏れたのか「地図航測会社」が購入したいと来社され１号機が無事売れました。「四国の等高線」入力が人手の1ヶ月が１日でできたと喜ばれていました。この頃から地図業界との付き合いが始まります。

危なかった話：AutoDigitizer330の請求書をY氏が「地図航測会社」へ持って行った時に請求金額が１桁足りなかったそうです。Y氏が気づいて速攻で引っ込めて、再度請求したと聞きました。もし間違ったままだったらそこで終わっていたでしょうから危ない所でした。

AutoDigitizer330が売れた資金で次のAutoDigitizer4001開発ができる様になりました。AutoDigitizer4001は以下の様なある意味怪物システムでした（＝現在のスマホと比べるとCPU性能はおオモチャです）。

CPU	独自の画像処理32bitCPU 制御はIntel80xxx	当時の大型コンピュータの40倍の処理性能でした。
Memory	最大64Mbyte	当時の大型コンピュータでも1Mbyte程度なので６４倍のメモリー量でした。
画像読み取り	A0ドラムスキャナー A1スキャナー

世の中16bitCPUが全盛の頃に独自の32bitCPUをH氏が作り、大型コンピュータの４０倍以上の画像処理性能を出していたので痛快ですね（＝新プロジェクトXの取材来ないかな。こないだろうな）。当時はCPUを作るICがあり16bitALUを２個繋げて32bitにしてます。私は32bitCPU用にアセンブラを定義し画像処理機能を作成していました。

AutoDigitizer4001は大手電気業界や地図業界に納入されて行きました。

当初は画像から線に変換するだけでしたが、意味を抽出するためにシンボルや文字認識機能が要求される様になり、三重大学の指導をうけて文字認識機能を作成しました。

東京・名古屋・大阪の大手ガス会社用に「AutoDgitizer4001＋シンボル・文字認識＋CAD」を組み合わせて専用の「ガス図面入力システム」を構築しました。担当の方から「予定より1年程度早くガス図面のデータ化ができた」と言われた事を思い出しました（＝数億円近くの経費削減効果です）。

７）OHM=CAD

AutodDgitizer4001のベクターデータはGDS2に入れて使用していましたがGDS2が無くなった為に、代わりとなるCADが必要になりました。画像（ラスター）もベクターも使えて、電気業界・地図業界でも使える様な物はありませんので、「無ければ作れば良い」だけです。
何を使うかでSunとApolloを比較する事にしました。最初にApolloの日本法人に行き、質問とテスト開発で簡単なベクター表示プログラムをApollo上に作成しました。次にSunの代理店に行き同様にしたのですが、質問（＝メニュー作成豊富。ベクター描画方法）しても返答が帰ってこないので諦めてマニュアルのみ借りてかえり、次の日に簡単なベクター表示プログラムをSun上に作成しました。この結果Apolloを使用する事にしました。その後Sunが暫くは天下取り（＝Sunの本社は今やFacebook=Metaになっている）ましたが、最初はひどい物でした。

７−１）インターグラフのマニュアルは２ｍ

AutoDigitizer330ユーザの「地図航測会社」が地図用CAD＝インターグラフを使用されてので、地図業界で必要な機能調査の為にマニュアルを半日見せていただきました…が、そのマニアルは大きくて複数あり並べると「幅が２ｍ」近く有りました。それも英語です（＝絶望的な状況）。

が、見ていくと何とかなる物で「地図で必要なのは属性とメッシュ管理構造だ」と確信した次第です。

７−２）メモリーマップドファイル

普通のファイルアクセスプログラムは、「open/read/write/close」の流れですが、仮想記憶OSの動作を詳しく見ると「open/仮想記憶メモリーread/プログラムメモリーに移動(A)/プログラムメモリーから仮想メモリに移動(B)/仮想メモリーwrite/closeの流れです。小さいサイズのファイルでは問題になりませんが、CADや地図データの場合遅くて使い物になりません。(A)(B)の様な無駄なメモリー移動を無くし、高速のファイルread/writeする方式がメモリーマップドファイルです。仮想記憶OSの特徴的機能です（＝現在のOSはほとんど仮想記憶OSですので、ほとんどのシステムで今でも使える技術です）。OHM=CADを作る時に使用した基本的な技術ですが重要です。

７−３）OHM＝CAD

CADの名称はOHMです。CADの心臓となるデータ管理はY君が作りました。その他は多くの人が参加しました。CADには以下の様な特徴を持たせました。

１	ラスター背景	AutoDigitizer4001で読み取った画像をCAD背景として配置して、背景を参照してベクターデータを追加・修正・削除します
２	ベクター修正	2DCADの基本機能です。IC/PCB設計の流れもありますからArrayReference（＝NxMで部品を配置する機能）も有ります。
３	ユーザ言語（CGL)	GDS1/GDS2の系統ですから当然です。ユーザサイドで機能拡張できます。現在でも使われている一つの要因でしょう。Pascal風ユーザ言語の名称はCGLにしました。
４	協力なログ	操作状況をログとして保存しています。またログから「再実行」できる様にしています。これはユーザサイドで不具合が出た場合に、ログがあれば不具合を再現できてデバックする為です。また自動テストにも利用できます。
		この機能が無いと「どの様な操作で不具合が出ましたか？」と聞かれても誰も答える事はできませんので必須の機能です…が、現在のソフトで同様の対応しているのは…少ないな。
５	早い	とにかくストレス無く動く事を目標にしています。この当時でもストレスは余りありませんでしたので、現在も少ないメモリーでサクサク動くのは当たり前です。メモリーマップドファイルはキー技術で合言葉は「早ければ七難隠す」です。
6	外部データベースリンク	CADは「属性」がなければただのお絵描きソフトです。当時でてきたパソコンCADはほとんどお絵描きソフトで、今のCADもお絵描きソフトの性格が残っているのが多いのが嘆かわしい所です、属性を少量なら内部にも持てますが、地図(GIS)を考えると、多量の属性は外部データベースで管理する事がCADの性能的に有利です。その為に外部リンクキーをOHMの全データに持てる様にしてあります。

驚いた事１：阪神大震災の2年後ごろ、西宮にある海洋関連事業を展開されている会社に訪問した事が有ります。そこの担当者はとても優秀な方でユーザ言語(CGL)を駆使して業務機能・メニューを作られてました。機能に驚き逆に私が「どうやってその機能を作ったのですか」と聞いてしまいました。自分たちが作った物以上のシステムになるとは「してやったり」と思ってニヤついてしまいました（＝阪神大震災の爪痕がまだまだ残っていた時でしたので、若干不謹慎でした）。

驚いた事２：OHMの子孫（？）が現在でもCATV設計CAD CadixExpertとして現役で使われています。私の手をはなれて20年以上になりますが、その後多くの人々のメンテナンスと改良の結果でしょうが、基本機能が充実していたのも一因と（勝手に）思っています。先週10年ぶりに操作・動作を見ましたがMac上のVMware：仮想環境(４Gbyte,2CPU構成＝今では低スペック）でもサクサク動いていました。東日本の地図を背景にCATVデータ設計がストレスなく動くのはOHM作成時と比べると１０００倍以上CPU性能が上がっているので当たり前ですが、今作成したらこのスピードはなかなか出ないと思った次第です。

７−４）仮想cpuの命令は１０種類

OHMのユーザ言語・強力なログを実現する為には、シェルスクリプトの様なコマンド実行機能が必要なのでインタープリターが必要です。またCGL言語ソース(=ユーザプログラム）をそのままインタープリターで実行するのは、ソースにバグがある場合何が起こるかわかりませんので危険です。結果「CGL言語ソースを中間コードにコンパイル」して、中間コードを「仮想cpu」で実行する形式にしました。またログ・コマンド対応として「１行コンパイラー」で中間コードに変換して実行する方式にしました。
コマンドインターフェース全体をGraphicShell(Gsh)と呼びます。

ここで仮想cpuの命令＝中間コードの設計ですが、当時はCISC/RISC論争が活発でした。RISCが優勢だったのでどこまでシンプルにできるかと考えて中間コードを絞り込み、残ったのが約１０個の命令でした=OHMは１０個の命令で動いている究極のRISCマシーンです（＝若干嘘が含まれていますが、ご容赦を）。仮想cpuとか独自の32bitCPU作成に参加していた影響か、興味本意の面白そうなのでやってみたのが真実かな？。

＜CISC／RISC論争＞

1980年代におけるCISC（Complex Instruction Set Computer）とRISC（Reduced Instruction Set Computer）の論争は、CPU設計のアーキテクチャに関する大きな議論でした。以下にその背景と要点を説明します。

CISCとは?

• CISCは「複雑な命令セットを持つコンピュータ」を指します。
• 1980年代まで、CISCが唯一のアーキテクチャでした。特に米国Intel社のx86プロセッサが有名で、CISC文化を築いていました。

RISCとは?

• RISCは「縮小された命令セットのコンピュータ」を指します。
• 1980年代初頭にスタンフォード大学で「MIPS」プロジェクトが始まり、RISCプロセッサーが台頭してきました。

論争の背景と争点:

• RISCは少数のシンプルな命令を採用し、高速化と効率化を図るアプローチでした。
• CISCとRISCのどちらが優れているかについて激しい議論が巻き起こりました。

現在の視点:

• 現在ではRISCとCISCの区別はあまり意識されません。両方のアーキテクチャはCPU実装の選択肢となっています。
• RISCは高性能CPUの技術として登場しましたが、CISCも高速化技術やコンパイラ技術を駆使して十分な性能を発揮できるようになりました。
  結局、現代のCPUはRISCとCISCの研究で培われた技術の結晶であり、両者の良いところを取り入れています。

（＝MicroSoft Copilotを使用して時代背景を作成しています。便利な世の中ですね）

＜仮想cpu中間コード＞

もう覚えていませんが以下の様な物は必要でしょう。中間コードにコンパイルラーは部下だったI君がコンパイラーコンパイラーyacc/lexで作りました。

１	nop	何もしない
2	jmp	指定アドレスへ移動する
3	jmpIf	条件が真の場合指定アドレスに移動する
4	call	関数を実行する	CADコマンドや四則演算、アレー計算など全て「関数」として実行します。この機能により中間コードは制御機能のみになりました。
			四則演算の＋などは全て（スカラー、ベクター、アレー）＋（スカラー、ベクター、アレー）のように混合して計算できる様にしてあります。内積・外積など図形処理に良く使う計算も有ります＝APLやGPL2の継承です。
5	rtn	関数から戻る
6	eq	比較（等しい）	この辺はもしかしたらCALLの関数にしたかも？
７	neq	比較（違う）	この辺はもしかしたらCALLの関数にしたかも？
８	gt	比較（大きい）	この辺はもしかしたらCALLの関数にしたかも？
９	gte	比較（大きいまたは同じ）	この辺はもしかしたらCALLの関数にしたかも？
10	inc	＋１する
11	dec	−１する

７−５）自動テスト＝動作ログと再実行

仮想cpuも準備できたので後はCAD操作全て「コマンド化」するだけです。メニュー表示もメニュー遷移・メニュー操作もです。マウス操作やイベントも全て「コマンド」として実装する事により、ログのコマンド部分（＝確か　＞か％の後がコマンドだった様な…）を抽出して１行コンパイラーに渡す事を繰り返せば、ログの再実行ができます。この機能でユーザでの不具合を調査・確認したり、修正後の自動テストに利用しました（＝40年も前からGUIの自動テストを行なっていたのは偉いでしょう）。

８）8bitCPU=Z80と角度計算

究極の8bitCPU 6809、最速の8bitCPU 6502、8080の上位互換のZ80と賑やかな世の中でした。私はZ80を使ってインテリジェンスデジタイザー用に色々機能を作りましたが、角度計算が一番記憶に残っています。

いまのCPUには当然の浮動小数店計算やタンジェントなどの三角関数計算はZ80には有りません。角度計算にはアークタンジェント計算が必要なので、固定小数点計算とアークタンジェントの多項式近似計算で作成しました。Z80には8080のA,　B,　C,　D,　E,　H,　Lレジスターが2種類（＝裏レジスターと呼ばれています）あったので、それを駆使して角度計算したら１秒間に１０回以上の角度計算ができました。実際はXY情報取得・長さや角度計算・液晶表示など行いましたがカーサ移動について表示が追従する十分な性能で8bitCPU恐るべしでした。