CPLD試食

PSoCを触って以来、古いLSIを弄るにしても周辺ロジックはプログラマブルなデバイス使ってもいいんじゃないかと思い始めまして。 かといってMPUもアナログも使わないのではPSoCはちょっと場違いなので、CPLDを覚えようと思い立った次第です。

f:id:marlesan:20170611043000p:plain
で、これが一応2入力ANDの回路をプログラムして動作させている図なのですが……使ってるCPLDはとっくにディスコンになった時代遅れの一品。 日本語のハウツー的なものはほとんど存在せず、前提知識ゼロでここまでこぎ着けたのは奇跡に近いです。

普通に評価ボード付き入門書とか買ってくればいいのに、無駄な遠回りをしたがる性分なんですな。

たぶん需要ゼロだと思いますが、ちゃんと知識付いたら手順などまとめてみます。 今はJTAG?HDL?論理合成?はぁ?みたいな状態で勘で弄ってます……。


頭おかしくなるかと思った、0.8mmピッチのはんだ付け。 全ピンをDIPピッチの足に引き出して、プログラミングに使うピンは上部のL字ピンヘッダにも繋いでいます。 先日作ったワイヤリングペンは大活躍。 作業にあたって参考にした動画はもちろんこちらです。

www.nicovideo.jp

CPLDへのダウンロードはこんな様子。

f:id:marlesan:20170611045122p:plain
秋月のFT2232Dでイケるぞ!みたいな記事がたくさんヒットしたので見よう見まねでやってみました。 レベル変換もバッファもなく直結で動いたので助かった(ほんとに何も考えてません)。

グラボ製作の方は不足ICの到着待ちです。
245は前もってストックしておけばよかったな。

バス・アービトレーション

水平/垂直帰線期間中はVRAM/PCGにCPUがアクセスできるよう、両者のアドレス端子とデータ端子をバスにつなぎます。 一方、モニタが可視範囲を走査中はVRAMのD0~7からキャラクタID(文字ならASCIIコード)が出て、PCGのA3~A10に入っていきます。 ここにデータバスとアドレスバスが交錯するルートができるので、調停がややめんどくさそうです。 まぁ、541挟めばいいだけなのかな。 PCGがキャラクタROMならアドレス端子をバスに繋げる必要がないので簡単なんですね。

74HC165は入力側で繋がっていて、帰線期間中は動作しないのでCPUアクセス中もそのままでよいはず? ただ、逆に誰もバス権取ってない状況を考えると、アドレス/データバスってプルアップかプルダウンしておくべきものなのかしら。

自作ワイヤリングペン

UEW配線用のワイヤリングペンを作りました。


2本失敗して一番右が決定版。この形じゃないとボビンが倒れてしまうのです。


ホルダー状に曲げた平型の針金を瞬着で仮止めし、細い針金できつめに縛ってから2液タイプのエポキシ接着剤で固めています。 材料はダイソーで全部揃えました。 平型の針金と四角いペン軸の組み合わせがいい具合です。

作る時のポイントは…

  • 土台になるシャーペンは多めに用意しておく
  • 接着剤の硬化はちゃんと待つ


0.5mmシャーペンに0.26mmの線材、0.7mmシャーペンに0.4mmの線材を取り付けました。 ちゃんと使い分けすることになるのかは不明……。

ボビンの外径いっぱいまで線材を巻き取るとフワッてなったとき大変です。 6~7割程度で止めてフワッてなっても線が外に出ないようにするといい感じでした。 予備たくさん用意するために巻き取り用の治具作りたいな。


ちなみに太い方は試作2号機を軌道修正したものです。

引き続きZ80用グラフィックボード検討

そろそろ回路設計したい!
要件まとめて来週中にハード実装に移りたく思います。

VRAMの容量は1Byte/文字の32*24表示で、最低限768Bytes必要。 マルチスクリーンとか画面外バッファとか後々のオプションで考えるとしても、2kBあればOK。

文字のビットマップはRAMに置くので、キャラクタROMではなくPCGと呼ぶそうです。 検討の結果いちばんシンプルに2色でいこうとなったので、1文字が8*8pxで8Bytesのデータになります。 1Byte/文字と決めたのでこれを256文字分用意して2kB必要

つまり2kBのRAMが2個あればちょうどよいです。 まぁ、ないですが。 32kBで代用してもいいけどチョットなー……。 さくっと8kBくらいのDIPSRAM買っちゃいますか(@400円くらい)。 SFCのカートリッジから抜き取ってもよいですが、ハードオフが遠い…そういえばこの方法で8kBを1個は手に入れてるんでした。 アクセス速度は150nsまでならOKと考えてます。

汎用ICはカウンタ、レジスタ、シフトレジスタ、マルチプレクサ(要るかな?)、論理ゲートいくつか、があればなんとかなるでしょうか。 レジスタはビデオ出力の強制暗転をCPUから設定できるようにするためのもので、単に74とか574のD-F/Fでよさそうです(書きっぱなしで読み戻す必要なし)。

HD6445+XGAディスプレイ

HD6445の使い方を勉強中です。

グラフィックボード(CRTC)その1
こちらのページを大いに参考にさせてもらってます。もちろんデータシートも。

