VL-BusとPnP ISA PCの仕様をMicrosoftとIntelが決める時代、始まる

0

2021年04月13日 13:52  ITmedia NEWS

  • チェックする
  • つぶやく
  • 日記を書く

ITmedia NEWS

写真写真3:ATIのMach64 VLBの場合、ISA Busもしっかり利用している感じの配線になっている。出典はWikipedia。赤枠は筆者追加
写真3:ATIのMach64 VLBの場合、ISA Busもしっかり利用している感じの配線になっている。出典はWikipedia。赤枠は筆者追加

 IBM PC、PC/AT互換機からDOS/Vマシン、さらにはArmベースのWindows PC、M1 Mac、そしてラズパイまでがPCと呼ばれている昨今。その源流からたどっていく大原雄介さんによる解説の第6回。前回はVL-Bus登場前夜 GUIの要求と高精細ビデオカードの台頭まで。



【その他の画像】



 「ビデオカードの帯域不足」の根本的に解決するには、もうI/Oの帯域を増やすしかない。とはいいつつ、EISAは高価でその割に帯域は低い(ピークで33MB/sec)し、MCAは政治的および価格的な問題で採用できない。だからといって一から新しいI/O Busを策定していたら時間が掛かる。そこで誰が思い付いたのかは知らないが、「80486のCPUバスにビデオカード直結すればいいんじゃね?」というアイデアが登場した。



 賢かったと思うのは、このアイデアを思い付いた当人たちだけで具現化するのではなく、VESAに持ち込んだことだろう。



 VESA(Video Electronics Standards Association)は名前の通り、ビデオ映像絡みの規格の標準化を行っている業界団体であって、発足は1989年。



 ビデオカードのレジスター設定とかリフレッシュレートと表示タイミング、ビデオBIOSなどが主な作業範囲であって、I/Oバスの規格なんていうのは本来VESAのカバー範囲外である。恐らくは他に適当な団体もなく、「ビデオカード用のI/OバスなんだからVESAがやったっていいじゃないか」的なゴリ押しにVESAが負けた、という辺りが真相だと思う。



 とにかくその80486のバスをI/Oバスとして利用するための規格策定を行う羽目になった。当時VESAにはSuperVGA、Monitor、Multimedia、XGAという4つのCommittee(委員会)が存在しており、それぞれのCommitteeが拡張規格の標準化などを行っていたのだが、1991年12月に5つ目のLocal Bus Committeeが発足。ここがビデオカード用Local Busの仕様策定に携わることになる。最終的に1992年8月、VESA Local Bus Standard 1.0がリリースされることになった。



 余談ながら当時のことだからそもそもインターネットもないので、Specificationは紙で入手することになるが、これがなかなか大変である。そうこうしているうちに、オープンインターフェースという会社(AX協議会の事務局が会社化したもの。2011年に破産)がVESAの仕様をまとめて翻訳して1993年に出版しており、これを入手して仕様を確認していたのは筆者だけではないと思う。



 さてそのVL-Busの仕組みは図1のような構造である。



 要するにビデオカードやその他高速I/Oが必要なデバイス向けに、80486のバスの信号をそのまま引き渡す格好だ。破線でVL-Bus Buffer / Bridgeが入っているのは、80486SX/DXに関しては別にBufferもBridgeも必要ないのだが、80386DX(32bit Address/Dataだが、一部80486と信号互換性がないのでBridgeが必要)や80386SX(32bit Address / 16bit DataなのでBufferの機能も必要)、Pentium(32bit Address / 64bit DataなのでBufferの機能が必要)などを考慮したためである。



 さて、このVL-Busの登場は大きな変革となった。その理由は要するにビデオカードが大幅に性能が上がったからだ。前回でもちょっと触れたが、XGA(1024×768ピクセル)やSXGA(1280×1024ピクセル)で256色表示だと60Hzインタレースでフルに画面を書き換えるのに22.5MB/secとか37.5MB/secとかの帯域が必要になる。



 おまけにこのころになるとHi-Color(15ないし16bitカラー:32K色あるいは64K色表示)をサポートしたビデオカードも出てきたから、この場合必要になる帯域はざっくり倍である。もちろん常に全画面を書き換えるとは限らないから、普段のオペレーションではそれほど不満は出ないかもしれないが、ウィンドウをつかんでドラッグするなどの操作になると途端に遅くなるといった、割とストレスの掛かる操作感だった。



 ところがVL-Busにすると33MHz動作でも理論上132MB/secの帯域が確保できる。実際は半分程度だとしても66MB/secで、こうしたビデオカードをフルに使うようなケースでも帯域不足に陥りにくくなる。



 この結果として、これまでDOSベースでは画面が小さい(VGAサイズ)こともあって非現実的だったGUIベースの環境(Windows 3.1とか)が、比較的大画面(XGA以上)でもストレスなく使えるようになり、実際現実的な操作が可能になった。



 筆者の場合で言えば、それまで原稿執筆やNIFTY-Serveの巡回といった作業は、当初がPC-386M(エプソンのPC-9801互換機)のMS-DOS上、次いでMacintosh SE30+Vimage 8 SE/30(外付けディスプレイ用ビデオカード)の構成だったのを、1993年にWindows for Workgroup 3.11+Win/Vという構成のDOS/V機に環境を移している。Windowsだけでなく、(ユーザーは少なかったが)GUIをフルに利用したOS/2 2.xもちょうどこの辺りから登場。やはりストレスなく利用できていたが、こうしたソフトウェアがちゃんと動くようになったのはVL-Busが普及したことに起因する。



 個人的に言えば、このあたりでPCはMacintoshを完全にキャッチアップし、以後性能で言えばずっとMacintoshを上回る時期が始まった(Intel Macが登場する2006年までこれが続いた)と考えている。もちろん操作感とかOSの作りこみ(特にDTP用途向けの色の管理など)などMacintoshが優位に立っている部分も少なくはないが、ハードウェアだけで見ればPowerPCベースのMacintoshは、CPUとグラフィックス性能の両面で、PCの後塵を拝する結果になっていたと思う。



 もっともVL-Busに問題がない訳ではないというか、いろいろと問題はありまくりだった。



 そもそも規格はかなり緩めなもので、例えば信号速度はCPUと連動するので、最大66MHzまでサポートする。ただしコネクター(つまり拡張スロット)を経由する場合の信号速度は最大40MHzで、その場合スロットは1つ。33MHz以下の場合スロットは2つまで許容するという仕様になっている。ところが実際にはスロット2本で50MHz駆動可能とかスロット3本搭載とか、明らかに仕様的にアウトな製品が大量に市場に出回った。



 こうした製品の極北が、Diamond Computer Systems(のちのDiamond Multimedia)がリリースしたFastBus VLBという1992年に発表したマザーボードであるが、相性が出まくりで「動くと速いが動かない」という非常にトリッキーな製品であった。まぁFastBus VLBだけが問題な訳ではなく、緩い仕様になっていたこともあり、マザーボードメーカー、ビデオカードメーカーのどちらも仕様の限界に挑戦しているといった風情もなくはなかった。まぁ性能が一番のアピールポイントだと、どうしてもそうした状況にならざるを得ない。



 ちなみにこのVL-Busは図1でも分かるように32bit分のアドレスとデータが両方渡される格好ながら、物理的にはVL-Busの拡張コネクターがISA/EISAコネクターと一直線に並んでいる格好なので、VL-BusとISA Busを両方使うことも可能だが、ISA Busを使わない構成もできた。



 こうした流れとは別に、「もうちょっとISAを何とかできないか」という議論が、ちょうどこの時期にIntelとMicrosoftの間で始まっていた。



 直接的なニーズは、Microsoftの方から出たようだ。Windows 3.xは半ばMS-DOSの延長にあったが、Microsoftはこれに続きChicagoと呼ばれるコード名でWindows 95の開発を行っていた。ここで問題になるのが、「デバイスの設定がソフトウェアから見えない」ことだ。



 例えば有名なところでCreative Labsの「Sound Blaster」。これを利用するためにはIRQ:5、I/O Port:0x220、8bit DMA:1、16bit DMA:5を使うのがデフォルトになっている。ただデフォルトなだけで変更は可能なのだが、それはボード上のジャンパーピンの設定で行うことになっている。逆にいうと、ジャンパーピンでどの設定になっているのか、はソフトウェアから判断できない。だからといって、「じゃあSound BlasterはIRQ:5、I/O:0x220の固定で」という訳にもいかない。他のカードと干渉する場合がある(実際しばしばぶつかる)からだ。まぁ当時のゲームソフトの中には、これを決め打ちしていて、そのため他の設定にすると音が鳴らないとかハングするといったケースもあったりしたが。



 またもっと根本的な問題として、「どんな拡張カードが装着されているか分からない」という問題もあった。当時MS-DOSの場合、デバイスドライバはユーザーがconfig.sysという設定ファイル内を書き換えて明示的にロードさせる(か、autoexec.batという初期実行スクリプトの中でメモリ常駐型ドライバを登録する)方式だったのでこれでも許されたのだが、MicrosoftはChicagoではドライバの自動ロードを計画しており、そのためには「システムにどんな拡張カードが装着され、どんな設定になっているか」を知るための手段が必要であった。



 実はこの機能を最初に広く実装したのはIBMのMicrochannelであり、これに対抗してEISAはEISA Utilityとして同等の機能を実装しようとして◆ https://www.itmedia.co.jp/news/articles/2102/22/news094_3.html◇失敗した◆わけだが、ISAでもそうした機能が必要になると考えた。



 かくして、MicrosoftはIntelと共同でPlug & Play(挿すだけで動作する) ISAの規格の策定を開始する。正式名称は“Plug and Play ISA Specification”、一般にはPnP ISAと呼ばれたこの規格、1993年1月には仕様のドラフトが完成、1993年5月にRelease 1.0がリリースされるが誤植やミスが多く、最終的に1994年5月に修正版のVersion 1.0aがリリースされた。これは要するにマザーボードのBIOSおよび拡張カードに、



