Universal Videogame List - www.uvlist.net

Text 40x48 characters
Anything over 280 points (pixels) of horizontal resolution can be considered "hires".
Text 80x48 characters (expansion card, standard in later models)
Lo-Res 40x48(40)x16
Double Lo-Res 80x48(40)x16
Pure Hi-Res 140x192(160)x6 (not UVL's "hires" tag)
Hi-Res 280x192(160)x6 (achieved via programming exploits, there is not actually more than 140 horizontal pixels)
Double Hi-Res 560x192(160)x2 (eligible for UVL's "hires" tag, but be sure to check the box for monochrome display)
Double Hi-Res 560x192(160)x6 (eligible for UVL's "hires" tag) (achieved via programming exploits)
Double Hi-Res 560x192(160)x16 (eligible for UVL's "hires" tag) (achieved via programming exploits and dithering hackerdry)
(4 lines of text space at the bottom could be switched on and off in graphic modes)

The Lo-Res modes where actually mapped to the text display memory, So the writing any text on the screen would produce unexpected results in the graphics, including the 4 lines at the bottom. The same would happen to text when graphics were displayed. However, since the text was separate from the hi-res modes, one could manipulate them separately without interfering with the other. It was especially convenient to change text in the 4 bottom lines while the graphics covered them then uncover the text when needed. Likewise the graphics could be changed while the bottom 4 lines of text were visible without effecting the text. In a way, the bottom lines could be thought of as an hideable docked tool bar.

The Double Hi-Res 560x192(160)x6 took special programming to utilize. In fact, it didn't officially exist in the Apple ]['s specs and many would argue it does not exist at all, but is just a kludge of programming tricks to fake 560 pixels from 140 actual pixels. Only 2 colors (black1, while1, black2, and while2, count them, 2) existed in this resolution. This was due to unusual quirks such an orange pixel turning white because the application drew a green pixel next to it. This was due to 'pixels' and memory not exactly lining up. Think of it as placing 60 inch squares adjacent to each other on an grid with 64 inch divisions (that's was an analogy, not a technical fact). A more technically accurate explanation would be to say that a colored pixel was 4 pixels wide and could occupy 560 horizontal positions on the screen but the colors themselves could only occupy 140 of those positions. In the digital world, the binary strings of color information were by default written across two pixels instead of a single one, which meant both pixels got a unique unintended color. To further complicate matters, some of the bits in the graphic memory were reserved for other uses. As a technical point, there is not actually enough video memory in an Apple ][ to keep track of 560x192x4 pixels; such attempts would spill the data into other areas of the Apple's memory. A programmer could actually be changing how the apple read from the disc drive in an effort to coax an unavailable color out of a certain pixel on the screen. Programming libraries eventually were created by enthusiasts that made it easier and safer to work around the quirks.