パソコンにおける80系 VS 68系の時代

パソコン 歴史

f:id:juangotoh:20170705181958j:plain

　1974年に、Intelの8080とモトローラの6800という8ビットCPUが登場した。8080が、電卓用4ビットCPU 、4004から8008を経て進化したのに対し、6800はミニコンのアーキテクチャ(DEC PDP-11をモデルにしたといわれている)を縮小して設計されたらしい。つまり8080は電卓が進化したCPU。6800はミニコンが退化したCPUといえる。Intel 8080とその後継アーキテクチャを80系、モトローラ6800とその後継アーキテクチャを68系と呼び、これらが戦いを繰り広げた時代があった。

　特徴として、8080はレジスタが多めで、数値をいくつも代入してちゃっちゃと計算するのに向いていた。それに対し6800は直行性の高い命令で、一貫性の高いプログラムを作成するのに向いていた。誤解を恐れずいうなら、8080はとにかく実用性重視。6800は理念重視といえるのではないだろうか。高度な電卓VS簡易化されたコンピューターだったのだ。この場合、すでにミニコンや大型コンピューターを使っていた技術者からは、よく似たアーキテクチャの6800は評判が高かったはずだが、インテルはいちはやく評価ボードやCPUを安価に配布し、初期の段階でわりとシェアを取ってしまう。マイコンの歴史に残るAltair8800など、当時インテルが市販していたCPU単体の価格と変わらない値段で筐体とマザーボード込みのコンピューターセットを販売できた。これはIntelがこういう企業に対し、極めて格安でCPUを卸していたからに他ならない。

　ここで、80 VS 68の第一ラウンドは80の勝利に終わるのだが、ここで成功したのはIntelではなかった。IntelからスピンアウトしたZilogが、Z80という、8080互換で、さらに便利な命令や裏レジスタを完備たCPUを発売。横から商売をかっさらっていく。
　日本では、日立Basic Masterが6800を採用。シャープ MZ-80と、NEC PC-8001がZ80を採用していた。その後、モトローラは6800を大幅に改良した6809を発売する。6809は究極の8ビットCPUと呼ばれ、日立のほか、富士通が採用して一定の支持を得る。しかしこれは6800との互換性がなかったし、登場時期も遅すぎた。「究極の8ビット」というのは、要するに「8ビット時代の最後を飾る」という意味になってしまう。

　なお、日本でパソコンへの採用例はほぼないのだが、米国では6502がかなりのシェアを得た。これはモトローラからスピンアウトしたモステクノロジーが開発したCPUで、6800をさらに簡易化したような製品だ。プログラムカウンタ以外のレジスタがすべて8ビットであり、命令数も少ないが、その分高速で動作した。つまりプログラムはより複雑になる。のちのRISCにちょっと似ている。モステクノロジーはこのCPUをすげえ安く市販した。8080が3万円位した時代に2000円位で売り出したらしい。これに注目したのがスティーブ・ウォズニアックで、彼が作ったのがApple I。後継のApple IIも6502を使っていたので、アメリカを席巻したパソコンが6502を採用したということになる。コモドール社もPET-2001でこの6502を採用し、のちのコモドール64でも使われた。英国でもエイコーン社がBBC Microに6502を採用。世界的に安価なパソコンは6502という流れがあった。なぜか日本ではパソコンにおける採用例がない。これは日本で初期にパソコンを製造したのが半導体メーカーばかりで、これらがモトローラやインテル、ザイログと提携して自社で互換チップを製造していたこともあるのだろう。初期の日本のパソコンは基本自社製のCPUを搭載していたはず。製造ライセンスを買った後の製造原価で考えるならどれも大差なく、ならば高機能なZ80や6809となったのではないか。
　それに対して米国などでパソコン市場を立ち上げたのは、自社に半導体工場なんか持たない新興企業だった。大量に外部から購入する部品として、安価な6502は魅力的だったと思われる。
　6502を68系に含めるのなら、案外日本以外ではいい勝負をしていたかもしれない。日本においては、ファミコンが6502に機能を追加したカスタムCPUを採用し、その後PCエンジンやスーパーファミコン（16ビット化された65816のカスタム）などに採用された。セガのSC-1000などがZ80を採用していたのに勝ったので、ゲーム機市場では80系の負けといえたかも。


