]> 4ch.mooo.com Git - 16.git/commitdiff
new file: 16/lib/intro/M13ORG.ASC
authorsparky4 <sparky4@4ch.maidlab.jp>
Sun, 1 Jun 2014 03:06:29 +0000 (22:06 -0500)
committersparky4 <sparky4@4ch.maidlab.jp>
Sun, 1 Jun 2014 03:06:29 +0000 (22:06 -0500)
new file:   16/lib/intro/M13ORG.GIF
new file:   16/lib/intro/MXORG.ASC
new file:   16/lib/intro/MXORG.GIF
new file:   16/lib/intro/XINTRO.TXT

16/lib/intro/M13ORG.ASC [new file with mode: 0644]
16/lib/intro/M13ORG.GIF [new file with mode: 0644]
16/lib/intro/MXORG.ASC [new file with mode: 0644]
16/lib/intro/MXORG.GIF [new file with mode: 0644]
16/lib/intro/XINTRO.TXT [new file with mode: 0644]

diff --git a/16/lib/intro/M13ORG.ASC b/16/lib/intro/M13ORG.ASC
new file mode 100644 (file)
index 0000000..906ec42
--- /dev/null
@@ -0,0 +1,55 @@
+Figure 1: Memory organization in mode 13h (ASCII version)\r
+         by Robert Schmidt\r
+          (C) 1993 Ztiff Zox Softwear\r
+\r
+a. Imagine that the top of the screen looks like this (pixel values are\r
+   represented by color digits 0-9 for simplicity - actual colors may\r
+   range from 0 to 255) - a screen width of 320 pixels is assumed:\r
+\r
+    address:  0         10                310      319\r
+             ----------------------------------------\r
+             |0123456789012345    .....   0123456789|\r
+             |                                      |\r
+             |                                      |\r
+             |\r
+\r
+b. In VGA memory, the screen is represented as follows (question marks\r
+   represent unused bytes):\r
+\r
+   Plane 0:\r
+\r
+    address:  0         10                310      319\r
+             ----------------------------------------\r
+             |0???4???8???2???    .....   ??2???6???|\r
+             |                                      |\r
+             |                                      |\r
+\r
+   Plane 1:\r
+\r
+    address:  0         10                310      319\r
+             ----------------------------------------\r
+             |?1???5???9???3??    .....   ???3???7??|\r
+             |                                      |\r
+             |                                      |\r
+\r
+   Plane 2:\r
+\r
+    address:  0         10                310      319\r
+             ----------------------------------------\r
+             |??2???6???0???4?    .....   0???4???8?|\r
+             |                                      |\r
+             |                                      |\r
+\r
+   Plane 3:\r
+\r
+    address:  0         10                310      319\r
+             ----------------------------------------\r
+             |???3???7???1???5    .....   ?1???5???9|\r
+             |                                      |\r
+             |                                      |\r
+\r
+   I.e. a plane is selected automatically by the two least significant\r
+   bits of the address of the byte being read from or written two.\r
+   This renders 3/4 of the video memory unavailable and useless, but\r
+   all visible pixels are easily accessed, as each address in the video\r
+   segment provides access to one and ONLY ONE pixel.\r
diff --git a/16/lib/intro/M13ORG.GIF b/16/lib/intro/M13ORG.GIF
new file mode 100644 (file)
index 0000000..1fb4fc4
Binary files /dev/null and b/16/lib/intro/M13ORG.GIF differ
diff --git a/16/lib/intro/MXORG.ASC b/16/lib/intro/MXORG.ASC
new file mode 100644 (file)
index 0000000..295766b
--- /dev/null
@@ -0,0 +1,49 @@
+Figure 2: Memory organization in unchained 256-color modes (like\r
+          Mode X) (ASCII version)\r
+         by Robert Schmidt\r
+          (C) 1993 Ztiff Zox Softwear\r
+\r
+\r
+Imagine that the screen looks the same as in figure 1a.  A screen width\r
+of 320 pixels is still assumed.\r
+\r
+In VGA memory, the screen will be represented as follows:\r
+\r
+   Plane 0:\r
+\r
+    address:  0         10                70       79 (NOT 319!)\r
+             ----------------------------------------\r
+             |0482604826048260    .....   0482604826|\r
+             |                                      |\r
+             |                                      |\r
+\r
+   Plane 1:\r
+\r
+    address:  0         10                70       79\r
+             ----------------------------------------\r
+             |1593715937159371    .....   1593715937|\r
+             |                                      |\r
+             |                                      |\r
+\r
+   Plane 2:\r
+\r
+    address:  0         10                70       79\r
+             ----------------------------------------\r
+             |2604826048260482    .....   2604826048|\r
+             |                                      |\r
+             |                                      |\r
+\r
+   Plane 3:\r
+\r
+    address:  0         10                70       79\r
+             ----------------------------------------\r
+             |3715937159371593    .....   3715937159|\r
+             |                                      |\r
+             |                                      |\r
+\r
+Note that if pixel i is in plane p, pixel i+1 is in plane (p+1)%4.\r
+When the planes are unchained, we need to set the Write Plane Enable\r
+register to select which planes should receive the data when writing,\r
+or the Read Plane Select register when reading.  As is evident, one \r
+address in the video segment provides access to no less than FOUR\r
+different pixels.\r
diff --git a/16/lib/intro/MXORG.GIF b/16/lib/intro/MXORG.GIF
new file mode 100644 (file)
index 0000000..31c0ac5
Binary files /dev/null and b/16/lib/intro/MXORG.GIF differ
diff --git a/16/lib/intro/XINTRO.TXT b/16/lib/intro/XINTRO.TXT
new file mode 100644 (file)
index 0000000..0ac0585
--- /dev/null
@@ -0,0 +1,569 @@
+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