まず、マザーボード上の Ultra 100 がどういう構成になっているのかを調べなくてはならない。出発点となった「U100をFT100に改造」で説明されているハードウェア部分の改造についての主な点を挙げると、
以上の二点に絞られ、いずれも ROM に関係していることが分かるが、この改造を行うことによってどういう効果があるのかが気になるところである。ROM の 2, 3, 4, 23 番ピンは、信号名で言えばそれぞれ A16, A15, A12, A10 に相当し、全てアドレスラインである。そのため、一見したところでは、この改造は ROM の読み出しアドレスを細工しているように見えるかもしれない。しかし、それは早とちりというもので、そんなことをしたら ROM が正しく読めなくなるだけであり、アドレス小細工説では説明できない。そこで、Ultra 100 において ROM 周辺の回路がどういう構成になっているのかを、より詳しく探ってみた。オンボード版の Ultra 100 には BIOS 用の ROM は存在しないため a. の改造は関係ないだろうと踏み、特に b. の改造に注目して回路図にしてみたものが 図1 である。
図1. Ultra 100 における ROM の周辺回路（赤色の部分は、改造後の回路）
- ROM の 2 と 3 番ピンを基板から切断し、それぞれを R16 と R17 に接続する
- ROM の 4 と 23 番ピンに、それぞれ 120Ωの抵抗を追加して GND に落とす
以上の二点に絞られ、いずれも ROM に関係していることが分かるが、この改造を行うことによってどういう効果があるのかが気になるところである。ROM の 2, 3, 4, 23 番ピンは、信号名で言えばそれぞれ A16, A15, A12, A10 に相当し、全てアドレスラインである。そのため、一見したところでは、この改造は ROM の読み出しアドレスを細工しているように見えるかもしれない。しかし、それは早とちりというもので、そんなことをしたら ROM が正しく読めなくなるだけであり、アドレス小細工説では説明できない。そこで、Ultra 100 において ROM 周辺の回路がどういう構成になっているのかを、より詳しく探ってみた。オンボード版の Ultra 100 には BIOS 用の ROM は存在しないため a. の改造は関係ないだろうと踏み、特に b. の改造に注目して回路図にしてみたものが 図1 である。
図1. Ultra 100 における ROM の周辺回路（赤色の部分は、改造後の回路）
図1 では ROM の 4 と 23 番ピンに関係する回路だけに絞って書いてあることをご留意いただきたい。ご覧のように ROM の 4 と 23 番ピンは、それぞれコントローラである PDC2026x の 52 と 53 番ピンに接続されており、また 33Ωの抵抗を介して、それぞれ IDE ポートの 37 と 36 番ピンに接続されている。要するに、コントローラから見れば ROM も IDE ポートも同一のバス上に配線されており、どちらにアクセスするかは、/CE などで決めているのだと考えられる。関係ないが、IDE ポートの直前にある 33Ωの抵抗は、恐らくダンピング抵抗だろう。
さらに、Ultra 100 では、いずれのバスとも 1KΩの抵抗で VCC にプルアップされており、FastTrak 100 に改造した後には、逆に 120Ωで GND にプルダウンされる結果となる。このような点から見て疑問として残ることは、なぜこの線がプルアップされていなければならないか、また、なぜこの線がプルダウンされることによって Ultra 100 が FastTrak 100 に化けるのかという二点である。そもそも、Ultra 100 も FastTrak 100 も、使用しているコントローラは同一のチップである。そのことから考えると、コントローラは 52 と 53 番ピンのロジックレベルを調べ、High であれば Ultra 100 として、Low であれば FastTrak 100 として動作するような仕掛けになっているものと推定される。
それにしても、120Ωで GND に落とされているとあっては、コントローラのポートが少々苦しいかも。
さらに、Ultra 100 では、いずれのバスとも 1KΩの抵抗で VCC にプルアップされており、FastTrak 100 に改造した後には、逆に 120Ωで GND にプルダウンされる結果となる。このような点から見て疑問として残ることは、なぜこの線がプルアップされていなければならないか、また、なぜこの線がプルダウンされることによって Ultra 100 が FastTrak 100 に化けるのかという二点である。そもそも、Ultra 100 も FastTrak 100 も、使用しているコントローラは同一のチップである。そのことから考えると、コントローラは 52 と 53 番ピンのロジックレベルを調べ、High であれば Ultra 100 として、Low であれば FastTrak 100 として動作するような仕掛けになっているものと推定される。
それにしても、120Ωで GND に落とされているとあっては、コントローラのポートが少々苦しいかも。
ここまで判明すれば、オンボード版の Ultra 100 にも同様の原理を適用すれば良いわけだから、話は早い。ASUS A7V の基板上のどこかに、PDC20265 の 52 と 53 番ピンのロジックレベルを High にしている抵抗が実装されているはずだから、これを探して Low になるような改造を施せば良いに違いないのだ。調べてみると、確かにそれらしい抵抗があった。部品番号で言えば R430 と R433 で、案の定 52 と 53 番ピンをプルアップする形で VCC に繋がっている。
マザーボードのリビジョンにより少し異なるかも知れないが、その抵抗を撮影したのが下の写真である。
マザーボードのリビジョンにより少し異なるかも知れないが、その抵抗を撮影したのが下の写真である。
お気づきの方もいるかもしれないが、R430 と R433 の上部には「いかにもそれらしい」未実装パタンがある。しかも、これまた親切なことに、問題の未実装パタンの片側はそれぞれ PDC20265 の 52 と 53 番ピンに繋がっており、もう片側は双方ともに GND に落ちているではないか。まるで、「どうぞ僕を改造してください」と、半田ごての登場を静かに待ちわびているかの如く。ならば、もうこれは手術を施してやるしかない。
上図のように抵抗を付け替えれば、少なくともハードウェア的には FastTrak 100 に化けたはずである。なお、この二カ所以外にも空パタンがあり、どれもが PDC20265 の振る舞いを決めるものと思われるが、詳細は良く分からない。
なお、この改造を行うとノーマルの BIOS では二度と立ち上がらなくなるので注意されたい。
なお、この改造を行うとノーマルの BIOS では二度と立ち上がらなくなるので注意されたい。
次に問題となるのが、BIOS である。Ultra 100 と FastTrak 100 とでは、ROM に書かれている BIOS が全く違うので、変身させる際には書き換えてやらなければならない。しかし、いま相手にしているものはオンボードであるため、BIOS が拡張カード版のように独立した ROM に書かれているわけではなく、マザーボードの BIOS に組み込まれてしまっている。従って、ちょっと工夫しないと書き換えられない。ASUS のマザーボードで使用されている AWARD の BIOS については、AWARD BIOS を解析する に解析結果をまとめて解説したので、詳しくはそちらを参照されたい。この中の u100b20.bin というファイル（BIOS の リビジョンにより、枝番が異なる）が、Ultra 100 の BIOS である。基本的には、これをどこかから落としてきた FastTrak の BIOS に差し替えれば良いわけだ。BIOS の構造は、事前に詳しく解析しておいたので、早い話がそれだけのこと・・・で済むはずだった。
ところが、単に差し替えただけでは読み込まれすらしない。原因を突き止めるまでに随分と苦労したのだが、分かってしまえば非常に単純でアホ臭いことだった。Ultra 100 で使用される BIOS の ROM イメージのサイズは 16kB であるのに対し、FastTrak 100 で使用される BIOS の ROM イメージのサイズは、64kB である。A7V の AWARD BIOS では、stn.bin というファイル名で ROM に格納されている System BIOS 部分が Ultra 100 の BIOS を読み込んでいるのだが、このときに ROM イメージのサイズを 16bit のレジスタで計算していたため、64kB の イメージを正しく処理できていなかったのだ。まずは、これを修正しないとどうにもならない。
拡張カードに搭載される ROM イメージの構造について簡単に説明すると、ROM イメージの先頭は 0x55 0xaa というバイト列で始まらなければならず、また ROM イメージの 3 バイト目は、ROM イメージのサイズを 512 で割った数字でなければならないことになっている（64KB なら、0x80）。さらに、byte 単位で総和を取ったとき、結果がゼロにならないといけないというチェックサムの決まりもある。これらをチェックするのは System BIOS の仕事であり、そのために以下のようなコードがあった（なお、リストのアドレスは、A7v1003.awd の stn.bin の先頭を 0000:0000 として出したものだ。より新しいリビジョンでも問題となる部分のコードは変わっていないようだが、アドレスがずれているので注意）。
赤色で記した命令で、CL に格納された ROM イメージの 3 バイト目（＝イメージのサイズを 512 で割ったもの）を 9 ビット左にシフトし、512 倍して ROM イメージのサイズを計算していることが分かる。ところが、64kB のイメージが入ってきた場合には 0x80 を 512倍することになり、その結果が 0x10000 になるため、16bit レジスタである CX で演算を行った場合には 0x0000 が格納されてしまう。従って、チェックサムの検査が正しく行われず、FastTrak の BIOS は不正なものと判断されて破棄されてしまっていたわけだ。律儀に修正するのも面倒だし、あまり意味がないので、チェックサムの計算は省くようにして回避した。
このルーチン以外にも ROM イメージのサイズを 16bit レジスタで計算しているところを発見した。こちらは ROM イメージのサイズそのものを得るための重要な部分なので、ごまかしで回避するわけにもいかず、32bit レジスタで計算するように書き直した。ただ、コードのバイト数が変わるとジャンプ先アドレスの再計算が面倒なので、修正後も結果的に命令長が同じになるよう注意しながら書き換えるのだ。先頭では EDX を XOR でゼロ化し、32bit で計算しようというそぶりを見せながらも、いざ肝心なところでは 16bit で計算するという何とも意地悪なコードだ。ゼロ拡張付きの mov である movzx 命令に 32bit バレルシフタと、80386 様々である（あ、脳味噌は AMD なんだけどね）。
逆アセンブラなどを使用しないで簡易的に改造するのであれば、まず A7V の BIOS から stn.bin だけを取り出し、そしてバイナリエディタなどで開いて問題のバイト列を検索すれば、修正すべき個所が見つかるだろう。その部分をガリガリと書き換えてしまえば良い（でも、間違ったところを書き換えたり、書き換えが間違っていると必ず立ち上がらなくなるので、くれぐれも慎重に！）。
これで、System BIOS が FastTrak 100 の BIOS を読み込んでくれるようになった。しかし、今度は起動時に「No FastTrak Controller Found」と出て、FastTrak 100 が存在しないことになってしまう。やはりというか、一筋縄ではいってくれない可愛くないヤツだ。
しかし、これもまた分かれば簡単なことだった。拡張カード版の FastTrak 100 は、Plug and Play の Device ID が 0x4d30 であるのに対し、オンボードの FastTrak 100 は、Device ID が 0x0d30 になっている。当然、どこかから落としてきた BIOS では 0x4d30 という Device ID を持ったデバイスの存在を期待しているため、そのままでは Plug and Play の処理において 0x0d30 という Device ID を持つ FastTrak 100 の存在を検出することができないのだ。これは、FastTrak 100 の BIOS 中に現れる 0x4d30 を、全てバイナリエディタで 0x0d30 に書き換えてしまえば回避可能である。チェックサムの再計算は不要だ、さきほど省いてしまったから。
結果論を叙述的に記せばそれだけのことだが、ここに至るまでの血の滲むような解析作業と実験の末、
ところが、単に差し替えただけでは読み込まれすらしない。原因を突き止めるまでに随分と苦労したのだが、分かってしまえば非常に単純でアホ臭いことだった。Ultra 100 で使用される BIOS の ROM イメージのサイズは 16kB であるのに対し、FastTrak 100 で使用される BIOS の ROM イメージのサイズは、64kB である。A7V の AWARD BIOS では、stn.bin というファイル名で ROM に格納されている System BIOS 部分が Ultra 100 の BIOS を読み込んでいるのだが、このときに ROM イメージのサイズを 16bit のレジスタで計算していたため、64kB の イメージを正しく処理できていなかったのだ。まずは、これを修正しないとどうにもならない。
拡張カードに搭載される ROM イメージの構造について簡単に説明すると、ROM イメージの先頭は 0x55 0xaa というバイト列で始まらなければならず、また ROM イメージの 3 バイト目は、ROM イメージのサイズを 512 で割った数字でなければならないことになっている（64KB なら、0x80）。さらに、byte 単位で総和を取ったとき、結果がゼロにならないといけないというチェックサムの決まりもある。これらをチェックするのは System BIOS の仕事であり、そのために以下のようなコードがあった（なお、リストのアドレスは、A7v1003.awd の stn.bin の先頭を 0000:0000 として出したものだ。より新しいリビジョンでも問題となる部分のコードは変わっていないようだが、アドレスがずれているので注意）。
| −修正→ |
|
赤色で記した命令で、CL に格納された ROM イメージの 3 バイト目（＝イメージのサイズを 512 で割ったもの）を 9 ビット左にシフトし、512 倍して ROM イメージのサイズを計算していることが分かる。ところが、64kB のイメージが入ってきた場合には 0x80 を 512倍することになり、その結果が 0x10000 になるため、16bit レジスタである CX で演算を行った場合には 0x0000 が格納されてしまう。従って、チェックサムの検査が正しく行われず、FastTrak の BIOS は不正なものと判断されて破棄されてしまっていたわけだ。律儀に修正するのも面倒だし、あまり意味がないので、チェックサムの計算は省くようにして回避した。
このルーチン以外にも ROM イメージのサイズを 16bit レジスタで計算しているところを発見した。こちらは ROM イメージのサイズそのものを得るための重要な部分なので、ごまかしで回避するわけにもいかず、32bit レジスタで計算するように書き直した。ただ、コードのバイト数が変わるとジャンプ先アドレスの再計算が面倒なので、修正後も結果的に命令長が同じになるよう注意しながら書き換えるのだ。先頭では EDX を XOR でゼロ化し、32bit で計算しようというそぶりを見せながらも、いざ肝心なところでは 16bit で計算するという何とも意地悪なコードだ。ゼロ拡張付きの mov である movzx 命令に 32bit バレルシフタと、80386 様々である（あ、脳味噌は AMD なんだけどね）。
| −修正→ |
|
逆アセンブラなどを使用しないで簡易的に改造するのであれば、まず A7V の BIOS から stn.bin だけを取り出し、そしてバイナリエディタなどで開いて問題のバイト列を検索すれば、修正すべき個所が見つかるだろう。その部分をガリガリと書き換えてしまえば良い（でも、間違ったところを書き換えたり、書き換えが間違っていると必ず立ち上がらなくなるので、くれぐれも慎重に！）。
これで、System BIOS が FastTrak 100 の BIOS を読み込んでくれるようになった。しかし、今度は起動時に「No FastTrak Controller Found」と出て、FastTrak 100 が存在しないことになってしまう。やはりというか、一筋縄ではいってくれない可愛くないヤツだ。
しかし、これもまた分かれば簡単なことだった。拡張カード版の FastTrak 100 は、Plug and Play の Device ID が 0x4d30 であるのに対し、オンボードの FastTrak 100 は、Device ID が 0x0d30 になっている。当然、どこかから落としてきた BIOS では 0x4d30 という Device ID を持ったデバイスの存在を期待しているため、そのままでは Plug and Play の処理において 0x0d30 という Device ID を持つ FastTrak 100 の存在を検出することができないのだ。これは、FastTrak 100 の BIOS 中に現れる 0x4d30 を、全てバイナリエディタで 0x0d30 に書き換えてしまえば回避可能である。チェックサムの再計算は不要だ、さきほど省いてしまったから。
結果論を叙述的に記せばそれだけのことだが、ここに至るまでの血の滲むような解析作業と実験の末、
設定画面が現れ、ハードディスクを認識させることに成功した。
道のりは長かったとはいえ、ここまでは突撃実験室の専門分野だったので
いつも真っ直ぐ突っ走れ（解析だ！）
誰の助けもいらないよ（男だね！）
我慢はできない 弱音は吐かない
腕を振るうぜ 組み込み屋
などと頭の悪い替え歌を作りながらでも、どうにか対処できる範囲の問題だけで済んでいた。
ところが。
メダルが眩いばかりに光り輝くのもここまでか（違うぞ）。BIOS まで動くようになって「ドライバ」という良く分からないものに行く手を阻まれてしまった。マザーボードや BIOS 改造した状態で Windows 2000 を立ち上げてみると、RAID コントローラを検出したとの表示が出るのでハードウェアとしては動作している模様だ。となれば、あとはドライバにも必要な改造を施してやれば、本プロジェクトは完成するはずである。
ドライバから見て、Ultra 100 (改) FastTrak 100 オンボード版が拡張カード版と決定的に異なる点と言えば、まず Device ID が挙げられる。BIOS の部分でも述べた通り、拡張カード版の Device ID は 0x4d30 だが、オンボード版の Device ID は 0x0d30 なのだ。Windows 2000 は、この Device ID を元に inf ファイルから適切なドライバを探して組み込む仕掛けなっているため、まずは FastTrak 100 の FASTTRAK.INF をテキストエディタで書き換えた。FASTTRAK.INF の中に現れる DEV_4D30 という文字列が拡張カード版 FastTrak 100 の Device ID を示している部分なので、これを実体に合わせて、全て DEV_0D30 に書き換えるのだ。
同じ理由からドライバ本体の FASTTRAK.SYS も書き換える必要があるのは明白なので、バイナリエディタ開いてみた。0x4d30 を探すと二カ所あり、調べた結果いずれとも偶然の一致ではなく Device ID としての 0x4d30 であると考えられたため、これらも全て 0x0d30 に書き換えてみる。このようにして改造した FastTrak 100 のドライバをインストールするところも、何の問題もなく完了するのだ。ところが、ドライバをインストールした状態で OS を再起動すると、起動時にドライバが組み込まれようとはするのだが、その途端に OS がハングアップして起動しなくなってしまう。考えられる問題点は色々と洗ってみたのだが、いまだ解決には至っていない。
ん〜〜悔しいことに、ここまできて Windows 2000 のドライバに玉砕。
ほかの OS ではどうなるのかを試してみる必要もあるし、コントローラのチップが PDC20267 ではなく PDC20265 というのも気になる（Device ID が異なるだけで同じ動作をしているように見えるのだが）。また、Windows のカーネルモードドライバについては全く知識がないため、このような改造だけで良いのかどうかすら定かではないし、仮に問題点があるとすれば、それがどこでどのように起きているのかを調べる方法も、残念ながらよく分からずお手上げ状態である。
ふふふ、我こそは！
Windows のドライバをやらせれば俺の右に出る者などいるはずがない！
という強者の皆様、必要な情報は提供しますので、引き継いでみませんか！？
いつも真っ直ぐ突っ走れ（解析だ！）
誰の助けもいらないよ（男だね！）
我慢はできない 弱音は吐かない
腕を振るうぜ 組み込み屋
などと頭の悪い替え歌を作りながらでも、どうにか対処できる範囲の問題だけで済んでいた。
ところが。
メダルが眩いばかりに光り輝くのもここまでか（違うぞ）。BIOS まで動くようになって「ドライバ」という良く分からないものに行く手を阻まれてしまった。マザーボードや BIOS 改造した状態で Windows 2000 を立ち上げてみると、RAID コントローラを検出したとの表示が出るのでハードウェアとしては動作している模様だ。となれば、あとはドライバにも必要な改造を施してやれば、本プロジェクトは完成するはずである。
ドライバから見て、Ultra 100 (改) FastTrak 100 オンボード版が拡張カード版と決定的に異なる点と言えば、まず Device ID が挙げられる。BIOS の部分でも述べた通り、拡張カード版の Device ID は 0x4d30 だが、オンボード版の Device ID は 0x0d30 なのだ。Windows 2000 は、この Device ID を元に inf ファイルから適切なドライバを探して組み込む仕掛けなっているため、まずは FastTrak 100 の FASTTRAK.INF をテキストエディタで書き換えた。FASTTRAK.INF の中に現れる DEV_4D30 という文字列が拡張カード版 FastTrak 100 の Device ID を示している部分なので、これを実体に合わせて、全て DEV_0D30 に書き換えるのだ。
同じ理由からドライバ本体の FASTTRAK.SYS も書き換える必要があるのは明白なので、バイナリエディタ開いてみた。0x4d30 を探すと二カ所あり、調べた結果いずれとも偶然の一致ではなく Device ID としての 0x4d30 であると考えられたため、これらも全て 0x0d30 に書き換えてみる。このようにして改造した FastTrak 100 のドライバをインストールするところも、何の問題もなく完了するのだ。ところが、ドライバをインストールした状態で OS を再起動すると、起動時にドライバが組み込まれようとはするのだが、その途端に OS がハングアップして起動しなくなってしまう。考えられる問題点は色々と洗ってみたのだが、いまだ解決には至っていない。
ん〜〜悔しいことに、ここまできて Windows 2000 のドライバに玉砕。
ほかの OS ではどうなるのかを試してみる必要もあるし、コントローラのチップが PDC20267 ではなく PDC20265 というのも気になる（Device ID が異なるだけで同じ動作をしているように見えるのだが）。また、Windows のカーネルモードドライバについては全く知識がないため、このような改造だけで良いのかどうかすら定かではないし、仮に問題点があるとすれば、それがどこでどのように起きているのかを調べる方法も、残念ながらよく分からずお手上げ状態である。
ふふふ、我こそは！
Windows のドライバをやらせれば俺の右に出る者などいるはずがない！
という強者の皆様、必要な情報は提供しますので、引き継いでみませんか！？
はっきりいって、止めておくことを心からご忠告申し上げます。
シロウトさんお断りネタであることは論を俟たない。純粋に FastTrak 100 が欲しいのなら、素直に店に行って正規品を購入されるべきだ。改造といっても、ここまでディープになってくれば、ほとんど技術屋のオナニーである。その味が分からない人にとっては、むしろやるだけ馬鹿らしいだけだと思う。
本稿に書いた内容を完全に理解するためには、ハードウェア、BIOS、Plug and Play、アセンブリ言語など多岐に渡る知識が必要だし、BIOS をいじくる以上、Flash に失敗したときの備えがない方は、そもそも手を出すべきではない。当然ながら、マザーボードに半田ごてを付けた時点で保証はなくなる。たとえ改造に失敗して、あなたの大切なパソコンに異常が発生したとしても、突撃実験室は何の補償も手助けもできないことをご承知いただきたい。
「んなことたぁ、百も承知だ」という方は、煮るなり焼くなりご自由に。
シロウトさんお断りネタであることは論を俟たない。純粋に FastTrak 100 が欲しいのなら、素直に店に行って正規品を購入されるべきだ。改造といっても、ここまでディープになってくれば、ほとんど技術屋のオナニーである。その味が分からない人にとっては、むしろやるだけ馬鹿らしいだけだと思う。
本稿に書いた内容を完全に理解するためには、ハードウェア、BIOS、Plug and Play、アセンブリ言語など多岐に渡る知識が必要だし、BIOS をいじくる以上、Flash に失敗したときの備えがない方は、そもそも手を出すべきではない。当然ながら、マザーボードに半田ごてを付けた時点で保証はなくなる。たとえ改造に失敗して、あなたの大切なパソコンに異常が発生したとしても、突撃実験室は何の補償も手助けもできないことをご承知いただきたい。
「んなことたぁ、百も承知だ」という方は、煮るなり焼くなりご自由に。