あっれえぇぇぇぇ？？

おっかしいなぁ。0x9000を読み出してみたけどなんか値が違うなぁ・・・
試しにアセンブラでこんなことしてみたけど

 		MOV		AX,0x9000

 		MOV		ES,AX

 		MOV		DI,0

 		MOV		AX,0x4f00

 		INT		0x10

 ;test

 		MOV		BX,'A'

 		MOV		[ES:DI],BX

 

 		CMP		AX,0x004f

 		JNE		scrn320

やっぱり値が違う・・・0x9000って、なにかで使われてる？？　もしかして？？

あーー！　違う違う！　そうかぁ！！

その後に、他のVESAの情報をゲットするために0x4f01とかをコールしてるんだよ！
で、そいつらもES:DIに書き込むから別の値になっちゃってるのか！？？

・・・いや・・・違うなぁ・・・。やっぱりだれかが書き換えているようだ・・・

まいったなぁ。黒猫本読んでみたけど、誰が書き換えてるかわからんなぁ・・・
やむをえん。とりあえずVESAの情報が書き込まれるアドレスを0xe00に移動するか・・・（誰もつかってないよね？ここ。大丈夫かなぁ・・・）

あっれえぇぇぇぇ？？？？
なんか勘違いしてる？　

 		MOV		AX,0xe00

 		MOV		ES,AX

 		MOV		DI,0

 		MOV		AL,'A'

 		MOV		[ES:DI],AL

たとえばこうした後に32bit化したとして、0xe00を読み出すとAが・・・じゃないの？？？　[ES:DI]という指定って・・・

やぁ〜んば　らぇあぇあ〜♪　やぁ〜んば　らぇあぇあ〜♪

はりぼてでは起動時、VESAをちょこっとだけ検査して切り替えてるよね？
いろいろと調べてみたら、VESAはもっといろいろな情報を返してくるらしいぞ？

そーゆーのを表示してみたいので古いはりぼてを弄ってたんだけど、
大問題。qemuって、BIOSでの文字列表示とかがヤワらしくてまともに
表示してくれないんだよなぁ・・・
（しかもアセンブラでしょ？　なんかツライ・・・）

そこでザビたんですよ！

