艦長日誌・私的記録 DS9

　先日のamazonのセールで，また新しい測定器を買ってしまいました。HO102というハンディオシロです。

　今持っているオシロもテスターも機能的には満足していますが，先日AppleIIの修理をやっているときに，現場で波形を見たいときが頻繁にあり，この時いちいちTDS3054を持ち運んでいたのがとても面倒だったのです。

　帯域は最低でも100MHz，2ch測定が可能で，10:1プローブが使えて，トリガも綺麗にかかって，カーソルも使いやすくて，それで十分なメモリとサンプル周期を持っているもの，つまり一昔前の中級モデルくらいのものが電池で動いてくれればいいなあと思っていたところ，目についたのがHO102でした。

　スペック的に3万円から4万円くらいするのも当然だと思っていたのですが，HO102はセールで2万円でした。聞いたことがないようなメーカーのものですが，同じ物がOWONに供給されているようなので，そんなに悪いものではないでしょう。

　とにかく，100MHzで2chのオシロが2万円です。

　さて，そのHO102ですが，スペックを並べると100MHzで2ch，10:1のプローブが使えてと，すでに十分使いものになりそうな感じです。サンプリングは最大500Ms/sでメモリは8k，画面の更新速度は10000回/sと，これも実用レベルではないかと思います。

　これが手のひらサイズで電池駆動，しかも2万円なんですから恐れ入りました。

　で，少し使ってみたのですが，例えばカーソルの時間測定が逆数表示（つまり周波数ですね）出来ないとか，ロータリーエンコーダがないので直感的に操作できないとか，ちょっとフロアノイズが大きいとか，そういう不満はありながらも，普段使いには十分なものであると思います。なんといっても電池駆動というのが素晴らしい。

　そうなると心配なのは精度と信頼性です。信頼性は使ってみないとわからないですが，精度は使い始めるときに分かっていないと不安なものです。ただ，オシロスコープなんてのはそもそも精度を追い込む時に使うような測定器ではないので，テスタモードでの精度を見てみることにします。

　HO102にはテスタモードを持っていて，ボタン1つで切り替えが出来ます。カラフルなLCDで見やすく表示されるので好印象ですが，ファンクションの切り替えがロータリースイッチではないので使いやすさは今ひとつです。

　気になるのは精度で，一応一応スペックとしては20000カウントです。ちょっといいテスタくらいの感じでしょうか。コンデンサの容量はもちろん電流も測定出来ますし，今どきのテスタが出来る事は一通り出来そうです。

　では早速，恒例の誤差を調べてみましょう。いつものように標準電圧発生器を測定してみます。

　この標準電圧発生器は2016年に購入したもので，AD584KというICを使って，温度係数が15ppm/℃という安定性を持っています。出荷時に信頼出来る測定器で測定した値を添付してくれているので，これとの比較を行えば自分の測定器の精度がある程度わかります。

　出荷時の値は以下の様な感じです。

2.500V・・・2.50165V
5.000V・・・5.00302V
7.500V・・・7.50454V
10.00V・・・10.00533V

　測定日からすでに7年も経過しているので，ズレていても仕方がないのですが，そこも含めて確かめていきます。

　まず，うちの基準器であるHP34401Aです。
2.5018V
5.0035V
7.5053V
10.0064V

結構ズレているように思いますが，実は昨年に測定した値があります。

2.5017V
5.0035V
7.5054V
10.0065V

　これを見るとほとんど変わっていません。しかも昨年の値と2019年の値とは一致しているので，この3年ほど値がほぼ変わっていないことになります。

　次に，HP34401Aの現在の値とHO102の比較です。

2.502V -0.2mV -0.00799%
5.003V -0.5mV -0.00999%
7.505V -0.3mV -0.00400%
10.006V -0.4mV -0.00400%

　お，なかなかやりますね。桁数が減った分だけ不利になっていますが，ほぼドンピシャという感じでしょうか。これなら十分信頼出来る測定器といえるでしょう。気に入りました。

　でも，20000カウントの弱点が出てますね。2.5Vでは少数3位までしか出てません。私のように5Vまでの範囲でおさまってしまう弱電屋さんにとっては，20000カウントも6000カウントもそんなに変わらん，ということです。

更新速度は仕様として規定されていませんが，1秒間に3から4回というところでしょうか。十分です。また，trueRMSというのも地味にうれしいところです。

精度の仕様はDCが0.5%+3dig，ACが0.8%+5digですから，DT4282の足下にも及びませんが，FLUKE 101と同じですね。実用範囲です。

　参考までに，うちのもう1つの基準器であるDT4282です。購入後1年経過しました。

