VESA1.2対応、あきらめますた!!!

決定打なのが、OSASKやMonaでもこれに対応するために仮想86モードを導入していることが解ったから。

Kタンやひげぽんさんがこの手法を使っているのだから、たぶんオイラが妄想している
「なんとかプロテクトモードからバンクを切り替える」
のが無理なのだろうという結論に達しました・・・　orz　・・・

この段階で、オイラ程度のスキルで仮想86モードにまで手を出すのは単に無謀だろうと。
ただでさえあちこち穴だらけなんですからねぇ・・・。もちろん、

そうは言っても！！！

なので、いつかもう少し勉強して仮想86モードが十分に扱えるようになったらその暁には・・・とは思っております。

いや〜。なにかと勉強になったです〜。

・・・妙なことに気が付いた。
昨日の写真をみてほしい。画面の途中までしか色が出てないでしょ？
（横方向はワザと。じゃなくて縦方向。）

オイラてっきり、実験で0xa0000からすこししか書き込んでいないのでこうだと思っていたんだけど・・・
その後、いくら書き込むアドレスを増やしても状況が変わらない。つまり、画面全体を真っ白にとかができない。

もしやと思い、ちょっと計算してみた。この画面ではどうやら1ドット=1バイトらしいので　640 × 480 × 1バイト = 307,200バイト。
キロバイトに換算すると300KB。
・・・300KB！？？　VRAMは0xa0000〜0xaffffまでの64KBしかない！
画面全体の1/5くらいしか容量がないじゃん！！！
（今画面を大雑把に定規で測ってみたら、たしかに1/5くらいで描画が止まっている！？？）

うむむむ！？？？

もしかして、この画面モードの場合、残りの部分を担当するVRAMがどこか別の場所に用意されている・・・のかな？？？

VESAコマンドを改良して、WindowAだとかそういうのの値をちょっと調べてみよう！

・・・うーむ。違うみたい・・・　WindowA、WindowBどちらも0となってしまう・・・

・・・やはりダメなのかなぁ・・・
ここからは単なる予想だけど、多分、バンク切り替えを行うともっと下のほうを描画できるんだろうなぁ・・・
でも、バンクを切り替えるためにはBIOSをコールしないといけない。

くっそぉぉぉ・・・・　ここまでがんばったけど、ここらあたりが限界なのかなぁ・・・

・・・なんかかなり濃厚になってきたぞ・・・

VESA 1.2ではバンク切り替えで色を表現するが、そのバンク切り替えという作業そのものはBIOSコールにて行われるのでプロテクトモードに移行した後はできない。ゆえに色を出すことができない

という疑念・・・・




・・・あっれぇ？　ちょっと待てよ？・・・・・

むりやりグラフィックモードを変更して、0xa0000に強制的に
データを書き込んで見たんだけど・・・・
色、出るじゃん！

ヒデェやひでぇや！　助さんも格さんも！
アッシにゃぁもう、なんがなんだか！！！

こうなったらもう、寝てやるぅ！！！

vesaコマンドを少し改良したよ。

これではりぼて上で行われているチェック項目は網羅できたかな。
さっそくGT475でVESAの状態を見てみよう！！！

・・・ orz ・・・

VESA  Ver 1.20  VRAM= 15KB

Vender:CHIPS 65520/525/530 Flat Panel VGA

Support SVGA Mode

 100  101  102  103  104  105  110  111

1Pix=  0Bits Mem Model is DirectColor.linear FB is NO!

・・・なんつーか・・・・
ことごとくはりぼてにはじかれる要素達・・・

ほんとにこんなの、どうにかなるのか？？　
VGAのコード書いたほうがまだ楽なんてことないのか・・・




え”っ！　うそ・・・・。まさか、バンク切り替え式（ノンリニアフレームバッファ）の場合って、BIOSで切り替えるの？？？　それじゃ、プロテクトモード上じゃ利用できないの？？　いやそんな・・・　まさか！！！　

