エントリー

カテゴリー「make:」の検索結果は以下のとおりです。

KT-1100Dを久々に調整する

 うちのFMチューナー,ケンウッドのKT-1100Dは,以前入手した時にセパレーションが機内温度と共に変動してしまい,故障なのか仕様なのかを判断するためにもう一台入手し,結局現在2台所有することになってしまっています。

 結局この時は2台目もセパレーションが同じように変動することがわかり,仕様として割り切ったという結論になったのですが,問題は2台目が故障していたことです。

 完動品という触れ込みで入手しましたが,検波コイルに内蔵された温度補償用のコンデンサが壊れるという持病でチューニングがズレるという問題を抱えていました。

 結局同等品のコンデンサに交換することで完調となった2台目のKT-1100Dですが,出番はなくずっと押し入れで眠っていたのです。

 しかし,ふとしたことから友人に使ってもらうことになり,動作確認と再調整のために6年ぶりに引っ張り出したというわけです。

 SSGや歪率計も数年ぶりに電源を入れますので心配でしたが,これらは今でも問題なく動いてくれました。ケーブル類が断線してたりして手間取りましたし,調整の手順も忘れており,時間がかかってしまいました。しかしかなりいい仕上がりになったと思います。

 忘れないように調整手順を書いておこうと思います。すでにFMチューナーの修理と調整には有名なサイトが存在し,私もそこで勉強させて頂きましたが,複数あるサイトで数値や順番が一致していなかったり,頼りになるはずのサービスマニュアルが案外使い物にならなかったりということもあり,自分用に調整手順を作らざるを得ませんでした。


(0)準備を念入りにする。KT-1100DはFMモード,IF BANDはWIDE,RF SELECTORはDISTANCE,TUNINGモードはAUTO,REC CALはOFF,PROGRAMはOFF,そしてQUIETING CONTROLはNORMALとして右端に。

(1)まずバリキャップ電圧の調整。アンテナを外し,TP6とTP7に電圧計を繋ぐ。76MHzで3.0V±0.1Vになるようにメイン基板上のL14を調整。

(2)次に90MHzで25V±0.1Vになるようにメイン基板上のTC1を調整し,(1)と(2)を何度か繰り返して追い込む。

(3)次は検波の調整。83MHz,80dB,無変調を受信し,TO10とTP11に電圧計を繋ぐ。0V±10mVになるようにDET基板上のL9を調整。L9内蔵のコンデンサが壊れているとここで詰む。

(4)続いてPLL検波の調整。(3)のまま電圧計をTP12とTP13につなぎ替え,0V±10mVになるようにDET基板上のL12を調整。

(5)次にRFの調整。83MHz,40dB,変調を受信し,DET基板にあるCN3の4ピンとGNDの間の電圧が最大になるよう,L1,L4,L7,L18を調整。

(6)このままIFTの調整へ。(5)からSGのレベルを30dBに下げ電圧が最大になるよう,L10を調整。

(7)ここで神経を使うRFの調整は終わり。続けてオートストップレベルの調整。これは放送局の電波を受信したかどうかを判別するレベルを調整するもので,これを下回るレベルはサーチで引っかからない。83MHz,30dB,変調を受信しメーター基板上のVR1を調整。

(8)チューニングメーターの調整。83MHz,80dB,変調を受信し,バーグラフが中央で白く点灯するようにメーター基板上のVR2を調整。

(9)ここからはいよいよステレオへ。まずはMPXのVCOを調整。83MHz,80dB,無変調を受信し,TP14に周波数カウンタを繋ぎ,19.00kHz±50Hzになるようにメイン基板上のVR4を調整。

(10)次にサブキャリアの調整。83MHz,80dB,SUBを受信し,Lチャンネルの音声出力が最大になるようにメイン基板上のL25を調整。

(11)そしてKT-1100Dのキモの1つ,歪みの調整。83MHz,80dB,モノラルを受信し,音声出力の歪みが最小になるようにDCC基板上のVR3を調整。

