Anyway if you are reading 0xA0000 in the first meg or in the 4th Gb, i think in both cases you will find the dos environment 1st meg replicated in the 4th GB so your assumption on "interlace" is probably wrong... dont think you will find the other"pages":)

but with a vesa call via an int you can map this 0xA0000 to anywhere in the lfb...

But you ll have to go 16b ring0 or dos prog, as I said.

But does it really work?
Can you really write on to of windows screen (windows, cursor...) without crashing everything?
I yes I see an interesting experiment: see if it overwrites the mouse cursor. Guess if it will work, because there are harware functions with a separate cursor bitmap i think, that gets displayed over all...
Posted on 2003-11-19 11:45:47 by HeLLoWorld
Ugh.

Haven't really looked at what mrgone is doing, but in the "bad old days" (no, they were NOT good), you would sometimes see (dirty) code setting up a #PF handler to emulate a LFB in VESA banked mode - good we don't have to use these tricks anymore, with nice APIs at our disposal.


even then you where you you can not write to a specific PHYSICAL addr can you?

Indeed you cannot, you will have to set up a linear mapping. Under win32, this would of course be done through the lowlevel API, not by messing with the page tables directly.

0xA0000 is the standard VGA memory physical addr, but nobody says the "real" framebuffer has to reside there - try to open your device manage in windows, look at your video card properties, and which resources it has allocated. My card has four different memory ranges, an IRQ, and two port ranges. If you want to program your card in dos/no-os, use VESA support. On win32, use one of the existing APIs.


you can make a dos prog (is it possible to call a dos prog from a win PE and come back?) (even a .com) that calls int0x10 vesa get info, to know the addr of lfb, but its physical so under win you dont know where it is; you can go ring0 to map it to physical? (i dunno jack about that) and then access it direcly with a zero based seg.

VESA is going to be emulated by the OS, so there's no guarantee you can do this. It's silly, too.


Or if you went in ring0, hey, who cares about dos progs? you just jump in 16b seg and call int!!

Ah yes, because it _is_ this easy. </sarcasm>. Takes quite some code to call 16bit rm code from 32bit pm. When running under an OS, you have to be extra careful. It's safe to assume VESA calls will reprogram the card chipset, so it's safe to assume this is a bad idea to do under an OS.


the only thing is they call vesa setmode before writing...

It's been a while since I messed with VESA, and even longer since I went through the specs. But iirc, the LFB address could be different for each mode (didn't ever see this happen, but I think it was allowed). Furthermore, why do you think windows emulation layer would report the real LFB address? Hint: it's possible running a lot of VESA apps in windowed mode.


Who would have thought you could do more things with the dos emulation system than with a win32 PE?

You can't. Dos emulation and DPMI virtualization just happen to take care of a lot of things for you. You can get very direct access to the screen with existing APIs, just not "hardware direct" - you don't need it, and it's not good practice to do under an OS.


for ex. you cant trash your bootsector by calling int0x13 bios sector write can you??

Under 9x, you can LOCK a drive. Under NT, I think this is disallowed - but if you run from a user account with administrative privileges, you have full access to your disk. Read up on the CreateFile API.


0xB0000 is the start of text mem under dos I think, or is it 0xB8000?

Neither. 0xB0000 is the physical address of the monochrome text display memory while 0xB80000 is for color - under 16bit dos, you'd be accessing 0xB000:0 and 0xB8000:0 ;-).


