(ホントは７４ＨＣ、ＣＭＯＳなんだけど…）
［第４１０回］
●ＰＩＣ１８Ｆ４５５０のメモリアクセスについて説明するつもりでしたが…
本日は大晦日です。
本当にあっという間の１年でした。
２００９年も本日限り。
で、メモリアクセスについて、本年の締めくくりとして、ばたばたっと片付けてしまって、ではよいお年をお迎えくださいませ、という調子でやっつけてしまおうと思ったのですけれど…。
前回、前々回を読み直してみますと、いやあ、そういうわけにはいかんなあ、という感じなのですねえ。
ここで、ばたばたっと片付けてしまったら、まるでよくある類の、読んだけど結局何も身につかないという「技術入門書」と同じじゃないの。
前回は、「こんなもの読む必要はありません」のひとことで片付けてしまいましたけれど、そういうことでは、いかんでしょう。
やっぱりまじめな読者諸氏におかれましては、「読むな」と言われてもやっぱり読みたい、読んでみよう、と思われるのが人情の常。
で、読んでみようとするけれど、たいがいは「うう。わからん」ということになります。
そうすると、欲求不満になってしまいますので、そういう精神状態で新年を迎えていただくのはよろしくありません。
くそみそにけなしていましたけれど、よくよく落ち着いてＰＩＣ１８Ｆ４５５０のＤａｔａ Ｓｈｅｅｔを読み直してみますと、それほどけなさなくてはならないほどひどいシステムではないではないか、いや、逆になかなかよく考えてあるなあ、と思い始めたところでもあります。
そうしますと、ここはまたまた道草ついでに、ひとつ徹底的にカイボーしてしまおうではないか、ということになってしまうのですよねえ（もう藪の中というよりも、富士の樹海みたいなもので、果たして生きているうちに抜け出せますかどうか）。
こうなると、もう大晦日もお正月もない、俗世を離れて、技術三昧でまいりましょう。
なのですけれど、そうは言ったものの、そこは小人の悲しさ、浮世を離脱してしまうことはとてもかないまへん（そんなことをするとほんとうに死んでしまいまする）。
で、あらためて腰を据えてかかりたいと思い直したメモリアクセスについては、次回以降（つまり年が明けてからということであります）に致しまして、今回は本年の締めくくりといたしまして（どこが締めくくりじゃあ）、別のテーマでお話をいたします。
●Ｃ ｏｒ アセンブラ ？ ｉｎ ＰＩＣ
口は災いの門とか申しまして、言わなくてもいいことを不用意に発言したりするものですから、あとでフォローを余儀なくされることになってしまいます。
「ＰＩＣでＣなどを使うお方の気が知れない」などという過激な発言を続けてまいりますと、「いまどきこんな時代錯誤にはつきあっておれん」と思われて、ついには貴重な読者様を失ってしまうことにもなりかねません。
んでも、事実は事実として、伝えなければいけませぬ。
そうなると、要はフォローです。
言いっぱなしは一番いけませぬ。
●そもそもＣとは一体なにものぞ？
そこんところをわかっていらっしゃらないでＣをお使いの方が世間には余りに多いように思われます。
ああ。ＣでもＣ＋＋でもＶｉｓｕａｌＣ＋＋でも同じです。
面倒なのでＣの眷属一族郎党を全部ひっくるめて、Ｃと称します。
ことにＣでＰＩＣプログラムを解説していらっしゃる方々などは、本当にわかっていらっしゃるのかなあ、と疑問に思ってしまいます。
ああ。Ｍｉｃｒｏｃｈｉｐ社の面々もおんなじかあ。いや、こりゃ弱ったなぁ。引っ込みがつかんではないか。
でもでもこれだけ分厚いＤａｔａ Ｓｈｅｅｔを作成していらっしゃるところを見ますと、本当はＭｉｃｒｏｃｈｉｐ社もそこんところは十分に承知の上、と推測しております。今のところは。
でも多少危険な兆候は見受けられます。
Ｍｉｃｒｏｃｈｉｐ社供給のＰＩＣのサンプルプログラムがみごとにＣばっかりになっておりまする。
こうなるってえと、詳細にわたって解説しておりましたＰＩＣのＤａｔａ Ｓｈｅｅｔが全て消え去って、Ｃでの記述に統一されてしまう日もそう遠くではないのかも、と危惧の念を抱かざるをえません。
何が間違っているのか、何が危険なのか。
それについて、説明をいたします。
●Ｃは高級言語です
そもそもＣとは一体なにものぞ。
Ｃとは高級言語でありまする。
高級言語とは、通常低次の言語である機械語（アセンブラを含む）に対比して用いられる言葉であります。
んなことは知ってるよぉ。
あ。まあまあ。落ち着いて。
ん？知っていらっしゃる？
本当に？
では機械語に対して高級言語という場合そもそもどこがどう違うのか。
なぜに機械語ではなくて、高級言語なのか？
そこのところからの理解が肝要でありまする。
機械語が面倒極まりないことは周知のことであります。
そのために、アセンブラが開発されました。
それでいいじゃないの？
それでよくはなかったのです。
昔のコンピュータはみごとにハードに依存していました（はずです）。
●機械語は？
たとえば、ＩＢＭのコンピュータで開発した機械語（アセンブラ）のプログラムは、他社のコンピュータでは実行できません。
それは当たり前のことです。
それだけではなくて、同じＩＢＭのコンピュータの間でも、技術の進歩にしたがって、新しい回路を採用すると、以前の回路で通っていた機械語のプログラムが実行できなくなってしまいます。
互換性を維持しようとすると、いつまても旧式の回路をひきずることになってしまいます。
ちなみに、一世を風靡したＮＥＣのＰＣ９８０１シリーズは、初期の８０８６ＣＰＵのＰＣ９８０１との機械語レベルでの完全互換を維持するために、その後の２８６、３８６ＣＰＵを搭載したシリーズにおいても、ボード内に
［２０１１．５．４注記］当記事をお読みいただいた方からメールをいただきました。
２８６、３８６を搭載した９８０１Ｖシリーズに実装していたのは８０８６ではなくてＶ３０です、とのご指摘をいただきました。
Ｖ３０はＮＥＣが開発した８０８６上位互換の１６ｂｉｔＣＭＯＳ・ＣＰＵです。
ご指摘いただき有難うございました。
ここに謹んで訂正させていただきます。（注記ここまで）
さすが、ＮＥＣであります。それでこそ、あっぱれ日の丸メーカーであります。
今のＮＥＣはどうだか知りませんけれど。
ほんと、Ｍｉ○ｓｏｆｔのビ○イツ君には、カネ儲けばっかりに専念しないで、ＮＥＣのツメのアカでも煎じて飲め、と言ってやりたいですぅ。
ああ。また脱線してしまいました。
本題に戻ります。
それはしかし、大変なことであります。
いまやソフトウェアを抜きにしてはコンピュータは全く成り立ちません。ソフトウェアの重要性は日々増大してきています。
そのソフトウェアが初期のコンピュータのように、個々のマシンの設計に深く依存しているということでは、応用技術の開発に致命的な影響を与えてしまいます。
●高級言語とは？
もうおわかりいただけたと思います。
高級言語はそういうハードウェアとのしがらみを断つために考え出された言語だったのです（と思いますよ）。
したがって優れて洗練された高級言語はハードウェアを選ばない。
ソースプログラムレベルでは、どういうハードウェアの上でも実行できる互換性を維持していることが、その存在の基本的な条件であります（ここんとこ、非常に重要ですから、しっかりマークしておいてくださいませ）。
このルールによって、あらゆるソフトウェアがハードウェアにかかわることなく、完全な互換性を獲得したことになります（これはいうならばバーチャルなシステムであります）。
そこで次に必要不可欠になってきますのが、そのソースプログラムを個々のマシンの機械語に正しく翻訳してくれるコンパイラです。
そうすると、せっかく苦労して作り上げた高級言語なのだけれども、今度は新しいマシンを開発するたびに、コンパイラ（つまり機械語への翻訳プログラム）も個々に用意しなければならない、ということになります。
それを助けるために、ＯＳ（オペレーションシステム）なるものも考え出されたのでありますけれど、基本的に、コンパイラが機械語に翻訳しなければならない、という役目がＯＳによって変わったわけではありません。
しかしＯＳについては余談の余談になってしまいますから、ここでは触れません。
ともかく、高級言語というものは、要するに、ハードウェアのしがらみから完全に開放されるためのものである、ということについては、どちら様にも異存はなかろうかと思います。
でも、実際のところ、Ｃをお使いの皆様方は、そこんところをついうっかりと失念なさっているのでは、と思います。
●それではＰＩＣのプログラムをＣで書くということは…
よろしいでしょうか。
Ｃはハードウェアに依存しない高級言語である。
よろしいですね。
では、ここで問題です。
ＰＩＣのプログラムをハードウェアに依存しないで、書くことが可能でしょうか？
いや、たとえ可能だとしても、そんなプログラムになんの意味があるのでしょうか？
だって、ハードに依存しないことが建前の言語を使って、どうやってＰＩＣの何番ピンの、ポート何とかのビットからＨ信号を出力せよ、とか、何番ピンから信号を入力せよ、とかというプログラムを書くのでしょう？
私の知る限りでは、Ｃ（Ｃ＋＋でもよろしい）のｓｔｄｉｏでもなんでもよろしいが（スタンダードＩＯと言っているにもかかわらず）、マシンに直結する、ＩＮ、ＯＵＴ命令は存在しないはずなのですよねえ。
そしたらＰＩＣのプログラムなど、書けるはずはないじゃありませんか。
どだい、やろうとしていることが無理なのですよ。
もう完全に分裂しておりまする。
Ｍｉｃｒｏｃｈｉｐ社もそこんところはわかっていて、だからＰＩＣのためだけの（はやいはなしがそこんとこだけはめちゃめちゃ互換性無視のムリムリの）Ｃコンパイラを用意しています。
んじゃあ、どこがＣなのかといいますと、Ｃの機能にＰＯＲＴＢだとか、ＴＲＩＳＢだとかの機能名が扱えるようになって、Ｃコンパイラですう、ということのようなのですよねえ。
そうすると、それを使えばＰＩＣについて知らなくてもプログラムを書くことができるようになるのか、というと、そういうわけにはいかんでしょうよ。
そもそもＰＯＲＴＢというものが何物で、そのビットがＰＩＣなんたらの何番ピンにつながっているのか、というような基本的な情報は知らないで済ますわけにはいかないでしょう。
いかないけれども、ひょっとすると、そこんところも、ヘッダーファイルにしてインクルードしてしまって、たとえばｏｕｔｐｂ１（ｎ）をＣＡＬＬするとＰＯＲＴＢのｎビットから１を出力しますよ、ｏｕｔｐｂ０（ｎ）をＣＡＬＬすると０を出力しますよ、というふうにしてしまいますと、これはもうかなりバーチャルに近くなってきます。
んでも、そういうことでよいのか？本当にそれでいいのか？
と、どうしても考えてしまうのですよね。
え。皆様はどうお思いになられますでしょうか。
●ＰＩＣにはアセンブラがあるじゃありませんか
そんな面倒なことをしなくても、ＰＩＣアセンブラで
ｂｓｆ ＰＯＲＴＢ，ｎ
と書けば済むじゃありませんか。
オーバーヘッドなど気にすることは全くありません。
実クロックで実行してくれます。
ああ。そうです。
高級言語のもつ致命的な欠点として、オーバーヘッドがあります。
コンパイラはそれをなんとか回避しようと努力しますけれど、所詮機械語（＝アセンブラ）の敵ではありません。
コンピュータの世界ではオーバーヘッドとは、ある処理をするのにかかってしまう処理時間（とりわけそれがかかり過ぎるときに用いる）のことをいいます。
でも、それってＰＩＣのプログラムでは致命的なのではありませんか？
ま。そのことについては、あとでまた説明することにいたしましょう。
たとえばＰＩＣのＣ１８コンパイラを使うことにして、通常のＣコンパイラのみの知識しか持っていない方が、Ｃ１８コンパイラを使うとしたら、最初にまず、ＣＯＮＦＩＧの設定だとか、ＰＯＲＴの設定だとかをどうすればいいの？というところでつかえてしまうはずです。
だって、それは一般のＣの関与しない（すべきではない）事柄なのですから、知らないのが当たり前です。
そうすると、Ｃ１８コンパイラの説明書を読んで、関数を探すことになります。
ひょっとすると、メインの命令部分には書いてなくて、インクルードするヘッダーファイルにあったりして…。
なんで、そういう不毛としかいいようのない努力をせにゃあならんのか？
たとえばさきほどの
ｂｓｆ ＰＯＲＴＢ，ｎ
のｂｓｆという命令は、ＰＩＣのＤａｔａ ＳｈｅｅｔのＩｎｓｔｒｕｃｔｉｏｎ Ｓｅｔを見ればちゃんと書いてあります。
［出典］Ｍｉｃｒｏｃｈｉｐ社 ＰＩＣ１６Ｆ８８Ｄａｔａ Ｓｈｅｅｔ
簡潔にして明快、もうそのまんまじゃありませんか。
なんでこういうすぐに使える簡単なものを使おうとしないで、わざわざ回り道をして、Ｃなんぞを使おうとするのでしょう？
しかも設定ファイルだとか、ヘッダーファイルだとか、前準備が大変なものですから、結局のところ深く踏み込もうとはしないで、どなたかがお作りになったサンプルプログラムをいただいて、そのなかで関数のパラメータだけをちょこちょこっと直して、それで、
できた、できた、先生、ＰＩＣのプログラムができました。
って、それって違うでしょ。
何にもわかってないのと違います？
せっかくＰＩＣという、手軽にハードとソフトの両方が体験できる素材がありながら、なんでわざわざＣなどを使ってバーチャルにしてしまうのか、私にはとんと合点がいきませんです。
●アセンブラは難しいか？
だって、アセンブラは難しいから…。
そんなことはないです。
それは一般に流布されたデマにすぎませんです。
アセンブラくらい簡単なものはありませんですよお。
あ。ま。それはちょいとオーバートークでした。
今後の「舌禍」を避けるためにも、一応、「ＰＩＣに限っては」つう但し書きをつけておくことにいたします。
どのくらい、ＰＩＣアセンブラが簡単なのか、例で示してみることにいたします。
例題です。
ＰＯＲＴＢのビット０から最短の幅のパルスを出力しなさい。
これはよくあるシチュエーションです。
書き込みパルスでも制御パルスでもなんでもいいですけれども、ある周波数のパルスを出力したい、というのは出力制御の基本中の基本です。
ＭＹＣＰＵ８０のＴＫ８０応用プログラムでも、出力パルスの周波数を変えることで、音階を出力するというのがありましたですねえ。
さて、Ｃならどうやりますでしょう？
私は知りません。
んなもの考える気にもなりませんから。
●ＰＩＣのサンプルプログラムです
ＰＩＣは何でもよいのですが、ＰＩＣ１６Ｆ８８を使ってみることにしましょう。
ＰＩＣ１６Ｆ８８は内部クロック発振モードという便利な機能があって、外にクリスタルを取りつけなくても、ｃｏｎｆｉｇの設定でＭａｘ８ＭＨｚのクロックを自前で供給できますから、回路が実に簡単になります。
こんな感じです。
さすがにこれはちょいと乱暴ですけれど、とりあえず動きます。
ねえ。ハードはこんなに簡単ですのに、このハードを動かすのに、Ｃコンパイラを使うんですかあ。
アセンブラを使いましょうよ。
で。アセンブラのソースプログラムです。
［注記］このプログラムにはミスがあります（［第４１６回］参照）。
ＣＯＮＦＩＧのところはおまじないみたいなものです。
でも詳細を知りたければ、ＰＩＣ１６Ｆ８８Ｄａｔａ Ｓｈｅｅｔにはちゃんと書いてあります。
［出典］Ｍｉｃｒｏｃｈｉｐ社ＰＩＣ１６Ｆ８８Ｄａｔａ Ｓｈｅｅｔ
各設定値の意味、詳細についてもＤａｔａ Ｓｈｅｅｔに説明があります（巻末の索引で記載ページがわかります）。
アセンブラのＣｏｎｆｉｇの表記にはちょいとクセがありますが、たとえば＿ＣＰ＿ＯＦＦとか＿ＬＶＰ＿ＯＦＦというような表記は、ＭＰＬＡＢをダウンロードするとついてくる、ｉｎｆファイル（上のプログラム例ではｐ１６ｆ８８．ｉｎｆ）を読めば見当がつきます。
こういうことはアセンブラを使うから見えてくることで、Ｃコンパイラではよくわからない部分でしょう。
さて、アセンブラのソースリストの、ｂｓｆ ＳＴＡＴＵＳ，５からｂｃｆ ＳＴＡＴＵＳ，５までのところは、ポートの向き（ＩＮかＯＵＴか）とかＣＰＵクロックの設定などをしているところで、ＰＩＣを扱うからには、Ｃであろうとなかろうと、ここは避けては通れないところですし、その内容についても、当然知っていなくてはなりません。
で、ここも、Ｃを通じて理解するのが簡単か、それともＤａｔａ Ｓｈｅｅｔから直接理解するのが簡単か、ということですけれど、いかがでしょうか？
たとえば特殊レジスタＳＴＡＴＵＳのビット５を１にすれば、メモリバンク１が選択され、それを０にすればバンク０が選択される、ということもＤａｔａ Ｓｈｅｅｔを読めばわかるのです。
またＯＳＣＣＯＮに６Ｃを与えれば、内部発振クロックが４ＭＨｚになることも、Ｄａｔａ Ｓｈｅｅｔを読めばわかりますし、ＴＲＩＳＢの’０’を書き込んだビットに対応するＰＯＲＴＢのビットの向きが出力になるということも、それから、ＯＳＣＣＯＮやＴＲＩＳＢはバンク１にあって、ＰＯＲＴＢはバンク０にあるということも、全部Ｄａｔａ Ｓｈｅｅｔを読めばわかるのです。
ところでＣコンパイラだと、いったいどこを読んだらそれらを理解することができるのでしょうか？
よくわからんから、結局サンプルプログラムをそのままコンパイルすることになってしまうのではありませんか？
それじゃあ何もわからんのと同じではありませんか？
私は、そういうことが言いたいのですよ。
さて、プログラムの実行部分です。
ｌｏｏｐからｇｏｔｏ ｌｏｏｐまでを繰り返しているだけです。
たったこれだけです。
ＰＩＣのプログラムをご存知ではない方でも、８０８０やＺ８０の機械語（アセンブラ）がおわかりになる方でしたら、なんとなく読めるような気がしませんか？
その通り。読めるのですよ。
ＰＩＣのアセンブラはちょいとクセがあって評判は余りよろしくないようですけれど、それでもＣよりは相当マシだと思いますよ、私は。
ｍｏｖｆ ＰＯＲＴＢ，ｗはＰＯＲＴＢをワーキングレジスタｗにｍｏｖｅせよという命令ですし、ｘｏｒｌｗ ０１は、そのｗの値と０１のｘｏｒを計算せよという命令ですし、ｍｏｖｗｆ ＰＯＲＴＢはｗレジスタの値をＰＯＴＢにｍｏｖｅせよ、という命令です。
ほらね。そのまんまじゃありませんか。
実に簡単でしょう。
それだけのプログラムで動いてしまうのですよ。
この通りです。
上のプログラムを実行中の写真です。
ジャノ目基板は裏側しか見えませんが、ＰＩＣ１６Ｆ８８以外には抵抗とコンデンサしかありません。
ミノムシクリップで電源を供給しています。
ミニクリップはオシロのプローブにつないでいます。
●アセンブラならパルス幅が計算できるのです
これはもう、Ｃでは逆立ちしたって実現できない機能です。
だれかが作ったタイマールーチンなんてものをさがしてきてインクルードすればアバウトでしたらできないことはないでしょうけれど、これだけ正確にしかも高い周波数を得ることは、Ｃにはできない芸当でしょう。
今回のプログラム例ではＰＩＣのクロックはたかだか４ＭＨｚです。
ＰＩＣの命令サイクルはＣＰＵクロックの１／４です。
つまりＣＰＵクロックが４ＭＨｚの場合、１命令は１μｓ単位で実行されます。
たいていの命令は１μｓで実行されますが、２μｓかかる命令もあります。
それでいて、オシロの波形からわかりますように、Ｈ＝５μＳ、Ｌ＝５μＳですから１００ＫＨｚの出力が得られているのです。
Ｈ出力もＬ出力も、わずか５命令サイクルで実行されているのです。
しかもＣと違って、アセンブラなら、プログラムを書いたときから、そのパルス幅は約束されているのです。
ｍｏｖｆ、ｘｏｒｌｗ、ｍｏｖｗｆは１命令サイクルで実行され、ｇｏｔｏは２命令サイクルで実行されます。ですから１回の出力あたり５μｓなのです。
いかがでしたでしょうか？
ＰＩＣならアセンブラ、ということに納得いただけましたでしょうか。
●ＭＰＬＡＢのバグ？
ところで、アセンブラをおすすめしておきながら、何なのですけれど、ＰＩＣ１６Ｆ８８についてはＭＰＬＡＢにバグがあるようです。
私は普段はＭＰＬＡＢ ＩＤＥ ｖ７．３１を使っているのですが、そこで気がついたバグは、念のため確認してみたところ ｖ８．４でも同じでした。
ＣｏｎｆｉｇｕｒｅのＳｅｌｅｃｔ ＤｅｖｉｃｅでＰＩＣ１６Ｆ８８を選んだうえで、ＰＩＣ１６Ｆ８８のソースプログラム（上のプログラム例のような）をアセンブルすると、どういうわけか、ｃｏｎｆｉｇが間違っている、というエラーメッセージがでてしまいます。
デバイスを（ウソですけれど）ＰＩＣ１６Ｆ８４とかＰＩＣ１６Ｆ６２８にして、同じプログラムをアセンブルすると、「デバイスの設定が違ってるじゃないの」という警告メッセージが出ますけれど、正しく終了してＨＥＸファイルが作成されます。
あ。私は面倒なことが嫌いですので、Ｐｒｏｊｅｃｔの設定などは全部無視して、いきなりソースプログラムをＯｐｅｎして（またはいきなりＮｅｗ ＦｉｌｅをＯｐｅｎして、そこにソースプログラムを書いてしまって）、Ｐｒｏｊｅｃｔ→ＱｕｉｃｋＢｕｉｌｄで簡単一発アセンブルを済ませてしまっています。
そのことと、バグとは多分関係ないとは思いますが。
［２０１０．４．２７注記］
バグではありませんでした。間違っていたのは、この私のほうでした。
ＰＩＣ１６Ｆ８８のＣＯＮＦＩＧの書き方が悪かったのです。
下のＰＩＣプログラマで表示されたメッセージも、そのＣＯＮＦＩＧの書き方に関係していました。
詳しくは［第４８８回］をご参照ください。
［注記ここまで］
●なんとＰＩＣプログラマでもバグが？
秋月のＰＩＣプログラマで、今回のテストプログラムをＰＩＣ１６Ｆ８８に書き込もうとすると、気持ちの悪い警告メッセージが出ます。
こんな表示が出ます。
アセンブル後のリストで確認してみましたが、Ｃｏｎｆｉｇの機械語コードに間違いはありませんし、それはここで表示されている３Ｆ７８に間違いありません（これはｄｅｆａｕｌｔではなくて、あくまで上のテストプログラムのＣＯＮＦＩＧで設定した値です）。
ここは無視して、書き込みをしてしまうと、何事も無くＯＫになります。
もちろん正しく実行できることは、さきほどお見せした写真の通りです。
●ＰＩＣ１６Ｆ８８のＰＯＲＴＢについて
今回のテストプログラムを書いて試してみる過程で気がついたことがあります。
上の方でお見せした回路図で、ＲＢ０端子に１０ＫΩのプルアップ抵抗がつけてあります。
これがないと出力が確認できません。
ＰＩＣ１６Ｆ８８のＤａｔａ ＳｈｅｅｔのＰＯＲＴＢの説明では、どこにもオープンドレインである、とは書いてありません。
ただＰＯＲＴＢのブロック図をみると、いろいろな出力や入力やらが１つのピンに複合されていて、その回路の動作によってはオープンドレインになってしまうかも、と疑う余地は十分にあります。
このあたりも、ことＰＩＣ１６Ｆ８８については、かなり確認して使わなければ期待通りには動いてくれない、という可能性があるように思えます。
クリスタルなしで済むというあたりは、なかなかに捨てがたいＩＣではあるのですが…。
ということで、本年はこれで終わりです。
今年一年、お付き合いいただき有難うございました。
来年も倍旧のお引き立てをお願いいたします。
私といたしましても、さすがに新年正月くらいはちょいとのんびりしたいと思いますので（そんなことを言いながら、きっと元旦から、ＵＳＢの追及解明などをごそごそやったりして…）、新年の更新開始は正月明けから、ということになると思います。
皆様。よいお年をお迎えくださいませ。
２００９．１２．３１ｕｐｌｏａｄ
２０１０．４．２７追記
２０１１．５．４注記
前へ
次へ
ホームページトップへ戻る