(12)(11)のままDCC基板上のVR4を調整し,さらに歪みを最小にする。ここで2次歪みが最小になる。

(13)(12)のままDCC基板上のVR6を調整,さらにさらに歪みを最小にする。ここで3次歪みが最小になる。

(14)次はステレオの歪み。83MHz,80dB,LEFTを受信し,音声出力の歪みが最小になるようにDCC基板上のVR5を調整する。

(15)83MHz,80dB,SUBを受信し,音声出力の歪みが最小になるようにDCC基板上のVR7を調整する。

(16)IF BANDをNARROWに切り替えて,80MHz,80dB,LEFTを受信し,音声出力の歪みが最小になるようにDCC基板上のVR2を調整する。出来れば(9)までを何回か繰り返す。

(17)ここからはセパレーションの調整。IF BANDをWIDEに戻して83MHz,80dB,RIGHTを受信し,Lチャンネルの出力が最小になるようにメイン基板上のVR2を調整。

(18)83MHz,80dB,LEFTを受信し,Lチャンネルの出力が最小になるようにメイン基板上のVR3を調整。

(19)IF BANDをNARROWに切り替えて83MHz,80dB,LEFTを受信し,Lチャンネルの出力が最小になるようにメイン基板上のVR1を調整。

(20)次はSメーターの調整。83MHz,80dB,変調を受信しバーグラフの最も上のセグメントが点灯するようにメーター基板上のVR3を調整。

(21)変調度のメーターを調整。REC CALをONにし,MODULATIONのメーターが4つ点灯するようにメーター基板上のVR4を調整。ついでに75%変調で7つ点灯するかどうかも見ておく。


 ここまででFMは完了です。続けてAMです。

(0)準備として,ループアンテナを取り付け,モードはAM,IF BANDはNARROW,TUNING MODEはAUTO,REC CALはOFFにする。

(1)バリキャップ電圧の調整。TP6とTP7に電圧計を繋ぐ。522kHzで1.5V±0.1Vになるようにメイン基板上のL20を調整。

(2)次に1629kHzで8.0V±0.1Vになるようにメイン基板上のTC2を調整し,(1)と(2)を何度か繰り返して追い込む。

(3)続けてRFの調整。630kHz,30dB,変調を受信し,シグナルメーターが最大になるように,メイン基板上のL21を調整。

(4)今度は1440kHz,30dB,変調を受信し,シグナルメーターが最大になるように,メイン基板上のTC3を調整。

(5)いよいよ最後,IFTの調整。999kHz,30dB,変調を受信し,シグナルメーターが最大になるように,メイン基板上のL22を調整。


 これで全部終了。調整を追い込めなくて故障が見つかったり,設定を変更するのをうっかり忘れたりすると,あっという間に1時間や2時間の時間がかかってしまいます。しかし,これでKT-1100Dは甦ります。

 友人のKT-1100Dは,最終的に歪率が0.02%以下,セパレーションは54dBになりました。チャンピオンではないでしょうが,一応スペックは満足する数値です。

 自分用のKT-1100Dもせっかくなので調整を行いましたが,6年くらいでは調整はそれほどズレておらず,相変わらず調子の良い状態であることがはっきりしてよかったと思います。

 悩んだのはシグナルメーターとオートストップレベルの調整です。サービスマニュアルにある数値をそのまま使うと,どうも調整しきれなかったりするので,いろいろ調べてこの数値で調整することにしました。

 というわけで,調整手順をマニュアル化できました。これで気軽に調整ができるというものです。あとどれくらい使えるか分かりませんが,3年に一度くらいは調整できればと思います。

