home *** CD-ROM | disk | FTP | other *** search
/ The Fatted Calf / The Fatted Calf.iso / Applications / Misc / a2 / Source / README.GRAPHICS < prev    next >
Encoding:
Text File  |  1992-03-13  |  4.3 KB  |  88 lines
  1. I picked this emulator up off the net somewhere and hacked in some
  2. reasonably fast hires support.  I wasn't thinking about adding text,
  3. lo-res, double hi-res, etc, when I wrote it.  Consequently, if this
  4. looks like a gross hack that was grafted on to another program, it is.
  5. I didn't originally write these routines for public consumption, but
  6. some of you are interested in it, so here it is.
  7.  
  8.  
  9. Hastily scrawled technical explanation: How the hi-res support works.
  10. ---------------------------------------------------------------------
  11.  
  12. ObBenchmark: this emulator can fill the entire screen with a color and
  13. display it in grayscale on the NeXT screen in about .5 seconds.  This
  14. is about 1/4 as fast as an Apple ][.  I believe most of this
  15. inefficiency is in the 6502 emulator (just look what it does when they
  16. reference $C000!)
  17.  
  18. The interface is entirely bogus.  A window containing only a "WozView"
  19. appears.  It lets you continually view HGR page 1 regardless of what
  20. graphics mode the Apple ][ is really in.  Simultaneously the emulator
  21. is doing its own termcap thing somewhere.
  22.  
  23. The WozView keeps track of a 2 bpp bitmap with 288x192 pixels.  (It's
  24. 288 pixels wide instead of 280 because I wanted each row to be a
  25. multiple of 4 bytes wide; 288/(4 pixels/byte) == 72 bytes, 72 % 4 == 0).
  26. The extra pixels are outside of the NeXTstep window, so you can't
  27. see them anyway.
  28.  
  29. Periodically, the emulator is halted and a routine is called which
  30. compares the last hires screen displayed to the contents of
  31. $2000-$3FFF.  It marks the areas that have changed and converts them
  32. from Apple ][ format to NeXT format (in the WozView's frame buffer,
  33. which it makes public.)  The WozView is then told which areas have
  34. changed and asked to update the screen with its version of the bitmap.
  35. The reason the WozView doesn't do the conversion itself is that I
  36. wanted the WozView to be just a frame buffer that other sections
  37. (text, lo-res, hi-res) could modify and display in a reasonably clean
  38. and efficient way.
  39.  
  40. The way the Apple ][ graphics are actually converted is strange and
  41. wondrous.  [Check out hgrconv.c].  There are two different modes:
  42.  
  43. 1) Monochrome.  Each byte on the Apple ][ hires screen contains 7
  44. pixels and one color bit.  These 7 bits are converted to 14 bits via a
  45. lookup table and then blasted to the WozView's frame buffer in the
  46. right place.  This actually happens by packaging together the
  47. sequences of 14 bits into longs and blasting them out together, so the
  48. minimum number of memory writes are made.
  49.  
  50. 2) Color.  Apple ][ color is weird.  The mapping from Apple ][ to NeXT
  51. won't always be perfect, but I made the best approximation I could.
  52.  
  53. - A NeXT pixel will be black if the a2 pixel is off, and neither
  54.   neighbor is an on, colored pixel.
  55. - A NeXT pixel will be white if the corresponding a2 pixel is on AND either
  56.   1) A neighboring a2 pixel is on, or
  57.   2) All a2 pixels <= 2 pixels away are off.  The point of this is to make
  58.      vertical lines that are one pixel wide look white.  Just a heuristic.
  59. - A NeXT pixel will be colored if either
  60.   1) The a2 pixel is off and a neighboring a2 pixel is both on and its
  61.      corresponding NeXT pixel is colored, or
  62.   2) The a2 pixel is on, neither neighbor is on, but a pixel 2 away is on.
  63.  
  64. Which color is used depends on whether or not the pixel is an even- or
  65. an odd-numbered pixel.  Since the NeXT bitmap only has 2 bits per
  66. pixel, the high bit of each byte is ignored.  This means blue and
  67. green look the same, as do violet and orange.  I doubt this will often
  68. be a problem.
  69.  
  70. makehgrtable.c generates two 32K lookup tables which map 14 Apple ][
  71. bits to 7 NeXT pixels via the above algorithm (one table for odd
  72. bytes, one for even.)  The reason it maps 14->7 instead of 7->7 is
  73. that the neighbors of the boundary pixels are required to tell what
  74. color the boundary pixels should be.  One of those 14 bits (the color
  75. bit for one of the bytes being considered) is ignored, so really we
  76. are converting 13 Apple ][ pixels to 7 NeXT pixels.  Consider the
  77. following diagram listing the bits to be converted:
  78.  
  79. xxx0123456xxx
  80.  
  81. Here 0,1,2,3,4,5,6 represent pixels to be converted, and the x's are
  82. just there to provide more information for how to color those pixels..
  83. The proof that you really need 3 x's on each side instead of just 2 is
  84. left as an exercise to the reader.  :-)
  85.  
  86.  
  87. -Mat  (mjhostet@athena.mit.edu)
  88.