発掘時に遭遇した問題をまとめておきます。
通常の「バグ」に関しては触れません。
現在(2021年)の感覚では理解できない点もあると思うので、歴史(技術)的な背景を踏まえて説明します。
問題は単独で存在するとは限りません。
一般論として、Tape(紙,磁気) や Disk を誰かに送っても、相手に同様の環境がなければ利用できません。 当然、プリントアウトすることもできません。ハードウェアだけでなくソフトも再現しないとだめです。
「マイコン」が「私だけのコンピュータ」を意味していた時代がありました。 アセンブラの仕様もまちまちでした。 「私だけのコンピュータ」と同じ環境が編集部になければ、デジタルデータを送っても利用できないのです。 そんな訳で、プログラムリストは作者が自前で印字して送るか、手書き原稿を編集部で写植リストに起こすのが一般的だったようです。 記事中の「実行画面の写真」も編集部で撮影したものはほとんどないと思います。 この時代の発掘対象としては、TK-80 用のソフト, 2K-BASIC 用のソフトがあります。
記事 と カセットテープや Disk を送って、リストと実行画面の写真は編集部で用意するスタイルが定着するのは、 皆が吊るしのパソコンを利用し「掲載されたものをそのまま打ち込んで使う」ことが可能になった、TK-80BS世代以降です。
おそらく、写植を打っていたのはコンピュータに縁のない方だったと思います。 基本的に「打ち込んでもそのままでは動かない」ものだと思ってください。
[大文字の O と 数字の 0] や、[小文字の L と数字の 1] の間違いのような単純なものだけではありません。 記事をよく読んで「仕様」を把握しておきます。 基本的にコードの内容から推定するしかないのですが、その環境で小文字が使えなければ絞り込みが可能です。
ダンプ付のアセンブルリストの場合は双方を比較して正しいコードを推定します。 アセンブルリストのコメントは後付けのケースがあるので、全面的に信用しない方が良いと思います。 後付けのコメントは作者さんの手によるものとは限りません。かなり酷いものもあります。
行が丸ごと欠落/重複している事も多いので、アドレス,行番号に注意が必要です。
実行画面の写真などから推定します。 写真が掲載されていない場合は、他の同様の部分から推定します。 時代が進むとスペースの数を注記するようになりますが、それが正しい保証はありません。
2K-BASIC の場合、作者の環境が(あまり)一般的でないと(編集部によって)判断され、画面レイアウトの改変などが行われたり、TK-80BS用に書き変えられた例もあるようです。 この場合、作者による記事,実行画面写真 と 編集部による実行画面写真,リストの注記 がごちゃ混ぜになっていることがあります。 (⇒ 編集部による改変)
ワークエリアを特定の値で初期化する必要があるけれど、その情報が無いことがあります。 また、ワークエリアの宣言も(掲載時に？)端折られていることが多いので、適宜補わないとアセンブルできません。 ROMルーチンのラベルなど、当時の「常識」は何の説明もなく使われていたりしますので、定義ファイルを作っておきましょう。
アセンブルリストは掲載されているのにデータが掲載されていない / 部分的に欠落していることがあります。 これは実行画面の写真などを参考に補うしかありません。
印字リストは印刷(原稿)の状態が良くないことが多いです。 判別に迷った部分を後から振り返ってチェックするのは困難です。 DMPファイルで打ち込む場合は、コメントを付けながら入力することをお勧めします。 迷った文字を [0/O → o], [1/I → i], [E/F → e/f] など 英小文字で仮入力しておくのも手です。
といった傾向があるようです。
同一文字の問題は、罫線表現でよく出会います。 実行画面の写真があれば確認した方が良いと思います。 他の罫線部分と比較するのも手ですが、作者さんの几帳面さに左右されるので、揃っているのが正しいとは限りません。
ドットの少なさも相まって判別が困難なケースがあります。
画面出力の文字列については実行画面の写真を参考にスペルミスか印字エラーか判断します
リストやダンプをCRT画面に表示したものを写真に撮って掲載することも一般的でした。 カナやグラフィック文字はコンピュータの機種毎の「独自」仕様(機種固有の文字)です。 英小文字に対応していないプリンタもありました。
画面写真リストの全盛期は「私だけのコンピュータ」から標準化されたものを皆が使う時代へ変わってゆく過渡期(TK-80BS のあたり)だと思います。 PC-8001 も発売直後は、機種固有文字等に対応したプリンタを用意できなかったのか写真で掲載した例があります。
画面写真リストの問題は、ほぼ編集作業によるものなので ⇒ [編集作業に由来する問題と対応] にまとめました。
キーボードからの入力と画面出力は、実装によって異なります。 BASICコードのセーブ/ロード機能はありませんので、それぞれの母艦のモニタ機能を利用することになります。
独自の拡張が多数存在しており、それを前提としたソフトでは適切な対応をしないと動作しません。
国内では 32桁x16行の「ビデオRAM」が複数種市販されていました。 64桁... (書きかけ)
定番としては、カーソル移動, 画面クリア, CALL命令, POKE命令, PEEK関数 あたりでしょうか。 同じ機能であっても予約語や引数の順番, 仕様にバリエーションがあります。 例えば POKE は アドレス,値 を渡すものの他に、x,y座標とASCIIコードを渡す VRAM専用のものがあります。 お使いの 2K-BASIC が作者さんと同様の拡張をしているなら、若干の調整で対応可能です。
u80 添付の 2K-BASIC ではゲーム用途の拡張なら大体網羅したつもりなので、書き変えなしで動作可能と思います。(要 MODE指定追加)
2K-BASIC (Palo Alto TINY BASIC) は、日本に紹介された際に独自のラベルが付けられました。 2K-BASIC を拡張する記事で、ソースコードがどのラベルを想定しているかによって... (書きかけ)
一画面に納まらないリストは複数回に分けて撮影し、編集作業で一連のリストとします。 ここで一部の行や行の一部が欠落したり、重複して掲載されたりします。 また掲載順が入れ替わっている例も見られます。 結果として行の一部が見つけにくいゴミとして、関係ない行に混在してしまうケースがあります。
画面毎に分けて掲載されている場合は、比較的再構成が容易です。
画面写真をまとめたリストの場合は、 画面の丸みによる歪やシャッターバーによる濃淡などで切り貼り位置を推定し再構成のヒントにします。
画面写真リストと同様に、切り貼り編集時のミスで行や行の一部が欠落/重複していることがあります。 切り貼り位置は微妙なずれなどで何となくわかることが多いので、注意して作業します。
ダンプリストの一部を切り貼り修正したのにチェックサムが放置されていた(と思われる)ケースがありました。
実行画面の写真から再現するしかありません。 一部でも判明すれば、記事の内容などから推定可能な場合もあります。 罫線の長さなど、統一されているであろう部分も推定して入力します。
どの機種の図形パターンか調べて、文字コードを割り出します。 同時に特定の文字(その機種で使わないコード)の欠落も想定する必要があります。
印字できない文字を写植や手書きで補ったケースがあります。 追記漏れなどミスが多いので注意が必要です。
記事の内容と掲載リストの相違などから、編集部で大きく改変したプログラムに差し替えて(壊して)掲載したと思われるケースがあります。 改変の事実と内容を明示しているケースもありますが、そうでない場合は、 説明にある変数がプログラムに存在しない, 説明の行番号が無い/おかしい, オブジェクトサイズが違う, 操作キーが説明と全く違う等で気づくことになります。
前もって初期化等ひと手間書けないとうまく動作しないことも多く、仕様かバグか判らないのも困ります。 こういったものは、打ち込みミスなのか掲載コードのバグなのかの調査にも時間がかかります。
コンパイルさえ通らない場合、編集部で使っているコンパイラやライブラリが掲載(一般公開)されたものと違うバージョンを使用している疑いもあります。 このようなケースでは問題解決が困難なことが多いです。
原作からターゲットの機種や仕様を変更して壊しているケースもあるようです。
64桁仕様の 2K-BASIC 用のコードを 32桁の TK-80BS LEVEL-1 BASIC に書き直した例では画面レイアウトに一貫性が無く、バグか仕様か悩みました。 原作の 64桁版ではキレイにまとまっていた画面がぐちゃぐちゃなので、原作者が気の毒になりました。 原作(実行画面の写真)にはない綴りの間違いとか、もう少し何とかならなかったのかなぁ。 発掘隊の方針として「掲載リスト通りに入力する」という決まりがあるので仕方なくおかしいまま打ち込んでいますが、 余りに酷い改変が疑われるものについてはコメント等で注釈を入れています。
編集部の方針なんでしょうが、作者に無断で大きく手を入れて、原作者名のみの表示で公開するところもあったようです。 被害者さんから直接伺った話です。 勝手に壊して、バグの不名誉を引き受けるのが原作者って酷くないですか？これって著作権法違反じゃないのかな？
記事や実行画面写真などを総動員して打ち込みミスを直していくのですが、写真とリストで表示内容が異なっているケースを時々見かけます。
画面右側にスコアなどを表示することが多かったのですが、その一番上に書かれたタイトルが違っているケースが一番多かったかな？ こちらは作者さん本人による改変だと想像しています。 送ったテープに「旧バージョン, 新バージョン」が入っていて、編集部では気付かずに旧版で掲載準備を始めたって事故もあるかな～とは思いますが、 掲載が決まって写真撮影などと並行して編集者が作者に連絡を入れたら既にデバッグ版(タイトル表記も気まぐれに改変済み)があるよってことでリストはこっちを掲載。 当時の投稿者の話から、投稿してからかなり時間をおいて掲載されるケースがあったようなので、こんなやり取りを想像してみました。 なお、このケースでは大きなバグに遭遇した記憶はありません。
余談になりますが、投稿者本人は没になったと思い他誌に投稿したら両方採用され二重投稿だと怒られたとか、気の毒な事件もあったようです。 投稿規定には何か書いてあったんでしょうけど、何年も埋め草用のストックとして飼殺して発表の場を奪うのは良心的では無いですね。
これは作者さんが「送ったプログラムと違う」と声を上げないと発覚しないのですが。。。
一般的に、プログラムが何をやっているかは見ればすぐ分りますが、意図はなかなか解らないものです。 普通の経験値を持つプログラマなら迂闊に触らないという程度の知恵は持っているものなのですが、 すぐに手を出したがる若い上級者さんがいるのです。 という訳で、編集部のバイト君が「変なとこ見つけたから直しておきました」案件でFA。
機種やバージョンの違いに関する知識がなく、編集部の環境に合わせて壊してしまっている例もあると思います。 証拠としては弱いかもしれませんが、PC-8801 の Nモードだとうまく動かないプログラムに文句を言ったり、 PC-8801mkII だとエラーになるプログラムに「エラーはちゃんと取ってから送れ」って説教してる編集者を見かけました。
テストプレイでハイスコアなどを上書きした状態のダンプリストを掲載してしまう様なケースです。 ランカー名などから明らかに初期状態と思われる掲載写真と違うのに気づいて発覚します。 発掘隊としては「掲載リスト通り」の方針に従い汚染されたものを掲載しますが、オリジナルも復元して保存したいですねぇ。
clear宣言のミスなどでプログラムが破壊されていることがあります。 ダンプ・プログラム(チェックサム・プログラム)実行時に壊している可能性もあります。 壊された部分がメッセージデータで画面写真が掲載されているなど、運が良くないと復元できません。
月刊マイコンで１件ありました。 1986年に久しぶりに掲載された PC-8001用のソフトなので、ダンプ・プログラムも、バイト君が「探すより作った方が早い」とか何とか言ってやらかしたのでしょうか？ 1byte 後ろにずらせば良かったのですが、チェックサムを利用するために手数がかかります。(先頭の 1byte は不明)
BASIC等のリストを見易くする目的だと思いますが、スクリーンエディタによるリスト表示と異なり、 画面右端で折り返す際に行番号分のインデントを追加しているケースがあります。 専用のフォーマッタを介して印刷しているのだと思いますが、おかしな印字をするケースがあるようです。
具体的には、折り返し部分のスペースの数が狂ったり、予約語(中間言語を翻訳したもの)が正常に表示されないなどの不具合が出るケースがあるようです。 こういったリストでは、構文的に不自然な部分は無いか？実行画面写真と差異はないか？など、注意しながら打ち込んだ方が安全です。 後からおかしなところを探すのは大変なので。
入力作業の実態として、上の行を目盛り代わりにするとタイプミスに気づきやすいので、 スクリーンエディタの挙動と揃っている方が打ち込みには向いていると思うのですが、まぁ好みもあるので。 でも、壊すぐらいなら余計な事しなきゃ良いのにというのが正直な感想。
リスト抜けや無関係のリストが掲載されてしまったケースでは、デバッグ記事に正しいリストが掲載されない限り対応できません。 デバッグ欄に掲載できず「希望者へリストを郵送」という(今となっては)最悪の対応が取られたものがあります。 打ち込み発掘が無理な場合でも、カセットサービスによる補完の可能性など手を尽くして調べます。
打ち込んだ後に発覚すると心が折れるので、事前に問題が無いか確認して自衛するしかありません。 発掘隊のデバッグ情報はすべてを網羅していませんので「デバック記事が案内されていない＝問題ない」ではありません。 ご注意ください。
ゲーム以外では(打ち込んだ人が少ないので？)、動作しないレベルの問題があってもデバッグ記事が報告(掲載)されていないことがあるようです。
印刷のかすれを伴うことも多く、OCRの敵でもあります。 当時、コピー(ゼロックス)対策だと噂していました。
余談になりますが、ダンプリストは OCRを推奨しますが、それ以外は止めた方が良いと思います。 何度か書いていますが、BASICなどの間違いを後から探すのは難しいです。 結局コードを読みながら調べていくことになるので、打ち込みながら全体を頭に入れておくのが吉です。 これまでの経験から言えるのは、打ち込んであるものをチェックするとき、どうも、合っていることを前提に読み流してしまうというか、 想定していないような間違いは見つけられない傾向にあるようです。 それなりに経験のある人が打ち込んだ場合は、初期状態である程度整った形になる(ヘンテコな間違いは無い)ので何とかなるのですが、 OCRでは想像もつかない様な文字列になりがちなので、厳密に一文字ずつ確認をする必要があり、 人間の集中力では歯が立たないのでは？と考えています。 実際に OCRしたものを何度見直しても間違いが見つからず、自力で打ち直したものと比較して不一致点を潰していくことで仕上げたことがあります。 「…A<10)…」のような間違いは、想定していないと見つけられないものです。
増刊系は本誌デバッグコーナーが怪しいですが、改版時に直しているかもしれません。 訂正のペラ紙一枚が挟まっていたケースに遭遇した記憶があるのですが、どの本だったか覚えていません。 本誌デバッグコーナーを探すには、発行日を調べてあたりを付けます。
本誌デバッグコーナーに掲載するには大きすぎるプログラムは希望者に郵政封書で配布という例もあります。
発掘隊のコンセプトは「スクリーンショットをだらだら眺めて懐かしいソフトに出会う」です。 スクリーンショット重視ですね。 では、打ち込みはスクリーンショットが撮れる範囲で手を抜いているのか？と言われれば違います。
発掘隊の成果は、最終的には公開されるべきものと考えています。 そのため、電子的に利用可能な形で後世に残すことを想定して発掘作業を行うようにしています。
書籍やメディアの保存,活用は公的な図書館が担うべきと考えています。 一方で、掲載されたプログラムリストを利用可能な形で整備しておくというのは、彼らには難しいのではないでしょうか。 機材の調達, 予備知識の獲得, 道具(主にソフトウェア)の整備, 発掘作業の体系化など、ハードルはたくさんあります。
次の工程の「クリーニング」を単純作業とする布石として「掲載リスト通り」を重視します。
REM文も省略しないで、すべて入力します。 作者による綴りの間違いも「直して」はいけません。 プログラムを読んで内容を比較するなんてやってたら、いつまでたっても「正しい」確証が得られません。
字下げなどの調整のあるリストの打ち込み, クリーニングは難易度が高い傾向があるので、作業者を選んで実施します。 2K-BASIC世代のプログラムのように単純作業では整備が難しいものは、次世代に引き継ぐ前にFIXするよう努めます。
過去(実機時代含む)に打ち込んだテープ,ディスクを吸い出したものには、入力者が意図的に省略,改変した部分があることがあります。 それらを掲載リスト通りに復元することを「クリーニング」と呼んでいます。 発掘作業として新規に入力したもののミスを修正する作業も含みます。
BASIC で RENUMBER を掛けたもの、特定のDOS用の起動処理が追加されたり書き換えられたものなど、復元には知識が必要になるケースがあります。 次の工程で、知識のない人でも作業に加われる様にひと通りの修正を行います。
修正が広範囲に及ぶ場合は、新たに打ち込んでしまった方が早いかもしれません。 吸い出したものは(部分的な)比較に使えます。
注意深く打ち込み、動作確認したプログラムでも必ずミスがあります。 こういったミスは記事と見比べてチェックしても見落としがちです。 そのため、現状ではほとんどのものがクリーニング作業後に塩漬けになっています。 運良く複数の入力データが入手できたもののみ、比較により「完品」を確認しています。
発掘隊にスクリーンショットが無い物を選んで提供してくださる方が多いですが、重複するタイトルも協力をお願いします。 こちらで確認してクリーニングしたものを返送します。
図書館等に本誌(記事)のアーカイブがあることを前提としています。 ただ、当時の常識的な部分の記述は漏れていることがあるため、何らかの方法でまとめておく必要があると考えています。
現状では、別途用意する必要のあるライブラリなどの情報のみ掲載しています。
(書きかけ)