2.5017V 0mV 0%
5.0035V 0mV 0%
7.505V -0.4mV -0.00633%
10.006V -0.5mV -0.00500%

　相変わらず良い値を示しています。さすがは60000カウント，6Vまでなら小数点4位まで表示する上，34401とぴったり同じの値を出すなど，しびれます。

　まとめると，HO102はスペックは凡庸で，20000カウントも実使用上はあまりうれしくないが，実力は十分で測定値も信頼出来る，操作性は今ひとつだが視認性は良く，常用可能なテスタであると言えるでしょう。

　考えてみると2万円ですから，オシロスコープの値段を考えるとタダみたいなもんです。現場でオシロとテスタを切り替えて使うことがどれだけあるかわかりませんが，とりあえず1台持っていけばどっちでも対応出来るというのは頼もしいですし，それぞれの機能に妥協しないで済むという安心感もあります。

　中国製なので見た目もアレですし，手触りも良くありません。PCと繋ぐソフトも試しましたが，別に使いたいと思うようなものでもない程度でしたし，付属品の質も低くて，テスタリードなどはなにやらベタベタして気持ち悪いです。

　ですが，オシロスコープとテストの2つの基本機能はしっかりしていますし，使い心地も悪くなく，測定結果は信頼出来ます。これが2万円ですからね，電子工作初心者の方々にこそ，この測定器をお奨めしたいです。おそらく10年は使えますよ。

 

 

　最近，私のAppleIIはテキストモードで派手に色ズレが起きるようになってきました。

　AppleIIは，テキストモードではカラー表示を行いません。ですが初期のAppleIIは積極的にNTSCのカラーバースト信号（3.58MHzですね）をOFFにすることをしていませんでした。

　そのため，テキストモードでも文字に色がついてしまい，滲んで見にくくなってしまうことが指摘されていたようで，後にテキストモードではカラーバースト信号をトランジスタでGNDに落としてしまう回路が追加されています。

　カラーバーストがないビデオ信号というのは白黒時代のビデオ信号そのものですので，モニタ内部では輝度信号だけのモノクロ信号として処理されるようになります。具体的にはカラーバーストを使った色信号の復調回路が完全に殺され，輝度信号だけでCRTが駆動されるようになるわけです。

　私のAppleII（もとはJ-plusなんですが）でもこの「カラーキラー」と呼ばれる回路は入っているので，多くの場合はテキストモードでカラーバーストが出なくなり，画面には滲みのない完全なモノクロ画面が表示されるようになっています。

　しかし，最近不安定で，一度グラフィック画面に切り替えてしまうとテキストモードに戻してもに色のじみが消えないとか，色のにじみが起動時から出てしまうなどの問題が頻発するようになりました。

　カードをたくさん追加するようになってから頻度が増えたので，電源の問題だろうと思っていたのですが，テキストモードでのにじみ方がひどくなって来ていることや，頻度が上がって実害が無視できなくなってきたことから本気で対策することを考えました。

　最初に行うことは，ビデオ出力レベルの調整です。私はNTSC-HDMI変換器を間に挟んでおり，こいつとの相性かも知れないと思ったので，まずは適正レベルに調整することを行いました。レベルが1Vp-pになるようにオシロスコープ波形を確認し，TRIMを調整します。

　ですが，やはり根本的な問題はこれではないようで，にじみは解決しません。

　カラーキラーが動いていない，あるいは不完全なのかも知れないので，カラーバーストの波形を確認します。カラーモードでは正確な3.58MHzが観測されますが，テキストモードでは3.58MHzのレベルがぐっと下がっていることが確認出来ます。

　うーん，しかしながら，カラーバーストは完全に消えておらず，半分くらいのレベルに下がっているだけですし，何周期かおきに大きなトゲが出ています。3.58MHzとは異なるノイズのようなものも載っていて，とにかく汚いです。

　広く知られているように，カラーバーストは色信号の基準となる位相を伝送するもので，色信号はこのカラーバーストとの位相差で色を伝送する仕組みです。

　本来，カラーバーストが3,58MHzから大きく外れてしまうと，モニタ側のPLLのロックが外れて白黒信号として扱われるわけですが，どのくらいでPLLがロックするかはモニタによるところがあるので，私のAppleIIでもカラーキラーが働かない場合もあるのでしょう。

　しかも，その3.58MHzがフラフラして。それにPLLがロックするようなことがあると，派手に色がずれるというのも道理です。アナログ時代の画質は，とにかく輝度信号の周波数特性が平坦で高域まで伸びていることと，カラーバーストがしっかりしていることが重要なのです。

