User Tools

Site Tools


base:built_in_screen_modes
no way to compare when less than two revisions

Differences

This shows you the differences between two versions of the page.


base:built_in_screen_modes [2015-04-17 04:30] (current) – created - external edit 127.0.0.1
Line 1: Line 1:
 +(Pasted from the Vic Article, and comments by Oswald/Resource added in //italics//.)
 +
 +====== Hires text mode ======
 +
 +//(You'd generally set this up with: $d011=$1b, $d016=$8)//
 +
 +In this mode (as in all text modes), the VIC reads 8 bit character pointers
 +from the video matrix that specify the address of the dot matrix of the
 +character in the character generator. A character set of 256 characters is
 +available, each consisting of 8×8 pixels which are stored in 8 successive
 +bytes in the character generator. 
 +
 +In standard text mode, every bit in the character generator directly
 +corresponds to one pixel on the screen. The foreground color is given by
 +the color nybble from the video matrix for each character, the background
 +color is set globally with register $d021.
 +
 +<code>
 + +---------------------------------------+
 + | "0": Background color 0 ($d021)       |
 + | "1": Color from bits 8-11 of c-data   |
 + +---------------------------------------+
 +</code>
 +
 +====== Multicolor text mode ======
 +
 +//(You'd generally set this up with: $d011=$1b, $d016=$18)//
 +
 +This mode allows for displaying four-colored characters at the cost of
 +horizontal resolution. If bit 3 of the corresponding $d800 color is zero, the character is
 +displayed as in standard text mode with only the colors 0-7 available for
 +the foreground. If bit 3 of the corresponding $d800 color is 1, each two adjacent bits of the dot matrix form one pixel. By this means, the resolution of a character of reduced to
 +4×8 (the pixels are twice as wide, so the total width of the characters
 +doesn't change).
 +
 +//It is interesting that not only the bit combination "00" but also "01" is
 +regarded as "background" for the sprite priority and collision detection.//
 +
 +<code>
 + +---------------------------------------+
 +         (1 bit/pixel)                 |
 +                                       | Multicolor flag($d016) = 0
 + | "0": Background color 0 ($d021)       |
 + | "1": Color from bits 8-10 of c-data   |
 + +---------------------------------------+
 +         (2 bits/pixel)                |
 +                                       |
 + | "00": Background color 0 ($d021)      | Multicolor flag ($d016)= 1
 + | "01": Background color 1 ($d022)      |
 + | "10": Background color 2 ($d023)      |
 + | "11": Color from bits 8-10 of c-data  |
 + +---------------------------------------+
 +</code>
 +
 +====== Hires bitmap mode ======
 +
 +//(You'd generally set this up with: $d011=$3b, $d016=8)//
 +
 +In this mode (as in all bitmap modes), the VIC reads the graphics data from
 +a 320×200 bitmap in which every bit corresponds to one pixel on the screen.
 +The data from the screen memory is used for color information. As the screen
 +memory is still only a 40×25 matrix, you can only specify the colors for
 +blocks of 8×8 pixels individually (sort of a YC 8:1 format). As the
 +designers of the VIC wanted to realize the bitmap mode with as little
 +additional circuitry as possible (the VIC-I didn't have a bitmap mode), the
 +arrangement of the bitmap in memory is somewhat weird: In contrast to
 +modern video chips that read the bitmap in a linear fashion from memory,
 +the VIC forms an 8×8 pixel block on the screen from 8 successive bytes of
 +the bitmap. The video matrix and the bitmap can be moved in memory with the
 +bits VM10-VM13 and CB13 of register $d018.
 +
 +In standard bitmap mode, every bit in the bitmap directly corresponds to
 +one pixel on the screen. Foreground and background color can be arbitrarily
 +set for every 8×8 block.
 +
 +<code>
 + +---------------------------------------+
 +         8 pixels (1 bit/pixel)        |
 +                                       |
 + | "0": Color from bits 0-3 of screen mem|
 + | "1": Color from bits 4-7 of screen mem|
 + +---------------------------------------+
 +</code>
 +
 +====== Multicolor bitmap mode ======
 +
 +//(You'd generally set this up with: $d011=$3b, $d016=$18)//
 +
 +Similar to the multicolor text mode, this mode also forms (twice as wide)
 +pixels by combining two adjacent bits. So the resolution is reduced to
 +160×200 pixels.
 +
 +//The bit combination "01" is also treated as "background" for the sprite
 +priority and collision detection, as in multicolor text mode.//
 +
 +<code>
 + +----------------------------------------+
 +         (2 bits/pixel)                 |
 +                                        |
 + | "00": Background color 0 ($d021)       |
 + | "01": Color from bits 4-7 of screen mem|
 + | "10": Color from bits 0-3 of screen mem|
 + | "11": Color from bits 8-11 of color mem|
 + +----------------------------------------+
 +</code>
 +
 +====== ECM text mode (aka 'extended background colors') ======
 +
 +//(You'd generally set this up with: $d011=$5b, $d016=8)//
 +
 +This text mode is the same as the standard text mode, but it allows the
 +selection of one of four background colors for every single character. The
 +selection is done with the upper two bits of the character pointer. This,
 +however, reduces the character set from 256 to 64 characters.
 +
 +<code>
 + +---------------------------------------+
 +        (1 bit/pixel)                  |
 +                                       |
 + | "0": Depending on bits 6/7 of char ptr|
 +      00: Background color 0 ($d021)   |
 +      01: Background color 1 ($d022)   |
 +      10: Background color 2 ($d023)   |
 +      11: Background color 3 ($d024)   |
 + | "1": Color from bits 8-11 of c-data   |
 + +---------------------------------------+
 +</code>
 +
 +====== Invalid text mode (ECM/BMM/MCM=1/0/1) ======
 +
 +//Setting the ECM and MCM bits simultaneously// doesn't select one of the
 +"official" graphics modes of the VIC but creates only black pixels.
 +Nevertheless, the graphics data sequencer internally generates valid
 +graphics data that can trigger sprite collisions even in this mode. By
 +using sprite collisions, you can also read out the generated data (but you
 +cannot see anything, the screen is black). You can, however, only
 +distinguish foreground and background pixels as you cannot get color
 +information from sprite collisions.
 +
 +The generated graphics is similar to that of the multicolor text mode, but
 +the character set is limited to 64 characters as in ECM mode.
 +
 +
 +====== Invalid bitmap mode 1 (ECM/BMM/MCM=1/1/0) ======
 +
 +//(Ie, setting ECM mode and Bitmap mode on at the same time)//
 +
 +This mode also only displays a black screen, but the pixels can also be
 +read out with the sprite collision trick.
 +
 +The structure of the graphics is basically as in standard bitmap mode, but
 +the bits 9 and 10 of the g-addresses are always zero due to the set ECM bit
 +and so the graphics is - roughly said - made up of four "sections" that are
 +each repeated four times.
 +
 +====== Invalid bitmap mode 2 (ECM/BMM/MCM=1/1/1) ======
 +
 +//(Ie. setting the ECM, Bitmap and Multicolor mode on at the same time)//
 +
 +The last invalid mode also creates a black screen but it can also be
 +"scanned" with sprite-graphics collisions.
 +
 +The structure of the graphics is basically as in multicolor bitmap mode,
 +but the bits 9 and 10 of the g-addresses are always zero due to the set ECM
 +bit, with the same results as in the first invalid bitmap mode. As usual,
 +the bit combination "01" is part of the background.
 +
 +====== Idle state ======
 +
 +In idle state, the VIC reads the graphics data from address $3fff (resp.
 +$39ff if the ECM bit is set) and displays it in the selected graphics mode,
 +but with the video matrix data (normally read in the c-accesses) being all
 +"0" bits. So the byte at address $3fff/$39ff is output repeatedly.
 +
  
base/built_in_screen_modes.txt · Last modified: 2015-04-17 04:30 by 127.0.0.1