2010-02

これは、うちにあるピンボールに入っているリレー回路です。

TTLのビデオゲームについて少し前に書きましたが、それ以前に作られていた電子回路を使わないゲーム、いわゆるエレメカでは、こうした機械式のリレーが論理回路として働いていました。TTLによるゲームも論理回路で構成されていますし、そもそもコンピューター(CPU)の中身も論理回路です。
つまり現在のゲームやPCが動作する原理の原始的な形がコレと言えなくもありません。
リレーは、電流が流れると電磁石の力でスイッチを引き寄せます。そして、電流が止まるとバネの力でスイッチが戻ってしまいます。簡単に言うと、別な回路のスイッチをON/OFFするのがリレーの役割なわけで、ゼルダの伝説で言うと床のスイッチを踏むと、遠くにある扉も一緒に開いたり閉じたりするのと似ています。
真空管やトランジスタ、ICチップであっても仕組みは同じことで、考え方の基本にあるのはデジタルの1と0を電流が流れているか、いないかで分けるということです。これだけの仕組みで計算ができてしまうのが驚きです。詳しくは触れませんが、興味のある人は以下のページなど参考にしてみてください。
http://www.infonet.co.jp/ueyama/ip/logic/adder_r.html

こういった論理回路によって、0か1かの情報、さらにそれを集めた2進数の情報を保持でき、複雑な動作が可能になりました。
たとえばピンボールゲームだと、ゲームのスタートボタンを押すとスコアなど各種設定がリセットされてボールが出てきます。そして、「A」「B」「C」のターゲット全部にボールが当たると1000点入るなどのギミックが動くようになります。
こういった最初にこれをやって、次にこうなって、その次はこれ…といったシーケンス動作は、コンピューターのプログラムが得意とする部分です。特に手続き型言語(BASICとかHSPとか)は、まさに動作の順番を書いていくだけです。
手続き型で考えるとだいたい、こんな感じになります。

1. スタートボタンが押されるまで待つ
↓
2. スコアや各種設定をリセット
↓
3.「A」のターゲットにボールが当たったら変数Aを1に
↓
4.「B」のターゲットにボールが当たったら変数Bを1に
↓
5.「C」のターゲットにボールが当たったら変数Cを1に
↓
6. 変数A～Cがすべて1ならば1000点加算
↓
7. 3.からの動作を繰り返し

これと同じことをリレーが行なうと、

1. スタートボタンが押されたら設定を保持している回路を切断(0)する
また、ゲーム中であることを示す回路を接続(1)する
2. 「A」のターゲットにボールが当たったらAの回路を接続(1)する
3. 「B」のターゲットにボールが当たったらBの回路を接続(1)する
4. 「C」のターゲットにボールが当たったらCの回路を接続(1)する
5. 回路A～Cがすべて接続されると1000点加算

のような感じになります。
それぞれのスイッチごとに、どのような動作を行なうか、他の回路とどのような関係を持つかなどを考慮して設計する必要があります。特に「ゲーム中であることを示す回路(リレー)」は、エレメカ時代のゲームには必ずついていて、お金を入れるまではプレイヤーの操作などゲームに関わる回路に電源が繋がらない仕組みになっていました。これがタイマーにより一定時間で切れたり、カウンターが進むと切れるようにすることでゲームオーバーを作っていたわけです。
こうした考え方は、今注目されているマルチスレッドプログラミングや関数型言語に近いものがあるように思います。何か一周してきたようで不思議なものです。
ところで、機械式のピンボールにはまだ一部アナログ的な動作も残っています。たとえば5000点加算するような場合、論理回路で5回カウントさせるのは規模もコストもかかります。そこで、オルゴールのように回転する円盤が物理的に5回スイッチを入れるようになっています。これはスコアモーターと呼ばれているもので、必要に応じて1回、3回、5回などのパルス(スイッチのON/OFF)を発生させます。ある意味で、これがエレメカゲームの心臓部と言えるかもしれません。