　推測するに，トランジスタで作られたカラーキラーでは，カラーバーストの期間を完全にGNDに落せず，漏れ出てきたカラーバーストにあちこちから回り込んできたノイズで汚された変な信号がカラーバーストとして混合されているということでしょう。

　ですので，同じように色ズレが出ていても，グラフィックモードでカラーキラーが働いていないときの方がずっと綺麗な表示で文字も読みやすいです。

　さて，原因がわかったところで対策です。

　簡単な方法としては，カラーキラーを殺してしまうことです。テキストモードでもグラフィックモードと同じようにカラーバーストを有効にすれば，テキストモードでも色のにじみはありますが，今よりずっとましなにじみになります。

　初期のAppleIIと同じ回路になるわけですが，これはレトロPCとしては趣のある画面ではあっても実用性を損なっていて，長時間の使用には耐えないでしょう。MSXやPC-6001などのホビーマシンで文字がにじんでしまう事は許せても，プログラムやビジネスで使用するAppleIIでは厳しいからこそ，後のAppleIIでは改良されているわけですし。

　ではどうずるか。カラーキラーのトランジスタのベース電流を増やして，よりカラーバーストをGNDに流し込んでやるという対策が海外で行われていることを知りました。現在4.7kΩのベース抵抗を2kΩに半減してやると，カラーキラーが確実に働くようになったということです。

　これは簡単な改造で，ベース電流は現状1mA，これを2mAにわけですが，hFEが仮に200としてコレクタ電流は200mAから400mAに増やせることになるでしょう。2N3904としては400mAは流しすぎなのでちょっと怖いんですが，そもそもこのトランジスタのコレクタには1kΩが入っていますので，実は5mA以上の電流は流れません。ということはベース抵抗を小さくしてもあまり効果がないんじゃないかと思います。

　最後期のAppleII（Rev7の後期とRFI）で採用された対策回路はもっと積極的で，カラーバーストを74LS02でカットしてしまうと言う回路が追加されています。トランジスタによるカラーキラーも入っているので，2つの回路でより確実に，ということでしょう。

　で，うちのAppleIIはどのリビジョンなのか調べてみたら，Rev7の後期モデルでした。カラーキラーは74LS02によって積極的にカットされる回路でしたが，H2という信号の反転はトランジスタを使ったもので，RFIに特徴的な74LS02を使ったものではありません。

　さらに謎なのは，使われているトランジスタの種類が一部違っていたことです。回路図では2N3904という汎用の小信号トランジスタ（そう，日本で言う2SC1815みたいなやつです）なのに，カラーキラーとSOFT5反転のトランジスタが，ダーリントントランジスタになっていたのです。

　ダーリントントランジスタだと，確かに少しのベース電流で確実にトランジスタをON出来ますが，今回の使い方では2N3904で十分なはずで，hFEが極端に大きい方がむしろノイズを大きくしてしまうんじゃないかと思い，2SC1815に交換しました。

　さらに，H2の反転も余っている74LS02に作り替え，RFIと同じ回路にしてみました。（ただし，RFIでは垂直同期信号がより正確になるように74LS02を2つ使って回路を修正しています。そのためRev.7とは異なる回路になっており，Rev.7を完全にRFI同等にするのはやめておきました。）

　それでもやはり色のにじみは改善されません。カードを2枚くらい挿しただけだと大丈夫なんですが，3枚にするともうダメです。最初電源周りを対策すれば解決するだろうと思っていたのが甘かったようで，ちょっと目処が立たなくなってしまいました。

　TEXTモードではカラーバーストを混合する直前で，GND（それもビデオ出力端子のGND）に落とすのが効き目があるとわかって，リレーを使ったりしてみましたが，少しましになった程度です。

　しかもレベルを適正にすると画面が白く飛んでしまい，文字との区別がつきにくくなるという強烈な障害も発生するようになりました。これ，結局コンポジット信号の質が悪すぎることに原因があります。白く飛ぶのは黒レベル（ペデスタルレベル）を捕捉し損ねている結果ですし，波形を見ていればさもありなんというくらいのひどい波形です。

　こうなってくると小手先の修正では手に負えなく，次の一手としてビデオ信号の変換器を交換してみることにしました。

　私がこれまで使ってきたのはコンポジット-HDMIの安い変換器です。解像度は低く，モヤーっとした眠い画像ですが，色はしっかり出ますし，AppleIIだけではなくPC-6001でもM5でもちゃんと変換出来るので気に入って使っていました。

　今回試したのは，コンポジットをVGAに変換するものです。アナログRGBにするわけですので，デジタルに直接変換するものとは違い，変換品質にはあまり期待していませんでした。

　値段は少し高くて1500円ほどしましたが，これは正解でした。

