目次
前のページ
2016-05-31 色数と VRAM 構造
2016-05-31 WEBセーフカラー
2016-06-06 テトリス完成(1984)
2016-06-07 アラン・チューリング命日(1954)、ドナルド・デービス誕生日(1924)
2016-06-09 8086 発表日(1978)
2016-06-16 Jewels 2017
2016-06-16 Scratch の舞台裏
2016-06-20 顔文字 (^_^) の生まれた日(1986)
2016-06-24 【訃報】長谷川五郎さん
2016-06-30 Comet
2016-07-01 PHSサービスが始まった日(1995)
2016-07-07 ドナルド・ミッキー 命日(2007)
2016-07-11 岩田聡 命日(2015)
2016-07-12 Chromebook購入
2016-07-12 Chromebook で子供ができること
2016-07-14 監視ユーザーの問題回避
2016-07-16 ダン・ブルックリン 誕生日(1951)
2016-07-31 PowerPC 発表(1991)
2016-08-01 Microsoft Office 発売日 (1989)
2016-08-03 【訃報】シーモア・パパート
次のページ
FM-77AV や X1turboZ は、白黒画面を 12枚も持つ形で 4096色の画面表示を実現していた、という話を１年前に書いた。
今更その関連話題を書きたくなった。
まず、以前の話を、ざっと概要だけおさらいしておこう。
ここに書いてある内容、少し誤りがあります。近いうちに修正予定。
カラーテレビの信号方式（NTSC信号）の記述がおかしいようです。詳しい方から指摘ありました。感謝。
僕自身、ソフト屋なので VRAM 構造までは理解しているのですが、そこから先の動作はちゃんと理解できていません。
勉強しながら書いた形ですが、理解不足でした。お詫びいたします。
8bit 機の時代は、メモリが２つの意味で貴重だった。
今よりもビット単価が高く、メモリは高価なものだった。
そして、CPU から扱えるメモリ空間はたった 64KByte で、画面表示用メモリ (VRAM) を多く搭載するわけにはいかなかった。
そこで、一般的には CPU から扱えるのは白黒画面とした。
640x200 の解像度で、白黒２値なら 16Kbyte 。
これを何らかの方法で「複数画面」もつ。
色つきのセロファンを重ねればいろんな色を出せるように、色付きの白黒画面を重ねて多くの色を出そう、という発想だ。
CPU からは特殊な方法で、アクセスできる画面を選ぶようにする。
同時に１つの白黒画面しか書き換えられない代わりに、占有するメモリ空間を少なく抑えられる。
３画面重ねれば８色、４画面重ねれば 16色を出せる。
でも、FM-77AV や X1turboZ では、なんと 12画面も重ねて、4096色を表示した。
320x200 ドットという、比較的荒い解像度にも関わらず VRAM だけで 96KByte も必要だし、１ドット変更するのに 12回もアクセスする必要があるので画面表示も遅い。
綺麗な画面が出せる、というメリットはあるが、あまり実用的ではなかったように思う。
ところで今回は、人間の目の特性を利用して画像データを圧縮する、というような話が中心になる。
そのため、目の特性について知っておく必要がある。
恐竜が闊歩する時代に、安全な夜間のみ行動する、夜行性のネズミのような生物がいた。
これが哺乳類の祖先だ。
夜行性なので、わずかな光でも捉えられるように目が進化した。その反面、色の違いを見分ける能力が失われた。
今でも多くのほ乳類は色がわからない。
霊長類になり再び色を見分ける能力を取り戻したのだけど、実は目のほんの一部、視野の中央付近でしか色を捉えられない。
しかも、色を取り戻した部分は代償に光の感受性が落ちてしまった。暗い明りを見るときは、周辺視野のほうがよく見える。
人間の脳は、目の部分による感受性の違いをうまく利用していて、無意識に使い分けている。
常に目を動かし、感受性の良い周辺部で明確に捉えた形状と、色覚できる中央部でとらえた色を後から合成し、カラーで鮮明な世界を感じさせてくれる。
つまり、我々が「見た」と思っているものは、実は断片的な情報を重ね合わせた、合成画像だ。
もう一つ、アナログカラーテレビについても知っておく必要がある。
まず最初に、白黒テレビが実現された。
そのあとに、白黒と互換性を保ったまま、カラーテレビが実現した。
もちろん、白黒テレビを設計した時点では、後でカラー化することなんて考えていない。
テレビ電波としては白黒の「輝度変化」のデータだけを、べったりと送ってしまっている。
その信号の隙間を、半ば無理やり探し出して、何とか圧縮した色データを送る。
これがカラーテレビの仕組みだった。
白黒テレビの信号としては、十分なものが送られている。
だから、輝度の表現は十分だ。
ここに、圧縮して隙間に詰め込んだカラー信号を「載せる」。
白黒の絵を元に塗り絵をするような感じだ。
色だから R G B の３つのパラメータが必要なのだけど、それとは別にすでに白黒の輝度信号がある。
つまり、RGB を３つ揃えた場合の、「明るさ」はわかっている。
R G B の配合割合だけわかれば、元の RGB を再現できる。
配合割合なので、全体が 100% だと仮定すれば、２つわかれば残りの１つもわかる。
このような考え方で、カラー信号は ２つしかない。そして、白黒画像のドットの隙間に、交互に入れてある。
「交互」ということは、１ドットごとには色を変えることができない。
それでも、我々の目は輝度信号が正しい形を表現していれば、色が多少おかしくても違和感を感じない。
先に書いたように、もともと形と色を別々に捉え、脳内で合成しているためだ。
輝度信号と色信号が多少ずれていても、脳内で補正して正しい画像を認識してしまう。
さて、以上を前提に、AMIGA の話をしよう。FM-77AV や X1turboZ と同じく、4096色の表示ができる。
先の２機種と違って 16bit マシンなのだけど、先の２機種よりも前に発売されている。
（AMIGA:1985/7 FM-77AV:1985/10 X1turboZ:1986/12。X1のみ、発売日ではなく発表日）
この頃だと、メモリ空間の狭さは技術により克服されつつあった。値段もどんどん下がってはいた。
とはいえ、メモリはやっぱり高価なものだった。
そのため、AMIGA は先の２機種の半分の VRAM サイズで、4096色を表示する工夫が凝らされている。
基本は同じ、白黒画面を重ねてカラーを出す方式だ。
ただし、AMIGA では 4096色に必要な 12bit の半分、6枚分の VRAM しかない。
基本はこのうち４枚を使った 16色モードだ。
当時のコンピューターとしては標準的な構成。
そして、１ドットに対してあと 2bit を追加できる。
このとき、2bit は「モード」を示すフラグとなる。
2bit あるのだから、４つのモードがある。
１つ目は、4bit をパレット番号として使い、あらかじめ 4096色中から設定しておいた 16色を選び出すモードだ。
これも、当時のコンピューターとしてはごく普通。
あとの３つの画面モードは、それぞれ R G B と名付けられている。もちろん光の三原色の RGB だ。
R モードでは、赤の色成分だけを 4bit で指定する。
残りの GB は、直前に表示した左隣のドットの色を受け継ぐ。
G B のモードも同様だ。RGB のうち、どれか一つの色成分だけを指定し、残りは左隣から受け継ぐ。
RGB すべてを任意のものに変えるには、３ドットの幅が必要となる。
4096 色は本来 12bit 必要だけど、この方法で、半分の 6bit で表現できる。
AMIGA の後期機種では、24bit 必要な 1670万色を 10bit で表現するモードもあった。
ところで、AMIGA はテレビに接続して使うのが前提のパソコンだった。
先に書いたように、テレビでは色を急に変えることができない。
AMIGA の方式では「急に色が変えられない」のがデメリットになるのだけど、もともと色は急に変えられないんだ。
じゃぁ、VRAM が半分で済む、というメリットの方が大きい。
非常に美しい設計だ。
アナログテレビの特性を上手に利用した機種と言えば、Apple II (1977) を語らないわけにはいかないだろう。
Apple II では、横 280ドットの表示を行えた。
そして、基本的に白黒の VRAM しか持っていない。
アナログカラーテレビの仕組みとして、ドットごとの信号の「隙間」に、交互に色信号が入っていると書いた。
Apple II の回路は、ドットの「明るさ」の信号を出力する際に、この色信号の部分にまで信号を入れてしまう。
本当なら、信号が正しく送れていないダメ回路だ。
でも、これはわざとなんだ。
カラー信号は交互に入っている、と書いた。
しかし、ドットの輝度信号と一緒に送られてしまう。ということは、ドットを交互に描けば、色信号を制御できる。
偶数ドットだけを描いた縦縞を作ると、紫色になる。
奇数ドットだけだと緑色になる。
両方とも出力すると、白くなる。両方出さないときは黒だ。
Apple II では、さらにこの信号の位相をずらせるようになっていた。
白黒画面では、通常横 8dot を 1byte にするのだけど、横 7dot を 1byte にして、残り 1bit を位相ずらしのフラグにしたんだ。
位相がずれると色情報がずれる。青と橙になった。この場合も、白と黒は同じように出せる。
これにより、Apple II では黒、白、紫、緑、青、橙の６色を出せるようになった。
カラーなのに VRAM は白黒１画面分しかない。
画面表示を変えるときに書き換える VRAM も最低限で済むので、非力な CPU でもアクションゲームに強かった。
ちなみに、カラーテレビでなく白黒テレビに表示を行うと、位相をずらした部分だけ、ドットが半分ずれる。
上手く使えば横方向の見た目上の解像度を上げられる。240dot の解像度しかないのに 480dot のように見えるんだ。
これにより、細かな図などを表示できるため、ビジネス分野でも使用された。
工夫したことで少メモリになり、安く本体を提供できるから普及し、非力な CPU でもアクションゲームが作れたのでゲーム機としても普及し、白黒モニタできれいな画面が出せたのでビジネスマシンとしても普及した。
Apple II が強かった理由の一つだ。
PC-6001 でも白黒モードを同じような技法でカラー化できた。
もちろん、家庭用テレビに接続している時だけ。
Apple II のような「位相ずらし」はないので、４色出せることになる。
白黒モードなので、AppleII と同じ理由でアクションゲームに向いている。
PC-6001mkII のスペースハリアーでもこの画面モードを使っているのだけど、僕の友人宅には専用モニタがあったので白黒だった。
専用モニタに送られる信号は、テレビ信号のような「情報の圧縮」を行わず、VRAM に書いた通りのものを正確に描画してくれる。
本当はそれが正しいのだけど、テレビの特性をうまく使ってカラーを出すようなゲームでも、正確に白黒描画してくれる。
高価なモニタ使っているほうが貧弱な画面になる、というのが当時は不思議だったのだけど、こんな理由だったと後で知った。
MSX や SG-1000 で使用されている画面表示回路は、Apple II よりも後に設計されたものだ(1981)。
Apple II の考え方をもう少し汎用的にする形で 16色表示を実現している。
やはり、ドット表現としては白黒と同じだ。ただ、MSX では横８ドットごとにもう 1byte 使い、bit が 0 の時と 1 の時の色を決められる。
1byte = 8bit の中に２色を表現したいのだから、１色は 4bit 。16色の中から選ぶことになる。
Apple II よりも２倍の VRAM を使ってしまうが、色数は２倍以上に増えるし、自由な位置にドットを打てる。
（Apple II では、色とドット位置に相関関係があるので、好きな色で好きな位置にドットを打てない）
ここら辺、詳しい話は過去に書いたので、気になる人は参照してほしい。
MSX2 (1985) では 256色表示のモードができたのだけど、特記するようなことはない。
RGB を 3:3:2 bit で表現する。
合計 8bit 、1dot = 1byte の、とてもシンプルな方式だ。
MSX2+ (1988) では、この 256色モードと同じ VRAM 容量で、１万９千色を出せる。
自然画モードと呼ばれるのだけど、この方式は巧妙だ。
カラーテレビと同じように情報を圧縮する。だから、ベースとなるのは「白黒」の画面だ。
１ドットに付き 32階調、5bit の輝度情報を持つ、白黒画面を持っている。
これだけでも、当時普通だった「16色しか出ないパソコン」には真似のできない階調表現だ。
でも、１ドットに付き 5bit しか使わないのだから、3bit あまる。
横２ドット分で 6bit になる。４ドットあれば、6bit を２組作れる。
12bit ではなく、6bit ２組、というのが大切だ。
カラーテレビがそうだったように、RGB のうち２つの色の割合を示せる。これで色が決定できる。
カラーテレビでは、横２ドットで１つの色を作り出していた。
MSX2+ の場合、横４ドットなので、色のにじむ範囲がちょっと大きい。
でも、最初に人間の目の仕組みとして説明した通りだ。
輝度信号さえ正しければ、色が多少おかしくても気にならない。
僕が知っている中では、一番巧妙で複雑な VRAM 構造だ。
今はメモリが安くなったので、こんな複雑な構造の VRAM は使わない。
１ドットに 32bit あれば、 RGB に透明度まで加えて表現できる。
ハイビジョンサイズだって 8Mbyte ぽっちだ。今のメモリ容量なら誤差みたいなもの。
でも、人間の目の特性を活かした巧妙な圧縮方法は、今でも JPEG や MPEG の中で生き続けている。
関連ページ
別年同日の日記
11年 Smalltalk,Squeak, Etoys, and Scratch!
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
VRAM の話書いていたら急に思い出した、オマケの話。
WEB の黎明期、まだ Netscape が標準的な WEB ブラウザったころ、WEB セーフカラー、というものが存在していた。
今でもこの単語を調べれば解説しているページがたくさんある。
でも、どうも書いてあることがおかしい。
すでに失われた技術なので、なぜこんなものが存在したのか覚えている人があまりいないようだ。
・Windows でも Mac でも表示できる色を選んだものだ、という話があった。
・各ブラウザごとに使える色が違ったので、その共通色を選んだものだ、という話があった。
・この色を使えばディザリングなしに表示できるのだ、というような話があった。
そんなことはない。これ以外の色を選んだって、ちゃんと表示は出来た。
ただ、表示は出来るけど悲惨な副作用が待ち構えていただけだ。
Machintosh に 1bit の白黒時代があったことを忘れてはならない。
「すべてがグラフィック」という機械は、VRAM を大量に消費する。
メモリが高価だった時代、そんなに大量のメモリを使うと機械の値段がバカ高くなってしまう。
だから、最初の Mac は白黒だった。
でも、内部のソフトはカラーに対応していた、という有名な話がある。
ソフト的にはカラー対応なのだけど、「メモリが高価だから」白黒になっていただけなんだ。
後で無理なくカラーに拡張され、16色表示できるようになった。
Windows だって、最初は 16色からだった。
そして、Win も Mac も、256色表示できる時代がやってきた。
ちょうどそのころ、WEB が流行し始めたんだ。
たとえば MSX2 は 256色表示ができた。ここでは、RGB を 3:3:2 bit で表現する固定 256色だった。
でも、Win も Mac ももっと自由だった。使える色はたしかに 256色なのだけど、4096色とか、1670万色の中から選ぶことができた。
ただ、一つ問題があった。Win も Mac も、マルチウィンドウだったんだ。
あるウィンドウで、256色の絵Ａを表示したとする。ちゃんと表示できる。
別のウィンドウで、256色の絵Ｂを表示したとする。これもちゃんと表示できる。
ただし、さっき表示したウィンドウの絵Ａは、パレットが変更されて酷いことになっている。
Ａのウィンドウをアクティブにすると、Ａの色は元に戻る。代わりにＢが酷いことになる。
これは 256色同時発色の宿命だ。仕方がない。そんなもんだ。
見ようと思ったときには正しく表示できるのだから、まぁ諦めよう。
でも、WEB ではもっと困ったことが起こった。
ひとつのウィンドウの中に、絵が複数表示されるんだ。
最後の絵だけが正しい色合いで、後はぐちゃぐちゃ。
または、最初の絵だけが正しかったり、すべての絵を表示しようと努力して、減色を行ったり…
まぁ、そこらへんは環境依存。
ブラウザだけでなく、OS にもよる。いずれにせよ正しく表示されない。
実は、もっと困った問題だって起きる。
256色で絵を表示されると、ウィンドウの枠とか、メニューの文字とかの色まで変わってしまうのだ。
だって、画面全体で 256色しか使えないのに、絵を表示するために全部のパレットを変えてしまうのだもの。
この説明だけで理解できたと思うけど、必要なのは「すべての絵が同じパレットで描かれている」ことだった。
同じであれば何でもいい。ただ、世界中の人に同じパレットをつかおう、と提案するのだから、それなりに「公平な」ものでないといけなかった。
これが WEB セーフカラーだ。
全部で 256色しか使えない、とわかっている中で、誰もが使いやすいように満遍なく色を決定したい。
RGB の３つのパラメーターの掛け合わせで色が作られる。
１つの色で何階調使えるかは、256の三乗根を求めればいい。
∛256 = 6.349…になる。
だから、RGB 各６段階に設定する。6^3 = 216 で 40色ほど余るけど、これはむしろ好都合。
ウィンドウの枠などを描く色が確保できるからね。
階調が 8bit指定（RGB で 1670万色）だとすれば、00 33 66 99 CC FF の６段階を使えばいい。
4096色から選ばれるようなシステムの場合、適切に変換して、とにかく等間隔の６段階があればいい。
WEB セーフカラーではなくなるけど、256色しか使えないシステムで、ウィンドウの枠とかはないので 256色全部使って良くて、でも同時に違う絵を重ね合わせたりするので使われるパレットは共通化したい…
ゲームなんかではそういう用途が想定される場合があったのだけど、その場合は余った 40色にも色を詰め込んでいい。
R G B と Grayscale の４種類の、次の 10段階のグラデーションを詰め込んでいるのを見たことがある。
11 22 44 55 77 88 AA BB EE DD
間がとびとびだけど、その飛んでいる部分は、ベースとなる 216色に入っている。
だから、10段階追加しただけで、16段階のグラデーションが表示できるようになる。
巧妙に作られたパレットに感心した覚えがある。
どうせオマケ話なので、思い付きでどんどん横道にそれていこう。
「WEB セーフカラーをつかえればどんな環境でも表示で来た」というのは嘘で、MSX2 のような 256色固定表示の WEB 環境も当時普及していた。
i-mode を初めとする、ネット接続可能な携帯電話の、カラーが使えるようになった第二世代。
ほんのわずかな期間で、固定ではなく 4096色などを表示できるものに変わっていくのだけど、当初は固定 256色だった。
そのころに携帯電話の仕事をしていて、僕がプログラムを作り、知人がドット絵を描いていた。
RGB 3:3:2 の固定だと、グラデーションを描くのもままならない。階調が少ない青が邪魔するのだ。
パレットが使えないっていうのは、色表現に想像以上の制約を与える。
それらの携帯電話では、一応普通の WEB ページだって表示できた。
WEB セーフカラーで描かれた絵は、固定カラーに無理やり変換され、ディザリングされた。
非常に珍しい環境だから、見られないことを怒るわけではない。
ただ、「WEB セーフカラーだったら表示できる」と妄信してはいけない、という具体例として挙げたかっただけ。
関係ないついでに。
当時の国際的な定義では、ネットに接続できる携帯電話を「スマートホン」と呼んだ。
世界初のスマートホンは i-mode だ。
でも、世界的に「スマートホン」って概念が普及したころには、日本では i-mode は当然だった。
だから、日本では言葉に特別な意味を持たせ、「QWERTYキーボードが付いている機械」をスマートホンと呼ぶようになっていた。
日本初のスマートホンは W-ZERO3 だ。
今は…どう定義されているかわからない。
アプリをインストールできる機械？ それだと i-mode 時代でも可能だった。
キーボードが「ついてない」機械？ ついている機種だってあるけど、スマートホンと呼ばれる。
タッチパネルで操作する機械？
…本質ではないけど、これが一番、現在のスマートホンの定義にあっているような気がする。
関連ページ
別年同日の日記
11年 Smalltalk,Squeak, Etoys, and Scratch!
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今日は、テトリスが完成した日。
1984年の今日、最初のバージョンが完成した…のだそうです。
最初のバージョンは、ソ連製コンピューター、エレクトロニカ60の上で動いた、白黒のものでした。
エレクトロニカ60 は PDP-11 のクローン。
しかし、どうも証拠らしいものが見当たらない。
25周年の際にロイターがそう伝えた、という記事があって、それがほぼ唯一のソース。
ソ連の計画経済の中で、「仕事」の一環で作られたものなので、作業日誌でもつけていた可能性はあります。
でも、心理学の実験で使う予定のプログラムだから、必要ならいつでも手を加えたはず。
特定の日に「完成」なんて、決められないように思います。
だから多分、パジトノフがそう言ってたよ、って程度の世間話。
まぁ、1984年のこの頃に最初のバージョンが作られた、というのは事実だと思います。
当時は「対共産圏輸出統制委員会」（ココム）が存在していて、共産圏に 16bit 機は輸出できません。
ファミコンは輸出できるけど、メガドライブはだめ、なんて話もあったし、ソ連で MSX が普及した理由も同じ。
でも、翌年 1985年には、IBM-PC に移植されます。パジトノフはちゃんと IBM-PC を持っていた。
そして、夏ごろに知人にこのコピーをあげたら、いつの間にかヨーロッパ中の IBM-PC で遊ばれていた。
…ここからの話が、驚くほど壮大。
秘密のベールに包まれたソ連と、イギリスで暗躍するメディア王…ユダヤ人で、家族を虐殺された苦い過去を持つ男が強大な力をふるいます。
ATARI と、当時親会社だったナムコも絡み、セガと任天堂のテトリス権利問題も勃発する。
その一方で、日本の BPS 社長は孤独な戦いを始める。
彼は作者であるパジトノフと交流し、信頼を得ます。
ソ連政府も彼を信じて一計を案じる。
…そして、事態は急展開を遂げます。
ソ連の崩壊。メディア王の没落と、謎の多い死…
最後はパジトノフの手にテトリスの権利が戻ってくる。
壮大で、ハッピーエンドな物語。
くわしい話は、パジトノフの誕生日に書いていますので、そちらをご覧ください。
この話、すでにBBC作成のドキュメンタリーはあるのだけど、映画化の話も出ているみたい。
リンクした BBC のドキュメンタリーは、英語力がないので僕は見られていません。
映画化した際には、字幕でいいから日本語版を作ってほしい。ぜひ見たい。
テトリスの映画、と言っても ＳＦ映画とは違いますよ！
（これはこれで興味あるのだけど）
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今日は、アラン・チューリングの命日(1954)で、ドナルド・デービスの誕生日(1924)
この二人、関係が深いので一緒に紹介しましょう。
といっても、チューリングは誕生日の時に詳しく書いている。今日はデービスを中心とします。
チューリングはコンピューターの基礎概念を作った、と言われるのですが、計算機と概念はどちらが先か、微妙なところです。
計算機の自動化がある程度進められた時代背景があり、そこで「計算するとはどういうことか」を、仮想的な計算機を用いて説明しただけ。
この結果、どういう計算機を作れば汎用性が高いかが示され、それを目指して実際の計算機が作られていく…という流れ。
すでに職人芸で作られていたものに、学問的なお墨付きを与えたとでも言いましょうか。
チューリングマシン(1936)は重要な概念ではありましたが、「そのアイディアを基礎として計算機が作られた」わけではないのです。
＃ツーゼZ1の開発は1935年から、ABC の開発は 1937年から。
タイガー計算機は 1931年にはすでにあったし、その原型となるオドナー計算機は1874年に公表されている。
さて、時代的に計算機が作られ始めていましたから、チューリング自身、コンピューターに関する仕事もやっています。
1946年２月、チューリングはイギリス国立物理学研究所 (NPL)に、コンピューター製造計画の論文を提出します。
Automatic Computing Engine … ACE と名付けられたそのコンピューターは、人工知能を目指す計画でした。
これは、８月の ENIAC 公開よりも前に計画されたことでした。
もっとも、ENIAC は作成期間も長く、噂くらいは耳に入っていたのではないかと思いますが。
ACE は国家プロジェクトとなり、チューリングはその最高責任者でした。
そして、計画参加者の中にドナルド・デービスがいました。
デービスは、チューリングがチューリングマシンを想定した論文に、重要な誤りがあることを指摘しました。
詳細は、残念ながら僕は知りません。
「チューリングマシン」に与えるアルゴリズムによってあらゆる数が計算できることを示す部分で、アルゴリズムに穴があったようです。
「世界初のバグ」とも呼ばれています。
多少の穴があっても、そこは論文の本筋ではありませんが、「最高責任者」としての権威が揺らぎます。
重箱の隅をつつくようなことを言うデービスに対して、チューリングは不快感を示しました。
しかし、これは二人の性格の違いを示す、重要なエピソードのように思います。
ACE プロジェクトは、計算機にとって重要な「本質」を追い求めすぎ、肥大化します。
しかし、まだ当時の技術では、そんなに構想が肥大化したものは作れないのでした。
プロジェクトは頓挫しました。
チューリングは失望してプロジェクトを去りました。
しかし、これは国家プロジェクトです。止めるわけにいきません。
「作成技術」という現実を見ずに夢を膨らませて、うまくいかずに逃げ出したチューリングは無責任です。
その後、ジェームズ・ウィルキンソンが ACE プロジェクトを引き継ぎ、規模を縮小した「Pilot ACE」を作り上げます。
ドナルド・デービスは、Pilot ACE のプログラムを担当しました。
天才の論文に対しバグを指摘し、厳密さを重視する彼は、適役だったように思います。
デービスは、ロンドンの交通状況シミュレーションなどのプログラムを作っています。
Pilot ACE は後に量産され、1950年代に一番売れたコンピューターとなったそうです。
1950年ごろ、MIT でタイムシェアリング・システムが開発されます。
これにより、コンピューターに電話回線などでテレタイプを接続し、「時間貸し」ができるようになります。
また、コンピューター同士のネットワークも考案されていました。
コンピューター A にコンピューター B が接続するときは、時間貸しの端末と同じように、電話線を使って接続します。
A と C が接続するためにも電話線が必要で、B と C が接続するのにも電話線が必要です。
コンピューターがこのまま増えると、必要な線はどんどん増えることが予想されました。
コンピューター自体が高価なものでしたが、通信コストが馬鹿になりません。
しかも、これらの回線のほとんどは、「いつ通信があるかわからないので接続している」というだけで、ほとんどの時間、なんのデータも流れていないのです。
多数のコンピューターを、もっと少ない回線で結ぶことは出来ないか？
回線の利用効率をもっと高めることは出来ないか？
ドナルド・デービスはこの方法を考えます。
彼がたどり着いたのは、「パケット通信」と名付けた方法でした。
先の例でいえば、３台のコンピューター A B C が通信するには、 A-B 間、A-C 間、B-C 間の３つの回線が必要でした。
でも、A と C は、ともに B に接続しています。A-B と B-C の２つがあれば、B を介して A から C に通信ができるはずです。
それまでは、電話線の先にあるのが１台のコンピューターだったので、通信したいデータだけを送っていました。
でも、パケット通信では、一定のサイズのデータに区切り、それぞれのデータに「通信相手」を明記して送ります。
A から C に送るとき、途中で B が受け取りますが「C 宛」と書かれたデータはそのまま C に向けて再送信します。
もちろん、「B 宛」と書かれていれば受け取ります。
コンピューターが３台なら、３つの回線が２つに減っただけです。
でも、もっと多数のコンピューターがあったら…？
直接通信だと、１０台で４５本の回線が必要になります。
パケット通信なら、９本で十分です。
この通信方法は、現在のインターネット技術の基礎となっています。
ドナルド・デービスは、「パケット通信の父」なのです。
詳しい話はポール・バランの誕生日に書いていますので、そちらも読んでみてください。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今日は 8086 の発表日(1978)。
16bit 時代の覇者です。
僕としては、1980年代はまだ 8bit の時代だったイメージがあるので、70年代末にはすでに開発されていた、ということが驚きです。
8bit 時代の覇者は Z80 。
これはインテルの 8080 をベースに改良されたものですが、インテルからスピンオフした技術者が作ったザイログ社のものでした。
インテルとしては、あくまでも 8080 の「上位互換プロセッサ」として 8086 を作成します。
上位互換とはいっても、バイナリレベルでの互換はありません。
1978年の時点では、まだパソコンは普及しておらず、ソフト資産もないからね。
自分が作ったプログラムを、自分が作ったのだから理解していることを前提に、「ちょっと改良したら動く」で十分だった。
8bit から 16bit になっているのだから全然違うのですが、アセンブラのソースプログラムがあれば、レジスタ名や命令などを一括置換して再アセンブルすれば、８割がた動く、というあたりを目標に設計されたようです。
現実的な落としどころのように思います。
8bit CPU と互換性を持たせるため、メモリの構造に特徴があります。
8bit CPU では、8bit のレジスタを２本くっつけた 16bit のレジスタで、メモリアドレスを指定するのが普通でした。
この方法だと、64KByte のメモリ空間を持つことができます。
そして、8086 でも、16bit のアドレスレジスタでアドレスを指定します。
ただし、別のレジスタで「64KByte の起点となるアドレス」を指定できました。
これで、1MByte のメモリ空間の中から、任意の 64KByte を自由にアクセスできる、という構造を作り出しています。
ベースアドレスはプログラム中で変更可能なので、多少工夫すれば 64KByte を超えるデータだって扱えます。
8bit 資産も引き継げますし、16bit らしい大容量も扱える。
非常にうまい方法でした。
1978年の時点ではメモリも高価で、64KByte を超えるようなメモリを搭載する、ということがあまり現実的ではありませんでした。
1981年に発売された初代 IBM-PC は、16KByte のメモリしか搭載していません。
でも、あっという間にメモリは安くなり、大容量を搭載できるようになります。
90年代に入ると、64KByte 以上のメモリに連続アクセスできない、というのは足枷にすぎなくなります。
…もっとも、これはインテルだけの責任ではありません。
1985年には、後継の CPU 80386 が作られています。
8086 と、その後継の 80186、80286 までは、互換性を持つ 16bit CPU でした。
しかし、80386 は新規設計の 32bit CPU で、8086 互換モード「も」持っています。
互換モードでは、単に高速な 16bit CPU として動きます。
本来の能力を発揮すれば、メモリ空間も 4GB の連続アクセスが可能となりました。
インテルとしては、時代の要求に応えたものは作った。
これを使ってくれれば問題解決、というわけです。
でも、ここで「互換性」の問題が現れます。
8080 から 8086 に移行した時は、互換性とは「移植しやすければよい」という程度のものです。
しかし、時代は変わり、ソフトは買ってくるものになりました。
今までお金を払ったソフトを捨てないと 80386 には移行できないのです。
80386 を搭載したマシンは徐々に発売されていきますが、過去の資産を活かすため、単に高速な 8086 として使われていました。
ここで登場するのが Windows 。
3.0 の登場を覚えている人はいるでしょうか？
サポートする CPU 80286 以上でした。つまり、3.0 はまだ「16bit」で、8086 の呪縛を引きずっています。
アプリケーションを作るにも、16bit の呪縛が残っています。
だったら、Windows よりも普及している MS-DOS 用に作ったほうが、多くの人に使ってもらえるだけマシです。
それが、3.1 になった時に、80286 のサポートを打ち切り、80386 専用になります。
見た目はあまり変わらないのですが、80386 の性能を活かせる OS として作り直されていました。
アプリケーションを作りやすくなったのです。
＃勘違いがありました。指摘感謝。
僕は日本語版しか使ったことが無かったのですが、3.1が386以降専用となったのは、日本語版だけだそうです。
英語版では、8086で動かなくなったものの、80286でもまだ動きました。
ところで、Windows 3.1 は、まず MS-DOS を起動し、MS-DOS 上から Windows 3.1 を起動する、という構成でした。
内部に MS-DOS を持っているのです。
これを利用し、Windows 3.1 のアプリケーションの一つとして、仮想的な MS-DOS を実行することができました。
互換性は完全ではありませんでしたが、最悪の場合、Windows を終了すれば MS-DOS に戻れます。
先に書いた「過去の資産」問題への対策もできているのです。
このために、Windows 3.1 は大ヒット。
見た目の上ではあまり変わりませんでしたし、バージョン番号も 0.1 しか違いません。
しかし、やっと 8086 の古い設計から逃れられるようになったのです。
現在は、8086系統の CPU は、さらに改良されて 64bit になっています。
とはいえ、基本的に互換性を確保しながらの改良なので、設計が古いところは多数あります。
メモリが貴重だった時代、命令の必要性に応じて、データの量を可変にする「可変長命令」はいいアイディアでした。
しかし、現在となっては可変長命令は命令の取り込みをややこしくし、実行速度を低下させます。
Intel の CPU では多くの工夫によって速度低下を防いでいますが、「互換性」さえ気にしなければもっと簡単に速くできるのです。
命令セットも、時代に合わせてつぎはぎに拡張を繰り返した結果、複雑怪奇になっています。
スマホなどでは、過去の資産がないところから始まったため、8086 系の CPU を使う理由もなく、主に ARM が使用されます。
設計が簡素で強力…だったから使われ始めたのですが、こちらもすでに拡張を繰り返し、複雑化しつつあります。
8086 の設計は、すでに 40年近くも前のものです。
今のプロセッサに 8086 互換機能はないのですが、基本部分はバイナリ互換性を保ちながら拡張されてきました。
まだ完全互換を取り続けていました。指摘くださった方、ありがとうございます。
言い訳ついでに説明すると、リアルモードと呼ばれる動作モードに入ると、8086完全互換になります。
ただ、この機能を使うと最新の CPU の機能（たとえば膨大なメモリ空間）も使えなくなるため、普通は仮想 86モードを使用します。
仮想 86モードは、基本部分は互換なのですが、完全互換ではありません。
Windows では、MS-DOS のソフト資産を仮想 86 モードで動かし、完全互換でない部分に関しては、ソフトウェアで違いを吸収していました。
しかし、WindowsNT が導入されたとき、この「ソフトウェアによる 8086 互換の努力」は無くなりました。
Windows 95 系列との互換性のほうが重要になったためです。
このときに、すでに完全互換ではない、という記事を読んだ記憶が、最近の CPU は 8086完全互換ではないのか、というふうに記憶の中に残っていたようです。
現在の Core i7 でも、8086互換のリアルモードは残っていますので、8086 互換機能はまだあります。
そして、8086系列は今もまだ主流であり続けています。
おそらく一番「長寿」な CPU アーキテクチャのように思います。
公開後すぐに追記
IBMのメインフレームのほうが長く互換性保ってますよ、と教えていただきました。
メインフレームは使ったことないので不勉強でした。
IBM なんだから、途中で POWER に移行しているのだとばかり思っていた。
１年前の記事ですがIBM のメインフレームが５０年間互換性を保証している、と書かれていますね。
インテルの CPU と同じように改良・拡張もあるのだろうけど、ＰＣほど激しい競争のある世界でもないから、それほど汚いことにはなっていないのかな…と予想。
インテルの CPU は、誰もが言うけど汚い。
ただ、どんなに罵られようとも、実用性が高いのも事実です。
汚くなっているから設計コストだって馬鹿にならないだろうし、事実インテルは過去に何度も「新設計の CPU に移行」を試みては失敗しているので、もうやめたい気持ちだって大きいのでしょう。
それでも続けているのは、ある意味立派だと思います。
＃マイクロソフトも過去製品のサポートを続けていて立派だと思っていたのだけど、Win10 への移行で「もうサポートしたくない」という態度をはっきりさせた。
インテルもいつか「非互換です。嫌なら使うな」という態度をとるかもしれない。
というか、一度そういう態度をとったら AMD に美味しいところかっさらわれて、慌てて追いかけたのだけど。
いつかインテルが互換性を取るのに限界を感じた時、混乱なく事態を収拾できるだろうか？
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 【あきよし】 ところで、間違えていたことは申し訳ないとお詫びしつつ、間違った駄文はこれからもどんどん書く予定です。書かないことには何も始まらないから。 勉強は精進しますが、限界もありますし、間違い指摘があれば素直に受け入れます。 (2016-08-03 12:11:31) 【あきよし】 気付くのが遅れましたが、各種指摘ありがとうございます。 80386サポートは、当時僕が98版しか知らなかったための勘違いでした。 また、8086互換性について、仮想86モードが完全互換ではないことと混同がありました。 以上、記事中にも追記しています。 (2016-08-03 11:38:28) 【名無し】 Windows 3.1は80286もサポートしています。80386以上専用になったのはMSKKが販売していた日本語版では? (2016-06-19 00:50:35) 【6809】 初めてコメントを書かせて頂きます。他の方も軽く指摘していますが，思い込みや知識不足によると思われる誤りが散見されます。 多くの誤りがあるのでいちいち指摘はしませんがせっかくこうして書かれるのであればx86とWindowsについてきちんと勉強をして書き直しをされたらいかがでしょうか。このままではちょっと恥ずかしいです。 (2016-06-17 21:39:43) 【G-SHOES】 あれ、今のプロセッサにも8086の互換機能はあると思いますよ。 (2016-06-10 09:57:13) 【あきよし】 メインフレームはあまり知らなかったのですが、互換性保ち続けていたのですね。 IBMだから、POWERに変わっているのだと思っていた。不勉強でした。 http://japan.zdnet.com/article/35065282/ (2016-06-09 13:17:52) 【m.ukai】 長寿なのはIBMメインフレームでは？ s/360から現役のzまで互換を保ちつつ拡張されてますよね。(s/360 と 370 の互換の程度は実は知らないんですが s/370 以降は上位互換) (2016-06-09 13:13:27) |
子供が Scratch を楽しんでいる。
時々プログラムの処理について相談されるのだけど、だんだん質問が高度になってきた。
以前は、プログラム一般の話で答えられたのだけど、だんだん処理系依存の話が混ざり始めたのだ。
じゃぁ、ちょっと自分も詳しく知っておかないといけないな、と思っていた。
それとは別に、IchigoJam で何か作ってみようと思った。
1KByte しかフリーエリアがないから、小さなゲームがいい。
ちょっと考えて、テトリスを組んでみようと思った。
途中まで作っていたのだけど、中断。いろんな都合で IchigoJam をつかえる日は限られてしまう。
上記二つのものがくっついて、Scratch でテトリスを作ってみよう、と思った。
でも、テトリスは案外作っている人が多いんだよね。今更作っても面白くない。
じゃぁ、コラムスだ。
というわけで、作ったものがこちら。
スマホの人は見られないかもしれない。
Scratch は Flash で動いているから。
最初に限り、画面クリックだけでゲームが始まる。
ゲームオーバー後の再ゲームは、上にある「旗」のマークをクリックする。
プロジェクトページに行けば、画面拡大機能も使える。
Scratch のアカウント持っている人は、下にある星マークとハートマークも押しておくといいだろう（笑）
矢印キーとスペースキーで操作できる。
同じ色を３つ並べると消える。
それ以上の説明はいらないと思う。
「コラムス」はセガの登録商標だと思うので、名前を Jewels にしてある。
この名前で作られたコラムス類似ゲームは多い。
ベースはコラムス 97 だ。Jewels 2017 とした。
まだ 2016 年だけど、構うものか。コラムス 97 だって発売は 1996 年だ。
今後も手を加えるかもしれないけど、とりあえず現時点では、ゲームのコア部分しか入っていない。
BGM も効果音も、 Scratch で最初から使えるサンプル曲からそれらしいものを選んだ。
グラフィックは GARNET という、宝石をレンダリングする専用フリーソフトを使わせてもらった。
タイトルも違うし、コラムス 97 からもらってきたものは、ルール以外には何もない。
そして、ルールは著作権を主張できないから、類似物を作っても問題ない。
Scratch は一度公開してしまうと、作業中も公開しっぱなしになってしまう。
もし動かなかったら作業中だと思ってほしい。
というわけで、この日記はゲームの紹介のみ。
これを作る間に、Scratch の動作が理解できた。
そのことは次の日記で。
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
先の予告通り、Scratch の技術話。
Scratch は初心者向けの言語だけど、この話は初心者向けではない。
だって、Scratch の上でプログラムをする話ではなくて、Scratch というプログラムの話だから。
そういうわけで、Ｃやアセンブラでゲームなどを作ったことがある人を対象にさせてもらう。
Scratch というプログラムの話、といっても、いろいろ実験してその動作から推察しただけだ。
Scratch 処理系のプログラムを読んだわけではないので、間違えていたら申し訳ない。
▼並列動作と垂直同期待ち
Scratch は、多数のプログラムを書いて、それらが並列に実行される。
多数のキャラクターを動かすゲームでも、キャラクターごとのプログラムを個別に作るだけでよい。
これが、ゲーム作成には非常に役立つ。
キャラクターは動き続けるのだから、永久ループ（もしくは、ゲームオーバーになるまでの長期ループ）の中にプログラムを書くだけでいい。
これで、不思議と思い通りに動いてくれる。
たくさんのプログラムが同時に動くだけでなく、よく気を付けてみると、動くプログラムの数に関わらず一定の速度を保っている。
並列動作と、垂直同期待ちが自然な形で言語仕様に組み込まれているのだ。
しかし、永久ループなのにどうやって並列実行し、表示速度を保っているのだろう？
実は、Scratch はイベントドリブンマルチタスクだ。
MacOS 9 以前とか、Windows 3.1 の頃とかがそうだった。
ＯＳによって稼働時間を与えられたプログラムは、ある程度の時間動いたのち、処理をＯＳに戻さなくてはならない。
処理を戻されたＯＳは、次のプログラムを呼び出す。これを繰り返せば多くのプログラムが並列動作できる。
「クリックされた」とか「キーが押された」など、特別な事象は「イベント」という形で呼び出される。
通常の時間割り当てと違い、特別なことが起きたので、それに対応するプログラムを書く必要がある。
逆にいえば、通常の動作の中ではこれらを考慮しなくてよくなり、プログラムがすっきり書ける。
Scratch では、「ループの末尾」で処理をシステムに返している。
次に処理の割り当て時間が回ってきたときには、もちろんその続きから実行される。
＃2016.6.20 追記：
ループ末尾でシステムに処理を返すのは、「ループ内に画面を変更する処理がある場合」に限られるようです。
詳細はこの日記の末尾に。
メッセージの送信という「イベント」は、内部的にはキューに入れられる。
この操作自体は即座に行われるが、実際のイベント呼び出しは、システムに処理を返した後で行われる。
クローンの生成も、変数領域などのコピーは即座に行われるが、そのクローンに「クローンされた」というイベントを送るのはシステムに処理を返した後だ。
すべてのプログラムを動かし、イベントも処理し終わると、普通の OS なら、また最初からプログラムの実行を開始する。
それが一番時間を無駄にしないからね。
でも、Scratch は「垂直同期待ち」に入る。
全部のキャラが動いた後は、垂直同期待ち。
（実際には垂直同期ではないのだけど、ここではそう呼ばせてもらう）
コンピューターを「計算機」と考えるなら、待ち時間は無駄となる。
でも、ゲームを作ったりアニメを作ったりしたいのなら、この動作は非常に理に適っている。
▼高速化
ゲーム中に、大量のデータ処理が必要でループを回すと、上に書いたように垂直同期待ちを入れられてしまう。
データ処理をゲーム進行と並列に行う…というのでは動作がおかしくなってしまうだろう。
並列実行を前提としたプログラム環境…たとえば、Java なんかでは、一定の操作の中に割り込みを入れないことを保証する記述方法がある。
共有している変数を複雑な方法で書き換えている最中に、別のプログラムが関連する変数にアクセスするようでは困るからだ。
そして、Scratch にも割り込まれないことを保証する記述方法がある。
指定された範囲のプログラムには、ループ末尾で垂直同期が入らなくなる。これで大量のデータ処理が瞬時にできる。
この指定には「ブロックを作る」を使う。
ブロックとは、Scratch の命令のことだ。
自分で命令を作れる。つまり、サブルーチンのことだ。
ブロック作成時にはいろいろなオプションがあるのだけど、「画面を再描画せずに実行する」にチェックを入れる。
再描画とは、つまり垂直同期だ。ブロック中には垂直同期待ちをしない、と指定できる。
以上。方法としては非常に簡単だ。
以降の説明では、この技法を「高速化」と呼ばせてもらう。
注意点として、垂直同期待ちをしない、というのはシステムに処理を戻さない、という意味なので、イベントも発生しない、ということを忘れてはならない。
メッセージを送ったり、クローンを生成することは出来る。
でも、ブロックの中にいる限り、そのメッセージを他のプログラムが受け取ることはないし、「クローンされた」イベントも起こらない。
どういうことか、次に詳細に述べよう。
▼クローン処理
ループ内でクローンを使って多数のキャラクターを作り出していたとしよう。
クローンされたキャラクターを好きな位置に配置するために、座標をグローバル変数で渡していたとする。
「クローンされた」イベントが起きると、クローンは座標をグローバル変数から取り出し、自分自身の位置を変更する。
次々グローバル変数を書き換え、クローンを生成したとしても、ループ末尾ごとにシステムに処理は返され、「クローンされた」イベントが起きるので問題なく動作する。
ここで、多数のキャラクターを作るのに時間がかかるので、高速化したとする。
ループ末尾になってもシステムに処理は帰らず、次々とグローバル変数を書き換えながらクローンを作り出す。
いよいよすべての処理が終わり、ブロックが終了した後に、まとめてすべての「クローンされた」イベントが実行される。
最後のグローバル変数の位置に、作り出したすべてのクローンが移動してしまう。
高速化するためのオプションを入れただけでプログラムは変えていないのに、さっきまでは起きなかったバグが起きる。
単純なゲームを作る程度なら高速化する必要はない。
普通はクローンとループはセットになっているだろうし、何も気にせずに作っても、結構うまく動く。
でも、高速化が必要なくらい複雑なゲームを作りたいのであれば、相応に複雑な Scratch の内部構造を理解しなくてはならない。
▼クローン時の変数
さて、Scratch ではプログラムはスプライトに属するもので、そのスプライト自身の挙動を記述する。
他のスプライトの挙動を制御することは出来ない。
でも、クローンは例外的な命令で、自分自身をクローンするだけでなく、指定したスプライトをクローンすることもできる。
ここで、スプライトを指定してクローンすると、そのクローン後の挙動を制御することが難しい。
出現位置を変えたり、何らかのパラメーターを渡すには、上に書いたようにグローバル変数を介在させる必要があるだろう。
そして、高速化で悩むことになる。
もし「自分自身」のクローンで事足りるのであれば、こちらの方が多くのことを制御できる。
というのも、クローンは、クローン命令時点でのクローン元のローカル変数内容をコピーして引き継ぐからだ。
グローバル変数を介在しない。
「クローンされた」が実行されるまでのタイムラグもない。
命令実行時点でパラメーターを受け渡す、唯一の方法だ。
ただし、自分自身のクローンで何もかも済ますことはできない。
パラメーターを受け渡したい、という唯一の理由で、それ以外のすべてのプログラムも受け継ぎ、全く挙動が違うのに処理を振り分ける…なんていうややこしいことをする必要はない。
全く挙動が違うのであれば、全く違うスプライトにしたほうがいいだろう。
その分パラメーター受け渡しがややこしくなるかもしれないけど、全体が複雑化するよりは簡単だ。
パラメーター受け渡し用に、リストを用意するといいだろう。
「追加」すると、リスト末尾にデータが入る。
「１番目」から取り出した後で「１番目を削除」すれば、FIFO キューが出来上がる。
これで値を受け渡しすれば、多数のクローンが一気に作られても問題は出ない。
＃「クローン」命令の発行順と「クローンされた」イベントの起こる順が一緒である保証はないので、種別の違うスプライトをクローンする際には、違うキューを用意しておいた方が無難。
先に書いたように、一つのスプライトですべてを済ませてしまえば、キューが多数になるような複雑さは防げる。
どちらにするか、自分の良いと思うバランスを考えてプログラムするしかない。
▼プログラムテクニック
動作詳細としては、以上だ。
Scratch 、という言語処理系が、ゲーム作成に必要な技術を自然な形で取り込んでいるのがわかると思う。
だから、Scratch はゲームが作りやすい。
とはいえ、やっぱり初心者向けの言語なので、すでにプログラム経験が深い人には使いづらいかもしれない。
たとえば、関数を作れない。
BASIC でいうサブルーチンは作れるのだけど、返り値は戻せないし、ローカル変数も使えない。
一応引数は渡せて、それはローカル扱いになるのだけど、この引数は参照のみで変更禁止。
Javascript Code Golfer がやるような、引数を使ったローカル変数定義テクニックとかは使えない。
オブジェクトは作れる。
Scratch は Smalltalk 由来なので、C++ 的なオブジェクトではなく、Smalltalk 的なオブジェクトだ。
このオブジェクトは、ATARI 用語的なオブジェクトと若干の混同が見られる。
オブジェクトは、必ずスプライトなのだ。もちろん、わざとやっているのだろう。
スプライトだから必ず画面表示用の画像が付くし、暗黙の内に座標などの変数が定義されている。
でも、画面から「隠す」ことは可能だし、いらない機能は無視すればいい。
オブジェクトなのだから、その内部だけで使える変数も定義できる。
サブルーチンではローカル変数が作れないが、オブジェクト内でローカル変数が使えるのだから、良しとしよう。
オブジェクト間ではメッセージを介して通信ができるが、先に書いたようにメッセージ送信は即座に行われるわけではない。
オーバーヘッドが大きいので、「オブジェクトが通信しあいながら協調動作する」という、Smalltalk の理想には程遠い。
まぁ、ゲーム用なので、「次の画面までに解決できれば良い」程度のことは、メッセージで処理できる。
今回コラムスを作ったのだけど、フィールドを一つのオブジェクトとして扱おうと試みて、断念した。
結果として、フィールドは配列（リスト）構造になった。
落ちてくる宝石を操作するオブジェクトでは、このフィールドを覗きながら、積み上がっている宝石に当たらないように操作を行う。
落ちきったら、ゲームの流れを制御するオブジェクトが、フィールドを調べて消える宝石を消す。
宝石が消えたときは、「消えたよ」というメッセージが送信される。
でも、このメッセージは、表示されている宝石すべてが受け取ってしまう。
宝石は、メッセージをきっかけとして、各自が自分に対応するフィールドの中を調べる。
自分のいる位置の宝石が消えていたら、消えるアニメーションを実行して消滅する。
とにかく、「フィールド」の扱いがいろんなオブジェクトに分散していて面倒くさい。
オブジェクト指向の美しさなんて全くない。
これは「Scratch がダメだ」と言っているのではないよ。
泥臭い方法をとったけど、ちゃんと作りたいゲーム作れたもの。
世の中には結構ダメな環境があって、不満が出たら「あきらめる」しか選択肢がない場合もある。
ちなみに、不満が出ない環境というのは存在しない。
Scratch は、泥臭い方法を許容する。
それだけで十分だ。
2016.6.20 追記
Scratch 教室をやっている「ロジックラボ」さんが、このページ内容を子供向けに興味を持てる形に置き換えて、漫画で描いてくださっていました。
そこで指摘されるまで気づいていませんでしたが、画面描画に関与するような変更がない限り、ループ末尾でシステムに処理を返すようなことはしない、とのこと。
確かに、実験してみるとその通りでした。
「リスト」の処理が微妙で、ループ中にリストをいじった時、デバッグ用にリストを表示していると、表示更新のために垂直同期待ちします。
しかし、デバッグ時でないと垂直同期待ちしません。
この日記を書く前、ゲーム作成時にどうも同期タイミングが理解できず、「デバッグのために」リスト表示したりしていたので、ループ末尾は常に処理が戻るのだと勘違いした模様。
＃そもそも僕は Scratch の動作をあまり知らないので、調べて整理したかった、という動機です。
プログラム経験は長いけど、Scratch に関してはまだまだ素人。申し訳ない。
ちなみに、変数は画面に表示していても、垂直同期を引き起こさないようです。
一貫性がないけど、変数は頻繁に書き換えるものなのでいちいち待ち時間を発生しないほうが良い、という判断なのでしょう。
2016.6.27 さらに追記
もう一本ゲームを作ってみてます。
近いうちに公開できると思うけど、システムに処理を返すタイミングがよくわからなくなって困っています。
状況次第で、画面描画しないループでも、システムに処理を返すことがあります。
「高速化」オプションをつけているブロックの途中で、システムに処理を返してしまうこともあります。
今作っているゲームでは、面クリアして特定の面に差し掛かったところで、後者のバグ（？）が出ることが多い。
必ずバグが出るわけではないけど、ある程度再現性があるので、特定条件でバグが出るのだと疑っています。
また、一連の無限ループスクリプト内でブロックを呼び出している場合、繰り返し呼び出されるブロックが、常に高速かオプションが無視されます。
ということは、このバグは「ブロック呼び出し」に付随するのではなく、そのブロックを呼び出すスクリプトのスレッドに付随するようです。
＃面クリア時にスレッドを終了し、次の面で再度スレッドを起動する、というつくり方をしている。
バグが出た面は、ずっとスレッド内で呼び出されるブロックの高速化オプションが無視される。
（ゲームにならなくなってしまうので、クリアして次の面でどうなるかは不明）
スクラッチのタスクスイッチはまだまだ謎が多いです。
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今日は、日本式の顔文字 (^_^) が生まれた日(1986)。
一応、欧米式の顔文字、:-) と :-( は 1982 年に提案されています。
アメリカでは、1960年代から、テレタイプ端末を電話回線でコンピューターに接続して時間貸しするサービスがありました。
その延長で、いわゆる「電子掲示板」も早くから普及しています。
1970年代の末頃には家庭用のコンピューターも普及し始め、電子掲示板を使用するユーザーも増えます。
そして、ユーザーの急増に伴い、それまで数の少ないユーザーの間では「常識」で済んでいたことが、通用しなくなり始めたのです。
簡単に言えば、冗談を書き込んだのに真に受ける人が出始めた。
これはいけない、と、冗談の最後には「冗談だよ」という意味で、笑い顔のマーク :-) をつけようという提案がなされたのです。
さて、今日は日本の顔文字の話。
日本ではアメリカと違い、電話は国営でした。電電公社だけに許されたサービスだった。
その電話回線に接続する「電話機」もまた、電電公社の所有物で、レンタルでした。
電話料金と共に、毎月のレンタル料を支払う制度。
そして、その電話機以外の機械を電話回線に接続することは許されなかったのです。
この制度が変わったのが、1985年。
電電公社が民営化されてＮＴＴとなり、同時に電話機自体も、認可があれば別の会社が作れるようになります。
日本の「パソコン通信」時代の夜明けはこの後で、300bps のモデムとかで通信ができるようになります。
まだ漢字を使えるマシンも少ないころで、アルファベットとカタカナだけで通信をやっていました。
＃と書いているけど、僕がパソコン通信を始めたのは 1990年代なので、この頃の話は伝聞。
一応、これ以前からも、通常の電話機にマイクとスピーカーを密着させる「音響カプラ」でのパソコン通信は行われている。
さて、1985年には、パソコン雑誌で有名だったアスキーが主催する形で、パソコン通信の「アスキーネット」がいち早くサービスを開始しています。
日本式の顔文字が生まれたのは、1986 年、アスキーネットでのこと。
お祝いメッセージの中で、喜びの表現として (^_^) という組み合わせが使われました。
この時点では、自分の気持ちを表現するものなので、文末に自分の署名とともに入れる形です。
でも、「顔文字」という概念もないので、誰も顔だと気づいてはくれなかったとか。
その後は、「自分らしい署名」の一部として使用されます。
欧米での使われ方のような、感情表現とは違うものです。
しばらく後には爆発的な普及を見せ、各自が工夫したバリエーションが増えていきます。
ここら辺、考案者である「わかん」さんに、メールでお伺いしたことがあります。
当時は日本ではパソコン通信は「新しいもの」で、海外のパソコン通信を知っている人はほとんどいません。
存在程度は知っていても、実際使ったことはない、という意味ね。
だから、海外の顔文字は全く知らず、無関係だったそうです。
1980年前半のパソコンはグラフィックが使えないものも多く、ゲームなどを作る際に文字の組み合わせで形を作る「アスキーアート」を駆使していました。
これらは、ベーマガなどを読んでいた人にもお馴染みだったと思います。
しかし、わかんさんは視覚障碍をお持ちで、当然ながらこれらのゲームも知らないし、雑誌のプログラムを読んだこともないそうです。
つまり、全くのオリジナルアイディア。
今では、海外でも日本式の…横倒しになっていない顔の書き方は人気がありますし、Unicode によって文字のバリエーションも増えたため、驚くほど多くの表情を作り出せます。
時々、凝りすぎていて使い道がわからない顔文字も見かけますけど。
僕は文章の中に顔文字を入れすぎるのは好きではない。読みにくくなるから。
でも、時々 :-) や (^^; は使います。
前者は、英語的な表現と同じ「just joke」な感じ。
後者は、ちょっと照れ笑いを浮かべているような、なんと言ってよいか困っているような表現ね。
改めて説明しようと思うと的確な言葉が見つからないのですが、だからこそ顔文字で表現するしかない。
文章を書くプロであれば、微妙な表現でも的確な言葉を見つけないといけないでしょう。それがプロの仕事だから。
でも、今は素人でも書いた文章を人に見てもらえる時代。
上手い言葉を見つけ出せない時に、顔文字などで感情を伝えようとするのも、悪くないかと思います。
そこに「伝えたい」という気持ちがあるのであればね。
先に書いた「凝りすぎた顔文字」というのは、絵としての面白さはあるけど感情が乗らないようなものね。
絵を作り出した努力は認めますし、素直に面白いと思うものもある。
でも、顔文字が感情表現の一環であるならば、非常に使いづらい。
パソコン通信やメールでは顔文字が多用される、ということを前提に、DoCoMo が i-mode を作り出したとき、顔文字を１文字で表現するような「絵文字」が考案されました。
i-mode の初期の頃って、横幅が８文字分しかないんですね。顔文字の途中で改行されてしまう可能性は高いし、そんなことになったら絵として見られなくなる。
だから、１文字の幅の中で、笑い顔や泣き顔など、いくつかの顔を入れてしまった。
それでも、アスキーアートの延長だったので、絵としては非常に簡素なものでした。
その後、他社も真似して絵文字を入れていく過程で、完全に顔の絵になってしまった。
さらに表情も増え、それがそのまま Unicode に取り込まれた。
Unicode の策定に関わっている多くの人達が、「文字」ではないものを取り込むことに対して、強く反対したそうです。
そして、取り込むことを決めても、今度は日本生まれの「絵文字」が日本文化に根差しすぎていることが問題となった。
日本の文字なら日本文化に根差しているのは当然。
でも、絵文字は一見して「世界中誰でも理解できそう」だからこそ、その表現が日本文化だけに根差していることに問題があったのです。
非常に多くの議論が行われ、文字の形などが変更され、やっと取り込まれます。
実際取り込んでみたら大人気で、欧米のユーザーも喜んで使い始めた。
今では欧米からも、積極的に新しい絵文字の提案が出されています。
しかし、公式に「文字」の一部として顔の絵が使えるようになっても、なお新しい「顔文字」が作られ続けています。
組み合わせて自分で作る、という遊びが面白いという側面もあるのでしょうし、そもそも顔文字が「文字で表現できない微妙な感情を表現しよう」とするものだからでもあるでしょう。
公式にいくつかの顔が作られてしまえば、その中にない新たな表情を作りたくなる。
たぶん、顔の絵がどんなに増えても、「顔文字」が無くなってしまうことはないのだと思います。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
昨日の報道ですが、オセロ考案者の長谷川五郎さんが、20日に亡くなったそうです。
すぐに何か書こうと思ったけど、昨日は忙しくて書けませんでした。
僕は氏のことを全然知らない。
オセロの開発話は本やテレビで何度か見たことがあるし、それなりには知ってる。
でも、氏に対しての思いは特にない。
それで訃報を書くのもどうかと思うのだけど、オセロに関して思うところはいろいろある。
ちょうどよい機会だし、偉大な方だと思うので、自分の思い出を少し書こうと思う。
テレビゲームが子供の遊びの主役となる前、どこの家にも将棋やオセロなんかがあったと思う。
人生ゲームなんかもあるのだけど、あれは大人数で遊ぶ時用。
オセロなら、２人いれば十分で、しかも短時間で遊ぶことができた。
僕は兄弟が多く、兄や姉とよく遊んだのだけど、大抵は負ける。
小学校低学年の頃だったから、まだ論理性が身についていない。
オセロは、「多くとれる」ところを責めると、自分の色の駒がたくさん並んだ状態を作り出してしまう。
それは、とりもなおさず相手にとって「多くとれる」ことを意味する。
だから、闇雲に攻めちゃいけない。でも、そんなこともわからずに闇雲に攻めていたのだった。
小学校４年生の頃だと思うが、ゲームセンター向けにオセロのゲームがあった。
白黒画面で、○と×で駒を示しているやつ。
それを見たときは、「コンピューター相手にオセロができるんだ」とは思ったのだけど、お金を出してまでやろうとは思わなかった。
小学生にとって 100円は大金だし、オセロだったら家に持っているから。
＃注：まだゲームセンターに小学生が行っても問題なかった時代。
よく、金もないのにゲームセンターに入り、人のプレイやアドバタイズを見るだけでわくわくしていた。
そして、小学校６年の頃だったと思う。
オセロの販売元のツクダオリジナルが、オセロを遊べる家庭用テレビゲーム機を発売していた。
実はセガ SG-1000 の互換機で、カートリッジを入れないときはオセロが起動するようになっている。
おもちゃ屋の店頭に、遊べる状態で置いてあったのだけど、この「人工知能」に対して…確か、強さを選べて、一番弱い場合だったとは思うのだけど…必勝法を見つけ出した。
コンピューターは、こちらが同じ手を出せば、全く同じ手を出してきた。成長がなかった。
それで、５～６手進めただけで、すべて自分の色になってゲーム終了、という手順があった。
この手順を発見して、その店の店頭を通るたびに、わざわざ「完勝」して、誇示するようにその画面のままにして去ったのだ。
コンピューター相手にオセロをやったのは、たぶんこれが初めてなのだけど、「コンピューター、馬鹿だな」と思っていた。
中学生になり、ファミリーベーシックを入手した。
面白くもないゲームを作ることが楽しかったのだけど、ある日ベーマガに「オセロ」のプログラムを見つけた。
他機種用。でも、人工知能ってとても高度なもので、BASIC で簡単に組めるとは思わなかった。
興味を持って、プログラムを読んでみるのだけど、何をしているのかどうも意味が分からない。
プログラムのほとんどは、オセロのルール…挟んだらひっくり返るとか、ひっくり返せない場所にはおけないとか、そういう細々したことを実現するためのものだった。
人工知能らしい、高度な部分はない。
人工知能の思考ルーチンはと言うと、盤面の中で「駒を置ける場所」を見つけたら置いてしまう、と言うだけ。
ただし、置ける場所の順番は示されていて、単にマス目を端から見ていくのではない。
ふーん、すると、この順番に何か秘密が隠されているんだな。
ファミリーベーシックに移植して遊んでみる。
そのプログラムは、それほど強くはなかったけど、適当に相手をしても勝てない程度には強かった。
石を置く順番…取るべき優先順位は簡単な話で、盤面の四隅は最優先。
その隣は、最も優先順位が低かった。
オセロでは「駒を挟むとひっくり返せる」というのが最重要ルールだ。
でも、隅にあると絶対に挟めないから、自分の駒を置くと相手にとられない。
安全地帯なのだから、何よりも優先して確保しなくてはならない。
そして、相手の駒を挟む形でしか新しい駒は置けない。
隅の隣に駒を置かなければ、相手に隅を取られることはないことになる。
だから、隅の隣を迂闊に取るのは悪手。優先順位を下げないといけない。
でも、単純に優先順位をつけるだけでは、「多くとれるところ」を見逃すことにもなりかねない。
プログラムを改良して、位置の情報に「優先順位」フラグを付けた。
置ける場所が見つかっても、同じ優先順位のところがまだあるなら、そちらにも置けるか試す。
一番多くの駒をひっくり返せるところの位置は覚えておいて、同じ優先順位の場所が無くなったところで、「一番良いところ」に駒を置く。
ちょっとした改良で、ちょっとだけ強くなった。
これを友達に渡して遊ばせたら「何度か遊んだけど一度も勝てなかった」と言われた。
僕が遊ぶと、アルゴリズムを知っていることもあって、これでもかなり弱い。
一度も勝てないはお世辞じゃないかと思ったけど、そいつは思考ゲームは嫌いだったので、適当に遊んだら勝てなかったのかもしれない。
まがりなりにもオセロの思考ルーチンを考えたことがあったので、興味を持ってはいた。
その後、たしか雑誌の「ログイン」で、森田和郎さんが「森田オセロ」の解説をしていた。
森田和郎さんというのは、当時の有名プログラマで、オセロとか将棋を作るのを得意としたのね。
もっとも、ゼビウスに類似したゲームを、当時の非力なマシンで作り上げて、ナムコの許可を得て販売したりもしている。
アクションゲームも十分作れるし、複雑な思考ゲームも作れる。凄腕のプログラマだった。
話がそれたけど、森田オセロでは、もちろん「駒を置く位置」も考慮しているけど、それでいくつの駒をとれるか、置いた駒の周辺に空きマスはないか（空きマスがあれば、そこに相手が駒を置くことでひっくり返されやすい）、など、多くのパラメーターに点数をつけることで複合的に置く場所を決めているという。
そして、何より大切なのが「先読み」だった。
駒を置ける可能性のある場所はいくつもある。
その中でどこに置くかを決めるのに上に書いたように点数を使うのだけど、一番高得点のところに置けばいいというものではない。
そこに置いたとしたときに、次に相手はどんな戦略をとれるか。ここでも得点を出し、一番高得点のところに置くとする。
じゃぁ、それに対して今度は自分は…これを数手繰り返せば、先読みができる。
たくさんひっくり返したけど、その次の手でそれを全部取り返される、なんて間抜けな手を打たなくなる。
森田和郎さんの記事では、αβ狩りも説明されていた。
ややこしいので詳細は省くけど、先読みの範囲を絞り込んで、効率よく最善手を見つけ出すための方法。
実は、先読みまでするオセロを試作したことはあるのだけど、未完成なまま飽きた。
大学の時に Lisp 言語を入手したのね。
Lisp なら人工知能だろうって、当時の浅い知識で短絡してオセロを作り出した。
先読みルーチンを作るには、「今の盤面の状態」を記憶したまま、次々と「先読みした盤面」を作り出す必要がある。
具体的にいえば、先読みのために１階層深くサブルーチンを呼び出すたびに、新しいメモリを確保して盤面を保持した配列をコピーしないといけない。
関数に対して配列が渡せれば簡単なのだけど、C言語ではそのようなことは出来ない。
もちろん、BASIC でもできない。そもそも BASIC にはサブルーチンはあっても関数はない。
でも、Lisp は元からそういう言語構造だった。
データは呼び出しの際にコピーされる。だから先読みプログラムを作りやすい。
で、先に書いた通り、未完成なまま飽きた。
Lisp に慣れておらず、何か処理しようとするたびに方法を考えないといけなかったし、そもそも Lisp は「人工知能のアセンブラ」と言われるくらい、アセンブラのように命令が貧弱だった。
（…という考え方が間違っているのは、今ではわかっている。でも当時の僕はそう思った）
それ以降、こうした思考ルーチンは面倒くさくて作ってない。
興味はあるから、それなりに話を追いかけてはいるけれど。
もう、長谷川さんの訃報とはほとんど関係なくなっているね。
以上、オセロに関する僕の思い出話でした。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
先日 Scratch でコラムスクローンを作ったのだけど、完成してすぐにもう一つの作品を作り始めた。
実のところ、ゲームのコア部分は２日でできて、すぐに公開していた。
でも、宣伝してないので一人見てくれただけ。
その後が…長くかかった。
仕事の合間に作っているので、実働できるのは週２日程度。
データ整理に時間がかかったり、バグがなかなか取れなかったり。
（これについては Scratch のバグを疑っているのだけど、再現方法がわからない。
もっとも、「負荷をかけすぎた」のが問題で、これは自分のプログラムが悪かったので、修正して回避した）
で、ひとまず完成したので公開です。
まずは画面の緑色の旗をクリックして、プログラムを動かします。
彗星(comet) を動かして、黄色い星を囲んでください。
赤い星は倒せません。
まとめて囲むと高得点。
星の初期配置は星座の形。だから、全８８面。
ただし、途中で３面ほど、星が出てこない面があります。
暗い星しかない星座なんだよね。ボーナス面だと思って。
プロジェクトページに行けば、大画面で遊ぶこともできます。
（画面左上のマークで拡大できます）
Scratch の ID 持っている人は、左下の星とハートのマークも押しておくといいよ（笑）
これ、僕が X68k を入手して最初に作ったゲームの移植です。
詳しくは X68k のページに。
画面サイズが違う (X68k は 512x512 、Scratch は 480x320) ので、初期配置の星の位置と星座名が重なっていたりしますが、ご愛敬。
キャラクターも、当時のゲームを知っている人には大きく見えるかもしれません。
同じ 16x16 なのだけど、画面サイズが違うので相対的に大きくなっている。
いい機会なので、思い出話を一方的に語りだす。
以前聞かれて簡単に答えたけど、まとまった形にはなっていなかったので。
中学の頃、ファミリーベーシックを使っていました。
そのころから、スプライトがしっぽのようについてくるプログラムが好きで、よく作っていました。
スプライト番号を +1 しながらどんどん置いていけばいい。
番号が最大値を超えそうなら 0 に戻す。
これで、スプライトが「再利用」されて、古いものは消えていくことになる。しっぽの出来上がり。
MSX ではマウスは標準ではないけれど、HALNOTE を使っていたので購入していた。
そして、マウスをぐりぐり動かすと、やっぱりしっぽが付いてくるプログラムを作っていた気がする。
MSX でスプライトを使っていたのか、LINE でやっていたのかは覚えていない。
両方作っていたかもしれない。
LINE で描く場合は、しっぽが付いてくるのを自前で管理しないといけない。
配列をもって、過去の座標を覚えておき、ある程度古くなったら消せばいい。
そして、X68k を買ったらマウスが標準装備だった。
最初の試作として同じようなプログラムを作ったら、MSX とは比較にならないくらい高速に動く。
これでゲームになるんじゃないか、って作り始めたのが Comet 。
線を引くルーチンを自前で用意して、点を打つ前に、そこの色を調べる。
すでに何か描いてあるなら「囲んだ」ことになる。
囲んだ時、最初は星から上下左右の４方向に向かってドットを調べて「囲まれた」判定をしていた。
でも、これは遅かった。あとで「座標で計算すればいい」と気づいて、判定ルーチンを高速化した。
といっても、やはり上下左右が囲まれただけで「囲んだ」と判定していて、まじめな閉鎖領域チェックをしているわけではない。
今回のプログラムも同じ。
Comet は、大学１年の時点での、自分のゲーム哲学を反映したものだった。
今回も基本的に「移植」なのだけど、今だったら違うように作るだろうというところもある。
キャラクターは、単に絵が描けなかったので記号的になっている。
でも、同時に「テレビゲームの本質は記号操作だ」と思っていた。
この頃、絵に凝ったゲームが増え始めていて、絵は良いのだけど面白くないものも増えていた。
それに対する反発もあった。
今でもこの流れは変わっていないと思うけど、「絵を見るのも楽しみのうち」だということは理解するようになった。
綺麗な絵があるなら、それに越したことはない。
また、絵を見ることが目的なら、ゲームは簡素でつまらないくらいでちょうどいい。
今のソシャゲとか、「面白くない」という人もいるけど、絵を見たくて遊んでいる人は面白さなんて求めていない。
それが理解できないで文句を言うのはお門違い。
ゲームの楽しみ方は幅広い。巧妙で奥深いゲームのルールなんて求めるのは、そういうのが好きな一部のマニアだけだ。
Comet では、敵をたくさん囲んだ時に、100、200、300 …と得点単価が上がっていき、1000点以上には上がらない。
これは、初心者でも楽しめるように配慮したつもりだった。
100、200、400、800 …と倍々で増えていくのが当時のゲームとしては主流だったように思う。
でも、それじゃぁゲームマニアと初心者の得点差が離れすぎてしまい、一緒に楽しめなくなる、と思ったんだ。
これは思い違いだった。
例えテクニックを使用した時の得点上限を低めに抑えたとしても「テクニックで得点が上がる」という仕掛けを入れている限り、マニアと初心者の得点差は大きく開く。
でも、テクニックを使える人は、それに対する見返りがなくては面白くない。点数が上がる仕組みは必要だ。
つまり、マニアと初心者が一緒に競えた方がいい、という考え自体が間違えていた。
comet でこのことを知ったので、その後のゲームでは得点を低く抑えないようにした。
そのほうが遊んでいて気持ちいから。
マウス（初お披露目した大学祭では、トラックボールを使用）を使ったのも、初心者が楽しめるようにだった。
マニアは、コントローラー操作に慣れている。
じゃぁ、慣れないコントローラーを用意すれば、みんな同じスタートラインに立てる。
初心者にも競い合うチャンスがあるはずだ、と思った。
でも、トラックボールは時々使われているゲームがあったし、やっぱりマニアは扱いがうまかった。
このときはまだ勘違いしていて、トラックボールじゃダメだったんだ、と思っていた。
翌年「マイク入力」のゲームを作ったら、ゲームマニアの友人は、すぐにゲームルールを理解し、最適な操作方法を編み出した。
この段階に至り、コントローラーを工夫すれば初心者でも同じ位置からスタートできる、というのも勘違いだと気づいた。
マニアはコントローラーの扱いがうまいのではなく、どんなゲームを見てもすぐにルールを把握する適応力に優れているのだ。
これ、ずっと後に任天堂が Wii を発売した時にも同じことを感じた。
全く新しい操作方法で誰もが一緒に楽しめる、ゲームの在り方をリセットする意欲作…だったはずなのだけど、マニアはやっぱり適応力が高かった。
大学時代の、まだ青臭かった自分が作ったゲームなので、ある意味では黒歴史でもある。
BASIC で組んだものだからね。処理が下手な部分がいっぱいあって、スマートではない。恥ずかしいものだ。
その一方で、広く遊んでもらった初めての作品だ。
雑誌に投稿した作品がたまたま流通業者の目に留まり、市販してもらえることになった。
これで「自分の作ったゲームを多くの人に遊んでもらえる」という喜びを知ったから、ゲーム業界を志すようになった。
人生の転換点だった。
記念碑的な思い入れがあるけど、出来が悪い恥ずかしい作品。
それが Comet だったので、いつかどこかでリメイクしたい、という思いはあった。
実際、手を付けたこともあるのだけど、面倒くささが先に立って完成しなかった。
先日、コラムスクローンを作ってみて Scratch の性能が案外高いと判ったので、作ってみようと思った。
コア部分を試作したら、２日でできてしまった、というのは最初に書いた通り。
まぁ、リメイクした、と言うだけで納得してしまい、完成度は高くない。
いつか本気でリメイク出来たら楽しいけど、当面はこれでいいや。
＃夢を語るなら、８８星座のイラストを入れたいし、星の動きをもっと多彩にしたい。
今は初期配置が違うだけで、どの面も似たような攻略法になってしまうから。
星座の線に従って動く星、というのがあれば、星座の形にしている意味も出てくるだろう。
また、８８面は長いので、季節ごとの４コースに再編したい。
…などなど、改良したい点はいくらでもある。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今日は、PHSサービスが始まった日。
1995 年の今日、NTT の子会社である NTT Personal（現在は docomo に吸収）がサービスを開始しました。
PHS は、Personal Handy-phone System の略称。
「個人用の持ち歩ける電話」の意味です。
この当時、携帯電話はありました。
でも、とても高価なもので、会社の重役など、いつでも連絡する必要性がある人が会社から貸与されて使う、というようなものでした。
それに対して、「個人用の」安価なシステムを作ろうというのが PHS でした。
以下の歴史話は、昔読んだ新聞の記事などの知識を「記憶で」書いているものです。
すでに手元に資料はないため、細かな部分は間違えているかもしれません、とお断りしておきます。
1980 年代の後半、日本は好景気でした。
電話の通信料は、まだ３分１０円が基本。３０分も話をしていれば100円になってしまう。
1980年代が始まったころには、100円というのはそれなりのお金だったように思います。
でも、後半に入るころには、100円くらいはどうということのない、安いお金になっていた。
それどころではありません。
電話を引くには、７万６千円の権利料が必要でしたが、大学生くらいになれば自分のお金でこの権利を買える程度の好景気。
それで、女子大生あたりを中心に、自分の部屋に専用の電話を引いて、友達と電話で毎日何時間もおしゃべりする、なんていう人がたくさんいました。
1987年に電話機の「無線化」が認可されます。
家の中で、電話回線に接続した親機との間に、電波で通信できる「子機」を作れるようになったのです。
そして、当時は電波法も今とは違っていました。
何も遮蔽物がないところで、100m 程度まで届く電波は認められています。
家の中で使うはずの「子機」を、家の外に持ち出せました。
といっても、電話をしながらゴミ出しをできる、程度の簡単な外出でしたが。
こうした使い方の延長として、「親機」を 100m 程度置きに設置すれば、子機をどこまでも持ち出せるのではないか、という技術的アイディアが出てきます。
携帯電話は、2km 程度の距離で電波を飛ばさなくてはならなかったため、電波局としての認可も必要となり、高価なものになっていました。
しかし、100m 程度であればずっと安く作れるのです。
このころ、すでに日本の電話の基幹線は光ファイバー化されています。
NTT が埋設した ISDN で、１本のケーブルで 64K の回線を２本と、制御信号用の 16K の回線を１本使えました。
まだ各家庭までは光ファイバーは届いていませんでしたが、「公衆電話」など、NTT が管理する設備では積極的に光ファイバー化が行われていました。
すでに日本全国に埋設されたケーブルがあり、そこには通話可能な 64K の回線が２本も入っているだけでなく、制御信号用の別の線もある。
もちろん音声回線の１本は公衆電話用だとしても、もう一本を PHS で使用して、親機から親機に渡り歩く際にも「制御信号回線」を使えば…
もう、事実上システムは完成していたのです。あとは組み合わせて仕上げるだけ。
これが PHS という構想でした。
当時は電話を使ったパソコン通信でも、33.6Kbps 程度の速度の時代。
ISDN は 64K ですから、PHS でも最大 64Kbps が出る、しかもどこでも通信できる、というので、パソコンマニアからも期待されていました。
後で書きますが、PHS の主要なシステムは、NTT の子会社である NTT Personal が開発し、サービスを行う各社はこのシステムを使っていました。
そのシステムでは、最初の通信速度は 32K から。
DDI Pokect は、独自の技術で「みなし音声通信」を行い、モデムと同等の 33.6Kbpsを可能としていました。
後には 56Kbps での通信も可能とするのですが、そのころには NTT Personal のシステムでも 64Kbps になっています。
PHS は安かったため、女子高校生などに支持されました。
これ以前はポケベルで連絡を取り合っていた世代。
PHS のサービスが始まるころには、携帯電話もずいぶん安くなってきていて、女子大生などは携帯電話を使っていました。
PHS とかいて「ピッチ」と読む読み方も、女子高生世代が広めたように思います。
さて、NTT は NTT 法で縛られており、国は一番の大株主でした。
PHS 構築は国の指導の下で行われ、NTT にも協力が求められました。嫌とは言えません。
その一方で、NTT は携帯電話のサービスも行っていました。
普及させようと頑張り、やっと量産効果でコストが下がり始めたところでした。
ここで、わざわざ携帯電話を自ら潰しにかかる、対抗サービスを始めよというのです。
しかし、大株主でもある国には逆らえません。
NTT は、国の求めに応じて子会社である NTT Personal を設立し、PHS の研究を開始します。
PHS には多くの期待が集まりました。
当時はまだ、携帯電話の電波網も、今ほど細かくありません。
地下やビルの中では電波が届かず、通話できないこともありました。
でも、PHS はもともと安い基地局を大量に作る方式です。
地下やビルの中にも基地局が設置され、携帯電話よりも通話範囲が広い、とされていました。
さらに、最寄りの基地局の位置を取得することで、100m 程度の誤差で「現在地」がわかります。
いまでいう GPS みたいなものですが、携帯電話などでこうした「位置情報」が使えるようになるのは、ずっと後のこと。
こうした特性を活かしたサービスも想定されていました。
しかし、運用後半年程度で「安かろう悪かろう」だという風評が広がります。
基地局が頻繁に切り替わる方式ですが、その際に２～３秒通話ができない、という問題があったのです。
歩いているだけならまだしも、車や電車の中ではとても使い物になりませんでした。
すぐにシステムの改修が行われ、半年程度で問題は軽減しますが、「PHS は安物だ」と印象付けるには十分でした。
一方で、携帯電話はどんどん安くなり、0円端末も現れるようになります。
その分月額料金が高いのかと言うと…通話プランを吟味すれば、それほど高いわけでもない。
PHS の人気が無くなるのに、そう長い時間はかかりませんでした。
独自路線の DDI Poket は頑張りましたが、それ以外の PHS 会社は、「さっさと」撤退することになります。
NTT Personal も、早々に NTT DoCoMo に吸収されました。
技術的な面はわかりません。
最初の「基地局を渡り歩く際の通話ができない問題」は、本当に技術的な不具合だったのかもしれません。
しかし、その一方で、これは最初から NTT の策略だった、国は NTT にまんまと騙されたのだ、という噂もあります。
国は NTT に無理を言って PHS の研究を始めさせました。
NTT は、国の命令だから仕方がなく子会社まで作り、研究をする「ふりをした」だけ。
最初から、「事業が成り立たない」という形を作って DoCoMo に一本化するつもりだったのだと。
NTT って、実はこういうこと繰り返しています。
それが悪いというのではないよ。所詮は一企業で、利益を追い求めるのが本来の姿。
なのに、国に採算に合わないことを命じられて、仕方がなく「やったふり」をして終わりにする。
シティフォンとか、覚えている人いますでしょうか？
それまで使っていなかった新しい電波帯域を実験的に DoCoMo に割り当てて、仕方がないから作られたサービス。
使ってなかった帯域だから、電波網を全部再構築しないといけない。
そんなことを今更新しくやっても採算に合わないから、大都市でだけサービスした。（だから「シティ」フォン）
都市部でしか使えない携帯電話なんて魅力がないから売れるわけがない。
そして、「採算に合わないから撤退します」という終わり方になる。
誰が悪いのかと言えば、NTT ではなくて、国だと思う。
新しい事業を研究できるほど体力のある会社として NTT を使いたい意向もわかるのだけど。
以下思い出話。
HP200LX を使っていた時、NTT Personal の Paldio 321S 使っていました。
知る人ぞ知る、当時の「名機」ですね。
２つ折りの携帯電話なのだけど、下側のカバーを外すと、PC カードになっているの。
（PC カード自体、すでにわからない人も多そうだ…）
HP200LX は PC カード使えましたから、そこに携帯電話を直接差し込んで、通信ができる。
電車の待ち時間にパソコン通信のログをダウンロードして、電車内で読んで返事書いたりしていました。
（返事は、次回接続時にアップロードする。そういうスクリプトを書いて運用）
そのころ、今の妻とネットで知り合って付き合い始めたのだけど、妻も DDI Poket の PHS 使っていました。
最初に書いたけど、PHS はもともと「家庭用の無線子機」を外に持ち出す発想だった。
そして、この頃の DDI Poket の端末は、「家庭用子機モード」が付いているものがあった。
家で対応する親機を使っている場合、PHS を親機に接続できるの。
外に行くと公衆網に繋がるから電話代が割高になるけど、家では安く通話ができる。
いまの、スマホを家では WiFi で使うような感じ。
SL-Zaurus …いわゆる「りぬざう」を使っていた時は、bitwarp でした。
So-net のやっていたサービスで、通信発信専用の PHS 端末なのだけど、月額料金で使い放題なの。
この通信端末は、CF カードサイズだった。
…これも説明が必要だな。PC カードのサイズを切り詰めて小さくしただけの、拡張カードね。
りぬざうでは CF カードが使えたから、差し込んだらそのまま通信できた。
そして、W-Zero3 も持ってました。[es] と Advance ね。
これは PHS 端末にパソコン機能を付けたもので、国内初の「スマートフォン」という触れ込みだった。
＃国内初、とされるのは W-Zero3 の初代機ね。
僕が持っていたのは、２代目の [es] と、３代目の Advanced [es]。
スマートフォンって、バズワードね。都合によって意味が変わる。
ここでいうスマートフォンは「キーボードを備えたパソコンとして使える端末」の意味。
当時、海外でもそういう端末が流行し始めていて、W-Zero3 は国内初のものだった。
ちなみに、最初に「スマートフォン」という言葉が出てきたときの定義は、インターネットとデータのやり取りができる端末。
メールだけでもいいけど、簡易な WEB ブラウザが付いているとなおよい。
というわけで、この意味での「国内最初のスマートフォン」は i-mode だったりします。
実は世界初でもある。
海外では「スマートフォン」と言って憧れの的だったものが、日本人にはごく自然に生活に溶け込んでいた。
だからこそ「憧れのスマートフォン」として、日本ではキーボードが付いていることが条件にされたのだけど。
最後に関係ないネタ。
PHS が話題になっていた当時、Apple は Macintosh 互換機を許可する戦略をとろうとしていました。
みんなが同じリファレンス（参考物）を元に共通のハードウェアを作り、プラットフォーム（基盤）とする。
…英語で言えば、Common Hardware Reference Platform。頭文字を取って、この互換機のことを CHRP （チャープ）と呼びます。
また、当時はやっとインターネットが一般に普及し始めたころでもあります。
職場や家庭内で LAN を構築することが流行しはじめていました。
そこで「PHS で CHRP 端末を結び、LAN を構築する」という「ネタ話」が出来上がるのです。
真面目そうな話として語っておいて、最後に
♪ピッチピッチ チャープチャープ ランランラン
と歌って落とすんですけどね。
ただの駄洒落なんだけど、この小話好き。
今となっては PHS も CHRP も理解されないので、とても披露できませんね。
＃って、どさくさ紛れに披露したわけだけど。
2017.4.21 追記
最後まで PHS 会社として残っていたのは Willcom でした。DDI Pocket が社名変更した会社。
途中で書いていた、W-Zero3 を発売した会社でもあります。
2014年に Softbank 系列の携帯電話会社と吸収合併され、Y!mobile の一部となっていました。
（ブランドは存続）
しかし、本日…2017.4.21 の発表で、来年３月末をもって、PHS の新規受付を終了するそうです。
PHS サービスは完全に終わることになります。
もっとも、これは「新規受付」の終了で、当面は通話サービスも使えるでしょう。
PHS 以前に流行していたポケットベルも、大幅に規模を縮小したとはいえ、一部では特定用途として使用されています。
契約者に最新のニュース（株価情報など）を文字で届ける、などの使われ方ですが。
同じように、これで PHS が完全になくなる、というわけではないと思います。
現在、PHS は自動販売機などにも内蔵され、データ通信を利用して在庫・売り上げ情報をセンターに送信、適切な在庫補給タイミングを通知するのに役立てられたりもしています。
同じ用途で WiFi 接続を行う機種などもあるようですが、PHS のほうが設置場所が限定されにくいメリットがあります。
おそらくは、こうした「知られていないが実は使われている」というような技術になっていくものと思われます。
2018.4.20 追記
上の追記から１年がたち、PHS の新規受付は終了したようです。
そして、2020年7月に、サービス自体を終了すると発表されました。
上に書いた、自動販売機の在庫管理などの、機器監視用通信はまだサービスを続けるようです。
機器監視用ということは、発信源の位置が固定されていて、「移動電話」ではない、ということですね。
不要なアンテナも撤去していき、最低限残すことで採算に合うのでしょう。
同じテーマの日記(最近の一覧)
別年同日の日記
15年 A Dark Room , Candy box! , Cookie Clicker.
申し訳ありませんが、現在意見投稿をできない状態にしています。 【通りすがり】 懐かしすぎるw 当時H"の通話品質に感動した覚えが有ります。（携帯がハーフレート化して更に酷かったですから） CHRPはRadiusの互換機に憧れましたね(笑) (2016-07-03 17:29:27) |
今日は、ドナルド・ミッキーの命日(2007)
ディズニーキャラじゃないよ。計算機学者で、人工知能学者。
ブレッチレーパークのメンバーだった、というのだから筋金入りの天才。
ちなみに、命日は７月７日ですが、誕生日は１１月１１日です。
ミッキーはイギリス人ですが、イギリス領だった時代のビルマ（ミャンマー）で生まれています。
第二次世界大戦中、ビルマは日本軍によって激しい攻撃にさらされました。
この頃、ミッキーはイギリス本国にいましたが、諜報員になろうと考え、日本語を学ぼうと考えます。
…が、大学の諜報員向け日本語コースは定員オーバーでした。
仕方がなく、同じ諜報員向けの暗号解読コースに入ります。
そして、そこで才能を発揮し、ブレッチレーパークに配属されるのです。
ブレッチレーパークは、イギリス軍の暗号解読部隊。
その活動内容はトップシークレットでした。
今ではある程度秘密解除になり、活動が明らかにされているのですが、詳細はわかりません。
わからないから、よく小説なんかのネタになります。
それはさておき、現代コンピューターの父とされるアラン・チューリングもブレッチレーパークのメンバーでした。
ミッキーは、ローレンツ暗号…当時はフィッシュ暗号というコードネームで呼ばれたそうですが、この解読に携わっています。
話すと長いのですが、本題ではないのでざっと。
ドイツの暗号と言えば、エニグマ暗号が有名です。
エニグマは、タイプライター風の機械のキーを押すと、上にある文字のランプが点灯する、という形で、一文字ずつ別の文字に置き換えていく暗号機です。
まず通信文を作り、エニグマで暗号化し、モールス通信で暗号文を届け、再びエニグマで復号化し、通信文を入手する…と言った形で運用されました。
多くの人が間に入り、そのたびに「文字の書き写し間違い」などの可能性が入り込みます。
何よりも、緊急の通信時に煩雑な過程を経なくてはならない、というのは弱点でした。
もう一つ、エニグマ暗号は、回転する歯車上に作られた電気回路を使い、「一文字ごとに電気回路が組み変わる」ことで暗号を作り出すものでした。
電気回路なので、「入力と同じところに戻る形の出力は作れない」という決定的弱点があります。
A を暗号化すると、必ず A 以外の文字になるのです。これは大きな特徴であり、暗号解読の手がかりでした。
ローレンツ暗号は、この二つの問題点を克服しています。
まず、無線テレタイプを改造した暗号機でした。
テレタイプは 19世紀には使われ始め、第二次大戦の時には無線テレタイプもありました。
この、通信部分に暗号回路を挟み込んだのです。
傍受しても暗号文になっていて意味不明なのですが、送信者がキーを押すと、受信側にその文字が印字されます。
テレタイプは、文字（厳密には、押されたキー）を二進数で表現して記録・通信していました。
そこで、暗号化はこの「二進数」に対して、複雑な仕組みで作り出される二進数を XOR することで作り出されています。
この方式だと、A を暗号化した結果 A になることもあります。暗号解読の手がかりを与えない方式なのです。
エニグマでは、なんでもいいから１つの暗号文を解読して通信文を得ることができたら、「通信文」を「暗号文」に変換できるエニグマ暗号機の設定方法を自動的に見つけ出す機械がありました。
これによって鍵を見つけ出してしまえば、他の暗号も簡単に解読できます。
36台のエニグマが自動的に並列に動き、正しい鍵を見つけ出すまで処理を続けるものでした。
エニグマは歯車によって暗号を作り出しますから「歯車式計算機」と言えます。
ローレンツ暗号に対しても、同じような機械を作ろうとしました。
先ほど、二進数を XOR して暗号にする、と書きましたが、この二進数はエニグマと同じような歯車で作り出されています。
しかし、ローレンツ暗号はエニグマより複雑で、機械式では計算時間が現実的ではない、と予想されました。
そこで、論理的に同じことをする「電子回路」を作り出すことになります。
真空管により、通信文を正しい暗号に変換できる鍵を「計算」して求める機械です。
これがコロッサスで、ENIAC よりも古い、真空管によってつくられた計算機でした。
ミッキーはこのプロジェクトにかかわっていたようです。
本題ではない話でずいぶん長く書いてしまった…
今日の本題はここからの話。
ブレッチレーパークに勤めていたころ、チューリングと昼ごはんを食べながら、機械が知性を持つことはあるか、という談義をしていたそうです。
コロッサスの計算力なら、機械が人間のように考えることも可能かもしれない。
そうした「思考実験」です。
チューリングは、1953年にはチェスを打つアルゴリズムを考えて論文にまとめています。
もっとも、このころはまだコンピューターは非力です。
アルゴリズムを人間が「機械的に」真似て、対局などが行っていました。
そして、ミッキーは 1960年に論文を公表します。
人工知能に関するものでした。
ミッキーの論文も同じように、コンピューターを使用しないでも実行できる方法でアルゴリズムを示しています。
その名も、Machine Educable Noughts And Crosses Engine
Educable は「学習できる」。
Noughts And Crosses は「○と×」の意味。
日本語では「マルバツ」、英語で Tic-Tac-Toe と呼ばれる、三目並べのことです。
三目並べを対戦し、その結果から学習することで育つ人工知能です。
最終的には、絶対に負けないプレイヤーとなります。
略称は、正式名称の頭文字をとって MENACE 。「厄介な相手」という意味です。
絶対負けないプレイヤーに育つ、厄介な相手だということです。
これ、実は今までも僕のページで何度か紹介しています。
MENACE 以上によく知られた名称は「マッチ箱エンジン」。
特徴は、大量のマッチ箱が積み重ねられただけの「マシン」だということ。
中には色とりどりのビーズが入っています。そして、これが自己学習する最強プレイヤーなのです。
仕組みについても過去に書いていますが、改めて書きましょう。
装置を簡略化する都合から、MENACE は必ず「先手」で○を打つことにします。
そして、マッチ箱を 304 箱と、九色のビーズを、各 304 個…できるならもう少し、400個くらい用意します。
箱には、１つづつ３目並べの「局面」の絵を描いておきます。
MENACE は先手ですから、まず「何も描かれていない」局面があります。
続いて、MENACE は９カ所のどこかに○を描き込みます。さらに、人間は残る８カ所のどこかに×を描き込みます。
その次が MENACE の手番です。
9*8 = 72 通りの局面のどれかになっているはずです。
ここで、マッチ箱を減らすためにちょっとしたトリックを許可します。
最初の「９手」は、隅、辺、中央のいずれかですから、実際には「３手」とします。
続く人間の手は…数えるしかないのですが、論理的に同じ形であるものは同じとすると、人間の手が終わった時点で 12通りの局面があります。
以下、同じようにすべての局面を数えていきます。
途中でどちらかが３目並んだらそこでゲーム終了ですから、続く手は数えません。
こうやって数え上げると、全部で 304 通りの手があるそうです。
（この数字は受け売りで、面倒なので僕は数えてません (^^; ）
これを、すべてのマッチ箱の表面に描いておく必要があります。
この人は、ビーズの代わりに豆を利用しています。
さて、最初はすべてのマッチ箱に、９色のビーズを１つづつ入れておきます。
MENACE 先手ですから、「局面に何も描かれていない」絵柄のマッチ箱を取り出し、中からビーズを１つ取り出します。
この取り出したビーズの「色」は、９カ所のマスのどこに手を打つかを意味しています。
では、○を描き込みましょう。ビーズは元のマッチ箱に戻してください。
続いて人間がどこかに×を描き込み、MENACE の番です。
やはり、局面の絵柄の箱を探し、ビーズを取り出します。
ビーズは最初に９個入れてしまっているので、「すでに描かれている場所に○を描く」指示が出るかもしれません。
このときは、ビーズは捨てます。この手は打てない、と MENACE に学習させるのです。
これを繰り返していくと、MENACE はゲーム終了までの手を打っては来るでしょう。
…ただし、学習前はうち筋はランダムで、人間に負けると思います。
負けたら学習しましょう。
最後に打った手は、人間に負ける悪手です。そのビーズを取り出して捨てます。
MENACE はこの手を２度と打ちません。
もし勝つことがあったら、最初からすべての打ってきた手が良かった、ということになります。
ご褒美として、途中で使ったマッチ箱すべてに、取り出したビーズと同じ色のビーズを加えます。
次から、同じ手を良く打つようになります。これも学習です。
こうして、MENACE は勝ちにつながりやすい手は積極的に打ち、負けた手は２度と打たないように成長していきます。
最終的には絶対に負けないプレイヤーに成長するでしょう。
馬鹿馬鹿しいというなかれ。これは立派な「人工知能」です。
MENACE 以前から、マルバツの人工知能は作られています。
1952年には oxo が作られている。
でも、この二つは、人工知能としてのタイプが全然違います。
oxo は、1980年ごろに再流行する古いタイプ。
人間はどう考えているのだろう？ と考えて、その考え方をアルゴリズムで示したものです。
このやり方は、模倣です。本物である人間を超えることはない。
つまり、アルゴリズム考案者を超えることは出来ない、頭の悪い人工知能です。
例えば、将棋はこの方法で「そこそこ強い」人工知能が作れました。
（現在の将棋が強くなったのは、別の方法を組み合わせています）
でも、囲碁ではこの方法は使えなかった。
だから「囲碁は難しい」と言われるようになった。
MENACE はこれとは違い、自己学習する人工知能です。
人間は、すべての局面に対して対応方法を丸暗記する…なんて方法は取りません。
明らかに、人間の考え方とは違っている。
でも、人間とコンピューターは違うのです。
考え方が違ったとしても、結果として正しい答えが導き出せるのであれば「人工知能」と呼んで差し支えないはずです。
今流行しているディープラーニングは、MENACE の遠い子孫に当たるものです。
仕組み自体は大したものではありません。
とても考えているとは思えないような、ランダムな配線の集合体。
マッチ箱と似たようなものです。
でも、学習させるととてもいい結果を出す。…こともあります。
ディープラーニングを使い、将棋より難しい囲碁で、ＡＩが人間に勝った、と騒がれています。
でも、これは間違っている。
囲碁が将棋より難しい、というのは、先に書いた「人間の思考を真似るタイプの人工知能では」という話です。
囲碁はマルバツと同じように、盤面に記号を並べていくゲーム。MENACE と同じように自己学習向き。
そこで自己学習を適用したらうまくいった、というだけで、将棋とは全く別の世界。
「将棋より難しい囲碁」という言葉が間違えていて、自己学習ＡＩにとっては将棋のほうが難しいです。
このことが理解できれば、「やがて人工知能が人間を支配する」なんて言説は噴飯ものだとわかるでしょう。
人工知能は確かに実用になるほど研究が進んでいますが、まだ特定の守備範囲を持つもので、臨機応変な対応が可能な人間に変われるようなものではないのです。
＃逆にいえば、特定の守備範囲内ではＡＩは普及するだろう、ということでもあります。
臨機応変さを持たない人間なら不要になるでしょう。不要と言われないように頑張りましょう。
ミッキーはこの後も人工知能の研究を続け、自然言語処理なども研究しています。
最後は事故死。「元妻」と離婚後も仲が良く、一緒に自動車で移動中の事故でした。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今日は、元任天堂社長の岩田さんの命日です。
亡くなってからもう一年。まだ一年。
想いは昨年の追悼記事に書いたので、今日は日付を記すのみです。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
子供たちが Scratch で遊んでいて、１台しかないノートパソコンの奪い合いが起きるようになった。
ところで、そのノートパソコンは親のサブマシンだ。
仕事で使う会計ソフトはそこにインストールしてあり、決算期なので使わなくてはならない。
というわけで、子供用マシンの購入を検討した。
そして、Chromebook を購入したのだけど、日本では事前に十分な情報を得られず、予想外のことがあった。
まずは、いい面から書こう。
Chromebook は素晴らしい！ まだ使い始めてわずかだが、ちょっと調べものをしたいときなどに気軽に使える。
スリープしている状態からなら１秒で使えるようになる。
完全に電源断の状態からでも、５秒もあればログイン可能になる。
ログインにはパスワードが必要だけど、ログイン後はすぐに使い始めて大丈夫。
（Windows だと、ログイン後に環境整えるのに時間かかるからね）
もっとも、後で書くけど万人に勧められるものではない。
自由に使える Windows マシンがあったうえで、サブとして使うのが前提だ。
十分に使用用途が絞り込まれていれば、安いし、軽いし、電池もちも良い。
（ハードディスクや DVD-Drive のような、重たくて電気食いのモーターを使わないから）
今回購入したのは、Acer の Chromebook C730E C730E-N14M というモデル。
学校などで使用することを想定したモデルで、堅牢さが売りだという。
子供に使わせるのが主目的なので、その堅牢さが魅力だと考えた。
でも、買ってみたら薄くて軽いので驚いた。もっとゴツイのかと思っていた。
現在人気の Chromebook は、ASUS の Chromebook flip C100PA。
値段はほぼ同じだけど、こちらの方が少し安い。
画面がタッチパネルになっていて、キーボードを背面に回してタブレットとして使える。
ただし、CPU はちょっと非力で省電力。
購入モデルは Intel で、flip は ARM 。
Chromebook として使う分には CPU はどちらでも関係ないのだけど、将来 Linux マシンなどにするつもりなら、Intel のほうがつぶしが利く。
もうひとつ。
すぐに詳細を説明するけど、Chromebook はメインメモリ 2GB のものが多い。人気の flip も 2GB。
でも、購入モデルは 4GB 。
そんなことを考えながら選定した。
購入前に情報を調べていて、勘違いしている人が多いように思える。
まず、大前提としてパソコン初心者が１台目に購入するものではない。
世の中には、Chromebook が安いから「初めてのパソコン」として購入検討している人がいるようだ。
もしあなたがそういう人なら、すぐやめたほうが良い。
お勧めの１台目は Windows だ。なぜなら、利用者が多くて一番無難だからだ。
無難で、面白くもなんともない。無難にまとめてあるので最大公約数的なつくりで、使いやすくもない。
でも、初心者なら何よりも必要な「手厚いサポート」がある。
解説書もいっぱい売っているし、ネットで質問しても回答を得られやすい。
ちなみに「２台目」…これは、買い替えの２台目ではなくて、メインマシンとは別の機械、という意味だけど、２台目に買うのもお勧めしない。
世の中では Chromebook は２台目に良いということになっているのだけど、たぶん２台目として買うと不満が出る。
２台目に MacOS を買ってみたり、もしくは Windows マシンを買うのだけど、どうせサブなのだから Linux とのデュアルブートにして遊んでみたりするといいだろう。
OS が違うと、できることが全く違う。いい面もあるし悪い面もある。
そういうことを理解したうえで使わないと、Chromebook は不満だらけのマシンになりそうだ。
逆にいえば、「そんなにパソコンいらんわ」って程度のパソコンの使い方の人は Chromebook なんて買わないほうがいい。
というわけで、初心者向けの足きりは終わった。
以降の話は、Chromebook を買ってもよさそうな人が、買おうと検討していることを前提に書かせてもらう。
Chromebook の安さについて、「同じ性能なら Windows10 マシンでも同じ程度の値段である」と言っている人もいる。
これは事実だ。
Chromebook の多くは、ちょっと非力な CPU で、メモリは 2G しかなくて、ストレージが 16G 程度しかない。
そして、事実としてその程度の性能の Windows10 マシンは売られていて、同じ程度の値段だ。
じゃぁ、その Windows10 マシンは使い物になるのか、と言われると、全く使い物にならないだろう。
Windows10 を「まともに」使いたいのであれば、メモリは 4G 、ストレージは 64G からだろう。
快適に使いたいなら、メモリ 8G にストレージ 128G は欲しい。
でも、Chromebook ならメモリ 2G 、ストレージ 16G で十分まともに使えるし、メモリが 4G になれば快適だ。
ハードウェアのスペックを見て「同程度なら同じ値段」というのではなくて、使い物になる機械かどうかで判断しないといけないのだ。
このコストパフォーマンスの良さが Chromebook の魅力だ。
とはいえ、Chromebook が使い物になるかどうかは、その人の使い方次第だ。
先に、「目的を絞り込んだ３台目」という書き方をしたのだけど、絞り込み方次第では「使い物にならない」ということになる。
大前提として、Google が嫌いな人は使えない。
Google アカウントを取得し、Google に個人情報を含む情報を預けないといけない。
Google は悪だ、と考えている人には許せないことだろう。
Chromebook は、Google のサーバーにぶら下がっている「Thin Client」として動作する。
Thin Client というのは、企業向けコンピューターで使われる用語で、それ自体は計算機能(CPU とメモリ)以外をほとんど持たず、多くの機能をサーバーに依存する機械をいう。
企業で Thin Client を使う理由は、管理の手間が省けるからだ。
会社で使っている業務用のソフトのアップグレードがあった場合、全社で使われる数千台のパソコンに、すべてインストールする必要がある。
しかし、 Thin Client ではそうしたソフトをすべてサーバーに置いているので、サーバーにあるファイルをアップグレードすれば終わりだ。
Chromebook では、この仕組みを企業向けではなく、一般向けに開放している。
だから、ソフトウェアは常に最新版を使える。
Chromebook が適しているのは、まず WEB ブラウジング。
つづいて、Gmail 。WEB mail だね。
Google Docs や Google Spreadsheet を使って、文章作成や表計算もできる。
これらも WEB アプリだ。
他にもいろいろあるけど、全部 WEB アプリ。つまりは、Chromebook では WEB 以外のことは出来ない。
WEB アプリって低機能でしょう？
なんて思う人は、まずは Windows 上で WEB アプリを使ってみるといい。
Google Spreadsheet を Excel の代わりとして使うと、おそらく違うところが目について「やっぱり低機能だ」と判断するだろう。
でも、Google Spreadsheet は、チャットしながら同じ表を編集したりする機能がある。
仕事で情報を共有するときに、非常に有用だ。
さらには、特定の URL にアクセスすることで、内容を CSV で取得したりできる。
プログラム開発する際に、データを Google Spreadsheet にまとめておいて、複数人数で編集してから、プログラム Make 時に最新のデータを自動的に CSV で取得、整形してプログラムに組み込む、なんて芸当ができる。
これは、Excel では出来ないことだ。
すでに、僕は仕事で Google Spreadsheet の便利さを知ってしまったので、Excel に戻りたいとは思わない。
Chromebook には、これらの WEB アプリが、インストール可能なアプリとして提供されている。
もっとも、インストールしたところで、現実的には WEB の URL にジャンプするだけのものも多い。
それでも、Bookmark と違い、配布アプリをインストールするとアプリ一覧の中にアイコンが置かれるようになる。
すぐに呼び出せるので使いやすい。
また、一部のアプリは、WEB で使われるデータをすべてパッケージ化してあり、URL へのアクセスなしに動く。
この場合、ネット接続できない場所でも使用できる。
本当に限られた一部パッケージだけとはいえ、便利だ。
Google Docs や Google Spreadsheet はこの機能に対応しているので、最低限の作業はオフラインで完結できる。
こうした「アプリ」以外に、「機能拡張」と呼ばれる仕組みもある。
こちらは、Windows でいえばデバイスドライバ的な役割を持つ。
たとえば「ファイル」というアプリがある。ファイル一覧を表示するものだ。
通常は、ローカルのファイル一覧が表示される。
とはいえ、Chrome はローカルストレージが非常に小さい。ここにファイルを置くことはあまり想定していない。
そこで、Google Drive の中身も表示される。
ネットの向こうにある、クラウドストレージだ。Chrome では、通常のファイル置き場としてここを使う。
この「ファイル」アプリは機能拡張に対応していて、好きなクラウドストレージを使えるようになっている。
SMB (Windows のファイル共有形式)対応の機能拡張もあるので、家に NAS (LAN に接続するハードディスク) がある人や、メインマシンとしての Windows マシンがある人は、そのファイルも使える。
これらもよく言われていることだから、購入検討者には「いまさら」な話だろう。
それでも購入検討を続けているのだから、WEB アプリで十分な用途、または WEB アプリでないといけない用途に使うのだと思う。
うちの場合は、最初に書いたけど子供たちの Scratch だ。これは WEB アプリなので、Chromebook で十分だ。
先に書いたけど、僕は Google Spreadsheet をつかえればそれでいい。
でも、「表計算」ではなくて、「Excel」でないとどうしてもだめなんだ、という人には使えない。
一応、Microsoft も Office online という WEB アプリを用意していて、Excel も使える。
使えるのだけど、これは第三の表計算ソフトであって、デスクトップの Excel とは似て非なるものだ。
Excel が必要なんだ、という人は Windows を使わなくてはならない。
同じことは、 Word についても言えるし、Photoshop についてもいえる。
どうしても使いたいソフトがあるなら、そのソフトが提供されている OS を選ばないといけない。
さて、子供に与えることを前提として購入検討していたら、当然のことながら Google アカウントの問題が出てくる。
Google では、（米国法が定めた）未成年保護の観点から、13歳未満のアカウント取得を許可していないのだ。
ここで大事なのは「アカウントが取得できない」ことではなく、これが「未成年保護」のためだということだ。
Google の機能を 13歳未満に使わせたくない、ということではない。
実は、Google では、未成年には親のアカウントの権限を一部委譲して使わせることのできる機能がある。
この場合、未成年ユーザーは親の管理下に置かれ、閲覧した WEB サイトの情報などは、すべて親に筒抜けになる。
Supervised user 。日本語では「監視ユーザー」と訳されている。
普通の PC Chrome でも監視ユーザーは作れるのだけど、Chromebook のために作られた機能だと考えたほうがいいだろう。
Chromebook を利用できるユーザーを登録する際に、未成年用に監視ユーザーアカウントを作ることができる。
監視ユーザーでログインすると、親のアカウントを借りる形で WEB を閲覧することになり、その際の URL 履歴は後で親が確認できる。
（確認は Chromebook を使う必要はない。Google アカウントに対して履歴が記録されているため、PC からでも、Chrome 以外のブラウザからでも見られる）
この機能は、2013 年の秋ごろから一部ユーザーに提供が開始され、2014年の春には一般公開されたようだ。
にもかかわらず、日本ではこの機能の詳細を書いたページがない。
無いというか、監視ユーザー機能は「どの URL を閲覧したか親が確認でき、必要なら URL 単位、ドメイン単位でブロックできる」という程度のことしか書かれていない。
公式にはいろいろな制限ができる、と書いてあって「アプリのインストールを禁止できる」とあった。
アプリのインストールは出来ない、と書かれていたページもあったのだけど、不安に思って情報を調べたところ、Google 公式のヘルプファイルには「管理者権限でのインストールは可能」ということが書かれていた。
ということは、監視ユーザーと通常ユーザーの違いは、WEB アクセスが自由ではないことと、勝手にアプリをインストールすることができないだけなのだろう、と考えて購入した。
しかし、そうではなかった。
監視ユーザーは通常ユーザーと明らかに機能が違う。
後から見返したら、そう書かれているページもあるのだけど、あまり重要視している人はいないようで、さらっと書かれている。
もしかしたら、そういう機能があるから紹介しているだけで、実際に子供に使わせたりはしていないのかもしれない。
そこで、子供に使わせる人向けの、「警告としての」監視ユーザーについての話を書きたいと思う。
ちょっと話が長くなるので、いったんここで区切ろう。
同じテーマの日記(最近の一覧)
関連ページ
Chromebook を買ったのだけど【日記 20/05/21】
Lenovo Ideapad Duet 購入【日記 21/02/23】
Microsoft Office 発売日 (1989)【日記 16/08/01】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
先に、Chromebook では13歳未満は「監視ユーザー」としてログインしなくてはならないことを書いた。
Google は未成年保護の観点から、13歳未満にはアカウントを発行していない。
Chromebook の利用には Google アカウントが必要なのだけど、監視ユーザーは、親の Google アカウントを間借りして利用できる。
その代わりに、何をやったかは親に筒抜けになる。
13歳未満は「アカウントが取得できない」ことを、「親の保護下にある」ことで回避ししているのだ。
非常によく考えられた仕組みだ。
では、子供が「監視ユーザー」として、何をできるか書いておこう。
まず、Chromebook の基本である、WEB アクセスはできる。
まぁ当然だね。これができないようじゃ Chromebook とは言えない。
…以上だ。他に何もできない。
Chrome 以外のアプリは一切使えない。Gmail も使えない。
管理者ならインストールできる…という公式情報もあったが、この情報は僕の勘違いだった。
（Chromebook のヘルプに書かれていたが、Chrome for work、または Chrome for education という特別バージョンの話だった。
実機購入前で細かな違いの意味が分かっていなかった。）
公式ヘルプにも、監視ユーザーが「アプリをインストールできないようにする」ことができる、と書かれている。
この書き方だと、禁止しない（つまりインストールできる）方法もありそうだが、そうではなかった。
機能拡張も使えないので、自宅内の NAS へのアクセスもできない。
NAS に家族の写真などが置いてあるのだけど、それを見ることもできない。
先に書いたが、我が家では Chromebook は子供の Scratch 用として購入した。
Scratch 自体は、子供でも親の同意のもとでアカウント取得ができるし、作成したプログラムはクラウドに置かれる。
だから、WEB ができれば問題がない…ともいえる。
だけど、プログラムしながらちょっとしたメモファイルを作ることもできない。
子供が好きな Scratch で作られたゲーム、「ネコRPG」ではパスワード形式のセーブを採用しており、非常に長いのでコピペでファイルに保存したい。でもできない。
これでは子供に使わせるのにあまりにも問題が多い。
ただし、この状況の改善のため、努力は続けられているようだ。
監視ユーザーの機能が提供され始めたのは、2013年の秋。
このときは OS のβテスターに対する提供だったようだ。
その後、いつから一般提供され始めたかわからない。
でも、たぶん 2014年の３月中頃ではないかと思う。
というのも、この時期に急に「監視ユーザーがアプリを使えないのは問題がある」という不満が、いたるところで書き込まれ始めるからだ。
ところで、Chromebook は Google が開発している、とされることが多いけど、実は違う。
オープンソースの Chromium プロジェクトで開発されていて、Google はそのプロジェクトを主導する重要メンバーに過ぎない。
オープンソースなので議論もオープンにされているのだけど、監視ユーザーとアプリの問題はいち早く報告され、多くの人が「改善すべきだ」と意見を寄せている。
一方、同じような議論は Chromebook Central Help Forum（Google 公式のユーザーフォーラム）でも行われる。
こちらでも、多くの人が Google に「改善してほしい」と意見を寄せ、Google の社員も「積極的に意見を寄せてほしい」と前向きに回答している。
しかし、2014年の中ごろで、どちらの議論も停滞する。
Chromium プロジェクトでは、改善が必要であることはわかっているが、どうも実装しようとしていることの「矛盾」に悩まされ始めたようだ。
監視ユーザーは、できるだけ WEB 上に足跡を…個人情報などを残さないようにしたい。
WEB を閲覧する機能だけならともかく、WEB アプリを使い始めると、積極的に自分の「作品」を残してしまうことになる。
ともかく、改善が必要なことは認める。改善に努める。
そのためには、どのように改善を成し遂げるかの方針を決めなくてはならない。
これまでにもらった意見を元に考えるので、今後新しい意見を出すのは控えてくれ、という投稿が行われる。
「意見するな」は傲慢に思えるかもしれないが、まっとうな話だ。
非常に難しい課題に挑もうとして、仕様を定めている最中なのだ。
そこに横やりを入れられると、誰かが「仕様変更しよう」と思い始めるかもしれない。
プロジェクトにとって一番困るのは、この「土壇場での仕様変更」で、それを避けることが重要課題になったのだ。
Chromium プロジェクトはハッカーの集まりだから、意図を理解したのだろう。
意見を出す人は激減した。
でも、その後も「僕はこう思う」的なことを言い出す人が少しいたため、議論のための掲示板自体が閲覧専用にされた。
その後、2015年の秋になって、作業チームから「トリアージが必要だ」という投稿が行われている。
やろうとしていることが矛盾だらけで難しいことが予期される。
＃トリアージ：医療現場で使われる概念で、とにかく現状を把握して優先度をつけること。
この優先度をつけるのに手間取るようでは意味がないので、直感でつけて構わない。
ただし、状況が変わるたびに優先度を見直すこと。
ユーザーフォーラムの方も、一部の人は Chromium の議論も見ているのだろう。
2014年中ごろから議論が低調になる。
ただ、こちらはあくまでもユーザーフォーラムなので、早く何とかしてほしい、という要求は時々出される。
上手くいかない理由を説明する人もいるのだけど、それはユーザーフォーラムに参加する人の意見にすぎず、Google 公式見解でもない。
Google は教育機関向け(つまりは子供向け)に特別な Chromebook を販売しているので、その商売の邪魔になる「監視ユーザー」機能は充実させるわけがない、というような邪推を行う人も出始める。
Chromium の掲示板はずっと停滞していたが、2016 年の５月末（最近だ）になって動きがあった。
掲示板は一般の書き込みは不可能みたいなのだけど、ある程度の権限を持った人なら書き込めるみたいなのだ。
そこで「ずいぶん経つけど、その後どうなってますか？」と質問が出た。
関係はわからないけど、どうも Chrome の全体責任者に近い立場の人が、監視ユーザー機能のチームの責任者に質問したようだ。
報告から２年もたつのに解決方法も提示されないので、ちょっと心配しているらしい。
いろいろと会話があるのだけど、返事は「監視ユーザーチームで作業中。」だった。
解決に向けて取り組みが進んでいる、というのは明るい話だ。
できることなら、早期に解決してほしいと思っている。
2016.7.14 追記
この問題、暫定的な方法で回避しました。
あくまでも回避であって根本的な解決ではないのだけど、何もできないよりはマシ、という程度。
関連ページ
Chromebook を買ったのだけど【日記 20/05/21】
Lenovo Ideapad Duet 購入【日記 21/02/23】
Microsoft Office 発売日 (1989)【日記 16/08/01】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
chromebook の「監視ユーザー」がアプリ/機能拡張を使えない問題の続き。
「機能拡張」に関してはどうしようもない。絶望的だ。
でも、アプリに関しては、もともと WEB アプリだ。
bookmark として WEB アプリが使えれば、当面はしのげる。
ところが、例えば Google Docs を使おうとすると、Google アカウントが必要になる。
Google カウントが取得できないから監視ユーザーを使っているのであって、ここで Google アカウントが必要だ、というのは堂々巡りだ。
ここでちょっと考える。
Google Docs は、本当に Google アカウントがないと使えないのか？
いや、そんなことはない。
Google アカウントがないと、文章ファイルを「所有する」ことは出来ない。
でも、Google Docs の文章ファイルには URL が割り振られている。
共有しない設定では、所有者以外が URL アクセスしてもエラーとなる。
でも、共有していれば、URL アクセスすることで文章の内容が見られる。
さらには、共有設定が「誰でも編集可能」となっていれば、内容を変えることだってできる。
ということは、 Google アカウントを持っていない監視ユーザー用に、共有設定した文章ファイルを用意しておけば、監視ユーザーが文章を作ることができる。
自由に新しいファイルを作れないというのは不便だけど、ないよりはましだろう。
この方法で運用できるのではないか。
とりあえず試してみよう。
GoogleDocs の文章 URL は、あるきまった URL の中に、文章ファイルの ID が入っている。
この ID が、 base64 エンコーディングされた…ほぼランダムと言っていい、44文字の文字列になっている。
紙に書いて手で入力、というのはやりたくない。
普通ならメールで送信、とかなるのだけど、今は WEB 以外が使えないから困っている。メールも無理。
いろいろ考えてみたが、一番簡単なのは SD カードを経由する方法だった。
テキストファイルに URL を書いて、Chromebook に挿入。ファイル表示されたらダブルクリック。
テキストエディタはないので（だから困っているのだけど）、編集などは出来ない。
でも、WEB ブラウザはただのテキストを表示できるモードがあるので、そこから URL をコピーし、URL 入力窓にペーストすればアクセスできる。
これで共有された Google Docs のファイルを開くと、監視ユーザーでも文章に書き込むことができた。
仕上げは、この URL をブックマークしておくことだ。
これで、とりあえずテキストをコピペしておいて置いたり、ちょっとした文章作成などは出来るようになった。
もっとも、新しいファイルなどは作れない
ところで、Chromebook の全機種が SD カード使えるわけではないんだよね。
以下、SD 以外で試してみたことを書こう。
先に書いたように、ほぼランダムで 44文字もあるので、紙に書いて手入力、というのは避けたい。
メールも使えない。NAS にアクセスもできない。
Chrome には、他の Chrome とブックマークや履歴を共有する機能がある。
そして、「監視ユーザー」も、Chromebook に限らず、PC の Chrome で共有できる。
じゃぁ、PC で監視ユーザーに切り替えて、通常アカウントの Chrome のウィンドウから URL をコピペして…と考えたのだけど、これはダメ。
監視ユーザーの所有物、という概念は存在せず、一切の情報が共有できない。
「履歴」の共有を使う方法も「ブックマーク」の共有を使う方法も、そもそも監視ユーザーではこれらが共有されなかった。
（すでに書いたが、「監視ユーザー」の設定自体は共有できるが、その監視ユーザーに関するものが共有できない。
なお、管理者は監視ユーザーの閲覧履歴を知ることができる。監視ユーザーは自分自身の履歴を見られない。）
何とも不便だ。
我が家には WEB サーバーがあるので、家の中の WEB サーバーに URL を列記した「リンク集」を作ってしまう、という方法も考えた。
しかし、WEB サーバー使うのなら、いっそのこと WEB サーバー上に、テキストエディタの WEB アプリを構築すればいいのではないか。
そうすれば、Google Docs なんて使わずに済む。
そう思って、WEB アプリのテキストエディタでソース配布のものを探してみるが、案外見当たらない。
ふと気づいて、QNAP アプリを探してみる。
QNAP は我が家で使っている NAS だ。
先ほど「NAS へのアクセスができない」と書いたのだけど、これは SMB 経由でファイルとして扱えない、という意味だ。
QNAP は高機能 NAS で、http サーバーの機能を持っている。WEB としてアクセスできる。
さらに、QNAP 上で様々な WEB アプリを動かせるようになっていて、アプリストア経由でインストールできる。
（アプリは基本的に無料だ）
そして、Notes Station という、ワープロ機能を持つアプリが配布されていた。
一連の書類を「ノート」という単位にまとめ、そのノートを複数冊管理できるようになっている。
利用には QNAP にアクセスするためのアカウントが必要なのだけど、これは家の中のサーバーなのでいくらでも発行可能だ。
URL も非常にわかりやすく、受け渡しを考えずとも、簡単に手で入力できる。
というわけで、「我が家としては」解決できそうだ。
一般性のない方法なので、同じ悩みを持って読んでくださった方には申し訳ない。
先に書いたように、Google Docs に子供が使える「共有ファイル」を作って、SD を使うか、紙に書いて手で入力するか…なんとか URL を渡せれば、「ないよりまし」という程度の使い方はできると思う。
無料の WEB サーバー使ったり、掲示板つかったりして URL を受け渡すのはお勧めできない。
「公開」されてしまうので、見知らぬ第三者が、ドキュメントに書いた情報を覗き見できるかもしれない。
SD カードが使えず、家庭内にも WEB サーバーがなければ、多少面倒でも紙に書いて手で入れた方がよさそう。
Windows も MacOS も、標準で簡易 WEB サーバー機能が付いてくるから、その機能を使って URL の共有に挑むのもいいかもしれない。
（僕はやったことないから詳細を語れない）
＃そもそも、ここで書いている Google Document での共有は、URL さえわかれば誰でも見られる、「公開」方法だ。
ただし、その URL が長すぎて、受け渡すのにも苦労するほどなので、推察も難しい、という点でセキュリティを保っている。
＃何とか「最初の１ドキュメント」が共有できれば、その中に URL を書くなどして、以降のドキュメントを増やすこともできるだろう。
URL の受け渡しをなんとかすれば、後の道は開ける。頑張ってくれ。
ちなみに、QNAP のアカウントを子供たちにも与えることで、SMB 経由ではファイルにアクセスできないけど、NAS へのアクセスは可能になる。
家族写真などが大量においてあるが、見たければそれらも見られる。
QNAP 上で動作する WEB アプリの「写真アルバムソフト」が入っているので、時系列などで写真を気軽に眺められる。
Chromebook は子供たちに使わせるものなので、あまりややこしい方法は取りたくない。
だけれども、現状としては「できない」ことよりも「できる」ことのほうが、幾分かましだろう。
引き続き Chromebook のバージョンアップは頑張ってほしいのだけど、今は工夫で乗り切ることにしよう。
関連ページ
Chromebook で子供ができること【日記 16/07/12】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今日は、ダン・ブルックリンの誕生日(1951)。
表計算ソフト、Visicalc の考案者です。
後でもう一度書きますが、僕は VisiCalc はパソコンソフト最大の発明品だと思っています。
こんなに応用の利く仕組みは、汎用機時代にもなかったし、その後も現れていない。
ただ、それ以前にも表計算は存在したそうです。
まず、「表計算」という概念自体が、経済学の世界にありました。
紙の上に数値を書いていき、計算結果をもとにまた別の計算をし…というようなものですが。
自分で確定申告とかしたことがある人なら、単純な「事実」の数字をいくつも書き込んだうえで、「(1)と(2)のうち大きい方」とか「(3) に1.2を乗じたもの」とか、紙に書かれた指示の通りに単純な計算を繰り返したことがあるでしょう。
あれが、まさに表計算です。
その表を埋めて財務書類を生成する、という意味での「表計算ソフト」なら、汎用機にもあったという話も目にしました。
ただ、それは VisiCalc のような汎用性があるものではない。
1978年の春、ダン・ブルックリンは、ハーバード・ビジネススクールで、教授が黒板に書いていた計算式の一つで計算を間違えたことに気付き、以降のすべての計算をやり直すところを目撃しました。
その時に、こんな単純な計算はコンピューターに任せられればいいのに、と考えたのだそうです。
ダンは、学校にあったタイムシェアリングシステムで、考えをプログラムしてみます。
表の「マス目」に対して、他のマスとの関係性を示す数式を設定しておきます。
そして、いくつかのマスに数値を入れると、即座にその数値で計算が行われ、マス目が書き換わるのです。
しかし、タイムシェアリングシステムは、使用する時間に対して課金されました。
表を書き換えながら計算する…なんてソフトは、わかりやすいけど操作に時間がかかります。
タイムシェアリング向けではありません。
ダンは、このプログラムを誰でも使えるように、当時発売されたばかりの Apple II で作ろうと考えました。
しかし、問題が一つ…
ダンの考えていた表計算プログラムでは、表のどこでもすぐに書き換えられるように、縦横に自由に動くカーソルが必要でした。
ダンは Alto の存在を知っていて、同じようにマウスを備えたシステムを夢想していました。
しかし、Apple II にはマウスはありません。
代わりに、ブロック崩しを遊べる「ボリュームコントローラー」が付いていましたが、これだと左右、または上下の動きしか表現できません。
何とかキーボードで操作しようとしても、Apple II のキーボードには、左右の矢印キーしかありません。
これでは上下に動けません。
結局、矢印を押すと左右に、スペースを押しながら矢印を押すと上下にカーソルが動く、という操作にしたのだそうです。
ダンの友人のボブ・フランクストンがプログラムを担当し、プログラムが形になります。
最初は「Calculedger」（カルキュレジャー）という名前だったそうです。
このソフトを販売しようと、彼らは Apple 社に持ち込みます。
しかし、Apple では、Apple II の売れ筋ソフトを、ホビー向けの、ゲームとプログラム言語だと考えていました。
「ビジネス向けに使える」なんていう、数字を計算するだけのソフトには興味がありません。
マイクロソフトにも持ち込んだそうです。
しかし、こちらでも同じような反応。
当時はパソコンはホビー向けで、ビジネスに使おうなんて人は誰もいなかったのです。
ダンが教授たちにプログラムを見せてみると、多くの人は感心してくれました。
しかし、それ以上の興味は示しません。
教授たちは、必要があれば計算を学生に任せていました。
だから、「学生がやってくれる」が、「コンピューターがやってくれる」に変わったとしても、それほど大きな変化はなかったのです。
教授の一人は、企業では財務処理に汎用機が使えるのだから、パソコンでビジネス向けの計算を扱うものなどいない、とアドバイスをくれます。
しかし、その教授が、１年上の学生を紹介してくれます。
すでに卒業し、パソコン向けソフト販売の「パーソナルソフトウェア」社を興していた。ダン・フィルストラでした。
（名前が同じなので、以下は彼のことは「フィルストラ」と呼びます）
フィルストラはダンと契約し、Calculedger の販売に力を貸すことにします。
まずは、名前をわかりやすく変更します。
表計算は、計算過程を見えるようにするものです。
Visible Caliclator (見える計算機）。
だから、これを縮めて「VisiCalc」というのが、フィルストラの考案した名前でした。
ダンの考案した開発時の名前…Calculedger は不採用で、販売時には VisiCalc という名前が使われます。
フィルストラは VisiCalc をコンピューターフェアで発表しますが、やっぱり当初は売れません。
発売月の販売本数は、500本程度だったそうです。
しかし、手ごろに買える値段のパソコンで、ビジネスに必要なややこしい計算が可能だという噂が広まり、人気は急上昇します。
１年半後には、１か月の販売本数は１万２千本に達していました。
パーソナルソフトウェアは、VisiCalc の会社、ということで「VisiCorp」と社名変更します。
そして、VisiCalc と一緒に使うと便利な、連動ソフトを開発し、販売していきます。
計算結果をもとにグラフ化したり、現在の売り上げデータをもとに今後の推移を予測したり…と言ったソフト。
このときに依頼されて作成したのがミッチ・ケイパーで、彼に莫大な資産をもたらしました。
その後、ミッチ・ケイパーは Lotus 1-2-3 を作ります。
表計算ソフトの世代交代でした。 VisiCalc の売り上げは落ち、Lotus 1-2-3 は大人気となります。
売り上げが落ちた VisiCorp はソフトの改良を怠ったせいだとダンを訴えます。
ダンは VisiCorp から VisiCalc の版権を引き上げようとフィルストラを訴え、フィルストラはさらに、VisiCalc の名称は自分が考えたもので、勝手な販売はさせないと返し…
泥沼になっていた二人の仲を取り持ち、和解させたのはミッチ。
Lotus 1-2-3 で参入してライバルにはなっていたのですが、そもそも VisiCalc の周辺ソフトで儲けた恩を忘れていませんでした。
ここら辺の話は、ミッチ・ケイパーの誕生日に書きましたので、そちらも参照してください。
さて、最初に書いたけど、VisiCalc が最大の発明だという話。
VisiCalc は、おそらく最初の「考えるための道具」としてのソフトウェアでした。
汎用機では、計算時間は課金対象でした。
データを流し込み、計算させて、結果を得る。計算を操作しながら試行錯誤する、というような考え方はありません。
ミニコンピューターはもう少し計算機の使い方を自由にしましたが、基本的には同じでした。
コンピューターを使うときに、ゆっくり考えていると、どんどん課金されてしまう。
だから、あらかじめ考えておいた操作を一気に行い、結果を得る。それが普通の使い方です。
でも、VisiCalc は Apple II という「パソコン」の上で作られました。
パソコンには、ゲームが多数ありました。
まさに、コンピューターを「操作しながら考える」ことを楽しむソフトです。
VisiCalc は、ゲームとは違ってビジネスに使える実用ソフトでした。
しかし、ゲームのように時間を無駄遣いすることが許されました。
その結果、とにかく集められたデータをもとに、試行錯誤しながら考える、という使い方が可能となったのです。
以下は僕の経験話。
ゲームを作っている時に、企画屋から鉛筆で書いたラフな曲線を描いただけのグラフを見せられながら、「こんな感じに難しくなっていくゲームにしたいのだけど、どういう式にすればいいかな」と相談を受けたことがあります。
僕は、彼に表計算ソフト（VisiCalc ではありませんでしたが）の使い方を教えて、大まかな計算式の必要パラメーターを自由にいじれるようにして、結果が即座にグラフに反映されるようにしました。
あとは、このパラメーターを思う存分いじって、理想のグラフができたところが「目的の式」です。
これを教えてから、その企画屋は表計算をゲーム作成のツールとして便利に使い始めました。
これ、ゲームに限らず、どんな業界でも応用可能。
将来こうしたい、という目標があれば、その目標に向かって何を揃えていけばいいのか試してみることができる。
状況をシミュレーションするための数式が考案できること、というのが条件ですけど、ある程度大雑把な数式であったとしても、何も指標がないよりもずっといい。
あらかじめ決められた計算をする、という使い方ではなくて、どんな計算がいいのかを試行錯誤して考える。
「計算機」のパワーは十分に生かしつつ、その真の目的は「計算」ではなく、考えることにあります。
もちろん、ただの高機能計算機として使うこともできる。
VisiCalc の登場で、計算機は「計算する機械」から、「考えるための道具」に変わったのです。
VisiCalc が売れ始めたのは、ビジネスユーザーがこのことに気付いたからです。
パソコンには多くのソフトがありますが、「考えるための道具」として使用できるソフトは、そう多くはありません。
エディタやワープロは考える道具なのですが、元はタイプライターの模倣から始まっています。
PhotoShop や Illustrator も考える道具ですが、紙の模倣から始まっています。
しかし、「表計算」は、コンピューターを計算機として使う延長上にありながら、考える道具となった最初のソフトなのです。
パソコンがないと生み出すことができなかった、パソコンらしい考える道具。
今でも、表計算ソフト以外に、このようなソフトは無いように思います。
＃ただし、いわゆるプログラム言語は除外して考えています。
後で書きますが、表計算も「プログラム」ではあるので、ちょっとずるい基準です。
途中で書いた通り、ジョブズもゲイツも、このソフトが持ち込まれたときに興味を持ちませんでした。
いや、作者のダン・ブルックリンすらも、このソフトを「経済学のわかる人向けのビジネスソフト」として準備していたのです。
その応用性の高さに気付いたのは、VisiCalc を購入したビジネスユーザーでした。
評判は広まり、VisiCalc が使いたいから Apple II を購入する、というユーザーが急増します。
まさに、パソコン業界最初の「キラーソフト」と言っていいでしょう。
Lotus 1-2-3 が出たときは、このソフト欲しさに IBM-PC を購入する人が急増しました。
Mac 用として開発された、最初の Excel が発売されたときは…「Mac の画面は狭すぎる」と不満が出たようです。
ソフトは魅力的でしたが、ハードウェアが追いついてなかったのですね。
しかし、Excel は Mac のキラーソフトとして初期の Mac を牽引しましたし、Windows が順調になってからは Windows のキラーソフトとなりました。
表計算は、プログラム環境の一つです。
セル間のつながり、という形で処理を書き込んでいき、条件判断なども交えたアルゴリズムを表現し、最終的に結果を出すのですから。
プログラム覚えたいけど、難しくて挫折、という話はよく聞きます。
いわゆるプログラム言語は、最も簡単だと言われるような初心者向けのものでも、それなりに難しい。
でも、表計算ならそれほど難しくありません。
「計算」しかできないために、目的が明確でわかりやすいのです。
それでいて、「計算」というのは数字の操作にとどまらず、非常に多くのことができます。
表計算の機能だけで自由なプログラムが作れるか、と言えば、作れません。
しかしそれは「プログラム言語ではない」という意味ではありません。
計算目的に限って言えば、非常に簡単に目的を達成できる良いプログラム環境です。
会社員時代、勤怠表を書くのに使っていたな。
何年何月、と入れておくと、曜日計算してカレンダーを生成してくれるの。
そして、そこに出勤時刻と退勤時刻を書いていくと、１か月に何時間働いて何時間残業、って出してくれる。
おそらく、こういう使い方をすることは、ダン・ブルックリンは想定していなかった。
でも、実際できてしまう。まぁ、進化の中で関数が増えたおかげでもあるのだけど。
表計算はデータベースにもなります。
何万件もデータがあるような大規模データベースには使えませんが、数千件レベルであれば、十分実用的に使えます。
データベースとして使う場合は「計算」は行いませんから、表計算と呼ぶのはおかしいかもしれませんが、言葉の意味を超えて使えてしまうほどの汎用性があるというのはすごいことです。
Google Forms って仕組みがあって、WEB アンケートを簡単に作れるのね。
このアンケート結果は、Google Spreadsheet っていう表計算のファイルとして蓄積されます。
アンケート結果だからデータベースに入れるべきなのだけど、データベースとして表計算を使っているのね。
そして、このデータを自由に「計算」して、アンケートの結果を集計してグラフ書いたりできます。
その Google Spreadsheet なのだけど、WEB ブラウザで表計算ソフトが動くようになっていて、誰とでも共有できる。
仕事で便利に使っています。
アプリを作る際に各国語版を作りたくて、「日本語」のメッセージ一覧を表計算にほおりこんだ。
そして、英語の翻訳は他の人に任せた。
実際のデバッグ時に「ちょっとニュアンス違うな」なんて思ったら、誰でも修正できる。
これ、日本語・英語と、システム内で使っている「文章の意味を示したタグ」が並んでいます。
そして、このタグは、アプリ内の文章を表示したい部分に同じものが埋め込んである。
実際に動作するときは、タグの部分に日本語・英語の文章が表示されるのです。
そのため、アプリに文章をまとめた「言語ファイル」を組み込まないといけない。
ここが Google Spreadsheet を使う最大のメリットで、アプリビルド時に、最新データを取得して言語ファイルを作るのを自動化できる。
Excel だったら、最新ファイルを扱いやすい CSV で吐き出して処理して…とか必要なのですが、Google Spreadsheet は WEB アプリなので、特定の URL にアクセスして CSV をダウンロードできるのですね。
あとは、テキストファイルなので perl なり ruby なりで処理して必要なファイルにしてしまえばいい。
そんなわけで、表計算はプログラムに必要なデータ整理ツールとしても欠かせません。
Excel を使ってドット絵を描く人や、Excel をワープロとして使うような人もいますね。
これ、よく「やめてくれ」って批判をきくのですが、僕としては構わないと思っています。
間違った使い方だという人もいるし、それは事実かもしれない。
でも、想定を超えた使い方ができて、それなりに使えてしまうというのは、それだけ汎用性が高い環境であることを意味しています。
そして、汎用性が高いから、ゲーム作成の際に事前シミュレーションをしたり、各国語ファイルを生成するデータ整理ツールにしたり、アンケートフォームの自動集計用にしたりできるのです。
もし「変な使い方しないでまともに使う」人ばかりだったら、こんなに応用が利くソフトに育たなかったと思うよ。
今後の表計算ソフトには、もっとお絵かきしやすい仕組みや、ワープロとして使いやすい仕組みが備わっていくかもしれない。
だって、そうやって使う人がいるのだから。そして、それらの機能が充実することで、さらなる応用が可能になる。
どんどん無駄なことやればいいんです。
元々「計算機資源の無駄遣い」が可能だと気づいたところから VisiCalc が始まっているのだから。
同じテーマの日記(最近の一覧)
関連ページ
ミッチ・ケイパーの誕生日(1950)【日記 13/11/01】
Microsoft Office 発売日 (1989)【日記 16/08/01】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今日は PowerPC の開発が発表された日。
古い Macintosh で使われていた CPU です。
少し前、Wii / PS3 / XBOX 360 が争っていた時代、この３つのゲーム機の CPU はいずれも PowerPC を元としたものでした。
というくらいには普及していたのですが、そのころを頂点にすっかり消えてしまった感があります。
PowerPC とは、POWER プロセッサの PC 版。
いや、正式名称は Performance optimization with enhanced RISC - Performance Computing で、この頭文字が PowerPC です。
でも、こんな正式名称がどう見たって後付け。
POWER は、世界最初の RISC プロセッサです。
1970年代、コンピューターをプログラムするのには、アセンブラを使うのがまだ普通でした。
Ｃ言語のような高級言語はすでに登場していますが、性能を出すにはアセンブラでないといけないと言われていた時代。
PDP-11 は、それまでのシリーズとの互換性を断ち切り、非常に使いやすい機械語命令を搭載して話題となります。
PDP-11 のアーキテクチャは、6800 6809 68000 V60 トロンチップなど、多くの CPU の手本とされました。
その特徴は、命令の直交性が非常に高いこと。
CPU の機械語命令では、足し算、引き算という「命令」と、結果を残すレジスタやメモリアドレス、計算に使用するレジスタやメモリアドレス、の３つの組み合わせで作られます。
たとえば、Z80 の ADD A,#5 という命令は、レジスタ A の現在の内容に、数字の 5 を加えて、その結果を A に残すことを意味します。
LD A,(1234) は、アドレス 1234 のメモリ内容を、レジスタ A に読み込みます。
じゃぁ、ADD A,(1234) だったら、アドレス 1234 のメモリ内容を A に足すか…というと、そうではありません。
そんな命令は存在しません。ADD では、アドレスを指定したメモリとの足し算は出来ない、という決まりがあるのです。
こうした決まりは、CPU 設計の技術上の問題で生じています。
しかし、極力技術上の問題をクリアし、人間が直感的に使えるようにすることを「直交性が高い」と呼びました。
＃直交性は数学的な概念です。グラフを書くとき、X座標とY座標が「直交している」という、その直交。
X と Y がお互いを制限することなく、自由であることを意味しています。
さて、PDP-11 の頃から始まる、直交性が高くて使いやすい CPU は人気が出ます。
その一方で、これらの CPU は技術的な課題をクリアするために、非常に複雑な仕組みを使っていました。
そして、その複雑さは「遅さ」につながります。
もう一つ、先に Z80 の例を挙げましたが、Z80 は非常に命令が豊富です。
足し算や引き算は当然として、「裏レジスタ」というものを持ち、レジスタの表と裏を入れ替える命令とか、メモリ内のある領域から特定の 1byte を入れてあるアドレスを見つけ出すとか、1byte = 8bit を、4bit で表現できる 10進数２桁とみなして足し算・引き算するための命令とか…
これらの仕組みもまた、複雑で「遅さ」につながります。
1970年代、IBM は豊富な命令のどの程度が利用されているのか、既存のプログラムコードを調査しました。
調査対象は、主に IBM System/370 用のプログラム。
人間が直接アセンブラで書いたプログラムや、FORTRAN や COBOL を利用したプログラムなど、様々なものがありました。
さらに、IBM のコンピューターだけでなく、他社のコンピューターも調査したようです。
その結果、次のようなことがわかります。
・プログラム実行時間の８割で、10個程度の基本命令しか使われていない
・それらの基本命令でも直交性は十分利用されておらず不要である
・「便利な命令」よりも「単純な命令」を組み合わせたほうが高速に動作することが多い
これは、従来の「人間にとって使いやすいプロセッサが、良いプロセッサである」という価値観を覆すのに十分でした。
IBM は 801 というコンピューターを作成します。
これは実験プロジェクトで、上に書いた調査結果を元にしたものです。
よく使われる基本命令を高速に実行するように最適化されており、直交性も低いです。
しかし非常に高速に動作し、人間にとっての「使いやすさ」は、コンパイラを開発することで保証されます。
801 の作成中に、パソコン用の 1chip プロセッサーである、ROMP の作成が開始されます。
801 では、高速性を求めてすべての命令を同じ長さにしていたり、単純な命令の組み合わせで複雑な命令を実現したりするため、プログラム容量が大きくなることが予期されていました。
801 では、すべての命令が 32bit でした。
ROMP では、一部の命令を 16bit にして、混在命令長にすることで省メモリ化を図っています。
ROMP は 1981 年に開発が開始されたそうですが、実際に製品として発売されたのは 1986 年でした。
その後、1990 年に POWER 1 が作成されます。
大型汎用機に使用されるもので、CPU の機能を複数の LSI に分散しています。
そして、このときに、1970 年代の研究成果と共に「一部の命令を高速化すればよい CPU が作れる」というアイディアが宣伝されました。
この宣伝のために、RISC という概念が作られました。
同時に、従来の人間に使いやすいプロセッサは CISC と名付けられました。
ここには、IBM の宣伝のうまさがあります。
RISC の R は Reduce の意味。複雑化しすぎて遅くなっている CPU を「Reduce」（元に戻す、縮小する、減らす、などの意味）する、という意図があります。
それに対し、CISC の C は Complex 。「複雑な、込み入った、嫌悪する」などの意味のある単語です。
この用語の対比を見ただけで、RISC は素晴らしく、CISC はダメなものに思えてしまう。
POWER は頭文字…最初に挙げましたが、意味のある単語で、最後の R は RISC です。
でも、そんな意味よりも「POWER」＝「力」という意味を強く感じる。ここでも、POWER が素晴らしいものに見える。
ここから、1990年代の RISC CPU ブームが起きます。
でも、RISC って結局、宣伝文句のバズワードに過ぎなかったのね。
「命令が少ないから高速化できる」と言った POWER は、どんどん命令を追加して強力なものになっていく。
一方で、CISC 代表のように言われた Intel の CPU …当時は i486 とかなんだけど、Pentium の時に互換性のあるまま「RISC になった」とされる。
RISC と CISC の共通部分 ISC は「Instruction Set Computer」を意味しています。
命令によって見分けるのだから、互換性があるなら CISC のままのはず。
でも、インテルも宣伝上手で、RISC の定義を「ワイヤードロジックである」ことに置き換えてしまうのね。
ワイヤードロジックとは、すべての命令を回路で作ってある、という意味です。
それ以前は、非常に多くの命令を効率的に作るために、複雑な命令は CPU 内部で別の命令に置き換える形で実行していた。
このやり方だと、回路は使いまわせるから効率的だけど、結局インタプリタみたいになっているので遅い。
1991 年 7 月 31日、IBM 、 Motorola 、Apple の３社は、共同で「PowerPC」の作成を行うと発表します。
前年に、大型コンピューター用に作られたばかりの POWER を、PC に乗せられるサイズに小さくしようというのです。
Motorola は、CICS の代表格の一つ、68000 を作っていたメーカーです。
Macintosh の CPU としても使われていましたが、複雑すぎて、後継機で速度を上げるのが難しくなっていました。
IBM は、PC 用の CPU としては ROMP に次ぐ製品になります。
ROMP は、開発開始から製品が出るまでに 5年もかかっているのですが、多くの時間を OS 開発に費やしたそうです。
パワフルな CPU であることを活かし、他の CPU をエミュレートすることで、複数の OS をエミュレートし、どんなアプリケーションでも動く究極の OS を作ろうというものでした。
ROMP の時は途中で断念したようなのですが、PowerPC でも夢の続きを見ます。
プロジェクト名「Pink」、WorkPlace OS と呼ばれました。
UNIX 、DOS 、Windows、Macintosh OS 、などなど、どんな OS でもその上で動かすことができる…予定でした。
最終的には失敗し、AIX （IBM の UNIX） と、OS/2 （マイクロソフトと共同で作成した OS ）だけを動かす形に、規模を縮小して製品化されています。
PowerPC は 1993 年に完成し、Apple では 1994 年に Power Macintosh 6100 を発売します。
従来の 68040 を搭載した Mac のソフトも、ソフトウェアでエミュレートすることで動作しました。
…が、68040 を利用する実機よりも速度は遅い。エミュレートだから仕方がありません。
これはエミュレータ部分の設計がまだ未熟だったせいもあり、後に OS がバージョンアップされると、実機より速くなりました。
初期の PowerPC は、CPU ごとの互換性が良くありません。
最初の PowerPC 601 で搭載された命令が、後の CPU でなくなったりもしています。
その命令がなければもっと安く、もっと速くできる、というような判断で、もし該当命令が使われた際には、OS 内部でソフトウェアエミュレートします。
IBM / Motorola / Apple の３社で開発したものなので、チップ製造は IBM と Motorola が行いました。
といっても、PowerPC は PowerMac 以外にはほとんど使われません。
PowerPC を利用した PC を、多くの会社が作れるように CHRP という仕様が作られました。
IBM-PC における「互換機」をどこの会社でも作れるようなもので、CHRP が普及すれば CPU の市場が広がります。
しかし、PowerPC で動作する OS は、事実上 Apple の MacOS しかありません。
そこで、Apple も MacOS を CHRP で動作するように改良し、互換機市場を立ち上げようとするのですが…
この頃、低迷していた Apple に Jobs が復帰。
MacOS 互換機は許さない、と方針を転換し、CHRP 発売に向けて動いていたメーカーも、仕方がなく開発を中止します。
IBM / Motorola は PowerPC を作り続けるのですが、事実上顧客は Apple だけ。
当然のことですが、熾烈な値下げ競争となり、Apple だけが得をする状況になります。
CPU 製造には、製造量に関わらず、大規模な工場が必要です。
IBM も Motorola も PowerPC のために投資をしているのに、市場は広がらずに苦しい状態。
どうしても、値下げするとしても限界になります。
その結果、今度は Apple は PowerPC を捨て、Mac を Intel 系に移行するのです。
最初に書きましたが Wii / PS3 / XBOX360 の頃は、PowerPC はまだゲーム機に生き残りの道を見つけていました。
しかし、それもすでに過去の話。
元々の設計が良いので、今でも十分パワフルな CPU ですし、性能のわりに回路規模が小さいので、基板上の専有面積も小さく、無駄が少ないので省電力で発熱も少ない。
と言っても、これは PowerPC の特徴ではなく、真の RISC の特徴。
今、この特徴を活かして市場を席巻しているのは、PowerPC ではなく ARM です。
PowerPC の前途は多難なようです。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今日は、Microsoft Office の発売日 (1989)
最初のバージョンは、Macintosh用のソフトでした。
当時 Apple と Microsoft は仲が良くて、Apple II 用の BASIC も Microsoft が作っていました。
＃当初の整数 BASIC は、Woz の作。
しかし、浮動小数点への要望が大きかったこと、Microsoft BASIC は事実上の標準になっていたことなどから、Microsoft に作成を依頼した。
名称は Applesoft BASIC。
Macintosh の発売時にも、発売前から Microsoft に試作機などを提供し、ビジネスソフトを開発させています。
このときに作られたのが Word と Excel でした。
Mac には、Mac WORD 、Mac DRAW など、いくつかのソフトが同梱されていました。
これらは「GUI の使い方」を示すお手本にはなりましたが、ワープロやグラフィックソフトとしては、それほど高機能ではありません。
そこで、Microsoft も Mac 用に本格的なワープロソフトを発売します。
1984 年１月発売の、Microsoft Word for Macintosh でした。
＃Microsoft の作った UNIX 環境である、XENIX 用に発売したワープロソフトの移植。
XENIX 用は Multi-Tool Word という名前だった。
AppleII は、世界初の表計算ソフトである VisiCalc に牽引されてシェアを伸ばしました。
IBM-PC は、 VisiCalc よりも強力な表計算ソフト、Lotus 1-2-3 に牽引されてシェアを伸ばしました。
Apple は、表計算ソフトの重要性を理解していました。
そこで、Microsoft に表計算ソフトを作ってほしい、と依頼したようです。
…これは、どうも「会社として」の約束ではなく、Jobs が友人である Gates に依頼したもの。
この際に、非公開だった Mac の内部情報まで開示し、「どのように使ってもかまわない」と確約する直筆メモまで渡しています。
後に Windows と Macintosh の GUI が似ている、という訴訟になった時、このメモが原因で Apple は敗訴しています。
ともかく、Mac の GUI を上手に使った表計算ソフト Excel は、1985年9月に発売になっています。
その後、1987 年に Forethought 社から、Mac 用に、それまでになかった新しいタイプのソフトが発売されます。
「PowerPoint」というそのソフトは、コンピューターを使ってプレゼンテーションを行うという、新しいビジネススタイルの提案でした。
当時のパソコンは、本体・モニタ・キーボードが別々なのが当たり前。
移動するにしても、セットアップが面倒でした。
しかし、Mac は本体・モニタが１体型で、持ち運びのための持ち手までついています。
キーボードなしでもマウスで操作できます。
これを活かし、顧客の前で Mac の画面を見せてプレゼンテーションができる、という画期的なソフトでした。
Microsoft は、このソフトに将来性を感じ、会社ごと買収。自社のラインナップに加えます。
そして、Excel / Word / PowerPoint をセットにしてビジネス用パックを発売します。
1989 年の今日発売された、「Microsoft Office」でした。
Office は、それまで個別販売していたソフトの寄せ集めにすぎません。
しかし、これからコンピューターを使おうとする人が、まとめて必要なものを買うことができました。
実のところ、これ以前も Microsoft は類似のソフトを作ってきていましたし、この後もしばらく作り続けています。
Microsoft Works というのがそれで、ワープロ・表計算・データベースを中心として、いくつかの機能を使うことができました。
＃Handy98 に付属していたバージョンでは、このほか「グラフ作成」と「パソコン通信」の機能があった。
Works は、機能を単純に絞り込んだソフトの集合体でした。
最初から一緒に使うことを前提に設計されているので、インターフェイスもできるだけ共通化され、わかりやすいものでした。
しかし、初心者がちょっと使うには十分なのですが、本格的に使おうとし始めると、機能不足を感じるのです。
Office は、Works よりも高価でしたが、最初からフルセットの機能が使えました。
各ソフトは出自は別々でしたが…もちろん、Office が発売されるまでにインターフェイスは統合され、わかりやすく使えるのです。
今となっては当たり前に思うかもしれませんが、これは当時すごいことでした。
同じ OS の上で動く、同じ会社が作ったソフトであっても、それぞれのソフトごとに使い勝手がバラバラ、というのが当時の普通でしたから。
Microsoft は、 Windows が 3.1 以降になって普及し始めたときに、Office を OS にバンドルして販売する戦略を取ります。
バンドル版 Office は、特に人気がある Word / Excel だけに絞り込まれていました。
しかし、この２つだけ使えれば十分、という人も多く、Word / Excel を使いたいから Windows を選ぶ、という「キラーソフト」として十分な役割を果たしています。
ライバルである Lotus 社や、Justsystem も、Lotus SuperOffice や Justsystem Office などの対抗製品を投入するのですが、「OS にバンドルされる」という強力な販売経路を前に、大きく差をつけられてしまいます。
＃このやり方は、独占禁止法違反だということで後に訴訟になっています。
現在は、バンドルソフトは OS / PC 販売時に料金を示して別途購入できる、という形で解決しています。
（適正な金額が示されているので、市販品を買うのと変わらず、優位な販売方法とは言えない）
フルセットの機能を提供しつつ、ワープロ・表計算を中心としたいくつかのソフトウェアを提供…という形式は、今でも各社から提供されています。
まず、有名どころでは、旧 Sun Microsystems が作成していた Star Office。
Sun が作成した Java のキラーソフト…となる予定だった、Java 上で動くオフィスソフトです。
Java 上で動く、ということは、すべてのコンピューターで動く。（とされていた）
Sun は開発をオープンソースにすることにして、すべてのソースコードが公開されました。
これを元に、OpenOffice.org というソフトが作られます。
後に、Sun が Oracle に買収され、オープンソースの理念が引き継がれなくなる可能性が出ました。
その際に作られたのが LibreOffice 。
事実上 OpenOffice.org の主要メンバーは、すべてこちらに移行しています。
企業買収の影響でブランド名だけが変わってしまった、ということ。
Oracle は、OpenOffice.org を Apache 財団に寄贈しました。
現在こちらは Apache OpenOffice となっています。
Apache ライセンスで提供されているのですが、このライセンスは完全な「フリー」ではないため、LibreOffice と袂を分かった格好です。
もう一つ、IBM は、Lotus を買収し、Lotus SuperOffice の後継に当たる Lotus Symphony を無償で提供しています。
ただし、こちらの中身は OpenOffice をベースとしたもの。
過去の Lotus SuperOffice とは全く異なる、ブランド力だけを活かしたものです。
以上は StarOffice を源流とする無料オフィス製品です。
もう一つの有名 Office 製品の流れの代表としては、KingSoft Office があるでしょう。
MicroSoft Office 互換を目指して作られた、Windows 用の Office 製品。
ファイルもある程度互換性がありますし、操作性も似通っている。
「互換品」としては一番信頼性があるようで、人気があります。
とはいえ、あくまでも互換品で、完全に同じものではありません。
同様の「Microsoft Office 互換」ソフトは、他にもいくつかありましたが、今は大体消えてしまったようです。
さらに、全く新しい流れを作り出したものとして、Google のアプリケーション製品群があります。
ただし、Google はこれを Office とは名付けていません。
ドキュメント（ワープロ）、スプレッドシート（表計算）、スライド（プレゼンテーション）があり、それぞれ Word / Excel / PowerPoint と、ある程度のファイル互換性を持っています。完全ではないけど。
すべて Javascript で書かれていて、WEB ブラウザ上で動きます。
何よりも、オンラインで同時に多人数で編集できるとか、URL が割り振られるのでアクセスすることでデータを得られ、機械的な処理も可能とか、従来の Office にはない新たな使い方が広がります。
ここら辺、以前に Chrome Book を買ったときに詳しく書いてますね。
本家である Microsoft Office も、Google のやり方の新しさには気づいたようで、類似ソフトを作っています。
名前は Microsoft Office を連想させますが、Google の製品並みに「別物」だということを認識しておく必要はあるでしょう。
ただ、インターフェイスなどは極力似せてあるので、Microsoft Office に親しんだ人には使い易そうです。
以上、今日は Microsoft Office の最初のバージョンが発売された日だったので、Office がどれほどその後のソフト業界を変えてきたか、現在進行形の部分も含めて書いてみました。
すでに、いわゆる「Office」…Windows 上で動くマイクロソフトのデスクトップアプリ、は以前ほど優位性を持ってないように思います。
それでも、Office の中核がワープロと表計算である限り、これらのソフトは求めら続けるのでしょうし、統一的にデザインされた（同じ製造元の）製品のほうが使いやすいのだろうとは思います。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
7月31日、パパートが亡くなったそうです。享年88歳。
昨日知ったのですが、昨日は仕事が忙しくて訃報をかけませんでした。
LOGO を作った人です。
LOGO は今となっては古い言語なのですが、「計算機」に「計算させない」ための言語、というスゴイ発想の転換でした。
もちろん、コンピューターのアプリケーションで、計算を目的としていないものはあります。
しかし、それだって内部ではいろいろな計算をやっている。プログラムというのは計算で成り立っています。
でも、この「計算」こそが、プログラムを難しいものだと思わせている元凶だ、とパパートは考えました。
細かな数字なんてどうだっていい。
「プログラムする」こと自体を楽しめる言語を作れば、子供だってプログラムを楽しめるのではないか。
パパートは教育学者であると同時に、数学者でした。
そして、数学にとって当時はまだ「新しい武器」であったコンピューターにも触れていました。
この頃、BASIC のような「初心者向けのプログラム言語」が作られ始めていました。
パパートの在籍する MIT でも、子供に扱える、簡単なプログラム言語は作れないかと研究を始めます。
BASIC は、「文法が平易」で「実行しながらデバッグがしやすい」言語です。
しかし、そこで扱う概念はやはりコンピューターそのもので、計算することが中心になっていました。
これでは子供にとっては難しすぎます。
そこで、パパートはもっと概念が簡単なプログラム言語を作ろうとします。
プログラムの難しさは、計算を多用することと、できることが抽象的過ぎることの２点に集約されます。
そこで、パパートは複雑な計算をしないでも、ロボットが動かせる言語を作りました。
抽象的であることは、「ロボットに命令する」という具体性に置き換えて解決しました。
そして、常にロボットを中心として考えることで「座標系」の概念を知らないでも絵を描けるようにしたのです。
手順を示して絵…グラフを描くということは、幾何数学そのものです。
しかし、そこには座標系やベクトルなどの難しい概念は存在せず、分度器で測れる「角度」と、ものさしで測れる「距離」だけがあればいいのです。
LOGO は BASIC のようなものを目指して作られ始めましたが、できたものは全く違ったものでした。
BASIC は、プログラムの初歩を教えるものです。
文法は扱いやすく、デバッグもしやすいのですが、当時主流だった FORTRAN や COBOL と、根本的な部分では変わりません。
「なにか」を解決するためのプログラムを作るための道具です。
しかし、LOGO はプログラム言語でありながら、役に立つプログラムを作るための道具ではありませんでした。
LOGO で重要なのは、出来上がった成果物ではなく、その成果物を作る過程なのです。
子供は目的を達成するために、綿密に計画を立て、その手順をコンピューターにプログラムします。
しかし、大抵は思い違いなどで誤動作するものです。この「バグ」の原因を突き止め、自分の勘違いを修正しなくてはなりません。
人は成功からは何も学べません。
上手くいく、とわかっている知識だけを詰め込まれても、たいした役には立たないのです。
それよりも、何度も繰り返し失敗し、失敗した時にどう対処すればいいのか、どういうやり方なら失敗しにくいのか、実地で経験し続けることは、子供にとって何よりも重要な体験となります。
LOGO は、子供がそれを学ぶことができる言語なのです。
LOGO の開発話に関しては、パパートの誕生日にも記事を書いています。
興味のある方はそちらもお読みください。
LOGO は Smalltalk を生み出し、Smalltalk は Squeak, Scratch を生み出しました。
Scratch は、現在子供向けとしては一番成功しているプログラム言語です。
LOGO と同じように、具体性をもってプログラムできますし、非常に巧妙な仕組みで、初心者でも簡単にゲームやアニメを作れます。
＃一応本職のゲームプログラマの目で見ても、ゲームに関しては「子供でも使える」けど、子供だましではない本格的なものが作れます。
一方で、Smalltalk は「オブジェクト指向」という新しいプログラム技法を生み出しています。
LOGO が「ロボットに教える」という具体性でプログラムを解かりやすくしたように、任意の機能を持った「オブジェクト」（物、という意味）をプログラムして、オブジェクトの組み合わせでプログラムをしていく、という技法です。
オブジェクト指向は、C++ や Objective-C を生み、Java や Javascript にも使われてきました。
こちらは単純に LOGO の子孫とは呼びにくいものですが、パパートの考えた「わかりやすくするための具体性」は受け継いでいます。
４年後をめどに、日本でも学習指導要領が改められ、子供にも積極的にコンピューターに触れさせることになりました。
少し前から方針は明らかにされていましたが、一昨日詳細が発表されてニュースをにぎわしたところです。
日本で、パパートの目指した教育がやっと取り入れられようとしている時の残念な訃報でした。
同じテーマの日記(最近の一覧)
関連ページ
COMPET CS-10A 発表日(1964)【日記 19/03/18】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |