艦長日誌・私的記録 DS9

　先日よりHC-20の修理を少しずつ行っていますが，なかなか尻尾がつかめず，原因がはっきりしないままの試行錯誤が続くという，誠に辛い状況が続いています。

　万が一マスクROMが死んでいたとしたら，復活への希望も絶たれてしまいます。マスクROMが生きているのかどうかを確かめること，そして手持ちのEP-ROMを活用できるようにすること，あるいはNORフラッシュメモリを利用出来るといいかも知れないということで，ROMライタを買うことにしました。

　とはいえ，UV-EPROMが消えて久しく，車のエンジンのチューニングか，古い機器のメンテにしか使う事のないこれらのROMを書き込む装置も，また絶滅危惧種です。

　私は15年ほど前に，秋月でAKI-80をベースにしたROMライタキットを使って来ました。これはこれでそこそこ気に入って使っていますし，今でも動かそうと思えば問題なく動くのですが，2764，27128，27256と2864の4種類しか対応しませんし，スタンドアロンでの動作はディスプレイがないためわかりにくいですし，さりとてPCとの接続はRS-232Cを使わないと繋がらないなど，なかなか使いにくいものになってしまいました。

　特に27256までというのが致命的で，せめて1Mビットのものが読み書きできないとなにかと不便です。そこで，意を決して，秋月で売っているちゃんとした（本当にちゃんとしているかどうかはわかりません），完成品のROMライタを買うことにしました。

　現在もホームページに載っていますので調べれば分かることですが，LEAPER-3Cという機種名です。お値段は15000円ほど。この種の機器としては破格のお値段といえるでしょう。

　スタンドアロンでのコピーも可能ですし，PCとはUSBで接続出来るので，とても楽ちんです。ただ，それでもかなり昔に登場した製品のようですので，これから対応デバイスが増えるとか，ファームのアップデートがあるとか，その手のサポートは全く期待できないことでしょう。

　さて，手元に届いたLEAPER-3Cですが，台湾製にもかかわらず大変安っぽいです。はっきりいって中国製かと思ったくらいです。

　一応，ACアダプタは秋月オリジナルのスイッチングタイプに交換されていたのですが，付属のCD-ROMはCD-Rですし，こういう行き当たりばったり感が嫌いな人は，手を出すのはやめた方がいいでしょう。私？大好きですね，ええ。

　早速動かしてみます。

　まずはスタンドアロンモードです。HC-20から外したROMを読み出して，チェックサムを取ってみましょう。

　説明書があまりに不親切な上，どうでもいいことが丁寧に書かれていたりするので全く役に立たないことはお約束として，この28ピンのROMを，どのソケットに差し込むのか，そこから悩むことになります。

　LEAPER-3Cには，左右に32ピンのソケットがあります。左がSLAVE，右がMASTERと書かれています。

　ROMをMASTER側に差し込んでベリファイキーを押します。ピーと音がして，チェックサムが出ました。E000？これはなんか変ですね。

　SLAVE側に差し込みましたが，こちらもE000。ますますおかしい。ROMが死んでいて，読み出しが出来ないのかも知れません。別のROMを差し込んで見ますが，やっぱりE000です。HC-20の全てのROMのチェックサムがE000なんてことはあり得ません。

　PCにソフトをインストールし，PCモードで動かして読み出しを試みますが，やはりダメです。ダンプを取ってみると，全てFFです。全く読めていません。

　そこで，かつて修理したOberheimのMatrix-1000のROMを読み込んでみる事にしました。このROMは27256に焼かれているので，素直に読み出せるはずです。

　MASTER側では読み出せず，SLAVE側では読み出せました。うーん，そんなもんなんですかね。

　てことで，またHC-20のROMで試します。ROMタイプを27C64にせず，27C256にして読み出してみると，チェックサムがなにやら意味のある数字になっています。もしやと思ってダンプをすると，途中からそれらしいバイナリが見えるではありませんか。

　27256の32kByteのエリアの内，後半8kByteにそれっぽいものがあります。そこを取り出して8192バイトのバイナリファイルにして，HC-20のROMとして保存しました。

