鈴商のデュアルポートＲＡＭ

以前から気になっていた、鈴商店頭に並んでいる
デュアルポートＲＡＭ。

店頭にはデータシート無いし、
http://www.alldatasheet.com/
とかで探しても見つからなかったので、指をくわえて
いるばかりだったのですが、↓こちらのサイト経由で
http://www.fumi2kick.com/komekame/archives/232


データシートが検索できるとの情報。早速検索。
http://www.datasheets.org.uk/search.php?t=0&q=M5M4C264L&manystr=&sub.x=32&sub.y=11

あった。M5M4C264L。

というわけで早速眺めてみます。
うん。ピンコネは良く解りました。

が、想定外なことを発見。ＲＡＳ、ＣＡＳ？って…
これＤＲＡＭじゃん！

ＳＲＡＭのデュアルポートＲＡＭだったら速攻で
買っちゃうところなんですが、ＤＲＡＭなのか…

いろいろ調べてみると、元々ＤＲＡＭだからこういう
デュアルポートの仕組みになったってことなのねぇ。

でもアクセスがちょっと面倒だからな。リフレッシュとか。

マイコンはピンが少ないし、しかも専用のＩ／Ｆも
付いてないから、ＤＲＡＭを直接アクセスするのは
面倒だな。

まぁ、用途としてはマイコンと繋いでビデオＲＡＭに
しちゃおうという話なので、ビデオ信号生成と
描画処理を切り離して考えることが出来、その点では
楽といえば楽かな。

あと、良く解らないのは反対側のポートからの
読み出し方。ＳＡＭ（SerialAccessMemory）の
方のアクセス方法。コレがわかれば、まぁまぁ
ラクチンに扱えそうでは有るんだけど…。

http://www.c-able.ne.jp/~tatarat/mac/beginners/video/dual.html
http://www.c-able.ne.jp/~tatarat/mac/beginners/video/vramtak.html
ここを見てみると…

扱いとしてはＳＲＡＭのような、ＳＲＡＭじゃないような…
そもそもシーケンシャルに読み出すからＳＡＭっていう
ので、ＳＲＡＭ（StaticRandomAccessMemory）って
呼ぶのは変だな…。仕組み的にもStaticでは無いみたいだし。

それにしてもＳＡＭ側からの読み出しって結局
どうやれば良いんだろう？

一端行バッファに読み出したデータは、その範囲内なら
ＳＲＡＭみたいに読み出せるってことなのかな？
行を一端指定するといっぺんにバッファに
読み出しが行われ、その範囲内ならＳＲＡＭのように
扱えるっていうことかな？

そもそもバッファに読み出すための指示は
書き込み側からしか出来ないのかな？
それとも読み出し側からも自由に指定できる
のかな？

データシートの挿絵を掻い摘んで見てみた感じ
では、書き込み側からカラムを指定すると１行分の
データがバッファに読み出されるって感じかな。
そうすると、好きな行を好きなように読み出し
出来るっていうわけじゃなさそうだな。


まぁピンコネも解ったことだし、１，２個手元に
置いておこうかな？

ちなみに、HM534251のデータシートもここに
ありました。
http://www.ic-on-line.cn/IOL_hm534251bseries/PdfView/208208.htm
やっぱりＤＲＡＭですね。（あたりまえですが）

続： マイコンのビデオ表示に回転機能付けられないかな？

マイコンでビデオ表示をする時に、ビットマップを
回転表示できないかな？というお話の続き。

ビデオ表示を回転するって言うのを言葉で書いても
イマイチなので、マンガにしてみます。こんなかんじ。


青いフレームは、マイコン上のＲＡＭ（ＳＲＡＭ）に
展開されたイメージ全体だと思ってください。テレビに
表示されている部分だけのことではなく、ＲＡＭに
展開した全体です。例のＡＶＧＡでいうと、スクロールして
マリオが移動できる背景領域の全体と言う意味です。

で、ＡＶＧＡの場合はこの図で言う点線部分を切り出して
表示しているイメージ。
ＲＡＭから読み出したイメージを横に連ねた感じでピンに
出力していくと、普通にビデオ表示が出来るわけです。

で、回転というのは、この切り出し方がちょっと違います。

橙色の四角のように切り出す画面の角度が回転している
わけです。この角度を適宜指定することで、表示中に
自由自在にグルグル回すことが出来るわけです。

で、処理内容ですが、普通のビデオ表示との唯一の
違いは走査線に沿ったデータの取り出し方。その１点だけ。

