アップスキャンコンバータによる高解像度画面への表示

今日は趣向を変えて、ディスプレイの接続の幅を広げる実験をしました。

Bitfunx社のOSSC(Open Source Scan Converter)です。

1. レトロパソコンの解像度の話

まず大前提として、PC-88VA2のような超レトロなパソコンは、そもそも最近のディスプレイに画面を表示することができません。解像度が低すぎるのです。

最近のディスプレイの普通ぐらいがどのぐらいなのかよくわかっていませんが、まあたぶん、

• 1920×1080（フルHD）
• 3840×2160（4K）
• 7680×4320（8K）

あたりがよくある解像度なのでしょう。

で、PC-88VA2の解像度はというと、

• 320x200　主にアクションゲーム
• 640x400　一番普通に使われる画面モード。いわゆるPC-9801モード。
• 640x408　なんだかできるから作っちゃいました、みたいなモード

です。(その他にも何パターンかありますが、あとは上記の組合せです。)

因みに、縦408ピクセルって、たぶんPC-88VAシリーズのオリジナル画面モードなんじゃないかな？

まあ、とにかく解像度が全然違っていて、昨今のディスプレイではこれらの解像度の表示ができません。仕方がないので、これらの解像度に対応する中古ディスプレイを探すことになります。無いわけではありませんが、なかなか手に入りづらい状況です。

因みに私が今、メインで使っているディスプレイは、Century社のLCD-10000VH5です。

このディスプレイの解像度は1280x800ピクセル。そう、640x400ピクセルのちょうど縦横2倍なんですね。メーカ公式ではありませんが、640x400ピクセルの画面を表示することができるようになっています。

後継となる現行品はLCD-10000VH7という機種のようですが、この機種が640x400モードに対応しているのかは不明です。誰か試した人いないかな？

2. OSSC (Open Source Scan Converter)

さて、冒頭で紹介したOSSCですが、これは低解像度表示に対応していない最近のディスプレイにレトロパソコン、レトロゲーム機等の画面を映してしまう機器で、一般的には「アップスキャンコンバータ」と呼ばれているものです。そのオープンソースハードウェアがOSSCです。

色々なメーカから販売されていますがBitFunxはその中でもメジャーなメーカになります。

見た目はこんな感じです。

基板むき出しなものが多い中、Bitfunxはそれっぽいケースに入っています。

つないだらすぐに映るのかと思ったら、そういうわけではなかったようです。

とりあえず、電源をONしたら、リモコンの[3]ボタンを押します。

これは入力切換えですね。

• AV1: SCARTコネクタ
• AV2: Component端子
• AV3: VGAコネクタ

となっていますので、AV3入力を選択するということです。

(信号の構成の違いとかあるけど、細かいことは省略)

で、入力を選択したら画面は映ったのですが、左上方向にはみ出しています。

調整が必要なようです。

こちらのサイトによると、640x400ピクセルモードは、以下のように画面出力されているそうで、とりあえずこの通り調整すれば良さそうです。

• ピクセルクロック　21.0526MHz
• 水平同期周波数　24.83kHz
• フロントポーチ　80ピクセル
• 水平同期ピクセル　64ピクセル
• バックポーチ　64ピクセル

1スキャンライン分の論理ピクセル数を計算すると、

　21.0526MHz / 24.83kHz = 約848ピクセル

 　640 + 80 + 64 + 64 = 848

なので、ちゃんと計算も合っているようですね。

OSSCでは、フロントポーチの入力はありませんが、同期ピクセル数、バックポーチピクセル数、アクティブピクセル数から計算するようになっているようです。

それで、調整した結果が↓こちらの画面になります。

設定を書き出すと以下の通りです。

• H. samplerate = 847.00
• H. s.rate frac = 847.00
• H. synclen = 72
• H. backporch = 72
• H. active = 640
• V. synclen = 15
• V. backporch = 19
• V. active = 400
• H. border = 0
• V. border = 0
• Sampling phase = 180 deg

うーん、なんか計算値と違うんだけどなあ。

まあ、表示できるパラメータが正解ということで。

使用したディスプレイは、DELLのU2410です。

