エントリー

カテゴリー「マニアックなおはなし」の検索結果は以下のとおりです。

HC-20の修理その5?完結編

ファイル 434-1.jpg

 HC-20の修理に関する検討が,あっけなく終了しました。

 前回,SRAMのOEをGNDにして常にLowにしておくと動作せず,Eクロックの反転(正確にはEクロックの反転とSLEEPのAND)をつなぐと動作するので不可解だと書きました。

 不可解なまま終わらせても結果が良ければそれでよいという考え方もあり,疲れていた私としては逃げるように終わりにしようと考えたのですが,やはりここは白黒はっきりさせないといけないと考え,波形をきちんと取って,検証しようと考えました。

 疑問の根本は,OEが常にLowになっていることと,Eクロックの制御でLowになる,すなわちアクセス時にLowになるという動きとの間に,どんな差があるというのかという点です。

 前回書いたとおり,OEは常にLowで問題はないはずです。もちろん,アクセス時にLowになる事でも問題はないはずですから,今回の疑問は動くはずの回路でなぜ動かないのか,という点に尽きます。

 この話,先日ゆっくり風呂に入って検討の計画を練っているときに,解決の糸口が突然ひらめいたのです。

 とても単純な話ですが,OEをGNDに接続する際,もしかするとSRAMの一番左下のピンにハンダ付けをしたのではないのかと,ふと思い出したのです。

 普段面実装品ばかりを扱う関係で,ついついTopViewで考えてしまう癖がついていますが,今回のSRAMは面実装品を基板の裏面に取り付けましたので,裏返して取り付けています。ということはBottomViewで考えないといけない訳です。これをミスしていたのではないか,そんな疑惑が出てきたのです。

 そして疑惑は確信に変わりました。今日,意を決して本体をもう一度分解し,基板を確認したところ,本来の接続先である右下(つまりSRAMの15ピン)は,全くハンダ付けされた形跡がありません。

 なにも考えず,とにかくOEをGNDにつないで通電します。

 動きました!全く問題ありません。当たり前と言えば当たり前の話です。

 結果として,私が先日書いた通り,OEはGNDで問題なし,もちろんEクロックの反転でも問題なしです。SRAMにとっては,どちらも同じ意味です。

 消費電流ももう一度きちんと計り直しました。

 OEをEクロックで制御する場合も,GNDに落とした場合も,全く同じ電流となりました。動作時には22.7mA,スリープ時には12.1mA,そして電源OFF時には35.9uAです。この時の電圧は5.3Vです。

 電源ON時の平均消費電流は17.4mAとなり,前回よりもかなり小さな値です。エネループは1800mAですので,実に103時間。これはかなり良好な結果です。

 電源OFF時の電流は約36uAですから,実に50000時間!2083日,69ヶ月,5年以上も持ちます。まあさすがにこれは出来すぎですが,1年くらいは確実に大丈夫でしょうね。

 ということで,自分なりに納得のいく結果が得られました。特に消費電流にについては疑問も多く,こういう結果になったことは大変うれしいです。

 メモリは32kByteを実装しています。256kbitのSRAMを1つだけ使って,これを実現しています。証拠写真を載せておきます。STAT ALLと打ち込んだ結果です。

ファイル 434-2.jpg

 思えば,今回の修理も大変でした。基板が電解コンデンサの電解液で断線するという,当時の設計者があまり考えなかったようなことで故障したマシンを,手作業で修理することの面倒くささたるや,筆舌に尽くしがたいです。

 戦前,特にラジオが真空管を使い始めた頃の最先端技術として,電解コンデンサが登場しました。当時誰も見たことがなかった数十マイクロファラッドという巨大コンデンサが現実になったことで,電灯線から直流を得ることが可能になり,アンプの音質も改善したはずです。それがのちのち,経年変化として最悪の事態を招くとは,皮肉なものです。

 しかし,今回の修理は私にとって新しい地平を開いたも同然でした。私は80系の人で,68系のハードウェアは組んだことがありませんし,深くその動作を考えたこともありません。Eクロックに同期する同期バスというのも,言葉としては理解していても,実感を伴った,血や肉となる知識ではりません。

 それが今回の一件で,かなりバスのタイミングについて学ぶ機会を得たわけです。Eクロックに同期するとはどういうことか,バスサイクルとはどういうことか,6800や6809を使ったシステムを作ることを疑似体験させてもらいました。

 苦手意識はすでに去り,RAMでもROMでもI/Oでも,Z80も6800も気にせず遣い回すことが出来ます。この点は重要なことで,古いマシンを修理するのに,元の部品が手に入るとは限りませんから,手もとにあるものでうまく代用する必要があります。68系だから駄目というような贅沢は言ってられないのです。

 とてもいい勉強になったことと,その動作を丁寧に拾っていったことで,HC-20にはとても愛着がわきました。PC-8201でも,PC-2001でも,PC-1245でも,論理的な裏付けによって期待する動作が確定したときの充実感は,そのマシンへの愛着に帰着します。名機たるHC-20に愛着がわかないことに後ろめたさを感じていた過去とは,これで決別です。

 せっかくうまく動いた訳ですから,なにか実用的な利用法を考えたいところです。なんといってもフルスペックのBASICと,小型のプリンタを内蔵しているのです。うまく利用法を考えたいと思います。

