MSX DeuxLaque | Reloaded

PASOPIAの謎 再び

ううう、夏風邪をこじらせてしまいました。

虚弱体質には自信があるところ、今週は月曜から三日間病院巡りをして、すっかり体調を崩しました。病院は身体に悪いです。体調のいいときに行かないといけません。下を向くと水洟がポタポタ落ちるのでハンダづけもできません。

 

とか言いながら、東芝パソピアIQのRGB出力をなんとかせにゃとWebを見てました。すると、おお？　外国でも関心が持たれていたようで、そのページは「HX-10DPNは、特定の13ピンのコネクタを持っています。 それは、今日では見つけることはおそらく不可能です。」と、フランス語で始まっていました。

MSX Village

http://www.msxvillage.fr/wiki/wiki.php?title=connecteur-rvb-du-toshiba-hx-10dpn

 

写真と端子表を引用。

http://www.msxvillage.fr/upload/hx_10dpn_connector.jpg 

 

Description des broches

Broche	Nom	Description
1	GND	Masse (à relier aux masses de la Péritel)
2	VIDEO OUT
3	R	Composante rouge (à relier à la broche 15 de la Péritel)
4	G	Composante verte (à relier à la broche 11 de la Péritel)
5	B	Composante bleue (à relier à la broche 7 de la Péritel)
6	YS	Commutation rapide (à relier à la broche 16 de la Péritel)
7	AUDIO L	Audio (à relier à la broche 3 de la Péritel)
8	AUDIO R	Audio (à relier à la broche 1 de la Péritel)
9	?
10	VIDEO IN
11	AV	Commutation lente (à relier à la broche 8 de la Péritel)
12	?
13	?

うーん？11ピンはNC（未結線）のはずなんだがなあ、と思ってソースを見ると、

Source :

http://geocities.yahoo.co.jp/gl/dr_kikkie/view/20070603
http://geocities.yahoo.co.jp/gl/dr_kikkie/view/20070601

わはは、ワシの古いブログや〜ｗｗｗｗ

表中の「？」は「未結線」という漢字が分からんかったのでしょうな。

 

---

閑話休題。気を取り直して「しおんパパのひみつきち」を拝見。

2014/04/11付けで「東芝MSXのRGB出力ピンアサイン」という記事がありました。今年4月というと比較的最近ですな。

http://sions-papa.blogspot.jp/2014/04/msx.html

 

プラグとRGB21ピンプラグとの結線状態について、写真をお借りしちゃいました。

 

フランス語の表とRGB21ピンの写真に付された数字を見比べるのも面倒かと思いますので、再度、整理しておきます。RGB21ピンの写真内の数字は、パソピアIQ側の端子番号、（）内はRGB21ピン端子番号、最後にRGB21ピン端子で定義された信号の意味です。

 

 ４（19）RGBのうちG（緑）

 １（17）RGBのGND（緑）

 ３（15）RGBのうちR（赤）

 1 （13）RGBのGND（赤）

10（11）AVコントロール信号（AV）

 ２（ 9）コンポジットビデオ信号入力

 ８（ ５）音声出力（右）

 ７（ １）音声出力（左）

 ５（20）RGBのうちB（青）

 １（18）RGBのGND（青）

 ６（16）RGB映像切替信号（Ys）

 

ウィキペディアからも一部引用しちゃえ。

http://ja.wikipedia.org/wiki/RGB21%E3%83%94%E3%83%B3

 

端子配列

 

http://upload.wikimedia.org/wikipedia/commons/1/16/Scart_pin_layout.png

 

レセプタクル、またはコネクタを半田面から見た図となる。なお、本来のSCART端子とは端子配列（用法）が異なるので注意。

1. 音声出力（左）
2. 音声入力（左）
3. 音声出力グランド
4. 音声入力グランド
5. 音声出力（右）
6. 音声入力（右）
7. コンポジット・ビデオ信号入力グランド
8. コンポジット・ビデオ信号出力グランド
9. コンポジット・ビデオ信号入力
10. コンポジット・ビデオ信号出力
11. AVコントロール信号 (AV)
12. RGB映像マスク信号 (Ym)
13. RGB映像信号（赤）グランド
14. Ym・Ysグランド
15. RGB映像信号（赤）入力
16. RGB映像切替信号 (Ys)
17. RGB映像信号（緑）グランド
18. RGB映像信号（青）グランド
19. RGB映像信号（緑）入力
20. RGB映像信号（青）入力
21. フレームグランド（金属フレーム）

