[solved] VGA mode "13h" by registers

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
User avatar
mystran
Member
Member
Posts: 670
Joined: Thu Mar 08, 2007 11:08 am

[solved] VGA mode "13h" by registers

Post by mystran »

Mmmh.. so I thought I'd switch to some sort of graphics mode.. so I tried getting to the 320x200x256 VGA mode... but I'd love to do this without involving teh BIOS.. and for some reason I fail to get in there, even if I seem to do it all more or less the same as couple of other sources (svgalib, xorg..) so I guess I just fail to figure out something in there..

So far I've managed to get couple of interesting things happen in QEMU: 1280 pixels wide screen, which is normal 80x25 text mode but with each pixel twice as wide, and mm.. completely black screen.. that's the most promising thing.

I think I'm setting all the sequencer stuff, all CRTCs (copied from xorg then manually doublechecked for the best of my ability), the misc register, attributes 0x10,0x12,0x13,0x14 then graphics 5,6,7,8...

I'm also reprogramming my palette (and that works even without the mode switching) then clearing the screen (at 0xa0000) with white, so mm.. I should be getting something other than black.

Any suggestions where the problem might be?

[edit] Duh, also ment to say that if somebody has a straightforward listing of port-accesses for setting a given mode, please gimme... :D All the sources I can find have couple of levels of abstraction on top of the hardware access so they are kinda hard to read..
Last edited by mystran on Sun Dec 09, 2007 6:22 pm, edited 1 time in total.
The real problem with goto is not with the control transfer, but with environments. Properly tail-recursive closures get both right.
Top
User avatar
mystran
Member
Member
Posts: 670
Joined: Thu Mar 08, 2007 11:08 am

Post by mystran »

Ok, I just spent 'bout 12 hours banging my head to the wall, until I realized that if one has address/data IO register pairs, and one uses 16-bit accesses to write to them, then on little endian machines (like teh PC) you does not write:

out16_p(port, (address << 8 ) | data)

Instead, one writes:

out16_p(port, (data << 8 ) | address)

And when one realizes such a simple truth about process byte ordering with multi-byte IO access, then even the video graphics array starts behaving..

And I thought I knew how to program... :P
The real problem with goto is not with the control transfer, but with environments. Properly tail-recursive closures get both right.
Top
jal
Member
Member
Posts: 1385
Joined: Wed Oct 31, 2007 9:09 am

Post by jal »

mystran wrote:then on little endian machines (like teh PC) you does not write:

out16_p(port, (address << 8 ) | data)

Instead, one writes:

out16_p(port, (data << 8 ) | address)
Congratulations on this insight :). Now you must be banging your head for another 12 hours in realization :)). For me, this is one of the reasons I like little endian: if it's further into memory, it goes higher in the value :).


JAL
Top
Post Reply

Return to “OS Development”