CPUを変更

概要でも書きましたがRvII26のITFはL2チェッカが当時のIntelガイドラインに完全準拠しているようで、Klamath以降のCPUを搭載するとCACHE ERRORと表示して停止してしまいます。
しかし、L2チェッカを書き換えることで動作自体は問題なく可能な事は周知の事実だと思います。

N.Y氏のコンテンツと被りますが、Tualatinを搭載するための情報など書いてみようかと。
#N.Y氏のトコよりプログラムを多少わかる方向けになっていますのでご了承ください。
また、記載されているアドレスは僕所有の個体のものですのでITFのRevによっては異なる可能性が十分にありますことをご了承ください。

ITFの内容取得

まずはITF内部でどのような処理が行われているのか知る必要があります。
ITFの内容をダンプするツールとしてまりも氏作の「getitf98」というものがありますのでそれを利用します。
実行の際はリアルモードであることが求められますので、HIMEM.SYSを登録しない状態で起動します。
実行するとBANK0〜Fのファイルが出来ますが、添付のドキュメントにある通りITFはBANK4です。

GetITF98実行画面

作成されたBANK4.BINを解析するには逆アセンブラとバイナリエディタが必要です。
僕は逆アセンブラにDDEB.EXE、バイナリエディタにStirlingを利用していますのでそれをベースに説明します。
ちなみにどちらもVectorでダウンロード可能です。

DDEB&Stirling実行画面

ITFの逆アセンブル

ちなみに、ですがWindows上での作業なのでPC-98上でなくとも構いません。
DDEBのマニュアルどおりなのですが、以下の手順でBANK4.BINを逆アセンブルします。

1. DDEBをコマンドプロンプトで実行
2. N BANK4.BIN  としてデータを指定
3. L 0          としてオフセット0番地にデータを読み込み
4. > BANK4.TXT  として書き出しテキスト名を指定
5. U 0 7FFF     として逆アセンブル結果を出力
6. Q            でDDEB終了
7. xxxx:xxxxとセグメント:オフセットで出力されているのでセグメント部分を削除
	

ただこの状態だとベタで吐き出しただけなので、途中のワークエリアまで命令語と解釈した出鱈目を含むリストになっています。
これは手動で逐一修正していかないといけません。どうしても慣れが必要な作業です。
といっても必要な部分だけ整形できれば問題はないでしょう。

修正個所の発見1

出来上がった逆アセンブルリストとバイナリデータを基に修正個所の探求を行います。
powerx氏やN.Y氏のサイトにもありますが、エラーメッセージから探すのが一番簡単です。
ctrl+Fで検索ダイアログを出してデータ種別に「文字列」を選び、「CACHE ERROR」を入力するだけです。
すると3B3Fhから文字列が見つかります。
実際にはこの前にITF内部の文字列表示ルーチンでの制御コードがあるので、メッセージ自体は3B3Ehから始まっています。

Stirling画面写真

続いて、この3B3Ehがどこで参照されているかを逆アセンブルリストで確認します。
するとすぐ上の3B31hからの「mov   si,3B3E」で参照されていますね。
エラー表示の処理はココから始まるという事です。

すぐ上の命令でココを回避するように記述されており、更にその前はcall命令ですから何らかのサブルーチンです。
ということはここでcallされている35CFhからのサブルーチンの結果によりエラーかそうでないかが決まっている、と容易に想像できますね。

CrescentEve画面写真

修正個所の発見2

では早速35CFhからのサブルーチンを解析します。
pushad->mov->cpuid->and と連なる命令群の結果、axレジスタにcpuのステッピングコード(下一桁は0クリア)が入ります。
その後、063xより小さい(古い)か?とかL2は実装されているか?などのチェックを行い、とりあえずL2不可、未構成で初期化しています。
仮の初期化が終わった後、ステッピングが063xかどうか確認しています。
これがKlamathかどうかの確認で、そうでない場合は別処理に移ります。
#ただ、この別処理に入った後は全てCACHE ERROR・・・

ということはこの「Klamathでない時」の処理を書き換えてやればOKという事になりますね。
僕は以下のようなコードを書きました。
Tualatin以外にKatmaiやMendocinoも動くようにしましたが、きっと常用はしないんだろうなぁ。

:3615 81FB3006        cmp     bx,0630
:3619 0F853200        jnz     364F
    ・
    ・
    ・
:364F以降
    cmp     bx,0680             ; Coppermine以降か?
    jnl     3717                ; YES => 何もせず終了
    cmp     bx,0660             ; Mendocinoか?
    jnz     3679                ; NO  => Katmaiかチェック
                                ; ここからMendocino用設定
    mov     ecx,0000011E
    rdmsr
    mov     eax,0130442A
    and     edx,-01
    or      edx,+00
    wrmsr
    nop
    jmp     3717                ; Mendocino設定終了

:3679
    cmp     bx,0670             ; Katmaiか?
    jnz     3717                ; NO  => 不明なCPUだが何もせず終了
                                ; ここからKatmai用設定
    mov     ecx,0000011E
    rdmsr
    mov     eax,0134442A
    and     edx,-01
    or      edx,+00
    wrmsr
    nop
    jmp     3717                ; Katmai設定終了
    nop                         ; 余ったので長さあわせ
    nop
    ・
    ・
    ・