　HC-20には8kByteのROMが全部で4つありますが，それぞれで異なった値になっていますし，所々にASCIIで意味ありげな文字列が見えたりしますので，これでたぶん大丈夫でしょう。

　ということで，書き込みの試験はまだやっていませんが，とにかく読み出しがちゃんと出来たという事で，まずはこのLEAPER-3Cは所期の目的は果たせそうです。

　・・・しかし，なんでHC-20のROMが2764では読み出せず，27256で，しかも後半で読み出せるのでしょう。

　よくよく考えてみました。

　HC-20のマスクROMは，64kビットのマスクROMで，SMM2365という品種だそうです。回路図はつぶれてよく見えないのですが，実物は28ピンですのでおそらく2764互換だろうと，そんな感じです。

　実は，32kビットまではマスクROMもEP-ROMも同じ24ピンでした。しかし64kビットになるとき，EP-ROMはVppやPGM端子が必要になり，28ピンになりました。一方のマスクROMはアドレス線を1本追加するだけですので，24ピンのままでも成立しました。

　この24ピンのマスクROMは，一般に2364と呼ばれます。

　しかし，この2364は2764と差し替え出来るわけではありませんので，不便です。そこで2764と差し替え可能なマスクROMとして，2365が誕生するわけです。

　2365に限らず，マスクROMというのは基本的にカスタム品種ですので，チップセレクトの本数や論理を，カスタマーごとに選べるようになっています。

　さて，2365のデータシートを入手し，2764と27256のピン配置と並べてみますと，

　　2365　　2764　　27256
26　CE1　　　NC　　　A13
27　CE2　　　PGM　 　A14

　という感じです。これでもうおわかりですね。

　HC-20のSMM2365は，26ﾋピンと27ピンがCE1とCE2になっており，正論理にカスタマイズされています。これを2764で読み出しても，オープンかGNDになるだけで，2365はイネーブルになりません。

　しかし，27256で読み出せば，A13とA14がHighになるところで，2365はイネーブルになるわけです。

　なんか面倒臭いなあと思いつつ，こうした工夫をすることで，インバータが削除できたり，アドレスデコーダが簡略化できたりするので，当時は普通に行われていたことのようです。

　ところでHC-20の本体側の回路ですが，26ピンも27ピンもHighに吊ってあります。よってこのソケットにそのまま2764が差し込まれても，問題なく動くはずです。また，基板にはジャンパがあり，27128までは対応出来るようです。

　さて，先程OberheimのMatrix-1000が壊れた時のROMの話を書きました，これもここで何度か書いているので初めての話ではないのですが，この時の故障は，起動時は問題なく動くのですが，15分ほどすると暴走するというものでした。

　中をあけてみますがさっぱりわからず。正常動作をしているときはそれらしい波形が出ていますが，暴走すると全くプログラムが動いていない様子です。もしやとおもってROMを読み出してみると，暴走していた直後は読み出せず，しばらくすると読み出せるようになりました。

　十分時間を空けてから読み出しを行って，これをEP-ROMに書き込んで試すと，何時間経っても暴走しません。かくして，大事にしていたMatrix-1000は，ゴミにならずにすんだのでした。

　この一件で学んだことは，半導体，特にメモリICというのは，急に読み出せなくなるわけではなく，ジワジワと動かなくなるということです。動くか動かないかという話ではなく，アナログ的に壊れていくのですね。

　もしかすると，このHC-20のROMも，電圧が上がりきらないとか，リークがものすごくあるとか，そういうデバイスとして壊れていて，中身はとりあえず壊れておらず，ROMライタのようなしっかりした機器では読み出せたりするということがあるのかも知れません。

　現在，SRAMを256kビット品に交換しています。16kビットのオリジナルでもいいのですが，容量を増やしたいのと，RAMも案外壊れるものなので，不安を取り除いておこうという気持ちからです。

　SRAMを交換し，それで動いてくれればうれしいのですが，今回ROMライタを購入したことで，修理不能という最悪の事態だけは回避できそうな感じです。

[追記]2010/12/7