　黒レベルの捕捉は失敗しませんし，カラーキラーもきちんとかかります。変換後の画像もなかなかシャープで，これまでのものよりもずっと高品位です。惜しいのは復調の品質が良すぎて，元の信号の品質が悪いことが露呈してしまうことでしょうか。

　しかも，RGN入力端子を持っているので，ボタン1つで切り替えが出来ます。これで80桁カードとの切り替えもワンタッチです。

　あれこれ悩むより，これで対応した方がずっと早くて確実な方法で，私はリレーを使った回路を取り外してしまいました。

　これで色ズレの問題は決着なのですが，いつの間にか起動しないゲームが出てきていることが発覚しており，一難去ってまた一難を地で行っている感じがします。

　どうするかなあ。

　AppleIIの拡張カードの最後の砦，80桁カードを買いました。オークション，ジャンク，Videx VideoTermのデッドコピーです。

　もともと40桁がAppleIIらしくて好みなのですが，CP/Mを使うようになると不便で，WordMasterなどのエディタは80桁前提なのでほぼ使い物になりません。

　わざわざAppleIIでCP/Mをやることもないと思いますし，それに140KBしかない片面フロッピーでは不便極まりなく，つくづくX1をCP/Mマシンにした方が幸せになると思ったわけですが，後で欲しくなっても遅いので，リーズナブルな価格なら買っておこうと思いました。

　届いたカードは香港製のようで，現在の基準で見れば信頼性がちょっと心許ない感じなので，ハンダ付けをやり直してからAppleIIのスロット3に差し込みます。そう，80桁カードはスロット3に入れるのが定番なのです。

　ここには自作のUthernetIIカードがいますので，これを別に動かしてスロット3をあけて80桁カードを差し込みます。

　起動後PR#3とすれば画面出力先が80桁カードに切り替わりますので，80桁カードのビデオ出力をディスプレイに繋ぎます。

　おー，80桁出ました。しかし画質はかなり悪いです。

　回路そのものの動作はOKのようですので，ここでCP/Mを起動します。CP/MはVidexの80桁カードなら最初から80桁で起動してくれます。

　起動してみると，うまく80桁でCP/Mが起動しました。小文字も出ています。そっかー，AppleIIeやAppleIIcなんかだと最初からこんな感じなんですかね。

　しかし，文字がボケボケですので，ここはRGB入力で映したいところです。もともとカラーではありませんからNTSCである必要はありません。同期信号と輝度信号が重畳して出力してあるだけですので，SYNCとRGBをパラレルに突っ込むだけでOKです。

　しかし，SYNC信号はH-SYNCとV-SYNCが分離したものが必要なディスプレイが多いので，同期分離をしないといけないです。定番のLM1881を使っても良いのですが，せっかくMC6845を使ったビデオカードなんですから，6845から直接取ることにしましょう。

　名付けて，80桁カード・RGB出力改造です。（バッ活っぽいですね）

　繰り返しますが，カラー出力ではありませんので，RGB出力改造というよりもセパレート出力という方が正しいです。

　まず同期信号ですが，MC6845の39ピンと40ピンから直接取ります。最初バッファを挟むつもりでしたが，面倒になって直結することにしました。

　輝度尊号はSYNCが混じっていても構わないかも知れないと，最初そのままRGBに痛恨でいました。しかしこれだと同期信号が出た時に基準レベルが変化するので，干渉縞が出てしまうようです。それにレベルがあっていないのか，全体に緑っぽいです。

　そこで同期信号が混同される前の信号を取りだします。5VのTTLレベルですが，アナログRGBに突っ込んでも別に構いません。

　結果，シャープで高コントラストの文字が表示されました。考え方そのものは間違っていません。しかし，縦線が薄くなっています。Iの文字などはスペースに見えてしまうくらいです。

　こういうのは電源の質が悪いとか，どっかからクロックが回り込んでいる場合があると思ったのですが，指で触ってみればパッとIがくっきり表示される時があります。

　GNDかなあとコンデンサの追加やGNDの強化を行いましたがあまり効果がありません。さらに指で触る範囲を広げると，水晶発振子のケースに触れると確実に効果があることがわかりました。

　ははーん，クロックのジッタだな，と目処を付け，クロック発振を行っている74LS00にパスコンを取り付け，水晶発振子の真下に銅箔テープでGND強化を行いました。

　これで試すと効果てきめん，Iが綺麗に表示されるようになりました。

　改めて基板を見ると，ベタGNDもありませんし，パスコンもほとんど入っていません。回路はVidex VideoTermのデッドコピー（抵抗の定数は少し違う）なんですが，パターンもオリジナルはこんなに貧弱なんでしょうかね。

