Change framebuffer address of standard VGA modes (0x13)

[quadrant]

Is it possible to change the address of the framebuffer when using standard VGA modes. (I'm specifically interested in mode 0x13). From the wiki:

For standard VGA video modes the video memory will be at address 0xA0000 for EGA/VGA video modes and 0xB8000 for CGA and text modes.

Context:
I am currently using mode 0x13 to render graphics. I want to make changes to the framebuffer with user-space code. The address of the standard framebuffer (0xA0000) is outside what is accessible to user-space.
1) One option is to add the region (0xA0000 : 0xA0000 + 320x200) to the addresses the user is allowed to access (memory map).
2) Another option is to have the VGA access a framebuffer address specified by the user

My current approach is to make changes to a buffer created in user-space, and then use a system call to copy its contents to the VGA's framebuffer. The context switch and memory copy makes this approach slow. I wish to skip this step, and have the VGA use the user-space buffer for display...(Theoretically, this would mean one system call once to specify the buffer location, instead of a system call and memory copy everytime I want to update the display).

[iansjack]

What's your objection to option 1?

[rdos]

Provided you use paging, it shouldn't be a problem to map the VGA buffer to user space. OTOH, SVGA defines a way to put the framebuffer outside of the normal area and above 1MB. That's what you want to look at.

[quadrant]

What's your objection to option 1?

There's no security concerns with giving the user write access to "IO space"? Or is it okay in this case because it is a very specific region where we know it will only be used for display (no execution)...

[quadrant]

@rdos Thanks. I do use paging, just wasn't sure about giving the user write permission to the area. I was under the impression that they shouldn't have access to the "IO space"...

[iansjack]

What's your objection to option 1?

There's no security concerns with giving the user write access to "IO space"? Or is it okay in this case because it is a very specific region where we know it will only be used for display (no execution)...

It's memory rather than I/O space (which normally refers to ports). But the whole object of the exercise is to give user programs access to that memory region....

[Octocontrabass]

Is it possible to change the address of the framebuffer when using standard VGA modes.

With paging, the address can be pretty much whatever you want.

There's no security concerns with giving the user write access to "IO space"?

In general, you should make sure that any program being given direct access to hardware is trusted to access that hardware correctly, and has access only to the necessary hardware.

For the VGA frame buffer specifically, it's ordinary RAM (in mode 0x13) that happens to be displayed on the screen.

[mallard]

OTOH, SVGA defines a way to put the framebuffer outside of the normal area and above 1MB. That's what you want to look at.

"SVGA" is a just a generic term for better-than-VGA graphics adaptors, mostly used in the 1990s. It is not a standard/specification and therefore cannot "define" anything. Some/most SVGA graphics adaptors may have the ability to remap the VGA framebuffer (it's highly likely that any card that supports a linear framebuffer for high-resolution modes can do this), but the method of achieving it will be entirely adaptor/vendor-specific.

If by "SVGA" you mean "VBE" then I wouldn't be at all surprised to see some VBE compatible adaptors report a 320x200 8bpp with a high framebuffer address, but whether it's a simple relocation of mode 13h or not is a different matter (mixing VBE with VGA register access is not allowed unless ModeAttributes but D5 is set).

[rdos]

OTOH, SVGA defines a way to put the framebuffer outside of the normal area and above 1MB. That's what you want to look at.

"SVGA" is a just a generic term for better-than-VGA graphics adaptors, mostly used in the 1990s. It is not a standard/specification and therefore cannot "define" anything. Some/most SVGA graphics adaptors may have the ability to remap the VGA framebuffer (it's highly likely that any card that supports a linear framebuffer for high-resolution modes can do this), but the method of achieving it will be entirely adaptor/vendor-specific.

If by "SVGA" you mean "VBE" then I wouldn't be at all surprised to see some VBE compatible adaptors report a 320x200 8bpp with a high framebuffer address, but whether it's a simple relocation of mode 13h or not is a different matter (mixing VBE with VGA register access is not allowed unless ModeAttributes but D5 is set).

Yes, I mean VBE. Basically all graphics cards manufactured during the last few decenniums have VBE, and those that don't deliver the LFB through EFI boot instead. So I don't think it's useful to write drivers for ancient VGA modes mapped to the A000 area.

[quadrant]

Thank you everyone for your input. Will go ahead and use option 1.

[quadrant]

I've come across a problem

The framebuffer is size 64000 bytes. This is slightly less than what is needed to neatly page-align it. Assuming a page size of 4096 bytes, I would need to use 16 pages to map the buffer ( 16 * 4096 = 65536).

So the user will be able to write to physical addresses:
. 0xA0000 .. 0xA0000 + 64000 // OK
. 0xA0000 + 64000 .. 0xA0000 + 65536 // PROBLEM

Since I am not sure what other IO devices are using the RAM in this region, I would prefer for the user to have access only to the 64000 bytes associated with the framebuffer (and not the 65536 granted by page table mapping).

How does one work around this? Do I just cross my fingers and hope that
a) the trailing 1536 do nothing important
b) the user program will behave and stick to using 64000

[nullplan]

There is nothing else in this range. The entire range is reserved for the framebuffer. Writing beyond the end of the frame buffer does nothing.

[quadrant]

There is nothing else in this range. The entire range is reserved for the framebuffer. Writing beyond the end of the frame buffer does nothing.

Ah, thanks! Relief to hear .

Looked around, and found this table from the wiki of the region's use. Leaving it here for anyone who might stumble upon this post. The sections in the region align nicely with 4096 byte pages - which I'm sure is no coincidence.

low_mmap.png (11.22 KiB) Viewed 14814 times

[nullplan]

The sections in the region align nicely with 4096 byte pages - which I'm sure is no coincidence.

It certainly isn't. Most memory chips have a size that is an exact power of two in size. Other sizes you usually only get by adding multiple chips. This is simply because that way, if you have an address bus, the size of the chip is set by the size of the address bus of the chip, and you always have a valid address on it (example, if you have a 1024 byte ROM, it has ten address lines). Also, system bus design becomes a whole lot simpler if you naturally align your memory chips (so your 1024 byte ROM goes on a 1024 byte boundary), because that means the low address lines are just passed through to the ROM, and the high address lines can be used to decide which chip is selected. Nobody needs to do arithmetic on the addresses (like adding or subtracting offsets).

So most memory chips, and most register files, and most peripherals in general will have a size that is a power of two, and will be aligned to a power of two, and the only constraint needed to play well with 4k-paging is that the exponent be at least 12, which isn't hard for a video card, which needs tons of memory. At work I have three monitors in Full-HD resolution running with separate frame buffers. Try to calculate the memory requirements of that alone, never mind any back buffers the OS might have.

For ease of design, most system buses in the past were designed to use the high address lines to determine the chips to be selected. So unless they take more than the top twenty lines in a 32-bit system, everything will be nicely aligned for 4k-paging. And they won't because such large decoders would be expensive.