　LEAPER-3Cを悪く言う書き込みは見当たりませんが，他のお店で売られている中国製のライタが，安くて便利という書き込みを見つけてしまいました。

　これ，EP-ROMを書き込むだけなら別になんでもないのですが，SRAMやTTLのテストが出来るそうです。これはジャンク品を分解して外した部品を使う私のような貧乏人には，大変便利な機能だったかも知れません。

　ただ，スタンドアロンで動かないので，そこは残念なところです。USBで動けば別に問題はないし，LEAPER-3Cだって結局USBで繋がないと使い物にならないですから，9800円という値段であることを考えると，こっちの方にしとけば良かったかなあと，思ったりしています。

　あ，そうそう，HC-20については，SRAMを256kbitのものに交換してみました。アドレスデコーダをNANDゲート4つでちょこちょこっと作って試しましたが，結局動作はしてくれませんでした。道は険しいです。

　新しいものやデジタルガジェットに対して，スイス並みの中立っぷりを信条とする嫁さんが，あろうことかAppleTVを買いました。

　国内発売されたのが確か11月中旬でしたが，直後に品薄となり都内の量販店では売り切れが出ており，欲しいと言い出した時には絶望的な状況でした。

　しかしあるところにはあるものですね。自宅の近所の家電量販店に会社の帰りにふらっと寄ってみたところ，複数の在庫がありました。わずかとはいえポイントも付くので，Appleストアで買うより良かったのではないでしょうか。

　珍しく嫁さんが自分のお金で買うというので，そうしてもらいました。ゆえに，もし我々が離婚するようなことがあると，AppleTVは無条件に嫁さんに引き取られることになりますね。わはは。

　テレビは私のお金で買いましたから，天然ガスよろしく，ロシアのように意地悪をしてもよかったのですが，そんなことをしても誰も得をしないという大人の判断で，貴重なHDMI端子を1つ，気持ちよく提供することにしました。

　正直な話，私自身はAppleTVに興味がありつつも，具体的な使い道を考えつかなかったので購入を見送ったところでしたから，嫁さんの所有物であるとはいえAppleTVがどれほどのものなのか，気にはなります。

　簡単にレビューを書いてみましょう。

・簡単？難しい？

　接続は死ぬほど簡単です。HDMIでテレビとつなぎ，電源は直接AC100Vに繋ぎます。ほんとにこれだけです。

　ここで「簡単だ」などという話になると，これは実は正しくありません。ここからがとても大変で，私が思うに，およそ素人さんには無理なんじゃないかと思うほどでした。

　AppleTVは，ネットワーク接続された環境でなければ，全く動作をしません。なぜなら本体にストレージを持たず，コンテンツの再生はすべてネットワークを経由するものだからです。

　ところがこのネットワークの設定がなかなか難しいのです。無線LANを使えば配線は必要ありませんが，まず無線LANのアクセスポイントに対し，AppleTVのMACアドレスを登録し，接続許可をしなければなりません。

　はて，AppleTVのMACアドレスってどこに書いてあるの？

　これを探すのに15分。箱にも説明書にも本体にも書かれておらず，二人は途方に暮れました。

　答えは，電源をいれて，メニュー内の情報を表示することでわかりました。まずMACアドレスフィルタリングの設定をしてから電源を入れようとすると，永遠に電源が入りません。やられました。

　続けてネットワークの設定です。

　うちは固定IPで運用をしていますので，DHCPではありません。使いにくいリモコンでポチポチと設定を続けることは，もはや拷問です。

　DNSサーバの設定がおわると，設定完了，のはずです。ですが，画面が次に遷移しません。設定完了のボタンを押しても，次に進んでくれないのです。なにか設定が間違っているのかなあと，もう一度あの拷問を甘んじて受け，戻るボタンを連打して最初からやり直しますが結果は同じ。

　ぶち切れて戻るボタンを連打，メニューまで戻ってみると，あろうことか無線LANに繋がっていると表示されています。なーんだ，設定は済んでいたのか・・・それならそういってくれよー。