after all, who has 4Gb of mem? (ok, some will come up and say "me!", but I dont think motherboard support it.

Some people have more. Read up on the advanced windows versions and PSE+PAE.

Anyway, it's all fine and dandy messing around with this for learning purposes, to see how everything fits together in the win32 (and especially NT, since 9x is an uninteresting piece of shit) system, but I hope you realize it's worthless for "real code". Some info can be useful if you want to mess around with kernel design, but again, that's futile too - you'll never be able to compete with even linux.
Posted on 2003-11-19 11:55:31 by f0dder
First I would like to address that 64K limit. Did you download that DOS example? It shows you how to write to the 4 bitplanes 64K at a time. That should tell you something right there.

Ok Helloworld, actually you can have 4Gig ram these days. I can special order it here locally. Extended address mode allows something like 64 Tera bytes of virtual Ram in either 2Meg or 4Meg pages.
Consider the average Video screen. Most people operate in 800X600 pixel mode. That's only 480K x 4 bitplanes for color is still only 1,920,000,000 bytes of data. You could fit two of these in one single 4Meg Page of RAM.
B800:0000 in real mode is actual physical address B8000h and this is color "TEXT MODE" video buffer. B0000h is the old monochrome text mode buffer.
The reason the address is mapped to 800A0000h is do to the entry in the page directory. The processor translates that address to find that particular entry and I dare say without looking it would be something like this: 000A01E3h. The 1E3 is masked off the address and is bit information about the page such as bit7 is the (PS) page size bit.
You really need to read the Intel Pentium manual over and over again to get a grip on it. WindowsITlibrary.com is also a good source of information.
Posted on 2003-11-19 12:10:01 by mrgone
doh. seems like i still have a lot to learn.
(but hey even a god like you mrgone can write to me that

"
1,920,000,000 bytes of data. You could fit two of these in one single 4Meg

"

!!
okay, some ppl have 4gb of ram, but i d like to see someone with 1.9 Gb video card like you say ^_^

(just kidding, xcuse me)

btw what does it mean 480k *4bitplanes? theres no bitplanes in hicolor.
write 4bitplanes at a time ? modex? never bothered to learn about it . (should have maybe)





fodder:
"
sometimes see (dirty) code setting up a #PF handler to emulate a LFB in VESA banked mode - good we don't
have to use these tricks anymore, with nice APIs at our disposal.

"
win does exacly this if you ve got a video card not supporting lfb. its said in msdn at the ::lock section i think.


"
Ah yes, because it _is_ this easy. </sarcasm>. Takes quite some code to call 16bit rm code from 32bit pm. When
running under an OS, you have to be extra careful. It's safe to assume VESA calls will reprogram the card
chipset , so it's safe to assume this is a bad idea to do under an OS.

"

in fact i was meaning "jump into a 16b seg and disable protection... ofcourse i would maybe have some troubles returnin under win...:)

"
Furthermore, why do you think windows emulation layer would report the real LFB address?
Hint: it's possible running a lot of VESA apps in windowed mode.

"

Okay. forgot vesa was emulated. I understand. But it doesnt prove anythin. maybe these are vesa1.2 apps only(writes to A0000+setbank) or maybe win remaps the linear addr of lfb(that the prog uses) to some buffer, and the actual lfb (physical) still contains what you see on screen, windows, desktop, etc, and of course the window of your emulated prog. am I wrong?argh. yes i am. that case is possible, but it means the lfb returned by int is not the real, even if there is only one real.

"

Neither. 0xB0000 is the physical address of the monochrome text display memory while 0xB80000 is for color -
under 16bit dos, you'd be accessing 0xB000:0 and 0xB8000:0 ;-).

"

hmmm... what i said is right, but YOU have too much zeros, isnt it?


"
but I hope you realize it's worthless for "real code".

"

Of course I realize. I m just curious.
Posted on 2003-11-19 12:59:22 by HeLLoWorld
I worship the real God of Abraham,Isaac and Jacob. After what He can do I could never call myself "smart" only humble and eager to learn like a little child.
Anyway API's are certainly the way to go but there is always something left out. That's why nuts and bolts or the basics aid in programming I beleive.
Take for instance a hex editor I am working on would not allow me to backspace then insert and edited byte if the file was larger than 6K. Under 6K no problem. I call this a "bug". I worked that hard to get to that point I don't want to rewrite the whole program so nuts and bolts help me decipher what is wrong and perhaps give the API's a little nudge.
Posted on 2003-11-19 14:42:23 by mrgone
to be honest i didnt understand your post , though i read it several times(but i laughed a lot)javascript:smilie(':grin:')
javascript:smilie(':grin:')
whats nuts and bolt and nudge and are you serious?
Posted on 2003-11-19 15:10:50 by HeLLoWorld