:3717 0F20C0          mov     eax,cr0
:371A 660D00000060    or      eax,60000000
:3720 0F22C0          mov     cr0,eax
	

終了時に跳ばしている3717hはKlamath時に全てのチェックが正常終了した場合に通る場所です。
Klamath以外ではキメウチで設定して正常終了したことにするっていう寸法です。
この修正法の問題点は「本当にL2が壊れていても検出できない」ということですが、それはそれって事で(笑

バイナリの修正

修正すべき内容が決定したら、それをバイナリデータとしてBANK4.BINに反映します。
DDEBにはアセンブル機能もあるので、どのようにバイナリを得るかという心配は必要ありません。
そしてその結果を保存してバイナリエディタで手入力します。
実際の手順を書くまでも無いでしょうが、先の手順でBANK4.BINをロードした後、

1. A 364F       としてアセンブルモードにする。
2. 上記のソースコードを入力
3. U 364F       としてアセンブル結果を確認。
                併せてこの時のバイナリ値を保存。
4. DDEBを終了し適当なバイナリエディタでBANK4.BINの内容を編集
	

とすることで修正したBANK4.BINが出来上がります。
入力が終わったら、そのファイルをDDEBで再び逆アセンブルして打ち間違いが無いか確認したほうが良いでしょう。

チェックサムをあわせる

上記の修正でL2エラーは回避できますが、もうひとつやっておくことがあります。
ITFは各BANKの奇数/偶数アドレスそれぞれで、BYTE単位のチェックサムが0である必要があるのです。
コードを書き換えたわけですから、もちろんチェックサムも異なります。
N.Y氏のサイトでもチェックサムツールが紹介されていますので参考にしてください。
で、ドコでチェックサムをあわせるかというと3FFEhからの2Byteか修正ロジックの余り部分を使用します。
修正したら再度ツール等でチェックサムを確認してください。

sum.exe 画面写真

CPUの搭載

上記の修正を何らかの手法でITFのFLASHに書き込めば無事に完了です。
TualatinはFC-PGA2ですから変換ゲタを利用して搭載するのですが、有名どころのPL-iP3/Tだと個体によってはまともに動作しません。
僕の環境ではWindowsの起動中に停止してしまいました。
オススメなゲタはUpgradeware製SLOT-Tです。外部VRMを必要としますがシンプルな造りが良いのか非常に安定しています。

FUJI氏のサイトにRvIIにおけるゲタの解説があるので参考にしてください。
当サイトのリンク集からジャンプできます。

SLOT-Tの写真

ちなみにnicoの使っているVRMはDELTA製の05S2020という奴です。

DELTA 05S2020の写真

EZ1084発熱対策

ITF書き換えでCPU変更を行った場合に問題になるのが、左手前の3端子レギュレータの発熱です。
個体差もあるようですが、僕の場合迂闊に触ると指の皮がくっついてしまう位に熱くなってました。
ということでこのレギュレータには放熱板をつけ、CPUクーラーからの風を当てることが必須となります。

AGTL+をAGTLに変更

また、発熱自体を減らす努力も必要です。
「どるこむ」の過去ログに情報がありますが、以下の方法で実施します。
1.EZ1084の手前のピンをGNDに落とす。
2.EZ1084の奥のpinに供給される電圧を3.3Vに変更する。
上記1.はEZ1084に接続されている抵抗を無くし発熱を軽減するという手法ですが、これを行うと同時に出力が1.5Vから1.25Vになります。
AGTL+をAGTLに変更するということにもなりますから、Tualatinを搭載するなら必須で。
環境によってはこれだけでも十分なようです。
上記2.は入力と出力の電圧差を減らすことで発熱を軽減しようというもので、実際かなりの効果があります。
しかし、3.3Vを引き出す作業はハンダ馴れしていないとおっかなびっくりですから無理するより冷却強化をするのもありだと思います。

入力電圧を3.3Vに変更

最後に

ITFの修正方法は解ったが、書き込みはどないすねん。という感想の方も多いかと思いますが・・・
webにおける多くの事例紹介はROMライタによる書き込みです。
getitf98で作成されたファイルをきちんとした順序で結合すれば、ROMイメージと等価ですのでROMライタで書き込めます。
AT互換機+AwardFlash770を利用した手法も紹介されていますね。
僕の場合は以前FNECHARD会員だったので・・・でも、公開された手法を基に一応書き換えプログラムも作ってあります。
ただ基になった情報自体自分で調べたものではありませんし、一般に公開されていないので今のところ公開する予定はありません。
ヒントを挙げるなら、ITF内部に書き換えフロッピー読み込みルーチンがあるのでそこから起動するプログラムを作ればよい。ということです。
当掲示板の過去ログにもまりも氏の投稿があります・・・
あとはFLASH ROMの仕様書等を参考にして何とかしてください。


Valid CSS! Valid HTML 4.01 Strict