• 使わない端子はNC（無接続）とすることが可能。
• 信号名と対のグランドは、その信号と同軸または「より線」にしてインピーダンス整合を取ることが望ましい。
• コンポジット・ビデオ信号は、通常のビデオ端子（黄）と同じ。復合同期信号が重畳されており、0.7Vp-p、75Ω整合。
• RGB映像（赤、緑、青）は正極アナログ信号、0.7Vp-p、75Ω整合。
• 音声信号は0.4Vrms、インピーダンスは入力47kΩ、出力10kΩ。
• YsはHレベルでRGBから入力、Lレベルでコンポジットから入力。Lレベルが0 - 0.4VDC、Hレベルが1.0 - 3.0VDC、75Ω整合。
• YmはHレベルでコンポジットがマスクされる。レベル、インピーダンスはYsと同じ。
• AVは入力切替信号、Hレベルでこの端子からの入力が有効となる。TTLレベル、22kΩ整合。

こうして見ると、フランス人が参照したぼくの記事はパソピアIQの10ピンを「VIDEO IN」としているけれども正しくは「AVコントロール信号」のようです。また、11ピンは「（未結線）」でした。お詫びして訂正します。今ごろ〜ｗｗｗ

 

で、ここで疑問がフツフツと。

RGB21ピン端子を備えているような高級機？ならともかく、パソピアIQの13ピン端子（実質9ピン）で、2ピンの「VIDEO IN」てな豪華仕様はアリか？これは「VIDEO OUT」の間違いではないか？　とすれば、RGB21ピンの9ピンではなく10ピンに結線しないといけないのではないのか？

 

待て待て待て。ウィキペディアの端子の定義もおかしくないか？

音声とコンポジット・ビデオ信号については入力と出力がある。しかし、RGB映像信号については入力ばかりじゃないか（15：R、19：G、20：B）。

ひょっとして、ディスプレイ側から見た定義だとすれば、パソピアIQの2ピンは「VIDEO OUT」であってRGB21ピンの9ピンに繋ぐのが正しい。

ばかりではなく、音声についてもパソピアIQの7ピン（音声左）はRGB21ピンの2ピンに、同8ピン（音声右）はRGB21ピンの6ピンに繋ぐのが正しいのではないか？

AVコントロール信号というのがイマイチ理解できていないが、これはHレベルにしないとディスプレイ側に入力全体が受け付けられなくなる？　MSXとディスプレイの両方で5V出すと危ないぞ？

 

あかん、熱が出てきた。熱は最初から出てるけど。

それにしてもワロタ。ウィキペディアもぼくのブログから引用してるやん！

また、MSXの一部の機種ではRGB出力端子がDIN8ピンでない場合があり、ケーブルが転用不可能な事も考えられる[4]。

脚注　4.^ PASOPIAの謎　←当然、リンク切れｗ

あれこれなうｗ

---

■DTMFデコーダー・ハード

DTMFデコーダーのハードを収めるケースを物色中。候補は下のふたつ。いずれも百均アンプで、左側が旧機種。デザインがダサいでしょ？ｗ　右側が現行機種。いずれにせよ電源はMSX本体から取るので、単四電池2本分のスペースが空く。そこに右上のデコーダーチップを収めるつもり。

スイッチ付VRのスイッチ部分が無駄になるが、ライン出力の場合はアンプを生かし、イヤフォンジャック出力の場合はアンプを迂回するスイッチに転用するつもり。

受信端子としてRCA端子をネジ止めのつもり。MSXとの接続用のDサブ9ピン端子を切らしていたので到着待ち。電源を含めて7線をところどころ結束するつもり。10cmもあればいいかな？

つもりつもりが、積もりつもっとるな。

---

■DTMFエンコーダー・ソフト

まだ考えちう。考えているのは2点。

