home *** CD-ROM | disk | FTP | other *** search
/ Esprit de Apple Corps / EDAC-2.iso / Graphics / Apps / Demos / Maxcolor / Max.Color / Maxcolor.Readme.txt < prev   
Text File  |  1988-01-30  |  5KB  |  78 lines
  1.  -=[ MAXCOLOR   Copyright 1988 Jason Harper   CompuServe 76703,4222 ]=-
  2.  
  3. PURPOSE:
  4. To display the absolute maximum number of simultaneous onscreen colors that
  5. the Apple IIgs SuperHiRes graphics modes can handle: 3200.
  6.  
  7. SYSTEM REQUIREMENTS:
  8. Apple IIgs, 256K memory, must be running at fast speed.  Will not work
  9. properly if a desk accessory or other program is currently using an
  10. interrupt-driven background task (such as Alternate Display Mode).
  11.  
  12. USAGE:
  13. Run from the Launcher or Finder or anything else that is capable of running
  14. ProDOS 16 programs.  This program is slightly dangerous, so use it at your own
  15. risk if you have any important files on a RAMdisk that haven't been backed up.
  16. You should get a screen with 3200 colors used (count 'em): if there is any
  17. flicker, there is interference from another program or desk accessory.  At
  18. this point you can press the Escape key to exit the program, or the space bar
  19. to toggle to/from another screen with a different set of 3200 colors.  Between
  20. the two screens, all of the IIgs's 4096 displayable colors are used.
  21.  
  22. WHAT'S GOING ON HERE:
  23. Colors on the IIgs are specified in terms of their red, green, and blue
  24. components.  Each component has 16 possible values ranging from 0 (0% of this
  25. component) to 15 (100% of this component), for a total of 16 x 16 x 16 = 4096
  26. distinct colors.  Any one horizontal line of pixels can use at most 16 colors
  27. (the entire palette for the line is read during horizontal retrace, so it's
  28. impossible to change palettes in mid-line), so on the 200-pixel high screen at
  29. most 16 x 200 = 3200 colors can be displayed.  However, only 16 separate
  30. palettes of 16 colors each (= 256 colors total) are available, so the program
  31. has to contantly modify the 16 palettes.  Just changing the red component in
  32. all 16 colors of each palette every 16 scanlines takes about 90% of the
  33. processor time, so this technique doesn't have much practical use.
  34.  
  35. WHAT YOU'RE SEEING:
  36. The display generated by this program is divided horizontally into 16 bands,
  37. 20 pixels wide each.  All pixels in each band have the same blue component,
  38. ranging from 0 in the leftmost band to 15 in the rightmost.  Vertically, each
  39. group of 16 scanlines ranges from 0 to 15 in the green component.  Thus a
  40. rectangular area as wide as the screen and 16 pixels high contains all 256
  41. permutations of green and blue components.  Twelve and a half such regions
  42. completely fill the screen, each one having a distinct red component.  On the
  43. initial screen, the red component ranges from 0 in the top region to 12 in the
  44. bottom (half-size) region.  The alternate screen, accessed by pressing the
  45. space bar, has red components ranging from 15 down to 3.  The total number of
  46. distinct colors is 16 (blues) x 16 (greens) x 12.5 (reds) = 3200.
  47.  
  48. HOW IT'S DONE:
  49. With scanline interrupts, 26 of them per frame (1/60 second), set for every
  50. 8th scanline plus the very last scanline.  Only one scanline at a time has the
  51. interrupt bit set in its SCB (Scanline Control Byte): the interrupt handler
  52. clears the bit in the SCB of the current line, and sets it in the next line
  53. that an interrupt is scheduled for.  Each interrupt causes the red component
  54. of half of the color entries (16 colors in 8 palettes) to be changed.  The
  55. even-numbered interrupts (occurring on line 0 out of each group of 16) change
  56. the colors for the bottom 8, and the odd interrupts (occurring on line 8 out
  57. of each 16) change the top 8: thus there is no chance of a palette being
  58. modified before it is needed, unless something delays the handling of the
  59. interrupt long enough that it overlaps the following interrupt.  Modifying 128
  60. color palette entries within the half millisecond it takes to display 8
  61. scanlines of video was rather challenging.  I chose red as the color component
  62. to vary with interrupts because it is represented in memory in a separate byte
  63. from the green and blue components: I can therefore accomplish the change by
  64. storing a single value (0-15) in every other byte of the appropriate part of
  65. the color palette area ($E1/9E00-9FFF).  There simply isn't enough time to do
  66. this with any sort of loop or indexing: I have to use 128 'STA absolute'
  67. instructions, with the data bank register set to $E1.  There are two sets of
  68. 128 such instructions, one for the top and one for the bottom half of the
  69. color palettes.  Even then, the IIgs's interrupt handling mechanism takes too
  70. long to recognize that a scanline interrupt has occurred and to dispatch to my
  71. routine, causing the screen to flicker wildly (although I should point out that
  72. the interrupt dispatcher has to handle numerous IRQ sources: some of them are
  73. simply going to have more latency than others).  So instead of hooking into
  74. the scanline IRQ vector, my routine hooks into the system IRQ handler vector
  75. (therefore getting control within a dozen cycles of the interrupt), and passes
  76. any non-scanline interrupts to the original handler: not quite by-the-book,
  77. but there wasn't much choice.
  78.