VGAモニタ出力の実装

XilinxのData2memで、二つのメモリブロックをISEから自動的に別々のデータで初期化する方法が見つからないので、フォントデータは登録できていない。手動で書くなら、data2memを2回通せばいいような気がするが、マウスだけで簡単操作の原則に反するので、もう少し検討。とりあえずは、折角実装した動作の確認をオシロでする。

水平同期と垂直同期の信号は正しく出ているので、タイミングの計算は間違っていないことが分る。

追加メモリブロックが読めなかったり、いくつか原因不明のトラブルがあったので、実験的に、DCMを用いて、クロックの分周をしてみた。再現性が高い不具合なので、クロックの問題でないのは明らかなのだが、DCMを使う例題を作りたかったので、ちょうどよい。

SFLからDCMなど既存のモジュールを使う時には、プロトタイプ宣言に interface 修飾を付ける(sfl2vl限定)。

declare BUFG interface{
 output O;
 input  I;
}

declare DCM interface{
 param_int CLKDV_DIVIDE;
 param_str CLK_FEEDBACK;
 input RST, PSINCDEC, PSEN, PSCLK, CLKIN, CLKFB;
 output PSDONE, CLK0, CLK90, CLK180, CLK270,
        CLK2X, CLK2X180, CLKDV, CLKFX, CLKFX180,
	LOCKED, STATUS<8>;
}

モジュールにおけるDCMなどのインスタンスは、例えば、
 
 BUFG buff;
 
 DCM dcm_2(CLKDV_DIVIDE=4, CLK_FEEDBACK="1X");

と、宣言する。
共通動作宣言で、下記の様に接続を定義して使う。
(これは、4分周クロックを使う例となっている)

  dcm_2.RST = p_reset;
  dcm_2.CLKIN = m_clock;
  dcm_2.CLKFB = dcm_2.CLK0;
  dcm_2.PSEN = 0b0;
  dcm_2.PSCLK = 0b0;
  dcm_2.PSINCDEC = 0b0;
  buff.I = dcm_2.CLKDV;
  board.m_clock = buff.O;
  board.p_reset = p_reset;
 

VGAに文字が表示されたなら、プロジェクトをアップロードする予定だが、我が家には空いたモニタがないし、このところ忙しいので、いつになることやら…

パブリックドメインフォント

Apple-I互換機で使用するための英文フォントデータをXfree86のBDFフォントファイルから抽出するためのawkスクリプトを作成。

                                        
BEGIN {enc = 0; fnt = 0;}
/ENCODING/ && $2 > 31 && $2 < 128 { enc = 1;}
enc == 1 && /BITMAP/ { fnt = 1;}
enc == 1 && /ENDCHAR/ {enc = 0; fnt = 0; print "00\n";}
enc == 1 && fnt == 1 && !/BITMAP/ {print $0;}

5x7.bdf専用であり、汎用性は皆無だが、とりあえずの目的には合致しているだろう。

あとは、VGAコントローラを作成して、実際に表示できるようにするだけだ。

Apple-I互換機にPS2 Keyboardを接続

Spartan3EスターターキットにはPS/2コネクタを搭載しているので、これをApple-I互換機から使えるようにした。PS/2のインタフェースを入力線2本だけIOポートに接続してソフトでやらせてもいいのだけれど、ソフトの開発も自分でやるので、ここはPS/2用の小さなシリアル入力回路を作る。11ビットのシリアルデータをパラレルに変換し、ステータスビットを用意して、Apple-I互換機のメモリ空間にマップする。

とりあえずは、スキャンコードの変換はソフトに任せることとして、キーボードからデータが出力されることを確認。

文字と16進数の出力ルーチンはWozのモニタのサブルーチンを流用したので、確認プログラムはごく短い。

Apple-I互換機で、液晶パネル駆動

Apple-I互換機の液晶パネルの制御プログラムをアセンブラで書き、FASMでアセンブルした。FASMはNES用のアセンブラであり、オブジェクトフォーマットはAAXと書かれていたが、中身を見ると単なるモトローラS形式だ。