その後、ビデオゲームが登場しTTL制御の時代になっても、プログラムという手続き型の動作ではなく、エレメカの論理回路が行なっていた仕組みを継承し、より複雑なものになっていきました。
そう考えると、ブロック崩し(Breakout)などはどんな動作になっているのか興味深くなってきませんか?

※追記(2010/3/15)
さらに新しいバージョン(RC3)が公開されています。こちらの記事を参照してください。

前のバージョン(RC1)からいくつか内容を修正したHSP3.21RC2を作成しました。
RC1版との違いは、以下の点になります。

• sprocketさん製作のArtlet2D,SQLeleモジュール及びサンプルを同梱。
• hspinetプラグインに文字コード変換(nkf)、JSONサポートを追加。
• hspinetプラグインサンプルにTwitter API操作スクリプトを追加。
• mod_regexpモジュールを追加。
• Windows7用のマルチタッチサンプルスクリプトを追加。
• HGIMG3で直接描画のテクスチャ補間方法に関する設定を追加(hgimg3.txt参照)。

RC1から、HSP3及び標準的なランタイムに変更はありません。マイナーバージョンコードも変更していません。
プラグインや新規モジュールが主な更新ですが、よかったら試用してみてください。これで大きな問題がないようであれば、そのままリリース版として公開していく予定です。まだいくつか修正したい点はありますが、x64対応版への差し替えという側面もあるため、リリースを早めることを優先して進めています。

  hsp321rc2.zip (19.4 MiB)

フルセットの内容をzipファイルに圧縮してあります。
HSP3.2がインストールされている方は、別のフォルダに解凍するか、バックアップした上で上書きすることを推奨します。何らかの問題や不具合がありましたら、掲示板かこちらのコメント欄でお知らせ頂けると嬉しいです。
今回大きく更新された点として、sprocketさんが作られているHSP Document Library(HDL)及び、d3moduleモジュールに加えて、Artlet2D,SQLeleモジュールも正式に同梱されることになりました。特にArtlet2Dは、GDI+を利用した多彩な描画をサポートするもので、色々と応用ができそうです。(ただし、Windows XPより前のOSでは別途DLLのインストールが必要です)

他にも、HDLのドキュメントが見やすくまとまるようになったりと、細かい部分でバージョンアップされています。

現在、マイナーアップデートとなるHSP3.21の準備を進めていますが、その一環で文字コード変換機能をhspinetプラグインに付加しようとしています。
文字コードは、コンピューター内部で文字を扱う時の数値で、65ならば「A」、33ならば「!」のような感じに表示される文字と対応しています。ことに日本語の全角文字が環境やアプリケーションによって異なることがあり、文字コードが違うと正しく文字が表示されない「文字化け」が起こってしまいます。この文字コードは、歴史的経緯もあってなかなか統一できない点も含めて悩みのタネになっています。

2000年以降は、Unicodeと呼ばれる国際的な統一規格にまとまりそうな気配があるのですが、Unicodeが上位互換で新しい仕様を入れてくるため、対応が間に合わないとか、それ以前に作られたテキストが読めないなど難しい問題を抱えています。
特にWindows内部で使用しているUTF-16(Unicodeの一種)は、2バイト(16ビット)で1文字かと思いきや、サロゲートペアという不思議な仕様により4バイト(32ビット)になることがあったり、バイトオーダー(上位下位バイトの並び順)の違いがあったりと、かなり不親切な作りです。そこで、半角の文字や記号にわりと相性の良いUTF-8(これもUnicodeの一種)が、最近では主流になってきてるのかな…と感じています。
さて、その一方で日本のPC環境では、古くから日本語はSJIS(ShiftJIS)と呼ばれる文字コードが使用されてきました。HSPもずっと前から、SJISをベースに作ってきましたが、時代の流れとともに色々な問題が出てきました。

• SJISコードでは表現できない文字(漢字)がある
• Windowsの内部ではUnicode処理を行なっているため変換コストがかかる
• 各種コンポーネント(COM)がUnicodeをベースにしているため相性が良くない

