[continued from previous message]   
      
   >> More just interesting that I was able to get things "almost half-way   
   >> passable" from 1 bpp monochrome.   
   >>   
   >>   
   >> ...   
   >>   
   >>   
   >>   
   > I think your support for graphics is interesting; something to keep in   
   > mind for displays with limited RAM.   
   >   
   > I use a high-speed DDR memory interface and video fifo (line cache).   
   > Colors are broken into components specifying the number of bits per   
   > component (up to 10) in CRs. Colors are passed around as 32-bit values   
   > for video processing. Using the colors directly is much easier than   
   > dealing with dithered colors.   
   > The graphics accelerator just spits out colors to the frame buffer   
   > without needing to go through a dithering stage.   
   >   
      
      
   No real need to go much beyond RGB555, as the FPGA boards have VGA DACs   
   that generally fall below this (Eg: 4 bit/channel on the Nexys A7). And,   
   2-bit for many VGA PMods (PMod allowing 8 IO pins, so RGB222+H/V Sync;   
   or needing to use 2 PMOD connections for the VGA). The usual workaround   
   was also to perform dithering while driving the VGA output (with ordered   
   dither in the Verilog).   
      
   But, yeah, even the theoretical framebuffer images generally look better   
   than what one sees on actual monitors.   
      
   Even then, modern LCD panels mostly can't display even full RGB24 color   
   depth; more often it is 6-bit / channel or similar (then the panels   
   dither for full 24). But, IIRC a lot of OLEDs are back up to full   
   color-depth (but, OLEDs are more expensive and have often had a   
   notoriously short lifespans, ...).   
      
   But, yeah, my current monitor seems to be LCD based.   
      
      
      
   In my case, the video HW uses prefetch requests along a ring-bus, which   
   goes to the L2 cache, and then to external RAM. It then works on hope   
   that the requests get around the bus and can be resolved in time.   
      
   In this case, the memory works in a vaguely similar way to the CPU's L1   
   caches (although with line-oriented access), and a module that   
   translates this to color-values during screen refresh. General access   
   pattern was built around "character cells".   
      
      
   It can give stable results at 8MB/s to 16MB/s (with more glitches as it   
   goes higher), but breaks down too much past this point.   
      
   So, switching to a RAM backed framebuffer didn't significantly usable   
   increase screen resolutions or color depths.   
      
   Also, I am mostly limited to using either either a 25 or 50 MHz pixel   
   clock, so some timings were tweaked to fit this. Doesn't really fit   
   standard VESA timings, but it seems like monitors can tolerate   
   nonstandard timings, and are more limited to operating range.   
      
   So, say:   
      320x200 70Hz, 25MHz; 9MB/s @ 16bpp (hi-color)   
      640x400 70Hz, 25MHz; 9MB/s @ 4bpp, 18 MB/s @ 8bpp   
      640x480 60Hz, 50Mhz; 9MB/s @ 4bpp, 18 MB/s @ 8bpp   
      800x600 72Hz, 50Mhz; 8.6 MB/s @ 2bpp, 17 MB/s @ 4bpp   
      1024x768 48Hz, 50Mhz, 5MB/s @ 1bpp, 10MB/s @ 2bpp   
      
   So, this implies that just running 1024x768 at 2bpp should be acceptable   
   (even if it exceeds the usual 128K limit).   
      
      
   Earlier on, I had an 800x600/36Hz, and 1024x768/25Hz, these would have   
   allowed 8bpp color, but are below the minimum refresh rate of most   
   monitors (seems like VGA monitors don't like going below around 40Hz).   
      
      
   Of these modes, 8bpp (Indexed color) is technically newest.   
      Originally the graphics hardware was written for color-cell.   
      
   Earliest design had 32-bit cells (for 8x8 pixels):   
      10 bits: Glyph   
      2x 6b color  + Attrib (RGB222)   
      2x 9b Color: RGB333   
      
   was later expanded first to 64b cells, then to 128b and 256b   
      Some control bits effect cell size.   
        Also with ability to specify 8x8 or 4x4 cells.   
          Where, 4x4 cells reduce the effective resolution.   
      In the bitmap modes:   
        4x4 + 256b: 16bpp Hicolor   
        4x4 + 128b: 8bpp Indexed   
        4x4 + 64b: 4bpp RGBI (Alt2)   
        8x8 + 256b: 4bpp RGBI (Alt1)   
        8x8 + 128b: 2bpp (4-color, CGA-like)   
          With a range of color palettes available (more than CGA).   
          Black/White/Cyan/Magenta, Black/White/Red/Green, ...   
          Black/White/DarkGray/LightGray, also with Green and Amber, ...   
        8x8 + 64b: 1bpp (Monochrome)   
          Can select between RGBI colors and some special sub-modes.   
          The recent idea, if added to HW, would slot into this mode.   
      The color-cell modes:   
        8x8 + 256b: 4bpp (DXT1 like, 4x 4x4 cells per 256-bit cell)   
        8x8 + 128b: 2bpp (2bpp cells)   
          Each cell has 2x RGB555 colors, and 8x8x1 for pixel data   
          Had experimented with 8x RGB232,   
            didn't catch on (looked terrible).   
        8x8 + 64b: Text-Mode + Early Graphics (4x4 cells)   
      
      
   Generally, the text mode operates in a 640x200 mode with 8x8 + 128b   
   cells, so 32K of VRAM used (for 80x25 cells).   
      
   The 640x200 mode is the same as 640x400 (for VGA) but with the vertical   
   resolution halved. The 320x200 mode also halves the horizontal   
   resolution (so 40x25 cells).   
      
      
   In this case, a 40x25 color-cell mode (with 256-bit cells) could be used   
   for graphics (32K). Early on, this was used as the graphics mode for   
   Doom and similar, before I later expanded VRAM to 128K and switched to   
   320x200 Hicolor.   
      
      
   The bitmap modes are non-raster, generally with pixels packed into 8x8   
   or 4x4 blocks.   
   4x4:   
      16bpp: pixels in raster order.   
       8bpp: raster order, 32-bits per row   
       4bpp: Raster order, 16-bits per row   
   And, 8x8:   
       4bpp: Takes 16bpp layout, splits each pixel into 2x2.   
       2bpp: Takes  8bpp layout, splits each pixel into 2x2.   
       1bpp: Raster order, 1bpp, but same order as text glyphs.   
         With MSB in upper left, LSB in lower right.   
      
   Can note that the 8x8x1b cells have the upper-left corner in the MSB.   
   This differs from most other modes where the upper left corner is in the   
   LSB (so, pixels flipped both horizontally and vertically).   
      
      
   Can note that in this case, the video memory had several parts:   
      VRAM / Framebuffer   
        Note: Uses 64-bit word addressing.   
      Font RAM: Stores character glyphs as 8x8 patterns.   
        Originally, there was a FontROM, but I dropped this feature.   
        This means BootROM needs to supply the initial glyph set.   
          I went with 5x6 pixel cells in the ROM to save space.   
          Where 5x6 does ASCII well enough.   
      Palette RAM: Stores 256x 16-bits (as RGB555).   
      
   Though, TestKern typically uses what is effectively color-cell graphics   
   for the text mode (so, just draws 8x8 pixel blocks for the character   
   glyphs).   
      
      
   All this differs notably from CGA/EGA/VGA, which had used mostly   
   raster-ordered modes. Except for the oddity of bit-planes for 16 color   
   modes in EGA and VGA.   
      
      
   I did experiment with raster ordered modes which worked by effectively   
   stretching the character cell horizontally while reducing vertical   
   height to 1 pixel. Ended not going with this was it was prone to a lot   
   more glitches with the screen refresh (turned out to be a lot more   
   sensitive to timing than the use of 8x8 or 4x4 cells).   
      
   But, since generally programs don't draw directly into VRAM, the use of   
   non-raster VRAM is mostly less of an issue.   
      
      
   Well, apart from the computational cost of converting from internal   
   RGB555 frame-buffers. Though, partial reason RGB555 ended up used so   
   often was because it was faster to do RGB555 -> ColorCell encoding than   
   8-bit indexed color to color-cell, as indexed color typically also   
   requires a bunch of palette lookups (which could end up more expensive   
   than the additional RAM bandwidth from the RGB555).   
      
   Also, there isn't really a "good and simple" way to generalize 8-bit   
   colors in a way that leads to acceptable image quality. Invariably, one   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)