ファイル 434-3.jpg

 しっかし,疲れた。

HC-20の修理その4

 HC-20がとりあえず現状復帰しました。RAMは16kByteのままです。

 わずか2kByteのSRAMを8つも搭載して16kByteというのはあまりに不細工ですし,HC-20は最大32kByteのRAMをサポートしていますから,できる事ならRAMくらいフル実装してあげたいところです。幸い手持ちにMB84256という256kbitのSRAMが大量にあります。

 こうした動機から,修理の初期段階で工場出荷時のSRAMを全部基板から取り去り,256kbitのSRAM1つに換装して,大失敗をしたわけですが,その後もこの話はちょっと手間取っていました。

 この手の非同期SRAMというのは,CSというチップ全体をONにする端子と,OEというデータの出力を制御する端子,そしてWEという書き込みを制御する端子の3つで制御します。

 CSはチップ全体ですので素早く反応出来ません。通常,SRAMをランク分けするアクセスタイムという数字は,この速さを示しています。

 OEはCSの速度よりずっと速く動きますが,あくまで出力を出すか出さないかという端子に過ぎませんから,SRAM全体の電源を切る行為に相当するスタンバイモードへは遷移できませんし,WEよりも優先度は下になります。

 WEは書き込みの端子ですが,先にCSをEnableにしてからWEをEnableにするWEコントロールドライトと,先にWEをEnableにしてからCSをEnableにするCSコントロールドライトがあります。

 どちらも同じように思うかも知れませんが,書き込み動作が行われるのがWEなのかCSなのかという大きな違いがあり,WEの役割が前者は書き込みのトリガ,後者がバスの方向を切り替えるスイッチという点で,考え方を変える必要があります。

 一方,HC-20で使われているSRAMは,ちょっと違っています。OEがなく,CSがCE1とCE2の2つになっています。この2つはANDであり,両方の端子がEnableにならないとSRAMがONになりません。(えと,CSかCEかはメーカーによって違うだけで,ほぼ同じ意味で使われています。私個人はCEだとややこしいので,インテル風にCSと言うようにしています。)

 ここで,それぞれの真理値表を書いておきますね。CSとOEを持つSRAMはMB84256,CE1とCE2を持つSRAMはHC-20で使われているuPD449という古いSRAMとします。

 MB84256
CS OE WE  状態
H  X  X Stand-by
L  H  H Hi-Z
L  L  H Read
L  X  L Write

 uPD449
CE1 CE2 WE 状態
X  H  X Stand-by
H  X  X Stand-by
L  L  H Read
L  L  L Write

 見ての通り,大きな違いはSRAMが選択されても出力を出さない状態の有無と,書き込み時にCSさえEnableなら書けてしまうかCE1もCE2もEnableでないと書けないかという,そういう違いです。

 考え方として,CSとOEを持つSRAMのわかりやすいところは,

(1)アドレス確定
(2)チップ選択
(3)動作指定(Read or Write)

 という具合に,時間軸できれいに整理出来るのですね。私はこれに馴染んでいる人ですが,どちらかというと80系はこれかなーと思います。

 一方CE1とCE2のあるケースだと,