HSPも色々な環境に対応するために、今後はUTF-8など新しい仕様に移行することが必要と感じています。と…こんな話の流れではありますが、Windows版については当面SJISベースを維持する予定です。その根拠というか、思うことはWindowsもしくは日本のマイクロソフトも完全なUnicodeベースにしようとはしていない気がするからです。
最新のWindows7でさえ、ユーザーが新規テキストを作成した後、メモ帳で保存される形式はSJIS(ansi)です。また、DOSプロンプトでファイルにリダイレクトした結果もSJISになります。

互換性の問題もあるかと思いますが、ファイルに記録される文字コードの形式としてSJISが残っている限りは、Unicodeに移行しても問題が起こります。それで問題を増やすよりは、単一のフォーマットにして混乱を避けるのも1つの道かなと考えています。
ただ、インターネットを始めとして新しい環境では、それに合った文字コードがあると思いますので、そちらに向けては積極的に対応を進めていきたいところです。

ところで、ここから先は昔話ですが、その昔ヒットした日本初のパソコンとして名高いPC-8001というマシンがあります。これが登場したのが1979年で、漢字を表示することすら難しい時代でした。
この頃は、256種類の文字データがROMに内蔵されていて、これを変更することは基本的にできませんでした。その256種類の文字がこちら。(左上が0、右下が255のコードになります)

ごくわずかな漢字、「年」とか「秒」とかが用意されているところが涙ぐましいですが、限られた種類の中で必要そうな文字を選ぼうとしていた跡が伺えます。
で、この文字コードはその後、PC-9801という16ビット機にも受け継がれ、そのマシン上でMS-DOS、Windows3.1とOSが進化しても半角文字に使われるこの256種類は維持されてきました。
特に、漢字が出なかった時代はカタカナが使われていて、事実上カタカナの文字コードはこれが標準と言っていいと思います。
で、現在使われているSJISのコードを見てみると、見事にこの256種類の中で基本的な文字とカタカナを避けて定義されていることがわかります。SJISの1バイト目は、$81～$9f、$e0～$fcというコードで、昔の文字コードで言うところの、わりと使われない記号とか、トランプのマーク、わずかな漢字などの領域を全角の識別用に使い、半角カナを含むテキストはそのまま読めるようにしています。
つまりそれだけ長い期間かけて互換性が維持されてきた文字コードがSJISなわけで、これがすべて置き換わるのも長い期間がかかるのではないかと思ってしまいます。

ちなみに、PC-8001と同時期にシャープが発売したMZ-80というパソコンが使用していた文字コードがこちら。

MZ-80シリーズ(後のMZ-700やMZ-1200の元になる)は、当時PC-8001など多くのメーカーがコンピューターの本場アメリカの技術をベースにしていたのに対して、国産技術をベースにしていた点がとても異色でした。
それもあってか、この文字コードではカタカナの並びが謎なだけでなく、アルファベットや記号のコードすら当時の国際標準(ascii)に沿っていません。しかしながら、256種類をフルに活用してユニークな記号や、明らかにゲーム向けな図柄も多く含まれていて好感が持てます。実際とてもユーザー本位な作りをしていて、今でも熱狂的なファンがいるのも何となく頷けます。もし、この機種が日本の標準になっていたら、現在のSJISコードも違った体系になっていたでしょう。
でも、このカタカナ配列はやだなぁ…。

※追記(2/17)
よくよく見たらMZ-80のカタカナの配列は、キーボードのABCD…に対応するカナ入力のコード順だったのか。その発想はなかったけど、コード配列としてはやっぱりやだなぁ…。

前に紹介したUSB制御システムHIDaspxですが、その後、HSPからも制御できるようになりました。

と言っても、HIDaspxで利用できるhidmon.dllというDLLを呼び出しているだけなので、とてもお手軽です。
何よりドライバのインストールなど煩わしさがないところがいいですね。私のWindows 7(x64)でも普通に動作しています。この基板では、ボタン入力2bitとLED出力8bitですが、いずれ別なものも接続してみたいところです。
せっかくなのでHSP3で使うためのヘッダファイルとサンプルを置いておきます。ちょっと試してみたいという方はどうぞ。(別途HSP3フルセットが必要です)

  hidmon_hsp3.zip (15.3 KiB)