VL-BusとPnP ISA PCの仕様をMicrosoftとIntelが決める時代、始まる：“PC”あるいは“Personal Computer”と呼ばれるもの、その変遷を辿る（3/4 ページ）

[大原雄介，ITmedia]

　そもそも規格はかなり緩めなもので、例えば信号速度は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を両方使うことも可能（写真3）だが、ISA Busを使わない（写真4）構成もできた。

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

写真4：Trident TGUI9440搭載のノーブランドカード。ISA Busの方は電源とGNDのためだけに用意されている感じ。出典はWikipedia

　こうした流れとは別に、「もうちょっと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として同等の機能を実装しようとして失敗したわけだが、ISAでもそうした機能が必要になると考えた。