One of the things that I've been reading lately is how 8-bit home computers did their graphics.
There was often a tradeoff between color resolution and horizontal resolution.
For example, the Atari 800 had a 320x192 mode that had 2 colors. If you wanted 4 colors, the horizontal resolution would be lowered to 160x192. If you wanted 16 colors, you could lower the resolution to 80x192.
The number of bytes per row would remain constant while the horizontal resolution and the color depth would vary inversely.
Graphics Antic Colors Resolution Memory (bytes) Display mode
mode mode
8 F 2 320 x 192 8138 Graphics
15 E 4 160 x 192 8138 Graphics
11 - 16 80 x 192 8138 Graphics
============================================The c64 had a standard bitmap mode:
http://dustlayer.com/vic-ii/2013/4/26/vic-ii-for-beginners-screen-modes-cheaper-by-the-dozen
https://www.c64-wiki.com/index.php/Standard_Bitmap_Mode
You had 320x200 8k bitmap with the color information for each 8x8 block of pixels stored in 1K of Screen Ram, basically a 40x25 cell color overlay.
==========================================
With the Spectrum ZX you had a 256x192 resolution with each 8x8 block having attributes that defined the foreground and background color out of 16 colors.
https://en.wikipedia.org/wiki/ZX_Spectrum_graphic_modes
============================================
And we have VGA text modes that use 2 bytes: 1 byte to define the character displayed, and another byte to define the foreground and background colors.
==========================================
I always wished that the Amiga had a text mode that would display lots of colors. It was disappointing that there were only 4 colors in a 640x200 Workbench.
It always bothered me that a computer that was supposed to be about colorful graphics couldn't display lots of colors at its highest resolution. The 1.3 workbench colors were pretty garish: blue, white, red and black. Workbench 2.0 colors were so bland: 3 shades of grey (black, grey, white) and blue.
The basic idea here is the same as chroma subsampling: https://en.wikipedia.org/wiki/Chroma_subsampling
"Chroma subsampling is the practice of encoding images by implementing less resolution for chroma information than for luma information, taking advantage of the human visual system's lower acuity for color differences than for luminance."
The big problem with the Amiga was that the chip bandwidth was limited. A 640x200 screen bitmap would take 16K of memory. Each bitplane would be 16K, and a 4 color Workbench would be 32K/frame.
What if the Amiga had a "color overlay" scheme similar to the VGA text screen. You could have a 640x200 screen bitmap consisting of 80 bytes, and a color overlay that uses 80 bytes as well (8 pixels per byte and for each cell you could choose 1 of the 16 possible foreground colors in the high nibble (addressing color registers 0-15, and 1 of 16 possible background colors specifying color register 16-31 in the low nibble). Something like this would have been good for a text screen, or ANSI color graphics. A scheme like this would use 24k of total memory, 16k for the foreground/background bitmap and 8k for the color attributes.
Or maybe you could have a "color overlay" with lower resolution bitmaps: A 640x200 bitmap screen, but with multiple 320x200 bitplanes that would provide additional color information. This would fit neatly into the Amiga bitplane design and allow you to have multiple 8K color planes. This would be a "hybrid" high-low resolution screen.
So for 640x200 with effectively 4 bitplanes of color (16 colors)
16K + 8k + 8k + 8k = 40K which is the same bandwidth as a 5 plane 320x200 screen.
And what if you had flexible bitplane sizing: like x1,x2,x4,x8 width pixels, you could reduce the memory requirement at the expense of color resolution on a per-plane basis.
So with x8 width pixels, a 80 pixel wide bitmap would only use 10 bytes/row instead of 80 bytes/row for x1 width pixels.
A 640x200 screen with x8 width pixel overlay of 4 additional color planes could do 80 + (4*10) or 120 bytes/row.
120*200 = 24K bandwidth/frame.
That would get you 32 colors (maxing out the Amiga's color registers), and with less bandwidth than a 4 color regular workbench.
===================================
It's interesting to study how the Amiga generated video. In the Amiga Hardware Reference manual section on the Blitter, it tells you how the chip memory DMA bandwidth is allocated.
For NTSC, there are 226 color clocks per line, each color clock acts as a "slot" for a 16-bit memory access, and having 452 bytes of total DMA bandwidth per line.
200 lines * 452 bytes/line = 90400 bytes per frame * 60 frames per second = 5,424,000 bytes per second.
The 68000 processor is ideally going to have access on the even slots, with the odd slots going to the custom chipset.
160 color clocks are allocated to the display generation. If that sounds familiar, the Atari 2600 TIA had 160 color clocks for the display generation and 68 color clocks for the horizontal blank.
=================================================
http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node012B.html
"The time-slot allocation per horizontal line is:
4 cycles for memory refresh
3 cycles for disk DMA
4 cycles for audio DMA (2 bytes per channel)
16 cycles for sprite DMA (2 words per channel)
80 cycles for bitplane DMA (even- or odd-numbered slots
according to the display size used)
Figure 6-9 shows one complete horizontal scan line and how the clock
cycles are allocated.
Figure 6-9: http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node02D4.html
(I took the liberty of fixing some typos in the diagram: 420->320 and d6->d8 and se0->$e0)
If the display contains four or fewer low resolution bitplanes, the 68000
can be granted alternate memory cycles (if it is ready to ask for the
cycle and is the highest priority item at the time). However, if there are
more than four bitplanes, bitplane DMA will begin to steal cycles from the
68000 during the display.
During the display time for a six bitplane display (low resolution, 320
pixels wide), 160 time slots will be taken by bitplane DMA for each
horizontal line. As you can see from Figure 6-11, bitplane DMA steals 50
percent of the open slots that the processor might have used if there were
only four bitplanes displayed.
- timing cycle -
T T + 7
+ * + *
_______________________________________________________________
| | | | | | | | |
| | 4 | 6 | 2 | | 3 | 5 | 1 |
|_______|_______|_______|_______|_______|_______|_______|_______|
Figure 6-11: Time Slots Used by a Six Bitplane Display
If you specify four high resolution bitplanes (640 pixels wide), bitplane
DMA needs all of the available memory time slots during the display time
just to fetch the 40 data words for each line of the four bitplanes
(40 * 4 = 160 time slots). This effectively locks out the 68000 (as well
as the blitter or Copper) from any memory access during the display,
except during horizontal and vertical blanking .
- timing cycle -
T T + 7
_______________________________________________________________
| | | | | | | | |
| 4 | 2 | 3 | 1 | 4 | 2 | 3 | 1 |
|_______|_______|_______|_______|_______|_______|_______|_______|
Figure 6-12: Time Slots Used by a High Resolution Display
============================================================Ideally, a display would use 80 cycles, with every other cycle going to the CPU or the blitter, but display generation that requires more than 160 bytes per line can gobble up additional slots, up to 160 cycles (320 bytes per line).
That's why you only get 4 colors on a standard 640x200 workbench, because that allows the CPU to run on every even chip memory cycle.
A 16 color 640x200 screen would essentially consume the entire chip memory bandwidth during the display, effectively locking out the cpu. That explains why the system gets very slow when using such a screen.
So any scheme that would boost colors and relieve memory bandwidth requirements would help. There would be tradeoffs, surely the hardware and the programming would have more complexity, and you'd have artifacting but you would have more flexibility too. If you were clever with the alignment of windows, graphics and text to fill lo-res pixels it would be less noticeable.
I suppose that it doesn't matter now with all of the memory bandwidth and truecolor modern graphics of today, but it would've been a neat trick back in the day.