具体的には三角関数と行列変換を使って緑色の点の座標を
求めておいて、そこから緑色の線に沿って、ビットイメージを
読み出してはピン出力、読み出してはピン出力…と繰り返すだけ。

処理内容自体はこの通り簡単で、使う計算式も簡単。

ただ、マトモにやるとMEGA88、MEGA168程度では
歯が立たないので、処理を端折って端折って、
端折りまくってクロック数を省きます。

まずｓｉｎ、ｃｏｓ計算はテーブル化しておき、
走査線の先頭で緑色の座標を1回だけサクッと
計算しておきます。（すべての点について計算すると
とてもじゃないけど時間がかかりすぎるので）

で、その後の緑色の座標は、「傾き」だけ最初に計算
しておいて、あとは走査線1本で表示するドットの数
だけ傾きを足し算していくという寸法。緑色の反対端
まで走査線１本分繰り返していきます。

これによって、面倒な行列計算、三角関数計算は1回だけ
に済ませ、あとは単純な足し算の繰り返しです。
1ドット分の座標を求めるのに最低で4クロック。
（整数部、小数部をそれぞれ８ビットと仮定）

あとは求まった座標を元にビットマップデータを読み出す
訳ですが、ここがなかなか厳しい。

ＡＶＧＡのように、真横にビットマップを読み出すので
あれば8ドット単位で処理が出来るんですが、
斜めに走査する場合は1ドット単位でビットマップから
読み出し→切り出しをしないといけなくなっちゃう。

で、1ドット分を切り出すのにどのくらいのクロック数が
要るのかということを考えるのが昨晩の課題でした。
ザッと大まかに数えてみました。

（１）ケース１
　　…ビットイメージをそのままベタイメージで
　　　ＳＲＡＭに展開した場合（デコード不要）

　　２０クロック少々？

（２）ケース２
　　…ＳＲＡＭ上にはキャラクターコードだけを
　　　持っておいて、ＲＯＭにビットイメージを
　　　別途もつ場合（デコード要）

　　３０クロック程度？

まぁ、大雑把な計算なのですが、コレを前提にして
走査線1本分の間に何ドット表示可能かを考えて
みます。

ちなみに、２０Ｍｈｚだと６４μ秒の間に自由に
使えるのは約１０００クロック程度。
とすると、割り算し…

（１）　→　５０ドット
（２）　→　３０ドット

うーん。やっぱり１ドット単位でデコードするって
いうのはやっぱクロック数食うなぁ。しかも実際に
処理組んだらもう少し増える可能性もあるし…

もう少しデコードを端折って、簡単にできないものかなぁ？
若干なら出来そうな気がするけど、劇的に減らすのは
難しいな…。

この程度のドット数では、表現力が低すぎるモンなぁ…
特に（１）はビットマップをバリバリ消費するので、
スクロール可能な領域が狭すぎ。

「回りました！」だけではつまんないモンなぁ。
ある程度表現力がないとなぁ…。
作ってみようって気がおこらない…

atom登載ボードが欲しいこの頃

この間サブＰＣのマザボが不調になったので、
新しいボードを買ってきたばかりなのですが、
メインで使っているＰＣもファンがうるさい
ので、ずっと何とかしたいと思っていたところ。

atom登載のボードD945GCLF2が安く売ってるし、
後はメモリを買い足すだけで済むので、
出費としてはまさに最低限で済んじゃうのが
いいところ。


ちなみに気になるのがスペック。

というわけでネットでベンチマーク結果を
検索してみました。

今使っているセレロンＤ２．４Ｇｈｚの結果と
皆さんのD945GCLF2のベンチ結果と比較すると…

整数演算、小数演算はどんぐりの背比べ程度。
（そうかぁ。もはや２．４Ｇｈｚと言っても
　世代が古くなっちゃうともう実用ギリギリの
　遅さなんだな…）

メモリの読み書きは現行マシンの方が速いな。

あとグラフィックはさすがに現行マシンの方が
勝ってるみたい。atomのチップセットはだいたい
貧相だからな…。ベンチの数値では数倍の能力差。
が、どうせゲームはやらないので３Ｄ性能は
実はどうでもよし。

というわけで、普段使う機能で比べたら、今の
マシンと大差無いってことだな。うんうん。

そう、D945GCLF2はビデオ出力機能があるんだよな。
ＰＣ画面で操作した内容をビデオに撮っておいたり
するのにも使えちゃう。いい感じ。

どうしたものやら…。
スペック自体はほとんど変わんないんだよな…。
冬だから「排熱が暑い」とか考える必要もないし。
うるさいか静かか、それだけの違いなんだなぁ。