 |
| 第2部 第4章 PC-9801に誰が魂を吹き込むか |
| 1982 悪夢の迷宮、互換ベーシックの開発 |
古山を苦しめる96Kバイト
富田倫生
2010/4/28
| 本連載を初めて読む人へ：先行き不透明な時代をITエンジニアとして生き抜くためには、何が必要なのでしょうか。それを学ぶ1つの手段として、わたしたちはIT業界で活躍してきた人々の偉業を知ることが有効だと考えます。本連載では、日本のパソコン業界黎明期に活躍したさまざまなヒーローを取り上げています。普段は触れる機会の少ない日本のIT業界の歴史を知り、より誇りを持って仕事に取り組む一助としていただければ幸いです。（編集部） |
| 本連載は『パソコン創世記』の著者である富田倫生氏の許可を得て公開しています。「青空文庫」版のテキストファイル（2003年1月16日最終更新）が底本です。「青空文庫収録ファイルの取り扱い規準」に則り、表記の一部を＠ITの校正ルールに沿って直しています。例）全角英数字⇒半角英数字、コンピューター⇒コンピュータ など |
GDCのような描画を高速化するための専用回路を持たないPC-8001やPC-8801では、すべてのグラフィックス処理がCPU上で実行されていた。それに対しGDCを持つN-10なら、可能な限りグラフィックスの処理を専用回路に任せてしまえば、それだけ描画は高速化できた。だが従来使ってきたベーシックの文法を守りながらGDC用の命令にベーシックの命令を変換する論理には、一部に組みにくいところがあった。開発期間がきわめて短かったこともあり、せっかくGDCが機能を持っているにもかかわらず、別個に手順を組み立ててCPUで処理させることになったものも少なくなかった。
| エンジニアライフ コラムニスト募集中！ |
あなたも＠ITでコラムを書いてみないか 自分のスキル・キャリアの棚卸し、勉強会のレポート、 プロとしてのアドバイス……書くことは無限にある！ コードもコラムも書けるエンジニアになりたい挑戦者からの応募、絶賛受付中 |
円や楕円の描画も、CPUによる処理にまわさざるをえなかった。
円や楕円を書く手順は、プロッターの制御用アルゴリズムとして学会誌に掲載されていた論文を参考にして組み立てた。動かしてみると、確かにうまく書けた。ところがPC-8801用に書かれたゲームのプログラムを動かしてみると、「土星の水漏れ」と開発チーム内で用語が定着することになった奇妙な現象が起きた。
このゲームには、土星の環のようなリングを書いてそこをペイント命令で青く塗りつぶす手順が含まれていた。ところがその手順にかかると、まるで環から水でも漏れ出してしまったように、画面全体が真っ青に塗りつぶされた。
もともと数学には自信を持っている古山は、水漏れの報告を受けて参考にした論文を家に持ち帰り、夜っぴてアルゴリズムを当たりなおしてみた。ところが楕円を書くアルゴリズムにはどう見ても論理的な誤りはなく、プログラムも正しくその手順を記述していた。
とはいえ、求められていることは正しいアルゴリズムを組み立てることではなく、あくまでPC-8801やPC-8001のベーシックと同じように振る舞うものを開発することだった。採用したアルゴリズムでは、楕円の弧の端に1ドット差が出る場合があり、2つの弧がつながらなくなるケースが生じることを明け方近くになってようやく突き止めた古山は、端で1ドット余計に書かせるようにすることで、ついに「水漏れ」をくい止めた。
百人一首の和歌とカルタの絵札を組み合わせたゲームを動かしている最中には、紫式部の顔が真ん中で切れて左右入れ替わって表示される事件が起きた。調べてみるとマニュアルが実際のプログラムの動きを左右取り違えて書いてあることが分かった。ゲームを開発する側は作業の途中でこの誤りに気付き、プログラムをベーシックの実際の動きに合わせていた。そこで互換ベーシックの側も、マニュアルではなく実際の動きに合わせて手直しすることになった。
また、マニュアルにはまったく書かれていないものにも、数多く対応せざるをえない要素があった。ゲームプログラムにはユーザーになにかキーを押してもらい、それをきっかけに場面を切り替えているものがある。マシンの側には、どのキーが押されたかを一時的に記憶しておくキーバッファーと呼ばれる小さなメモリーが用意してあるが、こうしたゲームに対応するためにはバッファーに記憶された内容をあらかじめ消しておかないと、以前に押されたキーの内容をユーザーからの指示と取り違えて、誤動作する可能性があった。
こうした点に関しては、マニュアルにはまったく記載がなかった。そこで新しくキーバッファーの中身をクリアするための機能を付け加えると、それが思わぬところでじゃまをして今度は別のプログラムに問題が生じた。
1つ1つ石を積み上げ、ようやく形ができたところで足りない機能に気付く。その機能を付け加えるために重ねたもう1つの石が、せっかく積み上げた石の山を崩してしまう。
手探りのチェックを繰り返しながら、古山は賽の河原で石を積み上げるような気分にとらわれていた。
6月末にでき上がったバラックセット上で7月から8月にかけてチェックと手直しを繰り返し、互換ベーシックはかなり体裁を整えてはきた。だがどこまで作業を続けても、なにか大きな問題点が隠されているのではないかとの不安は、古山の胸からいつまでも去らなかった。
互換ベーシックのチェックの工程では、機密保持の徹底という制約が大きな障害となった。本来なら、開発中のマシンをある時点でソフトハウスに配り、その会社のアプリケーションが問題なく動作するか、問題が起こるとすればどこで引っかかるかをテストしてもらうことができた。サードパーティーに広く協力を求めれば、製品として出荷するまでには、ほとんどの問題点をつぶすことも可能だった。ところが極秘裡の開発となったために、外部を巻き込んだテストをかけることができなかった。そこで開発スタッフが自ら市販のアプリケーションをできる限りたくさん動かしてテストしてみたほか、基本ソフトウエア開発本部の他のセクションのスタッフにも協力を仰ぎ、彼らが持っているPC-8801やPC-8001用のプログラムを走らせて問題点を拾い出していった。
基本ソフトウエアのトラブルは許されないとはいえ、納入先がはっきりしているオフィスコンピュータならまだしも責任の取りようがあった。ITOSは一大トラブルを引き起こしてユーザーとディーラーに大きな迷惑をかけたが、最低限日本電気は彼らに直接わび、ITOSを問題なく動くものに作り変えて供給しなおすことができた。
けれどパーソナルコンピュータでは、重大な問題がのちに確認されて手をつくしたとしても、救いきれないマシンが数多く残る可能性が強かった。
1982（昭和57）年の夏、古山は心臓を握りしめられるような緊張感と戦いながら、1つ積んでは1つ崩れ落ちそうになる石のバランスをとり、互換ベーシックの積み上げの作業を続けていった。
振り返れば日本電気に入社して以来のどの作業にも、常にスケジュールには余裕がなく、スタッフは不足し、それぞれの作業にそれぞれの困難がつきまとっていた。息を詰めて削りに削らなければ機械語のプログラムがメモリーに収まらない時代から、ソフトウエアの規模は拡大の一途をたどり、拡大は否応なく混乱を引き連れてきた。ACOSのOSは膨大な規模に膨れ上がり、古山は火のついたITOSを両手で受け取らざるをえなかった。
だがN-10プロジェクトの互換ベーシック開発は、これまでに体験してきたどんな作業よりも過酷な悪夢だった。互換ベーシックとBIOSを合わせれば、その規模はわずかに96Kバイト。大型コンピュータのOS開発を経験してきた古山にとって、「たった」と思えるその96Kバイトが、8月が終わりに近づいてもなお古山を苦しめ続けていた。
互換ベーシックにどんな問題が起こるか予測できないために、浜田と戸坂はハードウエアに逃げ道を用意してくれた。
本来なら、ベーシックとBIOSを収めたROMは基板の上に組み込むのが当然だった。だが最後の最後まで手直しが続くことを予測して、新16ビット機は6つ用意した増設スロットの1つにROMを持たせたボードを差し込むという、きわめて変則的な構成を採用した。
互換ベーシックの問題が発見された際、ROMが基板に取り付けてあるのでは、筺体をはずしてから入れ替えてもう一度組み立てざるをえない。それに対し増設ボードなら、抜き差しだけで対処できる。せっかくの増設スロットをこのために1つつぶしてしまう点でも、そもそも新16ビットのあり方を決める基本ソフトを増設ボードに置くという不自然さにおいても、こうした選択は望ましくなかった。だが開発状況を直視すれば、緊急時への備えはやはり欠かせなかった。
さらに増設ボード上に置くROMに関しても、浜田は古山からの注文を入れて特殊なタイプを採用する道を選んだ。
本来ならベーシックとBIOSを収めたROMには、製造の段階で情報を焼き込んでしまうマスクROMを使うのが当然だった。大量生産に向いたこのタイプなら、コストを低く抑えることができた。一方EPROM（Erasable Programable ROM）と呼ばれる特殊なタイプなら、いったん書き込んだ情報を紫外線を照射するなどの処置を施して消してから、再度新しい内容を書き込むことができた。コストで比較すれば、EPROMはマスクROMに比べて大幅に高くなった。だが「なにが起きるか分からない」との古山の意見を入れて、取りあえず初期の出荷分はEPROMで臨み、これ以上大きな問題は起こらないと見極めがついた時点でマスクROMに切り替えるという方針が採用された。
| » ＠IT自分戦略研究所 トップページへ |
＠IT自分戦略研究所は2014年2月、＠ITのフォーラムになりました。
現在ご覧いただいている記事は、既掲載記事をアーカイブ化したものです。新着記事は、 新しくなったトップページよりご覧ください。
これからも、＠IT自分戦略研究所をよろしくお願いいたします。