　とりあえず安定して動いているのでこのままCP/Mの運用に入ることが出来そうです。念願だったWordstarを実用的に動かしたり，MBASICを起動してみたりしましたが，案外ちゃんとに動くので驚きました。キャラクタベースだから当然なんでしょうが，80桁，小文字の表示がこれだけ高品位に出てくるようになるなら，そりゃ定番のオプションになるわなと思いました。

　しかしですね，RGBで80桁でAppleIIとは違うフォントでCP/Mが動いているのを見ると，もうAppleIIを触っているという感覚はほとんどありません。楽しくないというかワクワクしないというか。

　その上キーボード制限が強くて小文字を普通に入れられない，Backspaceがないなど，独自のお作法を覚えないと満足にWordstarを使えません。

　やってみてわかったのは，AppleIIで80桁でCP/Mを動かすと，もうAppleIIじゃないということです。


　それはさておき，せっかくCP/Mが動くようになったのですから，Wordstarが動くようになるまでを簡単に書いておきます。

　Wordstarはスクリーンエディタですので，エスケープシーケンスやキーコードにしっかり対応した方がより使いやすくなります。しかしそれらを簡単に定義する仕組みはなく，アセンブラで対応するコードを書き，バイナリを本体にパッチする方法で行うんだそうです。

　いくつかテンプレートがありますので，近そうなものを選び，修正します。これをCP/M付属のアセンブラでアセンブルし，HEXファイルをDDTコマンドを使ってパッチします。

　具体的には，

ASM hoge

DDT WS.COM
I hoge.HEX
R

SAVE 38 WMhoge.COM

　こんな感じです。

　本当はhoge.ASMも紹介したいところなのですが，ちょっと著作権的にどうなのよという感じもするので，ここではやめておきます。とにかく，Wordstarをコンフィギュレーションしたいのだがどうすりゃいいのよ，という人の最初の一歩になればと思います。


　私の場合，画面消去（国産機には画面消去のキャラクタコードがあるがVideoTermはないようです）のコードを用意したこと，表示位置制御は国産機のものをそのまま利用し，あとは表示文字数を80x25にしたことくらいです。これで最低限の動作はしてくれました。

　しかし，AppleIIはSHIFTキーもなければ，Backspaceキーもありません。改造する方法も広く知られていますが，当座なんとかしないといけないので調べてみました。

　まずSHIFTキーですが，これはCTRL+Aで大文字と小文字をトグルします。数字はそのままなのでSHIFTのロックとは違うのですが，"]"は"}"と入力されるようになりますのでCapsLockとも違います。

　次にBackspaceですが，WordstarのヘルプではRUBキーに割り当てられています。しかしそんなキーはありません。Softcardのマニュアルを見るとRUBキーはCTRL+@にアサインされているということがわかりましたが，@を出すにはSHIFT+Pを押す必要があります。

　なので先にSHIFT+CTRLを押してからPを押せばBackspaceと同じ動きをしてくれます。2回目以降はPを連打すればよいです。（WM.HLPも書き換えておきました）

　最後に"["と"]"，"{"と"}"です。普段は使わずに済ませられる文字ですが，Cでプログラムを書くときには必須で，この文字を入力するキーがAppleIIにはないとわかった時に，私は深く絶望しました。

　答えは"["がCTRL+K，"]"がSHIFT+Mでした。"{"と"}"はそれぞれCTRL+Aで小文字にトグルしてそれぞれ入力出来ます。久々にキーボードアドベンチャーをしましたよ。

　ちなみに→キーはTABキーでした・・・

　そんなわけで，CP/MがAppleIIで実用的に動くようになったわけですが，ディスクの容量の小ささもありますし，X1でCP/Mを使った方が普通に便利というのが，今回の結論でした。

　実はVideoTermで80桁にした環境では，"Shift-Key Mod"と呼ばれる改造が半ば標準化しており，最終的にはApple公認の改造となっています（1984年にレターが出ています）。

　これはSHIFTキー（エンコーダ基板の24ピンに出ている）をゲームI/OのPB2（J14の4ピンもしくはH14の1ピン）に繋ぐという改造で，ソフトウェアがSHIFTキーの状態をPB2ポートで検出出来るという仕組みです。

　なんでこんなことをするかといえば，AppleIIのキーボードはSHIFTキーが押されているかどうかを本体に出力せず，SHIFTと一緒に押された時のキーコードを送出するだけだからです。悪いことに，AppleIIのキーボードエンコーダーICはSHIFTキーの状態に関係なく，アルファベットを同じコードで本体に送出するので，大文字と小文字をSHIFTキーで切り替える事が出来ないわけです。

　のちにこの改造はApple公認となったばかりか，AppleIIeで採用されてしまいました。

