# HG changeset patch # User Paul Boddie # Date 1327866059 -3600 # Node ID d357bdd67748cc1e63ed5371e57955ca656e34da # Parent cb61693507b2246a1f32e885e172d4b6cb63feb9 Fixed character attribute calculations, noting that attribute data is only needed once per character row, not once per scanline. Added bandwidth notes on hardware sprites. diff -r cb61693507b2 -r d357bdd67748 ULA.txt --- a/ULA.txt Fri Jan 27 00:31:47 2012 +0100 +++ b/ULA.txt Sun Jan 29 20:40:59 2012 +0100 @@ -157,8 +157,8 @@ that hardware to reduce the load on the system CPU which was responsible for producing the video output. -Hardware Sprites and Colour Planes ----------------------------------- +Hardware Sprites +---------------- An enhanced ULA might provide hardware sprites, but this would be done in an way that is incompatible with the standard ULA, since no &FE*X locations are @@ -169,18 +169,16 @@ (for example, &FE20-F) specifying a fixed number of eight sprites, with each location pair referring to the sprite data. By limiting the ULA to dealing with a fixed number of sprites, the work required inside the ULA would be -reduced and it would avoid having to deal with arbitrary numbers of sprites. +reduced since it would avoid having to deal with arbitrary numbers of sprites. -Providing hardware sprites can be awkward without having some kind of working -area, since the ULA would need to remember where each sprite is to be plotted -and then deduce which sprites would be contributing to any given pixel. An -alternative is to use memory into which the sprites would be plotted, and this -memory would be combined with the main screen memory, taking a particular -colour as the "colourkey" which is to be considered transparent, and only -overwriting the main screen pixels with pixel values for other colours. - -Even without an intermediate memory buffer, the colourkey concept could still -be used in combining pixel values from sprites and the normal pixel data. +The principal limitation on providing hardware sprites is that of having to +obtain sprite data, given that the ULA is usually required to retrieve screen +data, and given the lack of memory bandwidth available to retrieve sprite data +(particularly from multiple sprites supposedly at the same position) and +screen data simultaneously. Although the ULA could potentially read sprite +data and screen data in alternate memory accesses in screen modes where the +bandwidth is not already fully utilised, this would result in a degradation of +performance. Additional Screen Mode Configurations ------------------------------------- @@ -252,49 +250,36 @@ to apply attribute data to the first column, the initial 8 cycles might be configured to not produce pixel values. +For an entire character, attribute data need only be read for the first row of +pixels for a character. The subsequent rows would have attribute information +applied to them, although this would require the attribute data to be stored +in some kind of buffer. Thus, the following access pattern would be observed: + + Cycle: A B ... _ B ... _ B ... _ B ... _ B ... _ B ... _ B ... _ B ... + A whole byte used for colour information for a whole character would result in -a choice of 256 colours (or 512 colours if the attribute data were combined -with the pixel data), and this might be somewhat excessive. By only reading -attribute bytes at every other opportunity, a choice of 16 (or 32) colours -could be applied individually to two characters. +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 -Further reductions in attribute data access, offering 4 (or 8) colours for -every character in a four character block, for example, might also be worth +Further reductions in attribute data access, offering 4 colours for every +character in a four character block, for example, might also be worth considering. 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/512 - 320 40 x2 40 20 16/32 - 320 40 x2 40 10 4/8 - 208 26 x3 26 26 256/512 - 208 26 x3 26 13 16/32 - -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, and if only 10 bytes were read, the screen memory would be a more -reasonable 125% 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). - -One significant limitation of this scheme is the effect on memory bandwidth. -It is arguably unattractive to effectively limit the bandwidth available in -modes similar to MODE 4 or 5, merely to gain attribute colours, particularly -in the most extreme application of the scheme. + Screen width Columns Scaling Bytes (B) Bytes (A) Colours Screen start + ------------ ------- ------- --------- --------- ------- ------------ + 320 40 x2 40 40 256 &5300 + 320 40 x2 40 20 16 &5580 -> &5500 + 320 40 x2 40 10 4 &56C0 -> &5600 + 208 26 x3 26 26 256 &62C0 -> &6200 + 208 26 x3 26 13 16 &6460 -> &6400 MODE 7 Emulation using Character Attributes ------------------------------------------- @@ -305,15 +290,13 @@ Screen width Columns Rows Bytes (B) Bytes (A) Colours Screen start ------------ ------- ---- --------- --------- ------- ------------ - 320 40 25 40 20 16 &5120 -> &5100 - 320 40 25 40 10 8 &58f0 -> &5800 + 320 40 25 40 20 16 &5ECC -> &5E00 + 320 40 25 40 10 4 &5FC6 -> &5F00 -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. If -only 8 colours were permitted, eliminating any use of an extra bit to indicate -flashing colours, the same amount of memory as MODE 4 or MODE 5 would be -needed. +Although this requires much more memory than MODE 7 (8500 bytes versus MODE +7's 1000 bytes), it does not need much more memory than MODE 6, and it would +at least make a limited 40-column multicolour mode available as a substitute +for MODE 7. Enhanced Graphics and Mode Layouts ----------------------------------