VGA Programming

Started by
3 comments, last by rents85 12 years, 9 months ago
[color="#1C2837"]Hi! I want to develop a VGA graphics driver (for Linux(Ubuntu)) with support for the basic primitives such as putpixel, drawline, fillrect and bitblt. I want to do it in protected mode.
[color="#1C2837"]I´ve been googling for a week and the following four links are the best I have found:

http://www.brackeen....vga/basics.html
http://www.cs.ucla.edu/~kohler/class/04f-aos/ref/hardware/ibm-vga.txt
http://bos.asmhacker...sing%20bios.htm

Unfortunately, the first one uses a BIOS call so I cannot use it. The second link has lots of information on the VGA registers but no examples showing how to make them work together. The third example is a example to switch in 13h mode but i've tried it and nothing happened. Can you guys give me a hint? Thanks in advance!

--Vincenzo
Advertisement
What exactly are you trying to do? Replace a hardware driver with your own interface? Build a layer that calls standard interfaces that you can use for hardware-independent graphics output?

Wielder of the Sacred Wands
[Work - ArenaNet] [Epoch Language] [Scribblings]


[color="#1C2837"]for Linux(Ubuntu) ... I want to do it in protected mode. ... [color="#1C2837"]The third example is a example to switch in 13h mode but i've tried it and nothing happened.

This sounds like a post from the early 1990s, not for 2011.


The things you mention only work if you are the only program running on the hardware. This was the case back in the days of DOS, but has not been the case for over 15 years. Modern operating systems hide the details of the hardware and give each process a virtual machine to run on, with an API for hardware such as graphics, input, storage, and more.

The modern OS coordinates access to various hardware resources, including video memory, or else the various programs would end up stomping on each other as they attempted to access various hardware. Imagine the corruption that would happen with multiple programs trying to draw in different video modes, or multiple programs sending data to disk.

The days when a single program was the only program are long gone.



Your operating system is already running in protected mode. It must do so to allow each process their own virtual memory area. Switching to protected mode was something you did in the late 1980s and early 1990s when DOS thought you were the only program. Linux has always been a multiprocessing OS, and has always been in protected mode on the x86 family.

Attempting to switch to protected mode from an app running on that machine would crash the hardware.

Fortunately the OS can trap your attempt to re-enter protected mode and kill your program.




VGA Mode 13h is also a relic of that time. When you were coding directly to the hardware it allowed a somewhat easier way to access the VGA framebuffer, at the cost of being slower and abandoning 3/4 of the available video memory. Even when it was popular it was only generally used as a stepping-stone for beginners until they figured out how work with memory windows.

The modern operating systems intentionally restrict your access to those memory blocks and ports so that one app doesn't stomp on another.

Just like protected mode, it is a good thing the OS does this since applications would stomp on each other and quickly crash the system.
You only have one option in Linux to work with the old VGA modes and DOS era game programming: Get DOSBox, and run you executables there.

Otherwise, set yourself up a Win 3.1/Win95/Win98 machine. If i remember correctly, all of those will still let you screw things up if you want. Its been a long time, though. You'll also need an old Real Mode compiler, I always preferred Borland's Turbo C/C++. Another choice is DJGPP which will let you compile 32-bit protected mode programs as well as 16bit Real Mode. That will let you work with extended memory regions and SVGA stuff.

As cool as all of that was, to be that close to what you were doing it isn't really reasonable nowadays. Instead, just choose an API that will give you access to to a "frame buffer" Like Direct Draw/SDL Surfaces, or Direct3D/OpenGL textures. Once you have that its just as old school: draw your pixels to an offscreen buffer and copy those to whatever your API choice is using to represent your "frame buffer"(this is probably just generating a texture from the raw pixel data in OGL/D3D)

I suppose I should have left out all the DirectX stuff since you're on Linux, but you get the idea. I miss the old days, too, but really, there was a lot going on behind the scenes then too, it only seems simple because all we had to do was load some registers and "int 13h", now you just have to call a new blackbox entry-point, whichever you choose.
Thank you all for the replies. I'm very newbye in the graphics field. The original goal for me was develop a GUI for VxWorks but i've never found anything about that (only propietary library like [font=arial, verdana, sans-serif]http://www.bsdi.com/products/graphics/). [/font][font=arial, verdana, sans-serif]Then i've thought that first i can try with Linux (that are more popular) and after porting it in VxWorks. [/font]

This topic is closed to new replies.

Advertisement