そこで、CでS形式からApple-Iモニタメモリ入力形式への変換プログラムを書いて、TeraTermからファイル送信で、Apple-I互換機にアップロードする。

端末設定で、受信の改行をCR+LFにすることと、シリアル設定で、送信遅延を2mS以上取ることに注意する。(シリアルコントローラの受信部の問題?)

Spartan-3E starter kitのマニュアルを参考に、LCDパネルコントローラにコマンドを送るプログラムを作成。

遅延時間を微調整したりしたが、とりあえず、無事、画面表示はできるようになった。

---

ちなみに、プログラムは…

0800: A9 01 85 10 A9 03 20 E0 08 20 FB 08 A9 03 20 E0 08 20 F2 08 20 F2 08 20 F2 08 A9 03 20 E0 08 20
0820: F2 08 A9 02 20 E0 08 20 F2 08 A9 28 20 BD 08 20 F2 08 A9 06 20 BD 08 20 F2 08 A9 0C 20 BD 08 20
0840: F2 08 A9 01 20 BD 08 20 FB 08 A9 48 20 C7 08 20 F2 08 A9 65 20 C7 08 20 F2 08 A9 6C 20 C7 08 20
0860: F2 08 A9 6C 20 C7 08 20 F2 08 A9 6F 20 C7 08 20 F2 08 A9 21 20 C7 08 20 F2 08 A9 C0 20 BD 08 20
0880: F2 08 A9 41 20 C7 08 20 F2 08 A9 50 20 C7 08 20 F2 08 A9 50 20 C7 08 20 F2 08 A9 4C 20 C7 08 20
08A0: F2 08 A9 45 20 C7 08 20 F2 08 A9 2D 20 C7 08 20 F2 08 A9 49 20 C7 08 20 F2 08 4C 00 FF 48 A9 01
08C0: 85 10 68 20 D1 08 60 48 A9 03 85 10 68 20 D1 08 60 48 4A 4A 4A 4A 20 E0 08 68 29 0F 20 E0 08 60
08E0: 8D 21 D0 A5 10 8D 20 D0 EA EA EA EA A9 00 8D 20 D0 60 A9 C0 85 11 C6 11 D0 FC 60 A9 80 85 12 20
0900: F2 08 C6 12 D0 F9 60

SPARTAN-3E Starter KitでApple-I互換機

Xilinx社のSPARTAN3E starter kitにもApple-I互換機(AISoCS)を移植した。
このキットには、7SEG LEDが付属せず、液晶パネルが付いている。そこで、液晶パネルのコントローラをアドレスデコードして、6502から読み書きできるようにしておく。その上で、液晶パネルをクリアするコマンドを出力するように、プログラムを作成する。
Apple-Iのモニタの上で開発するのはしんどいので、16進数を打ち込んだファイルをTeraTermPROのファイル送信機能を用いてアップロードする。
(ここで、文字ごとに少し遅延を置かないと、文字化けが生じた)

結果であるが、このプログラムの実行で、液晶パネルは何らかの影響を受けているらしい(;-p)

というのは、送ったのはパネルクリアのコマンドのはずだが、2回プログラムを実行しないとクリアしないのだ？？？(1回目もパネルの表示は変るのだが、クリアはしない)

Digilentの仕様書もいいかげんだし、ハンドアセンブルなので、初期化など完全にサボっている私のプログラムもいいかげん ということで、原因は追求していないが、時間ができたころにゆっくりと対策を考えよう。

Apple-I互換システム(AISoCS)を作ろう!

以前、6502互換CPUを作ったが、これを用いて、お正月休みの間に、Apple-I互換システム(AISoCS)を作成した。

本来のApple-IはNTSCのテレビモニタとASCIIキーボードを接続して利用するボードコンピュータであるが、今の時代、これらは返って不便なので、入出力はシリアル端末に変更する。

Wozのモニタの使い方については、ネットを探すと、Apple I Operation Manualが見つかるはずなので、そちらを参考にしてほしい。

ターゲットボードは、Xilinx社のSpartan3 Starter Kitである。
(実は、帰省直前に、digikeyに発注していたSpartan3E Starter kitも届いたのであるが、持ち帰らなかったので、少し古めのボードになるが、シリアルしかまともには使わないので、シリアルポートが使えるボードならなんでもいいはず)。