(1)アドレス確定
(2)動作指定(Read or Write)
(3)チップ選択(CE1とCE2同時)

 となりますので,結果は同じとはいえ,なんか気持ち悪いです。(2)と(3)が同時だったりするので,どうもしっくりきません。

 さて,通常,SRAMを換装する場合のセオリーは,CSがアドレスデコーダからの出力に接続,OEはRD,WEはWEに繋ぎます。

 で,80系だと,メモリ空間とI/O空間が分かれているので,それがメモリ対象ならMERQが,IO対象ならIORQが,それぞれ同時に動きます。そこでメモリのRDとWEについてはMREQと,IOのRDとWEについてはIORQと,それぞれANDを取ってやるのです。

 この接続は,アドレスの確定,チップの選択,動作指定という流れに綺麗に従っており,80系のバスタイミングにそれなりに合致します。(といいますか,非同期SRAMの動作として,極めて自然だと思います。)

 同じ考え方で,HC-20のSRAMを,MB84256に換装することにしたわけですが,この試みは失敗に終わるわけです。

 まず,アドレスデコーダです。HC-20のSRAM空間は,0100hから7FFFhまでです。0100hなんてCP/Mっぽくて笑ってしまいますが,CPUの内蔵RAMとI/O空間ですので,ここはSRAMの空間ではないという,それだけの意味です。

 80系のCPUと違い,68系のCPUはRESET解除後,プログラムカウンタを0にして起動せず,FFFEhとFFFFhに書かれた値をプログラムカウンタにロードして起動します。リセットベクタを可変出来ることはメリットのようで,私は別に大した利点に見えないのですが,こういう事情もあって,HC-20では80系マシンと違い,RAMを前半32kByte,ROMを後半32kByteに配置してあります。

 HC-20の回路図によると,8つのSRAMのアドレスデコーダは定番の74138(実際にはTC40H138)を使っています。そして,このデコード出力は,0000hから00FFhまでをデコードしたIOCS信号とリセット信号によっても制御されています。このデコーダの出力はSRAMの18ピン,CE2に繋がります。

 1チップで32kByteを実現するMB84256のアドレスデコーダを作るためには,A15が0,リセットが1,そしてIOCSが0の時にEnableになるような回路を作ればよいのです。私は手持ちの関係で74LV00を使って,このデコーダを作りました。デコーダの出力は,前述のセオリー通りCSに繋ぎます。

 続いて,OEはオリジナルのSRAMの20ピン,CE1に繋がっていた信号を繋ぎます。これは結局6800系に特徴的なEクロック(の反転)です。HC-20の場合,Eクロックの反転と,SLEEPの時にLowになる信号のANDを取ってあり,SLEEP中にはSRAMへのアクセスが起こらないようになっています。消費電力の低減にも役だっています。

 そうそう,SLEEPというのは,別に電源を切ったときのことを言っているわけではなく,なにも処理を行っていないときに動作を停止して,消費電流を半減させる仕組みです。キーの入力などの割り込みで通常モードにさっと復帰します。これを1982年当時にやってるんですね,すごいです。

 WEはそのまま元のSRAMのWE,データバスとアドレスバスもそのまま繋ぎます。

 ところが,すでに何度も書いているように,動きませんでした。画面にゴミが出まくって,暴走します。

 配線間違いやら勘違いでもしたかなと,深く考えずにCSとOEを入れ替えてみると,なんとまあさくっと動いてしまいました。これが一昨日の話です。

 「動いたんだから成功だ!これでいこう!Ok!好了!」

 とビールを飲み始めるも,なぜかおいしくありません。釈然としないのです。

 何度も書きましたとおり,CSにはアドレスデコーダからの出力を繋げていました。しかしこれでは動かず,アドレスデコーダの出力をOEにつなぎ,EクロックをCSに繋いで動くというのは,どう考えても納得いかないわけです。

 まずは動かないはずの配線で,なぜ動くのかを考えます。

 まず,HC-20で使われているuPD449のCE1とCE2はANDされた端子であり,どちらかが優先されることはなく,機能も全く同じです。ゆえに,uPD449のCE1とCE2と入れ替えても動くはずです。

 では,CSにEクロックが入った場合を考えます。Eクロックはバスサイクルを示すすべての基準信号ですが,Highの時にリードかライトが起こります。CSがEクロックで制御されSRAMがONになるのですから,これはOKですね。

 これに引き続き,OEにアドレスデコード信号が入った場合です。アドレスのデコード出力が入ると,データが出力されます。他のアドレスのメモリからはデータが出ませんので,バスの衝突は起こりません。従ってリードは成立します。

 最後にWEです。WEはOEに優先しますから,EクロックがHighでWEがEnableだと,書き込みが起こります。これだと他のアドレスを持つ別のデバイスへの書き込みでもSRAMに書き込みが起こってしまうので,本当だったら暴走するはずです。

 しかし,HC-20の場合,外部のデバイスはなんとSRAMしかありません。RTCもあるにはありますが,RTCであるMC146818へは,純正の68系ファミリらしく,専用の方法でアクセスされているので,SRAMと同じ非同期のバスにぶら下がっている書き込み可能なデバイスは,他にはないのです。

 よって,WEがEnableになるのは,SRAMへの書き込みだけとなります。SRAMが複数チップにあると暴走しますが,今回は1チップですから,暴走もしないわけです。

 うーん,動いているには違いないのですが,やっぱりおかしいです。

 試しに,ほぼすべてといっていいRAM空間を,55hとAAhで埋め尽くすテストを行いましたがエラーはなし。クロック600kHzのマシンなら,タイミングは多少ダルでも動いてしまうのでしょう。

 ですが,モニタからROMのアドレスであるE000hに書き込みを行うと,SRAMの6000hにおかしな値が書き込まれました。アドレスのデコードが行われずに書き込みが行われるのですから,ROMの出力とCPUの出力が衝突し,これがWEで書き込まれたのでしょう。

 実際にROMへの書き込みは通常起きませんから,このままでも実用上は問題ないのかも知れません。しかし,データの衝突も起きていますし,もし拡張スロットにデバイスを追加するようなことがあったら,完全に破綻します。それに,たまたま動いているだけの話ですから,ダメなものはダメというところでしょう。

 では,逆の見方をして,なぜ動くはずの回路で動いてくれないのでしょうか。CSにアドレスデコード出力,OEにはEクロックの場合を考えてみます。

 68系のタイミングチャート見ていると,WEに繋がっているR/W信号は,バスサイクルの先頭で確定し,終了までその状態が維持されます。アドレスも同じで,従ってアドレスデコード信号も,1サイクルの間動きません。

 OEはEクロックですので,バスサイクルの真ん中辺で変化します。データが有効なところでHighになります。

 バスに乗っているデータは,このEクロックがHighになったところで有効になるわけですから,書き込みはこのタイミングで行われなければならないのに,EクロックがLowのところでもWEがEnableになっています。もし,WEコントロールドライトであったとしたら,正しいデータは書き込まれません。

 ここで改めて考えてみると,元のSRAMはCE1とCE2を持っていました。CE1とCE2はANDされて,MB842156でいうところのCSに内部で繋がっています。

 ということは,アドレスデコード信号とEクロックのANDを取って,CSに入れているのと同じことです。一方,MB84256でいうOEは常にEnableになっていると考えられます。

 ということは,HC-20の書き込みは,先にWEを確定し,CSをトリガにするCSコントロールドライトであるということです。いやー,今さらなにを,という感じです。

 しかし,私が動くはずだといっている回路では,WEが先に確定し,次にCSが確定するべきなのに,CSに繋がっているのはアドレスデコード信号ですから,WEと同時にEnableになります。ここではデータがバスに乗っていませんから,正しい値が書き込めるはずもなく,そりゃ暴走するわけです。

 ゆえに,OEとCSを入れ替えてEクロックをCSに入れれば,CSコントロールドライトでめでたく書き込みが成立するわけで,動くはずのない回路で動くことの説明もつきました。

 なら,対策は簡単。

 uPD449のCE1とCE2と同じように,アドレスデコード信号とEクロックのANDを取ってMB84256のCSに入れて,OEはGNDに落とせばよいのです。

 幸い,MB84256の真理値表を見ると,OEの優先度は最低で,スタンバイも書き込みも,OEの状態は無視されます。有効になるのはWEがDisableで,CSがEnableのときだけですから,ずっとGNDに落としておいても問題なさそうです。

 なお,CE1とCE2という具合に,CEを2つ持つSRAMには厳密に言うと2種類あります。SRAMの基本形はCSとOE,そしてWEであることを前提にすると,OEをGNDに落としCE1とCE2が本当にANDされてCSに入るというもの,例えばuPD449やHM6118などがこれに該当します。

 これに対し,OEにはCE2が,CSにはCE1とCE2がANDされて繋がっているものもあります。TC5116やHM6117がこれに該当しますが,CE1だけがEnableになっても動作せず,CE2もEnableにならないと動かない点では前者と同じですし,CE2すなわちOEだけがEnableになっても動作しないことも同じです。

 ただ,前者と違って,CE1とCE2は全く同じではなく,CE2はOEにのみ繋がっていますからCE2の動作速度はOEと同じで,高速に動作します。CE1があらかじめEnableになっていれば,CE2で出力を制御できる訳で,OEの高速性を犠牲にしない合理的な方法と言えます。

 今回問題になっていることは,EクロックがOEに繋がっているがゆえにライトの時に無視されることであり,この回路が期待するCE1とCE2が共にEnableになることで行われるCSコントロールドライトに失敗することにあります。

 ですので,TC5516でもHM6117でもuPD449でも,どれでも今回の場合は問題ないという事になります。平たく言えば,細かいタイミングではなく,真理値表が問題だということですね。いやー,中学生以来の疑問,TC5516とHM6116の使い分けがやっと分かった気がします。まだまだ未熟者です・・・

 では試してみましょう。ANDを取るといっても負論理ですので,ORゲートが1つ必要です。手持ちにHC32が2つ入ったTC7W32がありますので,これを使います。

 それで,結果なのですが・・・ダメです。動きません。画面にゴミが出ておわりです。

 これだけ考えてダメということは,かなり凹むところなのですが,OEをGNDに常時落としてあるところが引っかかっていて,OEをEクロックの反転(つまり元のCE1)に繋ぐと,あっさり動き出しました。

 メモリチェックも通り,ROMへの書き込みでもRAMが破壊されません。

 なんでだろう。

 OEをGNDに落とすと,CSがEnableになると無条件にデータが出力されるわけですが,CSはアドレスデコード信号とEクロックのANDを取ってあるので,結局EクロックがHighの間しかデータは出てきません。

 OEをEクロックの反転に繋いでやったことと,見た目にはなにも変わらないはずなのに,片方は動かず,もう片方は問題なく動いています。不思議です。

 書き込みもスタンバイも非選択も,OEの状態は無関係です。読み出しの時だけLowでなければならないと決まっているだけですから,OEを常時GNDにすることで問題はないはずなのです。繰り返しますが,OEをEクロックの反転とANDしたって,CSにはEクロックが織り込み済みなわけですから,同じことのはずなのです。

 理論的には手詰まりになり,今も動かなかった原因,動いている原因を考えているのですが,どっかでバスの衝突が起きているということくらいしか思いつきません。

 部屋が散らかり放題散らかっていることと,疲れていることを理由に,論理的裏付けはなくとも,そのまま話を進めることにします。

 バッテリと直結で安定化されていないVLとVCの2つの電源は,DC-DCコンバータで昇圧,安定化します。VBとVCおよびVLに繋がったパターンをカットし,この間にHT7750を使ったDC-DCコンバータを挟み込む感じです。

 で,電池は結局エネループを4本使うことにしました。そうすると電池の収納場所が問題なのですが,いろいろ触っている内に名案が閃きました。

 マイクロカセットやROMカートリッジが格納される場所は,私のHC-20は中身が空っぽのダミーカートリッジがついています。ここに単3のエネループを4本入れると,ちょうどの大きさです。

 ここから逆流防止用のショットキーダイオードを通し,VBに繋ぎます。順方向電圧だけ下がってDC-DCに入りますが,DC-DCの出力は問題なく5Vで安定化されます。後述しますが,電圧検出はVBで行います。

 一方,ACアダプタからは,7805で5Vに安定化してVBに突っ込みます。幸い逆流防止用のダイオードは最初から基板についているので,これをそのまま流用します。

 ところが,電圧検出器の設定電圧が,下が4.49V,上が4.89Vでヒステリシスを持つようになっており,普通のシリコンダイオードを通った後の電圧が4.4Vあたりまで下がると,もう動作しなくなってしまうのです。

 実はこの話,電池の場合も深刻です。Ni-MHの下限電圧である1.1Vまで使い切ると,トータル4.4Vです。ここまでは動いて欲しいのですが,ショットキーダイオードを通して0.3Vも下がってしまうと,満充電の電池でもわずかな時間しか駆動できそうにありません。

 そこで,ヒステリシスを持たせないようにR51を削除,また検出電圧を4.0Vあたりまで下げるため,R5に2.2kΩを直列に追加しました。

 さらに,7805のCOM端子にダイオードを入れてかさ上げします。0.6Vくらい上がるかと思ったのですが,逆流防止用ダイオードの後で,最終的に5.3Vくらいになっていました。これがそのままあちこちに加わりますが,一応動作電圧範囲内なのでよしとしましょう。

 これで,エネループでも対応になりましたし,9Vくらいの非安定化タイプのACアダプタでも問題なく動作するようになりました。あやまって高い電圧のACアダプタを差し込んでも壊れることはありませんし,バッテリも使い切ることができます。

 もともと入っていた電池は4.8Vで1100mAhのNi-Cd電池です。ということは5280mWhです。これがエネループになると,4.8Vで1800mAhですので,ざっと1.64倍に増えました。

 消費電流は,動作時27mA,スリープ時12mA,そして電源OFF時に400uAという結果です。改造前は電源OFF時が600uAと大きかったのですが,RAMの数が減った分少なくなり,DC-DCが増えた分増えて,このくらいの値になったのではないかと思います。

 で,動作電流は,27mAと12mAで変動します。平均すると約20mAですね。この状態で1100mAhの電池を使い切ると,ざっと55時間。メーカーの公称値が50時間ですので,まあこんなものでしょう。

 これが今回のエネループになると,実に90時間も動作することになります。随分とグレードアップしたものです。

 また,電源OFFの時の電流が0.4mAですので,4500時間。約187日ですので,半年くらいは持つ計算ですけど,半年というのはちょっと短いなあという印象です。1年くらい持って欲しいです。

 実は,検討の途中で一度電源OFF時のバックアップ電流を測定したことがあり,この時は40uAと一桁少ないものでした。なぜ今回増えたのか,ちょっとわからない(もしかすると見間違いかもしれない)ので,とりあえず現実を受け入れようと思います。

 ここまでの作業を切った貼ったで切り抜けて,なんとか動くところまで持っていきました。肝心要の理論的裏付けがまだですので,これで終わったわけではありませんけども,一応形になり,動かすことが出来るようになりました。

 動いて見ると,実に他愛もないコンピュータなのです。当時は小さく,軽いものだったかも知れませんが,私が今使っているMacBookAirと比べると,パワーも大きさも軽さももはや桁違いと言ってもよいくらいです。

 ただ,机の上に並べられた2つのモバイルマシンをつくづく眺めてみると,全てのノートパソコンは,このHC-20から始まったということを実感します。世界初のノートパソコン,それがHC-20です。

 HC-20には,完全CMOS構成,RAMのバッテリバックアップ,電源ONですぐ起動,そして演算やキーの操作が行われていないときには消費電力を半減させるステートがあるという,現在のパソコンの原理を先取りする仕組みがあります。

 形の上で,ノートPCの元祖と言うだけではなく,技術的な仕組みやそれをやろうとする動機となる,いわばモバイルとはこうあるべきという設計思想という点で,HC-20は始祖であると,私は思いました。

