+++ /dev/null
-Title: INTRODUCTION TO MODE X (XINTRO.TXT)\r
-\r
-Version: 1.8\r
-\r
-Author: Robert Schmidt <robert@stud.unit.no>\r
-\r
-Copyright: (C) 1993 of Ztiff Zox Softwear - refer to Status below.\r
-\r
-Last revision: 25-Nov-93\r
-\r
-Figures: 1. M13ORG - memory organization in mode 13h\r
- 2. MXORG - memory organization in unchained modes\r
-\r
- The figures are available both as 640x480x16 bitmaps\r
- (in GIF format), and as 7-bit ASCII text (ASC) files.\r
-\r
-C sources: 1. LIB.C v1.2 - simple graphics library for planar,\r
- 256-color modes - optionally self-testing.\r
-\r
- Excerpts from the source(s) appear in this article.\r
- Whenever there are conflicts, the external source file(s)\r
- are correct (or, at least, newest), _not_ the excerpts\r
- provided here.\r
-\r
-Status: This article, its associated figures and source listings\r
- named above, are all donated to the public domain.\r
- Do with it whatever you like, but give credit where\r
- credit is due. I would prefer it if this archive was\r
- distributed in its entirety, including the files\r
- mentioned above.\r
-\r
- The standard disclaimer applies.\r
-\r
-Index: 0. ABSTRACT\r
- 1. INTRODUCTION TO THE VGA AND ITS 256-COLOR MODE\r
- 2. GETTING MORE PAGES AND PUTTING YOUR FIRST PIXEL\r
- 3. THE ROAD FROM HERE\r
- 4. BOOKS ON THE SUBJECT\r
- 5. BYE - FOR NOW\r
-\r
-\r
-0. ABSTRACT\r
-\r
-This text gives a fairly basic, yet technical, explanation to what, why\r
-and how Mode X is. It first tries to explain the layout of the VGA\r
-memory and the shortcomings of the standard 320x200 256-color mode,\r
-then gives instructions on how one can progress from mode 13h to a\r
-multipage, planar 320x200 256-color mode, and from there to the\r
-quasi-standard 320x240 mode, known as Mode X.\r
-\r
-A little experience in programming the standard VGA mode 13h\r
-(320x200 in 256 colors) is assumed. Likewise a good understanding of\r
-hexadecimal notation and the concepts of segments and I/O ports is\r
-assumed. Keep a VGA reference handy, which at least should have\r
-definitions of the VGA registers at bit level.\r
-\r
-Throughout the article, a simple graphics library for unchained (planar)\r
-256-color modes is developed. The library supports the 320x200 and\r
-320x240 modes, active and visible pages, and writing and reading\r
-individual pixels.\r
-\r
-\r
-1. INTRODUCTION TO THE VGA AND ITS 256-COLOR MODE\r
-\r
-Since its first appearance on the motherboards of the IBM PS/2 50, 60\r
-and 80 models in 1987, the Video Graphics Array has been the de facto\r
-standard piece of graphics hardware for IBM and compatible personal\r
-computers. The abbreviation, VGA, was to most people synonymous with\r
-acceptable resolution (640x480 pixels), and a stunning rainbow of colors\r
-(256 from a palette of 262,144), at least compared to the rather gory\r
-CGA and EGA cards.\r
-\r
-Sadly, to use 256 colors, the VGA BIOS limited the users to 320x200\r
-pixels, i.e. the well-known mode 13h. This mode has one good and one\r
-bad asset. The good one is that each one of the 64,000 pixels is easily\r
-addressable in the 64 Kb video memory segment at 0A000h. Simply calculate\r
-the offset using this formula:\r
-\r
-offset = (y * 320) + x;\r
-\r
-Set the byte at this address (0A000h:offset) to the color you want, and\r
-the pixel is there. Reading a pixel is just as simple: just read the\r
-corresponding byte. This was heaven, compared to the havoc of planes and\r
-masking registers needed in 16-color modes. Suddenly, the distance from a\r
-graphics algorithm on paper to an implemented graphics routine in assembly\r
-was cut down to a fraction. The results were impressively fast, too!\r
-\r
-The bad asset is that mode 13h is also limited to only one page, i.e.\r
-the VGA can hold only one screenful at any one time (plus 1536 pixels, or\r
-about four lines). Most 16-color modes let the VGA hold more than one page,\r
-and this enables you to show one of the pages to the user, while drawing on\r
-another page in the meantime. Page flipping is an important concept in making\r
-flicker free animations. Nice looking and smooth scrolling is also almost\r
-impossible in mode 13h using plain VGA hardware.\r
-\r
-Now, the alert reader might say: "Hold on a minute! If mode 13h enables\r
-only one page, this means that there is memory for only one page. But I\r
-know for a fact that all VGAs have at least 256 Kb RAM, and one 320x200\r
-256-color page should consume only 320*200=64000 bytes, which is less\r
-than 64 Kb. A standard VGA should room a little more than four 320x200\r
-pages!" Quite correct, and to see how the BIOS puts this limitation on\r
-mode 13h, I'll elaborate a little on the memory organization of the VGA.\r
-\r
-The memory is separated into four bit planes. The reason for this stems\r
-from the EGA, where graphics modes were 16-color. Using bit planes, the\r
-designers chose to let each pixel on screen be addressable by a single\r
-bit in a single byte in the video segment. Assuming the palette has\r
-not been modified from the default, each plane represent one of the EGA\r
-primary colors: red, green, blue and intensity. When modifying the bit\r
-representing a pixel, the Write Plane Enable register is set to the\r
-wanted color. Reading is more complex and slower, since you can\r
-only read from a single plane at a time, by setting the Read Plane\r
-Select register. Now, since each address in the video segment can\r
-access 8 pixels, and there are 64 Kb addresses, 8 * 65,536 = 524,288\r
-16-color pixels can be accessed. In a 320x200 16-color mode, this makes\r
-for about 8 (524,288/(320*200)) pages, in 640x480 you get nearly 2\r
-(524,288/(640*480)) pages.\r
-\r
-In a 256-color mode, the picture changes subtly. The designers decided\r
-to fix the number of bit planes to 4, so extending the logic above to 8\r
-planes and 256 colors does not work. Instead, one of their goals was to\r
-make the 256-color mode as easily accessible as possible. Comparing the\r
-8 pixels/address in 16-color modes to the 1-to-1 correspondence of\r
-pixels and addresses of mode 13h, one can say that they have\r
-succeeded, but at a certain cost. For reasons I am not aware of, the\r
-designers came up with the following effective, but memory-wasting\r
-scheme:\r
-\r
-The address space of mode 13h is divided evenly across the four bit\r
-planes. When an 8-bit color value is written to a 16-bit address in the\r
-VGA segment, a bit plane is automatically selected by the 2 least\r
-significant bits of the address. Then all 8 bits of the data is written\r
-to the byte at the 16-bit address in the selected bitplane (have a look at\r
-figure 1). Reading works exactly the same way. Since the bit planes are so\r
-closely tied to the address, only every fourth byte in the video memory is\r
-accessible, and 192 Kb of a 256 Kb VGA go to waste. Eliminating the\r
-need to bother about planes sure is convenient and beneficial, but to\r
-most people the loss of 3/4 of the total VGA memory sounds just hilarious.\r
-\r
-To accomodate this new method of accessing video memory, the VGA\r
-designers introduced a new configuration bit called Chain-4, which\r
-resides as bit number 3 in index 4 of the Sequencer. In 16-color modes,\r
-the default state for this bit is off (zero), and the VGA operates as\r
-described earlier. In the VGA's standard 256-color mode, mode 13h, this\r
-bit is turned on (set to one), and this turns the tieing of bit\r
-planes and memory address on.\r
-\r
-In this state, the bit planes are said to be chained together, thus mode\r
-13h is often called a _chained mode_.\r
-\r
-Note that Chain-4 in itself is not enough to set a 256-color mode -\r
-there are other registers which deals with the other subtle changes in\r
-nature from 16 to 256 colors. But, as we now will base our work with\r
-mode X on mode 13h, which already is 256-color, we won't bother about\r
-these for now.\r
-\r
-\r
-\r
-2. GETTING MORE PAGES AND PUTTING YOUR FIRST PIXEL\r
-\r
-The observant reader might at this time suggest that clearing the\r
-Chain-4 bit after setting mode 13h will give us access to all 256 Kb of\r
-video memory, as the two least significant bits of the byte address\r
-won't be `wasted' on selecting a bit plane. This is correct. You might\r
-also start feeling a little uneasy, because something tells you that\r
-you'll instantly loose the simple addressing scheme of mode 13h. Sadly,\r
-that is also correct.\r
-\r
-At the moment Chain-4 is cleared, each byte offset addresses *four*\r
-sequential pixels, corresponding to the four planes addressed in 16-color\r
-modes. Every fourth pixel belong in the same plane. Before writing to a byte\r
-offset in the video segment, you should make sure that the 4-bit mask in the\r
-Write Plane Enable register is set correctly, according to which of the four\r
-addressable pixels you want to modify. In essence, it works like a 16-color\r
-mode with a twist. See figure 2.\r
-\r
-So, is this mode X? Not quite. We need to elaborate to the VGA how to\r
-fetch data for refreshing the monitor image. Explaining the logic\r
-behind this is beyond the scope of this getting-you-started text, and it\r
-wouldn't be very interesting anyway. Also, mode 13h has only 200 lines,\r
-while I promised 240 lines. I'll fix that later below. Here is the minimum\r
-snippet of code to initiate the 4 page variant of mode 13h (320x200), written\r
-in plain C, using some DOS specific features (see header for a note about the\r
-sources included):\r
-\r
-----8<-------cut begin------\r
-\r
-/* width and height should specify the mode dimensions. widthBytes\r
- specify the width of a line in addressable bytes. */\r
-\r
-int width, height, widthBytes;\r
-\r
-/* actStart specifies the start of the page being accessed by\r
- drawing operations. visStart specifies the contents of the Screen\r
- Start register, i.e. the start of the visible page */\r
-\r
-unsigned actStart, visStart;\r
-\r
-/*\r
- * set320x200x256_X()\r
- * sets mode 13h, then turns it into an unchained (planar), 4-page\r
- * 320x200x256 mode.\r
- */\r
-\r
-set320x200x256_X()\r
- {\r
-\r
- union REGS r;\r
-\r
- /* Set VGA BIOS mode 13h: */\r
-\r
- r.x.ax = 0x0013;\r
- int86(0x10, &r, &r);\r
-\r
- /* Turn off the Chain-4 bit (bit 3 at index 4, port 0x3c4): */\r
-\r
- outport(SEQU_ADDR, 0x0604);\r
-\r
- /* Turn off word mode, by setting the Mode Control register\r
- of the CRT Controller (index 0x17, port 0x3d4): */\r
-\r
- outport(CRTC_ADDR, 0xE317);\r
-\r
- /* Turn off doubleword mode, by setting the Underline Location\r
- register (index 0x14, port 0x3d4): */\r
-\r
- outport(CRTC_ADDR, 0x0014);\r
-\r
- /* Clear entire video memory, by selecting all four planes, then\r
- writing 0 to the entire segment. */\r
-\r
- outport(SEQU_ADDR, 0x0F02);\r
- memset(vga+1, 0, 0xffff); /* stupid size_t exactly 1 too small */\r
- vga[0] = 0;\r
-\r
- /* Update the global variables to reflect the dimensions of this\r
- mode. This is needed by most future drawing operations. */\r
-\r
- width = 320;\r
- height = 200;\r
-\r
- /* Each byte addresses four pixels, so the width of a scan line\r
- in *bytes* is one fourth of the number of pixels on a line. */\r
-\r
- widthBytes = width / 4;\r
-\r
- /* By default we want screen refreshing and drawing operations\r
- to be based at offset 0 in the video segment. */\r
-\r
- actStart = visStart = 0;\r
-\r
- }\r
-\r
-----8<-------cut end------\r
-\r
-As you can see, I've already provided some of the mechanics needed to\r
-support multiple pages, by providing the actStart and visStart variables.\r
-Selecting pages can be done in one of two contexts:\r
-\r
- 1) selecting the visible page, i.e. which page is visible on\r
- screen, and\r
-\r
- 2) selecting the active page, i.e. which page is accessed by\r
- drawing operations\r
-\r
-Selecting the active page is just a matter of offsetting our graphics\r
-operations by the address of the start of the page, as demonstrated in\r
-the put pixel routine below. Selecting the visual page must be passed\r
-in to the VGA, by setting the Screen Start register. Sadly enough, the\r
-resolution of this register is limited to one addressable byte, which\r
-means four pixels in unchained 256-color modes. Some further trickery is \r
-needed for 1-pixel smooth, horizontal scrolling, but I'll make that a subject \r
-for later. The setXXXStart() functions provided here accept byte\r
-offsets as parameters, so they'll work in any mode. If widthBytes and\r
-height are set correctly, so will the setXXXPage() functions.\r
-\r
-----8<-------cut begin------\r
-\r
-/*\r
- * setActiveStart() tells our graphics operations which address in video\r
- * memory should be considered the top left corner.\r
- */\r
-\r
-setActiveStart(unsigned offset)\r
- {\r
- actStart = offset;\r
- }\r
-\r
-/*\r
- * setVisibleStart() tells the VGA from which byte to fetch the first\r
- * pixel when starting refresh at the top of the screen. This version\r
- * won't look very well in time critical situations (games for\r
- * instance) as the register outputs are not synchronized with the\r
- * screen refresh. This refresh might start when the high byte is\r
- * set, but before the low byte is set, which produces a bad flicker.\r
- * I won't bother with this now.\r
- */\r
-\r
-setVisibleStart(unsigned offset)\r
- {\r
- visStart = offset;\r
- outport(CRTC_ADDR, 0x0C); /* set high byte */\r
- outport(CRTC_ADDR+1, visStart >> 8);\r
- outport(CRTC_ADDR, 0x0D); /* set low byte */\r
- outport(CRTC_ADDR+1, visStart & 0xff);\r
- }\r
-\r
-/*\r
- * setXXXPage() sets the specified page by multiplying the page number\r
- * with the size of one page at the current resolution, then handing the\r
- * resulting offset value over to the corresponding setXXXStart()\r
- * function. The first page number is 0.\r
- */\r
-\r
-setActivePage(int page)\r
- {\r
- setActiveStart(page * widthBytes * height);\r
- }\r
-\r
-setVisiblePage(int page)\r
- {\r
- setVisibleStart(page * widthBytes * height);\r
- }\r
-\r
-----8<-------cut end------\r
-\r
-Due to the use of bit planes, the graphics routines tend to get more\r
-complex than in mode 13h, and your first versions will generally tend to\r
-be a little slower than mode 13h algorithms. Here's a put pixel routine\r
-for any unchained 256-color mode (it assumes that the 'width' variable\r
-from the above code is set correctly). Optimizing is left as an exercise\r
-to you, the reader. This will be the only drawing operation I'll cover\r
-in this article, but all general primitives like lines and circles can be \r
-based on this routine. (You'll probably not want to do that though, due\r
-to the inefficiency.)\r
-\r
-----8<-------cut begin------\r
-\r
-putPixel_X(int x, int y, char color)\r
- {\r
-\r
- /* Each address accesses four neighboring pixels, so set\r
- Write Plane Enable according to which pixel we want\r
- to modify. The plane is determined by the two least\r
- significant bits of the x-coordinate: */\r
-\r
- outportb(0x3c4, 0x02);\r
- outportb(0x3c5, 0x01 << (x & 3));\r
-\r
- /* The offset of the pixel into the video segment is\r
- offset = (width * y + x) / 4, and write the given\r
- color to the plane we selected above. Heed the active\r
- page start selection. */\r
-\r
- vga[(unsigned)(widthBytes * y) + (x / 4) + actStart] = color;\r
-\r
- }\r
-\r
-char getPixel_X(int x, int y)\r
- {\r
-\r
- /* Select the plane from which we must read the pixel color: */\r
-\r
- outport(GRAC_ADDR, 0x04);\r
- outport(GRAC_ADDR+1, x & 3);\r
-\r
- return vga[(unsigned)(widthBytes * y) + (x / 4) + actStart];\r
-\r
- }\r
-\r
-----8<-------cut end------\r
-\r
-\r
-However, by now you should be aware of that the Write Plane Enable\r
-register isn't limited to selecting just one bit plane, like the\r
-Read Plane Select register is. You can enable any combination of all\r
-four to be written. This ability to access 4 pixels with one\r
-instruction helps quadrupling the speed in certain respects, especially when \r
-drawing horizontal lines and filling polygons of a constant color. Also, most \r
-block algorithms can be optimized in various ways so that they need only\r
-a constant number of OUTs (typically four) to the Write Plane Enable\r
-register. OUT is a relatively slow instruction.\r
-\r
-The gained ability to access the full 256 Kb of memory on a standard\r
-VGA enables you to do paging and all the goodies following from that:\r
-smooth scrolling over large maps, page flipping for flicker free\r
-animation... and I'll leave something for your own imagination.\r
-\r
-In short, the stuff gained from unchaining mode 13h more than \r
-upweighs the additional complexity of using a planar mode. \r
-\r
-Now, the resolution of the mode is of little interest in this\r
-context. Nearly any 256-color resolution from (about) 80x8 to 400x300\r
-is available for most VGAs. I'll dwell particularly by 320x240, as this\r
-is the mode that Michael Abrash introduced as 'Mode X' in his DDJ\r
-articles. It is also the resolution that most people refer to when\r
-using that phrase.\r
-\r
-The good thing about the 320x240 mode is that the aspect ratio is\r
-1:1, which means that each pixel is 'perfectly' square, i.e. not\r
-rectangular like in 320x200. An ellipse drawn with the same number of\r
-pixels along both main axes will look like a perfect circle in 320x240,\r
-but like a subtly tall ellipse in 320x200.\r
-\r
-Here's a function which sets the 320x240 mode. You'll notice that\r
-it depends on the first piece of code above:\r
-\r
-----8<-------cut begin------\r
-\r
-set320x240x256_X()\r
- {\r
-\r
- /* Set the unchained version of mode 13h: */\r
-\r
- set320x200x256_X();\r
-\r
- /* Modify the vertical sync polarity bits in the Misc. Output\r
- Register to achieve square aspect ratio: */\r
-\r
- outportb(0x3C2, 0xE3);\r
-\r
- /* Modify the vertical timing registers to reflect the increased\r
- vertical resolution, and to center the image as good as\r
- possible: */\r
-\r
- outport(0x3D4, 0x2C11); /* turn off write protect */\r
- outport(0x3D4, 0x0D06); /* vertical total */\r
- outport(0x3D4, 0x3E07); /* overflow register */\r
- outport(0x3D4, 0xEA10); /* vertical retrace start */\r
- outport(0x3D4, 0xAC11); /* vertical retrace end AND wr.prot */\r
- outport(0x3D4, 0xDF12); /* vertical display enable end */\r
- outport(0x3D4, 0xE715); /* start vertical blanking */\r
- outport(0x3D4, 0x0616); /* end vertical blanking */\r
-\r
- /* Update mode info, so future operations are aware of the\r
- resolution: */\r
-\r
- height = 240;\r
-\r
- }\r
-\r
-----8<-------cut end------\r
-\r
-\r
-As you've figured out, this mode will be completely compatible with the\r
-utility functions presented earlier, thanks to the global variable\r
-'height'. Boy, am I foreseeing or what!\r
-\r
-Other resolutions are achieved through giving other values to the sync\r
-timing registers of the VGA, but this is quite a large and complex\r
-subject, so I'll postpone this to later, if ever.\r
-\r
-Anyway, I hope I've helped getting you started using mode X. As far as\r
-I know, the two modes I've used above should work on *any* VGA and Super\r
-VGA available, so this is pretty stable stuff. Let me know of any \r
-trouble, and - \r
- good luck!\r
-\r
-\r
-\r
-3. THE ROAD FROM HERE\r
-\r
-I'm providing information on various libraries and archives which relate\r
-to what this article deals with. If you want me to add anything to this\r
-list (for future articles), let me know, although I can't promise anything.\r
-I am assuming you have ftp access.\r
-\r
-\r
-wuarchive.wustl.edu:/pub/MSDOS_UPLOADS/programming/xlib06.zip\r
-\r
-This is the current de facto C/assembler library for programming\r
-unchained modes (do not confuse with a X Windows library). All sources\r
-are included, and the library is totally free. It has functions for\r
-pixels, lines, circles, bezier curves, mouse handling, sprites (bitmaps),\r
-compiled bitmaps, and supports a number of resolutions. The version number\r
-('06') is current as of November 1993.\r
-\r
-\r
-graphprg.zip\r
-\r
-Michael Abrash' articles in Doctor Dobbs Journal is always mentioned\r
-with awe. In this 350 Kb archive, most of his interesting stuff has\r
-been gathered. Read about Mode X development and techniques from month\r
-to month. Included is also all the individual source code snippets from\r
-each article, and also the full XSHARP library providing linedrawing,\r
-polygons, bitmaps, solid 3D projection and speedy rendering, and even an\r
-implementation of 2D texture mapping (can be used for quasi-3D texture\r
-mapping), plus an article on assembly optimization on the i86 processor\r
-family. Definitely recommended.\r
-\r
-\r
-oak.oakland.edu:/pub/msdos/vga/vgadoc2.zip\r
-\r
-This is a bare bones VGA register reference. It also contains register\r
-references for the CGA, EGA and Hercules cards, in addition to dozens of\r
-SuperVGAs. Check out the BOOKS section for some decent VGA references\r
-though - you don't want to start tweaking without a real one.\r
-\r
-\r
-wuarchive.wustl.edu:/pub/MSDOS_UPLOADS/programming/tweak15b.zip\r
-\r
-TWEAK might be of interest to the more adventurous reader. TWEAK lets you\r
-play around with the registers of the VGA in an interactive manner.\r
-Various testing screens for viewing your newmade modes are applied at\r
-the press of a key. Version 1.5 adds a test screen which autodetects your \r
-graphics mode and displays various information about resolutions etc.\r
-Keep a VGA reference handy. Don't try it if this is the first time you've \r
-heard of 'registers' or 'mode X' or 'tweaking'. I was planning a version\r
-based on the Turbo Vision interface, but time has been short. Maybe later!\r
-\r
-\r
-\r
-\r
-4. BOOKS ON THE SUBJECT\r
-\r
-Extremely little has been published in written form about using\r
-'Mode X'-style modes. Below are some books which cover VGA programming\r
-at varying degrees of technical level, but the only one to mention\r
-unchained modes and Mode X, is Michael Abrash'. I'd get one of the VGA\r
-references first, though.\r
-\r
- o George Sutty & Steve Blair : "Advanced Pogrammer's Guide to the\r
- EGA/VGA" from Brady. A bit old perhaps, but covers all *standard*\r
- EGA/VGA registers, and discusses most BIOS functions and other\r
- operations. Contains disk with C/Pascal/assembler source code.\r
- There's a sequel out for SuperVGAs, which I haven't seen.\r
-\r
- o Michael Abrash : "Power Graphics Programming" from QUE/Programmer's\r
- Journal. Collections of (old) articles from Programmer's Journal on\r
- EGA/VGA, read modes and write modes, animation, tweaking (320x400\r
- and 360x480). His newer ravings in DDJ covers fast 256-color\r
- bitmaps, compiled bitmaps, polygons, 3D graphics, texture mapping\r
- among other stuff.\r
-\r
- o Richard F. Ferraro : "Programmer's Guide to the EGA and VGA video\r
- cards including Super VGA". I don't have this one, but heard it's\r
- nice. Detailed coverage of all EGA/VGA registers. The Super VGA\r
- reference makes it attractive.\r
-\r
- o Richard Wilton : "Programmer's Guide to PC & PS/2 Video Systems"\r
- Less technical, more application/algorithm oriented. Nice enough,\r
- even though it is a bit outdated, in that he discusses CGA and\r
- Hercules cards just as much as EGA/VGA.\r
-\r
-\r
-\r
-\r
-5. BYE - FOR NOW\r
-\r
-I am considering writing a text describing in more detail the process of\r
-using TWEAK to achieve the VGA resolution you want or need. However, I\r
-thought I'd let this document go first, and see if I get any reactions.\r
-If I don't, I'll stop. Feel free to forward any suggestions,\r
-criticisms, bombs and beers.\r
-\r
-I can be reached via:\r
-\r
- o e-mail: robert@stud.unit.no\r
-\r
- o land mail:\r
-\r
- Robert Schmidt\r
- Stud.post 170\r
- NTH\r
- N-7034 Trondheim\r
- NORWAY\r
-\r
-Nothing would encourage or please me more than a postcard from where you\r
-live!\r
projects / 16.git / commitdiff