このディスプレイの解像度は、1920x1200ピクセルです。そう、640x400の縦横3倍です。

ちょうどいい解像度のくせに、水平同期周波数24.83kHzに対応していないので、640x400の画面が表示できないのです。

しかし、これでもう安心。

表示できることが確認できました。

他にも色々と試してみたいことはありますが、今日のところはここまで。

USBキーボード・マウス変換器のインタフェース基板

PC-88VA用キーボード・マウス変換器ですが、ソフトの方もだいたい完成したので、ブレッドボードだったインタフェース部分を基板に作り替えました。

私は元々ソフト屋さんで、ハード制作が得意なわけでも何でもないので、写真は遠目にしておきます。

黒井電気さんのかんたんUSBホストはそのまま使っています。

本当はブレッドボードに差していた足を上向きにしてインタフェース基板を上に載せるような感じにしたかったのですが、足のピンをどうしても上手く外すことができなかったので、USBコネクタが上に出っ張ったような形になっています。

かんたんUSBホストをもう1台買えたら良かったのですが…再販してくれないかな。

で、足のピンを頑張って外そうとしていた時に、基板上の回路を破損してしまい、LEDが点灯しなくなってしまいました。

3.3VからLEDにつながる線を切ってしまったようだったので、今はジャンパー線で接続しています。

写真が遠目なのはそんな恥ずかしい状態だったからなんですね。

さて、インタフェースボードは完成しましたが、ケースに入れるかどうかは未定です。

というかケースに収める前提で作っていないので色々と厳しいかな？

気が向いたら3Dプリンタで専用ケースを作るかも？

USBマウスの接続 その1

USBキーボードが接続できたので、マウスも接続できるんじゃない？ということで、マウスの接続に挑戦してみた記録です。

1. PC-88VAのマウスプロトコル解析

PC-88VA側のマウスI/Fですが、BNNのPC-88VAテクニカルマニュアルによると、X/Yの移動量データを4ビット単位に以下の順で送信すると書いてあります。

• X上位4ビット

• X下位4ビット

• Y上位4ビット

• Y下位4ビット

え？待って、これ、普通に違和感ありますよね？

この時代のNEC(MSXマウス仕様だとしても)は、Z80 or Intel8086系の互換CPUしか使っていないんだから、「上位→下位」は違うんじゃない？と思いますよね？

そもそもテクニカルマニュアルって、誤記多過ぎるし、どうせまたこれも誤記なんだろう

・・・と思っていた時期が私にもありました。

実際にオシロで見てみたら、書いてある通りでした。

ちなみにストローブ波形はこんな感じでした。

• 約16.7ms周期

• ON 約100μs

• OFF 約66.7μs

• ON 約66.7μs

• OFF

16.7msってあたり、垂直帰線割込みに同期しているのでしょうね。

そのあたりは納得できます。

しかし、もう1つ、納得できない話があります。

それは転送される4ビットデータの形式です。

最初は「ビット反転」だと思っていたのですが、実際には、「正論理のまま符号反転」でした。

つまり、

+1 → -1
-1 → +1

のような感じ。

いや、これ、明らかにビット反転と符号反転の違いを理解できていない人が設計してるよね？

FM音源のI/Oとか8255とか使ってるから、ビット反転で入力したいというのなら理解できるけど、何故に符号反転？全く意味が解りません。

でも実際、調べてみるとそうなっているんだから仕方がない。

当時のNECの新人社員に仕様作らせて、ノーチェックで出荷しただろ？と疑ってしまうようなお粗末な仕様で、正直、驚きました。

(MSXマウスとかもそうなの？知ってる人、情報求ム！)

2. Timer2割込み処理追加

最初はメインループ内でストローブを監視していました。

まあ、ループしちゃうと普通にWatch Dog Timerでリセットされてしまうので、WDOGリセットをかけながらループするんですけどね。

でもやっぱり、USB処理やキーボード処理も同時に走っているのに、ストローブ監視の為に他の処理を止めてしまうのは、下策でした。

あちこちで処理落ちするようになってしまいました。

結局、Timer2割込みを使って20μs周期でストローブ監視する方式に変更。

「割込み処理をどこまで重くしていいのか？」

というのは、はっきり言ってわかりません。

