1.1 --- a/ULA.txt Mon Dec 12 01:31:51 2011 +0100
1.2 +++ b/ULA.txt Wed Dec 14 02:03:08 2011 +0100
1.3 @@ -73,8 +73,23 @@
1.4 ----------------------------------------------------------
1.5 6 lines - final, partial character row (hidden)
1.6
1.7 -Thus, region blanking would impose a 250 line display with the bottom 6 lines
1.8 -blank. The height of the screen could be configurable still further.
1.9 +Thus, in this case, region blanking would impose a 250 line display with the
1.10 +bottom 6 lines blank.
1.11 +
1.12 +Screen Height Adjustment
1.13 +------------------------
1.14 +
1.15 +The height of the screen could be configurable in order to reduce screen
1.16 +memory consumption. This is not quite done in MODE 3 and 6 since the start of
1.17 +the screen appears to be rounded down to the nearest page, but by reducing the
1.18 +height by amounts more than a page, savings would be possible. For example:
1.19 +
1.20 + Screen width Depth Height Bytes per line Saving in bytes Start address
1.21 + ------------ ----- ------ -------------- --------------- -------------
1.22 + 640 1 252 80 320 &3140 -> &3100
1.23 + 640 1 248 80 640 &3280 -> &3200
1.24 + 320 1 240 40 640 &5A80 -> &5A00
1.25 + 320 2 240 80 1280 &3500
1.26
1.27 Palette Definition
1.28 ------------------
1.29 @@ -158,8 +173,125 @@
1.30 colour as the "colourkey" which is to be considered transparent, and only
1.31 overwriting the main screen pixels with pixel values for other colours.
1.32
1.33 -Enhanced Graphics
1.34 ------------------
1.35 +Additional Screen Mode Configurations
1.36 +-------------------------------------
1.37 +
1.38 +Alternative screen mode configurations could be supported. The ULA has to
1.39 +produce 640 pixel values across the screen, with pixel doubling or quadrupling
1.40 +employed to fill the screen width:
1.41 +
1.42 + Screen width Columns Scaling Depth Bytes
1.43 + ------------ ------- ------- ----- -----
1.44 + 640 80 x1 1 80
1.45 + 320 40 x2 1, 2 40, 80
1.46 + 160 20 x4 2, 4 40, 80
1.47 +
1.48 +It must also use at most 80 byte-sized memory accesses to provide the
1.49 +information for the display. Given that characters must occupy an 8x8 pixel
1.50 +array, if a configuration featuring anything other than 20, 40 or 80 character
1.51 +columns is to be supported, compromises must be made such as the introduction
1.52 +of blank pixels either between characters (such as occurs between rows in MODE
1.53 +3 and 6) or at the end of a scanline (such as occurs at the end of the frame
1.54 +in MODE 3 and 6). Consider the following configuration:
1.55 +
1.56 + Screen width Columns Scaling Depth Bytes Blank
1.57 + ------------ ------- ------- ----- ------ -----
1.58 + 208 26 x3 1, 2 26, 52 16
1.59 +
1.60 +Here, if the ULA can triple pixels, a 26 column mode with either 2 or 4
1.61 +colours could be provided, with 16 blank pixel values (out of a total of 640)
1.62 +generated either at the start or end (or split between the start and end) of
1.63 +each scanline.
1.64 +
1.65 +Character Attributes
1.66 +--------------------
1.67 +
1.68 +The BBC Micro MODE 7 employs something resembling character attributes to
1.69 +support teletext displays, but depends on circuitry providing a character
1.70 +generator. The ZX Spectrum, on the other hand, provides character attributes
1.71 +as a means of colouring bitmapped graphics. Although such a feature is very
1.72 +limiting as the sole means of providing multicolour graphics, in situations
1.73 +where the choice is between low resolution multicolour graphics or high
1.74 +resolution monochrome graphics, character attributes provide a potentially
1.75 +useful compromise.
1.76 +
1.77 +For each byte read, the ULA must deliver 8 pixel values (out of a total of
1.78 +640) to the video output, doing so by either emptying its pixel buffer on a
1.79 +pixel per cycle basis, or by multiplying pixels and thus holding them for more
1.80 +than one cycle. For example for a screen mode having 640 pixels in width:
1.81 +
1.82 + Cycle: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
1.83 + Reads: B B
1.84 + Pixels: 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
1.85 +
1.86 +And for a screen mode having 320 pixels in width:
1.87 +
1.88 + Cycle: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
1.89 + Reads: B
1.90 + Pixels: 0 0 1 1 2 2 3 3 4 4 5 5 6 6 7 7
1.91 +
1.92 +However, in modes where less than 80 bytes are required to generate the pixel
1.93 +values, an enhanced ULA might be able to read additional bytes between those
1.94 +providing the bitmapped graphics data:
1.95 +
1.96 + Cycle: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
1.97 + Reads: B A
1.98 + Pixels: 0 0 1 1 2 2 3 3 4 4 5 5 6 6 7 7
1.99 +
1.100 +These additional bytes could provide colour information for the bitmapped data
1.101 +in the following character column (of 8 pixels). Since it would be desirable
1.102 +to apply attribute data to the first column, the initial 8 cycles might be
1.103 +configured to not produce pixel values.
1.104 +
1.105 +A whole byte used for colour information for a whole character would result in
1.106 +a choice of 256 colours, and this might be somewhat excessive. By only reading
1.107 +attribute bytes at every other opportunity, a choice of 16 colours could be
1.108 +applied individually to two characters.
1.109 +
1.110 + 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
1.111 + Reads: B A B -
1.112 + 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
1.113 +
1.114 +Consider the following configurations for screen modes with a colour depth of
1.115 +1 bit per pixel for bitmap information:
1.116 +
1.117 + Screen width Columns Scaling Bytes (B) Bytes (A) Colours
1.118 + ------------ ------- ------- --------- --------- -------
1.119 + 320 40 x2 40 40 256
1.120 + 320 40 x2 40 20 16
1.121 + 208 26 x3 26 26 256
1.122 + 208 26 x3 26 13 16
1.123 +
1.124 +Here, a mode resembling MODE 4 would occupy the same amount of space as MODE 1
1.125 +if 40 attribute (A) bytes were read in addition to the 40 bitmap (B) bytes.
1.126 +This would offer limited benefit over the mode with the higher colour depth,
1.127 +especially if palette definition lists were also available. However, if only
1.128 +20 attribute bytes were read, the screen memory would be only 150% of the
1.129 +original.
1.130 +
1.131 +Similarly, if an additional configuration pixel-tripled mode were to require
1.132 +as many attribute bytes as bitmap bytes, it would occupy as much space as its
1.133 +equivalent with twice the colour depth. However, by requiring only 13
1.134 +attribute bytes for every 26 bitmap bytes, it would actually be more efficient
1.135 +than MODE 6 (a screen start address of &6600 versus MODE 6's &6000).
1.136 +
1.137 +MODE 7 Emulation
1.138 +----------------
1.139 +
1.140 +If the scheme of applying attributes to character regions were employed to
1.141 +emulate MODE 7, in conjunction with the MODE 6 display technique, the
1.142 +following configuration would be required:
1.143 +
1.144 + Screen width Columns Rows Bytes (B) Bytes (A) Colours Screen start
1.145 + ------------ ------- ---- --------- --------- ------- ------------
1.146 + 320 40 25 40 20 16 &5120 -> &5100
1.147 +
1.148 +Although this requires much more memory than MODE 7 (12000 bytes versus
1.149 +MODE 7's 1000 bytes) and more memory than even MODE 6, it would at least make
1.150 +a limited 40-column multicolour mode available as a substitute for MODE 7.
1.151 +
1.152 +Enhanced Graphics and Mode Layouts
1.153 +----------------------------------
1.154
1.155 Screen modes with different screen memory mappings, higher resolutions and
1.156 larger colour depths might be possible, but this would in most cases involve