　この改造は当然ソフトウェアがPB2を見てSHIFTキーの状態を確認する必要があるのですが，VideoTermのファームウェアはこの仕組みを持っているので，CP/MでもSHIFTキーによる大文字/小文字の切り替えが可能になります。

　使い方ですが，CTRL+Aで小文字のトグルしておくと，SHIFTキーを押しながら入力することで大文字になってくれます。大文字でトグルしておけばこれまでとなにも変わりませんし，40桁の標準モードではそもそもCTRL+Aが動きませんので，なにも変化しません。よく考えたなあ。

　さくっと自分のAppleIIでも試してみました。SHIFTキーで大文字と小文字を切り替えることが出来るので，普通のパソコンっぽくなったという感じがしたわけですが，今度は逆に"["や"]"を入力するのに，いちいちCTRL+Aを押さないといけなくなったのが面倒になりました。

　しかし，CP/Mの環境がどんどん改善していきます・・・そしてどんどんAppleIIらしさが薄れていきます。1970年代後半から1980年段前半をなぞる旅，楽しいですね。

　

　X1turboIIIですが，なかなか手強いです。

　破損したディスクを修復するのも手間取っていて，LOADするときちんと読めるのにturboBASICでCOPYコマンドを使うとファイルが壊れるという謎の問題に手を焼いています。

　COPYコマンドが信用出来ないわけではないし，書き込み先のディスクの破損もありませんから，やはり読み込み元のディスクの破損が問題なのでしょう。私はフロッピーディスクのフォーマットに詳しいわけではないですし，昔のようにディスクエディタで中身を覗き込むことに，あまり興味を持てなくなっています。

　最初，COPYコマンドでコピーを取ったBASICのリストがかなりの確率で壊れているので，打ち込み直しまで考えたところ，普通にLOADすればあっさり読み込めることを発見し，安心した一方でこれまでに処理したファイルの破損を調べ直さないといけなくなったことにがっかりした記憶があります。

　ところで以前PC-6001やPC-386でも活躍したGOTEKのFDDエミュレータですが，X1でも動作しています。私の場合，まずは外付けFDDのコネクタに繋ぐケーブルを自作し，GOTEKと繋ぎました。

　ちゃんと2HDも2Dも認識しているので問題なのですが，悲しいのはX1のコピーツールのほとんどは，ドライブ0からドライブ1へのコピーに設定されているので，外部FDDに切り替える事ができないのです。

　だから手元のディスクのバックアップを取りたいなあと思った時は本体を開けてFDDを引きずり出し，ドライブ番号のジャンパを差し替えて動かすという離れ業をやらないといけません。

　といいつつ，turboのマニュアルにはそのやり方が詳しく書いてあるので，X1ユーザーならこれくらい出来ないといけないのでしょうね。なんとユーザーに厳しいマシンである事よ。

　で，ここだけの話ですが，CZ-8FB03のイメージを手に入れました。そう，turboZ-BASICです。うちのマシンはturboIIIですのでturboZではありませんが，Z特有の機能を除いてCZ-8FB03が動作します。

　私はturboユーザー向けに外販されたCZ-8FB03を買わずにいました。turboで使う限りCZ-8FB03を使う理由が見当たらなかったからです。バンクメモリも付属していましたが，ここにはコードを置く事が出来ず，変数エリアとしてしか使えなかったことも買わなかった理由です。

　逆にturboZを買っていたら，予約してでもCZ-8FB03を買っただろうと思います。

　そんなわけで見送ったCZ-8FB03ですが，turboでもCZ-8FB03の起動する画面を拝めるかも知れないと内緒でワクワクしながら起動したのです。

　しかし残念ながら起動せず。バンクメモリがないから起動できないと，怒られてしまったのでした。いやいや，起動くらいはしないといかんよと思ったのですが，聞けばMMLの実装などでバンクメモリをほとんど使い切っているくらいだそうで，アクセスに時間のかかるバンクメモリを活用するBASICってのも，あまりうれしくないものです。

　しかし，ないものは作ってしまえばいいと，手持ちの部品棚を探し回ってみると，1MbitのSRAMもTTLもゴロゴロ出てきました。基板さえ手に入れればあっという間に作れるでしょう。

　X1turboのバンクメモリは，前半32kBを切り替えて使うようになっています。このアドレスは32kBのBIOSのROMと切り替えるエリアですが，turboではここをバンクとして割り当てており，最大16バンクで512kBまで扱えるようになっています。

　バンク制御はI/Oアドレス0x00B0にあるレジスタで行い，下位4ビットで16個のバンクを指定，5ビット目でバンクメモリ有効/無効，6ビット目でBASICがバンクアクセスしているかどうかを知るフラグとして使われています。