まあ、とりあえず今は動いているからヨシとしています。

3. USBマウスのプロトコル仕様

USBマウスのプロトコル仕様(Boot Mouseと呼ぶらしい)は、以下の通りです。

• ボタン → 8ビット ビット列 (各ビットがボタンに対応)

• X移動量 → 符号付き8ビット数(-127～+127)

• Y移動量 → 符号付き8ビット数(-127～+127)

• ホイール移動量 → 符号付き8ビット数(-127～+127)　(オプション)

ホイールがあれば4バイト。なければ3バイト。解り易くてたいへんよろしい。

しかし、これはあくまでも「基本的には」という話。

キーボードと同様に、Bootモードだったらそうです、みたいな話のようです。

私の手元にあった複数のUSBマウスを繋いでみると、ほとんどが移動量は16ビット。

上記、Boot Mouseプロトコルでそのまま動いたのは、中華製ノーブランドマウスのみでした。

とりあえず、動かないマウスには、

SET_PROTOCOL(BOOT)

という、デバイスにブートモードを指示するUSBホストコマンドがあるので、これを送ってみました。

結果は、移動量が8ビットになるマウスもあれば、完全無視するマウスもある、ということに。

うーん、微妙・・・

まあ、BIOS設定画面はだいたいキーボード操作なので、困っていないのでしょうね。

結局、受信パケット長が4バイト以下なら正規のBoot Mouse仕様、それ以上なら移動量16ビット仕様と見なすようにしました。今のところ、手元にある4台のマウスはそれで動いています。

4. USBマウスの移動量積算

最初、USBパケットから取り出したマウスの移動量を、X/Yそれぞれの変数領域に毎回上書きしていました。

多少ロストしても、マウスなんて人が手で動かしているんだからいいでしょ？

ぐらいに思っていたのですが、やっぱりそれではダメだったようです。

PC-88VA側は16.7ms周期なので、その間に来たUSBパケットが失われて、マウスの動きが妙に遅くなってしまいます。

そこで、

USB側の移動量を積算　→　PC-88VAのストローブタイミングで放出

という方式に変更。

動きは自然(というか普通)になりました。

USBマウスから送られてくる移動量はだいたい±10以下ぐらいが多いようなので、16ビットには拡張せず、積算値は8ビット符号付きで保持し、±127でクリップしています。

PC-88VAの解像度ならこれで十分そうです。

5. HUB対応？

今回の変換器は、かんたんUSBホスト (HIDキーボード用)をベースに使っています。

元々USB HUBに対応しており、複数のキーボードを同時に接続することができるようになっています。(キーボードを複数接続したいシチュエーションがよくわかりませんが…)

当然ながら、マウスも複数台同時に接続できるようにするべきでしょう。

・・・と思ったが、ん～、ダメだこりゃ

やっぱりちょっと処理が重くなってきているようです。

マウスを激しく動かしていると、Hub Port Disableが発生して、HUBの接続が解除されているようです。

ここでUSBの仕様を読んでみると・・・

あれ？

USB仕様を読むと、通信パケットロスト時にHubがPortをDisableにするのは正しい動作ですが、その時のホスト側の対処方法は、

1. Disableをクリア
2. ダメならポートリセット
3. それでもダメなら接続解除
   (ただし、接続解除まで、必ず4ms以上は待つこと。)

となっています。

つまり、HUBの動作が仕様と違う。これはどうしましょうかね？

HUBを作るのは今回の趣旨ではないんだよね～。

他にも小さなバグは数箇所見つけているんだけど、これは作者に報告すべきか…

まあ、PC-88VAにUSBマウスを2台接続したい人なんていないから、問題ない。

と、今はそうしておきます。

6. まとめ

とりあえず、

• USB有線マウス (バッファローマウス、X68000Zマウス、中華製ノーブランドマウス)

• USB無線マウス (ロジテックマウス)

• HUB経由

• キーボード同時使用

あたりは動作確認できました。

ソフトはそれなりに動くようになったという認識です。

なので、ソフト開発の方はこのぐらいにしておいて、冒頭の写真の通り、現状、まだブレッドボード状態なので、次は基板化のほうを進めていこうと思います。