モニタプログラムはWozのApple-Iモニタを16進ダンプしたものを作成した。(このモニタは、WozがApple社設立以前にパブリックドメインとしたものだ)

IP ARCHのサイトにパッケージをアーカイブしておいたので、これと、sfl2vl(の最新版)を用いて、Apple-I互換機が完成する。

sfl2vlの20090101版は、開発環境の問題から、WindowsGUI版しか作っていないのだが、以前のバージョンとの違いは実はあまりなく、XilinxのISEが、Verilog構文的には正しいのに、エラーを報告する部分の出力形態を調整しエラーを出さないように変えただけ。

組込み技術者のためのFPGA開発入門

組込み技術者のためのFPGA開発入門の執筆を始めた。
この連載記事は始めてFPGAで論理回路を作ってみようと思う人向けの、お手軽入門書を目指している。どれだけ続くか分からないが、とりあえず、第２回までは執筆したので、興味がある方は眺めて欲しい。

FPGAボードとしては、自宅にあるSpartan-3 Starter Kitを使った。
このボードは購入当時、確か、1万1千円で購入したはずであり、値段の割に高機能なボードである。今なら、Spartan-3Aか-3Eのボードが相当するのだろう。

開発用のPCは、例によって、EeePCなのだが、Starter Kitのダウンロードケーブルはパラレルポート用であり、接続できない。そこで、X社のUSBダウンロードケーブルを繋ぐが、これを動かすのに一苦労。そもそも、ISEをインストールした時点で、ドライバが入っているはずなのだが、デバイスが使用できませんとなる。X社のホームページで検索して、ドライバをダウンロードしてインストールするが、やはり、失敗。

結局、ダウンロードしたドライバをインストールした後、ISEのbin/ntの下のドライバを追加でインストールをすることでようやく利用可能となった。

Windowsのバカバカしさであるが、接続先のUSBポートが変更になるたびに同じことを繰り返さないといけない…

物理的なインタフェースのUI設計

もう随分と昔の話になるが、産業機器を開発する会社に勤めていたころ、筐体のインタフェースの口はメス型にするようにと言われていた。

オス型のコネクタはピンが折れることがあり、ピン折れで機器の故障となることがよろしくないということだった。

これはこれで一理はあるかなと思っていた。何しろ、その産業機器は1台が数十億円していたので、機器側の故障となると半端じゃすまないのだ(ケーブルなら消耗品で取り替えればすむ)。

ところが、シリアルケーブルのDCE/DTEを見ても分るように、筐体にオス型のコネクタを付けることを厭わない文化もある。どちらがよいとかいうのではなく、思想の問題だろう。


昨日のことであるが、某オークションサイトで落札した、ゲームポートに接続するMIDIインタフェースが到着した。中古品であるから、さっそく動作確認を…

ということで、PCの後ろのゲームポートにインタフェースを接続し、電子ピアノのMIDIコネクタにケーブルを繋ごうとするが、設置場所の関係でコネクタに書かれているポート名が読みにくい。

なんとか、3文字か2文字かは分ったので、おそらくOUT/INであろうと、ケーブルのOUTを3文字側に、IN側を2文字側に接続し、WindowsのコントロールパネルからMPU-401ドライバをインストール(って、これはレガシードライバなので、検索にはかからず、リストから選ぶだけだが)。

サウンドのプロパティ(だったかな？)から、MIDI機器をMPU-401に変更し、MediaPlayerで以前に打ち込んだ、パッヘルベルのカノンの伴奏を演奏させる…が音が出ない？

接続を確認したり、ソフトをMIDIシーケンサに変更したりしたが、同じだ。

う～む、中古品だし、原因追求をどう進めるべきか？(といっても、MPU-401なんて、単純構造なので、そうそう壊れそうもないのだが)

と思いつつ、ふと、MIDIのIN/OUTについて思いだす。

そうだ、MIDIでは、INはOUTに、OUTはINに接続しないといけないだろう？