で、気付いたことメモ。

  • 同期信号のタイミング指定がキャラ単位なので、先日PSoC5でうまくいったタイミングと同じにできない。HD6445が出す信号をPSoC5でエミュレートして検証する必要あり。
    • 特に垂直はかなりズレそう。ただしトータルは R4 VERTICAL TOTAL ADJUST で調整できるはず。
  • ラスター(1文字あたりの縦px数)は1文字8*8pxなので8。ではなく、32を設定する。で、ラスタアドレスは下位2bitを無視してキャラROMに繋ぐ?
    • 256*192pxを縦横4倍してXGA(1024*768px)としてディスプレイに出力するための方策。
    • データシートのINTERNAL BLOCK DIAGRAMによるとラスターカウンタは2段あって、2段目がスムーススクロールのコントロールに使われてるよう。つまり、上記のような拡大出力にも対応していて、XGAレベルでの4px移動をスムーススクロールとして扱ってくれるということなら、すごく考えられたICだ。その機能を使うかは別として…。

追記

  • スムーススクロールは行ごとの開始ラスターアドレスがR29に設定した値になる機能のよう。ラスター上限を超えると次の行のデータが出てくるような図があるので、そのタイミングでVRAMのアドレスが次の行+ラスターアドレスが0にリセット、となるのでしょう。つまりR29を+4ずつ足していけば4倍拡大出力時のスムーススクロールも実現可能、のはず。
  • それとは別に、縦2倍ならCRTCで対応可能(RASTER INERPOLATION)。同じラスタのタイミングを2回ずつ出力してくれる。
  • SKEW。詳しい説明がないので常識的な概念なんだろうか…たぶん、可視範囲でアクティブになる信号DISPTMGのディレイをかけられる(キャラクタ単位)。先日考慮した「走査に先行して出力データを作っておかないといけない」というのはこれで対応できそう。走査の方を遅れさせるわけですね。この場合、同期信号も遅れてくれた方がいいと思うけど、その辺はどうなってるんだろう。
  • 分割スクリーン機能あり。どういう仕組みだろう?と思ったけど、各スクリーンごとにVRAM上の開始アドレスを設定できるらしい。なるほど!

キャラクタディスプレイ考

1文字8*8pxを256*192のスクリーンに敷き詰めると32*24文字。1文字(の1ラスタ)のデータを用意するのに使える時間は16MHz/8の逆数で500ns。85nsのSRAMで3メモリサイクルはいける?

  1. VRAMから文字コード読み込み
  2. キャラクタROMからシフトレジスタへ8bitのラスタを読み込み
  3. 色などの指定を読み込めそう

色指定するならDACの経路をスイッチして、そこへラスタデータをピクセルクロック(16MHz)で押し出す。てな感じでしょうか。 走査が始まるまでに押し出し準備完了している必要があるので、データ読み込みは走査タイミングより先行しないとですね。 そう考えると水平同期や垂直同期のタイミングって色々工夫ができそうな期間に思えます。でもまぁ、とりあえずシンプルに。

次の問題はVRAMからデータを読み込む方法です。これはDMA(グラフィック回路が直接RAMにアクセス)になると思います。 この時VRAMがメモリ空間にあるならCPUを止めないとなんですが、4MHzで動作してるところに2MHzのタイミングでバス権取ったらかなり遅くなりそう。 というか都度BUSRQする方式ではCPUの状態次第で走査タイミングに間に合わない場合も出てくるのでは?

  • VRAMをIO空間に置く
  • VRAMをメモリ空間に置くが、メイン空間と別バンクにする

単純に思いつく別解は以上で、どちらもCPUからのアクセスが明示的になるので、それ以外の期間はCPUバスから切り離しておいてグラフィック回路が自由にアクセスできるようにする方法です。 今度はCPUからVRAMに書き込むタイミングが難しくなりますね。IO方式だとさらにCPUからVRAMへのアクセスが遅くなるし、使える命令も限られてきそうです。 どうするのがいいかなー。

サイクルスチールというキーワードが気になったので調べてみます。

追記

85nsのSRAMで3メモリサイクルはいける?

むりかも。バスにデータが出てくるまでに16MHzの1クロックじゃ足りないので2クロック待って、3クロック目で出力先がホールド、なので1メモリサイクル=3クロック。65ns*3クロック*3サイクル=585ns。oh…

  • A案:色を諦める。もともとオプションだからこれでいいけども。
  • B案:色情報だけ1文字4bitとすれば2文字分取ってこれる計算になる。ただ2文字処理ごとに3サイクル目を入れて結果をラッチするという回路がめちゃめんどくさいはず。
  • C案:データ待ち130ns・ホールドに65nsどっちも無駄があるので、ベースクロックを32MHzとかもっと細分化して、RAMアクセスはそっちで動かす。現実的。

追追記

いや、VRAMとキャラROMにアクセスするためのアドレスはHD6445が生成するから、そのタイミングも合わせて考えないと何ができるか確定しない…。

Z80システムのグラフィックボード

解像度256*192でスペック下げたつもりでしたが、8bitCPUのゲーム機と考えたら限界近いサイズな気がしてきました。 ハードで相当工夫しないとMSXとかファミコンみたいにならないですね。当たり前か。

目下の問題は、VRAMから映像信号作るのに、使用予定のSRAMのアクセス速度が足りないことです。 ピクセルクロック16MHzだと1pxの信号は65nsで作らないといけないと思うんですが、手持ちのSRAMは85ns。 1px処理するのに、リアルタイムに読み込めるデータって1Byteもない計算に……。

なんだか知識経験ゼロ故に根本的に勘違いしてる感あるので、まずシンプルなところから始めたいと思います。 白黒のキャラクタディスプレイドライバ製作を次の目標としましょう。 HD6445を使ってみる予定。