|
Apple II Plus
Personal Computer
(1978) |
 |
|
2020年01月から次第に深刻さを増してきた新型コロナウイルス、
2020年03月27日には勤務先事業部従業員全員に可能な限り出社を控えよという、
前代未聞の指示が出ました。
3月に入ってからは基本的に在宅勤務をしていましたが、
社内SNSにこの指令が出たのを読んですぐさまオフィスに赴き、
必要な機材・資料を持ち出しました。
その日の夜第3研究所を一時閉鎖し、中央研究所に戻りました。 しばらくはメインワークベンチで在宅勤務作業を行っていましたが、テレコンが多い仕事柄、 家族の活動に干渉されて不都合が多いです。 ので、中央研究所開設以来12年間放置しっぱなしだった資料機材保管室を整理してオフィスにするための作業を始めました。 文字通り、偽りなく、一歩も足を踏み入れられなかった倉庫室に、数日後 椅子に座れるだけのスペースができ、 一週間後には暫定デスクができ、ラップトップコンピュータを使った軽作業が開始できるようになりました。 保管室改め「夢と時空の部屋」、稼働開始です。 2020年ゴールデンウィーク、夏休み、 年末から2021年新年にかけての休暇はすべて夢と時空の部屋の整理と環境改善作業に向けました。 そして2021年01月10日、とうとう最下層最深部から、アップルIIが発掘されました。 2021-01-10 Apple II 発掘 |
|
|
このApple II、10年ほど前に何かの簡単な計算をしたくて電源を入れたとき、
5分ほどは動いたのですがプログラムを書いている間にクラッシュし、その後動かなくなっていました。
おおかた電解キャパシタの劣化か何かだったのしょう。
劣化はさらに進んでいるでしょうから、
はたしてこのまま電源を入れていいものか。
動かないのはまだいいとしても、電源ユニット故障で過電圧が出てしまっていたら、
内部部品を焼いてしまうかもしれません。 このコンピュータを廃棄扱い品の譲り受けで入手したのは1988年。 その時以降33年間、内部を清掃した記憶はありません。 カバーをかける等していたわけでもないので、内部マザーボードは薄汚く埃で覆われています。 |
 |
|
本体の電源投入に先立って、
本体と一緒に譲り受けたグリーンモノクロモニタのテストを行っておきます。
高圧電源回路を持つブラウン管モニタは、古くなって傷んだことによる発火事故の可能性はコンピュータ本体より高いですから。
まあこのモニタが使えなくなっていたとしても、
NTSCコンポジットビデオ入力端子のあるブラウン管テレビは夢と時空の部屋に1台ありますから、
さほどに失望することもないでしょうけれど。 ビデオ信号ソースを用意し、汚れたビクター・データシステムズ製のモニタにつないでみると、 おお、モニタは正常に動作しています。 2021-01-11 ビデオモニタ単体テスト OK |
 |
