1.1 --- a/ULA.txt Fri Jan 27 00:31:47 2012 +0100
1.2 +++ b/ULA.txt Sun Jan 29 20:40:59 2012 +0100
1.3 @@ -157,8 +157,8 @@
1.4 that hardware to reduce the load on the system CPU which was responsible for
1.5 producing the video output.
1.6
1.7 -Hardware Sprites and Colour Planes
1.8 -----------------------------------
1.9 +Hardware Sprites
1.10 +----------------
1.11
1.12 An enhanced ULA might provide hardware sprites, but this would be done in an
1.13 way that is incompatible with the standard ULA, since no &FE*X locations are
1.14 @@ -169,18 +169,16 @@
1.15 (for example, &FE20-F) specifying a fixed number of eight sprites, with each
1.16 location pair referring to the sprite data. By limiting the ULA to dealing
1.17 with a fixed number of sprites, the work required inside the ULA would be
1.18 -reduced and it would avoid having to deal with arbitrary numbers of sprites.
1.19 +reduced since it would avoid having to deal with arbitrary numbers of sprites.
1.20
1.21 -Providing hardware sprites can be awkward without having some kind of working
1.22 -area, since the ULA would need to remember where each sprite is to be plotted
1.23 -and then deduce which sprites would be contributing to any given pixel. An
1.24 -alternative is to use memory into which the sprites would be plotted, and this
1.25 -memory would be combined with the main screen memory, taking a particular
1.26 -colour as the "colourkey" which is to be considered transparent, and only
1.27 -overwriting the main screen pixels with pixel values for other colours.
1.28 -
1.29 -Even without an intermediate memory buffer, the colourkey concept could still
1.30 -be used in combining pixel values from sprites and the normal pixel data.
1.31 +The principal limitation on providing hardware sprites is that of having to
1.32 +obtain sprite data, given that the ULA is usually required to retrieve screen
1.33 +data, and given the lack of memory bandwidth available to retrieve sprite data
1.34 +(particularly from multiple sprites supposedly at the same position) and
1.35 +screen data simultaneously. Although the ULA could potentially read sprite
1.36 +data and screen data in alternate memory accesses in screen modes where the
1.37 +bandwidth is not already fully utilised, this would result in a degradation of
1.38 +performance.
1.39
1.40 Additional Screen Mode Configurations
1.41 -------------------------------------
1.42 @@ -252,49 +250,36 @@
1.43 to apply attribute data to the first column, the initial 8 cycles might be
1.44 configured to not produce pixel values.
1.45
1.46 +For an entire character, attribute data need only be read for the first row of
1.47 +pixels for a character. The subsequent rows would have attribute information
1.48 +applied to them, although this would require the attribute data to be stored
1.49 +in some kind of buffer. Thus, the following access pattern would be observed:
1.50 +
1.51 + Cycle: A B ... _ B ... _ B ... _ B ... _ B ... _ B ... _ B ... _ B ...
1.52 +
1.53 A whole byte used for colour information for a whole character would result in
1.54 -a choice of 256 colours (or 512 colours if the attribute data were combined
1.55 -with the pixel data), and this might be somewhat excessive. By only reading
1.56 -attribute bytes at every other opportunity, a choice of 16 (or 32) colours
1.57 -could be applied individually to two characters.
1.58 +a choice of 256 colours, and this might be somewhat excessive. By only reading
1.59 +attribute bytes at every other opportunity, a choice of 16 colours could be
1.60 +applied individually to two characters.
1.61
1.62 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.63 Reads: B A B -
1.64 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.65
1.66 -Further reductions in attribute data access, offering 4 (or 8) colours for
1.67 -every character in a four character block, for example, might also be worth
1.68 +Further reductions in attribute data access, offering 4 colours for every
1.69 +character in a four character block, for example, might also be worth
1.70 considering.
1.71
1.72 Consider the following configurations for screen modes with a colour depth of
1.73 1 bit per pixel for bitmap information:
1.74
1.75 - Screen width Columns Scaling Bytes (B) Bytes (A) Colours
1.76 - ------------ ------- ------- --------- --------- -------
1.77 - 320 40 x2 40 40 256/512
1.78 - 320 40 x2 40 20 16/32
1.79 - 320 40 x2 40 10 4/8
1.80 - 208 26 x3 26 26 256/512
1.81 - 208 26 x3 26 13 16/32
1.82 -
1.83 -Here, a mode resembling MODE 4 would occupy the same amount of space as MODE 1
1.84 -if 40 attribute (A) bytes were read in addition to the 40 bitmap (B) bytes.
1.85 -This would offer limited benefit over the mode with the higher colour depth,
1.86 -especially if palette definition lists were also available. However, if only
1.87 -20 attribute bytes were read, the screen memory would be only 150% of the
1.88 -original, and if only 10 bytes were read, the screen memory would be a more
1.89 -reasonable 125% of the original.
1.90 -
1.91 -Similarly, if an additional configuration pixel-tripled mode were to require
1.92 -as many attribute bytes as bitmap bytes, it would occupy as much space as its
1.93 -equivalent with twice the colour depth. However, by requiring only 13
1.94 -attribute bytes for every 26 bitmap bytes, it would actually be more efficient
1.95 -than MODE 6 (a screen start address of &6600 versus MODE 6's &6000).
1.96 -
1.97 -One significant limitation of this scheme is the effect on memory bandwidth.
1.98 -It is arguably unattractive to effectively limit the bandwidth available in
1.99 -modes similar to MODE 4 or 5, merely to gain attribute colours, particularly
1.100 -in the most extreme application of the scheme.
1.101 + Screen width Columns Scaling Bytes (B) Bytes (A) Colours Screen start
1.102 + ------------ ------- ------- --------- --------- ------- ------------
1.103 + 320 40 x2 40 40 256 &5300
1.104 + 320 40 x2 40 20 16 &5580 -> &5500
1.105 + 320 40 x2 40 10 4 &56C0 -> &5600
1.106 + 208 26 x3 26 26 256 &62C0 -> &6200
1.107 + 208 26 x3 26 13 16 &6460 -> &6400
1.108
1.109 MODE 7 Emulation using Character Attributes
1.110 -------------------------------------------
1.111 @@ -305,15 +290,13 @@
1.112
1.113 Screen width Columns Rows Bytes (B) Bytes (A) Colours Screen start
1.114 ------------ ------- ---- --------- --------- ------- ------------
1.115 - 320 40 25 40 20 16 &5120 -> &5100
1.116 - 320 40 25 40 10 8 &58f0 -> &5800
1.117 + 320 40 25 40 20 16 &5ECC -> &5E00
1.118 + 320 40 25 40 10 4 &5FC6 -> &5F00
1.119
1.120 -Although this requires much more memory than MODE 7 (12000 bytes versus
1.121 -MODE 7's 1000 bytes) and more memory than even MODE 6, it would at least make
1.122 -a limited 40-column multicolour mode available as a substitute for MODE 7. If
1.123 -only 8 colours were permitted, eliminating any use of an extra bit to indicate
1.124 -flashing colours, the same amount of memory as MODE 4 or MODE 5 would be
1.125 -needed.
1.126 +Although this requires much more memory than MODE 7 (8500 bytes versus MODE
1.127 +7's 1000 bytes), it does not need much more memory than MODE 6, and it would
1.128 +at least make a limited 40-column multicolour mode available as a substitute
1.129 +for MODE 7.
1.130
1.131 Enhanced Graphics and Mode Layouts
1.132 ----------------------------------