　拷問で傷ついた心と体を引きずりながら，いよいよ真面目に操作をしてみますが，なにやらテーブルの上の嫁さんのMacから「プツプツ」という音がすることに気が付きました。もしかして・・・そう，AppleTVのリモコンに，MacBookも反応しているのです。

　上下キーを押すとMacBookの音量も変化してしまいます。これは大変困りました。Appleは，AppleTVのユーザーに，Macユーザーがいないと思っているのでしょうか？？？

　きっと無効にする方法があるだろうと試行錯誤に血みどろになっていると，どうも本体とリモコンはペアリングが出来るらしいのです。日本の家電では，リモコンにスイッチがついていて，こうした問題は起こらないようにわかりやすく出来ていますが，さすがというかなんというか，Appleはペアリングをするんですね。

　いろいろ試していると，どういうわけだかAppleTVがリモコンに全く反応しなくなってしまいました。どうやら，ペアリングを行った上で，解除してしまうと動かなくなるようです。

　こうなると初期化が必要ですが，AppleTVにはなんのボタンもありません。リモコンでしか操作できない製品を，どうやって初期化するのでしょう。

　途方に暮れて私は絶命しましたが，嫁さんが初期化の方法を見つけて，根気よく設定をしました。よって私は，どうやって解決したのかを知りません。

　ここまで，約2時間経過。果たして皆さんは，これを「簡単」といってよいと思いますか？私は理不尽な難解さ，これすなわち「不条理」を感じました。

・使い心地

　せっかく動くようになったのですから，少し使ってみましょう。電源スイッチはなく，操作をすればスリープから起き上がって動き出します。一定時間操作しないとスリープに入るので，ユーザーが能動的に電源を切ったり入れたりすることは，基本的には必要ありませんが，そういう概念も真新しいですから，丁寧に説明が欲しいです。

　動き始めるとサクサクと小気味良い間隔で動き，このあたりはAppleの真骨頂です。もともとOSもCPUもiPhoneやiPadのそれと同一ですので，当たり前の心地よさです。

　日本語の入力が出来ない事は，想像以上に厳しい制約です。特にYoutubeは日本語が入らないと，ダウンタウンの名コント「やすしくん」になかなかたどり着けません。

　そんなこんなでYoutubeは問題なし，大画面でみると面白いものですが，これって冷静に考えるとPS3でできる事ですね。それを言い出すとなんでもそうで，映画のレンタルもネットワークで再生することも，PS3で既に実現していますが，私はやったことがないのです。Appleという会社は，こういう無関心な人にもアピール出来てしまうんですね。怖いです。

・映画を見る

　せっかく買ったのですから，夫婦で映画を見ようということになりました。何を見ようかと考えたところ，公開時に見よう見ようと思って結局見そびれていた，ドリームガールズを見る事にしました。もちろんHDでです。

　2時間以上の映画ですから，終わる時刻を考えて，満腹で苦しいおなかをかばいながら，大慌てで夕食の後片付けをします。やっと終わったとAppleTVを操作し，レンタルをしてみます。

　カードの番号の入力に少し手間取ったのですが，手続きは完了。さーみるぞ，と意気込んでみたものの，再生が始まりません。

　・・・再生できるのは，1時間以上あとだと表示されています。詐欺だ。

　ストリーミング再生出来るんじゃなかったのか，我々は何のために苦しいなか急いで片付けをしたのだ！

　怒りにまかせ，私は風呂に行きました。風呂から出てくると再生可能になっていました。結局再生可能になるのに，1時間半ほどかかりました。

　「1時間もあったら，ツタヤにいって帰ってきて，また返しにいって戻ってくるだけの時間があるやんけ」と毒づいた私を，哀れなものを見るような目でみた嫁さんを忘れません。

　確かにAppleTVは，AppleTVで直接映画をレンタルすると，ストリーミング再生が出来ます。ですから，ダウンロードが全部終わってからでないと見る事ができないというわけではありません。

　しかし，ネットワークの帯域が狭い場合には，途中で途切れることのない程度にバッファリングをしないといけません。AppleTVはなかなか上手に，再生のビットレートとネットワーク帯域の幅から，どれくらいバッファリングすべきかを計算しているようです。

