.globl _start
_start:
movl $0xb800,%eax
movl $0x411f,(%eax)
loop: jmp loop

The above is my code for writng into Video Memory for displaying a character A. However The second line of the code where I am trying to
write 0x411f to the memory 0xb800 pointed by eax causes sigfault.

This is how i have created the hex code
as -o video.o video.s
ld video.o -o video
./video

help appreciated.

Hi -

There's this little thing called "protected mode"

If you want to write to video memory, a preferred approach is to use a higher-level library like OpenGL or SDL (on Linux), or DirectX (on Windows):

http://www.libsdl.org/

If you want to simply "talk to the metal", communicating directly with physical hardware addresses and hardware interrupts, then you need an OS that works in "real mode" ... like DOS.

1 members found this post helpful.

i'm stuck the same as Saptarshi4031...

i discovered the real/protected mode thing this past weekend concerning linux, and so far it still does not really satisfy as an answer that we should use higher level language to code graphics...

i mean, why cant i just get simple graphics using assembly?
Sure protected mode locks me out of the video memory/buffer area, but how can programs like dosbox or dosemu simulate real mode environments and run other programs like ketman which codes assembly on the spot to access the video buffer 0xB800 and it works just fine? but i myself cant seem to turn on that little real mode switch and have fun?

And still what would be involved in these two thing? 1.) assembly graphics 2.) in protected mode?

DosBox is an emulator, it does not run on the real hardware, but interface an emulated one of something else (SDL?). And nothing prevent you from doing graphics in assembly, you just need to link it to a library able to interface with the real hardware or see how DirectFB does it. My guess is that it will require you to write in the /dev/fb0 file for the frame buffer or link (and use) XLib or XCB for X11 (graphical server).

Accessing the hardware directly is a major security flaw, it is what drivers are all about, not userland applications. You know, it is why doing void main() { unsigned short i=1; while (i) *i = 0; } does not crash Linux.

Assembly is as nice as you want to make it, but as others already pointed out, if every program could do whatever it wishes with the hardware then linux wouldn't differ from any other OS in which regards security and stability. That's why we use OSes nowadays: they are supposed to talk to the hardware for you (or your program). If you want to get direct access to *real* hardware, then you are looking at the wrong direction. You should rather be programming a kernel module and make your program interface with that, just like graphic drivers do in X, vhba, fuse, virtualbox, qemu, etc.

You can use assembly there if that's your call, good luck making it portable then.

Dosbox and dosemu are (or use) a VM. So, when you use assembly inside that jail you are not assembling instructions to real hardware, but instead to emulated hardware.

You can't just "change to real mode" and then continue working as usual in protected mode on the same hardware.