Format Name: Apple IIGS Super Hires Screen Image Used on: Apple IIGS only Size: 0x8000 bytes uncompressed. Compression: Optional, see "Apple Preferred Format," "PAK" formats Unpacks to: 320x200x16 colors or 640x200x4 colors or mix thereof; uses at most 256 colors from 4096 (2^12) possibilities. Filename Extensions: None defined (not used on Apple IIs) ProDOS Filetypes: Filetype $C0, Auxtype $0001 The Super Hires Screen Image is a raw memory dump of the video ram for this format on the Apple IIGS. Please note that the pixels defined by a straight unpacking are not square; duplicating each scanline to go to 640x400 will make the aspect ratio look normal on non-GS screens. Conventions: bit[7..0] is one byte, with 0 in the least significant place. A word is 2 bytes, least significant byte stored first in ram: bits[7..0], bits [15..8]. All hexadecimal numbers will be prefaced with the C-style '0x'; all other numbers may be assumed to be base 10. To read one word, this code fragment may help: short readword(char *ptr) { return ((*ptr) + ((*(ptr+1))<<8)); } Internally, the screen image is structered as follows relative to where it resides in memory at 0xe12000: 0x0000..0x7CFF: scanline information: 200 rows of 0xA0 bytes each 0x7D00..0x7DFF: 200 'scanline control bytes' (SCBs) plus 56 unused bytes 0x7E00..0x7FFF: 16 pallettes, 32 bytes each. Scanlines are stored in linear order, left to right, top to bottom. Offset 0x0000 is the top left corner, 0x009F the top right, 0x00A0 the leftmost byte of the second line, etc. The data in them is interpreted according to the SCBs and pallette info. SCBs are also in linear order (0x7D00 for top row, 0x7D01 for second row...) They affect the entire line. They have the following structure: Bit # Use 0..3 Pallette number (00..0x0F) 4 Reserved, should be 0 5 Fill Mode (1=on, 0=off) 6 Interrupts (1=generated, 0=not generated) 7 Number of pixels (0=320,1=640) The interrupt bit is only used by the video display hardware to generate an interrupt when that particular line on the screen is drawn. They do not affect the displayed picture. Fill mode only affects 320 mode; see below. Pallettes consist of 32 bytes each, each holding 16 words for color info in the following form: 0RGB, with the red component in bits 11..8, the green in bits 7..4, and the blue component in bits 3..0. A value of 0x0F for a color value means full intensity, 0x00 is no contribution. Further, words (2 bytes) are stored with the least significant byte first. For example, a color with Red=0x07, Green=0x0D, Blue=0x01 would be stored in memory as follows: 0xD1,0x07. Since there is at most one pallette per line, there is a limitation of 16 distinct colors per line. Further, with 16 pallettes that must be shared between the 200 lines, this limits the picture to at most 256 colors at once. With tricky interrupt work replacing pallettes as the vertical retrace is happening, it is possible to use a unique pallette per line (by reusing each pallette in turn); see the 3200 Color format description for the file format of those. Pallettes are further stored in linear order; to get the color value for a color, you can use: Offset=0x7E00+ 0x20 * PalletteNumber + 0x02 * ColorNumber A pixel is either 4 or 2 bytes wide, depending on whether the particular scanline is in 320 or 640 mode, respectively. They are also ordered according to the bit order from highest to lowest. For example, bits 7..4 are the left pixel from a 320 mode byte, and bits 0..3 are the right pixel. Although 640 mode only uses 4 colors, the remaining 12 entries in the pallette are used to get simple dithering. The bit numbers from the pixel byte determine which of 4 tables is used within each pallette: Bit Numbers Colors Referred to: 0-1 12-15 2-3 8-11 4-5 4-7 6-7 0-3 Fill mode is only usable in 320 mode for a line; in 640 mode, that bit is ignored. When on, the 0th color in the tabe is inactive, and is a signal to use the last displayed color on that line. For example, a line with fill mode on and the following color values 3 0 0 4 5 7 0 0 0 5 0 8 0 1 0 0 3 4 5 6 7 8 will be displayed exactly the same as 3 3 3 4 5 7 7 7 7 5 5 8 8 1 1 1 3 4 5 6 7 8 Description written by Nathan Mates (nathan@visi.com), August 1996.