　16ビットでは、Intelが8086、モトローラが68000を出した。8086はこれまた8080を大きく拡張したアーキテクチャで、機械語に互換性はなかったものの、再アセンブルすれば今までのプログラムがそのまま動くようにできていた。そういう設計のため、16ビットCPUとしてはメモリが64kB単位で区切られたり、非常にせせこましくなっていた。それに対して68000は、リニアな16MBメモリマップを実現し、たくさん装備された汎用レジスタは32ビットで自由自在に使えるなど、どう考えても68000の勝ちだろってな仕上がりだった。しかし、6800や6809との互換性とかは特に考えられていなかった。この時代、IBM-PCが8086の8ビットバス版の8088を採用し、AppleのLisa、Macintosh。アタリのST。コモドールのAmigaが68000を採用した。後者はどれもビットマップディスプレイを効率的に扱う必要上、68000の方が率直にOSやアプリケーションを書くことができる利点があった。しかし、IBM-PCやその互換機が主流となり、ここでも68系は敗退する。
なお、8ビットパソコン市場でIntelのパイを奪ったザイログは、16ビットのZ8000が思ったより速くならず、エラーも出たりして16ビットパソコン市場ではさっぱり採用例がなかった。アーケードゲームとかでいくつか採用されたようだけど。

アタリやコモドールがドロップアウトして、唯一の68系陣営となったアップルは、IBMのPowerPCを採用し、これにモトローラを巻き込む。PowerPCの時代を68系と言っていいのかどうか、全然アーキテクチャ違うし難しいところだけど、最終的にモトローラのCPU採用をやめたIntel Mac登場の2006年を持って、1974年から続いたパソコン市場の80系 VS 68系の戦いは幕を閉じたと考えていいのだろう。

Win2Dを使って２Dゲームを作る場合のメモ的な何か

アニメ・ゲーム プログラミング

　別にゲーム作る予定があるわけではないのだけど、ちょっと興味を持ったので調べてみた。Win2Dには、SpriteBatchという、昔のゲーム機やホビーパソコンで使われた「スプライト」に似た機能がある。まあこれ自体はDirect3DやDirect2Dに以前からあって、XNAなどでも便利に使われてたものだけど、UWPアプリ用のDirect2DライブラリであるWin2Dの発表時には含まれておらず、あとからサポートされた。なので、SpriteBatch関連のAPIは、Windows10 November update以降でしか使えないとなっている。

　Win2Dが描画を行うコントロールは、主にCanvasControlと、CanvasAnimatedControlだ。後者は前者にアニメーションのための機能を付けえくわえたものと考えていい。具体的には、一定間隔（デフォルトでは1/60秒間隔)で画面の更新が強制的に行われるようになっており、そのためのイベントハンドラが使える。ここにキャラクターの移動などの処理を描けば、無理なくアクションやシューティングゲームのためのゲームループが作成できるわけだ。というわけで、とりあえずXAMLに

xmlns:canvas="using:Microsoft.Graphics.Canvas.UI.Xaml"

と書いてから、Gridの下に

<canvas:CanvasAnimatedControl x:Name ="canvas" Margin="10" Update="canvas_Update" Draw="CanvasControl_Draw" CreateResources="OnCreateResources"  ClearColor="Black"/>

などのように書いて、CanvasAnimatedControlを作成する。CreateResourcesはリソース作成時に呼ばれるので、スプライト用の画像データを読み込むなどするために登録したほうがいい。Updateは1/60秒ごとに呼び出されるアップデートイベントで、これが呼ばれた直後にDrawメソッドも呼び出されるので、Invaridate()とか呼んで無理やり描画イベントを起こす必要もない。

　CanvasのDrawメソッドが呼び出されるとき、引数に

Microsoft.Graphics.Canvas.UI.Xaml.CanvasAnimatedDrawEventArgs args