各種の穴の修理と平行して、VESAの1.2について調べているのだが、なかなかはかどらないっす・・・(T T）

ウチのノートはVESA1.2だと分かったのはまあいいとして。
VESA1.2でも、インフォメーションを見る限りでは 0x101（640x480x256）や 0x105(1024x768x256）を
サポートしているふうである。
またこのノートでWin95を動かした場合はちゃんと 640x480x256 になる。
（つまり、液晶がこの能力を持っているわけである）

うーーーーん・・・・

はりぼてはなぜVESA1.2を採用していないのか。いろいろ調べると、
Linux等でも同じような感じが見受けられる。いったいなぜ・・・

よーし！　アンズよりグミは安いという格言もある。
いっそ、試してみるか！！！

沢山人がいる。その中に１人、侍がおる。どうすれば分かるだろう？
なに簡単だ。聞いてみればいいのだ！
「お前やろ！」　「僕は違います」
「お前やろ！」　「俺は違いぞ」
「お前やろ！」　「私じゃありません」
「お前やろ！」　「拙者は」
「おまえや〜〜〜〜〜〜〜〜〜〜・・・・・」


・・・でも長くなりそうなのでここいらへんに移動・・・

1. VESA対応機にて高解像度にならず落ちてしまう
   
2. なぜか320x200モード時、タスクバーの文字が書かれない
   
3. コマンド実行後、カーソルが点滅しなくなる
   
4. 起動直後、他のウィンドゥもアクティブ状態になる
   
5. タスクバーにはウィンドゥがかからないようにすべきでは？
   
6. タスクバーをクリックすると他の窓が非アクティブになる
   
7. dir2コマンドが古い
   
8. type3はもういらないのでは？
   
9. apiでseekが搭載されていない
   
10. memdumpコマンドが絶対番地に対応していない
    
11. FDアクセスで、4e等古いAPIが残っている
    
12. vesaコマンドが実機ではStackのエラー？を起こす
    

vesaコマンドの修理完了〜。
原因は二段構えなのだ　(^^;

まず最初。vesaコマンドの内部で豪華に char aaa[256]; とかをいっぱいやってたのね。
こんなのが3つも4つもあれば、そりゃあっと言う間にスタックがあふれちゃう。
で、それじゃあってんで、 api_malloc を使ったんだけど、今度は
Makefile内で指定するのを忘れてたのでエラー吐きまくり。
さらに、ある部分で、

  char *aaa;

  aaa = api_malloc(256);

  /////  aaa にデータを入れた  ///

  sprintf(s,"ahahaha! %s",aaa);

なんてふうにして、aaaを直接出力しようとしたんだけど、これが
NG!!

・・・そんなわけでとりあえずは直ったかなぁと・・・

いや〜。勉強になった。ノーミソがくすぐったくてかなわん！

・・・たははは・・・

いろいろやり過ぎたかなぁ。なんかあっちこっちで穴だらけですよ。

えーーっと。まず。

1. VESA対応機にて高解像度にならず落ちてしまう
   
2. なぜか320x200モード時、タスクバーの文字が書かれない
   
3. コマンド実行後、カーソルが点滅しなくなる
   
4. 起動直後、他のウィンドゥもアクティブ状態になる
   
5. タスクバーにはウィンドゥがかからないようにすべきでは？
   
6. タスクバーをクリックすると他の窓が非アクティブになる
   
7. dir2コマンドが古い
   
8. type3はもういらないのでは？
   
9. apiでseekが搭載されていない
   
10. memdumpコマンドが絶対番地に対応していない
    
11. FDアクセスで、4e等古いAPIが残っている
    
12. vesaコマンドが実機ではStackのエラー？を起こす
    

・・・こんなところかなぁ。

えーっと。まずは「１」ね。解決。リビジョン99

くっそぉ・・・わっからねぇなぁ・・・。
「２」なんだけど、解像度を上げるとなにもなかったように表示する。
しかし、320x200だとダメだなぁ・・・。文字そのものは表示しようとしている
みたいなんだけど、前景色が白になっちゃうようだ。しかも、これはタスクバーのシート内で一度でもboxfill8を使うと起こる。
（boxfill8を全部コメントアウトするとちゃんと文字が出る）
・・・なんでじゃ〜？？？　他のウィンドゥでも同じ現象がおこるなぁ・・・

はみゅ〜ん・・・

なんとか出来たぞ・・・　vesaコマンド搭載。
極簡単ではあるけど、VESAの情報を表示できるコマンドです〜。

こいつで調べてみると・・・

ノワアァァァァァァ！　ヽ(`Д´)ノ

やっぱウチのノート、VESA1.2じゃんかよぉ！！！


・・・あっれえぇぇ？？？
実機で動かしていろいろやってたらエラーが・・・

INT 0C :

 Stack Exception.

EIP = 00000038

だって・・・
なんじゃらホイ？　これ・・・


・・・つーーーーーか！！！！！
時計が動いてないじゃんかよ！？？？
あっれええぇぇぇ？
いつからだ！？　これ？？？

無事、VESAからにインフォメーションを受け取れるようになったんだけど、ナゾがナゾを呼んでいる！
（おーい　早く来いよ〜　）

ここ見てもらえるとわかるんだけど、
受け取ったインフォメーションの頭から6バイト目。
OEMベンダー名へのポインタっての。
・・・これ、なにをどうすればいいんだろう？？？

qemuではこれは、

+06  0x78

+07　0x00

+08　0x00

+09　0xc0

こうなってる。で、さらにOS-Wikiのページだと、
「seg:ofs16」と書かれている・・・

0xc000 * 16 + 0078など等、いろいろな組み合わせでやってみたんだけど、
これらの数字から導き出せるアドレス（ポインタ先？）には0だのなんだの、
とても文字とは思えないデータしか入っていないんだよなぁ・・・

いや〜。こまった・・・　いったいどう使うんだろう？　この数字？？？

たはははは・・・

そうだよそうだよソースだよ！　（GPLかい！）

16ビットモード（リアルモード）上で[aa:bb]という形式で指定された
アドレスは、絶対番地に換算すると aa×16 + bbになるんだよぉ！

・・・ってことは逆に考えれば、0xe00(絶対番地）をリアルモードで
指定したい場合は、ES = 0xe0 DI = 0 と、こうしなきゃダメなんじゃん！！！

とほほほほ・・・・　　いまさらこんなのに引っかかるとは・・・

うーん。でも、それでもやっぱり0x9000はダメだなぁ。
ここ、誰が書き換えてるんだろう・・・・