オス型のケーブル端にOUTと書いてあったら、普通の人はOUTコネクタに挿すと思うが、このケーブルはきっと、PCのOUTのつもりで書いているに違いないと思いつき、OUT/INを入れ替えると… ちゃんと音が出るではないか!

ユーザーを迷わす設計はよろしくない。

MIDIは日本からの提案だけれど、アメリカ人が考えたら、きっと、INはメス型、OUTはオス型のコネクタとしたのかもしれない。と、ふと考えたのであった。

PS:先日来、IMEにSKKIMEを利用している。これはこれで便利なのだが、なんとなく、キーを打つ指に力が入ってしまうのは慣れていないから？

Visual C++ 2008 Express でのSystemC

普通に単純なサンプルプログラムを実行させようとしただけなのに、思ったよりもずっと苦戦してしまった。

教科書によく出ている加算器のモジュールを作り、そのテストベンチをsc_mainに書くという単純なものだが・・・・

1. なぜか、systemc.hがcmath.hを呼び出し、しかも、usingの解消ができないエラーが発生。モジュールは関係なく、#includeだけにしても起きる。プロジェクトをクリーンできれいにしても現象変わらず。昨日、インストール時に確認した最低限(sc_mainだけ）のプロジェクトは再コンパイルしても正常。
   結論：VCが何かのリソースを残しているらしい。完全に新しいプロジェクトを起こし直して、ソースコードだけこちらに持ってきたらコンパイル完
   
2. SC_METHODの指定でワーニング。無視してコンパイルしたら実行時にメモリ参照の例外でダウン。普通に教科書通りなので、言語仕様的には間違っていなさそうで、原因追求に時間がかかる。（その間にLiveCygwinでSystemCをコンパイルしようとしていたりして、メモリ不足からシステムが不安定になるなど、混乱に拍車が掛かる）
   結論：VCのコマンドラインコンパイルオプションに /vmg を追加することでOK。MSDNには、この手のワーニングが発生した時には /vmm を追加しろと書いてあったのでそれを信じて追求に時間が掛かった。
   
   
   
   1. プロジェクトのプロパティ→C/C++→コマンドラインの追加のオプションに /vmg を記述すること。
      
   2. 同じくプロパティー→コード生成→簡易ビルドを行う　を　「いいえ」にする
      
   
   

とりあえず、基本の基本（1つのハードウェアモジュールと、それのテストベンチ）がようやくコンパイルできるようになった。Linux+gccでやれば圧倒的に簡単だろうなぁ・・

EeePCにSystemCを

ネットブックといっても、160GBものHDDを持つPCなのだから、普通のノートPCと何も変わるところがない。OSCIから2.2.0のアーカイブをダウンロードして展開してビルドすれば終わるはず・・


であったが、私のEeePCには以前買ったVisual C++.NETがインストールされているので、こいつでビルドしてみようと考えた。

ところが、SystemCのVC用のプロジェクトは、VC71用しかない。正確にはVC60用のフォルダもあるのだが、中身が空になっている。

私のVC.NETは7.0であり、VC71用のプロジェクトはコンパイルできない（！）。

ということで、急遽、マイクロソフトのVC++ Expressをダウンロード・インストールした。

スレッドライブラリの指定の違いだの、若干の問題はあったが無事にコンパイルしてサンプルの小さなプログラムを動かすところまではできたのでよしとしよう。

SystemCを何に使うんかというは、別のお話・・

マイクロフォーサーズ

横浜のヨドバシカメラの店頭でマイクロフォーサーズのデジカメ第1弾のLUMIX-G1を見てきた。

デジカメはもともと光学系が１系統であり、１眼の要素を持っているのに、１眼レフ（レフレックス）のためのミラーは余分なものだとの想いがあった。そこで、ミラーレスの規格であるマイクロフォーサーズには期待が大きかった。EVFの解像度を上げてきたこともスペック的にまっとうであり、頼もしい。

Panasonic デジタル一眼レフカメラ LUMIX (ルミックス) G1 レンズキット コンフォートブラック DMC-G1K-K

