home *** CD-ROM | disk | FTP | other *** search
/ Collection of Hack-Phreak Scene Programs / cleanhpvac.zip / cleanhpvac / PCGPEV10.ZIP / MODEX.TXT < prev    next >
Text File  |  1994-05-10  |  29KB  |  721 lines
  1.  
  2.                       ┌────────────────────────┐
  3.                       │ INTRODUCTION TO MODE X │
  4.                       └────────────────────────┘
  5.  
  6.                  By Robert Schmidt <robert@stud.unit.no>
  7.  
  8.  
  9.  
  10. ┌──────────────┬─────────────────────────────────────────────────────────────
  11. │ XINTRO18.TXT │
  12. └──────────────┘
  13.  
  14. Title:          INTRODUCTION TO MODE X
  15.  
  16. Version:        1.8
  17.  
  18. Author:         Robert Schmidt <robert@stud.unit.no>
  19.  
  20. Copyright:      (C) 1993 of Ztiff Zox Softwear - refer to Status below.
  21.  
  22. Last revision:  25-Nov-93 (Modified for the PCGPE 17-Apr-94)
  23.  
  24. Figures:        1. M13ORG - memory organization in mode 13h
  25.                 2. MXORG - memory organization in unchained modes
  26.                 (Both files are appended to the end of this document)
  27.  
  28.                 The figures are available as 7-bit ASCII text (ASC) files.
  29.  
  30. Status:         This article, its associated figures and source listings
  31.                 named above, are all donated to the public domain.
  32.                 Do with it whatever you like, but give credit where
  33.                 credit is due.
  34.  
  35.                 The standard disclaimer applies.
  36.  
  37. Index:          0. ABSTRACT
  38.                 1. INTRODUCTION TO THE VGA AND ITS 256-COLOR MODE
  39.                 2. GETTING MORE PAGES AND PUTTING YOUR FIRST PIXEL
  40.                 3. THE ROAD FROM HERE
  41.                 4. BOOKS ON THE SUBJECT
  42.                 5. BYE - FOR NOW
  43.  
  44.  
  45. 0. ABSTRACT
  46.  
  47. This text gives a fairly basic, yet technical, explanation to what, why
  48. and how Mode X is.  It first tries to explain the layout of the VGA
  49. memory and the shortcomings of the standard 320x200 256-color mode,
  50. then gives instructions on how one can progress from mode 13h to a
  51. multipage, planar 320x200 256-color mode, and from there to the
  52. quasi-standard 320x240 mode, known as Mode X.
  53.  
  54. A little experience in programming the standard VGA mode 13h
  55. (320x200 in 256 colors) is assumed.  Likewise a good understanding of
  56. hexadecimal notation and the concepts of segments and I/O ports is
  57. assumed.  Keep a VGA reference handy, which at least should have
  58. definitions of the VGA registers at bit level.
  59.  
  60. Throughout the article, a simple graphics library for unchained (planar)
  61. 256-color modes is developed.  The library supports the 320x200 and
  62. 320x240 modes, active and visible pages, and writing and reading
  63. individual pixels.
  64.  
  65.  
  66. 1. INTRODUCTION TO THE VGA AND ITS 256-COLOR MODE
  67.  
  68. Since its first appearance on the motherboards of the IBM PS/2 50, 60
  69. and 80 models in 1987, the Video Graphics Array has been the de facto
  70. standard piece of graphics hardware for IBM and compatible personal
  71. computers.  The abbreviation, VGA, was to most people synonymous with
  72. acceptable resolution (640x480 pixels), and a stunning rainbow of colors
  73. (256 from a palette of 262,144), at least compared to the rather gory
  74. CGA and EGA cards.
  75.  
  76. Sadly, to use 256 colors, the VGA BIOS limited the users to 320x200
  77. pixels, i.e. the well-known mode 13h.  This mode has one good and one
  78. bad asset.  The good one is that each one of the 64,000 pixels is easily
  79. addressable in the 64 Kb video memory segment at 0A000h.  Simply calculate
  80. the offset using this formula:
  81.  
  82. offset = (y * 320) + x;
  83.  
  84. Set the byte at this address (0A000h:offset) to the color you want, and
  85. the pixel is there.  Reading a pixel is just as simple: just read the
  86. corresponding byte.  This was heaven, compared to the havoc of planes and
  87. masking registers needed in 16-color modes.  Suddenly, the distance from a
  88. graphics algorithm on paper to an implemented graphics routine in assembly
  89. was cut down to a fraction.  The results were impressively fast, too!
  90.  
  91. The bad asset is that mode 13h is also limited to only one page, i.e.
  92. the VGA can hold only one screenful at any one time (plus 1536 pixels, or
  93. about four lines).  Most 16-color modes let the VGA hold more than one page,
  94. and this enables you to show one of the pages to the user, while drawing on
  95. another page in the meantime.  Page flipping is an important concept in making
  96. flicker free animations.  Nice looking and smooth scrolling is also almost
  97. impossible in mode 13h using plain VGA hardware.
  98.  
  99. Now, the alert reader might say: "Hold on a minute!  If mode 13h enables
  100. only one page, this means that there is memory for only one page.  But I
  101. know for a fact that all VGAs have at least 256 Kb RAM, and one 320x200
  102. 256-color page should consume only 320*200=64000 bytes, which is less
  103. than 64 Kb.  A standard VGA should room a little more than four 320x200
  104. pages!"  Quite correct, and to see how the BIOS puts this limitation on
  105. mode 13h, I'll elaborate a little on the memory organization of the VGA.
  106.  
  107. The memory is separated into four bit planes.  The reason for this stems
  108. from the EGA, where graphics modes were 16-color.  Using bit planes, the
  109. designers chose to let each pixel on screen be addressable by a single
  110. bit in a single byte in the video segment.  Assuming the palette has
  111. not been modified from the default, each plane represent one of the EGA
  112. primary colors: red, green, blue and intensity.  When modifying the bit
  113. representing a pixel, the Write Plane Enable register is set to the
  114. wanted color.  Reading is more complex and slower, since you can
  115. only read from a single plane at a time, by setting the Read Plane
  116. Select register.  Now, since each address in the video segment can
  117. access 8 pixels, and there are 64 Kb addresses, 8 * 65,536 = 524,288
  118. 16-color pixels can be accessed.  In a 320x200 16-color mode, this makes
  119. for about 8 (524,288/(320*200)) pages, in 640x480 you get nearly 2
  120. (524,288/(640*480)) pages.
  121.  
  122. In a 256-color mode, the picture changes subtly.  The designers decided
  123. to fix the number of bit planes to 4, so extending the logic above to 8
  124. planes and 256 colors does not work.  Instead, one of their goals was to
  125. make the 256-color mode as easily accessible as possible.  Comparing the
  126. 8 pixels/address in 16-color modes to the 1-to-1 correspondence of
  127. pixels and addresses of mode 13h, one can say that they have
  128. succeeded, but at a certain cost.  For reasons I am not aware of, the
  129. designers came up with the following effective, but memory-wasting
  130. scheme:
  131.  
  132. The address space of mode 13h is divided evenly across the four bit
  133. planes.  When an 8-bit color value is written to a 16-bit address in the
  134. VGA segment, a bit plane is automatically selected by the 2 least
  135. significant bits of the address.  Then all 8 bits of the data is written
  136. to the byte at the 16-bit address in the selected bitplane (have a look at
  137. figure 1).  Reading works exactly the same way.  Since the bit planes are so
  138. closely tied to the address, only every fourth byte in the video memory is
  139. accessible, and 192 Kb of a 256 Kb VGA go to waste.  Eliminating the
  140. need to bother about planes sure is convenient and beneficial, but to
  141. most people the loss of 3/4 of the total VGA memory sounds just hilarious.
  142.  
  143. To accomodate this new method of accessing video memory, the VGA
  144. designers introduced a new configuration bit called Chain-4, which
  145. resides as bit number 3 in index 4 of the Sequencer.  In 16-color modes,
  146. the default state for this bit is off (zero), and the VGA operates as
  147. described earlier.  In the VGA's standard 256-color mode, mode 13h, this
  148. bit is turned on (set to one), and this turns the tieing of bit
  149. planes and memory address on.
  150.  
  151. In this state, the bit planes are said to be chained together, thus mode
  152. 13h is often called a _chained mode_.
  153.  
  154. Note that Chain-4 in itself is not enough to set a 256-color mode -
  155. there are other registers which deals with the other subtle changes in
  156. nature from 16 to 256 colors.  But, as we now will base our work with
  157. mode X on mode 13h, which already is 256-color, we won't bother about
  158. these for now.
  159.  
  160.  
  161.  
  162. 2. GETTING MORE PAGES AND PUTTING YOUR FIRST PIXEL
  163.  
  164. The observant reader might at this time suggest that clearing the
  165. Chain-4 bit after setting mode 13h will give us access to all 256 Kb of
  166. video memory, as the two least significant bits of the byte address
  167. won't be `wasted' on selecting a bit plane.  This is correct.  You might
  168. also start feeling a little uneasy, because something tells you that
  169. you'll instantly loose the simple addressing scheme of mode 13h.  Sadly,
  170. that is also correct.
  171.  
  172. At the moment Chain-4 is cleared, each byte offset addresses *four*
  173. sequential pixels, corresponding to the four planes addressed in 16-color
  174. modes.  Every fourth pixel belong in the same plane.  Before writing to a byte
  175. offset in the video segment, you should make sure that the 4-bit mask in the
  176. Write Plane Enable register is set correctly, according to which of the four
  177. addressable pixels you want to modify.  In essence, it works like a 16-color
  178. mode with a twist.  See figure 2.
  179.  
  180. So, is this mode X?  Not quite.  We need to elaborate to the VGA how to
  181. fetch data for refreshing the monitor image.  Explaining the logic
  182. behind this is beyond the scope of this getting-you-started text, and it
  183. wouldn't be very interesting anyway.  Also, mode 13h has only 200 lines,
  184. while I promised 240 lines.  I'll fix that later below.  Here is the minimum
  185. snippet of code to initiate the 4 page variant of mode 13h (320x200), written
  186. in plain C, using some DOS specific features (see header for a note about the
  187. sources included):
  188.  
  189. ----8<-------cut begin------
  190.  
  191. /* width and height should specify the mode dimensions.  widthBytes
  192.    specify the width of a line in addressable bytes. */
  193.  
  194. int width, height, widthBytes;
  195.  
  196. /* actStart specifies the start of the page being accessed by
  197.    drawing operations.  visStart specifies the contents of the Screen
  198.    Start register, i.e. the start of the visible page */
  199.  
  200. unsigned actStart, visStart;
  201.  
  202. /*
  203.  * set320x200x256_X()
  204.  *      sets mode 13h, then turns it into an unchained (planar), 4-page
  205.  *      320x200x256 mode.
  206.  */
  207.  
  208. set320x200x256_X()
  209.         {
  210.  
  211.         union REGS r;
  212.  
  213.         /* Set VGA BIOS mode 13h: */
  214.  
  215.         r.x.ax = 0x0013;
  216.         int86(0x10, &r, &r);
  217.  
  218.         /* Turn off the Chain-4 bit (bit 3 at index 4, port 0x3c4): */
  219.  
  220.         outport(SEQU_ADDR, 0x0604);
  221.  
  222.         /* Turn off word mode, by setting the Mode Control register
  223.            of the CRT Controller (index 0x17, port 0x3d4): */
  224.  
  225.         outport(CRTC_ADDR, 0xE317);
  226.  
  227.         /* Turn off doubleword mode, by setting the Underline Location
  228.            register (index 0x14, port 0x3d4): */
  229.  
  230.         outport(CRTC_ADDR, 0x0014);
  231.  
  232.         /* Clear entire video memory, by selecting all four planes, then
  233.            writing 0 to the entire segment. */
  234.  
  235.         outport(SEQU_ADDR, 0x0F02);
  236.         memset(vga+1, 0, 0xffff); /* stupid size_t exactly 1 too small */
  237.         vga[0] = 0;
  238.  
  239.         /* Update the global variables to reflect the dimensions of this
  240.            mode.  This is needed by most future drawing operations. */
  241.  
  242.         width   = 320;
  243.         height  = 200;
  244.  
  245.         /* Each byte addresses four pixels, so the width of a scan line
  246.            in *bytes* is one fourth of the number of pixels on a line. */
  247.  
  248.         widthBytes = width / 4;
  249.  
  250.         /* By default we want screen refreshing and drawing operations
  251.            to be based at offset 0 in the video segment. */
  252.  
  253.         actStart = visStart = 0;
  254.  
  255.         }
  256.  
  257. ----8<-------cut end------
  258.  
  259. As you can see, I've already provided some of the mechanics needed to
  260. support multiple pages, by providing the actStart and visStart variables.
  261. Selecting pages can be done in one of two contexts:
  262.  
  263.         1) selecting the visible page, i.e. which page is visible on
  264.            screen, and
  265.  
  266.         2) selecting the active page, i.e. which page is accessed by
  267.            drawing operations
  268.  
  269. Selecting the active page is just a matter of offsetting our graphics
  270. operations by the address of the start of the page, as demonstrated in
  271. the put pixel routine below.  Selecting the visual page must be passed
  272. in to the VGA, by setting the Screen Start register.  Sadly enough, the
  273. resolution of this register is limited to one addressable byte, which
  274. means four pixels in unchained 256-color modes.  Some further trickery is 
  275. needed for 1-pixel smooth, horizontal scrolling, but I'll make that a subject
  276. for later.  The setXXXStart() functions provided here accept byte
  277. offsets as parameters, so they'll work in any mode.  If widthBytes and
  278. height are set correctly, so will the setXXXPage() functions.
  279.  
  280. ----8<-------cut begin------
  281.  
  282. /*
  283.  * setActiveStart() tells our graphics operations which address in video
  284.  * memory should be considered the top left corner.
  285.  */
  286.  
  287. setActiveStart(unsigned offset)
  288.         {
  289.         actStart = offset;
  290.         }
  291.  
  292. /*
  293.  * setVisibleStart() tells the VGA from which byte to fetch the first
  294.  * pixel when starting refresh at the top of the screen.  This version
  295.  * won't look very well in time critical situations (games for
  296.  * instance) as the register outputs are not synchronized with the
  297.  * screen refresh.  This refresh might start when the high byte is
  298.  * set, but before the low byte is set, which produces a bad flicker.
  299.  * I won't bother with this now.
  300.  */
  301.  
  302. setVisibleStart(unsigned offset)
  303.         {
  304.         visStart = offset;
  305.         outport(CRTC_ADDR, 0x0C);               /* set high byte */
  306.         outport(CRTC_ADDR+1, visStart >> 8);
  307.         outport(CRTC_ADDR, 0x0D);               /* set low byte */
  308.         outport(CRTC_ADDR+1, visStart & 0xff);
  309.         }
  310.  
  311. /*
  312.  * setXXXPage() sets the specified page by multiplying the page number
  313.  * with the size of one page at the current resolution, then handing the
  314.  * resulting offset value over to the corresponding setXXXStart()
  315.  * function.  The first page number is 0.
  316.  */
  317.  
  318. setActivePage(int page)
  319.         {
  320.         setActiveStart(page * widthBytes * height);
  321.         }
  322.  
  323. setVisiblePage(int page)
  324.         {
  325.         setVisibleStart(page * widthBytes * height);
  326.         }
  327.  
  328. ----8<-------cut end------
  329.  
  330. Due to the use of bit planes, the graphics routines tend to get more
  331. complex than in mode 13h, and your first versions will generally tend to
  332. be a little slower than mode 13h algorithms.  Here's a put pixel routine
  333. for any unchained 256-color mode (it assumes that the 'width' variable
  334. from the above code is set correctly).  Optimizing is left as an exercise
  335. to you, the reader.  This will be the only drawing operation I'll cover
  336. in this article, but all general primitives like lines and circles can be 
  337. based on this routine.  (You'll probably not want to do that though, due
  338. to the inefficiency.)
  339.  
  340. ----8<-------cut begin------
  341.  
  342. putPixel_X(int x, int y, char color)
  343.         {
  344.  
  345.         /* Each address accesses four neighboring pixels, so set
  346.            Write Plane Enable according to which pixel we want
  347.            to modify.  The plane is determined by the two least
  348.            significant bits of the x-coordinate: */
  349.  
  350.         outportb(0x3c4, 0x02);
  351.         outportb(0x3c5, 0x01 << (x & 3));
  352.  
  353.         /* The offset of the pixel into the video segment is
  354.            offset = (width * y + x) / 4, and write the given
  355.            color to the plane we selected above.  Heed the active
  356.            page start selection. */
  357.  
  358.         vga[(unsigned)(widthBytes * y) + (x / 4) + actStart] = color;
  359.  
  360.         }
  361.  
  362. char getPixel_X(int x, int y)
  363.         {
  364.  
  365.         /* Select the plane from which we must read the pixel color: */
  366.  
  367.         outport(GRAC_ADDR, 0x04);
  368.         outport(GRAC_ADDR+1, x & 3);
  369.  
  370.         return vga[(unsigned)(widthBytes * y) + (x / 4) + actStart];
  371.  
  372.         }
  373.  
  374. ----8<-------cut end------
  375.  
  376.  
  377. However, by now you should be aware of that the Write Plane Enable
  378. register isn't limited to selecting just one bit plane, like the
  379. Read Plane Select register is.  You can enable any combination of all
  380. four to be written.  This ability to access 4 pixels with one
  381. instruction helps quadrupling the speed in certain respects, especially when 
  382. drawing horizontal lines and filling polygons of a constant color.  Also, most 
  383. block algorithms can be optimized in various ways so that they need only
  384. a constant number of OUTs (typically four) to the Write Plane Enable
  385. register.  OUT is a relatively slow instruction.
  386.  
  387. The gained ability to access the full 256 Kb of memory on a standard
  388. VGA enables you to do paging and all the goodies following from that:
  389. smooth scrolling over large maps, page flipping for flicker free
  390. animation... and I'll leave something for your own imagination.
  391.  
  392. In short, the stuff gained from unchaining mode 13h more than 
  393. upweighs the additional complexity of using a planar mode.  
  394.  
  395. Now, the resolution of the mode is of little interest in this
  396. context.  Nearly any 256-color resolution from (about) 80x8 to 400x300
  397. is available for most VGAs.  I'll dwell particularly by 320x240, as this
  398. is the mode that Michael Abrash introduced as 'Mode X' in his DDJ
  399. articles.  It is also the resolution that most people refer to when
  400. using that phrase.
  401.  
  402. The good thing about the 320x240 mode is that the aspect ratio is
  403. 1:1, which means that each pixel is 'perfectly' square, i.e. not
  404. rectangular like in 320x200.  An ellipse drawn with the same number of
  405. pixels along both main axes will look like a perfect circle in 320x240,
  406. but like a subtly tall ellipse in 320x200.
  407.  
  408. Here's a function which sets the 320x240 mode.  You'll notice that
  409. it depends on the first piece of code above:
  410.  
  411. ----8<-------cut begin------
  412.  
  413. set320x240x256_X()
  414.         {
  415.  
  416.         /* Set the unchained version of mode 13h: */
  417.  
  418.         set320x200x256_X();
  419.  
  420.         /* Modify the vertical sync polarity bits in the Misc. Output
  421.            Register to achieve square aspect ratio: */
  422.  
  423.         outportb(0x3C2, 0xE3);
  424.  
  425.         /* Modify the vertical timing registers to reflect the increased
  426.            vertical resolution, and to center the image as good as
  427.            possible: */
  428.  
  429.         outport(0x3D4, 0x2C11);         /* turn off write protect */
  430.         outport(0x3D4, 0x0D06);         /* vertical total */
  431.         outport(0x3D4, 0x3E07);         /* overflow register */
  432.         outport(0x3D4, 0xEA10);         /* vertical retrace start */
  433.         outport(0x3D4, 0xAC11);         /* vertical retrace end AND wr.prot */
  434.         outport(0x3D4, 0xDF12);         /* vertical display enable end */
  435.         outport(0x3D4, 0xE715);         /* start vertical blanking */
  436.         outport(0x3D4, 0x0616);         /* end vertical blanking */
  437.  
  438.         /* Update mode info, so future operations are aware of the
  439.            resolution: */
  440.  
  441.         height = 240;
  442.  
  443.         }
  444.  
  445. ----8<-------cut end------
  446.  
  447.  
  448. As you've figured out, this mode will be completely compatible with the
  449. utility functions presented earlier, thanks to the global variable
  450. 'height'.  Boy, am I foreseeing or what!
  451.  
  452. Other resolutions are achieved through giving other values to the sync
  453. timing registers of the VGA, but this is quite a large and complex
  454. subject, so I'll postpone this to later, if ever.
  455.  
  456. Anyway, I hope I've helped getting you started using mode X.  As far as
  457. I know, the two modes I've used above should work on *any* VGA and Super
  458. VGA available, so this is pretty stable stuff.  Let me know of any 
  459. trouble, and -
  460.                         good luck!
  461.  
  462.  
  463.  
  464. 3. THE ROAD FROM HERE
  465.  
  466. I'm providing information on various libraries and archives which relate
  467. to what this article deals with.  If you want me to add anything to this
  468. list (for future articles), let me know, although I can't promise anything.
  469. I am assuming you have ftp access.
  470.  
  471.  
  472. wuarchive.wustl.edu:/pub/MSDOS_UPLOADS/programming/xlib06.zip
  473.  
  474. This is the current de facto C/assembler library for programming
  475. unchained modes (do not confuse with a X Windows library).  All sources
  476. are included, and the library is totally free.  It has functions for
  477. pixels, lines, circles, bezier curves, mouse handling, sprites (bitmaps),
  478. compiled bitmaps, and supports a number of resolutions.  The version number
  479. ('06') is current as of November 1993.
  480.  
  481.  
  482. graphprg.zip
  483.  
  484. Michael Abrash' articles in Doctor Dobbs Journal is always mentioned
  485. with awe.  In this 350 Kb archive, most of his interesting stuff has
  486. been gathered.  Read about Mode X development and techniques from month
  487. to month.  Included is also all the individual source code snippets from
  488. each article, and also the full XSHARP library providing linedrawing,
  489. polygons, bitmaps, solid 3D projection and speedy rendering, and even an
  490. implementation of 2D texture mapping (can be used for quasi-3D texture
  491. mapping), plus an article on assembly optimization on the i86 processor
  492. family.  Definitely recommended.
  493.  
  494.  
  495. oak.oakland.edu:/pub/msdos/vga/vgadoc2.zip
  496.  
  497. This is a bare bones VGA register reference.  It also contains register
  498. references for the CGA, EGA and Hercules cards, in addition to dozens of
  499. SuperVGAs.  Check out the BOOKS section for some decent VGA references
  500. though - you don't want to start tweaking without a real one.
  501.  
  502.  
  503. wuarchive.wustl.edu:/pub/MSDOS_UPLOADS/programming/tweak15b.zip
  504.  
  505. TWEAK might be of interest to the more adventurous reader.  TWEAK lets you
  506. play around with the registers of the VGA in an interactive manner.
  507. Various testing screens for viewing your newmade modes are applied at
  508. the press of a key.  Version 1.5 adds a test screen which autodetects your 
  509. graphics mode and displays various information about resolutions etc.
  510. Keep a VGA reference handy.  Don't try it if this is the first time you've 
  511. heard of 'registers' or 'mode X' or 'tweaking'.  I was planning a version
  512. based on the Turbo Vision interface, but time has been short.  Maybe later!
  513.  
  514.  
  515.  
  516.  
  517. 4. BOOKS ON THE SUBJECT
  518.  
  519. Extremely little has been published in written form about using
  520. 'Mode X'-style modes.  Below are some books which cover VGA programming
  521. at varying degrees of technical level, but the only one to mention
  522. unchained modes and Mode X, is Michael Abrash'.  I'd get one of the VGA
  523. references first, though.
  524.  
  525.   o  George Sutty & Steve Blair : "Advanced Pogrammer's Guide to the
  526.      EGA/VGA" from Brady.  A bit old perhaps, but covers all *standard*
  527.      EGA/VGA registers, and discusses most BIOS functions and other
  528.      operations.  Contains disk with C/Pascal/assembler source code.
  529.      There's a sequel out for SuperVGAs, which I haven't seen.
  530.  
  531.   o  Michael Abrash : "Power Graphics Programming" from QUE/Programmer's
  532.      Journal.  Collections of (old) articles from Programmer's Journal on
  533.      EGA/VGA, read modes and write modes, animation, tweaking (320x400
  534.      and 360x480).  His newer ravings in DDJ covers fast 256-color
  535.      bitmaps, compiled bitmaps, polygons, 3D graphics, texture mapping
  536.      among other stuff.
  537.  
  538.   o  Richard F. Ferraro : "Programmer's Guide to the EGA and VGA video
  539.      cards including Super VGA".  I don't have this one, but heard it's
  540.      nice.  Detailed coverage of all EGA/VGA registers.  The Super VGA
  541.      reference makes it attractive.
  542.  
  543.   o  Richard Wilton : "Programmer's Guide to PC & PS/2 Video Systems"
  544.      Less technical, more application/algorithm oriented.  Nice enough,
  545.      even though it is a bit outdated, in that he discusses CGA and
  546.      Hercules cards just as much as EGA/VGA.
  547.  
  548.  
  549.  
  550.  
  551. 5. BYE - FOR NOW
  552.  
  553. I am considering writing a text describing in more detail the process of
  554. using TWEAK to achieve the VGA resolution you want or need.  However, I
  555. thought I'd let this document go first, and see if I get any reactions.
  556. If I don't, I'll stop.  Feel free to forward any suggestions,
  557. criticisms, bombs and beers.
  558.  
  559. I can be reached via:
  560.  
  561.   o  e-mail: robert@stud.unit.no
  562.  
  563.   o  land mail:
  564.  
  565.      Robert Schmidt
  566.      Stud.post 170
  567.      NTH
  568.      N-7034 Trondheim
  569.      NORWAY
  570.  
  571. Nothing would encourage or please me more than a postcard from where you
  572. live!
  573.  
  574. ┌───────────┬────────────────────────────────────────────────────────────────
  575. │ M1ORG.ASC │
  576. └───────────┘
  577.  
  578. Figure 1: Memory organization in mode 13h (ASCII version)
  579.           by Robert Schmidt
  580.           (C) 1993 Ztiff Zox Softwear
  581.  
  582. a. Imagine that the top of the screen looks like this (pixel values are
  583.    represented by color digits 0-9 for simplicity - actual colors may
  584.    range from 0 to 255) - a screen width of 320 pixels is assumed:
  585.  
  586.     address:  0         10                310      319
  587.              ----------------------------------------
  588.              |0123456789012345    .....   0123456789|
  589.              |                                      |
  590.              |                                      |
  591.              |
  592.  
  593. b. In VGA memory, the screen is represented as follows (question marks
  594.    represent unused bytes):
  595.  
  596.    Plane 0:
  597.  
  598.     address:  0         10                310      319
  599.              ----------------------------------------
  600.              |0???4???8???2???    .....   ??2???6???|
  601.              |                                      |
  602.              |                                      |
  603.  
  604.    Plane 1:
  605.  
  606.     address:  0         10                310      319
  607.              ----------------------------------------
  608.              |?1???5???9???3??    .....   ???3???7??|
  609.              |                                      |
  610.              |                                      |
  611.  
  612.    Plane 2:
  613.  
  614.     address:  0         10                310      319
  615.              ----------------------------------------
  616.              |??2???6???0???4?    .....   0???4???8?|
  617.              |                                      |
  618.              |                                      |
  619.  
  620.    Plane 3:
  621.  
  622.     address:  0         10                310      319
  623.              ----------------------------------------
  624.              |???3???7???1???5    .....   ?1???5???9|
  625.              |                                      |
  626.              |                                      |
  627.  
  628.    I.e. a plane is selected automatically by the two least significant
  629.    bits of the address of the byte being read from or written two.
  630.    This renders 3/4 of the video memory unavailable and useless, but
  631.    all visible pixels are easily accessed, as each address in the video
  632.    segment provides access to one and ONLY ONE pixel.
  633.  
  634. ┌───────────┬────────────────────────────────────────────────────────────────
  635. │ MXORG.ASC │
  636. └───────────┘
  637.  
  638. Figure 2: Memory organization in unchained 256-color modes (like
  639.           Mode X) (ASCII version)
  640.           by Robert Schmidt
  641.           (C) 1993 Ztiff Zox Softwear
  642.  
  643.  
  644. Imagine that the screen looks the same as in figure 1a.  A screen width
  645. of 320 pixels is still assumed.
  646.  
  647. In VGA memory, the screen will be represented as follows:
  648.  
  649.    Plane 0:
  650.  
  651.     address:  0         10                70       79 (NOT 319!)
  652.              ----------------------------------------
  653.              |0482604826048260    .....   0482604826|
  654.              |                                      |
  655.              |                                      |
  656.  
  657.    Plane 1:
  658.  
  659.     address:  0         10                70       79
  660.              ----------------------------------------
  661.              |1593715937159371    .....   1593715937|
  662.              |                                      |
  663.              |                                      |
  664.  
  665.    Plane 2:
  666.  
  667.     address:  0         10                70       79
  668.              ----------------------------------------
  669.              |2604826048260482    .....   2604826048|
  670.              |                                      |
  671.              |                                      |
  672.  
  673.    Plane 3:
  674.  
  675.     address:  0         10                70       79
  676.              ----------------------------------------
  677.              |3715937159371593    .....   3715937159|
  678.              |                                      |
  679.              |                                      |
  680.  
  681. Note that if pixel i is in plane p, pixel i+1 is in plane (p+1)%4.
  682. When the planes are unchained, we need to set the Write Plane Enable
  683. register to select which planes should receive the data when writing,
  684. or the Read Plane Select register when reading.  As is evident, one 
  685. address in the video segment provides access to no less than FOUR
  686. different pixels.
  687.  
  688. ┌───────┬───────────────────────────────────────────────────────────────────
  689. │ Zox3D │
  690. └───────┘
  691.  
  692. Available via ftp :
  693. ftp.wustl.edu:/pub/MSDOS_UPLOADS/games/programming/zox3d15.zip
  694. wasp.eng.ufl.edu:/pub/msdos/demos/<somewhere>/zox3d15.zip
  695.  
  696. zox3d15.zip contains a demo of my 3D graphics engine.
  697. It resembles Wolf3D, but has a number of additional
  698. features:
  699.  
  700. - texture mapped floor and ceiling (sky, in this demo)
  701. - real, recursive MIRRORS!
  702. - partly TRANSPARENT walls
  703. - input from keyboard, joystick and mouse (at the same
  704.   time, too, if you wish)
  705. - controllable camera height - NOT fixed like Wolf3D
  706. - quick resizable window
  707. - online help and fps rating
  708. - advanced collision detection and handling
  709. - supports a variety of tweaked X modes, from 256x256 to 400x300.
  710.  
  711. The sky and mirrors have to be seen to be beleived!
  712.  
  713. Zox3D does NOT implement objects, like the guards in
  714. Wolf3D, but that should be a breeze to add.
  715.  
  716. The complete sources are available.  Read ZOX3D.DOC in
  717. the demo archive for information.
  718.  
  719. ────────────────────────────────────────────────
  720. Robert Schmidt - robert@stud.unit.no - Buuud@IRC
  721.