もう一つのライブラリ
目次
開発環境
（この項、2014.11.26 に追記し、その後29日まで連日情報が寄せられたために大きな修正が繰り返されました。）
前項で書いた「ＳＢＬからＳＧＬに乗り換えられなかった理由」として「使用機材が違った」という指摘を頂きました。
ＳＢＬは、SH2 を使うという基本に忠実に、日立製のＣコンパイラで使用できるライブラリとして作られていたが、ＳＧＬは gcc (GNU C Compiler) が使われていたというのです。
調査したところ、ＳＧＬ、ＳＢＬとも、流出していたマニュアルでは「日立SH2-Cコンパイラ」を使用し、その他の開発機材も同じように書いてありました。
僕自身の記憶では、…コンパイラが何だったか覚えていません。でも、日立製だった気がします。
…と、調査結果を書いたところ、別ページに書いた補完情報を頂いた kozo さんから「ＳＧＬは確かに GCC を使っていた」という詳細情報を頂きました。
それによれば、「ＳＢＬは日立製コンパイラとソフィアシステムズ製の機材だった。ＳＧＬはGCCと亜土電子製の機材だった」とのこと。
亜土電子！！！ …これで忘れていたことを思い出しました。
「もう一つのライブラリ」というテーマからは逸れてしまいますが、「開発環境も２種類あった」ことを書き記しておきましょう。
ＳＧＬは、AM2研がバーチャファイターを移植するために作った「MODEL1の演算部分をソフトで行うプログラム」がベースになってライブラリとしてまとめられたものです。
業務用開発部署の AM2 が作っていたので、当初は業務用のＳＴ－Ｖから使われ始め、サターン用となってまとまったのは少し後だったと思います。対外的にはサターン用が完成した時点で発表となった気がします。
僕はＳＴ－Ｖ用ソフトを作成する会社にいたため、対外的な発表の前から、開発中のＳＧＬを使用させてもらっていました。
そして、この時点では確かに、日立製の開発環境を使用していました。
日立製のコンパイラやデバッガは、ワークステーションで動作するものでした。
基本的には、SUN OS 上で動作するように作られていますが、HP（ヒューレットパッカード社）のワークステーション用もありました。
…わかる人にだけ伝わればよいのだけど、SUN OS 用なので OpenWindows のガジェットライブラリ使っています。HP の Motif 環境で動かしても、このウィンドウの中だけ OpenWindows 。非常に使いにくい。
でも、それしかないから使わざるを得ないよね～
そしてもう一つ、開発にはやはり日立製の ICE が必要でした。ICE っていうのは、CPU と同等の動作をする外付け回路。
同等の動作をするのは「あたりまえ」で、好きな時に一時停止したり、１命令づつ実行したり、CPU の内部状態を書き変えたり、自由に制御できます。
この ICE は、LAN 経由で、先に書いたワークステーション用のデバッガを使って制御するようになっていました。
ICE は CPU １つ分の動作しかしません。なので、普通はメイン CPU を ICE にして、サブ CPU は普通の CPU を使っていました。必要なら ICE を入れ替えることも出来たと思います。
（ＳＧＬの開発チームとか、ICE ２つを使っていたかもしれませんね）
そして、この ICE をソフィアシステムズの機材に接続します。
まず、ソフィアシステムズについて書いておきましょう。電子回路の開発機材などを作っている会社です。一般向けではなく、開発会社向けの開発会社。セガが依頼して、サターンの開発機材を作っていました。
サターンの開発用では、「ターゲットボックス」と呼ばれたのが、ソフィアの機材でした。
僕はＳＴ－Ｖの開発をやっていたので、ターゲットボックスは使ったことがありませんが、ＳＴ－Ｖ開発ボードもソフィア製だったのではなかったかな。
ともかく、開発には日立の開発環境と ICE 、それを動かすためのワークステーション、そしてターゲットボックスが必要でした。
これが非常に高くて…ICE が特に高く、数百万したのではなかったかな。
余談になりますが、これらの機材は高すぎるので、僕のいた会社ではレンタル品を使っていました。
僕は会社で機材管理もしていたのですが、途中で前任者から引き継いだものでした。
そして、前任者の管理がいい加減で…開発キット一式を返却する時期が来て、どこを探してもマニュアルが１冊見当たらない。マニュアルと言っても製本されたものではなく、コピーをバインダで綴じただけのもの。
どうしても見当たらないので、レンタル会社に電話して、「見当たらない場合はどうなりますか？」と聞いてみました。そしたら、完全な状態で返却できないなら損害として新品相当の金額を請求になります、とベラボーな金額を言われた気が…。
金額を正確に覚えていないのですが、血の気が引く回答だったことは覚えています。
結局、マニュアル一冊だけ欠品で期日前に返却し、「マニュアルは引き続き探す」ということで了解してもらいました。
でも、必死に探しても見当たらず。１か月後に、レンタル会社から「今回だけ特別に」返却しないで良い、と電話がかかってきました。
あの時は寛大な措置、ありがとうございました。＞オリックス・レンタリース殿
さて、そんなに開発キットが高価では、サードパーティ参入の障壁になります。
後に亜土電子工業が、もっと安価な開発キットを開発しました。
亜土電子工業は、秋葉原で当時「T-ZONE」というパソコンショップを展開していた会社。サターン発売の４年前、1990年にセガの資本提携を受けて事実上の子会社となり、1995年には当時のセガの親会社であったＣＳＫからも資本提携を受けています。
つまり、亜土電子工業が開発したと言っても、事実上はセガが公式に開発し、提供したようなものです。
開発資金が必要だったが、セガはソニーとの消耗戦に陥って金がなく、親会社が提供したのかもしれない。
この時に開発されたのが、「DEV-SATURN」と呼ばれるもの。
市販されるサターンを一部改造して、開発のための機能を追加したものです。量産品の一部改造なので、ターゲットボックスに比べると非常に安価。
ここに、ヨーロッパの会社（CROSS Product）が作った機材「CartDev」と、CartDev を使うための開発ツール「CodeScape」を組み合わせると、サターンの内部を PC から操作することが可能になりました。
ICE 相当…とまではいかなかったようですが、それに近い感覚で扱えたようです。
CradDev + CodeScape は、亜土電子が日本国内で販売するライセンスを取得し、DEV-SATURN とセットで販売したようです。なので「亜土電子製機材」と言った場合、これらすべてをセットにしたものを示すようです。
でも、PC でもデバッガが使えるように、ICE が無くてもソフト的にほぼ同等の機能を作り出すことは可能。
CodeScape は Windows 上で動作し、エディタからコンパイラ、デバッガまでを統合した環境です。いわゆるＩＤＥと呼ばれるもの。
と言っても、コンパイラとしてはＧＣＣが使われていた模様。これが、「日立製コンパイラとは別に、ＧＣＣがあった」ということの様子です。
これで、日立＋ソフィアの、ワークステーションも必要な非常に高価なシステムを全く使わず、亜土電子製のツール＋普通の PC で開発が出来るようになります。
ところで、今回調査中に、４年前にサターンの開発話を Twitter で語ったものがまとめられているのを発見。
それによれば、当初はＧＣＣは日立製よりも性能が良かったが、日立製ががんばってバージョンアップして追い越した、とのこと。
そうか、僕は日立のコンパイラでプログラムしていたけど、別に性能悪いんじゃなくてよかったよ。
さて、ここまで説明したうえで、やっと最初の話に戻りましょう。
ＳＢＬは日立コンパイラ向けだったが、ＳＧＬはＧＣＣ向けだったので移行できなかった、という話。
これは、ＳＧＬの提供時期と亜土電子の開発環境の提供時期が近かったために、そのような勘違いが起きていただけのようです。
ＳＢＬもＳＧＬも、コンパイラを問いません。日立製でもＧＣＣでも、どちらからも呼び出せるライブラリでした。
最初に書きましたが、ＳＧＬのチュートリアル冒頭には、日立＋ソフィア開発環境のセットアップ方法が書かれています。ＳＧＬ提供時には、まだ亜土電子の開発環境が存在していなかったようです。
なので、提供時期が「近かった」だけで、同時ではなかったのでしょう。コンパイラが２種類あったことが、２種類のライブラリを移行するための障壁になった、ということは無かったようです。
僕のいた会社では、日立の環境でＳＧＬを使っていましたし。
ですから、開発環境としては日立製以外に使えません。
（ＳＴ－Ｖ開発ボードはソフィア製だったのではないかな、と思いますが記憶が定かではありません）
とはいえ、先に書いたように提供時期が近いための勘違いが起きていた可能性はあります。
その意味では、近い時期にライブラリと開発機材を立て続けに提供したのは、サードパーディを無用に混乱させていたのかもしれません。
恐らくは、これが「機材が違うからＳＧＬに移行できなかった」という、最初の情報提供に繋がったのでしょう。
…と、ここまで書いて公開したら、数分後に「ＳＢＬとＳＧＬは共存できたので、移行するのではなくて両方使うことも出来ました」という情報が。
実際に、セガから発売されていたリンクルリバーストーリー
これまたすごい情報。どちらかを使うしかないのだと思ってました。
共存と言っても同時にメモリ上に存在するわけではなく、シーンによって完全入れ替え。そのため、特にメモリを無駄遣いするようなこともありません。
ゲームに必要な変数の領域は、ちゃんと「書き変わらない場所」に確保してあり、「ＯＳ」と呼ばれていたライブラリを完全に入れ替えても、ちゃんとゲームは続行できています。
先にＳＢＬとＳＧＬの性格の違いを書きましたが、適材適所で使い分けていた、という例ですね。得意な部分を上手に活かし、開発の手間を軽減しているのでしょう。
その一方で、この作り方は「ライブラリの習得コスト」という意味では、全く違う２つのライブラリを使い分ける必要があるので大変そう。
この情報を教えてくれた方が、一人でＳＢＬとＳＧＬの両方を使って作っていたそうですが、ある程度の技量が無いと、なかなか両方を使い分けて…とはできなかったかと思います。
もちろん、ＳＢＬとＳＧＬで開発環境は同じだった、という情報もいただきました。やはり、開発環境が違うから移行できない、ということは無かったようです。
情報提供ありがとうございました。