　うちは，ADSLで実力5Mbps程度です。HDのAVCのビットレートがもし5Mbps程度なら，10分程度バッファリングすれば済むでしょう。全部で2時間の映画を，プログレスバーを見る限り半分程度バッファリングしたということは，3時間30分かけて2時間分のデータを取り込んでいることになります。

　ということは，うちのネットワーク帯域である5Mbpsでは全く足りず，その1.75倍の帯域，つまり9Mbps程度ないといけないという事になりますね。

　これから，1280x720のAppleTVのHDのビットレートを9Mbpsとしますと，720x480のSDではこの1/3として3Mbps。これなら全然うちでも間に合いますね。MPEG2はAVCのざっくり倍ですから，DVD-Video出考えると6Mbps相当になりますので，SD解像度の映画でも，ごく普通のDVD-Videoと同程度の画質は期待できそうですね。

　ということで，AppleTVでHDの映画を堪能するなら，10Mbps以上の帯域は確保することをおすすめします。

・画質

　画質は悪くないです。上手く調整をしてあるせいか，9Mbps程度のHDでも目に付いた破綻はありませんし，ごく普通に楽しめました。バッファリングが長かったぶん，途中で止まったり途切れたりすることもありませんし，見ている間は全く違和感も不自由さも感じませんでした。

・結論

　すでにおわかりのように，AppleTVは映画をレンタルして見るという事に限れば，とてもシンプルな仕様になっています。しかし，ここでMacのiTunesと連携する，iPhoneやiPadと連携する，ということになると，途端に話が難しくなります。特に従来AirMacExpressでのみ許されていたAirTunesがAirPlayと名前を変え，AppleTVに対しても音楽をストリーミング出来るようになったので，そういう利用方法が出てくるととても便利になってきます。

　うちはすでにAirMacExpressでAirTunesを使っていますので，特にAirPlayの必要性を感じませんが，AppleTVの底なしのポテンシャルを使い切ろうと考えると，素人にはかなり難しい領域になるように思います。

　価格は8800円，小さくて格好良くて，接続は簡単，使いこなしは底なしに難しく，その代わり自由度も大きいくせに，DLNAには対応しないばかりか，実はPS3でできる事ばかりだったりするこのAppleTVに対する評価は，ちょっと分かれるかも知れません。

　でも，iTunesとの連携でいえば，実質これしか答えはありません。それ相応の覚悟を持って買われるなら，幸せになれる機材といえるかも知れないです。

　ちょうど1年前に作ったGPS時計は，私にしてはソースの公開をしたこともあり，「作ってみたよ」と言う反響を頂く事があります。

　先日メールを頂戴した方は，どうしたら正確なGPS時計を作る事が出来るのか，という問題について悩んでらっしゃるとありました。

　貴重な情報なのでご紹介したいのですが，世の中にGPSモジュールを使って時計を作っている方はいても，1PPSのパルスを使って正確な時計を作っている方は，この方が知る限りいらっしゃらないのだそうです。つまり，GPSモジュールから出てくるメッセージの時刻情報を，そのまま表示しているだけということでしょう。

　この方法では，特にGT-720Fというモジュールを使った場合には，私が昨年悩んだのと同じように，大きな表示誤差を含んでしまいます。最悪で1秒の誤差（というよりここまでずれれば表示ミス）になるため，もはや時計と呼んではいけないレベルです。

　原因は，GT-720Fの時刻情報が，1/10秒以下を.999としてくる場合があることでした。例えば34秒という時刻を，33.999と1/1000秒前の時刻で送ってくることがあり，これを小数点以下省略で表示すると，1秒ずれてしまうわけですね。もっとも，次の更新で正しい時刻表示がなされますが，更新周期が1秒だったりすると，まるまる1秒ずれたままになります。

　34.500とか34.600だと0.5秒，0.6秒ずれるように考えがちですが，この.500や.600は書略されてしまうので，どちらも34秒と表示されます。よって，表示時刻と現実の時刻との間には，ズレはないことになります。

　ということは，現実の時刻が34秒の時に，33秒と表示されることがないようにすれば，表示誤差は更新周期以内に抑えられます。この考え方から，私は33.999は34と見なす，と言う仕組みを入れ込んだのです。

