2012年9月後半 (2012年第37～38週）
生きています。
ひと月ほどＨＰの更新をサボったら、「持病が悪化して入院したのか？」というメイルを頂きました。
体調はすこぶる快調なのですが、RETROF-16の画像生成回路（VGA信号の発生回路）に致命的な設計ミスを発見し、落ち込んでおります。
CPU自体は全ての命令が順調に動くのですが、画面がまともに表示更新できないので、BASICのコンパイラもインベーダーゲームも年内実現は厳しくなりました。
もちろん、本プロジェクトを放棄したわけではありません。
設計ミスの詳細は全て把握し、リカバリ方法も決定しました。但し、PCBはパターンのカットやジャンパの嵐で、満身創痍状態です。
思い切ってPCBを作り直すことにしました。 という訳で、回路図、パターン図の書き直しで手が一杯、このHPの更新まで手が廻らなくなり、このHPの更新はしばらくお休みしている次第です（年内には再開予定）。
再開までの作業状況や裏話はtwitter(ID=duo6750）で紹介中です。
2012年9月9日 (2012年第36週）
QtのSLOTを知る50行のサンプルソース
RETROF-16のコンパイラもQtで同時開発中です。ところがこのQt、純粋なC++ではなくC++の言語仕様を独自拡張しています。特にSLOTと呼ばれる独自のイベント通知機能は、VC++やC++builderに慣れている者にとっては、その本質を理解するのは大変です。ここではQtの紹介と私自身の備忘録を兼ね、SLOTに関するサンプルソースを掲示しておきます。
現在、RETROF-16のクロスコンパイラはこのソースに対してクラスや関数を追加することにより作成しています。
※このサンプルソースは、main.cppとmain.hの２つだけで、ビルド可能です。Qt自体は無料で入手できます。
※このソースは、「SLOT機構が動く最もシンプルなサンプル」として筆者自身がスクラッチで作りました。
※動作は確認済ですが、「SLOT機構の理解」や「全てのPCでの動作」を保証するものではありません。
左がmain.h。実体はCxiMainクラスのヘッダーです。実際の「画面作り」はコンストラクタ内で行ってみました。
下から３行目の「private
slots」がQt独自の拡張部分です。簡単に言うと画面の操作(GUI)に対応する「処理」を行う関数であることを示すキーワードですが、純粋なC++erにとっては、この「private
slots」や６行目の「Q_OBJECT」等は非常に違和感を感じるソースコードに見えると思います。
下はmain.cpp。 QApplicationクラスがアプリケーション実行に関する「面倒な儀式」を隠蔽しています。アプリケーション固有の処理はQMainWindowを継承したCxiMainクラスに任せています。
実行結果
上記が実行画面です。大きなテキストエリアが左右に２つあり、左にソースを書いて［Compile］ボタンを押すと、右にオブジェクトコードが現われます。但し、上記のソースはまだコンパイラ本体は実装する前のコードですので、［Compile］ボタンを押しても、単にそれがオブジェクトコードの表示領域にコピーされるだけです。
久々のソフト
今週は、ハードも完成していないのに、久々にソフト作りに「のめりこんで」しまいました。
私自身、スロットを本格的に扱うのは初めてであり、マクロを展開した後のソースを覗いたりして、Qｔの絶妙な実装方法に驚いております。他にも面白いWindowsアプリの開発環境があれば試して見たく思い物色中です。
2012年9月2日 (2012年第35週）
RETROF-16の現状
早い物で、もう９月です。本来ならばとっくに完成しているはずのRETROF-16ですが、まだ画面表示が正常に動作しておりません。
画面表示が乱れる原因と対策（１）
詳細は８月５日の製作日誌にて記述済みですが、要するにVRAMにアドレスを与えてからデータが出てくるまでの遅延時間が原因です。現状この問題は別途ブレッドボード上に用意した74LS04で遅延回路を組み、それを無理矢理挿入する事で、応急処置をしています。
ブレッドボードをVRAMの上に両面テープで固定し、そこに74LS04を置いて、遅延回路としています。
回路的には上記の様にインバーターを６段重ねにしているだけです。
画面表示が乱れる原因と対策（２）
こちらの方はもっと深刻な問題で、「指定したアドレスではない所に書き込んでしまう」です。
これでは、はっきり言って使い物になりません。 現状、原因は確定していないのですが、VRAMに書き込む時のアドレスのホールドタイムが不足している様です。RAMのマニュアル上は「この時間は０でも書き込める」とあったのでので、本当に０として設計したのですが、これがアダにになったようです。
実際に試験に用いた、画面表示のテストプログラム
0000 9080 LD R80H // R80Hの初期値は不定でかまわない
0001 D280 STV R80H // R80Hで表現される「色」をR80で示されるアドレスに書き込む
0002 8801 ADD 1 //
0003 C480 ST R80H // R80の値がインクリメントされる
0004 3000 0000 JMP 0000 // 繰り返すC言語だとこうなります
下記は上記のアセンブラコードを、参考のためC言語で書いたもので、実際にコンパイルをしてものではありません
short int i ; // iの初期値は不定でかまわない
for(;;++i){
x = i & 0xFF ; // 下位8bitをx座標とする
y = j >> 8 ; // 上位8bitをy座標とする
poke(x,y,i) ; // poke()は指定座標に指定データを書き込む関数とする
}要するに
要するに、このプログラムは、画面上に、座標値と１対１に対応したデータを書き続けるものです。
無限ループになっておりますが、同じ場所には同じ値を書き込むので、見かけ上は「静止画」になるはずなのです。しかし実際は左の画像（動画ではないなので説明になりませんが）の様に、激しく画面がチカチカし、微妙に画面が揺れる（表示色が変わる）のです。
この不具合も、8月中には原因を確定したかったのですが、突然押しかけてきた親戚連中や、家の中を遊園地と勘違いしているガキンチョ連中に邪魔され、殆どデバッグができませんでした。
というわけで、本格的な作業は、夏休み終了後になりそうです。