On Sunday 01 May 2005 18:00, Viktor Pracht wrote: > Hi all, > > I thought a bit about the VGA controller, and here are the results: > > The design goal is to implement a VGA controller with as little hardware as > possible. Since this won't be a standalone controller, we should use the > existing 3D pipeline, video controller and RAM. The most obviously useful > part is the video controller: if we somehow manage to get the VGA image > into a 32 bpp framebuffer, then we don't have to worry about timings or any > real-time aspects at all (we're doing VGA for compatibility, not for > speed). The second obvious part is the RAM, which should be used as VGA RAM > and as framebuffer for the video controller. With 256 KB of VGA RAM + > 800*600*4 bytes of framebuffer, we're using less than 2% of the available > 128MB.
Erm, last time I programmed VGA it was 640x480 max. Did something change? Or are we talking about VESA here? It's a minor point, but just to avoid trouble...:-). > The attached files are an abstract C++ class implementing the hardware > only. Subclasses are supposed to implement the methods write_3d() and > draw(). As minimum functionality, write_3d() must remember the video > settings (framebuffer position and dimensions etc.) and draw() must update > the real output with the contents of the framebuffer. Also, the subclasses > are supposed to initialize the RAM with something useful. The four entry > points CODE_* should be filled with JUMP instructions to the actual code. But how do we initialise all those tables in hardware? Where do we get 128 MB of lookup table data before the system has even booted? Lourens
pgpdsHcdR6cSD.pgp
Description: PGP signature
_______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