ラムダッシュの自動洗浄機の問題が突如解決

 自動洗浄機のトラブルで困り果てていたラムダッシュですが,あっけなく問題が解決してしまいました。

 洗浄中の泡の発生がものすごく,その結果空気抜きのパイプに泡が侵入し,水浸しになったり空気が抜けずに洗浄液がプールに溜まったままになったりと,散々な問題を起こしており,洗浄液の濃度を下げる,洗浄液を少しすてて液面を下げるなどの工夫で,騙し騙しここまでやってきました。

 しかし,水で薄めて泡の発生を抑えても,翌日にはなぜか元のように盛大な泡が発生してしまいますし,洗浄液を少し捨てても捨てた分だけ泡が発生して結局結果は同じという,なんとも不思議な現象が起こっています。

 異物を投入したり水を入れて薄めたりと,雑菌の発生がかなりあるのでしょう,実はこの1ヶ月ほど,毛穴からばい菌が侵入して,吹き出物がひどいです。

 このままでは埒があかない,一か八かで,カートリッジを交換してみることにしました。

 前回も交換して何の改善も見られなかったので,今回もダメかもと思っていましたが,冷静に考えてみると今回のカートリッジは,購入時期も場所も異なる,別ロット品(と思います)です。

 カートリッジは3つで1パックですから,前回と前々回は少なくとも同じパック。その前ももしかすると水漏れが起こっていて,そのせいで空気抜きのソレノイドが断線したと考えられます。

 しかも,この状態で約1ヶ月使い続けたのですが,ヒゲくずがタンクに入って底に溜まっています。しかもぶよぶよとしたゼラチンのようなものが,タンクの内壁にへばりついています。

 以前はこんなことは全くなく,ヒゲくずはカートリッジのフィルタで越し取られ,タンクには洗浄液しか入ってきません。それがこういう状況になるというのは,どうもカートリッジに問題があるようです。

 これでだめなら捨てるだけ,とカートリッジを交換して洗浄すると,なんと,あっさり元通りになりました。

 泡もほとんど発生せず,ヒゲくずもタンクに戻りません。もちろん髭剃りは清潔を保っており,油も供給されるせいでしょうか,そり心地もよいです。

 こんなことなら,さっさとカートリッジを交換しておけばよかった,1ヶ月もかけて検討するようなことだったのかどうか,私はとても悲しくなりました。

 残念な事に,このパックのカートリッジは全部使ってしまい,捨ててしまったので手元にはありません。不良品として送り返せば代わりのものくらいは送ってもらえたかもしれませんが,もはやそれも出来ません。そんなことより,やっぱり時間の無駄と,顔の吹き出物が悔しいところです。

 これまで外側のカバーを取り付けず,むき出しの状態で使っていた洗浄機ですが,これをうけて元通り取り付けて,現状回復となりました。カートリッジは検査できませんから,こうした不良が混じってしまうとどうにもならなくなるのは分かりますが,水漏れや体調に関わる問題だけに,慎重になって欲しいと思います。

 おそらく,パナソニックはこうした問題に気が付いていないのではないかと思います。また,「ラムダッシュ カートリッジ 不良」でgoogle先生に聞いてみても,それらしいものは出てきません。

 私だけの問題とは,ちょっと思えないのですが,皆さんどうしているのでしょうか。私はとりあえず,カートリッジが原因だったようです。

 これから年末,新年を迎えるにあたり,とりあえずボロボロになった顔の傷が治ってくれることを,期待したいと思います。