　これくらいの仕様がわかっていると回路図を起こすのは簡単で，さっと設計した時は3チップ+SRAMで出来ました（これでは動かないことをのちに思い知るわけですが）。これで4バンク128kBです。

　つくづく悔しいのは，サンハヤトのX1用ユニバーサルボードを予備で1枚買ってあったものを，昨年の実家の整理で捨ててしまったことです。作ったMIDIボードも捨ててしまいましたので，せめてそれだけでも残しておけばと悔やまれてなりません。

　50ピンの基板をなんとか手に入れて，X1用に44ピンに削って基板を用意します。重い腰を上げて製作に入ってしまえば2時間ほどで製作できたので早速試してみたところ，CZ-8FB03は拡張メモリがないとだだをこねて起動してくれませんでした。

　やっぱそんなに甘くはないか・・・

　いくつかの配線ミスを発見して修正しますが状況は変わらず。ただ，念のためと確認したFM音源ボードも動作しなくなっていたので，もしやと確認するとやはり拡張スロットと本体基板を繋ぐコネクタが外れていました。あちゃー。

　組み立ての時に接続し忘れたんでしょうね。戻して組み立てなおし，FM音源ボードの動作は確認出来たところで，拡張メモリを差し込みます。

　しかしやっぱりCZ-8FB03は起動しません。そこで真面目にオシロスコープを引っ張り出して動作の確認を順番にやることにしました。

　まずアドレスデコード。これは0x0B00でデコード出来ていますし，WRもRDもこれに従って作られています。

　次にレジスタ。ここはD-FFの入力にデータバス，クロックに先程のWRをいれて書き込みますが，読み出しは74HC125の入力にD-FFの出力を繋ぎ，出力はD-FFの入力（つまりデータバス）に繋ぎます。

　これ，74HC374を使えば簡単なのですが，D-FFの出力を引っ張り出してSRAMもアドレスにしないといけないので，使えないのです。面倒くさいです。

　そこで4バンク分のアドレス指定2ビットと5ビット目と6ビット目の4つのために74HC175を使い，このうち読み出しが必要な6ビット目だけワンゲートのNC7S126を使いました。

　波形を見ると一応期待した動きをしているのですが，CZ-8FB03は起動しません。もう一度I/Oマップを見直してみると，なんとすべてのレジスタが読み出し可能に指定されています。うーん，これはさらに面倒。

　しかし，レジスタが読み書き出来ないといけないなら仕方がありません。ワンゲートのNC7S125を普通の74HC125に交換して，4つのD-FFすべてを読み出せるようにします。

　これで動くかなと思って試してみると，CZ-8FB03が一応起動しました。

　うまくいったと喜びましたが，ミュージックサンプルを動かして見るとエラーが出ます。もしやとVDIM命令でバンクメモリに配列を取りA$(0)="AA"と書き込みを行うと，見事に暴走しました。（起動途中で暴走することもしばしばです）

　L-os angelesというOSでバンクメモリを確かめてみようと，BRADコマンドとBWORコマンドを入力しますが，4バンクを認識するもBWORKのイニシャライズでコケてしまいました。

　ということは，未使用のレジスタも含めて，すべて読み書き出来ないといけないのかも知れないです。バンク指定の4ビットのうち使わない2ビットは未実装でしたが，一大決心をしてすべて読み書き出来るようにしましょう。

　4個入りの74HC175は6個入りの74HC174に交換，74HC125との配線を全面的にやり直してすべて読み書き出来るように改造しました。

　これで試して見ましたが，CZ-8FB03でミュージックサンプルが動かない状況には変化なし，L-os Angelesでは8バンクと認識してしまいさらに状況が悪化しました。

　ここで疲れた私は昼寝をしながら，なぜそんなことが起こるかを考えていました。冷静に考えて見ると，実装は0から3の4バンクですが，今の回路はSRAMのアドレスのA15とA16をそのまま繋いでいるだけなので，4から5バンクを指定すると0から3バンクを指定するのと同じになってしまってました。

　これまではレジスタもなく，書き込んだ値が読み出せないので未実装と判定されていたのに，レジスタが用意されたことで実装済みと解釈された結果，上位バンクに書き込むと下位バンクが書き換わってしまい，データを壊していたんだろうと思います。

　まあ，全部で16バンクあるはずなのになんで8バンクしか認識しないのかは謎ですが，とにかくSRAMのアドレスをフルデコードしないとまずいのは確かです。

　そこでバンク指定レジスタの上位2ビットが共に0でないとCSが出ないように修正しました。

　これで試すと，ミュージックサンプルも動作し，VDIMでも暴走しなくなりました。しかしL-os angelesのBWORKコマンドで暴走する状況が残っています。