　実際，GT-720Fは33.999だけではなく，33.950という時刻も送ってくることがありますので，1/100秒を四捨五入することで，この問題を回避しています。

　これも，時刻情報の更新周期が1秒だったりすると成り立ちません。GT-720Fはツールを使って更新周期を0.1秒に出来ますから，1秒に10回時刻情報が出てきます。

　これだと，小数点から上の桁が，1/10秒以上ずれることは基本的には発生しません。例外は先程から書いているように，.999に近いところで起こる表示の誤差です。

　33.900なら，次の更新で34.000になりますから，小数点以下を表示しない方法でも誤差は1/10秒以下です。しかし，33.999なら，次に更新されるのは34.100付近ですので，33.900付近の前回の更新から34.100付近の更新まで，下手をすると0.2秒ほどの誤差を作ってしまいます。

　これを，0.950以上は1.000とするという処理で，1/10秒という最小分解能以下の誤差になるようしたのが，今回のミソだというわけです。

　結果として，出来上がったGPS時計が，GPS衛星が原子時計を搭載して，しかも相対性理論まで使って正確な時刻をもっていながら，それらをふいにしてしまうほど大きな1/10秒の誤差を含むという時計に仕上がってしまったわけです。これでいいのか？という疑問は，当然のことです。

　・・・私自身のおさらいはこのくらいにして，この頂いたご意見を読んで思った事を書くことにします。直接のお返事としてもよかったのですが，このGPS時計について私がどんな考えでいるのかを，公開してもよいと考えました。

　現在，個人レベルで現実的に手に入れられる時計で正確なものは，電源同期式の時計か，電波時計だろうと私個人は思っています。

　ご存じのように前者にはAC専用，後者には電波を受信出来る環境であることという制約があり，これは実生活で無視できるほど軽い制約ではありません。GPS時計にはその欠点を補う事を目指して作ってみたので，精度として「ばれない程度」ならそれで目的達成としました。

　といいますのも，1/100や1/1000秒の精度は，どうせ表示に至るまでの間で狂ってしまいますから，追い込むことにそれほど意味がありません。

　ただし，過去に書いたように，1秒近くずれることは論外としても，電波時計と並べて目視でずれているのが分かるくらいの差があると，時計としてもはや成り立っていません。

　これを根本解決するには，1PPSのパルスが出てくるモジュールを使い，しかもこのパルスの少し前に，パルスが出るときの時刻（つまり未来の時刻）を吐き出してくれていることが必要です。

　GT-720Fにはあいにくこんな機能はなく，どうしたって「過去」の時刻しか届きません。手前味噌ですが，1PPSを利用出来ないモジュールを使ったGPS時計として，私の作ったGPS時計はよく検討されて，上手く動いているGPS時計ではないかと思っています。

　GPS時計のメリットは，誤差の蓄積がないことです。水晶発振子を使った電波時計は，校正直後の精度は高くとも，その後は水晶発振子の精度で誤差が蓄積するため，校正後の経過時間が大きくなれば，絶対時刻との間にズレがどんどん大きくなってしまうわけです。

　電源同期式の場合は，発電所や変電所で作られた高精度な50Hzもしくは60Hzを分周して1秒を作るので誤差蓄積はありませんが，あくまで24時間での管理ですので，ある瞬間では大きな誤差を含んでいる可能性があります。

　GPS時計というのは，GPS衛星からの時刻情報ですので，基本的にどの瞬間も同じ精度の時刻情報を得ることが出来ます。これがGPS時計の最大のメリットではないかと，私は思っています。

　ですので，GPS時計を作るということは，この「いつでも同じ程度に正確」という点を生かしたものであるべきだと思いますし，それゆえ精度を衛星に搭載された原子時計レベルにすることまでは必要ないと考えています。

　そうなるとおのずと設計の仕方が見えてきて，表示が実際の時刻とどれくらい狂っているかを，きちんと実用上問題のない程度であるかどうかを含めて把握して，それ以上のズレにならないことを保証することに力点を置くことになります。