実際に手に持った感触は、普段使っているPENTAX *istDLに比べてそれほど小さいとも軽いとも思えなかったし、期待のEVFはMFの操作性が今ひとつで宝の持ち腐れである。AFも高速化したという割には、なんだかもったりしているし・・

第１弾ということなので、今後、ファームウェアのバージョンアップ等で改善の余地は大いにあるだろう（少なくともMFの操作性など、ハード性能に関係ない部分では・・）が、とりあえずは、見てきただけで満足した。

しかし・・コントラストＡＦ、もう少し何とか知恵を絞れないものですかねぇ・・
（そもそも、MFの出来がよければ、AFはおまけ程度で十分なんだが）

EeePC 904HA

しばらく使ってみての感想だが、
「これで十分じゃないの？」
という感じだ。

今まで、出張などで持ち歩くときのノートPCはDELLのD400を使っていたが、性能も重量も遜色ないし、なぜかWinodwsの立ち上がりはこちらの方が早い（英語版であることが関係するのかな？）。

出張時の緊急ネット用b-mobile hoursがPCカードだったので、EeePCでは当然使えないが、これは、b-Mobile 3G hoursを買うことで解消。
（電源容量不足なのか、本体左のUSBに挿すと画面がブラックアウトするが、右側ならOK）

プレゼンやいろいろな仕事で要求されるMSオフィスとしては、D400に搭載していたオフィス97をアンインストールして、EeePCにインストールした。

ハードディスクも容量的に余裕がるので、iTunesも入れて、どこでも音楽である。


私は、英語版のキーボードではキーボードドライバをAXキーボードに変更することが多かったが、今回は、ふと、101のままで、^\（コントロールバックスラッシュ）を半角全角切り替えキーに設定してみた（もちろん、デフォルトのALT-`も生きている）。バックスラッシュの位置は案外よい位置にあるので、これはいいかも？AXだと右コントロールに文字種切り替えがアサインされるので、ふとしたことで、文字種が変わって不便なときがあったのが解消された。

904HAならドライブは160GBもあるので十分だし、キーボードもかなり打ち易いので、常用していても気にならない。

価格破壊という言葉があるが、EeePCのおかげで十分な性能の文具を適切な価格で導入できて感謝である。

EEEPCがやってきた

Ebayで注文していた、EEEPC-904HAが到着した。

あれ？でも、持ってみるとずっしり重い気がする？

というわけで、重量を測定すると、電池込みで1.377kgなり。
う～ん、予想外に重い。Ebayの製品紹介のページは全く当てにならないことが分かった。

キーボードはほぼ等幅であり、打ちやすそうだし、ドライブも160GBのものが入っている。といっても、写真で（分かるかな？）示したように、ドライブはC:が80GB、D:が約60GBとなっている。

英語版のWindowsXPなので、コントロールパネルから日本語パックを導入して、日本語対応とする。

重さは予想外だったが、とりあえず、きてしまった。後はどう活用するかだ♪

持ち歩きようの文房具としては、KING JIMのポメラか、MVPenの方が便利そうだ・・

---
追記：どうやら、904HAは901系/700系と違い、1000HAなどと共通ボディのような気がする。前に買ったキーボードよりもストロークは深いし、キーは等幅で打ちやすい。ディスク容量も普段使いには十分あるので、「普通のPC」として使えそうな気がする。

EEEPCの新機種？

どうやら、新しい機種（S101)が計画されているらしい。
しかも、今度はキーボードが変わるとのことだ。
これにすると、折角買ったキーボードは使えないが、スペック上は案外魅力的。

うむむ、と、色々と調べると、日本以外ではもっと色々な機種が出ている。
904HAなんて、かなり魅力的かも？

1000Hにも興味を持ったが、よく調べると、この機種、1.4kgもあり、今使っているDELLのD400と大差ないので、携帯性や使い勝手が上がるわけではないので却下だ。

EEEPC US配列 キーボード

Ebayで購入し、郵送されてきたEEEPC用のUS配列キーボードである。
よく見ると、右手小指付近の記号キーが小さくなっている。
この不等キー配列は106だけではなかったのですね～（残念）

それでも、すっきりした配列なので、使い勝手は良さそう。

まだ本体はないのですが（爆）