が入るので、

CanvasSpriteBatch  batch = args.DrawingSession.CreateSpriteBatch();

としてSpriteBatchを作成する。これがなにかというと、Canvasに乗ったレイヤーのようなものだ。スプライトと言っても、ビットマップのキャラクターを登録したら、あとは座標を指定するだけで動き回ってくれるようなものではなく、毎回更新のたびに全スプライトをこのSpriteBatchの上に書き込む必要がある。CanvasSpriteBatchクラスのDrawメソッドを使うのだが、これはあらかじめ用意したキャラクター単一のビットマップ、もしくは歩きパターンなどを複数並べた大きなビットマップ（SpriteSheet)の任意の矩形領域からSpriteBatchに転送することになる。単一ビットマップを使う場合は、CanvasBitmap.Draw()メソッド、SpriteSheetを使う場合はCanvasBitmap.DrawFromSpriteSheet()メソッドを使う。どちらも用途に応じて多くのオーバーロード関数が用意されている。「Draw」となってるから、この時点で画面に表示されそうな気がするが、これはあくまでオフスクリーンで画面を作っている段階で、実際のCanvasへの描画は

batch.Dispose();

で行われる。「え？」と思うでしょ。実際ドキュメントには
Finalizes the sprite batch and submits it to the CanvasDrawingSession.
と書いてあるのでこの理解で正しいはず。まあ、シューティングゲームとかで考えても、敵が数十機出たり、弾幕とで数百個のビットマップをSpriteBatchに書き込むことになる場合もあるのだろうけど、おそらくそのへんうまいことやってくれてあんまし遅くならないんじゃないかな。なんせDirectX系だし（甘いか？）

　それにしてもWin2D、日本語での解説がなかなか見つからないうえに、本家のドキュメントもあまりにシンプルでいろいろ試してみないとわからない。引数の説明がほぼなかったり、まあDirect2Dのドキュメントの該当部分読めってことなんだろうけど…


　とりあえず黒背景で自機を動かしてショットを打つところまでは作ってみた。SEやBGMはネットで拾ってきたフリー素材。

　なお、自機の画像は背景透過のアルファ付きPNGで用意した。2コマしかないが、一応これがSpriteSheetということになる。
f:id:juangotoh:20170619065431p:plain

Win2DでUWPアプリに日本語縦書き

パソコン プログラミング

MicrosoftがGititHubで公開しているWin2Dというライブラリ、Direct2DをUWPのCanvasで簡単に使えるようにしたものらしい。ちょっと試してみた。

' 空白ページのアイテム テンプレートについては、http://go.microsoft.com/fwlink/?LinkId=402352&clcid=0x409 を参照してください
Imports Windows.UI
Imports Microsoft.Graphics.Canvas.UI.Xaml
Imports Microsoft.Graphics.Canvas.Text


