MSX-BASICでビジュアルプログラミング環境を作ってみた
マウスで命令ブロックをドラッグ＆ドロップすることによりコーディングできるビジュアルプログラミング環境*1を、MSX-BASICで作ってみました。
名付けて、MSX用ビジュアルプログラミング開発環境『MSX T-LEX』*2です。
MSXが、令和のプログラミング教育の最前線で戦えるかもしれない可能性。
いわゆるベーパウェアです。
目次
できること
動画
バージョン2
- 強化ポイント1：256色カラーに対応
- 強化ポイント2：描画精度の向上
- 強化ポイント3：日本語プログラミングとMSX BASICの命令に対応
- 強化ポイント4：条件分岐（IF文）に対応
画面解説
- ブロックエリア ブロック(命令)が格納されています。
- パレット切替 クリックすることで、表示するブロックを、英語系・日本語系・MSX命令系に切り替えることができます。
- コードエリア コーディングを行います。
- ブロックエリアのブロックをドラッグし、コードエリアにドロップすることでコーディングを行います。
- 行間にドロップすると挿入されます。
- ブロック構文（IF,REPEATなど）の間にドロップすると、ブロック構文内に挿入されます。
- 左ドラッグ すでに設置したブロックを移動します。ブロック構文の先頭をドラッグすると、ブロック構文が丸ごと移動します。
- 右クリック ブロックを削除します。ブロック構文の先頭を右クリックすると、ブロック構文が丸ごと削除されます。
- ブロックエリアのブロックをドラッグし、コードエリアにドロップすることでコーディングを行います。
- ヒントエリア ドラッグ中のブロックの機能が表示されます。
- 機能エリア クリックするか、ファンクションキーを押すことで、機能が実行されます。
- EXIT T-LEXを終了します。
- LOAD 保存済みのソースファイルを読み込みます。
- SAVE 編集中のコードエリアの内容を、名前を付けて保存します。
- OVERWRITE 編集中のコードエリアの内容を、現在のファイル名で上書きします。
- RUN 編集中のコードエリアの内容を実行するため、コンパイルを開始します。
とりあえず試してみる
以下のURLをクリックすると、WebMSXで起動します。*3
https://webmsx.org/?MACHINE=MSXTRJ&DISKA_URL=https://github.com/matsun-ri/msx-t-lex/raw/main/disk-image/T-LEX.dsk&MOUSE_MODE=1&BASIC_RUN=lex.bas
.BASファイルをアスキーセーブしているので、本来より読み込みにかなり時間が掛かります。
子ども向けプログラミングワークショップでScratchを選択する理由
何年か前から、ど田舎の図書館で子ども向けプログラミングのワークショップを開催しています。
子どもたちの最初の一歩として、どんな教材を使うか検討した結果、Scratchを選ぶことにしました。
その理由を挙げてみます。
目次
- マウスだけでほとんどの操作が可能（なんならタッチパネルでも）
- 命令語が日本語であること
- 文法エラーの排除
- 子ども向けのテキストが豊富
- 高い知名度
- 実はストイックなプログラミング言語である
- 「Scratchはテキストプログラミングじゃないからいやだ」という反論
- 「Scratchは素晴らしいノーコード環境だ」という誤解
- 結論
マウスだけでほとんどの操作が可能（なんならタッチパネルでも）
Scratchがブロックプログラミングであることに由来する利点ですが、パソコンが初めての子どもでも、マウス操作ならすぐに慣れることができます。
一方、多くのプログラミング開発環境で必須となるキーボードは、習熟している子と不慣れな子の差が激しく、不慣れな子どもを待っている間に習熟している子どもの集中力が途切れてしまいます。
プログラミングのワークショップを検討しはじめた時期に言われていたのは、2013年の調査によると小学生の打鍵平均速度は5.9文字/分しかないということです。これは平均ですから、習熟している子どもはそれなりに速いでしょうし、そうでない子どもはずっと遅いということになります。これでは、写経すら終わる前にイベント時間が終了してしまいます。
また、アルファベット（特に小文字）は小学生には分からない、というのが図書館での経験則です。そもそも、キーボードには大文字しか刻印されていません。
「キーボードやアルファベットなど、興味のある子どもならすぐに覚える」という反論もありましょうが、単発あるいは月1回程度のワークショップでは、覚えるのを待っている暇はありません。逆に言えば、例えば学童保育などで毎日のようにキーボードに触れる機会を持てるのなら、何でもありです。
今回の記事では扱いませんが、IchigoJam BASICは大文字でコーディングしますし、命令が短いので、子ども向けワークショップに向いていると思います。
命令語が日本語であること
Scratchそのものは海外のマサチューセッツ工科大学生まれではありますが、日本語化がほんとうに丁寧になされています。
これもScratchがブロックプログラミングであることに由来する利点ですが、他のブロックプログラミング環境では、必須の命令群が日本語化されていなかったり、フォントが微妙（読めない）だったり、ブロックに対して文字がズレているなどは当たり前のような状況です。*1
また、Scratchで日本語でコードを書き終わってから、表示言語を切り替えるだけで自分が書いたコードが外国語で表示されるのは、子どもたちにとって興味深いでしょう。*2
文法エラーの排除
これもまた、Scratchがブロックプログラミングであることに由来する利点です。
テキストプログラミング言語では、タイプミスによる文法エラーが起こりやすいのですが、Scratchでは命令語はブロックなので、単純なスペルミスが排除できます。
また、条件分岐の「もし」(if)や、ループの「〇回繰り返す」(for)なども、コードブロックの始まりと終わりが視覚的に囲まれますので、コードブロックの閉じ間違いによる文法エラーが排除できます。
これらは、テキストプログラミング環境で言えば、コード補完などの入力支援機能が有効に働いている状態に当たります。
初心者のうちは、ロジックエラーと文法エラーの区別がつきません。排除できるエラーは排除しておくことで、途中で投げ出す可能性を排除することにつながるでしょう。
子ども向けのテキストが豊富
自宅でプログラミングを継続する際にも、関連書籍など情報の入手が容易です。
むしろ、Scratchに関して言えば、本が多すぎて選択に迷いかねない状況ではあります。しかし、選択肢が多いことは、一般的には好ましいことです。
高い知名度
こんなど田舎でプログラミングワークショップに参加するようなアーリーアダプターは、すでにNHKの番組などでScratchの存在を知っていることが期待できます。
実際、開催後には、複数の保護者の方から「もともと、NHKのプログラミングの番組を観てて興味を持っていた」と伺いました。
実はストイックなプログラミング言語である
一般的なテキストプログラミング言語とScratchとの差は、命令語をキーボードで打ち込むか、マウス操作でブロックをドラッグ＆ドロップするか、という手間の違いだけです。
命令を組み合わせてロジックを構築するという部分は共通しているので、他の言語を覚える必要が生じた際にも、有利であることが期待できます。
以上の点から、受講者に希望がある場合は別として、「プログラミングを始めたいけど、何からすればいいか分からない」と言われたら、Scratchを勧めるのは充分に合理的でしょう。
とはいえ、これには反論も存在します。
「Scratchはテキストプログラミングじゃないからいやだ」という反論
「子どもにはScratchよりもテキストプログラミングに触れさせるべきだ」という意見を、時折耳にします。
例えば、次のような意見です。
- 「Scratchに慣れた結果、テキストプログラミングへの移行を面倒がってプログラミングをやめてしまった子どもを何人も見てきた。だから、最初からテキストプログラミングをするべきだ」
- 「Scratchでは、例えばデータベースの操作などの本格的で実用的なシステム構築はできない。だから、最初からテキストプログラミングをするべきだ」
- 「なんか思ってるのと違う。自分が好きなのは、真っ黒な画面にプログラムを苦労して打ち込んで、アスタリスクを左から右に移動させたりするのに成功した、あのワクワク感だ」
そもそも論として、子どもにプログラミングに触れてもらう目的を「子どもにプログラマーになってほしい」という明確だが狭い範囲に置くのか、それとも「子どもに、これからの社会を生きるための基礎知識のひとつをつけてほしい」という曖昧だが広い範囲に置くのか、そこを明確にしないと、捉え方が変わります。
1.の意見は、昔から初心者向けのプログラミング教本を多く出しているある著者が強く主張していました。
この手の話はたまに耳にするのですが、Scratchからの移行でプログラミングをやめてしまう子どもが、なぜ最初からテキストプログラミングだと継続できると思えるのかについて、納得いく解説を聞いたことがありません。
子どもにとっては、自分がやってみたいことと移行先のプログラミング言語でできることが乖離していたとか、移行先にScratch程の魅力を感じなかったからとか、そのような事情があったのでしょう。
その齟齬を埋められない責は、育成する側が負うものです。
2.の意見については、そもそもプログラミング言語には向き不向きがあるので、万能なプログラミング言語などありません*3。本格的にプログラミングを始めると、いくつかの言語を使い分ける必要が出てくるものです。それはScratchなどのビジュアルプログラミングでも、テキストプログラミングでも、変わりません。
3.の意見は、半分冗談で書きましたが、1.や2.だと主張するからよく聞いてみたら、実は3.みたいなことを言っていた、ということもあるようです。だったら最初からそう言ってくれ、って話ですが。
余談ですが、昔は、Scratchのスプライトのような画像を高速に動かすのはとても大変か、もしくはそもそも不可能でした。
今のようなネットなどない中、パソコン付属のマニュアルと月1回しか発行されない専門誌という限られた情報源を手垢まみれにして、やっとBASICを一通り覚えても、画像を思い通りに動かすなんて到底無理だとわかり、当時の子どもは、泣きながら機械語の使い方を覚えたものです。
Scratchであればそれが簡単にできてしまうのですから、やっかむのも無理はありません。*4
そういう人には、今ではSmileBASICみたいに大容量で高速な優れたBASIC開発環境がありますので、ぜひ触れてもらえればと思います。
それに、今の子どものほうが、画像処理まわりなんかは覚えることが多すぎて大変だと思います。昔は大したことはできなかったので、覚えることも少なかったわけですし。
子どもに強制しないのであれば、個人的な好き嫌いの話でしかないので、好きにすればいいのではないでしょうか。そういうのが好きな小学生は、たまにいます。
ただ、30年前のパソコン少年の知識だけでScratchに挑むと、メッセージやマルチスレッドあたりで初っ端からつまづくことになるので、あまりバカにしないほうがいいと思います。*5
「Scratchは素晴らしいノーコード環境だ」という誤解
ちょっと前から、一部のノーコーダーによる「Scratchはノーコードの一種だ」みたいな主張を時々目にします（そう主張している人が、本当にScratchを使い込んでいるのかは疑わしいのですが）。
Scratchで書くのはコードなんですけどね。ほら。*6
話がややこしくなる原因として「ノーコードには明確な定義が存在していない」ということがノーコーダーのコンセンサスとなっている点にあるかと思います。つまり、ノーコーダーが「ノーコードだ」と主張すれば、それは名誉ノーコードになってしまうのです。
Scratchは、自分の判断でブロックをコードエリアにドロップし、コーディングすることでロジックを構築しないと何も作れないわけですが、するとブロックプログラミングでブロックをドロップすることとエディタのコード補完機能でコードを入力することやマウスやタッチパネルなどのポインティングデバイスで仮想キーボードを使い、テキストプログラミング行うことの本質的な違いが問題になってきます。
また、Scratchは小学校低学年でも遊べる優れたUIを持っていますが、見た目よりもストイックで、ロジックの構築（＝コーディング）を手伝ってくれるものではありません。もしScratchがノーコードの仲間だとしたら、「ノーコードでシステムを構築するには、Scratchに匹敵する大変な修練とコーディングが必要だ」と暴露していることになるわけです。もし今のノーコードがその程度のものであるならば、これほど残念なことはありません。*7
Scratch勢はお上品なので、誰もはっきりと書かないのですが、単純な話、子どもたちにコーディングに親しんでもらおうと思ってマサチューセッツ工科大学が何十年もかけて作り上げた結晶であるScratchに対して、「コーディングなんか覚える必要ないぞ」と言わんばかりの名前で呼ばれたら、関係者は大激怒でしょう。思想を無視して、存在意義を否定されているのですから。
以上に挙げた反論にしても、誤解にしても、コーディングを楽しんでいる子ども達の耳に「君たちがやっているのは、本当のコーディングじゃないんだよ」と吹き込むような行為であって、個人的には大人がするような行為ではないと思いますが、人の口には戸が立てられません。
育成側としては、それを目にした子どもたちが混乱しないよう、説明できる術を身につけておくべきでしょう。*8
結論
子どもが興味あるものに触れるのが一番。
今回はScratchについて書きましたが、プログラミングのワークショップでは、Scratch以外にも、様々な教材を手配しています。
詳しくは、また後日に書こうと思います。
*1:MakeCode系のブロックプログラミングや、EV3 Classroomなど。
*2:逆に、外国語で書かれたコードがそのまま日本語で読めてしまう点は、指摘しないと気付いてもらえません。
*3:そんなものがあったのなら、バベルの塔の前の世界のように、言語はただ一つで統一されていたでしょう。
*4:僕もいまだにMSX BASICを触りますし、暇になったら30年前にやってたZ80のアセンブラを再開したいと思っているクチです。
*5:プログラミング経験のある大人ほど、Scratchで「旗が押されたとき」ブロックが複数置ける点につまづきます。
*6:しかも、以前[スクリプト]エリアと呼んでいた場所は、Scratch3.0から[コード]エリアに変わっています。
*7:ノーコードそのものは必要ですし、これからも進化し続けると思っています。また、ノーコードでのシステム構築の際に、Scratchでのコーディング経験は（他のプログラミング言語と全く同様に）役に立つと考えられます。 ここで問題としているのは、一部のノーコーダーによる「Scratch＝ノーコード」という決めつけです。
*8:私見ですが、「Scratchはテキストプログラミングじゃないからいやだ」と「Scratchは素晴らしいノーコードだ」は、昔あった「宇宙の真理がこんなに単純なわけがない。だからきっと相対性理論は間違っている」と「宇宙の真理がこんなに難解なわけがない。だからきっと相対性理論は間違っている」に近いような関係にあるんじゃないかと思っています。
遊星歯車機構とTHSのしくみ
『いずれはカローラにもハイブリッドシステムを載せたい』
と発言したのを聞いて
『安くてよく動くのが取り柄のカローラにハイブリッドシステムなんか積んだら、高くて動きが微妙な車になっちゃうじゃないのか……』
と思ったものですが、今では大抵のトヨタ車にハイブリッド仕様が存在しています。
というわけで、トヨタ車に積んでいるハイブリッドシステム、その名も『THS』について書いてみます。
追記
遊星歯車機構の動作をアニメーションにしてみました。
(1)～(6)のラベルをクリックすると、アニメーションを再生します。
https://scratch.mit.edu/projects/524873959
（注意事項）
- 音が出ます。
- 自分なりに調べた結果をアニメーション化したものです。
- シミュレータではありません。歯車が動く順番や歯車比とか適当です。
- 発電機の電気がバッテリーを経由せずに直接モーターへ行く場合などの、重要な部分を省略しています。
目次
免責事項
自分なりに調べたことを書いていますが、間違っている点があれば資料とともにご指摘いただければ幸いです。
ハイブリッドシステムの種類
一口にハイブリッドカーと言っても、異なる動力をどう組み合わせるかは様々です。
メジャーなハイブリッドシステムの形式には、パラレル方式とシリーズ方式があります。
パラレル方式
エンジンとモーターが直結されており、エンジンの出力不足をモーターで補う方式です。
一般的な車に最小限の変更を加えるだけで実装できるというメリットがあります。
シリーズ方式
エンジンは発電に徹し、それで得た電力でモーターを回す方式です。
遠回りな方法に見えますが、エンジンを最も効率のいい回転数で定速運転させることにより、燃費を抑えることができるというメリットがあります。
例えば、日産ノートe-POWERやJR西日本の豪華寝台列車『瑞風』が採用しています。
ノートe-POWERは登場時に
『電気自動車の、まったく新しいカタチ』
と宣伝されていましたが、実はシリーズハイブリッドは古くから大型艦船や潜水艦に使われている、枯れた（=完成度の高い）システムでもあります。
大型艦船では、 通常ではエンジン→軸→スクリューを一直線に配置しなければならないため、船内のレイアウトに厳しい制限が付きまといます。
モーターと発電機を加え、その間は電線を使うことで船内のレイアウトの自由度が増すこと、古い蒸気タービンだと出力の微調整が利きませんが、電気なら細やかな制御がしやすいことがメリットです。
潜水艦は、潜航中はディーゼルエンジンを使えない（空気がない）ため、電池でモーターを動かします。電池が切れるまでに浮上してディーゼルエンジンを使って充電しないと、動けなくなってしまいます。これはメリット・デメリットの問題ではなく、潜水艦が生まれてから今日に至るまでの宿命です。この軛から逃れることができるのは、稼働に空気を必要としない原子力潜水艦だけです。
スプリット方式
今回取り上げるTHSは、パラレル方式とシリーズ方式の良い所取りであるだけでなく、変速機の代わりまでこなしてしまいます。
名称は『スプリット方式』のほか、『シリーズパラレル方式』とも、モーターの役割が単なる補助ではなく、モーター単独でも走行可能なため『ストロングハイブリッド方式』とも呼ばれます。
THSにおける遊星歯車機構の挙動
普通の車のおさらい
どういうことかを説明するために、まず普通の車のギアについておさらいします。
普通の車のギアには、入出力が2つあり、それぞれエンジン、タイヤに繋がっています。
エンジンが動くと、その回転がタイヤに伝わり、車が前進します。
エンジンブレーキを掛けている状態では、タイヤの回転がエンジンに伝わります。
エンジンを回すのは重いので、それが抵抗になり、エンジンブレーキとなります。
遊星歯車機構のしくみ
プリウスのTHSに使われている遊星歯車機構は、3つの入出力を持っています。
それぞれ、
- タイヤ＋モーター（外側の青色が軸）
- 発電機（内側の紫色が軸）
- エンジン（中間の茶色が軸）
に繋がっています。
この部分をズームしてみましょう。
※面倒くさい方は、次の図までスキップすることをお勧めします。
遊星歯車機構の構造は、太陽系になぞらえられます。
- 太陽の位置にあるサンギア
- サンギアの周りを惑星のように取り囲むピニオンギア*1
- 惑星の軌道に沿って存在するプラネタリーキャリア
- 太陽系外縁部を囲むリングギア
このうち、2.のピニオンギアは、自分自身も回転しますが、プラネタリーキャリアも動かします。
太陽系になぞらえると、
- 惑星の自転→ピニオンギアの回転
- 惑星の公転→ピニオンギアの公転＝プラネタリーキャリアの回転
となります。
参考までに、各ギアを固定した場合、他のギアがどのように回転するかを表にしてみました。
- サンギアを固定すると、プラネタリーキャリアとリングギアは同じ方向に回転する
- プラネタリーキャリアを固定すると、サンギアとリングギアは互いに反対方向に回転する
- リングギアを固定すると、サンギアとプラネタリーキャリアは同じ方向に回転する
モーターのみで走行
難しい御託はこの辺までにして、まずは停止状態の車のアクセルをじわっと踏んでみます。
モーターで走行する状態では、電池の電力で(1)モーターを動かすことで、(2)タイヤを回転させ、車を前進させます。
なお、このとき、(3)ピニオンギアを経由して(4)発電機まで回転が届きますが、この時、発電機には負荷がかかっていない（発電しようとしない）ので、大したロスもなく空転するだけです。
モーター走行中にエンジンを始動
では、アクセルを踏み込んでみましょう。
(1)発電機がセルモーターとなり、(4)エンジンを回すことで、エンジンを始動します。
タイヤとモーターはグレーで描いていますが、暖機運転等の例外を除いて、走行中の多くの場合は、タイヤとモーターも動いています。
モーター＆エンジンで走行
モーターとエンジンの両方で走行する状態です。
発電機をロックすることで、(1)エンジンの動力が(4)モーターの動力と合算されて(5)タイヤに伝わります。
ところで、エンジンとモーターとでは得意分野が異なります。
エンジンは、一定の範囲の回転数で最も性能を発揮できます。言い換えると、それ以外の回転数――おもに発進時の低速域では燃費が悪くなります。
モーターは、回転し始めたその瞬間から最大のトルクを得られます。
そこで、低速域でもあえて(1)エンジンを燃費のいい回転数で動かし、その動力の一部を(3)発電機に分け与えて(5)充電を行います。
こうすることにより、通常の車では燃費が悪くなる速度域でも、電力を溜めることができます。
さらに、発電機で得た電力を(4)そのままモーターに与えて走行の手助けを行う場合もあります。
エンジン→発電機→モーター→タイヤ、という動力の伝達は、感覚的にはとても非効率に思えますが、実はこうすることで変速機を省くことができるのです。
言い換えると、通常の車ではたくさんの歯車の組み合わせで実現している変速を、エンジンと発電機とモーターの絶妙な協調によって、よりシンプルに実現しています。
『プリウスといえばTHS、THSといえば遊星歯車機構』
のように言われることがありますが、このような面倒くさい制御を20世紀のうちに量産車で実現してたのって、今思えば『21世紀に間に合いました』の売り文句は決して伊達じゃなかったんですね。
参考：日経トレンディネット『ハイブリッド車はなぜ燃費がいい？ モーターの役割は何？』
http://trendy.nikkeibp.co.jp/article/special/20090414/1025428/?P=9 ※リンク切れ
回生ブレーキ
では、アクセルを離し、ブレーキを踏みます。
ブレーキを掛ける際は、(1)タイヤの回転が(2)モーターに伝わります。
通常の車でいうエンジンブレーキと同じ状態ですが、スピードがモーターで電力に変換され、電池に蓄えられます。これを回生ブレーキと呼びます。
（この状態だとサンギアが回っているはずなのですが、サンギアにつながっている発電機が発電しているのか、単に空転しているのかがわかりません。どこかで「回生ブレーキにはモーターと発電機の両方を使用している」と読んだ気がしたのですが、ソースを見つけることができませんでした）
普通の車のブレーキは、ディスクブレーキをブレーキパッドで挟むことによる摩擦で作用します。スピードは摩擦熱となって消えてゆきます。
THSでは、フットブレーキを踏んだ際に要求されるブレーキ力を、回生ブレーキとディスクブレーキにうまく配分することで、できるだけ効率的に充電を行います。
このため、プリウスは普通の車よりブレーキパッドの摩耗が少ないとの話もあります。
なお、最近の電車は、回生ブレーキだけでほぼ停止ギリギリまでスピードを落とすことができるそうです。
凄いなと思っていたら、最近のTHSも、回生ブレーキだけでほぼ停止ギリギリまでスピードを落とすことができるそうです。
バック
バックは(1)モーターを逆回転することで行います。
エンジンは進行方向にしか回転しないので、エンジンではバックができません。
例によって発電機が空回りしますが、ロスにはなりません。
ところが、電池が少ない場合や急な登り坂へのバックなどでパワーを必要とする場合に、バック中でもエンジンが掛かる場合があります。
これは、バックするために足りない分の電力を、その場でエンジンを使って発電するからです。
エンジンを回すと前へ進む力が生まれますが、これを発電機とモーターでうまく帳消しにするよう制御しています。
ところで、アイドリングストップは燃費を稼ぐための大原則です。*2
しかし、暖機運転中や、あまりに電池が足りず燃費が悪くなりそうになると、停車中でも(1)エンジンによって(4)発電機を回し、充電を行います。
プリウスPHV(52型・2017年モデル)のEV走行
最後に、現行プリウスPHV（52型）のEVモードについてです。
プリウスの出力は、4代目（50系・いわゆる般若）の場合
- エンジン：98ps(72kW)
- モーター：72ps(53kW)
です。
足し算すると170ps(125kW)になりますが、実際の出力は122ps(90kW)にしかならず、通常のネット値とグロス値の差以上の開きがあります。
エンジンと発電機とモーターを協調させてギアチェンジの代わりを行う仕組み上、エンジンとモーターの両方が最高出力の状態で動力を加算することができないためです。
通常のプリウスであれば、モーターで足りなければエンジンを動せばいいだけですが、プリウスPHVでは事情が変わってきます。
PHVの場合、電池が充分にある限りはEVとしてふるまい、モーターだけでも走行できなければならないため、72ps(53kW)のモーターだけでは少し力不足です。
発電機は出力31ps(23kW)のモーターでもありますが、発電機をモーターとして利用した場合、エンジンが空転するだけで動力がタイヤまで伝わりません。
そこで、プリウスPHV（52型）では、エンジンとプラネタリーギアの間にワンウェイクラッチを追加し、特定方向への回転がエンジンに伝わらないようにしました。
これにより、EVモードでは発電機をモーターとして動力に利用できるようになりました。
旧プリウスPHV（35型）のEVモードでは最高速度が100km/hまででしたが、新プリウスPHVでは2つのモーターの力で、EVモードでも最高速度135km/hで走ることができます。
参考：日経ビジネスオンライン『次期「プリウスPHV」、走行性能が一気に向上』
http://trendy.nikkeibp.co.jp/article/special/20090414/1025428/?P=9
大容量の蓄電池を搭載するEVと比較して、電池容量8.8kWhしかないプリウスPHVでの高速走行は割といい勢いで電池が減ってしまいます。
本来、PHVで長距離の高速走行をしたければ、何も考えずにエンジンを回してハイブリッドカーとして走ればいいだけの話ですし、それが可能なのが、PHVのEVに対するメリットです。
それを、わざわざワンウェイクラッチの追加という仕様変更をしてまでEVモードでの高速走行の実現に拘ったのは、開発陣が『EV走行の楽しさ』をPHVユーザーに体感して欲しかったからではないのでしょうか。
乱暴な言い方をすれば、
『プリウスPHV1台で、ハイブリッドカーとEVの2台分の走行が楽しめます』
と言えるような、EVの走行フィーリングとハイブリッドカーの実用性の両方を兼ね備えるマシンを目標にし、本当に作ってしまったのだと思っています。
*1:ピニオンギアをプラネタリーギアと書いている資料もあります。遊星歯車機構を太陽系に見立てる場合、このギアが惑星に相当するので、プラネタリーギアと呼ぶほうが理解しやすいのですが、遊星歯車機構全体を差す“planetary gear mechanism”とごっちゃになるので、あえてピニオンギアで通すことにします。
*2:2021年現在、アイドリングストップはそこまで燃費や環境負荷に関与しないという話が出てきています。
MSXturboR（新CPU:USO800搭載）
Sorry, this article is written as a joke:)
MSXturboR（エム・エス・エックス・ターボアール）は、パソコンの国際規格であるMSXの一つ。
目次
- 概要
- FS-A1GT
- FS-A1STとFS-A1BT
- FS-A1ST
- FS-A1BT
- バージョンアップアダプタ
- オンラインサービス
- 追記
- 追記(2021年)
概要
1990年に規格が策定されたMSXturboRは、新開発のZ80バイナリ互換高速CPU「R800」と従来のグラフィックチップV9958を劇的に高速化（およそ20倍）させた新VDP「V9909」を組み合わせることにより、既存のMSX用ソフトウェアを1バイトも書き換えることなく高速に動作させることを可能とした。
FS-A1GT
1990年10月には、松下電器産業（現パナソニック）より、最初のMSXturboR規格マシンとなる「FS-A1GT」（以下、A1GTと省略する）が発売された。定価は89,800円(消費税を含まない額)であった。
A1GTの「GT」は「GUI Turbo」の略とされている。メインメモリを512kB搭載したほか、GUIソフトウェア「MSXView」をROMに搭載し、MSXViewの操作に必要なマウスを標準装備とした。
32ビットパソコン市場においてもGUIが珍しい存在だった当時としては、本体を購入するだけでGUIとマウスオペレーション環境が手に入ることは非常に画期的なことであった。
MSXViewは、HAL研究所が1987年にMSX2向けに開発したGUI「HALNOTE」をMSXturboR向けに転用したものであった（従来のHALNOTE用のアプリケーションもMSXViewでも動作させることができた）。
MSXturboRの「従来のMSX用ソフトウェアをコードを書き換えることなく高速に動作可能」という利点を生かし、HALNOTEのMSXViewへのバージョンアップはMSX-DOS2への対応など最小限のカスタマイズで済んだため、MSXturboRの販売価格を抑えたままMSXViewの標準添付を可能とした。
処理速度的に非力なMSX2上ではとても実用に堪えなかったHALNOTEであったが、MSXViewとしてMSXturboR上で動作することによって、ようやく本来の実力が発揮されたといえる。
MSXViewはROMで供給されたため、同じくROMで供給されたワープロソフトや日本語入力システムとともに、軽快な操作環境の実現に寄与した。
当時は、一般的なビジネス用途向け32ビットパソコン（NECのPC-9800シリーズなど）の市場においてもハードディスクドライブがほとんど普及しておらず、ワープロソフトや日本語変換システムがフロッピーディスクで運用されていたため、MSXturboRの操作応答性がビジネス用途パソコンのそれを上回るという逆転現象が発生した。
MSXView用のソフトウェアとして、表計算ソフト『ViewCALC』、ドローソフト『ViewDRAW』などがMSXturboRと同時に発売された。また、MSXturboRに内蔵されたワープロソフトについても、これらのMSXView用ソフトと連携させるための改良が加えられた。
いずれのソフトウェアもGUIによるマウス操作が可能であった。
MSXViewおよびそのアプリケーションに対して、既存のMSXユーザーの目は冷ややかであり（彼らがMSXを所有する目的は、ホビープログラミングか、そうでなければパソコンゲームのプラットフォームとしてであった）、彼らはMSXturboRを単に速度が速くなっただけのMSXとしか捉えなかった（もちろん、ホビープログラマは処理速度の高速化の恩恵に与れたし、それまでのMSXのスペックでは移植が不可能であった他機種向けゲームがMSXturboRに移植される事により、MSXをゲーム機として利用する層もその恩恵を享受することができた）。
しかし、実用ソフトが快適に動作し、しかもマウスによるGUI操作が可能となったMSXturboRは、『速い・安い・うまい』を合言葉に松下とアスキーが行なったキャンペーンにビジネス誌が乗りかかる形となり、一大センセーションを巻き起こした。
MSXのFDDで採用されていたMSX-DOSフォーマットが、もともとビジネス用途パソコンで使われていたMS-DOSフォーマットと互換性があったことに加え、ビジネス用途パソコンのFDDが5インチから3.5インチに移行しはじめていたことも、元々3.5インチFDDを採用していたMSXに味方した（ビジネス用途パソコンでは2HDディスクが使用されていたが、MSXでフォーマットした2DDディスクの読み書きが可能であったため、コンバータソフトなどを用いずとも相互にファイルの交換が可能であった）。
当時、一般的なビジネス用途パソコンと必要なソフトウェア（ワープロソフトなど）一式を揃えようとすると、フロッピー運用であっても一般的なサラリーマンの月収の2倍程度の投資を必要としたため、個人でビジネス用途パソコンを購入することには様々な制約があった。
ところが、MSXturboRで同じ環境を揃えた場合、ビジネス用途パソコン一式の1/3程度の投資で収まったため、MSXturboRは従来のMSXユーザーの大多数を占めたホビーユーザーだけでなく、それまでパソコンの購入をためらっていたビジネスマンや中小・零細企業へ一気に広まった。
このため、それまでMSXを『おもちゃ』などと呼称して見下していたビジネス用途パソコンユーザーが、会社ではビジネス用途にMSXを使い、自宅ではビジネス用途パソコンをホビー用途に使うという逆転現象が発生し、そのようなユーザーが悔し紛れにMSXturboRを『プアマンズMac』と呼ぶことがしばしば見られた。
A1GTはホビーユーザーに限っても10万台程度販売され、縮小傾向にあったMSX市場において久々のヒット作となった。なお、同時期にX68000シリーズの累計販売台数が10万台を突破している。
FS-A1STとFS-A1BT
A1GTの成功に気をよくした松下は、1991年10月に新機種「FS-A1ST」「FS-A1BT」の2機種を同時リリースした。
FS-A1ST
FS-A1STの「ST」は「Standard Turbo」の略とされている。
A1GTからMSXViewを含む添付アプリケーションおよびA1GTでは標準添付であったマウスを省略したものであり、ホビーユーザーをターゲットとした廉価版MSXturboRの位置づけであった（内蔵メモリなどハードウェア上のスペックに差異はない）。定価は74,800円(消費税抜き)であった。
FS-A1BT
FS-A1BTの「BT」は「Business use Turbo」の略とされている。
メインメモリが1MBに増加し、2DDフロッピーディスク対応FDDを2台搭載（A1GT・A1STにも基板上に未使用のFDD接続用パターンが存在し、それを利用してFDDを増設するユーザーもいた）で発売された。MSX史上初のメガバイト単位メモリ搭載機種となったほか、RS-232C端子、MIDI端子、アナログRGB15ピン端子を標準装備した。
RS-232C端子を搭載したことでモデムを接続可能となり、パソコン通信のほか、株式投資、馬券のオンライン購入、オフィスのFAX自動送信ソフトなどに利用された。
アナログRGB15ピン端子にはアップコンバートされたビデオ信号が出力（インタレースモードにおいては424ライン）されており、当時一般的だったPC-9801用モニタを接続することで、クリアな画面表示を実現した。
定価は128,000円であり、MSXとしては久々の10万円を超えた機種となった。なお、当時EPSONから発売されていたPC-9801シリーズ互換機「PC-286C」の定価が168,000円であった。
オンラインサービス
1992年には既存のMSX向けオンラインサービス「THE LINKS」の上位版として、MSXturboR専用のオンラインサービス「Turbo Links」が開始された。
サービスの利用には、モデムの他に専用の通信ソフトが必要とされたが、グラフィカルな画面でオンラインサービスの利用が可能であった。
ユーザーは Turbo Links 上で自分の分身となるキャラクターを操作し、電子掲示板の読み書きやチャットのほか、コナミの協賛によるオンライン対戦ゲームを行なうことができた。
ゲームのソフトウェアは、オセロや将棋などの小規模なものはオンラインで提供されたが、グラフィックなどを含む「重い」ゲームはフロッピーディスクやROMカートリッジで供給された。
特に、Turbo Links 上のクイズゲームでは、1992年の段階でクイズ問題の追加とオンラインによる対人戦を実現しており、現在まで続くオンライン対戦型クイズゲームの嚆矢となった。
クイズ愛好家の間には、視聴者参加型クイズ番組の減少による不満が鬱積していた時期でもあり、このゲームのためだけにA1STとμ・PACKを購入するクイズマニアが少なからずいた。
当時は定額制のネット接続サービスが存在しなかったため、特に地方のユーザーにとっては通信料の負担が大きく、「みかか破産」（NTTに高額な電話代を請求され、支払えなくなること）するユーザーがあらわれて問題となった。
アーケード用クイズゲーム「クイズマジックアカデミーアーケード」シリーズに「アーケード」と付くのは、オリジナル版が Turbo Links 上で運営されていたことの名残りである。
この「MSXturboR」を書こうとした人は途中で寝てしまいました。続きは自分で執筆してください（PJ コンピュータ / Portal:コンピュータ）。
MSX2がワークステーションになった日。HALNOTE
MSXのソフトの中では顧みられることが少ない、実用ソフトをあえて紹介してみます。
統合化ソフト『HALNOTE』
目次
概要
HALNOTEは、MSX2用のGUI環境と各種アプリケーションを含む統合化ソフトです。
HALNOTEには、以下の要素がまとめてパッケージされています。
- GUI環境『HALバインダ』（一般名詞として『デスクトップ』とも）
- ワープロ『日本語ワードプロセッサ』
- ドローソフト『図形プロセッサ』
- テキストエディタ
- デスクアクセサリ（カレンダー・メモ用紙・電話帳・時計・ユーティリティなど）
こんにち、Linuxディストリビューションをダウンロードすると、OSやデスクトップ環境からオフィススイートまでがセットになっていますが、それに近いといえます。
当時、主にPC88を扱っていた矢野徹氏（SF作家・翻訳家）は、こう記述しています。
十月二十日（月）
HAL研究所というところから、MSX用のHALNOTEというデスクトップ・アクセサリーが発売されるらしい。かつて＜ハルノート＞という強硬な対日文書があったことを思い出す。それはともかく、マッキントッシュの便利さがやっと輸入されてきたのか。5Mバイト*1のROMカートリッジを使い、アイコンを使い、電卓、カレンダー、時計、スケジュール手帳、電話帳、住所録、メモ帳、ワープロ、CGツール、通信ソフト*2、音楽ツール*3、データベース・ソフト*4など、なんでも入っているという。これを88や98用にも作るといいのに。
矢野徹 『ウィザードリィ日記 熟年世代のパソコン・アドヴェンチャー』角川書店 p.155
当時はユーザーの要求に対してパソコンの性能が不足していた（MSXに限らずビジネス向けパソコンですら！）こともあり、PC-98シリーズですらビジネスソフトでは極力グラフィックを排除しテキスト表示で済ませることで高速な動作を目指していた時代でした。
その正反対をMSXで実現してしまったことのインパクトは、想像に難くありません。
HALNOTEの説明を本から引用すると、こんにちでは
の一言で済んでしまいます。
しかし、マウスオペレーションが一般的でなかった当時は
- 独立した別々のソフトを、
- グラフィカルな画面とマウスオペレーションによって、
- 統一された操作体系で利用することができる環境
であることを説明するのに大変苦心したようです。
MSXマガジンの特集記事では、HALNOTEのジャンルである『統合化ソフト』を説明するにあたって
複数のツールを一括管理して動かし、相互のデータをやり取りするという環境
と紹介したうえで、マウスオペレーションについては、
あろうことか、『HALNOTE』ではあらゆる操作がマウスひとつで実行可能だ。この操作性の良さは、既存の上位統合化ソフトにもなかなかないものだ。
（中略）
パソコンを使い込んだ人は、マウスと聞くと首をひねるかもしれない。マウスは初心者には確かに便利だが、上級者にはかえって時間がかかるし、面倒なものとされているからだ。
でも心配はない。マウスを使わずにコマンド入力でもHALWORDは操作可能だ。初心者向けとか上級者向けとかにこだわらない、オープンな設計思想が感じられる部分である。
MSXマガジン1988年1月号 p.80-83
と、時代を先回りした擁護をしています。
Windowsの普及により、仕事で猫も杓子もマウスを使わなければならない時代はまだ先の話でした。
HALNOTEはソフトウェアとしての規模が大きかったほか、規格化されていなかったMSX用漢字変換システムのブラッシュアップに時間がかかり、発売延期を繰り返すなど、難産の末の発売となりました。
なにしろ、HALNOTEの開発当初は漢字変換と言えば単漢字変換が一般的だったものの、完成する頃には連文節変換でなければ競争力が得られない世の中になっていたのです。
当時の広告では、力強くこう宣言しています。
画面写真
HALNOTEのメイン画面となる、HALバインダ（デスクトップとも）です。
ファイルの一覧が表示されます。
このメニューはタイトルメニューと呼ばれ、画面左上のタイトルをクリックするか、SELECTキーを押すことで開きます。
メニューの項目が、縦1列固定ではなく所々が2列だったりするのが特徴的です。
見慣れない項目名が並びますが、意味するところはWindows風に言えば以下のとおりです。
- ≪A≫≪B≫：ディスクドライブの選択
- 読込：選択したファイルを開く
- 記録：選択したファイルのプロパティを表示
- デスクトップの保存：ファイルの位置やアイコンなどの状態を確定する（これをしないとアプリケーション実行後やHALNOTE再起動時にアイコンの配列が元に戻ってしまう）
- ディスク状態：ディスクドライブのプロパティを表示
- フォーマット：フロッピーディスクをフォーマット
- 印刷形式：用紙サイズの設定
- 印刷：選択したファイルを開き、印刷する
- 終了：HALNOTEを終了し、MSX-DOSに戻る
ディスク状態の実行結果です。
ルートに置けるファイル数は112個まで、階層化ディレクトリもない時代です。
日本語ワードプロセッサ（GUI上では筆記用具、記事等ではHALWORD）の画面です。
フォントサイズ指定ができたほか、欧文では何種類かのフォントが利用できました。
まだ単漢字変換ワープロが残っていた時代に、エルゴソフトが開発したEGBRIDGEベースの連文節変換とROMに搭載された6万語の辞書により効率的な漢字変換を実現しています。
この漢字変換システムは俗にソニー・HAL研系とも呼ばれ、松下・アスキー系（VJEベース）の漢字変換システムより賢かったと言われています。
（注：写真の文書は適当に書いたもので「ディスクキャッシュメモリとして」の部分の確証はありません）
欧文はプロポーショナルになっており、“Illegal function call”の文字幅が違うのが確認できます。
これらは今では当たり前のことですが、当時の日本語ワープロは等幅フォントが当たり前でした。また、文字を大きくするといえば倍角とか四倍角がせいぜいで、文字をちょっとだけ大きくする、なんてことはできませんでした。
そんな時代にWYSIWYGを実現してしまったので
『画面の文字が小さいから拡大表示したつもりが、無駄にでかい字で印刷された。どうなってるんだ』
とクレームが入るなど、理解されるのも難しかったようです。
なにしろ、HALNOTEがお手本にしたMacintoshですら、登場した頃にはこう言われていたのです。
- 『フォント』などというものを知っている一般ユーザーがいるのだろうか
- 書体のポイントサイズや、可変ポイントサイズの価値を理解できるビジネスマンがいるのだろうか
文書中に図形を入れることができます。
現実的には、当時のビジネスマンや学校の先生が原稿に図形を入れたいときは、ワープロ上では場所だけを確保しておいて、印刷してから物理的に切ったり貼ったりしていたと思います（その方が早かったのです）。
附属の図形プロセッサ（GUI上では製図用具、記事等ではHALDRAW）の画面です。
作成した図形データは、別売の通信ソフト（GTERM）で送受信することができたようです。
日本語ワードプロセッサ上でデスクアクセサリの一覧を表示させている状態です。
HALNOTEはマルチタスクでこそありませんが、メインとなるアプリの実行中に、デスクアクセサリと呼ばれる小さなアプリを一時的に起動することができます。
図形プロセッサの実行中に、デスクアクセサリのカレンダーを起動してみました。
おおっ、2000年問題に対応している！
カレンダーには、予定を書き込むことができます。
アプリケーションは、他にも別売ソフトとして
等がありました。
このうち、直子の代筆は他社（テグレット技術開発）が開発、販売していました。
ハードの限界へ
当時のMSXの限界に挑戦したHALNOTEでしたが、MSXのハードウェア環境に対して頑張りすぎてしまったため、『遅い』と言われたようです。
ディスクアクセスの解消にはHAL研も努力したようで、HALNOTE実行用ディスクに入れてある文書（上）ファイルには
HALNOTE実行中はディスクのバッファリングを行っていますので途中で電源を切ると最悪の場合ディスクが壊れます。
と書かれています。つまり、フロッピーディスクに対してキャッシュ動作（それもライトキャッシュ）を行っていたようです。
当時のパソコンは、何も考えずにいきなり電源を切って終了させるのが普通だったので、使いにくさを感じた人もいるかもしれません（HDDを使用している場合は、電源を切る前にヘッダをシッピングゾーンに退避させる必要があったため、HDDを持っていたブルジョアは所定の操作を行う、というのがせいぜいでした）。
ディスクキャッシュ用のメモリをどこから確保していたのかがよくわからず、
があるようです。
本体のメモリを使っていた場合、当時のMSX2の上位グレードではメインメモリを128kB以上積んだ機種があったので、そういった機種では潤沢なメモリをディスクキャッシュに使えたのかどうかも気になるところです。
MSX2の上位グレードにはZ80互換の高速CPU(日立HD64B180)を積んだVictorのHC-95といった機種もあったので、HALNOTEと協調して発売できていたら面白いことが起こっていたかもしれません（当時、そういった広告があった気がするのですが見つけられなかった）。
なお、HC-95は産業用としてかなり後まで出荷していたようで*6、見たことがある範囲では大学の講義室のブラインドの制御に使われていました。
レスポンスの悪さというものは得てして主観的なものであるので、例えばCPUやディスクアクセスの速度がきっちり2倍のMSXを用意して、その上でHALNOTEが2倍の速度で動いたとしても、遅いという人は一定数いたはずです。
とんでもなく高速な今のパソコンでだって、ビジネス文書を作成する際にいきなりWordで書かずに、まずテキストエディタで下書きを行なう人は一定数います（よね？）
遅いのがどうしても嫌なら、当時数万円のMSX2ではなく100万円出してフルセットのMacを買えばいいだけの話でした（それですら、今のパソコンのようなレスポンスは恐らく望めなかったでしょう）。
MSXマガジン1988年1月号の特集記事では、
これだけ盛りだくさんの機能は、MSX2の性能を限界まで使い切った結果、実現された。そのために、さすがに各所でレスポンスの悪さが気になる。しかし、統合化ソフトウェアをMSX2上に実用レベルで実現し、しかも随所に従来のソフトを上回る機能を発揮しているという点で『HALNOTE』は期待にたがわぬ、MSX2の未来を目の当たりにさせてくれる注目作品である。
と締めくくっています。
後にHALNOTEはMSX turbo Rに最適化され、MSXViewという名前でアスキーから発売されました。
MSX turbo Rの最終機種となったFS-A1GTでは、
- MSXViewシステムのROMドライブ化
- まとまった容量のRAMディスク
- R800CPU搭載による動作速度の高速化
などの恩恵もあり、快適に動く本当のHALNOTEが実現しました。
これこそが、当時のMSXマガジンがHALNOTEに見た『MSX2の未来』なのかもしれません（せっかくのHALWORDは、松下MSX内蔵ワープロと機能がかぶるせいか移植されませんでしたが…5.38MHzモードをこっそり搭載してちょっぴり速くなった松下製MSX2+とHALNOTEのタイアップなどといったことも、特になかったと思います）。
そして、PC-9801ユーザーが漢字変換の度に5インチフロッピーディスクドライブをガチャンガチャン言わせながら一太郎を使う横で、MSXユーザーがGUIベースの表計算ソフトをサクサク使う…みたいな光景も、日本のどこかには実在したかもしれません。
実験
MSX turbo RでHALNOTEを高速に動かすことに挑戦してみました。
もしMSX-DOS2上でHALNOTEが起動してくれるのなら、HALNOTEのフロッピーの中身を全部RAMディスクにインストールすれば、R800CPUの速度と掛け合わせて爆速での動作が期待できます。
しかし、どうしても動いてくれませんでした。
Twitterにて
HALNOTEのver1.2はDOS2に対応しているはず
との情報を提供いただいたのですが、
などと、疑うところが多すぎるのです。
あきらめてR800CPUで動かすことだけを考えるのならば、MSX-DOS(1)を立ち上げて、CPUをZ80からR800に切り換えてからHALNOTEを起動すれば速く動きます。
この状態で、HALWORDでディスク上のフォントを使うと再描画の度にフロッピーにアクセスしまくりますが、ディスクアクセスさえなければそれなりに速く動きます。
本来、MSX-DOS(1)をR800CPUで動かし、フロッピーディスクにアクセスすることは動作保証されていません。
ただ、試した範囲ではファイルの保存も含めて誤動作する様子は見られませんでした。
1chipMSXの10MHzモードはR800CPUほどは速くありませんが、内蔵SDカードドライブがフロッピーディスクイメージに対応しているので、これと1chipMSXの10MHzモードを組み合わせると、いい感じで動きます。
やっぱりストレージの速度は大事なようです。
HAL研、茲に戦を宣す
ご存じのとおり、HAL研はその後紆余曲折を経たものの、今なおメジャーなゲームメーカーとして現存しています（パソコン関連の部署は清算されてしまいましたが…）。
また、マイコン黎明期からの天才プログラマであり、当時HAL研の開発部長だった岩田聡氏は、その後任天堂の社長に就任（しかも初の山内家以外からの就任）し、業界のトップで大活躍したものの、惜しまれつつ早逝してしまいました。
そのずっと以前に名付けられた、HALNOTEという挑戦的なネーミングは、
かつて＜ハルノート＞という強硬な対日文書があったことを思い出す。
『ゴーマニズム戦争論』にでも出てきそうなネーミング
ゾルゲ市蔵 『謎のゲーム魔境3』 キルタイム・コミュニケーション p.109
と指摘されますが、HAL研究所発行のユーザ向け会報の名前が『LAB LETTER』だったのと同じく、ただのしゃれだったのだと思います。
しかし、あえてHAL研究所による宣戦布告と捉えるとすれば、誰に対する宣戦布告だったのかを考えてみるのも楽しいかもしれません。