ATTiny10とATTiny13の違い

  • 2022/12/09 10:27
  • カテゴリー:make:

 電子工作を共に楽しむある友人と久々に話をしたのですが,彼はすでにKiCadを使ってパターンを作り,中国の基板メーカーに発注するという,まさに電子工作の王道を驀進していました。

 翻って私はというと,未だに万能基板とポリウレタン線でコツコツと作っています。この半年は特に規模の大きな回路の配線をやったのですが,私はこの作業が楽しく(おそらく写経というのはこういうものだろう),苦にならないので基板メーカーに作ってもらうようなことはあまり考えていませんでした。

 しかし,彼の作品を見ていると刺激を受けます。私もCADを使って基板を発注してみようと思いました。

 手配線では,小型の部品の配線にどうしても限界があります。0.4mmピッチのQFPでさえも手ハンダでは無理でしょう。QFNなんかは最初からやろうとも思いません。

 アマチュアの電子部品がプロのおこぼれであるという状況が変わらない限り,基板無しで工作が可能な時間はそんなに長くはないでしょう。すでに多くのアマチュアが高度な基板を作っていることを考えると,私もやっておかないとまずいと思います。

 しかし,私の工作はまさに自分のためだけに行っているものです。それも目的があって,そのために工作がベストと判断されたときに行うもので,工作そのものが目的ではありません。

 目的がないのに基板を作る今回の話に私は頭を抱えました。なにか目的をでっち上げないといけないのですが,ふと思いついたのは随分前に夢中になったSi5351Aとtiny13の組み合わせで任意の周波数を作る回路です。これをモジュールにしてしまうような基板なら面白そうです。フットプリントは14ピンのDIPでいきましょう。

 好きな周波数が選べないTCXOの精度で,欲しい周波数が手に入るという長年の夢が,Si5351で実現することに興奮して検討していたのが6年前,I2Cで100ほどのパラメータを設定するのは手作業では無理でどうしてもマイコンが必要ですが,一度設定すれば変更しないものでもあり,高価で規模の大きなマイコンは使いたくありません。

 I2Cが搭載されるようなマイコンはそれなりの価格ですので,私は当時50円だったATTony13にソフトウェアでI2Cを実装して,Si5351Aの設定をさせようとしました。

 ところがAVRはハーバードアーキテクチャで,100ほどのパラメータを定数として配列に取ると,RAMにも確保されてしまいATTiny13のRAMではあふれてしまいます。結果正しい設定値が書き込まれず動作しなかったのです。

 そこで定数を配列に取るとき,プログラム用のフラッシュもしくは内蔵EEPROMから値を参照する仕組みがライブラリに用意されていて,これを使って完成したのでした。

 今回の基板作成で小型のモジュールを作るとなれば,ATtiny13では大きすぎます。なら米粒AVRことATTiny10を使いましょう。

 ATtiny10は秋月で45円時代に10個ほど買ってありましたが,書き込みがTPIであることもあり,買ってすぐには手を出しませんでした。PICKIT4を手に入れてからもGPIOの少なさから使うきっかけがなく,放置していました。

 しかしI2Cならたった2本。まさに米粒AVRに相応しい仕事です。

 早速MicrochipStudioを立ち上げ,ATTiny13のコードをコピペしてビルドします。ATTiny13にはEEPROMがありますが,ATTiny10にはありません。そこでプログラム用のフラッシュに設定値を持たせる事にしました。

 エラーがボロボロ出たので修正してビルドが通るようにしてから書き込んで実行しますが,やっぱり上手くいかず,Si5351はなにも出力していません。

 SI5351が壊れているかもとATTiny13で試すと綺麗に周波数が出てくれたので原因はATTiny10にあることがはっきりしました。I2Cのコードが問題なのかもと,I2CのLCDを繋いで見たところ,これは一発で正しい表示が行われました。

 本来の目的とはズレていますが,米粒AVRでLCDが動いているのはちょっと感激です。

 SI5351は正常,ソフトI2Cも問題ないという事なら,あとはもう設定値が正しく用意されていないということになりそうです。

 怪しいのは,やはり設定値を書き込んである定数の配列です。配列の宣言でPROGMEMを宣言し,参照はpgm_read_byteという関数で行っていますが,ここがどうも怪しいです。

 google先生に尋ねてみると,まずATtiny10はこれまでのAVRとは少々毛色が異なるものであることがわかってきました。まず大きいのはハーバードアーキテクチャではなくなったこと。コードとデータが別のメモリに置かれるというのはAVRの特徴だったのですが,小さい事を目指したATTiny10では採用されなかったみたいです。

 AVRの個性としてもう1つあったヒューズですが,これも少し格落ちしていました。これまでのAVRではクロックの設定がヒューズで行えたのですが,ATTiny10ではレジスタを叩くことになっています。しかもそのレジスタは保護対象になっていて,ロックを外すレジスタを先に叩いて,4クロック以内に設定を終えないといけないという面倒臭さです。

 ヒューズはリセット解除後すぐに設定が反映されることがメリットだったのですが,ATtiny10が持つヒューズはクロック出力のON/OFFとWDTの設定,そしてリセット端子をGPIOにする設定の3つになっていました。

 また,GPIOのプルアップは専用のレジスタが用意されました。これまでのAVRでは入出力方向の設定レジスタがプルアップも兼用していたのですが,専用レジスタを使わないとプルアップされません。

 そうそう,レジスタが16本に減りました。これもAVRらしさが減ったと感じさせますね。(それでも16本もあるわけですが)


 話を戻すと,ハーバードアーキテクチャをやめたことで,PROGMEM宣言の扱いが変わってしまうというのは事実のようでした。しかしその結果,コンパイラが未対応なのでPROGMEMは使用出来ないとか,逆にこれまで通りpgm_read_byteで参照できるとか,そうした記述のコードが実際に動いたとか,国内外でいろいろなコメントが見つかりました。

 半ばあきらめ書けていたときに見つけたあるコメントに興味を惹かれたのですが,これはPROGMEMでフラッシュに配列で定数を置いた場合,参照はpgm_read_byteではなく,普通にその配列を参照するだけでOKだというものでした。

 なるほど,ハーバードアーキテクチャのAVRなら,データを置けないエリアであるプログラム用フラッシュにデータを置いてその値をポインタで参照することは出来ず,一度1バイト分だけRAMにコピーしてこれを参照するような関数を用意する必要がありますが,ハーバードアーキテクチャをやめたATTiny10なら,ポインタでフラッシュメモリも参照できそうです。

 試しにpgm_byte_readをただの配列の参照にしたところ,あっけなく動いてしまいました。念のためATTiny13でも試しましたが,こちらは動作しなくなりました。やはりアーキテクチャの違いが原因だったようです。

 まとめます。

 まずお約束のprgspace.hをインクルードします。

