ザビタン開発日記
2009 | 01
2008 | 01 | 02 | 06 | 12
2007 | 10 | 11 | 12
11月 25 (日曜日) 2007
15:44
隣のインド人・・・なにしてる〜の?
 
あっれえぇぇぇぇ??



おっかしいなぁ。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]という指定って・・・











 
name: @Guest  Comment:
10:28
教えて アルムの森の木よ
 
やぁ〜んば らぇあぇあ〜♪ やぁ〜んば らぇあぇあ〜♪



はりぼてでは起動時、VESAをちょこっとだけ検査して切り替えてるよね?

いろいろと調べてみたら、VESAはもっといろいろな情報を返してくるらしいぞ?



そーゆーのを表示してみたいので古いはりぼてを弄ってたんだけど、

大問題。qemuって、BIOSでの文字列表示とかがヤワらしくてまともに

表示してくれないんだよなぁ・・・

(しかもアセンブラでしょ? なんかツライ・・・)



そこでザビたんですよ!



考えてみれば、32bitだわ日本語は表示できるわのザビたんだけど、

それでも起動はMS-DOS並みに早いよね? (OSASKにゃ勝てないけど・・・(^^; )

だったら、コイツの起動時(16bit時)にそういう処理を搭載して、

コマンドかなんかで表示させたってそう大差ないじゃない?



いや大有り。なんたってプログラムが楽じゃんねぇ??(^^



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



つーーーわけで、vesaコマンド(vesaの各種情報を表示する)の

搭載開始〜



ふむふむ・・・

はりぼてではasmhead.nas内で起動時にVESA(VBE)の検査をしてるよね?

ここで、2.0サポートかそうでないかの判断だけしてジャンプしちゃってるけど、

実はこの段階でいろいろな情報がもたらされているらしい。

その情報はES:DIが指し示すアドレスに書き込まれるらしい。

はりぼてでもこれはちゃんと行っているみたい。

ええと・・・ようするに、0x9000番地に情報が書き込まれているんだね?

あれ〜????

メモリマップで見る限り、ここはその後廃墟扱いで使われていないの??

・・・っということは、ここにデータが残っている???

こりゃシメた!!!!

さっそくここいらヘンを読み込むapiかコマンドを乗せてみよう。

・・・おっと! その前に!

VESAからどんな情報がもたらされるのか、ここらあたりにまとめておくか・・・

 
name: @Guest  Comment:
Referer  (1)
00:23
ベサメムーチョ
 
・・・ところで、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についてオベンキョしてみることにしよう。
 
name: @Guest  Comment:
11月 24 (土曜日) 2007
23:16
僕らは6人!六つ子だい!
 
・・・おっそおぉぉぉぉぉ!!!!!!



まいったなぁ〜。

もともとVGAに対応したかった最大の理由は、オイラが実機実験に

使っている劇古ノート(DynaBook GT475)上で320x200を表示させると

上と下が欠けちゃってシオシオだったから。(液晶だとこうなるんだよね・・・)

VGAに対応すればナンボかカコイイ感じになるかなぁと思ったのだが・・・



フォントの表示を半分くらい完成させたんだけど(harib02d相当)

オイラ程度の手法やアルゴリズムだと、このノートじゃ猛烈に

遅いことが判明した・・・



ただでさえ面倒で煩雑なVGA。がんばってこれに対応しても、

こうも遅いと・・・・

(なんか一気にやる気がしぼんでしまった・・・)



ちょっとしばらく考えてみよう。
 
name: @Guest  Comment:
20:39
V V V!ビクトリーー!
 
うっひょおぉぉ!

でけたでけた〜!!!!!



harib01h だけど、bootpac側は無改造で表示できたぞーー!

boxfil関数、VGA対応〜!!!

よーし! この調子で他の関数を書き換えれば・・・いけるかな!??



(まあもっとも、Sheet周りは今から大変そうなのが予測できるけどね・・・(^^;  )

 
name: @Guest  Comment:
13:03
ラッチ(あぁぁぁ!み・・・南ちゃんやぁぁぁ!)
 
VGAのラッチがわからずにハマっとるオイラです〜。



ラッチ! ラッチ! ここに ラッチ!

あ〜な〜た〜か〜ら〜♪

らぁっち!





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

 
name: @Guest  Comment:
11月 23 (金曜日) 2007
17:06
今週のハマり所メカ、発進!
 
ポチっとな!??



ここでヘコヘコと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にならないかららしい。なので、左シフトと同じ感覚で使うとオイラのようにハマりまくることがよくあるからだそうだ。もちろんそれを想定・過程した上でなら問題ないのだろうが・・・。参考までに。



 
name: @Guest  Comment:
11月 22 (木曜日) 2007
09:22
ミキと言ってもハウスじゃない
 
ふむ・・・・

あちこち調べていたのですが、どうもVGA画面つーのは今までみたいに

VRAMに値をポンで描画できるわけではないようです。

どうも、プルーンプレーンというものがいくつかあって、

それが色やら明るさやら?を個別に担当しているような感じ?



オイラが実験で悩んでいた、「ビットがドット」というのも

間違いではないようですが、ほかのプレーンにまた別のデータを

書き込むことで初めて色が出る・・・どうもそんな感じらしいです。



これに関すると思われる資料はもちろんOS-Wiki内で見つけてはいたのですが、

これが難しくてわからない・・・orz



もうすこしいろいろと調べてみないと・・・

(まだ原理や理屈が把握できていないのだ)



・・・たしかにこりゃややこしいよね?(^^;

(はりぼてで採用されていないわけだわ。こんなの、「入門」でやらされたら無理です〜)



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

 
name: @Guest  Comment:
11月 21 (水曜日) 2007
01:32
一点二点三点と。その先七転八倒(いつものパターンにゃ!)
 
あーー! わかったあぁぁ!!

これ、ビットだ!

二進数でビットが立ってる(1)ところが白。

そういうことかあぁぁぁぁぁぁぁぁぁぁぁぁぁ!!!!



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



・・・・  orz  ・・・・・・



おかしいじゃん!?

BIOSで0x12のモードにしてるんだから、これは16色モードのはずじゃない??

なんでビットごとなの? じゃ、赤とかほかの色出す時ってどーーーするの!???
 
name: @Guest  Comment:
Referer  (1)
00:35
過去と未来と昨日と今日を
 
クソったれ! どうもわからん!

そんなわけで先祖返り。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ドットごとのシマシマに

ってなるんだと思ってたが、どうも違うようだぞ???

 
name: @Guest  Comment:
Referer  (1)
1 2 3 4 (5) 6 7 8 9 10 11 12 13 14 » 

PopnupBlog V3 Denali created by Bluemoon inc.