OSDev.org

Hi guys,

This is my first post in this forum, although I visited it for a while now.

Now, I'm really sorry to make my first question one over the LFB address and I know that there are many other posts here with this topic. After reading those, I still can't get it to work.

So here we go:
What I've done before:
I picked myself a nice SVGA video mode (1280x1024 64K), checked all it's stats and tried it with it's native address 0xA0000.

It perfectly draws the first 51 and somthing lines (64KB limit).

So now I 'or'ed bit 14 when setting the videomode like this:
and after checking the video mode stats it gave me LINEAR ADDRESS = 0x6000000 (yes, linear addressing is supported on this mode)

So here's where I am right now.

I already tried making a gdt sector with its origin at 0x6000000 and sent some bytes like this:
So the final question is: How do I get to write at 0x6000000?

I have already gone through the vesa docs, but I found nothing helpfull.
Do I do it with paging, virtual addressing or other tricks?
Is this type of high memory folded to a lower address like accessing > 1 MB without A20?

I would appreciate any help
Thanks in advice

Hi,

wndproc wrote:I already tried making a gdt sector with its origin at 0x6000000 and sent some bytes like this:

Code: Select all

mov ax, 24
mov es, ax
mov byte [es:0h], 4h
mov byte [es:1h], 4h
mov byte [es:2h], 4h
mov byte [es:3h], 4h

That should work (if you're not using paging), although in this case it's often easier to have a GDT selector with it's origin at 0x00000000 and do things like "mov byte [0x6000000],0x04".

If you are using paging, then you need to map the physical addresses (from the start of the display memory (e.g. 0x6000000) to the end of the display memory) to linear addresses *somewhere*, and then write your graphics data to *somewhere*. In this case *somewhere* could be in the kernel's part of the address space, or in the video card device driver's own private address space, or anywhere else.

wndproc wrote:Is this type of high memory folded to a lower address like accessing > 1 MB without A20?

Yes. All physical addresses used by the CPU are effected by A20.

In your case, with A20 disabled you'd still be able to access the first 1 MB of display memory at 0x60000000. You won't be able to access the second 1 MB area of display memory though, as the CPU would talk to the first 1 MB of display memory instead. The same problem would happen for every "odd" MB in the physical address space. For example, if you try to access display memory from 0x60100000 to 0x601FFFFF you'd actually access display memory from 0x60000000 to 0x600FFFFF, if you try to access display memory from 0x60300000 to 0x603FFFFF you'd actually access display memory from 0x60200000 to 0x602FFFFF, if you try to access RAM from 0x00300000 to 0x003FFFFF you'd actually access RAM from 0x00200000 to 0x002FFFFF, etc.


Cheers,

Brendan

Thanks for the reply,

after you told me that it should work I double and triple checked my code. The problem was in my function PrintDword when reading the linear address. The actual address was 0xF8000000. Im feelin so stupid

Oh and thank you for that even odd thing with A20. I was also not sure there before.

Brendan wrote: In your case, with A20 disabled you'd still be able to access the first 1 MB of display memory at 0x60000000. You won't be able to access the second 1 MB area of display memory though, as the CPU would talk to the first 1 MB of display memory instead. The same problem would happen for every "odd" MB in the physical address space. For example, if you try to access display memory from 0x60100000 to 0x601FFFFF you'd actually access display memory from 0x60000000 to 0x600FFFFF, if you try to access display memory from 0x60300000 to 0x603FFFFF you'd actually access display memory from 0x60200000 to 0x602FFFFF, if you try to access RAM from 0x00300000 to 0x003FFFFF you'd actually access RAM from 0x00200000 to 0x002FFFFF, etc.

you need 2,621,440 bytes for that video mode, but you could make it work without enabling A20, just write the first 409 lines to 0mb, then the next starting at 2mb, then the last 206 lines to 4mb,

when the display raster hits the end of line 409 you reprogram the video controller's source address to 1mb (now displaying from 1mb + 1mb = 2mb), when you hit line 818 you reprogram it again to 2mb, then on vertical blank you reset it to 0mb and do it again.

easy!

PS:
wndproc, dont listen to me, this idea is totally absurd and most likely wouldnt work on half of today's video controllers.

I could try it. Just to insure I understand it enough to beeing able to do it logicaly unlogical.

wndproc wrote:I could try it. Just to insure I understand it enough to beeing able to do it logicaly unlogical.

I have a ticket to coding hell for you

personally, I'd just create overlays and map them to 2MB and 4MB. Besides, reprogramming the starting address does not normally change the current sequencer offsets.

jop, sure...

I will get back to that, as soon as I dig into vga a bit deeper. For now I'm just fine drawing my stuff by a simple mov [lfb_address], pixel_stuff

Combuster wrote:

wndproc wrote:I could try it. Just to insure I understand it enough to beeing able to do it logicaly unlogical.

I have a ticket to coding hell for you

personally, I'd just create overlays and map them to 2MB and 4MB. Besides, reprogramming the starting address does not normally change the current sequencer offsets.

oh, right, EGA/VGA latches the counter on display start or vblank... its been a while
back then I got around it by reprogramming the scanline pitch on the fly, but I'm not sure that even a new card would handle a scanline pitch of 1mb + 1280*16bit

and I wouldnt bet that current video controllers would even handle scanline reprogramming on the fly. I'm not sure they still support the 2nd video "window".

even textmode emulation is a bit weird on my nvidia, I got some weird bug using mplayer with libaa which caused the video display to go wild just by updating characters !!!


I also tried displaying a picture in 97 by reprogramming palette color 0 on the fly, worked on S3s and Cirrus Logics but when I tried on a matrox the ramdac only updated 1 color component (R, G, and B) once every 8 characters. spoiled my fun