(1) 出力する文字は「0123456789ABCDEF」に限られるのだから、8ビットを4ビットずつの2文字にしてデコーダーの負担を増やさなくとも、素直に「0123456789ABCDEF」とデコードできる形で出力してやればいいじゃないか。

(2) ウエイトをマシンサイクルに依存している。これではturboRに適用できない。MSX-Datapack Vol.3には「高速モード時は専用システムクロックを参照せよ」旨が書いてあるが邪魔臭い。turboRかどうか判断して、適宜Z80モードに切り替えることにする。BIOSが処理するとはいえ、スロット間コールは好きじゃないんだけどなあ。

---

■蛇足１

にゃごすさん主宰のWEB版「MSX2テクニカルハンドブック」は素晴らしい。が、ちょこっと手を加えたい部分もある。

カートリッジ用のワークエリアについて、

(1)カートリッジ自体にRAMをのせてしまう(最も安全確実な方法)。

(2)2バイト以下ならばSLTWRK(FD09H〜)の自分に対応する2バイトをワークとして使用する。

(3)必要なワークエリアが3バイト以上ならば、まずBOTTOM(FC48H)の内容をSLTWRK(FD09H〜)の対応するエリアに書き写し、BOTTOMの値を必要なワークエリア分増やし、そこをワークエリアとして確保する。

と3案が示されており、これはアスキー版原本及びMSX-Datapack Vol.2にも同じ記述がある。しかし、Vol.2添付の正誤表では、(2)(3)を削除し、「カートリッジにRAMを搭載することを推奨します」と改められている。この情報はあまり流布しておらず、今日もどこかで誰かが苦しんでいるかもしれない。

カートリッジスロットの端子について、「5Vが二つあるが、どちらが＋5Vで、どちらが−5Vか分からない」旨の注記があった。別途、＋12V及び−12Vの端子はあるが、5Vはどちらも＋5Vである。

下に某ゲームの基板を示す。左端の2端子が5V、次の2端子がGNDである。以前書いたように、電源の強化目的と考えていいと思う。

---

■蛇足２

今さらながらDTMF規格について調べてみた。そもそもは ITU-T勧告を元に総務省令 端末設備等規則第12条第2号に基づく別表第2号に、押しボタンダイヤル信号の条件として規定されているそうな。

その中で、信号送出時間は50ms以上、ミニマムポーズ（隣接する信号間の休止時間）の最小値は30ms以上。そして、周期（信号送出時間とミニマムポーズの和）は120ms以上と規定されている。

よく「ピポパ」と言われるが、「ピ」と鳴ってから次の「ポ」が鳴るまでに120ms以上かけないといけないらしい。これに従うと、10文字送信し終えるまでに120ms×9＋50ms＝1130ms。1秒以上かかる。

ちなみに、今回使用予定のDTMFレシーバーCM8870は、信号送出時間、ミニマムポーズとも最低20msである。実質4bit文字を10文字フルスピードで送るのに190ms。メチャ遅だが1130msよりはずっとマシである。

遅さが魅力のMSXであるが、そこそこのスピードは確保したい。苛立って叩き壊さない程度にねｗ(・∀・)

【速報】デコード成功！

自前のDTMFデコーダの完成が待ちきれず、Windowsのフリーソフトでデコードできるか試してみました。結果は大成功！（たぶん）

使ったソフトは「Software DTMF Controller」。Xpまでの対応のせいか、恐る恐るWindows７にインストールすると、１〜２回の試行でフリーズしてしまいましたΣ（・□・；）

やっと撮れたのがこの一枚です。

MSX側で「0123456789ABCDEF」と入力すると、予定どおり2文字ずつにエンコードされました。「0」が「A1」、「1」が「A2」という具合に対応しているようですｗ

「３」は「AA」となるべきところ、当初、上位４bit・下位４bit の発声が連続的過ぎて「A」一文字に変換されました。アセンブラソースを見直し、ウエイトを挟んで「AA」と認識されるように調整しました。

MSXのライン出力をパソコンのマイク入力に繋ぎましたが、音量が足りないようで、例によって百均アンプを挟みました。ゲインが大きすぎて少しVRを動かすとガバッと大きな音になります。音量調整にも苦労しました（*´Д｀*）