''' <summary>
''' それ自体で使用できる空白ページまたはフレーム内に移動できる空白ページ。
''' </summary>
Public NotInheritable Class MainPage
    Inherits Page
    Sub CanvasControl_Draw(sender As CanvasControl, args As CanvasDrawEventArgs)
        Dim textFormat = New CanvasTextFormat()
        Dim s As String = "こんにちは、" + vbCrLf + "私は後藤寿庵です。" + vbCrLf + "This is a pen."
        textFormat.FontSize = 24
        textFormat.Direction = CanvasTextDirection.TopToBottomThenRightToLeft   '縦書きを指定
        textFormat.VerticalGlyphOrientation = CanvasVerticalGlyphOrientation.Stacked　'英字グリフを正立に
        args.DrawingSession.DrawText(s, 100, 100, Colors.Black, textFormat)
        textFormat.VerticalGlyphOrientation = CanvasVerticalGlyphOrientation.Default　'英字グリフをデフォルトに
        args.DrawingSession.DrawText(s, 250, 100, Colors.Black, textFormat)
        textFormat.Direction = CanvasTextDirection.LeftToRightThenTopToBottom   '横書きを指定
        args.DrawingSession.DrawText(s, 270, 100, Colors.Black, textFormat)
    End Sub
End Class

なぜVBなのかといえば、慣れてるから。まあこの程度のコードならそのままC#に置き換えるのも難しくないだろう。
短いので説明の必要もないと思うが、何をやってるかといえば、CanvasTextFormatという、テキストの属性とかを定義するオブジェクトを作り、そこに行方向（CanvasTextDirection)とか、縦書き時のグリフの向き（CanvasVerticalGlyphOrientation これは漢字などのグリフではどちらでも変わらず、英数字の表示に影響する）を設定し、適当な座標にDrawingSession.DrawText()で描画しているだけ。フォントファミリーやサイズ、ウェイトなんかもCanvasTextFormatのプロパティとして簡単に設定できる。
結果：
f:id:juangotoh:20170613190819p:plain
確かに簡単だ。まあ、縦中横とかルビとかを実現しようと思ったらこれじゃ駄目なので、DrawText()じゃなくてDrawTextLayout()を使い、InlineObjectを定義するとかなんとかする必要は出てくると思うけど。

Direct2Dについての記事なのに、地味なテキストを表示するだけって…

アニメ「正解するカド」の、CGと手描きと歴史

アニメ・ゲーム

f:id:juangotoh:20170608185050p:plain

　「正解するカド」では、主要キャラクターは3DCGだが、登場頻度の低いキャラは手描き作画である。これ、頑張ってコスト計算してるんだろうなあ。人物の3Dモデルを制作するのはそれなりに手間と時間がかかるが、できてしまえばモデルの配置とモーション付けは手描きより早くできてコストを抑えられるだろう。これは同じモデルを使用する時間が長いほど安くなるはずだ。それに対し手描きの場合登場するたびにすべての動きを描かなければいけないので、コストがかかる。だたし、モデリングにかかる費用と時間を考えると、登場頻度の低い人物に関しては手描きのほうが安上がりになるだろう。

 

　1990年代末あたりから、アニメにCGが使用され始めたが、当初は宇宙船のような、ディティールが多く、基本的に変形せず、方向転換や移動というシンプルで描くのは大変だけどCGなら如実に楽で効果的になる部分に限られていた。人間のモーション付けみたいな作業がそれなりにこなれてきたあとも、しばらくは手描きでは大変な、巨大ロボットなどを中心に使われていた。2007年の「デュエル・マスターズ　ゼロ」などで、人物もCGになったが、トゥーンレンダリングがまだ不気味で、顎を上げたシーンなどで違和感が強かった。このへんは幼児向けのシンプルなキャラクターであることもCG化に向いていたのだろう。

　2000年代には、劇場作品などでフルCG作品がいくつも登場するが、この頃はおそらくTVに比べて予算をかけられる劇場映画だからこそフルCGができたのだろう。まだCGはカネがかかったわけだ。

 

　2010年代に入ると、TVでフルCG作品がそれなりに多くなってくる。「シドニアの騎士」あたりになると、CGキャラの不気味さもだいぶ緩和されてくる。ポリゴン・ピクチュアズや、サンジゲンといった、2Dアニメの中のCGパートを制作していた会社が作品元請けとなって制作されるので、その過程でためたノウハウが活かされているのだろう。

 

　「正解するカド」は東映アニメーション初のフルCGによるTVシリーズと言われている。最初に書いたように一部のキャラクターは手描きなので、完全なフルCGではないが、ほとんどCGではある。手描きアニメの老舗である東映アニメーションが、ここでCGアニメに本格的に取り組み始めたわけで、将来日本製アニメの中心がCGになる分岐点となるのかもしれない。東映アニメーションよ、どうか正解されたし。

19世紀物理学のエーテルとは

アニメ・ゲーム 雑談 科学

　19世紀、ニュートン力学が物体の運動を過不足なく記述し、電磁気学をマクスウェル方程式が過不足なく記述していた。物理学は「もうすぐ完成する学問」と思われていたのだ。この時代、光が波動であるというのは常識で、波動であるなら波を伝える媒質が存在するはずであると思われていた。水面に石を落とせば円形に波が広がるし、音は空気中を伝わる波動である。光もそれを伝える物質があるだろうと、当然思われ、それはエーテルと呼ばれていた。

 

　一般的に、波動を伝える媒質の性質は、波の周波数や伝搬速度が大きいなら、高密度で固体に近い性質を持たなければいけない。当時すでに光の速度の検証は行われており、秒速30万kmという、すごい速さで空間を伝わることがあきらかだった。そうすると、光を伝えるエーテルは鋼鉄より硬い物質でなければいけなかった。また、光が宇宙、空気中、水中、ガラスも関係なく伝わることから、あらゆる物質の中に「染み込む」非常に細かくどこにでもある物質でなければいけなかった。考えてほしい。宇宙のどこにも染み込んで存在し、鉄より硬い物質である。そんなものがあったら、惑星の公転運動もなにんもかも阻害されて停止してしまうだろう。なので、エーテルは光速に近い速度でだけ非常に硬くなるが、ゆっくり動く物質にとっては真空と同じくらい抵抗がないと定義される。かなり無理のある設定である。だが、当時は当然それが存在すると思われていたのだ。

 

　エーテルは宇宙に静止状態で存在し、その中を恒星や惑星が移動すると考えられた。したがって、エーテルに向かっていくときと、エーテルから遠ざかるときで、光の速度が変わるはずと思われた、地球が公転していることは知られていたので、その進む方向と、それと90度ずれた方向で光の速度を測れば、エーテルに対する地球の速度が測定できる。これをやったのがマイケルソンとモーリーで、結果はどの方向にも光速度は一定だった。方向にかかわらず光速度が一定というのは、異様な話である。新幹線が時速300kmで走ってるとき、駅で立ってる人が測っても、線路に並走してスポーツカーで時速200kmで走ってる人が測ってもどっちも時速300kmだというようなものだ。これをなんとかしようと頑張ったのがローレンツで、彼は高速移動すると距離が縮むとしたのだが、最終的にはアインシュタインが「いや、時間が縮むんだよ」と反則技を繰り出した。光の波を伝える媒質は、エーテルではなく「電磁場」という新しい概念になり、光を伝搬する媒質で、鋼鉄より硬いエーテルというものが不要になったのだ。　　

 

　アインシュタインの特殊相対性理論によって、エーテルは追放されたのだが、20世紀初頭のSFではまだ生きていた。あらゆる物質に染み込んで光を伝えるエーテル。ならば、エーテルに染み込むさらに細かく高硬度の物質があればどうなるか。超光速の情報や超光速移動をつかさどる「サブエーテル」である。物理学会で「サブエーテル」という概念が話題に上ったことはないと思う。これはSFがSFならではのセンスオブワンダーを生み出した運動であった。サブエーテルを含めたエーテル宇宙論は、レンズマンなど、20世紀前半のSFで使われ、スペースオペラの衰退とともに忘れられていったが、1980年代末、スタジオガイナックスの「トップをねらえ」で復権する。あれはエーテル風に宇宙船が流される様を描いた超エーテル宇宙論の世界である。

Minecraftのゾンビ肉を「ゾンビーフ」と呼ぶ由来

アニメ・ゲーム パソコン 雑談

　

f:id:juangotoh:20170603041346p:plain

　Minecraftの敵性MOBであるゾンビを倒したときにドロップする「腐った肉」(Rotten Flesh)。高確率で食中毒を起こすが、空腹ゲージの減りが速くなるというだけで、ライフ回復には使えるので、実は食料供給が難しい砂漠やメサバイオームにおいては意外と有効な食料である。この腐った肉をニコニコ動画のマイクラ実況などでは「ゾンビーフ」と呼ぶことが結構多い。しかし考えてみるとこれはちょっとおかしな話だ。ゾンビを倒して得られる「腐った肉」はどう考えてもゾンビの肉であってビーフ（牛肉）ではない。ゾンビ牛の肉なら「ゾンビーフ」でも良いと思うが、あれは人間のゾンビであり、言ってしまうと「腐った人肉」である。ちなみにMinecraftには牛が存在しており、これを倒して入手できる肉は「生の牛肉」(Raw Beef)である。マイクラには、ゾンビの牛は登場しない。

 

　これについて、

www26.atwiki.jp

Minecraft Japan Wikiでは、「ビーフは牛肉を表すので正確には間違いだが、語呂がいいので使われる」と解説しているが、僕は単に語呂がいいというだけではなく、元ネタがあったと思っている。それは、ニコニコ動画にアップロードされていた「妹が作った痛いRPG」シリーズの「えろえろ監禁病棟」だ。

　この動画では、死体を火葬するのは無駄だとして、ネクロマンサーを使ってゾンビ化し、食肉加工する会社が登場する。この食肉がゾンビーフと呼ばれるのだ。「人間のゾンビを食肉加工し、ゾンビーフと呼称する」定義がここで産まれる。

2010年にアップロードされたこの動画以前に、マイクラのゾンビ肉を「ゾンビーフ」と呼称した例があるのかちょっと確認できていないのだけど、この強引さは、「妹が作った痛いRPG」シリーズならではでないかなあと思う。

 

　「妹が作った痛いRPG」シリーズの作者は「高橋邦子」とクレジットされているが、これが本名かどうかはわからない。というか、どう考えても「妹のせいにしてトンデモないギャグ動画を制作したオタクの作品」だと思われるのだが、非常に面白く、一時期ニコニコでかなりのPVをかせいでいた。マイクラ動画で「ゾンビーフ」の呼称がこの影響で成立したと考えてもおかしくはない。

インスタントラーメンの油

歴史 食品 雑談

　日テレの「得する人損する人」という番組を見ていたら、インスタントラーメンをいかに美味しく、インスタントじゃないように作るかの勝負をやってて、「そんなに手間や追加食材、調味料増やしたらインスタントラーメン使う意味がねえんじゃねえか？」と思ったのだけど、それはさておき、麺の茹で汁を一旦切れば、麺の油が抜けてヘルシーになるというテクニックを使っていた。確かにカロリーを抑えるという意味ではそうなんだろうけど、ラーメンってもともと油の浮いた食いもんで、油も「ラーメン」の大切な要素じゃねえのかと思ったりした。

 

　インスタントラーメンは麺を油であげるのが基本である。油であげることで、高温で蒸発した水分が麺に微細な穴を開け、これが短時間でお湯が染み込み、３分で茹で上がるという特徴を生み出す。茹でたラーメンに粉末スープを加えればそれだけでいちおう「ラーメン」と呼べるものが出来上がる。つまり麺に染み込んだ揚げ油がスープに戻って「ラーメンの油」の代用をしていたのがインスタントラーメンである。

　さて、１９７０年代から１９８０年代にかけて、インスタントラーメンは「ノンフライ」という、揚げない麺を使用するものが流行し、いまも高級品はこの方法の延長で作られている。麺を油で揚げず、熱風などで乾燥させると、微細な穴があかないので茹で時間は長くなる。なのでノンフライ麺は４分とかかかるものも多い。まあこのへんは製造上の工夫で調整も効くようで、ノンフライだからといって必ずしも長くかかるとも限らないが、ノンフライのラーメンの場合、粉末スープに加え、「調味油」という油が付属するものが多い。つまり麺から油が出ないから油を別添しないといけなくなったのだ。油は簡単に粉末にできないので、粉末スープに混ぜて、一つの袋にすることができない。

 

　ノンフライ麺が普及する前に日清の「出前一丁」が「ごまラー油」をつけているが、これは文字通り追加の風味付けで、なくても普通にインスタントラーメンの味にはなる。

 

　なお、四角いインスタントラーメンと別の文化として、１９６０年前後という早い時期から九州では棒状ラーメンが各社から発売され、これらは一般にノンフライのようである。東日本からあんまし出たことのない僕はこれらが昔どうだったのかよく知らないのだが、少なくとも初期のデザインを引き継いでいると思われるマルタイ醤油ラーメンは、やはり粉末スープの他に油を別添している。