|
マザーボード上には電解キャパシタは見当たりません。
青い小さな積層セラミックキャパシタがパスコンとして使われているだけ。
電源を入れてしまおう。
まずはフロッピィディスクドライブなしでテストするため、
Disk IIインターフェイスカード / パラレルポートインターフェイスカード / リアルタイムカレンダークロックカードは取り外して電源を入れました。
昨日まで使っていたかのような自然さで本体スピーカがピッと音を立て、
ビデオモニタに APPLE ][ のロゴとBASICのプロンプトが表示されました。
おお、ちゃんと動くじゃん。 記念に写真を撮り、いやー懐かしいなと思いながらBASICでHello Worldプログラムを入力していたら、 キーボード入力を受け付けなくなり、 その直後にテキスト画面が乱れてしまいました。 電源を入れなおしてもダメ、正常に起動しません。 これは10年前に発生した症状と同じ。 やはり長い年月で、壊れてしまっています。 永い眠りから目覚められたのはほんの3分ほどでしかありませんでした。 |
 |
|||
|
もうApple IIは使えないのかな。
でも、やり残したことがたくさんあるなあ。
1988年に自分でBASICプログラムを書いて簡易ワープロとして使っていた時も、
わからないことがたくさんあった。
遅いマシンだからその能力を生かすにはマシン語でプログラムを書く必要があるのにまったく着手できず、
いまでは伝説の名器となっているこの初期のパーソナルコンピュータの中身がどうなっているかいまだに全く理解できていません。
結婚した直後に大学のころの友人 - 高校生の時にApple IIを使い倒していた、私にとっては先生のような友人 -
が新居に遊びに来てくれて、お手製のApple II用ジョイスティックとゲームソフトをいっぱい土産に持ってきてくれました。
その友人曰く、
「このコンピュータは本当にすごいぞ。
ジョイスティックインターフェイスの回路構成とそれを読み出すプログラムを見てみろよ。感動するぜ。」
と。 17歳の夢とあこがれ、理解して使いこなしてみたいという征服欲と、 触れることさえかなわず、言葉の意味さえなにがなんだかさっぱりわからない当時の自分の情けなさ。 それに加え、ここまで来てみろよという30年前の友人からの熱い薦め。 でも私はどれも実行できていないままにいます。 Apple IIの凄さを、私はいまだにまったく理解できずにいるのです。 このままで終わらせることはできない。 あのとき見られなかった17際の夢の続きを、見てみたい。 ― よし、直してみよう。 2021-01-16 10年+ぶりに電源投入 最初は正常起動するもすぐに故障 システム起動せず |
 |
|
ラジオにしろアンプにしろコンピュータにしろ、古い電子機器が故障するのはたいていが電解キャパシタのリークあるいはドライアップ故障です。
Apple IIのメインボード
(いわゆるマザーボードですが Apple II Reference Manualでは "The Main Board" と表記されていますので本ページでは「メインボード」と書きます)
に使われているのはパスコンとしての積層セラミックキャパシタだけですから、
故障しているのは、まあ電源ユニット内部の電解キャパシタでしょう。 Apple IIの電源ユニットは製造ロットによって複数のモデルがあるようですが、 わがラボの個体に使われているのはA2M001型の電源ユニットでした。 アップル社自社開発自社製造のスイッチングパワーサプライです。 アルミ板曲げ加工で作られた匡体はリベットで閉じられ、「いかなる状況にあっても開けてはならない」と警告ラベルに書かれています。 むむ、確かに、開けてはならない状況ってほんとどんな状況なんでしょうね。 リベットをドリルで揉んでケースを開けると、 内部はきれいで、目視する限り液漏れや素子の焼け・変形などは見受けられません。 外装フィルムが縮んだ電解キャパシタはありますので、詳細なチェックは必要かもしれませんけれど。 この電源ユニットは、単体無負荷では正しい出力電圧は出さないタイプです。 適切な負荷をつないで初めて定格電圧を出します。 したがって電源ユニットのテストをするためにはなにか適当な負荷を探さないといけません。 ジャンク箱・部品在庫箱を開けて眺め、いろいろ考えます。 いっぽう電源ユニット単体の調査を進めるのと並行して、正常な電源でメインボードを動作させてみるという作戦もありますね。 ±5Vと±12Vを出せる都合の良い電源ユニットの在庫は…ああ、このコーセルの電源ユニットが使えそうだ。 この段階で、電源ユニットを取り外してすでにほぼまる一日、あれこれやっています。 でも、まてよ、あれ? なにかまず最初にすべきことを忘れているような気がする。 A2M001電源ユニットのケーブルをメインボードのコネクタにつなぎ戻して電源スイッチをONにし、 メインボード電源コネクタピンでの電圧を測ってみると、 うん? +5Vも+12Vも-5Vも-12Vも、 ぜんぶ正常じゃん? 2021-01-17 A2M001電源ユニット内部点検 異常なし 正常動作を確認 |
  |
|
メインボードには正しい電源電圧が与えられているのに、システムが立ち上がらない･･･
まずはシステムクロックが正しく生成できているかどうかを調べるべきでしょうか。 でも考えてみれば、ビデオモニタには乱雑なキャラクタが…「ｿｿｿ」とかが表示されています。 それに、複数個所にあるものの、カーソル点滅している文字もあります。 これはテキストビデオメモリがスキャンされ、メモリの値に応じた文字の形を取り出して、 それをテレビ画面に表示するためのNTSCコンポジットビデオ信号を正しく生成できているということです。 つまり、キャラクタジェネレータを含むビデオディスプレイ回路は正常に動作しているのです。 ということは、ビデオディスプレイ回路に必要なクロック周波数は正常に発生できているわけです。 Apple IIのビデオ回路は、マイクロプロセッサとは完全独立で動作し、 RAMのうちビデオメモリとして割り当てられたアドレスレンジをサイクルスチールで共有しています。 これは、プロセッサクロック信号が正のサイクルのときにはCPUがメモリをアクセスし、 クロックが負のサイクルのときにビデオ回路がメモリをアクセスすることによって実現されています。 そしてビデオ回路が正常に動作しているということは、 プロセッサクロックもまた正しく所定の周波数で動作しているということ、のはずです。 リファレンスマニュアルを読んで、Apple IIのシステムクロック信号がどのように生成されるかを調べました。 うーん、すごい。 廃棄扱いの本機を譲り受けた1988年のときはリファレンスマニュアルに付属している回路図なんてチラ見しかしなかったし、 チラ見以上の理解はできませんでしたけれど、今読むと、これはすごい。 Apple IIは、そのCPUである6502のプロセッサクロック1MHzのほか、NTSCビデオのカラーサブキャリア周波数の3.579545MHz、 ビデオ回路を動作させるためのサブキャリア周波数の倍の7MHz、DRAMのRAS/CASのための2MHzを、 たったひとつのマスターオシレータから巧みに生成しているのです - しかもすべて標準TTLロジックチップだけを使って。 ウォズの天才設計のひとつのなのでしょう、BOMコストは明らかに最低限に抑えられていますし、 マウンテンビューのパーツショップで買える部品だけでできあがっています。 マスターオシレータの発振周波数は14MHzですが、 ここからカラーサブキャリア周波数を生成するため、これは正確には 3.579545MHzの4倍の14.31818MHzになっています。 念のために1MHzのプロセッサクロックφ0とφ1をメインボード上の複数個所で - 6502プロセッサのクロックピンも含めて - オシロスコープで観察しましたが、きちんと1MHz (正確には測定していませんが 1.020484MHz のはず) が出ています。 なお使ったのは夢と時空の部屋用に修理した 岩通SS-5702シンクロスコープ。 これはさすがに 6球真空管オシロ では不可能な測定です。 Apple IIの修理作業の準備として修理しておいたようなもの、かもしれません。 それでは電源投入直後に動作するハードウェアリセット回路がうまく働いていないのでしょうか。 Apple IIにはシステム拡張のためのペリフェラルスロットが8本装備されており、 主要なシステム信号が出ています。 リセット信号はペリフェラルコネクタの31ピンに出ているのでここをオシロで観測してみると、 電源投入直後にリセットラインはLOに落ち、ほんの一瞬遅れてHIに上がります。 これは正常な挙動。 6502プロセッサのリセットピンは一番端の40ピン。 ここも同じ挙動です。 プロセッサのソケットの接触不良ということでもありません。 よって、リセット信号は正常。 2020-01-17 プロセッサクロック1MHzとリセットラインの正常動作を確認 |
  |
|
さあて、いったいどこが悪いんだろう。
皆目見当がつかない。
何かどこかに手掛かりはないものか。 プロセッサが死んでて全然動いていないのかな。 ひきつづき、ペリフェラルコネクタに出ている信号線をひとつひとつ、オシロで当たっていきます。 すると、データバスやアドレスバスの中に、ピコピコ動いているラインがあります。 どうやらマイコンは何かしら動いている様子。 ロジアナかデジタルオシロでもあればどんな動きなのかより正確にわかるのでしょうけれど、 中学の実習用みたいなシンプルな岩通のシンクロスコープではそんな観測は無理。 分かる範囲で観察を進めます。 割り込みラインやノンマスカブル割り込みラインが落ちっぱなしということもありませんね。 すると、あれっ、これは? アドレスバスAD15のラインが、ロジックHIでもロジックLOでもない、1.9V固定になっていますよ? AD15はアドレスバスの最上位ビットですから、プロセッサがROMを読もうとすれば必ずHIになるはずだし、 RAMを読もうとすればたいていの場合はLOになるはずです。 これがHIでもLOでもない中間値で固定だったら、 デバイスが結果としてそれをHIと解釈するにせよLOと解釈するにせよ、 メモリから正しくデータを読み出せるわけないじゃん。 これは大きな手掛かりだ。 Apple IIの回路図を読み、アドレスバスAD15ラインの接続を調べます。 6502プロセッサの25ピンに出てくるアドレスラインA15の電圧は、トライステートバッファH4 8T97に入って、 システムアドレスバスAD15電圧が生成されます。 AD15は2つのアドレスデコーダ回路に入ります。 AD15はほかにも8本のペリフェラルコネクタに配られていますが、 いまはペリフェラルスロットはすべて空で何も装着されていません。 すると、トライステートバッファが壊れているか、 あるいはアドレスデコーダに異常があるか。 2021-01-18 アドレスバスAD15が1.9V固定になっていることを確認 |
 |
|
トライステートバッファ 8T97 のチップ故障でしょうか。
聞きなれないICなのでぐぐって調べてみましたが、意外にも現在でも入手は可能な様子。
8T97はメインボード上で3つ使われています。
AD15を受け持つ8T97を、別の8T97と入れ替えました。
もし8T97が故障しているのであれば、今度はAD15ではない違うラインが1.9V固定になるはず。
しかし相変わらずにAD15が1.9V固定のまま。
8T97トライステートバッファチップは故障していない、と判断できます。 こんなチェックが簡単にできるのも、すべてのICがソケット装着されているApple IIの美点。 ウォズニアックは 「ぼくは大のソケット好きなんだ。開発中にうっかりチップを焼いちゃってもすぐに交換できるからね」 と 自著"iWoz"の中で書いてます。 ウォズに賛辞を送りながら次に、RAMアドレスデコーダでAD15を受け取るチップ、 J1 74LS257 トライステート・データセレクタ/マルチプレクサICをソケットから抜いてみました。 すると、AD15ラインの電圧は正しく0-4Vでスイングしています。 ついで、74LS257でAD15がつながる13ピンを折り曲げ、このピンだけがつながらない形でICを刺しました。 AD15電圧レベルは正常。 原因判明。 J1 74LS257のB4入力ANDゲートのIC内部入力回路の故障。 2021-01-18 RAMアドレスデコーダ J1 74LS257 のデバイス内部故障と確定 |
 |
|||
|
74LS257の部品在庫はないので、ネットショップで注文します。
毎度のことながら、ICひとつ注文したのでは送料が高くつきすぎに感じられていまうので、ほかのパーツもあれこと同時に注文。
今回74LS257の内部で壊れているのは単なるANDゲートなので、74LS08があれば代替回路を作って試すことができます。
けれど、74LS08の在庫もありません。
今後使うかもしれないから一緒に発注しておこう。 翌日、ブレッドボードと在庫のTTLロジックICを組み合わせて、故障したLS257のANDゲートの代替回路をつくることを数時間試みましたが、 どうしてもうまく行きませんでした。 複数のゲートを重ねてANDゲートを作ったのでは、遅延時間とかグリッチが出ちゃうとかでうまくいかないのかな。 まあ、部品が届くのを待とう。 2021-01-19 故障したLS257のANDゲートを代替外付けロジックで動作させる試みはうまくいかず |
 |
|
発注した部品が入荷しました。
初めて使ったショップだったけど、早いね、梱包も好感が持てるし、またいつか頼もう。
で、ワクワクしながら新品のLS257を刺して電源ON･･･でもやはり起動しません。
うう、まあ、お約束ってものですね。 2021-01-21 LS257を新品に交換するが動作せず ともかくAD15ラインは正常なロジックレベルで動くようになったし、 起動後の画面の乱れのパターンも当初とは違ったものになっています。 一歩前進、なのには間違いありません。 電源スイッチを入れても画面は乱雑なテキスト、スピーカのビープ音も鳴りません。 ということは、やはりリセットルーチンが動けていないのでしょう。 システムに電源が入り、ごくわずかな時間の後にリセット信号が解放されると、 6502プロセッサはあらかじめ決められたメモリアドレス - $FFFC番地と$FFFD番地 - を読み込み、 そこに書かれているアドレスをリセットベクタとしてジャンプします。 Apple II では - 他の6502コンピュータでもそうでしょうが - $FFFC番地と$FFFD番地はROMになっています。 Apple II ではそこはメインボードに装着されたシステムモニタROMの一部で、 リセットベクタのジャンプ先はモニタの中のシステムスタートアップルーチン。 それらはいずれもアドレス$FB00番地より上にあり、 メインボードに装着されている6個のROMチップのうち一番左側の"F8" ROMの中に焼かれています。 それでは、起動直後、このROMチップ F8 はアクセスされているのでしょうか? F8 ROMチップ は 9316B 2kx8 マスクROM であり、3本のチップセレクトピンを持っています。 最初に18ピンのCS2をチェック。 これはシステムバスのINHであってこれがLOに落ちている間はメモリアクセスが禁止されますが、 安定してHIレベルにいます。 つぎにCS1とCS3。 この2本はメインボード上でつながっていて、ROMアドレスデコーダによって制御されます。 プロセッサが$FB00〜$FFFF番地をアクセスするとき、"F8" ROMチップのCS1とCS3がLOに落ち、そのROMが選択される仕組みです。 でもオシロで観察してみると、CS1とCS3は、HIレベルのまま。 モニタROMがアクセスされていないじゃないか。 Apple II は6502がサポートするメモリ空間64キロバイトの全域をサポートしており、$0000から$BFFFまでの48kがRAMに、 $C000から$FFFFまでの16kがI/OとROMに割りつけられています。 ROMアドレスへのアクセスのとき、ROMアドレスデコーダのF12 74LS138が、6個あるROMチップのどれへのアクセスであるかを決定し、 対象ROMにチップセレクト信号を送ります。 が、"F8" ROMチップをセレクトする74LS138の7ピンはHIのまま。 74LS138 3-to-8 デマルチプレクサICの内部ロジック図を眺めて考えます。 LS138が出力を出すためには、出力イネーブル条件が揃う必要があります。 出力イネーブル条件がそろっていないときは、LS138はHIを出力し続けます。 その出力イネーブル条件とは、4ピンと5ピンがLOで、6ピンがHIのとき。 オシロで観てみると、4ピンと5ピンにはプロセッサクロックφ1が来ていますが、 6ピンはLOのままです。 あれえ? |
  |
|||
|
LS138の6ピン、G1イネーブルは、アドレスバスAD14とAD15のANDで生成されます。
アドレスバスAD14とAD15がともにHIのときに、LS138がイネーブルになるわけです。
アドレスバスAD14とAD15がともにHIのときに、というのは、アドレス$C000番地以上へのアクセス、
つまりプロセッサがI/OかROMにアクセスしようとしたときです。
なるほど、この回路が「ROMをアドレス$C000〜$FFFFに割り当てている」のか。
初めて自分で買ったマイコンシステム東芝TLCS-80A EX-80を使い始めたときはマニュアルに書いてある「アドレスデコーダ回路」の意味がちっとも分からなかったけど、
いまなら分かるぞ! で、どうしてG1イネーブルがHIにならないのだろう。 AD14とAD15からLS138のG1イネーブルをつくるANDゲート H1 74LS08のピンを見てみると、 ANDゲートの2本の入力ピンがどちらもHIなのに、出力はLOのままだ! これじゃあROMがアクセスされないのも当然だ! でも先週、LS257の代替回路を作ろうと思ったのにANDゲートロジックIC 74LS08はラボに在庫は一個もなくて… だからLS257を発注する時に一緒に新品を5個買っておいたんだよ! すごいぞワイ! 74LS08を新品に刺しかえると･･･ APPLE ][ のロゴとBASICのプロンプトが出た!! 2021-01-21 ROMアクセス不能 - H1 74LS08新品交換で回復 |
 |
|
実は電源入れても5回に1回くらいしか正常に立ち上がらなくて、今日はその調査。
立ち上がっても途中で止まったりしてしまいます。
リセットリリースが早すぎるのかなと思ったけどそんなことはなさそう。 立ち上がらなかったり、途中でクラッシュしちゃったときにメインボードのあちこちをオシロで調べていくと、 異常が発生したときにはUSER1ラインが電圧1.7Vくらいに固定されてしまっていることが分かりました。 USER1ラインがLOに落ちると、メインボード上のアドレス$C000から$C7FFまでの動作が停止してしまいます。 さらに調べると、メインボードのUSER1ジャンパーランドの上に、ものすごく細い髪の毛みたいなのが落ちていました。 どうやらこれはテスト中に使ったリード線から抜けた極細の銅線だったようです。 指先で取り除いたら、その後は完全に安定して動作するようになりました。 2021-01-22 極細ワイヤ異物によるUSER1ラインショート 清掃して回復 |
 |
|
Apple IIは正しく動き出したものの、
ビクター・データシステムズ製モニタに表示されるテキストエリアの上下は画面をはみ出してしまっており、
またそのサイズも不安定。
これは、モニタ内部のV-SIZEトリマポテンショの接触不良、
あるいはその取り付け部のプリント基板に半田クラックが入っているのではないかと思えます。
絶縁棒でこのトリマに力を加えると正常に戻りますので。 いちど基板を取り出して清掃しながら点検してみたいところですが、いまはそのまま。 接触不良が発生するたびに絶縁棒でトリマを突っつく暮らしです。 2021-01-22 ビクター・データシステムズ M-100グリーンビデオモニタ VSIZEトリマ接触不良症状を現認 |
 |
|
ウォズニアックがその天性のエンジニアリングスキルで一般ユーザの手が届く価格のフロッピィディスクドライブ "Disk II" を開発するまで、
一般ホビイストがコンピュータプログラムやデータを保存するためにはカセットテープレコーダが広く使われていました。
1と0のビット列をオーディオ信号として出力してテープレコーダで「録音」してセーブし、
それを「再生」してコンピュータにロードする方法です。
Apple IIにもそのためのカセットインターフェイスジャックが用意されています。 ラボのApple IIにはDisk IIが装備されていますが、そのテストは先送りにしているので、 今は作成したプログラムをカセットインターフェイスを使ってセーブします。 本物のカセットテープレコーダを使うのが正統なのかもしれませんが、 今はNoobow9100F Windows10 PCのオーディオインターフェイスを使ってWAVファイルに録音し、それを再生することにします。 カセットテープレコーダではテープのワウフラッタ、いろいろな原因によるノイズや音飛びなどで、 データの記録再生にはトラブルが付きものでした。 Windows PCでデジタル記録すればそのような心配は一切なし。 プログラム名をファイル名としてメモしておけるし、頭出しもライブラリ整理も簡単、 もちろんネットワークで送受信することもできるわけですから、 プログラムを遠隔地に送るためにはカセットテープを郵便で送っていた当時に比べれば夢のような話です。 Apple IIのカセットインターフェイスでは、平均して1.3kbpsのデータ転送レートが得られます。 Twitterのビデオツイートを使えば、2分20秒の中で約16キロバイトまでの プログラムやデータを「ツイート」することもできます。 面白い使い方ができるようにもなりました。 2021-01-23 カセットインターフェイスでプログラムをセーブ/ロードする |
  |
|
カセットインターフェイスで外部からプログラムをロードしようとしてLOADコマンドを動かしたはいいものの、
外部からの信号レベルが弱かったりノイズが入ったりしてエラーが発生すると、
Apple IIのLOADコマンドはカセットデータがそろうのをずっと待ち続けてしまったりすることがあります。
これを中断させるにはキーボードのRESETキーを押せばいい･･･はずなのですが。 キーボードにRESETキーがある、しかもRETURNキーの真上に…とはいまではとうてい信じられませんね。 さすがにこのキーだけにはばねが追加されていてちょっと強めに押す必要があり、 指先がさまよっただけでは押されないように工夫されています。 それでもやはりうっかり押してしまう可能性は残っているので、 ランニングチェンジでCTRLキーとRESETキーを同時押ししたときだけリセットされるように変更されています。 ところがこのRESETキー、このApple IIを譲り受けたときからずっと、いくら押しても何も起きないのです。 CTRLキーとの同時押しでもやはり何も起きません。 ひょっとして以前のユーザは、大切な連続動作をさせているときにうっかりリセットされてしまうのが嫌で、 内部でこのキーの配線を切っていたのかもしれません。 プロセッサの特権レベルもOSのプロセス保護機能も全くないApple IIでは、ちょっとしたことで簡単にシステムはハングアップしてしまい、 リセットさせる必要があります。 しかしそのRESETキーが効かないので、 ラボでは個別スイッチつきAC電源テーブルタップを使って、ハングアップするたびにパワーオンリセットしています。 とはいえ、この先モニタやマシン語プログラミングを試そうとしたらそれこそしょっちゅうハングさせてしますことになりますので、 RESETスイッチを修理 (あるいはもしかしたら改造を復旧) することにしました。 |
 |
|||
|
まずは The Apple II Circuit Description を読んで、RESETキーの回路を調べてみます。
右図に抜粋したRESETキー回路図で、いちばん左に見える "□3" は、キーボードコネクタの3ピンを示しています。
これはシステムのリセットラインそのもので、6502プロセッサやすべてのペリフェラルボードコネクタ、
ならびにマザーボード上のいくつかのICに接続されています。
この/RESETラインがローレベルに落ちるとプロセッサならびにシステムはリセットされ、
/RESETラインがHIレベルに戻るとシステムは動作を始めます。 本体外装カバーを取り外し、キーボードコネクタを取り外しました。 マザーボードだけで電源を入れ、キーボードコネクタの3ピンをGNDに落とすと、システムリセットか発生しました。 RESETキーが効かない原因はキーボード側にあります。 |
 |
|||
|
Apple IIのキーボードは、初期バージョンでは基板1枚のシングルピース・キーボードが、
途中からは基板が2枚のツーピース・キーボードが使われています。
ラボの個体はツーピース・キーボードがついていました。 キーが実装されている基板と、AppleII専用カスタムキーボードエンコーダICが積まれたエンコーダ基板を分離し、 まずはキー基板をチェックします。 こちらは単にON-OFFのスイッチであるキーが、基板間接続ピンヘッダコネクタにつながっているだけ。 テスタの低抵抗レンジで抵抗値を測り、RESETキースイッチそのものは正常だし、 キーからコネクタまでのパターン導通も問題がないことを確認しました。 ところでこのキー基板、ご覧のようにパターンカットとジャンパの加工が入っています。 いかにも素人臭い手つきで施されたこの改造ですが、 これはカタカナを入力できるようにするもの。 このAppleIIはJ-PlusではなくPlusですが、日本の輸入業者によりカタカナを取り扱えるように改造されているのです。 |
 |
|||
|
カスタムエンコーダICが搭載されたエンコーダ基板を調べます。
RESETキーとCTRLキーからの線はスイッチS1で一緒になってキーボードコネクタの3ピンにつながるだけです。
テスタで導通を調べていくと、変だな、ボード上も、キーボードとマザーボードをつなぐケーブルも、すべて正常に見えます。
ひょっとしたら接触不良がいじっているうちに直ってしまったのかもしれませんね。 2枚の基板を組み合わせて、キーボードケーブル先のコネクタ3ピンとGNDの間の抵抗値を見てみると、あれえ? RESETキーを押しても反応しません。 |
 |
|||
|
キースイッチボード単品ではRESETキーの動作は正常、キーエンコーダボードでの配線にも異常なし。
なのに、この2枚を組み立てると、RESETキーを押してもリセットは発生しません。 テスタで導通を見ながら配線をじっくり追っていくと･･･どうやらキースイッチボードとキーエンコーダボードとの間で、 RESETキー信号線だけがつながっていないようです。 年々ひどくなる老眼を罵りながら虫眼鏡で見ていくと、ふたつのボードをつなぐピンヘッダコネクタのメス側ターミナルピンが変形していて、 RESET信号のピンだけ接触していないことが分かりました。 |
 |
|||
|
ピン曲がりを修正できないものか精密ドライバで試してみましたが、
ありゃ、ピンがぽろっと折れて落ちてしまいました。 |
 |
|||
|
片側にヘッダピンがついているおあつらえ向きのリード線があったので、これを使ってRESETキー端子からヘッダピンまでジャンパーを飛ばしました。
もし次回2つの基板を分離するメンテが必要になったときも、半田こてを使わずに簡単に分離できます。
キーボードをつないで試すと、きちんとCTRL+RESETキー押下でリセットされました。 意図的にRESETキーを効かなくするための手立てならもっと簡単なものもあるでしょう。 このコネクタピンの変形は、ひょっとしたら日本のベンダでキーボードのカタカナ対応改造が行われた時の作業ミスなのかもしれません。 そして、だとすると、1978年か1979年か、このコンピュータが新品で納品された時からすでにRESETキーは効かなかったはず。 本体背面の電源スイッチが妙に使用感あふれてシーソーレバー表面の刻印が消えかかっているのも、 プログラムが暴走するたびに電源スイッチを入れなおしていたのだとすれば納得がいきます。 そして今、新品納品から43年経って、ようやく設計意図通りにRESETキーが効くようになった、ということなのかな。 2021-01-24 RESETキー効かず故障 修理完了 |
 |
|
グリーンモノクロモニタで使っている分には当然まったく気にならないのですが、
このApple IIのビデオ出力をビデオ入力端子付きカラーテレビにつないでみると、
テキスト画面の文字にひどく色にじみが出てしまいます。
読めなくはないんだけれど、なんだかなあ。 Apple IIのカラーグラフィックスハードウェアは汎用TTLロジックチップだけを使い、それも最小限の部品点数で実現するように設計されています。 ホビイストにも一般個人ビジネスマンにも手が届く価格のコンピュータでしかもカラーグラフィックスが使用可能、 というのはそれだけでセンセーショナルでエポックメイキングな製品だったわけです。 が、本来ならば信号の精密な位相管理を必要とするカラービデオ信号処理ゆえ、 可能な限り簡略化したApple IIのカラーグラフィックス回路では不完全な部分も当然出てきてしまっていました。 この問題は初期型Apple IIですでに課題として挙がっていました。 |
 |
|||
|
ウォズはこの対策として、Apple IIメインボードのRevision 1で、カラーキラートランジスタを追加しています。 カラービデオ信号の各フレームには、受像機側でカラー副搬送波周波数3.579545MHzの同期を取るため、 カラーバーストと呼ばれる信号が入っています。 カラーバーストはまた、ビデオ信号がカラー信号なのか白黒信号なのかを判断するためにも使われます。 カラーバーストがないとき、受像機は白黒ビデオであると判断し、受像機内部のカラーキラー回路を動作させます。 これによって、白黒番組を観るときには画面に色を出さず、きれいな白黒画面になります。 Apple II Revision 1以降のカラーキラートランジスタは、テキスト表示モードのときにのみ作動します。 カラーキラートランジスタは、ビデオコンポジットトランジスタに入る直前でカラーバースト信号をシャントし、 よってビデオ出力信号にカラーバースト信号が含まれないようにします。 ラボのApple IIでは、カラーテレビにつないだ時にテキストに色にじみが酷く出るわけですが、 これはApple IIのカラーキラートランジスタが働いていないということなのでしょうか? ビデオコンポジットトランジスタのベース波形を見てみると、いや、カラーキラートランジスタは動作しているようです。 テキストモードのとき、ビデオ信号のカラーバースト信号レベルは大きく低下しています。 ではなぜラボのシャープ製カラーテレビではカラーキラーが働かず白黒テレビ動作にならないのだろう? どうやらApple IIのビデオ回路とそのメインボード上でのパターン設計 - プリント基板上での配線の引き方 - では、 3.579545MHzのビデオリファレンス信号がどこかから、あるいはさまざまな経路で、 ビデオコンポジットトランジスタにまで到達してしまっているものと思われます。 そのため、カラーキラートランジスタでカラーバーストをシャントしてあっても、 ビデオ出力に3.579545MHz成分が重畳してしまっているのではないかと思われます。 そしてそれをカラーテレビ受像機がカラーバースト信号と認識してカラー動作をしてしまっている。 Apple IIメインボードの回路図を見ると、Revision1でカラーキラートランジスタが追加された後、 つづくRevision 7ボードの、それも後期生産型で、 カラーリファレンス信号がカラーバースト生成ゲートに達する手前で遮断するゲートが追加されています。 さらに最終のRFI Revisionボードでは、 ずっと手前の段階でテキストモードのときはカラーリファレンス信号を遮断するゲートロジックに変更されています。 おそらくテキストモードで文字の色滲みが出る問題は、 Apple IIプロダクトライフの末期まで、完全には解決できずに引きずっていたトラブルだったのでしょう。 メインボード最終リビジョンのRFI Revisionと同様の回路構成になるように改造すれば、 テキスト色にじみの問題は改善できるかもしれません。 |
 |
|||
|
いっぽうApple IIのメインボードを眺めると、
プリント基板の配索パターンの流儀は、低速デジタル回路時代のそれです。
パターンは細く、引き回し長/ストレー容量/パターンのインピーダンス/結合/反射/遅延時間あるいはグラウンドカードやシールド線プレートの採用などといったアナログ回路的な設計配慮はほとんど見られません。
システムクロックが1MHzという現在からすれば極めて低速なデジタル回路なのでそれで何とかなっているわけですが、
数MHzで動作するアナログ回路では悪影響が無視できなくなっている、
ということなのかも知れません。
グラウンドインピーダンスを下げたりシールドを確実にするとかいうアナログ回路的な対策が必要なのかもしれません。 あるいは･･･そうだ。 テキストモードではカラーキラートランジスタがカラーバーストを抑制しているのだけれど、 いろいろな経路で混入してきた弱く乱れた3.579545MHzが漏れ出て、それをテレビがカラー副搬送波として同期しているのだとしたら、 そんなノイズに近いような信号に同期を取らせるのではなくて、 しっかりとカラーバーストを出してやった方がむしろきれいにカラーが出るのかもしれない。 カラーキラートランジスタ 2N3904のベースに入っている抵抗を切り離してトランジスタがONにならないようにしてみると、案の定。 完全な白黒になったわけではなくて文字のふちにわずかに色がついて見えますが、 当初よりはずっとすっきりした白文字が得られるようになりました。 しばらくはこれで行こう。 2021-01-24 テキスト表示時の色にじみ対策としてカラーキラートランジスタをディセーブルしてみる |
 |
|
どこもかしこも埃で汚れていたメインボードは、
起動不能の修理をしながらあちこち綿棒とアルコール洗浄液を使ってちまちま拭き、
それなりにきれいになってきました。
キーボードの修理をするために外装ケースを取り外しましたので、
キーボードの下で今まで指が届かなかったフロント寄りの部分も清掃。 そんなことをしていたら、ツイッターのタイムラインに #見た人もなにか無言でLチカあげる というハッシュタグが流れてきたので、 ゲームポートのアナウンシエータ出力を使ってLチカを作ってみました。 メインボードのゲームコネクタには、スイッチ入力・ジョイスティック入力のほか、 2つのデジタル出力ポートが用意されています。 たった2ポートではありますが、 これを使って外部装置の制御プログラムを書くこともできるわけで、 これがあればコンピュータの応用範囲が格段に広がりますね。 1988年に入手したとき以降アナウンシエータ出力は一度も使ったことがありませんでした。 今回が初めて。 ひょっとしたらこのコンピュータが製造された1978年以来、初めてアナウンシエータが動作したのかもしれません。 今日はApple IIの外装ケースとお風呂に入って、 シンプルグリーン原液とスポンジとたっぷりのお湯で洗ってあげました。 この時代のプラスチック材料は優秀な紫外線褪色防止剤も自由に使えたのでしょう、 PC-9801に見られるようなみっともない黄ばみは見られず、 すっきり新品同様になりました。 2021-01-24 本体ケース洗浄清掃 |
  |
|
Apple II本体が安定して動作し始めたので、Applesoft BASICでプログラムを書いてみます。
さすがに33年も経ったのでいろいろ忘れてしまっていました。
マニュアルを参照し、思い出しながら、あるいは新たに学びながら。 ラボのApple IIは、長い間生産が続けられたApple IIシリーズの第2世代、Apple II Plusです。 初期型Apple IIはオンボードソケットのROMに、スティーブ・ウォズニアック自らの手によるInteger BASIC - 整数型BASICを搭載していました。 マイクロプロセッサプログラミングを理解していない一般ユーザでも、BASICで自分でアプリケーションプログラムを書くことができましたが、 取り扱うことのできる数値は整数に限られていました。 浮動小数点数を扱うためにはROMで提供されている浮動小数点パッケージを使う必要があり、 入門プログラマにはなかなか困難なことだったのです。 改良モデルApple II PlusはオンボードROMに浮動小数点演算をサポートし、 高精細グラフィックスを簡単に使えるコマンドを持ったBASICを搭載しています。 これはApplesoftという呼称を持っています。 Applesoft BASICはスティーブ・ウォズニアックによるものではなくて、 Microsoftが開発しました。 浮動小数点と高精細グラフィックスが手軽に扱えるApplesoftにより、取り扱えるアプリケーション分野も大きく広がりました。 一方でApplesoftの処理速度は高度に最適化されたウォズの整数型BASICに比べれば明らかに遅くなってしまいましたし、 整数型BASICとApplesoftでは互換性のないコマンドや文法も多くあります。 のちに出たAppleDOSを使えば、整数型BASICとApplesoftを簡単に切り替えることができ、 整数型BASICからApplesoftへの書き換えの必要も減りました。 BASICを使えば初めてコンピュータを買った入門ユーザがすぐに自分の課題を解決し手助けしてくれるプログラムを自分で書くことができた･･･ それまでには不可能だったことを可能にしてくれたのですから、その恩恵は計り知れないものがあります。 プログラミング言語としての体裁が未成熟であり言語仕様として酷いものであるとしても、それを揶揄するのは愚かな学者の浅はかな行いでしょう。 とはいえ、今になってApplesoftを使ってみると･･･ こりゃあポンコツだわ。 変数のスコープがなくすべてグローバル変数の扱い、なのは初期のBASICはそういうものだったのは良いとして、 ジャンプ先・分岐先指定にラベルが使えない、変数名で認識されるのは先頭2文字のみ、 予約語を部分に含む変数名は使えない、IF文にELSE節がない･･･などはさすがにキツく、 読みやすくわかりやすくデバッグしやすいプログラムを書こうとすると大きな支障になってしまいます。 (注: 「無理です」の意。) 加えて、剰余演算子がない、ビット演算子がない、HEX$がない、PRINT USING文がない、LINE INPUT文がない、DATA文の読み始め先頭指定ができない･･･と、 ないことづくめで、機能の制約も大きいものです。 それをすべて甘んじて、与えられたものの中で最大限の工夫をし、それを楽しみ、 いままでは手に入れられなかった価値と恵みを享受する。 それが正しいApplesoftの使い方なのだろうと思います。 |
  |
|
本機に装備されていたリアルタイムカレンダークロックカード "TIME II" は
カード上のニッカド電池でコンピュータの電源がOFFのときも時計が動き続けますが、
製造後40年も経っていますから電池は完全にダメになってます。
液漏れが皆無だったのは幸せなこと。
ジーエスバッテリーの優秀さに感謝。 1階のメインワークベンチをふと見ると、単三型ニッカド電池4本パックの袋入り新品が転がっています。 はて、もうここに何年転がっていたんだろうね。 なので今回はこれを使って、TIME IIの電池交換をします。 |
 |
|||
|
新品在庫のバッテリケースを使い、3本直列にして電池を装着し、
バッテリケースは両面テープでカードの半田面に取り付け。 大きなバッテリケースのために隣のカードと干渉してしまいますから、 このカードはデフォルトのスロット#7には取り付けられなくなってしまいました。 |
 |
|||
|
Applesoft BASICでTIME IIの日付時刻セット・表示プログラムを書きました。
へへっ、ウチのApple IIは時計が表示できるんだぜ! 日付・時刻は表示できるようになったものの、カードからデータを読み出して表示するのに約0.3秒を要しています。 BASICプログラムの高速化を試してみましたが、 1秒間に4回は無理でした。 この速度だと、連続更新しても秒の表示が変わる周期が一定にならず、 置時計プログラムとして使うには違和感があります。 せめて1秒に5回は表示更新するスピードが欲しいところです。 そろそろマシン語プログラミングを試す段階だな。 2021-01-26 TIME IIバッテリ交換 |
 |
|
クロック周波数わずか1MHzのApple IIでは、実用的なプログラムを書くにはやはりマシン語プログラミングが欠かせません。
高校生のときの東芝EX-80ではインテル8080のマシン語でプログラムを書くのが唯一だったから当然そうしたし、
大学では富士通FM-7で6809のマシン語プログラムを書きました。
でも見よう見真似の域でしかなく、マイクロプロセッサを理解して使いこなしているとは言えないレベルでしかありませんでした。
17歳の夢であった、「マイコンを理解してマシン語でプログラムを書く」に再挑戦するときかもしれません。
シンプルな6502なら敷居はきっと低いでしょう。 初期型Apple IIでは、6キロバイトのモニタROMの中になんとミニアセンブラが入っています。 これを使えば簡単にマシン語プログラムが書けそう、と思ったのですが、 ラボのは Apple II Plus。 電源投入してすぐにBASICが走る10キロバイトの「オートスタートROM」が使われていて、 その中にはミニアセンブラは入っていません。 なのでプログラム作成そのものは、実にクラシックな方式。 紙にニモニックを書き、インストラクションセット表を見ながら隣にオペコードを書きたしていく、 いわゆる手センブル方式です。 まあ今だからそこは別のコンピュータのエディタを使って… いや、この場合なら Libre Office Calcのほうが便利だな… それにしても手センブルだなんて42年ぶりだぞ。 Apple IIでは、アドレス$0300から$03F7まではユーザに解放されていて、最大248バイトまでのプログラムならこのエリアに入れられます。 まずは$0300始まりで小さなプログラムを書いて練習しよう。 わたしはいままで6502でマシン語プログラミングをしたことはありませんでしたので、 まずは6502プロセッサのプログラミングモデルを学ぶところからのスタートです。 昨年暮、書店の店頭で柴田文彦さん著の 6502とApple II システムROMの秘密 が発行されていることは知っていました。 ウチのラボのApple IIの発掘を予言されていたかのようにも感じます。 作業開始したその日に発注しておいたこの本を読み、 6502プロセッサとAppleIIプログラミングの方法を勉強していきます。 いやあ、それにしてもシンプルなプロセッサだなあ! |
 |
|||
|
マシン語プログラムの入力は、モニタを使って、キーボードでオペコードを十六進数で入力していく方式です。
Apple I 以前は、マイクロコンピュータのプログラム入力と言えば、
フロントパネルにずらりと並んだスイッチをパチパチ操作して1ビットずつデータをセットしていく方式でした。
それに比べれば、
ビデオターミナルディスプレイを見ながらキーボードで十六進入力できるというのは、10倍どころではない生産性の向上です。 Apple IIのモニタは、カセットテープへのセーブとロードもできます。 昔と違ってデジタル録音なので録音ミスや記録の不安定さが全くないのは本当に幸せなこと。 それに何より、モニタに内蔵された逆アセンブル機能がなにより頼もしい! 軽くてストロークの深いApple IIのキーボードをスコンスコンと打ち、 レスポンスの良いモニタプログラムを使ってのプログラム入力は、 原始的だし、生産性はとても低いものですが、 操作していて実に気持ちよく、そして楽しい!! ああだこうだ独り言をつぶやきながらデバッグを続け、 シンプルな "HELLO MIMA SAMA!" プログラムの完成。 2021-01-29 初6502マシン語プログラム完成 次いでTime IIの日付時刻表示プログラムのマシン語版を作成しました。 1回の実行時間は16.91msでした。 Applesoft BASIC版の20倍 高速ということになります。 さすがマシン語は速い!! 2021-01-30 Time II表示プログラム マシン語版 完成 |
 |
|
安定して動作しているApple IIですが、現状 ラボの他のコンピュータとのデータ交換の方法がありません。
CFやSDカードを使ったフロッピィディスクエミュレータのような製品が出回っているようなのでそれを使うのが一般的な解なのでしょうけれど、
なにかひとつ面白みに欠けます。
ラボのApple IIにはパラレルポートインターフェイスカードがありますが、
はたしてこのカードは双方向通信ができるのかなあ。
ゲームポートを使ってテレタイプインターフェイスを作る方法がマニュアルに掲載されていますのでこれはいつか試してみたいところ。 でもまずは、本体改造や特殊な部品追加なしにできる方法 - カセットインターフェイスでWindowsとデータ交換をする方法を試してみます。 カセットインターフェイス出力を録音したデータはWindowsのWAVファイルになっているわけですから、 この波形を解析して、データを取り出せばいいわけです。 さらに、任意のデータをカセットインターフェイスの波形として生成しWAVファイルを作れば、 それをApple IIに流し込むこともできるわけです。 さらに、Windows PCのオーディオインターフェイスをリアルタイムで動作させるプログラムを書けば、 Apple IIからWindowsにカセットインターフェイスでファイルを要求するコマンドを送り、 Windowsが自動的にそのファイルをカセットインターフェイスでApple IIに送り、ロードするといったことも可能なはず。 Disk Operating Systemならぬ Cassette Operating Systemもできそうです。 もっとも私はいまだにWindows PCのオーディオインターフェイスを使ってアナログオーディオ情報をリアルタイムに処理することは試したことがありません。 COSを実現したかったら、Windowsオーディオを制御する方法を学ばないと。 まあ最初の一歩は、Apple IIからWAVファイルにセーブした波形を解析して、データを取り出すことにチャレンジしましょう。 Apple IIのカセットインターフェイスがどのようにデジタル信号をオーディオ信号として出力するかはリファレンスマニュアルに描かれています。 これを読み、実際にWindowsで44.1kHz 16bit 2chで録音したカセット信号の波形を眺め、 どのようにして波形からデータを複合するかを考えます。 いきなりエディタでコードを書かず、まずはフロー図を書いてみるだなんてこれまた20年ぶりのこと。 プロダクトとしてのプログラム開発の仕事をしなくなってからもうそんなに時間が経っちゃったんだな･･･。 2021-01-31 カセットテープ信号 ビット種別判定ロジック設計開始 |
   |
|||
|
アイデア的には、
いまから21年前にエコラン車の走行データをとるためにつくったEX-Pulseプログラム
と同じです。 プログラムは、コマンドラインスタイルのWindowsプログラムとしてつくります。 開発環境は、EZPulseではTurbo Linix上のgccを使いましたが、 今回はこれまたずいぶん久しぶりに、MinGWを使います。 最新版MinGWをダウンロードしてNoobow9300/Noobow9200B/Noobow9100Fの3台にインストール。 いつでも、ちょっとした空き時間に開発を進められるようにします。 Cで実用プログラムを書くこと自体、本当に久しぶりです。 fgetc()の使い方などすっかり忘れてしまっていて、1994年の技術評論社のC言語辞典を引っ張り出して、 リハビリするようにプログラム開発。 Apple IIのカセットインターフェイスはハードウェアは実に素朴。 ただ信号レベルをトグルするだけです。 データのセーブもロードも、タイミングを含めすべてソフトウェアによって処理されています。 したがって突き詰めればそのロジックはとてもシンプルに実現可能なのでしょうが、 いまのWindowsマシンはApple IIとはけた違いなんてもんじゃない、10万倍以上の処理能力を持ちます。 なので、Windows側のプログラム - CassetteNetと名を付けました - は、 デバッグしやすさを主眼に置き、 処理速度は気にせず、 冗長な書きっぷりも気にせず開発します。 ステップ・バイ・ステップでのんびりと作業を進め、 カセットオーディオWAVファイルからバイナリデータを取り出すことに成功。 2021-02-03 カセットテープ信号からのデータ復号機能完成 |
 |
|||
|
今度は、Windows側で用意したバイナリデータをオーディオ信号に変換すること。
こちらは当然のことながら復号よりもずっと簡単にできます。 2021-02-03 任意のバイナリデータからカセットテープ信号を生成する機能 作成開始 生成したオーディオ波形は新しいWAVファイルとして出力するわけですが、 ここでチャレンジ。 WAVファイルの先頭にはRIFFヘッダという部分があって、その中にそのデータはWAVフォーマットであるということ、 どのようなエンコード方式でデジタル化されているのか･･･といった情報が入っています。 さらに、「このあとにつづく波形データは合計何バイト」というサイズ情報も入っているのです。 RIFFヘッダを書き出す段階では波形データの総バイト数は分かっていません。 いったん0かなにかを暫定的に書き込んでおいて、波形データを生成したのちにその総バイト数で書き換えるようかなあ。 今回は、波形データ部分だけをテンポラリファイルに書き出して、それが終わったらテンポラリファイルのバイト数を実際に数え、 それから本番WAVファイルにRIFFヘッダを書き出して、テンポラリファイルをアペンドする方法をとりました。 2021-02-03 RIFFヘッダ書き出し処理 実装 |
 1か所間違ってますね。 dLen = $001AEAA0 =1764000 = 44100 x 2 x 2 x 10 というのは、 |
|||
|
RIFFヘッダ書き出しルーチン、でーっきたっ!
WAVファイルを読み込ませると、ちゃんとWinAmpでピーギャー音が出ます。
さっそくApple IIのモニタでカセットからのデータロードを試しますが･･･
うまくいきません。
オーディオデータの再生が終わっても、モニタは完了のビープ音を出さず、
ロードが完了しないのです。 ちょっと考えて気づきました。 チェックサム最後に足してないや。 Apple IIからセーブしたオーディオファイル中のチェックサムを見て、 うん? これはどうやって計算されているのだろう? データ部のすべてのバイトの和をとると、 実際に生成されたチェックサムとは合いません。 単純な和の下桁ではないようです。 そこで、とても短いバイナリデータをApple IIのメモリ上に用意し、 それをモニタのカセットセーブコマンドでWindowsに取り込み、CassetteNetプログラムでデータを見て、 チェックサムの生成の規則性を調べてみます。 何回か試して、ははあ、こういうことらしい。 仮説を立てて、このデータからこうなるはず･･･と、うん、当たり。 データバイトを加算していくのではなくて、ビットごとに加算しているのですね。 バイト列の各ビットごとに和を取っていき、その結果を最後にビット反転しています。 結果として、チェックサムのビットnは、全データのビットnに1が偶数個あれば1、奇数個あれば0 となります。 これは手順的には、データバイトのXORを取っていって、最後に全ビットを反転すればできあがりです。 まあこんなのは今の時代、語り継がれる名機Apple IIのことですから調べればどこかに書かれているのでしょうけれど、 自分で調べて自力で見つけ出せればうれしいですね。 またひとつこのマシンが自分のものになった気がします。 CassetteNetプログラムのWAVファイル生成ルーチンにチェックサム生成ルーチンを追加して、 よーし、できた! これでWindowsから任意のデータをApple IIに流し込める。 2021-02-06 チェックサム計算方法調査・実装 |
 |
|
Windowsから任意のデータをApple IIに転送できるようになったので、
なにかモノクロのビットマップイメージを表示させてみます。 Apple IIに転送するデータは1バイト8ビットの各ビットに1ピクセルを対応させるシンプルな方式として、 横280ピクセル 縦192ピクセルで6720バイトになります。 元データをつくるため、 280x192ピクセルの24ビットカラーBMPファイルを用意して、 2値モノクロに減色しつつバイト列を生成するプログラムをCassetteNetの中に追加しました。 よーし元データができた、 そしてApple IIのメモリに転送できた。 ところで後で振り返ってこのページを書いていて思うのですが、 なんでこの機能をわざわざ自分でCプログラムとして書いたのだろう。 こんなのグラフィックスアプリでモノクロ減色して、 できあがったBMPファイルの中からデータチャンクだけバイナリエディタで抜き出せばいいじゃない。 こういうのは一人作業のデメリットですね。 いまこういうことをやってるよーって言いながらチームで作業していれば、 おまえそりゃ無駄だろ、試すだけならこういう手もあるだろうがって指摘してくれる仲間がいるはず。 一人作業では時として、いやけっこう頻繁に、 自分の思い込みにそれと気づかずひたすら本来不必要な作業を進めてしまうことがありますね。 Apple II電源の調査をしていた時もそうでした。 まあホビーであればその作業そのものが楽しくてやっているのですからそれで構わないですが、 コマーシャルビジネスではこの状況に陥っていないか絶えず自問すべきですよ > 自分。 で、Apple IIのApplesoft BASICで、転送したバイナリデータを高精細グラフィックス描画コマンドHPLOTを使って描くプログラムを。 おおお、描けた!! んあ、でもよく見ると、なんかどこかにバグがあるみたいですね。 8ピクセルおきに変な縦棒が表示されちゃってるし。 2021-02-06 Windows 10からBMPファイルをApple IIに転送して画面に表示することに成功 |
  |
|
今度は長文テキストを転送してみよう。
データバッファのデータをテキスト表示するプログラムを書いて、できたできた。 読み込ませるテキストは、Steve Wozniac著 "iWoz" から、Capter 13 "The Apple II" を。 そう、君はこうして生まれたんだよ、アップルII。 データ転送用バッファとしてシステム起動時に8キロバイトを確保していますが、 8キロバイトに収められるのは同書Chapter 13の3分の1にも届きません。 2021-02-07 Windows 10からテキストファイルをApple IIに転送して画面に表示することに成功 |
 |
|
いまだ手作業な部分が結構ありますが、とりあえずはApple IIとWindowsの間でデータ交換することが可能になりました。
ので、つぎは取り外しておいたフロッピィディスクドライブ、Disk IIを再稼働させます。 Disk II インターフェイスカードを目視点検。 汚れてはおらず、清掃はほぼ不要。 おそらく電源平滑用の小さい電解キャパシタが使われているので要チェックではありますが、 目視するかぎりは液漏れ等の異常は見受けられません。 Apple II本体とともにこのDisk IIを廃却品として譲り受けて使っていた1989年、 私にとってはDisk IIはなんとも古い、遅くて容量の小さなポンコツドライブにしかすぎませんでした。 しかしApple IIの生い立ちとその開発ストーリーを読んでこのドライブがいかに世界を変えたのかを知った今では、 このドライブが放つオーラと畏怖の念を感じずにはいられません。 1987年に発売されたDisk IIはドライブ1基とインターフェイスカードで595ドル (Wikipediaによれば2019年での2330ドルに相当するとか) という「低価格」で、 初めて一般ユーザが手にすることができるようになった高速・大容量の記憶装置でした。 グラフィックスディスプレイとキーボードで操作するコンピュータ本体、高速大容量の記憶装置、 そして確定申告の事務作業を大きく助けてくれる表計算プログラムVisiCalcのコンビは、 マイクロコンピュータをホビイストの楽しいおもちゃから実用不可欠なビジネスツールに変えました。 まさにパーソナルコンピューティング時代の幕を開けた装置だったのです。 そしてそれまで一般ユーザては手が届かなかったフロッピィディスクドライブの大幅な低価格化を成し遂げたのは、 オリジナルのShugart製ドライブの中にあった22個の制御用ICを2つだけ残してすべて取り払い、 代わりに最低限のハードウェアとソフトウェアでドライブを動作させるDiskIIインターフェイスカードの設計でした。 本来ならマイクロプロセッサをひとつ必要とするような複雑な動作が必要な機能を、 Disk IIインターフェイスカードはプログラマブルROMとわずかな数の汎用ロジックゲートICだけでステートマシンに組み上げるという 「エレガントかつ強力な」設計で実現しています。 開発者のウォズニアック自身が「ぼくの最高傑作」と呼ぶというこのカード。 時代を変えた製品がここにあります。 |
 |
|||
|
ドライブの中にも電解キャパシタはいくつか使われています。
おいおいチェックは必要になってくるでしょう。
Apple II本体メインボードと同様、ドライブの中にある「アナログボード」は、
ヘッドから読みだした微弱な信号を増幅してデジタルデータ化します。
ふつうのデジタル回路に比べれば数倍の神経を払って扱うべき繊細な電子回路。 |
 |
|||
|
フロッピィディスクドライブ下面のメカも観察しておきます。
うわあ、これはシンプルだ。中身はすっからかんじゃないか。 見えているのは、磁気ヘッドキャリッジを動かすためのカムディスクモータと、 ディスクを回転させるスピンドルのストロボ模様入りフライホイール。 ディスク回転モータのベルトはしっかりしています。 いい材料が使われているんですね。 しばらくスペアベルト探しはしなくても済みそうですが、 代替品を見つけるのは大変なんじゃないかなと思います。 |
 |
|||
|
中身の目視を一通りしたところで、実際にDisk IIをつないで試してみます。
と、まあ大方予想した通り･･･ディスクを読めません。
あれやこれや試して、手持ちの2〜30枚あるディスクのうち、ドライブ#1で読めるものがでてきました。
1988年当時に使っていたディスクです。
おお、Apple DOSが起動した。 で、あれっちょっとまって、Apple DOSでディスクにあるファイル一覧を表示させるにはどうするなんだっけ? DIRじゃないよな、MS-DOSじゃないんだし。 lsでもないな、Unixじゃないんだし。 FILES･･･は試したけどSYNTAX ERROR。それはN88BASICだったね。 Apple DOSのマニュアルを読んで･･･ああ、そうだ、CATALOGだ。 ドライブ指定は･･･ CATALOG D1とかCATALOG D2とかだ。 32年。 そりゃあさすがにすっかり忘れるよね。 しつこく試行を続けるうち、ドライブ#2でも読めるディスクがでてきました。 しかしいずれも動作は不安定で、読めたり読めなかったり。 それでも1989年当時に書いた自作簡易ワープロソフト、WORKCAPSULEが起動しました。 当時のテキストファイルもそのいくつかが読み出せました。 望みはありそう。 読めたものはその場ですぐ、カセットインターフェイスを使ってWindowsにコピーをとります。 でも、この様子じゃあそのうちまた全く読めなくなってしまいそうだな。 うまく読めない原因のひとつは、コレットハブ･･･フロッピィディスク中央の穴に嵌ってディスクをきれいにブレなく回転させるための中央保持具 ･･･ の動きが渋くて、ディスクが偏心したり傾いたまま回っているためのようです。 ドアを開けてディスクを抜き差ししなおして試したり、ディスクを一番奥にコンコン突き当ててやり直すとうまくいくことがあります。 2021-02-09 Disk II 再稼働 フロッピィ読み出しに成功 2021-02-12 オーバーヒートらしき現象を確認 |
 |
|
それまでの「フロントパネルにスイッチとランプがずらりと並ぶ」スタイルのマイクロコンピュータではなく、
「ディスプレイとキーボードを持つ」マイクロコンピュータシステムとして生まれたApple I は、
間違いなく初めて「パーソナル・コンピュータ」のスタイルを確立したマシンでした。
大評判のApple Iの量産モデルの開発に取り掛かったウォズは、
次期モデル Apple II が絶対に具備するべきものしてカラー・グラフィックス表示機能の開発に着手しました。
しかしマイクロコンピュータシステムそのものがまだまだ高根の花だったころに、
ホビイストのお小遣いやビジネスマンのポケットマネーで手が届く価格帯の製品にカラーグラフィックスを持たせることなど、
コスト的に暴挙とも思えるチャレンジでした。 それを実現したのはひとえにウォズが彼のエンジニアリングのコンセプト、 つまり「ハードウェアを極限までシンプルにし、複雑な処理をソフトウェアに行わせる」を突き詰めたからにほかなりません。 ウォズは280ピクセルx192ピクセルという「高精細」で、 かつ普通に考えればモノクロ表示がせいぜいのビデオメモリ容量とシンプルな回路で、 6色カラー表現を可能にする魔法のようなグラフィックスハードウェアを設計したのです。 本体搭載のApplesoft BASICを使えば、 マイクロコンピュータプログラミングの経験がなくとも、またハードウェア制御の方法を全く知らなくても、 テレビ画面に線画を描くことができました。 グラフィックスが簡単に使えるApple IIで多くの人がコンピュータゲームづくりに夢中になったし、 数値の羅列の表に比べ訴求力が段違いの折れ線グラフを簡単に描けるApple IIは、ビジネスコンピューティングの世界も拓きました。 |
|
ビットマップ画像データをApple IIに転送して描画する際、あらかじめWindows側でビットマップデータをプリ処理して用意するのではなくて、
WindowsのBMPファイルをまるっと流し込む方法に変更しましょう。
てかなんで最初からそうしなかったのだろう。 受け付ける画像フォーマットは、Windowsの非圧縮BMP、280ピクセルx192ピクセルの2値モノクロ形式に固定します。 WinCassetteNetでWindows BMPファイルをカセットオーディオとして送信、あるいは「再生」。 それをApple IIのモニタで指定したメモリアドレスに読み込みます。 でも毎回モニタを立ち上げて、バッファアドレスの先頭番地と最終番地を指定してカセット読み込みのコマンドを操作するのは面倒なので、 Apple II側のCASSETTENETプログラムにデータ受信機能を入れましょう。 これはApple IIモニタのカセット読み込みサブルーチンを呼び出すことによって実現しました。 データのロードが済んだら、つぎはバッファ中にあるWindows BMPを高精細グラフィックスに描画するBASICプログラム。 Windows BMPフォーマットのビットマップイメージでは、画面一番下のラインがいちばん最初に出てきて、 しだいに画面の一番上の方向にスキャンが進んでいきます。 これだとやはり不自然ですので、 描画は一番上のラインから始め、しだいに下に向かって描画が進んでいくようにしました。 描画はできるようになったのですが、いやはや遅い･･･ 1画面かかるのに17分を要します。 CPUは1MHzだし、BASICが遅いのは当然だけれど、 それにしても遅い。 最初は全ピクセルをひとつずつHPLOTコマンドで点を打ったのですが、 黒ならHPLOTを呼び出さないとか、白が連続している部分は横線一本をHPLOTコマンドを1回で描くようにするとか、 いろいろ工夫して3分35秒まで高速化できました。 でもBASICではその程度が限界かな･･･。 2021-02-15 BMP画像表示ルーチン高速化作業 3分35秒 Apple II高精細グラフィックスの横は280ピクセルなので、ビットマップでは1ラインは35バイトを使います。 が、Windows BMPフォーマットの仕様では、横1ラインのデータ長は32ビット(4バイト)の整数倍になるようにワードアラインされるようになっています。 なので、BMPのビットマップパート中で1ラインは36バイトで表現されています。 自分でいじってみるといままで知らなかったことに気づけますね。 2021-02-16 BMPファイルフォーマットのワードアラインメント仕様を再確認 今は白黒のモノクロ画像だけですが、 そのうちApple IIの6色カラーを使った表示にもチャレンジしたいですね。 それがApple IIの最大のウリであり、初期アップル社のリンゴマークの虹色の由来なのですから。 |
 |
|
外部から流し込んだ画像データを実用的な速度で高精細グラフィックスに表示しようと思ったら、
マシン語でプログラムを書くしかありません。
一画面をまるまる表示するのなら全体の処理そのものはさして複雑なものではないのですが、
Apple IIの高精細グラフィックスは、Apple IIを愛し知り尽くしたひとでさえ「変態グラフィックス」と呼ぶものなのです。 ビデオディスプレイハードウェアのシンプル化を突き詰めた結果、 ビデオメモリのアドレスの並びは一見して極めて変則的なものになっています。 画面上の特定の座標に点を打ちたいと思ったとき、ビデオメモリのどのアドレスのどのビットに1をセットすれば良いのかを知るには、 まるで呪文のような計算を行わなくてはなりません。 APPLESOFT BASICのHPLOTコマンドを使えばユーザはそのような煩雑さは一切なく任意の線を表示できるのですが、 APPLESOFTを使わずにマシン語で同じことをしようと思ったら、 天才と狂気が入り混じったウォズの変態グラフィックスに真正面から向き合わなくてはなりません。 Apple IIのコンピュータゲームを書いたプログラマはみなその試練に立ち向かい、 そして腕を競い合っていたわけです。 今からやろうとしているのはそういったゲームプログラマからすれば朝飯前のはずの動作 - 白黒2値の一画面を表示するだけ - ですが、 それでもそれができたなら、 まずはウォズの変態グラフィックスの理解の第一段階をクリアした、といえるはずです。 変態グラフィックスの仕組みの理解のために、 まずはApplesoft BASICで、 HPLOTコマンドを使わず、POKEコマンドでビデオメモリに直接データを書き込んで画像を表示するプログラムを書きました。 年老いた脳ミソを煮えたぎらせながらデバッグを続け、どうにか目的の機能が完成しました。 やったぜ、高精細グラフィックス、完璧に理解した! (注) HPLOT文を使えばBASICインタープリタがマシン語で処理しているところをすべてBASICで処理しているのですから、 速度は当然遅くなります。 最初に描いたこの画像では、1画面の表示に8分10秒を要しました。 でもあとは、同じ処理をマシン語で書きなおしていけばいいだけ。 さあて、どこまで高速化できるのでしょうか。 注: そういう意味です。 2021-02-21 バッファ上のWIndows BMPファイルをハイレゾグラフィックスのビデオメモリに直接描画するプログラムをBASICで作成 表示時間 8分10秒 |
  |
|
速度は二の次で動作検証のために書いたApplesoft BASIC版描画プログラムですが、
BASICのままでもう少し速くならないものか考えます。 BMPファイル画像ハイレゾビデオメモリ直接描画プログラムの中で結構な処理時間を必要としているのが、ビットオーダー反転です。 Windows BMPファイルのモノクロ2値非圧縮ビットマップフォーマットでは、データ中の各ビットがひとつのピクセルの白か黒かを表しており、 1バイトで横並びの8ピクセルを表現します。 このときバイト中のMSBつまりビット7がいちばん左、LSBつまりビット0がいちばん右のピクセルを示します。 いっぽうApple IIの高精細グラフィックスでは、1バイトが横並びの7ピクセルを表します。 ビット0からビット6までの7つのビットが該当ピクセルがON (点灯) か OFF (消灯) かを示していて、 ビット7はそのバイトの発光色パターンを指定するビットになっています。 この発光色パターンというのがApple IIのハイレゾグラフィックスの最大にクレイジーな部分なのですが、 説明するだけで気が狂いそうなのでここでは省きます。 問題は、Applie II ハイレゾグラフィックスでのビットの並びは、LSBのビット0がいちばん左、 MSB一つ前のビット6がいちばん右になっています。 つまり、Windows BMPファイルフォーマットとApple IIハイレゾグラフィックスとでは、 バイト中のビットオーダーが逆になっている、というわけです。 なので、Windows BMPファイルをハイレゾグラフィックスメモリに直接書き込んで描画するプログラムは、 何かの形でビットオーダー逆転処理を盛り込まなくてはなりません。 バイト中のビットオーダーを逆転する処理というのは単純に思えて、 案外に手がかかります。 C言語はそんな処理を行う演算子は持っておらず、 ビット演算処理とビットシフト処理をいくつか組み合わせて複数行のプログラムとする必要があります。 そういう命令をネイティブに持っているマイクロプロセッサは･･･ 近年のものはあるのかもしれませんが、 少なくとも6502はそんな命令はありません。 このAPPLESOFT版プログラムではCプログラムの例題に出ているような方式でビットオーダー逆転を行っていますが、 APPLESOFT BASICにはビット演算もビットシフトも剰余演算子もありません。 ので、ビットオーダー反転はすべて加減剰余を繰り返して行っています。 この処理はビデオメモリの横40バイトx縦192行で7680回繰り返さなければいけないので、 ここを高速化すればすぐに効き目はあるはずです。 そこで実行時演算負荷を最小限にする方法として、 128個のビット反転パターンをあらかじめメモリに用意しておいてそれをルックアップする方法も取ってみました。 結果、2分30秒の短縮。 BMPファイル上で隣り合った2バイトがどちらも$FFであるかどちらも$00であるときはそこから生成されるハイレゾバイトは$7Fあるいは$00なので 8ビット->7ビット詰め替えルーチンはスキップできるとか、 数値定数は直値としてプログラムに書くよりもいちど変数に代入してから参照した方がインタプリタは高速に動くとか、 GOTO文の飛び先行番号は毎回プログラム先頭からサーチされるから高速ループはプログラムの冒頭に書く方が良いとかの APPLESOFTマニュアルに書かれている高速化テクニックも使います。 結果として、右の写真に見えている画像をテストデータとして使ったときは当初は9分38秒かかっていたのですが、 5分38秒まで高速化することができました。 しかし、当然ですが、HPLOTコマンドを使って達成できる3分台には及びません。 2021-02-21 BASICによる直接描画プログラム高速化 描画時間5分38秒 |
 |
|
データバッファに読み込んだWindows BMPファイルを高精細グラフィックスのビデオメモリに直接描画する手順は実証できましたので、
ここからは高速化に向けてプログラムの機能ブロックをひとつひとつマシン語プログラムで置き換えていきます。 Apple IIのメインメモリのうちアドレス$0300から$03F7まではユーザに解放されていてマシン語プログラムを置いておけますが、 今回やろうとしているビットマップ表示プログラムはそこで許された最大サイズ248バイトには収まりそうにないので、 8KBのデータバッファに加えて新たに$7200〜$75FFの1キロバイトをマシン語プログラム領域として確保することにしました。 メインプログラムは相変わらずApplesoft BASICで書きますが、 BASICとマシン語パートのデータ受け渡しはゼロページでユーザ使用可能となっている$F9〜$FFの7バイトを使用します。 取り掛かりは、ビデオメモリの全バイトについて実行する必要のあるビットオーダー逆転ルーチン。 Cのテキストにも出てくるような、上位・下位に分けて入れ替えを繰り返すアルゴリズムです。 高精細グラフィックスのビデオメモリのビット7は色決めビットで、今回はこれはすべて0固定とするのですが、 サブルーチンは汎用とするためにbit0〜bit7をすべて対象とします。 これに合わせて、BMPビットマップ7バイトから高精細グラフィックス8ビットに詰め替える上位処理ではビット0を色決めビットとしておいてから、 ビットオーダー逆転サブルーチンを呼び出すように改造しました。 2021-02-23 MSB-LSB反転ルーチンをマシン語化 ところで6502のマシン語プログラミング、あいかわらず 6502とApple II システムROMの秘密 を片手に手センブルしていますが、 ふーん、Xレジスタをアキュムレータに転送する命令はないんだ。 変なの。 TYAがあるんだからTXAだってあっていいのにね。 次の日もういちどこの本のインストラクションセット表を見返して、あれ? あれれ? |
 |
|||
|
テストのために8キロバイトのデータバッファをゼロクリアする必要性はたびたび発生しますが、
8キロバイトをゼロクリアするプログラムを Applesoft BASICで書くと、処理に50秒かかります。
Applesoft BASICでは数値を直値でかくよりもいったん数値変数に代入しておいてから変数を参照する方が高速に走ります。
ループ中でこのテクニックを使って、ゼロクリア所要時間は30秒。 頻度が増えると毎回30秒待つのも無駄なので、 8キロバイトをゼロクリアする小さいマシン語プログラムを書きました。 ゼロクリアは一瞬で終わります。 やっぱりマシン語は速いですね。 2021-02-24 データバッファ8キロバイトをゼロクリアするルーチンをマシン語化 |
||||
|
次のステップは、
BMPデータ中の連続した7バイトを、ハイレゾグラフィックスの連続した8バイトに転送するサブルーチン。
やりたいことは簡単なのですが、プログラムにしようとするとかなりめんどくさい手続きです。
もっとシンプルでエレガントな方法があるはずだよなあとは思いながら、
多少冗長でもわかりやすくてサブブロックに分割できる方法で実装。
結果は1画面描画時間が1分16秒。
4倍のスピードアップになりました。
さすがマシン語、効果がはっきり出ますね。 2021-02-25 BMPデータ7ビットをビデオメモリ8ビットに転送するマシン語ルーチン作成 表示時間 1分16秒 つぎはBMP7バイト->HGR8バイト転送ルーチンを5回連続で呼び出して、1ライン描画すべてをマシン語化。 たかが5回繰り返すだけのFOR文を置き換えただけですが、 1画面の描画時間は24秒まで縮まりました。 FOR文で5回ループ、その中でのPOKE文によるメモリ書き込み、 CALL文によるサブルーチン呼び出し。 1ステートメントごとに、BASICではやはりかなりの時間を費やしてしまうのですね。 2021-02-25 1ライン データバッファ->ビデオメモリ転送ルーチンをマシン語化 表示時間 24秒 |
 |
|||
グラフィック表示Y座標からBMPファイルデータチャンク中のベースアドレスオフセットを計算する次の式SB = BA + 62 + ( 191 - y ) * 36をマシン語化。 191からYを引いているのは、画面一番上のラインから下に向かって画像をスキャンさせる見栄えのため。 36を掛けるのは、1ラインは36バイトで成り立っているから。 62は、BMPファイル中でデータチャンク先頭までのオフセット。 BAはBMPファイルが格納されているベースアドレス。 シンプルな算術演算だし、割り算は使っていないし、192回呼び出すだけだからさほどには影響ないかなあと思いつつ。 ここでは36を掛けるという掛け算が必要になりますが、6502プロセッサには掛け算命令はありません。 自分で掛け算サブルーチンを書く必要があります。 う、いままで掛け算サブルーチンを自分で書いたことはなかったなあ。 これはマイコン入門者にとってはきちんと教科書を読んで学ぶべき単元です。 けど。 あはは。 ここでは36を掛けるだけのことですからね。 2回左シフトして4倍したものと5回左シフトして32倍したものを足し算する方法でいきました。 結果は、24秒かかっていたところを19.7秒まで短縮できました。 4秒の短縮。 この計算を1回行うために、Applesoftは20ミリ秒前後使っていたことになります。 2021-02-26 データバッファY座標アドレス計算ルーチンをマシン語化 表示時間 19.7秒 |
||||
|
さあいよいよ、変態グラフィックスの変態たる所以、表示Y座標からビデオメモリのベースアドレスを算出する計算式をマシン語化します。
BASICプログラムとしてはたった1行で、Y座標ぶん、すなわち192回繰り返すだけたのでさほどに時間は食わないように思えるのですが、
いっぽうで本来ならマスクとビットシフトだけで処理できるところを剰余演算とINT関数を使って描いているので、それなりに時間がかかっているはず
(写真では説明のために数値は直値定数で書いていますが実際のBASCIの中では高速化のためにあらかじめ変数に置き換えてあります)。 結構ややこしく長ったらしくなってしまったこの計算、マシン語で書いたサブルーチンに置き換えたら、 それまでの19.7秒が半分以下の9秒になりました! とうとう10秒を切ったぞ! 2021-02-27 ビデオメモリY座標アドレス計算ルーチンをマシン語化 表示時間 9秒 |
 |
|||
|
最後の仕上げは、バッファとビデオメモリの先頭アドレスを計算して1ラインを表示する手順を192回、
つまり1画面にわたって繰り返す処理。
BASICではPOKE文によるゼロページデータ書き込みとCALL文によるマシン語サブルーチン呼び出し3回。それを192回繰り返すだけです。
ここはそんなに時間は食ってないだろうと思いながら、
1画面描画のすべてをマシン語に置き換えた結果は、
なんと描画時間1.2秒でした。
POKE文とCALL文だけでも、192回繰り返すと8秒も必要としていたんですね。 高精細グラフィックスビデオメモリへの直接書き込み描画プログラムは、 当初全BASICで1画面描くのに9分39秒かかっていました。 これがいまではすべてマシン語で書き替えて1.2秒で描けるようになったわけなので、 480倍の高速化に成功です! プログラムには冗長な部分もかなりあるのでさらなる高速化が狙えますが、 この先は保守性・可読性も次第に低下しはじめ、そのうちカリカリチューンの領域に入っていきます。 まずはここで一段落しましょう。 2021-02-28 ハイレゾグラフィックス直接書き込みBMP表示ルーチン完成 描画時間1.2秒 |
 |
|
Apple IIのテキスト画面に表示できる文字は、ASCIIコードに似ているものの、同じではありません。
小文字はないし、記号文字の文字種も限られているし、制御コードも違うところがあります。
よって、外部から読み込んだテキストを画面表示させるときは、PRINT文で単純に表示することはできず、
一文字ずつ文字コード変換処理を施す必要があります。
となると、BASICでは、ちょうど高速のテレタイプが文字を打ち出すような速度での表示になってしまいます。
読みながら表示を進めていくのであればちょうど良い速度ですが、
1画面を一気に表示したいような場合は遅すぎます。 そこで、ビットマップ画像表示の高速化に続いて、テキスト表示の高速化も行います。 書いたのはシンプルな、改行文字までの1行を画面に表示するルーチン。 小文字->大文字変換も含みます。 1文字出力はモニタのCOUT1ルーチンを呼び出しています。 やはりマシン語は速いねえ…というか、BASICインタプリタは遅い、という当たり前のことなのですが。 2021-03-04 テキスト表示ルーチンをマシン語化 |
|
|
Apple BASICプログラムとマシン語ライブラリの開発を本格的に進めると、
やはりフロッピィディスクのスピードがありがたいです。 ドライブが完全に壊れてしまうことを恐れて一日の終わりにカセットインターフェイスでWindows 10にもセーブしていますけど。 事実、Disk IIはときおりI/O ERRORを表示して読み書きできなくなることが頻発しています。 いっぽう、Disk II再稼働当初に頻発していたコレットハブのチャック不良によるトラブルはここのところ出なくなりました。 コレットハブ自体はコレットシャフトに対して傾きの自由度を持っていますが、 長期保管中にホコリか汚れによって動きが渋くなっていたのが、 動かしているうちに動きが良くなったものと推測されます。 2021-02-23 Disk II 不調頻度増大 |
||||
|
エラーを起こして読めなくなったとき、内部のメカをよく見ると、
スパイラル状に溝が掘られたカムディスクの溝から、ヘッドキャリッジのカムライダーが外れてしまい、
カムディスクがまわってもカムライダーが溝 (カムチャネル) に戻れなくなっています。 指でヘッドキャリッジの位置を動かしてから動かすとカムライダーが戻る場合が多く、 エラーが起きるたびに指でキャリッジを動かして使っています。 さてこれはどういう理由によるものなのでしょうか。 真っ先に考えられるのは、キャリッジがスライドする機構の、スライドシャフト部分の摩擦増大でしょう。 しかしDisk IIのサービスマニュアルを読むと、 「どんなに魅惑的に思えても、シャフトには絶対に注油してはならない」 と書かれています。 いやいや、魅惑的になんか思ってはいないよ。 ほかに手がないから、試してみるんだ。 呉5-56、というのは安直すぎてアレですけど、確かにミシン油では劣化したり固化したりする可能性もありますね。 ではシリコン潤滑剤ならどうだろう。 それよりもまず、アルコールでシャフト表面を清掃することだろうか。 テープデッキのヘッド清掃用アルコールをつけた綿棒でシャフトをこすってみると、 綿棒はすぐに真っ黒になります。 シャフト表面が汚れているのは確か。 しかしそれでもあまり状況は変わらず。 シリコン潤滑剤を薄く塗布したり、 それを綿棒でふき取ってみたり。 いろいろ試しながら、だましだましDisk IIを使います。 |
 |
|||
|
完調とは言わないまでもとりあえず実用になっていたDisk IIですが、
ドライブ1もドライブ2もディスクの読み書きができなくなってしまいました。
どちらのドライブも、いままでになかった異音 - カタカタカタという音を立てて、
"I/O ERROR"の表示を出してしまいます。
これはまずい。 2基とも同じ日に同じような症状を起こしたので、ディスクインターフェイスカードが故障したのかと思いましたが、 どうやらそうではなく、問題はドライブのメカにあり、たまたま同じ日に問題が顕著になったもののようです。 その日は春めいて気温が高くなった日だったので、室温が影響しているのかもしれません。 アナログカードの取り付けねじを取り外してメカにアプローチしやすくし、 カムライダー外れの様子を観察しながら、 ドライブ2のヘッドキャリッジレールをアルコールで清掃しました。 また、カムディスク表面、とくにカムチャネルの溝をアルコールで清掃しました。 2021-02-28 Disk II ドライブメカニズムトラブル メカ清掃を試みる メカ清掃は効果があったと見えて、ドライブ2は次第に調子を取り戻し、 数日間エラーフリーで動作するようになりました。 |
 |
|||
|
ドライブ#1については、キャリッジシャフトとカムディスク清掃だけでは回復しませんでした。
当初に比べてキャリッジはずっと軽く滑らかに動くようになったのに、カムライダーがカムチャネルに落ちてくれず、
カムディスクが空回りするだけ。
清掃を続け、別の種類のシリコン潤滑剤をシャフトに塗布してみたりを試しても一向に改善しません。
これはもうヘッドキャリッジアセンブリを分解して全清掃しよう。
分解することによってヘッドのアラインメントが狂い、それが原因でディスクを読めなくなったり、
ドライブ間のコンパチビリティを失ってしまう可能性がありますが、
いまのままではなにしろ全く読めないわけで、失うものもないといえます。 キャリッジを取り外したので、磁気ヘッドの内部を見ることができました。 ふーん、これが最初期のフロッピィディスクドライブのヘッドなのか。 ヘッド部にはダイオードと抵抗が入っているんですね。 2本のキャリッジスライドシャフトは、 外部からアルコールと綿棒で拭いていましたが、やはり完全には清掃しきれませんでした。 今回シャフトを完全に取り外せましたので、 鏡面仕上げ用のコンパウンドを使ってシャフトを磨きました。 カムディスクとカムチャネルもさらに念入りに清掃。 そして、分解した理由の核心、カムライダー。 ばね鋼で作られた舌片の先に、鉛か亜鉛か錫なのか、柔らかい金属製の突起がつけられた構造です。 このばねの押しつけ力が弱くなってしまっているものと推測したので、 慎重にばね舌片を指で曲げ、突起部位置を1.5mmほど変え、より強くカムディスクに押し付けられるようにしました。 突起部とその周辺はアルコールで洗浄した後、鉛筆の芯の先で軽くこすっておきました。 その結果…いきなり完全復調ということはありませんでした。 ときおりカムライダー外れが発生します。 しかしその頻度は明らかに下がっています。 さあて、あとはどこをどうすればよいのか。 2021-03-02 Disk II ドライブ#1 キャリッジレール分解 各部清掃 カムライダー曲げなおし |
  |
|
それまでの家庭用テレビゲーム機はPongのようなハードウェアゲームだったわけだし、
大勢を熱狂させたインベーダーゲームは初期型はモノクロ画面だったわけです。
そこに、カラーグラフィックスでジョイスティック付属、BASICで誰でもプログラムが書けるとなれば、
これは夢中にならないわけはありませんね。
どれほど多くの人が、自作ゲームづくりに夢中になったことでしょう。
し、プログラミングとソフトウェアエンジニアリングはゲームづくりから始めた、という人も多かったのでしょう。 しかしクロック1MHzの6502でBASICではスピード感のある処理は無理で、 応答速度を求めたらマシン語でプログラムを書くよりほかにはありません。 6色カラー表示といってもApple IIの高精細グラフィックスはトリッキーな作りで、 画面上のキャラクタの表示位置を1ドット動かすことさえ高度なテクニックを必要としました。 おのずとApple IIプログラマーは腕を競い合うようになります。 1988年当時に友人がくれたゲームソフトの中にあのKaratekaもあって、 けっこうハマって楽しみました。 けれどこのKarateka、いま試そうとすると、 起動時のロゴ画面は正しく表示するのに、 ゲームのメインプログラムのローディングの段階で全く先に進みません。 ああ、やはり古いフロッピィディスクだからなあ、 読めなくなっちゃったなあ。 しかし今日ふと気が付いて、そうか、ひょっとしたら ― 動いた! どうやらこのゲーム、Disk IIのインターフェイスカードがデフォルトのスロット#6に装着されているのを前提にしているようです。 いままでDisk IIカードはスロット#4を使っていたので、それがうまくいかない原因だったようす。 Disk IIカードをスロット#6に移したら起動しました。 1988年当時、すでにKaratekaの動作にはなんとものんびりしたほのぼの感を感じていましたが、 6502プロセッサの機能と処理能力、 ジョイスティックインターフェイスの仕組み、 スピーカ発音ハードウェアそして高精細グラフィックスのハードウェアアーキテクチャを理解した後だと、 なんでこんな貧弱で奇妙なハードウェアでこんな動きとビジュアルエフェクトと音響効果が出せるのか、 とても信じられません。 本当に、凄いなんてもんじゃない。 これがいまから40年前の、コンピュータの魔術師たちによる作品なんだ!! 2021-03-05 Karateka 正常に動作 |
 |
|
さて、1989年に書いてワープロとして使っていたWORDCAPSULEプログラムで解決できていなかった、
バグというか機能制限の問題について考えます。
WORDCAPSULEプログラムでは、文字列中にカンマやコロンを含んだテキストを取り扱えなかったのです。 APPLESOFT BASICには、テキストファイルから1行を読み込む機能がないのです。 NEC PC-9801シリーズ用のBASICであるN88BASIC(98)ならば LINE INPUT #1, TEXT$なのですが、APPLESOFT BASICにはLINE INPUT文はありません。 テキストファイルから文字列を取り込むものとしてINPUTコマンドがありますが、 INPUTコマンドは文字列をカンマおよびコロン区切りとして扱うので、 1行中にカンマあるいはコロンがあるとそれ以降を取りこぼしてしまい、 画面に EXTRA IGNOREDというメッセージを出してしまうのです。 これは、Apple DOSにおけるテキストファイルというのは、 SUZUKI, SP370, 1976[CR] YAMAHA, XT400, 1983[CR] HONDA, PS250, 2006[CR] YAMAHA, TDM850, 1996[CR] SUZUKI, V-Strom1000ABS, 2014[CR]といった、フィールド数固定の可変長テキストレコードを記録するためのものとして考えられていて、 行末区切りでのフリーテキストを記録するためのものとは考えられていない、のだと思えます。 Apple IIでは小文字は表示できないわけですし、ワードプロセッサとしての用途は想定していなかったのでしょう。 GETコマンドを使えばキーボードあるいはファイルから1文字を受けとる事ができ、 カンマやコロンや制御文字も受け取れます。 機能的にはこれで目的が果たせるのですが、 問題はその処理速度。 8キロバイトのテキストファイルを読み込むのに5分51秒もかかってしまい、 とても実用的ではありません。 いろいろ考えて試してみて、やはりINPUTコマンドもGETコマンドも使わず、 Apple DOSのファイルデータバッファから直接データを取り出す方法を取ることにしました。 Disk IIのフロッピィディスクは1セクタが256バイトです。 Apple DOSはファイルの読み書きはいつも1セクタ256バイト単位で読み書きし、 そのためのデータバッファが「DOSバッファ」としてシステム起動時に確保されています。 これを使い、 PRINT D$;"OPEN FILENAME,L256"で 1レコード長が256バイトのランダムアクセスファイルとしてファイルをオープンし、 PRINT D$;"READ FILENAME,Rn"でn番目のレコードを読み出します。 これでテキストファイルのn番目のセクタがDOSバッファに入りますので、 そこから256バイトのデータをユーザプログラム側のバッファにコピーすることで目的が達成できます。 もちろんファイルの最終セクタの場合は256バイトの途中でファイル終端を検出する処理が必要になります。 DOSバッファからデータバッファへの256バイトコピールーチンをPEEKコマンドとPOKEコマンドで書いて機能をテストし、 つぎに256バイトコピーを行うサブルーチンをマシン語で書きました。 ところで、DOSバッファに読み込まれたディスクのデータを見ると、どういうわけかデータバイトのビット7がすべて立っています。 データバッファに読み込んだ後にビット7を降ろす処理を入れるとこれまた時間がかかってしまうので、 256バイトデータ転送のマシン語サブルーチンの中でビット7を降ろす処理を付け加えました。 結果、8キロバイトのテキストファイルの読み込みは、5分51秒かかっていたところを10秒44まで高速化できました。 ざっと33倍の高速化です。 これで実用的な性能が得られました。 DOSバッファに読み込まれたデータのビット7が立っているのはどういうわけなんだろう。 このままではこの方法は、バイナリファイルの読み出しには使えません。 それともこれは、ファイル書き込み時にビット7を1にしてしまっているのかな? ひきつづき調べを進める必要があります。 なおドライブ#2はここのところ数日間、快調てす。 ので、ドライブ#2のケースを組付けました。 [課題] DOSバッファのデータのビット7が立っている理由を調べる。 [課題] 現在は読み込むファイルのサイズを8kB固定として扱っている。 任意サイズのファイルを読むために、あらかじめファイルサイズを調べ、それに応じたセクタ数だけ読み込むようにすること。 [課題] テキストファイルとして扱う場合は、ファイル中にEOF (MS-DOSファイル形式を使う場合) および NULL (Apple DOSテキストファイル形式を取り扱う場合) を検知した場合の終了処理を入れること。 |
|
ダイソーのスモークアクリル板を使ってグリーンモニタのスクリーンをつくってみました。
明るさは落ちてしまいますがコントラストは強まって、引き締まった印象の色になりますね。 2021-03-07 グリーンディスプレイ スクリーン手作り 温度が上がると動作異常が起きる件、 いのぶ〜 にでも取り付けようかと思って買ってあった、センサが1mほどのケーブルで伸びているデジタル温度計がありました。 これをROMチップの上に取り付けて、温度と異常動作の関係を見てみます。 ROMに取り付けたのは、指先で触れてみて一番温度が高いのがROMチップであるようなので。 冷却ファンを持たないApple IIは、当然ながら、ケースカバーを閉じるとメインボード上のチップの温度が上がります。 ROMチップ表面温度は室温に対して20〜25℃程度高くなるようで、 室温が22℃を超えるとROM温度は45℃を超えます。 ROM温度が46℃を超えたあたりから異常動作の可能性が出てきて、 47.5℃で2時間に1回程度の割合、 48.5℃に達すると頻繁に誤動作を起こすようになります。 誤動作を最初に起こすのはどこなんだろう? プロセッサかもしれないしROMかもしれないしRAMかもしれないしバスバッファかもしれないしアドレスデコーダかもしれないし、 言ってみればメインボードのほぼすべてのチップに可能性はあるわけです。 修理できるかもしれないと思ってもらってきた故障廃棄品の赤外線サーモグラフィがあったのですが、 あれは修理できずに捨てちゃいましたね。 あれがあれば文字通りどれが一番熱いのか一目瞭然なんでしょうけれど。 まあとにかく、風を当てればよくなるんじゃないのかな。 ラボの在庫パーツを見ると、60mm角のファンの新品在庫が一個あります。 どこに付けるのがいいかな。 背面スリットのあたりにつけて匡体内への吸気を試してみましたが、 ROMチップ表面温度はあまり変化がありませんでした。 むしろ匡体中央部において、中の空気を攪拌し、ROMチップやプロセッサに直接風が当たるようにする方がずっと昇温を抑えられます。 カバーを閉じても室温プラス10〜15℃どまりで、 ROMチップ表面温度は37度以下。 動作は安定しており、連続4日間、テキスト表示プログラムがループで動き続いています。 この方法でいこう。 ファン単体は「静音」を売りにしているのですが、ファンフレーム自体ははっきりと振動しており、 ケース内側に取り付けたら気にならないとは決して言えない音量でメカノイズが聞こえます。 スポンジ懸垂かなにかの方法で、うまく取り付ける方法を考えよう。 ファンスピード調整機能も欲しいかな。 2021-03-08 ケース内循環ファン仮装着 以降 異常動作は皆無 筐体内にステンレスステーを取り付けてファンを固定しました。 スポンジをかませたのですが、やはり音は気になります。 試しに5Vで回してみたら風量は少ないながら安定して静かに回っていますので、 これで様子を見てみましょう。 室温22℃で3時間連続稼働、ROMチップ表面温度は42℃まで上がりました。 これでは夏場は無理ですね。 可変電圧の電源を用意して、7V程度で回すようかな? 2021-03-26 ステンレスステー取り付け 5V駆動 ROM表面温度は室温+20℃ |
 |
|
先行していた作業と学びの結果を後追いでこのウェブページに書いていて、
前述ビットオーダーのセクションを書いているときに、あれっ?
これってこういう方法でもいけるんじゃね? 第3研究所で気がついたので手元に実機はありませんが、 JavaScriptによるApple IIエミュレータである Apple IIjs を試してみたら想像以上に正確に再現されており、モニタによるマシン語プログラミングもきちんと動きいているようす。 手センブルでプログラムを書き、Apple IIjsのにプログラムを入力して実行させてみると、 期待通りの結果が出ています。 1994年から2002年ころまでのプログラマ現役時代はずっとCで書いていましたので、 Cで解法を考え、それをマシン語化するというアプローチになってしまっていました。 この課題にチャレンジしてから2週間経過、 その間に6502プロセッサのマシンネイティブな動きがアタマの中ですこしずつ見えるようになってきている、 のかもしれません。 できあがったプログラムのアルゴリズムは、Cで書いたのでは絶対に出てこないもの。 LSR命令でソースバイトからビットをひとつ取り出してキャリーフラグに入れ、 それをROL(キャリー付き左ローテート)命令でディスティネーションバイトに入れていく方法です。 とてもシンプルなアイデアだし、ずっとコンパクトになりました。 これを使えば、ビットマップイメージ描画ルーチンがより速くなるはずです。 20201-03-11 MSB-LSB反転コードの効率的な方法を思いつく 中央研究所に戻り、CASSETTENETのマシン語サブルーチンライブラリにビットオーダー反転高速化を組み込み。 実際には、そのバイトがすべて白あるいは黒であればビット反転処理は省く仕組みを入れてあったこともあり、 体感できるような速度向上ではありませんでした。 ちょっと残念。 20201-03-13 MSB-LSB反転コード高速版を実機に組み込む - 速度改善はわずか |
 |
|
このApple II、ペリフェラルスロット#0に装着されているのは当初ランゲージカードだと思っていたのですが、
そうではなくてこれはROMカード - メインボードに装着されているROMではなくて、
カード上にあるROMでシステムが動作するようにするものでした。
そしてカード上にあるのは、どうやら初期Apple IIの6Kモニタと整数BASIC、のようです。 Apple II Plusのメインボード上には、10Kバイトの「オートスタート」ROMと、 浮動小数点型BASICであるApplesoft ROMが載ってます。 初期型の6Kモニタと、Apple II Plusの10Kモニタは、 モニタが提供するサブルーチンは多くが共通ですが、 6Kモニタにはミニアセンブラとステップ実行機能が搭載されています。 Plusの10Kモニタでは、新しい機能を入れるためにミニアセンブラとステップ実行機能は省かれてしまいました。 これは、Apple II Plusは最初からBASICでプログラムを書くため、 および市販のソフトウェアを買ってきて使うほうに重点を置かれた「進化」なのだろうと思われます。 しかし自分でマシン語プログラムを書くのであれば、ミニアセンブラとステップ実行機能はとても強力なツール。 おそらくこのマシンは、プログラム開発を行うために、 6Kモニタを使うために拡張ROMカードを追加したのでしょう。 ROMカード上には、6Kモニタのほか、AppleがオプションソフトウェアとしてROMチップの形で提供した "Programmers Aid #1" も搭載されており、 マニュアルも添付されています。 Programmers Aid #1はその名の通りプログラム開発に便利に使えるいくつかのサブルーチンが入っています。 その中の一つが、高精細グラフィックサブルーチン。 整数BASICは高精細グラフィックの描画をサポートしていなかったので、 BASICから高精細グラフィックスを使うにはこの高精細グラフィックスサブルーチンを呼び出す必要がありました。 マニュアルには Programmers Aid #1 のソースコードがすべて記載されています。 そうだ、それなら、高精細グラフィックスサブルーチンでは、自分が苦労して書いたビデオメモリアドレス計算はどのように行われているのだろう。 アセンブリ言語ソースプログラムを読み解いたら、 Y軸表示座標とグラフィックスメモリベースアドレスの関係がはっきりと再理解できました。 メモリアドレス計算ルーチンは、わずか21ステップで書かれています。 一見シフト命令とローテート命令を奇妙な順番で繰り返しているそのプログラムは、 6502インストラクション解説を読みながら1ステップずつ動きを追っていくと、 実に巧妙に、無駄なく、 Y軸画面座標をビデオメモリアドレスに変換しています。 すごい! これが天才の書いたプログラムなんだ! これに対して自分が書いたプログラムは40ステップあります。 天才のプログラムは、凡人が書いたプログラムのおよそ倍のスピードで、 同じ処理を行うのです。 2021-03-17 高精細グラフィックスサブルーチン ビデオメモリベースアドレス計算ロジックを理解 自分が苦労してやっとこさ書いたアドレス変換ルーチンをウォズが書いた天才コードで置き換えようかなとも思いましたが、 やめておきました。 凡人コードには凡人の努力の輝きがありますからね。ないか。 |
  |
|
そういえば私はコンピュータでどのように浮動小数点が記憶保存されているかを正しくは理解していなかったな･･･
自分で浮動小数点演算ライブラリを書いたこともデバッグしたこともなく、
BASICに実装されている浮動小数点計算機能やCコンパイラに付属してくる算術演算ライブラリをありがたく使わせてもらっているだけでした。
そんなことにふと気がついて、
Apple II Plusに搭載されている"AppleSoft"、つまり浮動小数点BASICでは、
どんなふうになっているのだろう。 AppleSoftでの数値変数の格納のされ方かいつまんで書いてしまうと･･･ BASICプログラムをRUNすると、ゼロページの$69-$6Aに変数エリアの先頭アドレスがセットされます。 (配列ではない)単純数値変数には浮動小数点型と整数型があり、どちらもひとつ7バイトのメモリを占有します。 浮動小数点型は先頭2バイトが変数名の最初の2文字 (Applesoftでは変数名は先頭2文字だけ認識されるんでしたね)、 それにつづく5バイトが浮動小数点数値を表しています。 整数型は、先頭2バイトが変数名、つづく2バイトで整数を示し、のこり3バイトは未使用。 あれまあ、整数型のほうがコンパクトでメモリを節約できると思いきや、どちらも同じひとつ7バイトを消費するんですね。 先頭2バイトが変数名を示しますが、浮動小数点変数の場合は2バイトそれぞれのビット7が0になっていて、 整数型のときはビット7がどちらも1になります。 ちなみに変数名1バイトめのビット7が1で2バイトめのビット7が0のときは文字列変数を示しています。 つまり、A (浮動小数点型)、A% (整数型)、 A$(文字列型)の3つの変数は、内部ではそれぞれ先頭2バイトが 41h 00h C1h 80h C1h 00h になっています。 浮動小数点型の数値は5バイト = 40ビットを使って表現されますが、 最初の8ビットが指数部、 ついで1ビットが正負の符号を示し、 残りの31ビットが仮数部です。 二進の浮動小数点表現では仮数部の最上位ビットはいつも1なのでこれはわざわざ記録する必要はありません。 つまり仮数部が31ビットということは、実質2^32個、4,294,967,296個の数値を表現できるということになります。 結果として、浮動小数点型の変数で表現できる最大の整数は 4,294,967,295 になります。 AppleIIの整数型は2バイト16ビットしかないので、扱える数値は-32767〜+32767まで。 浮動小数点型のほうがずっと大きな数値を扱えることになります。 浮動小数点型は指数表現を使うことにより4,294,967,295よりももっと大きな数値を扱えるわけですが、 4,294,967,295を超えるともはや数値の最小分解能が1より大きくなってしまうため、 1を足しても数値は大きくならず、 また1を引いても数値は小さくなりません。 計算結果に誤差が含まれるようになるので、結果は期待される値と異なってきてしまいます。 この計算誤差は計算順序によっても異なってくるので、さらに注意が必要です。 Applesoftのプログラミングマニュアルでは浮動小数点変数が扱えるのは9桁の数値まで、 と書かれています。 内部的には4,294,967,295までの整数なら正確に保持しているのですが、 PRINT文で数値を表示しようとすると、999,999,999 より大きな数値は指数表示になってしまいます。 これを踏まえると、Applesoftで扱える整数は9桁まで、としておくのが安全ですね。 |
 |