2012年8月25日 (2012年第34週）
早く終わって欲しい「夏休み」
既に親戚連中で満室の我が家に、別の親戚が泊まりに来て、小生の「特別開発室」も「来客用宿泊室」として没収されてしまいました。
電動ドリルとかハンダゴテ等の危険物も「一時避難中」です。
この状態では。RETROF-16の開発再開は夏休み終了後になりそうです。
【写真】突然運びこまれた来客用の布団セット2組。左上の黒いのは来客用に没収された小生の予備機。
2012年8月18日 (2012年第33週）
RETROF-16の内部からバグを２匹抽出しました
VRAMへのアクセスが不安定で、画面にフル解像度で絵が書けないというバグはまだ治ってません。
とりあえず、不具合の原因と思われるバグを２匹抽出しました。
と言うのは冗談で、これは某小学生の夏休みの自由工作用に作った「虫」を自分でも作ってみた物です。
最初は左の「虫」を作ったのですが、「目は光らないの？」と言われ、右の「改良版」を作りました。 改良版は３個ネジ止めボタン電池が腹部になっております。胸部は0.8mmφのドリルで穴をあけた電解コンデンサに抵抗を挿しただけのダミーです。 頭部はLEDの下にLMC555があり右目と左目が交互に点灯します。 顎の様に見える２本の突起は、左の回路図の33Kと2.2Kの抵抗です。
【警告】電解コンデンサに穴をあけるのは大変危険な行為です。中の電解液が飛び出る場合があります。
電解液が眼に入ると失明の恐れもあります。小さなお子さんの前では絶対に行わないでください。
CΞ言語 (シークサイ言語)コンパイラ
まあ、そんなこんなで、RETROF-16のバグの回収は全く進むんでおりません。
コンパイラ作成の方はそれなりに進んでいるのですが、その状況をHTML化する作業は全く行う余裕がありません。 ちなみに、下記はGUIの試験用に作ったソースプログラムの一部です。
今回はWindows用のライブラリや、String処理等の基本ライブラリのみQt(別窓で開きます)から借用し、それ以外は純粋なC++でフルスクラッチで作ろうと思います。（このペースだと完成するのは、ソチ五輪かリオ五輪の頃やもしれなせんが）
2012年8月12日 (2012年第32週）
一回休み
８ヶ月間毎週何らかの進捗があった本製作も、今回は完全に一回休みです。
RETROF-16の製作は、その殆どが早朝（朝４時～８時頃）に行っているのですが、今回は見事にその時間帯が、ロンドンオリンピックと重なってしまいました。別に「昔はアスリートだった」とか「スポーツ観賞が好きだ」という訳ではないのですが、やはりTVをつけているとどうしても競技を見てしまいます。結局、デバッグは殆ど何も進みませんでした。
まあ、何事も上手く進まない時は、焦らずに休養するのも大事かとも思います。
2012年8月５日 (2012年第31週）
大問題発生
先月から、ずっとグラフィック表示不調の原因が究明できず悩んでおりました。
症状を簡単に言うと「直線や矩形の様な簡単な図形は正しく描けるが、インベーダーゲームのタコの様な複雑なドットパターンを書くとドットの配置が乱れて絵にならない」という現象です。
当初これは、機械語で組んだプログラム自体の誤り、もしくは命令デコーダ等のCPU周りのバグだと思っていました。しかし、よくみると不思議な事に気がつきました。
左の画像は先週の製作日記でも紹介した乱れた表示の一部を拡大したものです。白枠で囲んだ部分が、RETROFが制御できる画素単位です。使用した液晶パネルは横1024画素なのに対し、RETROFの横方向の解像度は256です。四角で囲んだ所は縦線が４本（つまり横に４画素）あるのが判ると思います。
問題は、白い四角で囲んだ周辺に、縦線が２本とか１本しかない画素があることです。
回路上は横方向（水平スキャン回路）は液晶パネルの４ドット単位で必ず同じデータ値（つまり同じ色）を表示する設計になってますので、画像の様に２ドット単位あるいは１ドット単位で色が変わることは有り得ないのです。
当初は、「設計より小さな輝点はノイズを拾っているのだろう。後でパスコンでも入れよう」と安易に考えていたのですが、とんでもない設計ミスが潜んでいたのです。
素人並のタイミング設計ミス
恥を忍んで事実を公表します。ソフトにしろハードにしろ、どんなに難攻不落な不具合であっても、その99％は、原因がわかると実は驚くほど単純な原因であるものです。
RETROF-16のグラフィック回路は32KＢのSRAM(TC55257-PL10）をビデオバッファとして用い、256×256のドットを表示する設計です。各バイトを上位４ビットと下位４ビットに分けて使い、１バイトで２画素を表示します。（32K×２画素 = 64K画素 = 256×256画素）
書き込み時は横方向に隣接する２画素単位で書き込み、画面表示時は4bitのセレクタである74LS157を用いて、上位４ビットと下位４ビットのデータを交互に取り出し、RGB信号に変換して液晶ディスプレイに贈っています。このときの表示のタイミングチャートは以下となります。
もし、上記のチャートどうりなら何も問題は発生しないのですが、実際には以下となり、論理的な１画素よりも短い画素が現われます。これは隣り合う画素に異なる色を与えた時のみに現われる現象です。
何のことはありません。VRAMにアドレス値を与えてからデータが現われるまでの時間を無視していただけです。正確に言うと無視していたのではなく、「無視して良い程度に短い」と勘違いしていたのです。使用したSRAMのアクセスタイムはMAX100nSであることは百も承知だったですし、基準クロックが約9MHzであることも百も承知だったのに、なぜ「無視できる長さ」と判断してしまったのでしょうか？
解決策は暗中模索中
一番美しい解決方法は、VRAMのデータ出力をD-FFで受け、そのD-FFの更新タイミングを157による切替えと同期させることです。しかし基板上には予備のD-FFも予備のエリアもありません。
157の選択タイミングをSRAMのアクセスタイムと同じ程度に遅延させる、という方法もありそうですが、基板上には予備遅延素子も、それを置く予備のエリアはありません。よりアクセスタイムの速いSRAMを使えば若干は改善される可能性はありますが、入手に時間を要しますし、入手できても完治する保証はありません。
横方向の論理的な解像度を半分（128）にすると、本件は解決するのですが、その場合の解像度は、左の画像程度となり、RETROF-16の機能目標である「インベーダーゲームを動かせる事」をクリアすることができません。