# HG changeset patch # User Paul Boddie # Date 1323824588 -3600 # Node ID 0a7583905a1f77aed1b74faebfc6e8314c8acd83 # Parent c82fef2dd5622183514b592fdf63d69d22b8ad6d Added notes on alternative screen mode configurations, screen height adjustment and character attributes. diff -r c82fef2dd562 -r 0a7583905a1f ULA.txt --- a/ULA.txt Mon Dec 12 01:31:51 2011 +0100 +++ b/ULA.txt Wed Dec 14 02:03:08 2011 +0100 @@ -73,8 +73,23 @@ ---------------------------------------------------------- 6 lines - final, partial character row (hidden) -Thus, region blanking would impose a 250 line display with the bottom 6 lines -blank. The height of the screen could be configurable still further. +Thus, in this case, region blanking would impose a 250 line display with the +bottom 6 lines blank. + +Screen Height Adjustment +------------------------ + +The height of the screen could be configurable in order to reduce screen +memory consumption. This is not quite done in MODE 3 and 6 since the start of +the screen appears to be rounded down to the nearest page, but by reducing the +height by amounts more than a page, savings would be possible. For example: + + Screen width Depth Height Bytes per line Saving in bytes Start address + ------------ ----- ------ -------------- --------------- ------------- + 640 1 252 80 320 &3140 -> &3100 + 640 1 248 80 640 &3280 -> &3200 + 320 1 240 40 640 &5A80 -> &5A00 + 320 2 240 80 1280 &3500 Palette Definition ------------------ @@ -158,8 +173,125 @@ colour as the "colourkey" which is to be considered transparent, and only overwriting the main screen pixels with pixel values for other colours. -Enhanced Graphics ------------------ +Additional Screen Mode Configurations +------------------------------------- + +Alternative screen mode configurations could be supported. The ULA has to +produce 640 pixel values across the screen, with pixel doubling or quadrupling +employed to fill the screen width: + + Screen width Columns Scaling Depth Bytes + ------------ ------- ------- ----- ----- + 640 80 x1 1 80 + 320 40 x2 1, 2 40, 80 + 160 20 x4 2, 4 40, 80 + +It must also use at most 80 byte-sized memory accesses to provide the +information for the display. Given that characters must occupy an 8x8 pixel +array, if a configuration featuring anything other than 20, 40 or 80 character +columns is to be supported, compromises must be made such as the introduction +of blank pixels either between characters (such as occurs between rows in MODE +3 and 6) or at the end of a scanline (such as occurs at the end of the frame +in MODE 3 and 6). Consider the following configuration: + + Screen width Columns Scaling Depth Bytes Blank + ------------ ------- ------- ----- ------ ----- + 208 26 x3 1, 2 26, 52 16 + +Here, if the ULA can triple pixels, a 26 column mode with either 2 or 4 +colours could be provided, with 16 blank pixel values (out of a total of 640) +generated either at the start or end (or split between the start and end) of +each scanline. + +Character Attributes +-------------------- + +The BBC Micro MODE 7 employs something resembling character attributes to +support teletext displays, but depends on circuitry providing a character +generator. The ZX Spectrum, on the other hand, provides character attributes +as a means of colouring bitmapped graphics. Although such a feature is very +limiting as the sole means of providing multicolour graphics, in situations +where the choice is between low resolution multicolour graphics or high +resolution monochrome graphics, character attributes provide a potentially +useful compromise. + +For each byte read, the ULA must deliver 8 pixel values (out of a total of +640) to the video output, doing so by either emptying its pixel buffer on a +pixel per cycle basis, or by multiplying pixels and thus holding them for more +than one cycle. For example for a screen mode having 640 pixels in width: + + Cycle: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 + Reads: B B + Pixels: 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 + +And for a screen mode having 320 pixels in width: + + Cycle: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 + Reads: B + Pixels: 0 0 1 1 2 2 3 3 4 4 5 5 6 6 7 7 + +However, in modes where less than 80 bytes are required to generate the pixel +values, an enhanced ULA might be able to read additional bytes between those +providing the bitmapped graphics data: + + Cycle: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 + Reads: B A + Pixels: 0 0 1 1 2 2 3 3 4 4 5 5 6 6 7 7 + +These additional bytes could provide colour information for the bitmapped data +in the following character column (of 8 pixels). Since it would be desirable +to apply attribute data to the first column, the initial 8 cycles might be +configured to not produce pixel values. + +A whole byte used for colour information for a whole character would result in +a choice of 256 colours, and this might be somewhat excessive. By only reading +attribute bytes at every other opportunity, a choice of 16 colours could be +applied individually to two characters. + + Cycle: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + Reads: B A B - + Pixels: 0 0 1 1 2 2 3 3 4 4 5 5 6 6 7 7 0 0 1 1 2 2 3 3 4 4 5 5 6 6 7 7 + +Consider the following configurations for screen modes with a colour depth of +1 bit per pixel for bitmap information: + + Screen width Columns Scaling Bytes (B) Bytes (A) Colours + ------------ ------- ------- --------- --------- ------- + 320 40 x2 40 40 256 + 320 40 x2 40 20 16 + 208 26 x3 26 26 256 + 208 26 x3 26 13 16 + +Here, a mode resembling MODE 4 would occupy the same amount of space as MODE 1 +if 40 attribute (A) bytes were read in addition to the 40 bitmap (B) bytes. +This would offer limited benefit over the mode with the higher colour depth, +especially if palette definition lists were also available. However, if only +20 attribute bytes were read, the screen memory would be only 150% of the +original. + +Similarly, if an additional configuration pixel-tripled mode were to require +as many attribute bytes as bitmap bytes, it would occupy as much space as its +equivalent with twice the colour depth. However, by requiring only 13 +attribute bytes for every 26 bitmap bytes, it would actually be more efficient +than MODE 6 (a screen start address of &6600 versus MODE 6's &6000). + +MODE 7 Emulation +---------------- + +If the scheme of applying attributes to character regions were employed to +emulate MODE 7, in conjunction with the MODE 6 display technique, the +following configuration would be required: + + Screen width Columns Rows Bytes (B) Bytes (A) Colours Screen start + ------------ ------- ---- --------- --------- ------- ------------ + 320 40 25 40 20 16 &5120 -> &5100 + +Although this requires much more memory than MODE 7 (12000 bytes versus +MODE 7's 1000 bytes) and more memory than even MODE 6, it would at least make +a limited 40-column multicolour mode available as a substitute for MODE 7. + +Enhanced Graphics and Mode Layouts +---------------------------------- Screen modes with different screen memory mappings, higher resolutions and larger colour depths might be possible, but this would in most cases involve