　この力点に向かって進めて，結局私は1/10秒の精度を常に保証する時計を作りました。これが自作の醍醐味です。本当に正確なGPS時計が欲しければ，市販のGPSロガーを数千円で買うのが一番なのですから。

　さらにその醍醐味は，より高精度なものを作ろうと思案することにもあるでしょう。しかし残念ながら，1PPSが取り出せないGT-720Fでは，もう無理だと当時は考えました。だって，衛星の時計と同期したパルスが出てこないんだから，どうしようもないじゃないですか。

　・・・ん，まてよ，もう1つGT-720Fを使ったらどうだろう，いや1つと言わず，10個くらい同時に動かして，時刻の情報の多数決や平均など，統計的手法でデータの処理を行うと誤差が薄まらないか。うーん，やってみる価値はありそうだなあ。でもいくらかかるんだろ。

　こんな風に，いろいろなアイデアを出しては実験できることが，自作のおもしろさ，なんですね。

　昨日の波形から，もう1つ波形を一緒に取って，データとアドレスを特定しようという話を昨日書きました。面白そうで時間もかからないということもあり，昨夜寝る前に試して見ました。

　上はデータバスのD0，下はアドレスバスのA0です。

　赤い線はA0が変化するタイミングで私が勝手に引いたものです。ちょうど等間隔に引かれており，その間隔は約1.6usと，このシステムの1サイクル（1.63us）と一致しています。CPUが生きててよかったです。

　で，このオシロは2現象ですのでEクロックやアドレスストローブ（AS）を一緒に観測できなかったのですが，下位アドレスのラッチはASの立ち上がりで行われますから，この赤線のタイミングが，ASそのものと考えて差し支えないと思います。

　さてさて，今回のD0の動きを見ていて思ったのですが，現在SRAMを全て外してありますので，もしCPUがSRAMからのリードを行おうとしたら，バスはオープンになってしまいますので，1MΩのプルダウンだけがみえてしまいます。

　だけど，プルダウンが行われているので本来なら0Vまで落ちきってくれねばいけないところです。ここに0.6Vから0.7V程度の電圧が残っているということは・・・なんかヒントの香りがしてきます。

　それはそれとして，ASでアドレスをラッチしたしばらくあとに，データがのるわけですが，この写真，例えば一番左に写っているサイクルだと，D0にまずアドレスがHighとして現れASでラッチ，A0がHighに固定されたのち，D0がLowに落ちて0を示そうとしています。

　しかし0.7V付近まで落ちているだけで，0Vまで落ちきっていません。次のサイクルのように，CPUが能動的にこのピンにLow出力を出せば，ちゃんと0Vまで落ちるので，どうやらこの時CPUはリード，つまり入力側になっているようです。これもR/Wを一緒に観測しないと断定できませんが・・・

　D0のデータが0.7V付近で，次のサイクルでアドレスがLowで出てくるとちゃんと0Vまで落ちます。ここでASが立ち上がり，LowがA0としてラッチされます。ラッチがおわると，D0にはデータがのり，これをCPUが取り込むようです。このサイクルでも，CPUが入力になると中間電位になっていることがわかります。

　
　うーん，これはかなり面白くなってきました。

　やはり，この中間電位は，なにかを物語っています。どういう状況の時にこの中間電位が起こるのか，もっと多チャンネルで観測するべきです。

　R/WによってCPUが何かを吐き出しているのか，それとも吸い込んでいるのかを見ることも大事，CSによってどのデバイスをアクセスしているときに起こっているのかを見ることも大事です。少なくともD0，A0，R/W，そして各CSについては一緒に観測すべきですね。

　幸いこのオシロには，16chのロジアナが同じ管面に表示出来ます。中間電位を取るD0はアナログでみるとして，それ以外はロジアナで見る事にしましょう。

　この中間電位は，かならずどんなときにも出てくるわけではありません。またSRAMが付いている時でも同様に中間電位を持つことがありました。SRAMを外したから起きているということではないと考えています。

　CPUがなにをアクセスし，それを相手に読むのか書くのか，それが分かると，案外原因をさっと特定できるかも知れません。

