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とセグメント:オフセットで出力されているのでセグメント部分を削除

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

修正個所の発見１

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

Stirling画面写真

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

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

CrescentEve画面写真

修正個所の発見２

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

ということはこの「Klamathでない時」の処理を書き換えてやればOKという事になりますね。
僕は以下のようなコードを書きました。
とりあえず全CPUが通るようにしましたが、Coppermine/Tualatin以外は使わないだろうなぁ。

:35CF 6660            pushad  
:35D1 66B801000000    mov     eax,00000001
:35D7 0FA2            cpuid   
:35D9 25F0FF          and     ax,FFF0
:35DC 3D3006          cmp     ax,0630
:35DF 0F8C6701        jl      374A		; PenProなら抜ける
:35E3 8BD8            mov     bx,ax
:35E5 66B91E010000    mov     ecx,0000011E
:35EB 0F32            rdmsr   
:35ED 662500008000    and     eax,00800000
:35F3 0F855301        jnz     374A		; L2無効なら抜ける(Covington)
:35F7 66B91E010000    mov     ecx,0000011E
:35FD 0F32            rdmsr   
:35FF 6625DE0688FF    and     eax,FF8806DE
:3605 660D00400400    or      eax,00044000	; L2仮設定
:360B 6683E2FF        and     edx,-01
:360F 6683CA00        or      edx,+00
:3613 0F30            wrmsr   
:3615 81FB3006        cmp     bx,0630
:3619 0F853200        jnz     364F		; Klamath以外の処理へ(全てCACHE ERRORになる)

なので飛び先の364F〜369Dを以下のように書き換える。

:364F 81FB8006        cmp     bx,0680		; Coppermine以降か?
:3653 0F8DC000        jnl     3717		; YES => 何もせずL2有効化へ

:3657 66B91E010000    mov     ecx,0000011E	; その他CPU用設定(Deschutes/Mendocino/Katmai)
:365D 0F32            rdmsr
:365F 66B82A043401    mov     eax,0134042A	; Mendocino用L2値を仮設定(L2レイテンシ=5)
:3665 81FB6006        cmp     bx,0660		; Mendocinoか?
:3669 7406            jz      3671		; YES
:366B 66B82A443401    mov     eax,0134442A	; Deschutes/Katmai用L2値を設定(L2レイテンシ=5)
:3671 6683E2FF        and     edx,-01
:3675 6683CA00        or      edx,+00
:3679 0F30            wrmsr			; L2設定書き込み
:367B 0F08            invd
:367D 90              nop
:367E E99600          jmp     3717		; L2有効化へ

:3681 90              nop			; 以降は余り
 |
:369D 90              nop
    ・
    ・
    ・
:3717 0F20C0          mov     eax,cr0
:371A 660D00000060    or      eax,60000000
:3720 0F22C0          mov     cr0,eax

終了時に跳ばしている3717hはKlamath時に全てのチェックが正常終了しL2を有効化させる場所です。
つまり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