HC-20修理その3

 この土日,集中的に検討の時間を確保,朝から夜まで徹底的に調べることで,故障していたHC-20がとりあえず動き出しました。今回は原因がきちんと絞り込めず,時間ばかり消費するという,まさに忍耐の修理でした。

 修理に取りかかった早い時期にバスの衝突が起こっていることがわかったわけですが,メモリの不良の可能性を潰すことも考慮して,もともと付いていた16kbitのSRAMを全てとっぱらい,代わりに256kbitのSRAMに置き換えるということを行いました,実はこれが故障原因の発見を遅らせた張本人で,余計なことをすると失敗するといういいお手本になりました。

 やはり,修理というのは,順番に手順を追ってやっていかないとだめですね。

 さて,故障の根本原因は,電解コンデンサの液漏れによる,プリントパターンの断線にありました。断線箇所は全部で3箇所です。

 まず,SRAMの電源であるVCのスイッチのトランジスタQ7のベースと,R40との間が切れていました。これは最初に発見した断線だったので日誌にも書きましたが,修理することによりSRAMの電圧が正常になり,動作時で5V,バックアップ時で3VがSRAMに供給されるようになりました。

 次に,SRAMのCE2が切れていました。場所は16Cという場所で,アドレスはおそらく1800から1FFFまでの2kBです。ここと16Dにある40H138の12ピンとの間が断線し,SRAMのCE2はオープンになっていました。

 通常,SRAMはチップ全体の動作を制御するCSと,出力を出すか出さないかを制御するOEの2つで制御します。しかしHC-20で使われているSRAMは,CSに相当するCEが2つあり,それぞれCE1とCE2と名付けられています。どちらも全く同じ働きです。

 SRAMのCE2がオープンになることで,バスの衝突が起きていたと考えられます。惜しいですね,バスの衝突まで分かっていたのに・・・

 最後に,これは回路図の記載を見つけられなかったのですが,uPA54Hというダイオードアレイの,7ピンが切れていました。プリンタへのコネクタの近くにあり,プリンタのヘッドのドライバICと列んで配置されているので,おそらくヘッドか,モータの逆起電力吸収用のものではないかと思います。

 この3つの内,結局2つ目のSRAMのCE2の断線が一番大きな問題だったわけですが,これを見つけたのは結局全ての電解コンデンサを外し,パターンを目視で追いかけ,テスターで断線を調べるという,非常に原始的な方法によってでした。

 しかし,こうして断線を見つけたのは良かったのですが,前述の通りSRAMを256kbit品に置き換えていたので,このCE2の断線はすでに関係のないものになっていたのです。念のため繋いでみても,マウントされていないSRAMのCE2など,繋いだところでなにも変化はありません。

 といいますか,本当だったら256kbitのSRAMに置き換えた時に,さくっと動いてくれないと困るわけですね。動かないでいた理由は現在確認中ですが,どうもアドレスのデコードを行う回路で,凡ミスをしたようです・・・

 しかも悪いことに,このミスで起こることは,やはりバスの衝突なのです。結果として,CE2の断線と,256kbitSRAMへの換装失敗が,同じ現象として見えたことが,どちらの問題も見過ごしてしまうと言う最悪の事態を招いたのです。

 もう1つ,ロジックICのうち,40HシリーズについてはLCDの駆動に使われ6V以上の電圧が加わるICを除き,すべて74HCシリーズの新品に置き換えました。また,CMOS4000シリーズについても,アンバッファ品を除いて全て新品に入れ替えています。(アンバッファ品は入手できなかったのです)

 というのも,先に挙げた3つのパターン切れを修復してもまだ動作せず,もう個々のICの破損しか疑えなくなってしまい,あらかじめ用意してあったICに交換したのです。ソケットを使って交換しましたので,もとの40Hシリーズに戻すことも出来ますが,今後の補修部品の入手のことや,劣化が進んでいたりして,しばらくたって破損するようなことがあったりすると面白くないので,予防的対策として入れ替えたままにしました。

 なお,ICをすべて交換した当初,状況に変化はなく動作もしなかったため,交換の前後で状態が変化したのかどうかはわかりません。もしかしたら壊れたICがあったのかも知れませんし,全然壊れていなかったのかも知れません。なにぶん,動かなかった原因は自分でくっつけた256kbitのSRAMにあったわけですから。

 ICの交換後,それでも動かないことで私の気力はほぼ限界に来ていたのですが,もしかすると256kbitのSRAMに問題があるのではないかと,このSRAMのCSをもとのSRAMのCE2にくっつけたところ,文字化けはしますが,初めて起動音と共に,なにやら画面にぐちゃぐちゃと表示が出るようになりました。

 いままで全く画面に出てこず,起動音もまともになることがなったことを考えると,画面に何かが出るという事はコンピュータとして動いていることを示すものであるわけで,少なくともCPUやROMなどのカスタム部品が壊れている可能性がぐっと低くなったことがわかります。事態は大きく動きました。俄然やる気が出てきます。

 おかしなことを自分でやるからダメなんだと,その256kbitのSRAMを外して,もとのSRANに戻してみます・・・おおー,動き出しました。

 キーボードも動きます。プリンタも動作します。電流値も正常範囲のようですし,RTCも動いています。動作そのものは問題なさそうです。

 ただ,LCDを見ていると,太い2本のスジが入っており,ここの濃度がやや薄いような感じです。LCDの偏光フィルムを交換したときに,ゼブラゴムが上手く接触しなかったのでしょうね。

 気をよくした私は,もう一度LCDを分解し,組み立て直しました。なんどか繰り返しますが,もっとくっきりとスジが入ったり,表示そのものが無茶無茶になったりと,どんどん状態が悪くなります。

 そうこうしているうちに,LCDのガラスを基板に押し当て,ゼブラゴムを密着させるためにある,鉄のフレームの裾の部分の爪が金属疲労で折れてしまいました。

 これが折れると密着できず,LCDが正しく動作しません。絶体絶命のピンチです。

 そこで私は,小型のUSBコネクタを分解し,ハウジングに使われている薄手で硬く,バネ性のある金属を鉄のフレームにハンダ付けし,なんとか固定することに成功しました。

 まだ多少の濃淡はありますが,もうこれ以上いじると取り返しが付かなくなると思うので,このくらいで妥協することにします。


 というわけで,HC-20はとりあえず,現状復帰を果たしました。基板の断線というおそろしい故障は,本当に時間を気力を奪います。今後こういうことが起こらないよう,電解コンデンサはすべてタンタルコンデンサとセラミックコンデンサに置き換えました。タンタルコンデンサには故障するとショートするという致命的な欠陥がありますが,そこは3倍以上の耐圧のものを使う事で,信頼性を確保します。

 そうそう,マスクROMをそのまま27C256にコピーして差し替えたところ,問題なく動作しました。とりあえず買ったROMライタは壊れてなかったようです。

 今はまだ基板の状態ですが,今後のプランを考えることにします。

 まず,メモリの増設です。現在16kByteですから,256kbitのSRAMの半分を使い,4000から7FFFまでの16kByteを増設したいと思います。ただ,256kbitですので,本来なら0080から7FFFまで(HC-20は,前半の0000から007FをI/Oの領域として割り当てています)のほぼ32kByteを全部まかなえるはずですから,古いSRAMはすべて取っ払いたいところです。

 ただ,今ある16kByteのSRAMは温存しつつ,256kbitのSRAMのうち半分を使って増設する方法ありますね。これだと,拡張ユニット内蔵の16kByte増設メモリとコンパチの回路にすればいいので,微妙に違う内蔵のSRAMの回路と共通化出来ない場合は,この方法を使うことになるでしょう。

 次に電源です。HC-20は4本パックのNi-Cd電池が内蔵されています。これをACアダプタで充電するのですが,あろうことかACアダプタからは3.9Ωの抵抗が直列に入ってNi-Cdを0.1C程度で充電するようになっているだけですし,Ni-Cdの出力も安定化されていません。

 ざっと,4.4V付近から5.6V付近まで電圧が変動しますが,一応ICの動作電圧範囲に入っているということで,あえて安定化しなかったのだと思います。しかしこういう設計は,今はやらないでしょうね。

 それに,ACアダプタのジャックには,専用のもの以外にも刺さってしまいます。私も迂闊にやってしまったのですが,9Vのアダプタを差し込んだりすると,Ni-Cd電池に直列に入った抵抗はたちまちアッチッチになり,基板には7Vを越える電圧がかかってしまいます。

 こういうトラブルは,本体を壊すだけではなく,火を噴いたり爆発したりと,重大な事故を引き起こすことが考えられます。少なくとも,ACアダプタからの電圧だけは,大きくなりすぎないような工夫が必要です。

 手としては,ACアダプタからの入力に7805などのシリーズレギュレータを入れることがまずあります。しかし,Ni-Cd電池も交換してから10年が経過していますし,特殊なサイズの組電池ですので,出来ればエネループにしたい所です。そこで単三のエネループに置き換えを狙っていますが,これだと元の電池置き場に収まりません。

 そこで,単三を3本だけ使い,これを5Vに昇圧することを最初に考えたのです。この方法だと,ACアダプタからエネループを充電出来ませんが,電池は外して充電するのが安心で,本体内に入れたまま8時間以上も通電することには,やはり抵抗があります。

 筐体をいちいち開けないと充電出来ないというのが玉に瑕ですが,まあ仕方がありません。

 この方法は,一見して良い方法に思ったのですが,大きな問題に気が付きました。5Vへの昇圧回路ですが,HT7750Aを使ったものだと,200mAが精一杯なのです。通常の動作では全く問題になりませんが,プリンタが動作するときはさすがに問題です。

 HC-20に内蔵されているM-160と思われるプリンタは,モータが3.8Vから5.0Vで,電流は200mA必要です。またヘッドは3.9Vから4.5Vで,コイルの抵抗が1.5Ωだそうですから,3Aくらいの電流が流れます。これが4ピンありますから,ピークでは12A!

 まさかこれだけの電流が流れ続けるわけではありませんが,さすがに昇圧回路を通さず,電池から直接取るしかありません。

 でも,単三が3本だと3.3Vから4.2Vとやや低いのです。やはり4本にしないといけないのでしょうが,これだと置き場所の問題もありますし,電圧の変動が面倒です。

 電池が4本収まれば,昇圧回路を併用して5.0Vから5.3V(ショットキーダイオードが入りますので0.3Vほど小さくなります)とするのも手ですが,そうすると電池電圧の検出回路を改造して,電池端からひっぱって来ることになります。
 
 どんな方法が一番良いのか,もう少し考えてみようと思いますが,うーん,結局おかしなことをしないで,エネループを4本仕込むことを考えた方がいいのかも知れませんね。

HC-20の修理その2.5

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

ファイル 426-1.jpg

 上はデータバスの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がなにをアクセスし,それを相手に読むのか書くのか,それが分かると,案外原因をさっと特定できるかも知れません。

ページ移動

ユーティリティ

2020年05月

- - - - - 1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31 - - - - - -

検索

エントリー検索フォーム
キーワード

ユーザー

新着画像

新着エントリー

過去ログ

Feed