#include <avr/pgmspace.h>

 定数の定義はこれまで通りです。

const PROGMEM unsigned char hoge[14] = {
     86, 85, 84, 83, 82, 80, 81,  1,  0,  6,  5,  4,  3,  2};

 しかし,参照するときはこれまでとは違います。これまでは,

data = pgm_read_byte(&hoge[i]);

 としてアドレスを専用の関数に渡していましたが,ATTiny10では,

data = hoge[i];

 でOKです。なんとシンプルな。

 海外では,AVRのこうした変更を好ましいと考える人もいるようで,うちの嫁さんも「これが自然。元のAVRがおかしい」とまで言い切っていました。AVRが好きな私としては,ちょっと残念ですが。

 ATTiny10はRAMが32バイトと強烈に少ないですし,レジスタも半減しているので,設定値を1KBのフラッシュメモリから直接参照できるかどうかは,まさに死活問題です。今回,ATTiny10でこの問題を解決出来たことは,ATTiny10の応用範囲を拡大出来ると思います。

 

妥協しないハンディオシロを買う

 先日の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は,テキストモードではカラー表示を行いません。ですが初期の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桁カードとの切り替えもワンタッチです。

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

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

 どうするかなあ。

X1turboIIIにバンクメモリを

20221122141814.JPG 

 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のコピーが便利になると思うのですが,そういう機能もありません。

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

ユーティリティ

2026年01月

- - - - 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