考えてみれば、32bitだわ日本語は表示できるわのザビたんだけど、
それでも起動はMS-DOS並みに早いよね？　（OSASKにゃ勝てないけど・・・(^^;　）
だったら、コイツの起動時（16bit時）にそういう処理を搭載して、
コマンドかなんかで表示させたってそう大差ないじゃない？

いや大有り。なんたってプログラムが楽じゃんねぇ？？（＾＾

こういう拡張なら、別に無理に後で引っ込ぬく必要もないだろうしね。

つーーーわけで、vesaコマンド（vesaの各種情報を表示する）の
搭載開始〜

ふむふむ・・・
はりぼてではasmhead.nas内で起動時にVESA（VBE）の検査をしてるよね？
ここで、2.0サポートかそうでないかの判断だけしてジャンプしちゃってるけど、
実はこの段階でいろいろな情報がもたらされているらしい。
その情報はES:DIが指し示すアドレスに書き込まれるらしい。
はりぼてでもこれはちゃんと行っているみたい。
ええと・・・ようするに、0x9000番地に情報が書き込まれているんだね？
あれ〜？？？？
メモリマップで見る限り、ここはその後廃墟扱いで使われていないの？？
・・・っということは、ここにデータが残っている？？？
こりゃシメた！！！！
さっそくここいらヘンを読み込むapiかコマンドを乗せてみよう。
・・・おっと！　その前に！
VESAからどんな情報がもたらされるのか、ここらあたりにまとめておくか・・・

・・・ところで、VESA規格って1.1やら1.2やら2.0やら。いろいろあるみたいだよね？

はりぼてはVESA2.0にしか対応していないみたいだけど、なんでだろう？？？

また、1.2等古い規格って、純粋に上位下位互換なのかな？。それとも単なる名前？
（コロナとコロナマークⅡはなんの関係もないんだぜぃ！）

オイラの現時点での予測。

• VESA2.0くらいでないと、資料がぜんぜん出てきていない
  
• Kタンにとって1.2は縁起が悪い数字だった！(^^;
  
• 1.2等でも高解像度は可能だが、アクセス法が極端に煩雑なのではりぼてへの採用を見送った(今回分かったVGAの煩雑さとかね）
  
• 実は極端に採用数が少ない、VESAの歴史の中では仇花のような存在だった（VESA界のMeタン！）
  

ふむ〜・・・・・

時に！。ウチのGT475のビデオチップ。Chips 65520という型らしい。
で、ある資料に、コイツはVESA2.0をサポートしてると書かれていたのだが・・・
これ、まちがいじゃないかなぁ〜。
どうやっても320x200にしかならんのだがなぁ・・・。

まぁいいや。ちょっとVESAについてオベンキョしてみることにしよう。

・・・おっそおぉぉぉぉぉ！！！！！！

まいったなぁ〜。
もともとVGAに対応したかった最大の理由は、オイラが実機実験に
使っている劇古ノート（DynaBook GT475）上で320x200を表示させると
上と下が欠けちゃってシオシオだったから。（液晶だとこうなるんだよね・・・）
VGAに対応すればナンボかカコイイ感じになるかなぁと思ったのだが・・・

フォントの表示を半分くらい完成させたんだけど（harib02d相当）
オイラ程度の手法やアルゴリズムだと、このノートじゃ猛烈に
遅いことが判明した・・・

ただでさえ面倒で煩雑なVGA。がんばってこれに対応しても、
こうも遅いと・・・・
（なんか一気にやる気がしぼんでしまった・・・）

ちょっとしばらく考えてみよう。

うっひょおぉぉ！
でけたでけた〜！！！！！

harib01h　だけど、bootpac側は無改造で表示できたぞーー！
boxfil関数、VGA対応〜！！！
よーし！　この調子で他の関数を書き換えれば・・・いけるかな！？？

（まあもっとも、Sheet周りは今から大変そうなのが予測できるけどね・・・（＾＾；　　）

VGAのラッチがわからずにハマっとるオイラです〜。

ラッチ！　ラッチ！　ここに　ラッチ！
あ〜な〜た〜か〜ら〜♪
らぁっち！


現実逃避に首都高へ・・・　orz　・・・・

ポチっとな！？？

ここでヘコヘコとVGA書き込みの実験してたんだけど、そこでドッパまってしまったのでメモ〜。

右シフト演算はできるだけ避ける、もしくはできるだけunsigned型を使うようにしよう！

つーことらしい。

なにやってたかって言うと、マスク用変数を作りたかった。
たてえば、左から4ビットだけ0で後はみんな1とかそういうのを作りたかった。（この場合、何ビットずらすかがその都度不定なのでビットシフトを使っていた）

で、こうしてたんだよねぇ・・・・

    char aaa;

    aaa = 0xFF;     //まずは1111111111111111bを作って・・・



    aaa = aaa >> 4;    //この4は演算で出る値なので固定値ではない



    //やったぞ！　これで、0000111111111111bができたぞ！

ところがこれが、何回やってもうまく行かない・・・orz

で、いろいろ調べてたら分かったわけ。正解はこれ。

    unsigned char aaa;

    aaa = 0xFF;     //まずは1111111111111111bを作って・・・



    aaa = aaa >> 4;    //この4は演算で出る値なので固定値ではない



    //やったぞ！　これで、0000111111111111bができたぞ！

いや〜〜〜・・・・　ハマったハマった・・・(^^;

ちょっと補足。なんで右シフトは避けたほうがいいのか？。左シフトは空いてしまったビットが必ず0で埋められることが確約されているが、右の場合、unsignedかそうでないか等、いくつかの条件下で必ずしも0にならないかららしい。なので、左シフトと同じ感覚で使うとオイラのようにハマりまくることがよくあるからだそうだ。もちろんそれを想定・過程した上でなら問題ないのだろうが・・・。参考までに。

ふむ・・・・
あちこち調べていたのですが、どうもVGA画面つーのは今までみたいに
VRAMに値をポンで描画できるわけではないようです。
どうも、プルーンプレーンというものがいくつかあって、
それが色やら明るさやら？を個別に担当しているような感じ？

オイラが実験で悩んでいた、「ビットがドット」というのも
間違いではないようですが、ほかのプレーンにまた別のデータを
書き込むことで初めて色が出る・・・どうもそんな感じらしいです。

これに関すると思われる資料はもちろんOS-Wiki内で見つけてはいたのですが、
これが難しくてわからない・・・orz

もうすこしいろいろと調べてみないと・・・
（まだ原理や理屈が把握できていないのだ）

・・・たしかにこりゃややこしいよね？(^^;
（はりぼてで採用されていないわけだわ。こんなの、「入門」でやらされたら無理です〜)

なんかかなり大掛かりな勉強になりそうな悪寒なので、Wikiのほうへ一時移動するか・・・

あーー！　わかったあぁぁ！！
これ、ビットだ！
二進数でビットが立ってる（1）ところが白。
そういうことかあぁぁぁぁぁぁぁぁぁぁぁぁぁ！！！！

わかったーー！　ばんざーい！　ばんざーい！！！

・・・・　　orz　　・・・・・・

おかしいじゃん！？
BIOSで0x12のモードにしてるんだから、これは16色モードのはずじゃない？？
なんでビットごとなの？　じゃ、赤とかほかの色出す時ってどーーーするの！？？？

クソったれ！　どうもわからん！
そんなわけで先祖返り。harib01gを引っ張り出してベタ実験じゃ！

void HariMain(void)

{

	char *p; /* pという変数は、BYTE [...]用の番地 */



	//	init_palette(); /* パレットを設定 */



	p = (char *) 0xa0000; /* 番地を代入 */



	//	boxfill8(p, 640, 8,  20,  20, 120, 120);

	//	boxfill8(p, 640, 8,  70,  50, 170, 150);

	//	boxfill8(p, 640, 8, 120,  80, 220, 180);



	int i;

	for ( i = 0; i <= 512; i=i++)

	  {

	    p[i] = 0xef;           // ← 値をいろいろ変えて実験！

	  }



	for (;;) {

		io_hlt();

	}

}

・・・・・・・　orz　・・・・・・・・・・

わっかんねぇ〜〜〜〜〜〜〜〜。
反応はしているんだが、どうも法則がつかめない。オイラはてっきり、
0xffを書き込めば真っ白に。0x6fを書けば1ドットごとのシマシマに
ってなるんだと思ってたが、どうも違うようだぞ？？？