何はともあれ、データが「0〜F」に変換できる目途がついたので、安心してハード・ソフトの開発に専念できます。「A1」が「0」、「A2」が「1」という具合に元に戻せばいいわけですね。

虎の子のDTMFデコーダICを壊さないように、慎重に進めます。

以上、速報でありました。（ペコリ）

DTMFデコーダー考えちう

---

■人騒がせなポート1割り込み仕様の件

DTMFのアイデアの元ネタは、「MSXマガジン」（アスキー）の1991年4月号と5月号です。前回のエンコーダー試作の発声部分は、4月号に掲載されていたBASICプログラムの該当部分をほぼそのままアセンブラに移植したものです。データの与え方はBASICに任せて、汎用性を持たせたつもりです。

さて、次はさっそくデコーダーも5月号からパクリを…と思いましたが、記事に妙なことが書いてありました。

「＃15に10000000B（バイナリーコード）を出力すれば、#14にジョイスティックポート1の状態が現れるように思えます。ところが実際にBASICでこれを行ってみると、まったく読み取ることができないのです。これは内部の割り込みに関連して、#15のビット6が0になってくれず、常に1になってしまうためです。つまり、ジョイスティックポート2の状態ならば読めるということなのです。」

だから今回のデータの取り込みにはポート２を使うというのです。

ホンマかいな！？　参考まで、ポートA及びBの各ビットの意味を示します。にゃごすさん主宰の「WEB版MSX2テクニカルハンドブック」から引用。（http://ngs.no.coocan.jp/doc/wiki.cgi/TechHan?page=FrontPage）

参考までに最終兵器「MSX1アセンブラリスト」を引っ張り出してきました。PSGレジスタ書き込みBIOS「WRTPSG」は、内部ルーチンで割り込み禁止してアキュムレータの示すレジスタに値を書き込んでいますが、割り込み解除してRETしてます。読み込みBIOS「RDPSG」の本体は、わずか

　　OUT　(PSG.LW),A

　　IN　　A,(PSG.DR)

　　RET

これだけで、DI も EI もへったくれもありません。

もしMマガ筆者の言うように途中で割り込みがかかって、＃15のビット6が知らん間に「1」に書き換えられていたら、プログラマは原因不明の挙動不審に悩まされるでしょう。

なにぶん割り込みがらみのハナシなので、どこから割り込まれているのか発見には至りませんでした。人騒がせな仕様です。日を改めてホンマかどうか確かめてみます。

実は、この記述に今日まで気が付きませんでした。というのは、これまで工作するときは習慣的にポート2を使っていたのです。ポート1は6及び7端子を出力に使わない、いわばゲーム専用と割り切るのが無難でしょう。

---

■6及び7端子を出力に使っていいのか？

まだちょっとナゾというか、気になる点があります。

注目はポートBのbit0〜3。先の にゃごすさん版テクハンでは「汎用I/F1又は2の6又は7端子に接続」と書いてありました。

ところが、本家「MSX2テクニカルハンドブック」（アスキー）では「bit0〜3は使用しない」となっています。

「使用しない」となると、6及び7端子は入力専用となります。

実は、にゃごすさん版テクハンは、本家テクハンではなく、「MSX-Datapack」の記述と同じなのです。

「汎用I/F1又は2の6又は7端子に接続」という記述は事実を述べているだけで、「だからどうなの？」と考えてしまいます。

この点について、古典「MSX早わかり事典」（朝日新聞社）は明快です。「出力として使わない場合、「H」レベルにしなければならない。」と書かれてます。

6及び7端子は、「入出力兼用ですから、入力に使う場合には（中略）オープン・コレクター・バッファを入れてポートBからの出力信号を切断します」。なお、デフォルトで「H」になるよう、プルアップ抵抗が入っていると記述されています。確かに、MSX-Datapack の「MSX2＋回路例」では、抵抗アレイっぽいものが入っています。

結論、6及び7端子は出力にも使っていい。ただし、ポート1は前述の割り込み問題もあって気を遣う。ポート2の6及び7端子でイタズラするのが無難、というところでしょう。以前から工作にはポート2を使っていたぼくは、結果的に正解だったわけです。エヘン！（笑）

---

■トリガA・B のタイムラグのナゾ

