ちょっとTea Time!? VGAを調べてみる？？？ 2020.10.14
もともとはTFT-LCDのモニター化の失敗から
８００×４８０のLCDを購入したきっかけは、CPM６８K次男を独立したマイコンに仕上げるべく、
LCDをモニター代わりにできないかと考えたことです。いままでは、RS232でPCにつないで、PC(WINDOWS)を
端末として使っていましたが、そうなるといつまでたっても独立でつかうことができません。
＃独立にしたところで、何かにつかうあてもないのですが、「独立にしたい」という単なる欲望だけです・・・・
さて、モニターにするにはキャラクターで８０×２５文字は表示できるようにする必要があります。
４８０×３２０のLCDでも５×７のキャラクターフォントを使えば８０×２５文字は表示できますが、
小さくてとても見るに耐えられるものではありません。
そこで、８００×４８０にすれば・・・と思いました。あまり考えずに買ったこともあるのですが、
液晶サイズがほとんど変わらなかった（3.5→4インチ）ので、結局ボツに。画素が増えても、画面サイズが変わらなければ
文字の視認性なんて変わるわけありません。考えればわかることですが・・・・
で、買うなら７インチのものを買うべきだったかもしれません。でも、７インチになったところで、あまり
事態は変わらないかもです。それに、７インチのものって、結構高かったりします。
これにしておけばよかったかも。でも、結構高いんですよね〜。
なればVIDEO−RAMでも作るか？
結局、800ｘ480のLCDをモニターにつかうことは一旦保留にしました。さて、次善策はどうするか・・・・。
で、思いつたのが、VGA入力ができるPC用のLCDのモニターも余っているものがあるので、
それが使えないかということ。すなわち、VIDEO-RAMをCPMに搭載できるかな〜？と思ったのが
今回のTea Timeの始まり。
VIDEO-RAMといっても、PC用のグラフィックカードみたいなものではなく、単にSRAMの内容を
モニターに表示するだけの簡単なものです。使用する部品も汎用品ばかりでできるはずです。中心となる
SRAMについては、秋月で12nsの1MBitのSRAMが１00円で買えます。数個で足りるでしょう。
また駆動ロジックについても、何個かは購入が必要ですがまあなんとかなるでしょう。
これを使えばVIDEO-RAMも安く作れそう。12nsで1MBitです。１個１００円です。
問題は手元にLCDモニターに表示できるか？
作るとしても、それほど解像度は必要ありません。簡単に1024×768程度でいいでしょう。
これなら１画素/８ビット構成にシンプルにして、1MBitのSRAMが６個で足ります（768kByte）。
1024×768だとピクセルクロックは65MHzになりますが、サイクルタイムは15nsなので12nsの
SRAMなら間に合うでしょう。
ただ、気になるのが手元の液晶は1920×1080用なので、ちゃんと1024×768が表示できるかが
心配です。スペック上はできるのですが・・・画像がぼけたりしないかと・・・。一応、WIN-PCで画素数
変更した場合に1024x768でも綺麗に表示できますが、ひょっとしてI2CとかでPCとモニター間で色々な情報のやり取り
をして調整しあっているかもしれません。自作の回路だと大丈夫かなあ〜。
まずはVGA信号を見てみましょう・・・あれ？同期信号は正極なの？
まずはVGA信号がどうなっているかを調べます。基本的にはNTSCの同期信号を分離したものだと認識しているので
構造は簡単なはずです。解説が、いくつかのホームページがみつかります。
実際にどんな波形になっているか、自分のPCのVGA出力をオシロで確認してみました。
あれあれ、なにやら水平同期も垂直同期も正パルスになっています。
どのWEBをみても、大体同期信号は負パルスになっているのだけど・・・・なんで？
いきなりわからないことに突入です。
ひょっとして、最近のモニターはパルスの極性は問わないのだろうか？まさかね〜。
でも、これで動いているのだからいいのだろうな〜（かなり疑問が残ります。
VGA信号です。同期信号は負パルスです。 引用：https://diarywind.com/blog/e/g13_124_vgargb.html
あれあれ？水平同期信号が正パルスになっています。負パルスじゃないの？
垂直同期も正パルスです。これでいいのかな〜？
模擬的な信号をつくってみる！
同期信号が正パルスでいいのかどうかも含めて、一度VGAの模擬信号を作ってみて手持ちのLCDに突っ込んでみることにしました。
ちょうど、1024×768時のVGAのタイミングが書いてあるWEBがありました。ちなみに、色々な解像度のVGAのタイミングは
ここにあるようです。 → http://tinyvga.com/vga-timing
VGAの模擬信号はPICで作ります。64MHzで動作するPICですが、さすがにVGAの信号を完全に
トレースするには遅いので、すこし近似的な値になってしまいます。プログラムはひたすらI/Oを叩く内容です。
OUTPUT命令が連続して数１００個も並ぶ汚いプログラムです（笑。
1024×768の場合のVGAのタイミング。やっぱり同期信号は負論理とあるなあ〜。 引用：
http://diode.matrix.jp/VGA/index.htm
PICをつかって1024×768のVGAの模擬信号を作ります。
動くけど・・・
PICで擬似のVGA信号を作ってモニターに入力です。PICの電源を入れると、モニターがしばらく考えて、
２，３秒後に表示がでます。おそらく、入力信号を解析しているのでしょう。
擬似信号は簡単に全画面同じ色で塗りつぶしたものです。パターンを書くのも面倒くさいです。
ちょっとだけ弄って、簡単に筋も入れてみました。まあ、ここまでは動いていそうです。
赤一色で塗ってみました。
次は緑一色。
ちょっと変化をつけようと、筋を入れてみました。
縦じまがゆれる・・・・
つぎにプログラムをすこしいじって、縦じまがでるようにしてみました。
縦じまは出るのですが、問題はそのクオリティです。縞の境界部がかなりノイジーです。
ゆらゆら見えます。
こんなんでキャラクタ表示しても、長い間みていたら酔いそうです。
モニター側で調整できないか、色々と調べましたが、ほとんど自動モードで動くようです。
モニターを弄っていると、表示画素がでてきましたが、どうやら「1360×768画素」と認識
しているようです。これが問題なのかな？
そもそも、VGA信号の水平信号ってアナログなのに、どうやって画素数を換算しているのだろう？
やりかたはわかりませんが、擬似信号なのでもうちょっと、追い込み調整がいるのかもしれません。
1024画素のつもりで出しているのに、モニター側が1360画素と認識してしまっているので、
隣り合う液晶DOTのどちらに発色を割り振ればいいのかが不安定になっているのかもしれません。
縦じまも出ましたが、近くでみるとかなり縞がゆれています。
境界部分がガタガタです。なぜだろう？
モニターは1360×768画素の信号と認識しています。これが原因かな？
対策は・・・・
この揺らぎはなんとかしなくてはなりません。もともとのモニターが「１９２０×１０８０」の
ものなので、１０２４という中途半端な値じゃなくて、例えば半分の「９６０×５４０」とか
1/3の「６４０×３６０」にすればいいのだろうか？ しかし、そんな画素で動くのだろうか？
それよりも、そんな画素にしたらSRAMのアクセスがややこしいです。「１０２４画素」なら
ちょうど２の倍数ですが、640なんて・・・・・。
どちらにしても、綺麗に表示できることがわからないとVIDEO−RAMを作ろうという気が
おきません。まだまだ調べることはありそうです。
でも、今回の調べごとで水平同期、垂直同期が正論理だったのは意外でした。
私のPCだけ特異なの？まさかね〜。
色々と試してみる！ 2020.10.15
縞がギザギザになる理由の１つにPICの信号の鈍りがあるのではないかと考えて
出力にバッファーを入れてみました。
でも、あまり効果はなしです。すなわち、PICでも十分にドライブできているということでしょう。
PICの出力にバッファーを入れてみました・・・・、あまり効果はなかったです。
信号の縦じまをよく観察すると、ギザギザがあるところもあれば、ないところもあります。
やはり、ピクセルクロックが規定値でないので、ノイズがでている気がしてきました。
一度、規定値にあわせたクロックで信号をつくって確認しないとだめだろうな〜。
信号の縦じまをよく観察すると、ギザギザがあるところもあれば、ないところもあります。
クロック周波数が重要！
規定値のピクセルクロックが65MHzですが、現在のPICは16MHzの４倍PLLの64MHZで動いています。
この64MHzと65MHzの違いが問題と推測されます。そこで、PICを65MHzで動かすべく、外部から16.25MHzの
クロックを入れて、４倍PLLで65MHzで動作させてみることにしました。
クロックはSi514をつかったもので、外部から周波数をプログラムできる優れものです。結構重宝してつかっています。
その結果ですが、推測どおりピタっと画面が固定しました。ノイズ(ギザギザ）の発生がなくなりました。
これで、1024×768のVIDEO-RAMを作るモチベーションが高まってきました。
16.25MHｚのクロックを入力して４倍PLLでピクセルクロックの規定値である65MHｚで動作させます。
画面表示が綺麗になりました。
細かくみてもノイズはでていないようです。
まだまだ検討する課題は多い・・・・
１．スクロール速度の確保
1024×768画素として、キャラクターフォントを８×１６とすれば、１２８文字×48行というかなりの
文字が表示できます。ただ、グラフィック画面でスクロールをやろうとすると時間が気になります。
というのも、１行をスクロールするためには、まるまる１画面分の表示を１行分ずらすことから始まります。
VRAMの容量は約７５０ｋBですが、MC68000を16MHzで動かした場合のメモリー間の転送速度は約2MB/s。
すなわち大雑把に750k/２MB=3行分/秒 程度のスクロールしかできません。これも最大速度です。
まるで、昔のロール紙のプリンターでの印字速度みたいな形でしか、モニターに表示できないことになります。
これの対策としては、VRAMのアクセスアドレスに任意のオフセットを与えて、描画を開始するアドレスを
変更すればいいでしょう。オフセットを与えるアドレスも全アドレスは不要で、上位６ビットでよいので、
４ビットのフルアダーロジック(FULL ADDER LOGIC)を２段接続すればいいはずです。アダーの遅延速度が
数10nsでてくる可能性がありますが、上位アドレスの切替時間は水平同期の戻り時間の中に埋もれますから、
気にする必要はありません。
最大の問題は、グラフィックとの共存が難しいということです。上位アドレスにオフセットをつけてしまうと、
グラフィック画面の座標系がずれてしまいますから、まともに直線が引けなくなってしまいます。まあ、これに
ついては、グラフィックをするときにはキャラクタ表示は一旦クリアすることになるでしょう。
それにしてもフルアダーをつけるとすれば、それはそれで面倒です。でも、なければ使い物になりません。
もう、いっそのことキャラクター専門にするかです。そうすれば、VRAMの容量も８０×２５文字の２ｋB程度で
済みますから、ソフトウエアーでのスクロールも十分に高速にできます。ただ、キャラクターのドットに描画情報
を展開するためにはテーブルROMが必要だし、その駆動ロジックも結構面倒なことになります。やはり素直に
グラフィックVRAMとして、オフセット用のアダーをつけるのがいいでしょう。
２．水平同期信号をシンプルに
たとえば、水平同期信号をつくるためにはピクセルクロックを正確にカウントする必要があります。
厳密な信号つくることはできますが、ロジックICの数も増えてしまいます。
たとえば1024×768の水平同期のタイミングですが、下記のように
（厳密） FP=24,SP=136,BP=160 （合計３２０）
とバラバラです。一応すべて４の倍数なので、２ビットのプリスケーラをつけて、６ビットカウンタと比較器3個があれば
あればいいのですが、ちょっと面倒。そこで、このタイミングを近似します。例えば、
（近似） FP=32,SP=128、BP=160 (合計320)
というようにの３２の倍数にできれば、最初に５ビットのプリスケーラをつけておけば４ビットのカウンタと比較器で済みます。
このあたりは、もうすこしVGAの擬似信号をいじって、どこまで対応できそうかを見極める必要があります。
１０２４×７６８の水平同期信号を厳密につくるのは面倒かも。
３．CPUのアクセスを止めるには？
VIDEO-RAMはCPUとグラフィック制御側の両面からのアクセスがあります。勿論CPU側が優先ですが、
グラフィック側からのアクセス時にCPUがアクセスすると画面が乱れます。そのため、メモリーアクセスいは排他制御が必要です。
一番スマートなのは、RAMにDUAL PORTのものを持ちいればいいのですが、なんといっても高いです。1MBitのものでも１万円近くします。
それが６個は必要なので、迷わず却下です。
もっとも簡単なのは、CPU側からアクセスするときはVGAの同期信号がでている間（表示されていない期間）にアクセスを限定することです。
ちなみに、VIDEO画面でのRAMのアクセスの割合は1024x768の場合だと、全画面では1344*806ですから（1024x768）/（1344*806）となり
約73%です。したがって、連続してCPUがVIDEO−RAMにアクセスしようとしても25%程度のスループットしかでません。まあ、これは許容するとして、
どうやってアクセスを禁止にしたら効率的かな？
基本はCPUからVIDEO-RAMにアクセスしたときに描画中だったら、ｸﾞﾗﾌｨｯｸ制御回路からCPUにHALT信号をかけることだと思うのだけど、
CPUはHALT信号を受け取っても、現在のサイクルを終了しないとCPUを停止しません。ということは、VIDE-RAMへの書き込みにかかりはじめれば、
それを止めることはできません。ということは、描画は始めるすこし前にはHALTをかける工夫が必要になってしまいます。それとも、無理やりCPUの
クロックを止めてやるかな？でも、クロックを止めるのは結構荒業のような気がします。
やはり描画をはじめるすこし前にHALT信号を生成する回路をいれないとだめだろうな〜。具体的にはCPUがVIDEO-RAMのアドレスをアクセスと
グラフィック回路でのアクセス停止信号とのANDをとって、HALTをかけることになるでしょう。
ああ・・・だんだんグラフィック制御回路が複雑になってしまいます。
４．BIOSの書き換えは大丈夫？
VIDEO−RAMをアプリケーションからアクセスするだけだったらC言語だけでも組めますが、DOS側の表示をやろうとしているので、
現状のBIOSに描画機能をもたせる必要があります。現状のBIOSは必要最小限の機能しかないので、簡単なアセンブラで済んでいますが、
VIDEO−RAMをあつかうとなれば、結構分量も増えてきそうです。それをアセンブラだけで書く気になるかな〜。
C言語でもBIOSをかけるようになっているのだけど、どうやってシステムに組み入れるかなお方法がまだ良くわかってはいません。
このあたりは、まだまだ調べないといけないところです。
とりあえず、基本仕様を考える！ 2020.10.17
まずは実現できる（する？）かできないかは、おいておいて基本的な仕様を考えてみましょう。
１．解像度とカラー
解像度 640×480画素
当面は８ビットカラー（R:3bit、G:2bit、B:3bit）で最大16ビットカラー（（R:6bit、G:5bit、B6bit）
できれば1024x768を実現したいが、ピクセルクロックが65MHzになるので、RAMのアクセスタイムがかなり心配。
640x480だとピクセルクロックが25MHzまで低くなるので余裕ができます。
高速スクロールを考えて、すこし勿体無いですがRAMは連続でつかわず、1024バイト境界で区切ることにしましょう。
そうすれば1024ﾜｰﾄﾞ毎でのオフセットがかけられます。
RAMの使用領域はすこし勿体無いですが、こんな配置です。
2.同期信号はPICでつくる
ロジックICで組むとやはりICの数が増えるのと、何かを変更しようとすれば必然と配線のやり直しが発生してしまいます。
ロジックICによるハードロジックではなくて、できるだけソフトロジックに任せましょう。ただし、オフセット値を取得して、加算して
出力するなどの処理も増えますから、本当に間に合うかどうかについては事前に検証しておいたほうが良さそうです。
３．VIDEO-RAMの排他制御もいれる。
最初はなくてもいいかな〜と思いましたが、まずはHALTで止めるようにしてみましょう。
具体的にしていきましょう！
まずは全体をイメージするためにブロック図を描いてみました。
必要になる素子は
PIC １個
RAM 1MBitのものが４個あるいは８個（親亀小亀方式にするので、ICの個数としては２個分）。
ロジックIC バッファー、セレクターで１4個、制御関係で6個程度かな？ 合計２０個ほど。
このくらいなら、１枚の基板に乗るでしょう。
大まかなブロック図です。
ざっと回路図を描いて、どのくらのロジックICが必要か見積もってみましたが、１９個必要というになりました。ほぼ予想通りです。
手元にあるICだけで作ることを念頭においていますが、あと不足しているのはSRAM（１MB、12ns)です。これについては
週明けにでも秋月に注文しましょう。
コントロールロジックを検討中です。
色々間違えているな〜 2020.10.19
回路図を眺めていて、スクロールのためのオフセット値の入力が完全に抜けていることに気づきました。
オフセットを計算するのはPICですが、PICの入力端子はほとんど詰まっています。かといって40PinのPICにするには
基板の面積も必要だしな〜。 結局、I/Oポートを時分割で入力と出力で切り替えることにしました。
すこし、処理時間がかかりますが水平同期のパルスを出している間で計算できるでしょう。なんせ、PICを100MHz以上で
オーバークロックで動作させますから（本来は64MHzが最高値です）。
オフセット値の入力部分を追加しました。
さてさて、回路図もできたことだから不足している部品を秋月に注文しましょう・・・。
Dsub 15Pinがない！
足りない部品はSRAM程度なのですが、つい色々とついでに買ってしまいます。大体、１しか必要ないのに予備とか考えて２買うから、
部品箱が破裂するのですよね〜。そして、本来必要なものを買い忘れたりしてして、再度注文するときに、また余分を買ったりと・・・・
これぞ負のスパイラル・・・・・。
で、忘れちゃいけないのがVGAコネクタのDsubの３列の15Pinコネクタですが、秋月にありません。
最初に何も考えずに15Pinのコネクタを買い物かごにいれたら、説明書きがあって違うことに気づいて、
それから３列のものを探しましたが、どうやらないようです。
あれ〜、以前はあったような気がしたのだけどな〜？？？？。
間違って買いかけてしまいました。説明書きがあることをみると、間違える人が結構いるのかもです。
こんなのありました
秋月の中を探しまわりましたが、やはりないようです。こりゃ、手元にある１個を大切に使わないとだめだなあ〜。
でも、探している途中で「VGA」というキーワードで こんなものが見つかりました。
VGA出力用のR-2RのDACです。
RGB用で各色４ビットでのR-2R DACがついています。同じようなものを作ろうと思っていたのですが、これを使うのがいいかもです。
でも、各色４ビットで12ビットというのはちょっと中途半端。最終的には16Bit出力にしようと思っているので、ちょっと足りません。
でも、回路図もあるのでそれは参考にさせていただきましょう。
DAC部分の回路はこうなっていました。
ちなみに、動作ロジックは3.3Vなのだけど、この回路だとどのくらいの電圧がでるのだろう？
ということで、簡単にSPICEをかけてみました。このくらいの回路なら手計算できるだろ！とい
ツッコミがはいりそうですが・・・・。
で、計算結果は最大出力は0.675Vになります。VGAのRGBの電圧最大値の０．７Vに合致しますすね。
ということで、この定数を参考にしましょう。
しかしE２４系列で２７０Ωはありますが、５３６Ω(本来は５４０Ωがよい）なんてありません。
作るときは、２７０Ωを２本直列にするのだろうな〜。１６ビットの構成になるので抵抗が全部で
４８本も必要になります。まあ、このあたりは精度は特段必要にならないので5%の炭素皮膜でいいでしょう。
念のため６ビット構成にしてみましたが、この場合はすこし電圧が上がって0.706Vになりました。
負荷抵抗（７５Ω）が低いので、多少の変化はあるようです。
フル出力で0.675Vの電圧がでるようです。VGA規格のMAX値0.7Vですね。
6ビット構成にしたら、最大電圧は0.706Vになりました。
実装できるかな？
そういればR-2Rの抵抗の実装面積をあまり考えていませんでした。
すくなくとも、抵抗は横にはできないだろうな〜？ ﾁｯﾌﾟ抵抗をつかったほうがいいのかな？
手元に510Ωの抵抗があるので、それをつかえば出力電圧はどうなるのだろうかちょっと計算です。
計算結果は0.738Vとなり、0.7Vをかなりオーバしてしまいます。
ということで、出力に27Ω程度の抵抗を挟んだほうがいいでしょう。
抵抗値を510Ωと２５５Ω（510Ωパラ）にしたら、出力電圧は0.738Vです。
出力に27Ωの抵抗を挟めば出力電圧は0.68Vになります。これでいきましょう。
さて、現時点の回路図で必要なデバイスは下記の通りです。
32Pin DIP ２個
28Pin DIP 1個
20Pin DIP ５個
16Pin DIP １１個
14Pin DIP ４個
抵抗 約48個
ICだけで実装面積は２３個分です。ほんとうに乗るかな？
ためしにICソケットを並べてみましょう。
結構厳しいかも・・・・
裏面での配線を考えると、ICとICの横の間隔は穴２個は離したいので、それを考えたらほぼキチキチになりそう。
修正のために２〜３個のロジックの追加はありうるので、もう少し配置は考えた方が良さそうです。
それに、ICの配置次第によっては配線の複雑さが大きくかわります。大体いつも適当に配置してしまって、
やたらめったら配線を引き伸ばさなくてはならなくなるのがオチですから。配線しながら「これは、
ここに配置しておくべきだった〜」という後悔しきりです。
大きめの基板に実装しますが、結構キチキチになりそうな予感です。
本格的に作っていきましょう。まずは準備から！ 2020.10.20
まずは、部品配置を再検討です。回路図をみながら考えていきますが、なかなか煮詰まりません。
まあ、このあたりは思い切りが必要です。ということで、最後はエイヤで決めました。
SRAMだけが横向いてしまいましたがご愛嬌です。
部品配置を再検討です。
準備その１：ICピンを短く
今回はICソケットをつかうことにしました。本来はIC直付けにしようと思っていましたが、
色々と動作確認のためのテストをするだろうし、電源の逆接なんかやってICを飛ばす可能性も否定できません。
直付けしてしまったら、IC交換は絶望的です。そのため、ちょっとICソケットが勿体無いですが、すべてにソケットを
つかうことをしました。そういえば、大昔（学生時代）はラッピングでの配線が主体だったので、ロジックICの何倍もする
ICソケットをつかっていました。ソケットだけで２〜３万円つかった思い出があります。
さて、話はもどって準備のその１はICピンを短く切ります。これは、ピンが基板から突き出ると、配線が引っかかってしまうのと、
あとはランドの中央を通せないためです。これは他のWEBサイトをみて参考にさせていただきました。ポリウレタン線をランドの中央
に配置して、そこに半田コテ先を押し付ければ被覆も溶け易いようです。ただし、これはスルーホール基板しかつかえない方法です。
準備その１：ICピンが基板を突き抜けない程度に短く切ります。
準備その２：ピン足ラベルを作成
基板は裏返して配線するので、ICピンの左右が逆になります。注意しないと、ふと間違えて配線して、手戻りが発生します。
ということで、今回はすこし丁寧にICの裏に貼り付けるピン番号を書いたシールを貼ることにしました。さらに、今回は
シールの上に耐熱性のあるポリイミドテープを張っておきます。紙のままだと溶けた半田が触れると、簡単に焦げて黒くなってしまうので、
それを避けられるのではとの算段です。さてさて、効果のほどはいかに・・・・・。
準備その２：ICの裏に張るピン番号シールの作成です。黄色テープはポリイミドです。
こんな感じで貼り付けます。銅箔テープはVCCライン（５V)です。GNDラインは部品面にメッシュでベタがあります。
準備その３：電源ラインの配線
つぎは、ロジックICを含めて電源ラインとパスコンを配線です。
準備その３：電源ラインとパスコンを配線します。
さて、ここまで出来ればあとは回路図を見ながら配線です。
あ、忘れていました。
準備その４：まずは机上整理と・・・・
配線にかかる前に、一度机の上を整理して作業がしやすいようにしておきましょう。
そして、配線をしだすと喉も乾くので、泡の出る麦茶を準備です（笑。
さて、夜な夜な作業ができる環境が整いました・・・。
一気に・・・・
ちょっと配線しだして、もう遅いから寝なくっちゃと思いながらも、あと１本、あと1本だけ〜と
切りのいいところまでと、作業をしていたらすっかり配線が終わっちゃいました。
泡のでる麦茶も結構、飲んだなあ〜（笑。
もう、いい加減寝よ・・・・・・。
とりあえず配線完了 2020.10.21
思ったより早くできた？
おもったより短時間で配線ができたと思います。その理由は、回路図からみるほど配線があまり多くなかったかもしれませんが、
ICの裏面にピン番号のシールを張っておいた効果が大きかったと思います。というのも、いつもは、ピン番号は「右から３番目」とか
いちいち数えながらやっていました。じつは、それがかなり効率の悪い作業だったようです。ピン番号を振っておいたおかげで、
次々に配線を進めることができました。準備にすこし時間がかかりますが、全体でみればかなりの効率化です。
それに、ミスも少なくなります。これは、次から採用だなあ〜。
太目がいい？
今回もポリウレタン銅線をつかいましたが、いままではφ0.16mmのものでしたが、今回は下記のφ0.29mmを使ってみました。
どちらが、作業しやすいかというと、適材適所というところはありますが、結論としてはφ0.29mmの方が使いやすいようです。
その理由は
・ある程度の太さがあるので、安心できる（ちょっと引っ掛けたくらいでは切れない。勿論φ0.16mmでも切れませんが、安心感があります）。
・剛性があるので、曲姿で固定してくれる（φ０．１６はへなへなです）。
・線が太いのでよく見える（老眼にもや挿しやさしいです（笑））。
ただし、
・太いので被覆が溶けにくい。
・かさばる。
・ピンに巻きつけるのは難しい。
というデメリットもあります。今回の基板のように、１対１での配線が多いところではφ0,29が使いやすく、
RAMなどの同じパターンの配線を繰り返すような場合だと、ピンに線を巻きつけて半田づけできるφ0.16mmが使いやすいという感じです。
今回はこれを使ってみました。φ0.16mmに比べると断面積は４倍あります。
まずは配線完了です。チェックはこれからですが、ちょっとした達成感があります。
とりあえず配線が完了しました。
φ0.29mmのポリウレタン線をつかったので、すこし盛り上がっています。瞬間接着材で固めたらもう少し平らになるでしょう。
ただし、それは動作確認してからになります。
RGB信号出力のR-２R DAC部分です。R：５ビット、G：６ビット、B:５ビットの１６ビットです。一応65K色です。
ちょっと面倒ですが、ついでに・・・
VRAMのSRAMも組み立てておきましょう。128kByteのRAMを４個重ねて半田付けですが、
ICのピンを曲げるのが面倒です。これが２個必要になります。このRAMの加工については
CPM68Kの３号機のところでもやりました。
VIDEO-RAMも作りました。
明日は配線チェックをやりましょう。
配線チェック！ 2020.10.22
さて、テスターをつかっての配線チェックです。今回の配線チェックは、配線間違いを探すこともありますが、
ICソケットのピンを短く切っているので、半田がきちんと流れ込んでいるかの確認が大きいです。
調べてみると半田の流れ込み不良はありませんでしたが、１箇所ですが配線が入れ違いになっているこころがありました。
あと、もう１箇所はちょっと面倒な間違いをしていました。オフセット値のデータラインのD0〜D6を反対に取り付けていました。
一筆書き配線の途中での間違いなので、修正は面倒です。ただ、これはソフトで修正できるので、そちらにまかせます。
非力なMC68000ではなくて、オンボードのPICに変換テーブルをもたせて、D0〜D6を入れ替えましょう。６ビット程度なので
６４個の配列で済みますから、容量的にも問題ありません。
配線チェックをしていて、配線が反対向けになっていることろがありました。配線を直すのは面倒なので、ソフトで対応です。
PICのプログラム作成
配線チェックも終わったので、次はPICのプログラムです。PICと水晶発振器だけを挿してプログラム作成です。
PICは水平同期と垂直同期信号を生成していますが、消費する命令サイクル数が重要になりますので、
オシロで水平同期周波数を確認しながら作業を進めます。
このとき、オシロで観測する周波数から命令サイクル数の計算がしやすいように、水晶発振器は25MHzで行います。
本来は25.175MHzになりますが、電卓を叩くときに「27175」といれるより「25000｣といれる方が楽ですからね。
つい、横着してしまいます。
まずはPICだけを差し込んで、PICのプログラム作成です。PICは同期信号を生成しています。
動作速度をチェックしやすいように、25MHzのきりのいい水晶でテストです。
全部の部品を搭載しましょう！
PICのプログラムも作成（バグ取りはまだですが）したので、残りの部品ととりつけます。といっても、ロジックICはソケットに挿すだけです。
ちょっと面倒なのが、RAMを差し込んで数本の配線が必要ですが、まあそれほど時間がかかるものではありません。
で、とりあえず完成です。久しぶりに凝った回路をつくったので、しばし完成した基板を眺めて泡のでる麦茶です（笑。
全部の部品の搭載が終わりました。久しぶりの作品です。
反省するところあるな〜
完成したので、ますはボード単独で動かしていくことにしますが、単独だと入力端子の電圧が不安定になるところがあります。
そういったところは予めプルアップなどをしておくべきでした。ということで、急遽ICに直接抵抗をとりつけです。
基板の動作を確認したら、あらためて裏面にとりつけましょう。
急遽プルアップ抵抗をとりつけました。これでボード単体でも動作ができます。
動かない・・・・
いよいよ、ワクワクドキドキの電源投入です。で、まずは電源装置の電流モニターを注視しながら電源ONです。
万が一、いやもっと高い確率で起こりますが、異常な電流が流れるようならすぐさま電源OFFの体制をとります。
で、震える指で電源ON!!!・・・・・・
あれ？LCDモニターは真っ暗なままです。わずかに薄い縦線がみえますが・・・・・・。本来ならSRAM内部の情報が
表示されるので、ランダムパターンが見えると思ったのですが・・・・・
まあ、最初はこんなもんです。
ちょっと、気持ちを落ち着けるために、泡のでる麦茶をもう１本・・・・（と、かなり動揺してい（笑。
電源ON! あれ？うんともすんともいいません。
論理ミス発見！
オシロで信号をおいかけていくと、どうやらVIDEO-RAMが動いていません。正確にはRAMのCE端子が
アクティブになっていません。で、回路図を再度ながめて、論理ミスがあることがわかりました。
なんでこんな回路にしているのだろう？いまとなってはよく思い出せませんが、おそらく修正する前の
配線が残っていたのでしょう。まあ、この修正なら簡単です。
論理ミスがありました。
まずは前進？
配線を修正して、再度電源ONです。今度は、無事にランダムパターンがでてきました。
画面も固定しているので、VIDEO-RAMの内容を表示していると思います。
あとは、CPM68Kと接続して、VIDEO−RAMに書き込んだら表示が変わるかを確認です。
まずはランダムパターンがでました。VIDEO−RAMの内容を読み出していると思います。
ちょっと前進です。この画面がでると、すこし嬉しくなりました。
ということで、まずは泡のでる麦茶です。 いったい何本呑むのだろう？（笑。
CPM68Kと接続しよう！
寝ないといけないので、また明日かな〜・・・・・・。
連結基板でCPU基板と接続 2020.10.23
こういった基板があると便利なんだけどな〜といつも思っていましたが、あまり見かけることもなかったので
自分で作りました。いわゆるコネクターの小さなバックプレーンみたいなものです。最大50Pのコネクタがつかえます。
接続ピッチは適用に選択でるように穴をいっぱいあけています。基板が薄くできれば３〜４枚程度がつかえる計算です。
切断した40pに小さくすればRasPi用にでもいいでしょう。
連結基板をつくってみました。
裏面は繰り返しパターンです。
裏面のパターンです。
CPM６８Kの上側にVIDEO−RAMカードを取り付けました。L型のピンをつかっています。
まずはバグだらけ・・・・・
CPM68Kと接続したので、DDT（デバッッガー）をつかって、VIDEO-RAMに適当な値を書き込むのですが、
表示が無茶苦茶、ノイズだらけです。症状は
１）縦横で同じパターンが発生している。
２）書き込んでもいないところのドットが点灯する。
というところ。まあ、病状が顕在化しているので対処はしやすいです。
まずは一投目？ ヒットを打たれてしまいました・・・・。画面表示が無茶苦茶です。
まず同じパターンの発生については、アドレスカウンターに問題があることがわかります。で、オシロをつかってカウンターの出力をみていて
すぐにおかしなところに気づきました。そう、自分の書いた論理回路がおかしいのです。単純に４ビットの同期カウンターを３個並べて１２ビット
のカウンタにしてしまっていました。これって、８ビットまでしかできないんですよね〜。単純な馬鹿ミスでした。ということで、カウンター周りを
修正。まずは、同じパターンが出現する問題は解消しました。
ノイズの発生に関しては、あきらかにVIDEO-RAMに与えるアドレスのセットアップタイム不足です。まあ、想定していた範囲ではあったのですが・・・
動くかな〜と思っていましたが、やはり駄目でした。起こってほしくない悪いことは、必ず起こるというマーフィーの法則ですね。
これを修正するのは、CPUボードからの生アドレス信号をもらわないといけません。最初は、ｺﾝﾃﾞﾝｻと抵抗で信号をすこしずらすことで
対応しようとしましたが、CPUクロックを上げたら（オーバクロックで40MHzまであげたら）誤動作してしまいました。
悪あがきはやめて、すなおにCPUボードからアドレスの生信号を取り寄せることにしました。
描画を行うと、他のエリアにノイズが発生します。
同じ描画を繰り返すとこの通り。アドレスのセットアップタイム不足が原因でした。
CPUボードから生アドレス信号をもらって修正です。
ようやく綺麗な表示になりました
バグを修正して、ようやく綺麗が画面になりました。でも、細かいところをみると、1920×1080用のモニターに
640×４８０を無理やり表示させているので、すこしいびつさがあるのは仕方ないようです。
ようやく綺麗な表示になりました。
全体を組み立てなおし
さてグラフィックボードも完成したので、再度CPM68Kシステムを組みなおしです。
まずはCPUボードを上に、グラフィックボードを下に配置しなおします。
CPUボードの上に、IO基板を乗っけてます。この配線は40Pのフラットケーブルです。
CPUボードもグラフィックボードも４個のRAMを親亀小亀にしているので、背が高くなってしまいます。
ちょっと格好悪いですが、仕方なしです。
あとはソフトを書いていきましょう！
あとは、キャラクターフォントを搭載して、仕上げていきましょう。この後の作業はソフト中心ということもあり、
このTeaTimeのコーナもすこし長くなってきたので、一旦ここはお開きです。
あと、CPM68Kの独立化にはキーボードの直接接続が必要ですが、これは別コーナで取り扱いましょう。
備忘録（回路図）
（おしまい？）
エピローグ 2020.10.24
その１．フォント表示
どのような感じで文字が見えるか、試して見ました。２４インチモニターなので、８０×２５行にすると、かなり文字が大きいです。
老眼・近視にとっては嬉しいです。フォントを小さくして１０６×４８行で十分な視認性です。スクリーンエティターなら
こちらの方がいいかもです。
８x16ドットのフォントで８０×２５行表示。24インチモニターなので文字も大きく、目に優しいです。
5
5x7ドットフォントで100x48行でカラー表示。このｻｲｽﾞでも十分な文字の視認性が得られます。
エディターなら文字数の多いこちらかな。
５×７ドットのフォントです。
その２．CPU水晶交換
グラフィックボードを増設してから、ときたま、あるいは頻繁に謎のコンパイルエラーが発生。正確には、コンパイルの中で
アセンブラでエラーが発生している。そのエラーの発生も、同じソースでも異なることがある。また、あるときはSDカードの
内容が壊れた。正確には、同じファイル名が２，３個できたりしている。おかげでOS（ＣＰＭ６８Ｋ）を入れなおす羽目に。
いままで16MHz版のMC68HC000は40MHz水晶でオーバクロック動作させていたが、思い当たることもあり25MHzに変更。
そうしたら、コンパイルエラーも出なくなった。
おそらくボードを追加したことで、バス駆動が重たくなってメモリーのアクセス時間の余裕がなくなっているのかもしれません。
まあ、40MHzというのは過ぎたオーバクロックでしたからね。といっても25MHzでもかなりのオーバですが。
現状のメモリーは55nsなのだけど、グラフィックボードと同じ12nsに換えたら、40MHzでも動くかな？ なんせ、40MHzになれて
しまっていると25MHzになると、かなりスローに感じてしまいます。また33MHz水晶あたりに交換してみましょう。
3.その３ 800×512化 2020.10.25
640x480で動くのいいとして、メモリーが勿体無い。折角1MByteのせているのに、640x480だと59%しかつかいません。
もっとメモリーを有効活用しようということで、800X600表示に変更することにしました。ピクセルクロックは40MHzになりますが
ちょうどCPUの水晶を交換してあまったものがあります。また40MHzなら１サイクル25nsなのでメモリアクセス(12ns)も間に合います。
ただし、そのまま水晶を変更したのでしゃPICが動きません。４倍PLLで動いていますが、流石に40MHzでは早すぎます。
仕様上は16MHzで、実験結果からも29MHzが限界でした。ということで、PICには半分の20MHzに分周させて入力します。
PLLで４倍にしても80MHzで、１命令サイクルは20MHzになるので、PICで生成する同期信号はすべて、半分の長さに変更します。
また縦の600ラインはメモリーの都合から512ラインのみを表示させます。画面の中央に表示されるように、上に４４ラインの空白、
下に４４ラインの空白をあけて、44+512+44=600となるように同期信号を組みます。このあたりの柔軟な対応ができるのが
ソフトロジックのいいところです。ハードだと、かなり配線をやり換えなければなりません。
800X512モードで動かすと、フォントとしても8X16ドットがつかえるので、だいぶ見やすくなります。それに、800x512だとアスペクト比も
16:9に近くなるので、２４インチモニターに表示しても自然な感じです。
800x512で8X16ドットフォントを表示。
こちらの方が見やすいです。
800×512表示にすることで、メモリーの活用割合も78%まで上昇しました。
折角なので、1024X512というのも試してみるかな？
４．CPM68KのBIOS改造 2020.11.3
BIOSを改造してVRAM上で画面表示ができるようにしました。
最初はVRAMをあつかうプログラムをC言語で書いて、今までのアセンブラのBIOSと結合させて動かそうとしましたが、
なぜかうまく（全く）動きません。プログラムが悪いのか、リンカーの使い方が悪いのか原因が？？？？です。
そこで、面倒ですがC言語のプログラムをすべてアセンブラで書き直すことに。書きなおすといっても、一からではなくて
C言語のプログラムをコンパイラに通すとアセンブラのリストが得られるので、それをベースにして作成します。
で、BIOSを１本のアセンブラファイルに納めてCPM68Kのシステムに組み込んだら、無事動きだしました。
これで、CPM68Kの独立動作をさせることに大きく前進です。
VRAMをつかって表示ができるようにBIOSを改造です。これでCPM68Kの独立化がかなり前進しました。
で、気づいたことですがキャラクターの描画速度をC言語からアセンブラに書き換えましたが、速度の向上は約70%程度
でした。もっと早くなるかと思いましたが、倍も早くなるようではないようです。というのも、コンパイラの生成するアセンブラ
をみていると、あまり大きな無駄がないようです。MC680000の命令自体がC言語との親和性が高くて、多くのC言語の１文が
アセンブラの１文に対応するように変換できているからでしょう。大昔のCPUですが、先見性のある設計だったようです。