・拡張カードには、自分がどこのメーカーのどんなカードかを識別するためのIDを割り振る(EISAのVendor ID、それと各メーカーが独自に割り振れるSerial/Unique Numberという2つの値を持つ)



・システム初期化時に各拡張カードは自分のIDを申告、必要なリソース(IRQ、I/O、DMA、Memory)を申告し、BIOSがそれを割り振ってくれるのを受けて、そこを使うように設定する



・BIOSは初期化時に拡張カードのスキャンを行い、必要なリソースを重複しないように割り振る



という機能を追加する仕組みだ。これがうまくいけば、BIOSは装着されている拡張カードとその設定のリストを保持するので、あとはソフトがその設定を見ながらデバイスドライバをロードすればいいことになる。



 そして案の定、この仕組みは上手くいかなかった。主要メーカー、それこそCreative LabsやAdaptecなどがその代表例だが、こうしたメーカーはPnP ISA対応の製品をリリースした。ところが実際に動かしてみると、



・リソース割り振りに失敗する:そもそもISA Busのリソースが限られており、重複せずに割り振るのがそもそも無理ゲー



・割り振られたリソースにカードが対応できない:そもそもハードウェア的に自由にリソースを変更できないようになっているカードが少なくなく、BIOSの側でリソースの値を割り振っても、それをカードが利用できないケースが多数発生



・アプリケーションが理解しない:PnP BIOSを経由すればカードの設定を取得できるはずだが、それをやらないアプリケーション多数



というわけで、終いには“Plug & Pray”(挿して、動いてくれと祈る)とか揶揄(やゆ)される羽目になる。



 ただPnP ISAの失敗がUSB及びPCIにつながるわけで、意味のある失敗だったのが救いではあったのだが。そしてPCというものの「仕様」を定める重要な役割を担うメーカーとして、IntelとMicrosoftが大きくクローズアップされることになる、その最初の出来事である。


    ランキングIT・インターネット

    前日のランキングへ

    ニュース設定