最後に若干小ネタですが、似非職人工房で有名なつじかわさんの指摘を紹介しておきます。「MMCを使ってみよう」のサイトで触れられていたことです。

「それと今回実験に使用したMSX本体（FS-A1GT)のジョイスティックポートで、妙な挙動を発見しました。

MSXは、PSGレジスタR#15のbit2/3でジョイスティックポートBのトリガA/B出力を設定出来ます。bit2/3を同時に変化させれば、トリガA/Bが同時に変化する事が期待されます。

ところが実際には、トリガAの方がBよりも必ず600ns程度先に変化するのです。MSXエンジン(T9769)を使用したMSXで共通なのかも知れません。」

http://www.hat.hi-ho.ne.jp/tujikawa/mmc/mmc.html

MSXではあっても、600nsは決して短い時間ではありません。昔、「シリアル通信」でイタズラしていた頃は、ステート数を計算してギリギリと追い込んだものです。簡単に「600ns遅れるよ」と言われると困るのです。この点もGTだけの問題なのか、後日（いつになることやら）確かめてみたいと思います。

というわけで、汎用ポート周辺事情だけで今回は終わってしまいました。ま、DTMFデコーダ用の収穫として、

　(1)ポート2をターゲットにハード・ソフトを開発する。

　(2)6及び7端子は必要なら出力に使っていい。

というところでしょうか。あ〜疲れた >┼○ バタッ

DTMFエンコーダ試作

どうもブログの書き込みの際、アセンブラソースやBASICリストが蹴られてしまいます。仕方がないので画像で掲載します。流れをなぞっていただいて、こうしたほうがいいのじゃないかという点があれば、ご指摘いただけたら幸いです。

なお、当初は、キー入力バッファにあるだけのデータを一気にピポパとしていましたが、USR関数で与えられた1データ分だけ音を返すようシンプルにしました。

ラベルDACは、USR関数で与えられる引数の２バイトのうち、下１バイトが格納されるワークエリアです。本来は、Math-packで使用されるF7F6Hから始まる16バイトのエリアの一部です。引数が整数で与えられることを前提とした決め打ちのアドレスです。

A1〜A4とB1〜B4はPSGの音程レジスタに与える定数です。

WTは、WAITの長さで、256回の空ループを何回繰り返すかを示します。「50」としたのは仮の数字で、R2-D2っぽいと思ったスピードにしましたw

MAINでは、まず8ビットの上4ビットを音声化し、次に下4ビットを音声化しています。

JPTBLは力づくのジャンプテーブル。0〜15のどれに相当するか判断してPSGの音程レジスタに与える定数を決めています。

TONEはPSGの2チャンネルを使って、2音を同時発声させています。

ウエイトループを挟んでレジスタ7を操作して、発声チャンネルをON/OFFしています。

1バイトのデータは、4bit＋4bitの2音を「ピポ」と発声します。でも、例えばキャラクタ「3」の場合はアスキーコードが「33H」なので、「ピピ」と同じ音が続きます。

長年愛用の「MSX-DOSスーパーハンドブック」掲載のASM.COMを使って、「/B」オプション付きでオブジェクトファイルを作りました。ライブラリもリンカもない、シンプルなアセンブラで気に入っているのですが、2進数表現に対応しないのが残念です。2箇所に2進数表現でコメントを入れているのは、そういう事情です。

さて、次はエンコーダを試すBASICプログラムです。INPUT$()でコントロールコードを含む文字列を取り込んでいます。ただし改行コード（0DH）の場合は文字列の終わりと判断して、発声ルーチンに渡します。従って0DHを含む文字列は、このプログラムでは処理できません。

文字列がヌルだった場合は、プログラムを終了します。

まだデコードのハードもソフトも出来上がっていないので、果たしてうまくいきますやら？

そもそも、ソースコードを書くのが何年ぶりでしょうかね？（笑）

とんでもない間違いをしているかもしれません。いや、実際に間違いだらけでした。前回から相当修正したのはヒミツですｗｗｗ

もし万一、ソースをご希望の場合は、…どうやってお渡ししたらよろしいでしょうかね？　lhaで圧縮してishでテキスト化すればいいのでしょうか？　パソコン通信時代から進化してないのがバレましたｗ