　もう一度よく考えてみると，バンクメモリを使用することを示すレジスタの5ビット目をそのままSRAMのCSに入れている回路が問題と気が付きました。これだとバンク切り替えの対象ではない0x8000以降のメモリにアクセスしてもCSがイネーブルですから，SRAMへのアクセスが発生してしまいます。

　当たり前の事ですが，0x0B00の5ビット目とA15が同時にLowになっている時だけ，CSがLowになっているようにしないといけないわけで，あわててHC32を1つ追加しました。

　いやー，甘いなあ・・・回路の修正が終わって確認です。CZ-8FB03は問題なし，L-os angekesも大丈夫になりました。よかったー。

　ということで，初期に比べて回路規模が随分大きくなってしまいました。

　今回はレジスタの仕様とソフトでの叩き方から回路をゼロから設計して動かして見たわけですが，どんな手抜きコードが書かれていてもきちんと動作するハードウェアが必要であることを思い知りましたし，それだけソフト屋さんはハードウェアを信じてくれているのだなあとも思いました。

　それからちょっと手こずったのは，SRAMはあくまでメモリであり，メモリ空間に配置されるものであるということをうっかり忘れていたということです。SRAMのアドレスを生成するのはI/O空間にあるバンクレジスタだと思い込んでいて，バンクレジスタのアドレスデコードをやったときに安心しきって，メモリ空間のアドレスデコードを忘れたというのは，情けない話だと思います。


　さて，実際に4バンク128kバイトのバンクメモリが手に入ったわけですが，出来る事はほとんどなくて，CZ-8FB03ではカラープリンタもなく，FM音源をMMLで使うこともしない私にはあまり御利益はありませんし，文字配列変数が10000個確保出来てもうれしくありません。

　L-os angelesはまだ本気で使っていませんので，やっぱりバンクメモリはうれしくないです。

　これがですね，ディスクコピーのバッファにするとかしてくれれば，時間のかかる2HDのコピーが便利になると思うのですが，そういう機能もありません。

　思いついた回路を最終的にねじ伏せて，このプロジェクトは終了です。

　先日，復活作業中のX1turboで恐れていたことが起きました。

　手元にある貴重な5インチ2Dのディスクのうち，CP/M関連はバーベイタムのフロッピーディスクにしてあったのですが，こいつが他例に漏れずカビだらけになっていました。

　中身をとりあえず救い出さねばと，ジャケットを開いてディスクを取りだし，IPAを拭き掃除を行い，安心してドライブに突っ込んだのですが，カシャカシャと嫌な音がして，エラーが出ました。

　あわててディスクを取り出すと，同心円状のひっかき傷が出来ていて，完全に磁性体が削られています。

　ああ，やってしまった。

　カビのせいで脆くなった磁性体もろとも，ヘッドに付着してしまったようです。

　この状態ではヘッドが死んでしまうことが多く，ディスクはもちろんドライブも故障してしまうことが多いです。今さら5インチのドライブを交換するなんてとんでもないことだと真っ青になったのですが，とりあえず分解します。

　ドライブを取りだし，IPAでヘッドを拭き掃除しますがエラーは解消されず，全く読み込むことが出来ないままです。ああ，これはヘッドが完全に壊れたパターンだなあとうなだれていたのですが，あきらめきれずに無水エタノールでもう一度しっかり拭きました。

　するとカシャカシャという音もなくなり，ディスクも読み書き出来るようになりました。

　ヘッドが復活しました。割れたり削れたりしていないなら，まだ復活の可能性があるということでしょう。よかったー。

　もう一度ディスクをジャケットから取りだして，今度は無水エタノールでディスクを拭いたのですが，もう磁性体が剥げてしまって使い物にならないディスクになってしまいました。これはひどい。やっぱりバーベイタムは鬼門でした。

　読めなかったディスクもなんとか復活させました。全く読めなかったα-CというZ80用のCコンパイラですが，調べてみると元になったBDS-Cの最新版（V1.6）はすでにフリーになっていて，ダウンロードして誰でも使えるようになっていました。

　さっさとダウンロードしX1のCP/Mで使えるようにしてから，手元に残ったオセロゲームのソースをコンパイルして動作する事を実機で確かめました。これで今回の事件で失ったものはありません。

　ということで，ドライブの故障がなくてなによりでした。私は昔，カビディスクのせいでドライブを壊しているので今回も冷や冷やしましたが，もう危ないことはしないでおこうと思います。

　とはいえ5インチ2Dも今や貴重品です。カビも除去して使えるディスクは，使っていきたいところです。難しい判断だなあと思います。