　HC-20の修理状況です。

　Vcの電圧が正常に出るようになったところからのお話です。

　データバスとアドレスバスの波形をオシロスコープで眺めていると，データバスの波形で，0Vと5Vの間の中間の電圧を取っている時間があることに気付きました。階段状に何段も出てくる部分もあります。

　写真左側のLowの波形をご覧下さい。Lowが0Vまで落ちきっておらず，0.7Vくらいの電圧を持っています。そこからHighになりたいのでしょうが，2.7Vくらいで一度上昇がとまり，そこからよいしょ，と5Vまで上昇しています。

　右側のLowの波形はきれいですね。どちらかがデータ，もう一方がアドレスを示すのですが，どちらが異常でどちらが正常かは，波形だけではわかりません。タイミングを見ると左がアドレス，右がデータではないかと思うのですが，他の波形を一緒にみないといけないですね。

　以前にも書きましたが，HC-20におけるメインCPUのバスは，マルチプレクスされたモードで動いていますので，データバスにはデータとアドレスの両方がのります。アドレスはDラッチでASによってラッチされ，分離されます。

　データはそのまま分離されずアドレスと一緒にバスに乗りますが，アドレスもデータも確定したところでEクロックがHighになるので，CPUなりメモリは，このタイミングでデータを取り込むなり吐き出すなりすればよいわけです。

　こういう波形が出てくるというのは，バスの出力の衝突です。

　原因はいろいろ考えられます。基板のパターンがショートして，隣のバスラインとくっついてしまったとか，バスにぶら下がっているICが破損し，ショートしてしまったとか，入出力を持つICの，データの方向を切り替える仕組みが壊れてしまって衝突しているとか，とにかく出力がぶつかっているということです。

　この時代の，しかもこの速度のコンピュータですから，中間電位が出てきて正常ということはありません。むしろ動かない状態にあることが正しいといってもいいでしょう。

　そこで，この階段状の波形の原因を突き止めることにしました。すくなくとも，これが出ている内は，絶対に直らないと考えたからです。

　まずバスのショートを確認します。1本1本データバスにテスタをあてて，抵抗値の下がっている部分を探していきますが，これは問題なし。どれも500kΩ以上の抵抗でセパレートされています。

　そうなると今度はICの故障かも知れませんね。

　と気軽にいいますが，バスラインにぶら下がってるICというのは貴重なものが多いのです。筆頭はマスクROMですが，これはソケットに刺さってますので，外して確かめれば，原因かどうかははっきりします。

　果たして，原因はマスクROMではありませんでした。

　次にソケットが使われているのは，RTCのMC146818です。これは初代IBM-PCで，CMOSと呼ばれた部品です。当時CMOSでバッテリバックアップが可能なデバイスというのはまだ珍しく，小容量のSRAMとRTCを組み合わせたこのデバイスを，CMOSと呼ぶことは自然な事であったのです。

　これをソケットから外しましたが，波形には相変わらず階段状の波形がでています。これが原因ではなかったようです。（しかし良品であるという話でもありません）

　ならばSRAMだろうか，と，SRAMを8つ全部，ハンダ付けを外しました。これはかなり勇気のいることで，基板の破損も怖いし，手間もかかります。

　そこで，これを256kビットのSRAMに交換して，32kByteにすることを計画し，現在使われている16kビットのSRAMは全て外すことにしました。

　さて，取り外したのはいいのですが，やはり中間電位を取り，階段波形がバスラインにのります。そうなると，他のICを疑う必要が出てきます。

　まだ他のICを試せていませんが，その前に，今回測定した波形と一緒に，Eクロックやラッチされたあとのアドレスバスの波形を観測し，それらの時間関係を確認すれば，この衝突した波形がアドレスなのかデータなのか知る事が出来るでしょう。そうするともっと原因を絞り込める様に思います。

　時間は以前よりもあるように思うのですが，やはり一人暮らしと違って自分勝手に過ごすというのは難しいのが現実です。そうこうしているうちに，この勝利に対する興味や熱意を失ってしまうことを，私は密かに恐れています。