1.1 --- a/ULA.txt Mon Jan 09 00:34:03 2012 +0100
1.2 +++ b/ULA.txt Fri Jan 27 00:31:47 2012 +0100
1.3 @@ -162,14 +162,14 @@
1.4
1.5 An enhanced ULA might provide hardware sprites, but this would be done in an
1.6 way that is incompatible with the standard ULA, since no &FE*X locations are
1.7 -available for allocation. In a special ULA mode, one might allocate a pair of
1.8 -locations (for example, &FE20 and &FE21) as a pair of registers referencing a
1.9 -region of memory from which a sprite might be found and potentially copied
1.10 -into internal RAM, with other locations (for example, &FE22 and &FE23)
1.11 -providing the size of the region. Alternatively, one might write the region
1.12 -location and size through a single ULA location, with the ULA being put into a
1.13 -particular state after each write. For example: read LSB of region, read MSB
1.14 -of region, read size, read height.
1.15 +available for allocation. To keep the facility simple, hardware sprites would
1.16 +have a standard byte width and height.
1.17 +
1.18 +The specification of sprites could involve the reservation of 16 locations
1.19 +(for example, &FE20-F) specifying a fixed number of eight sprites, with each
1.20 +location pair referring to the sprite data. By limiting the ULA to dealing
1.21 +with a fixed number of sprites, the work required inside the ULA would be
1.22 +reduced and it would avoid having to deal with arbitrary numbers of sprites.
1.23
1.24 Providing hardware sprites can be awkward without having some kind of working
1.25 area, since the ULA would need to remember where each sprite is to be plotted
1.26 @@ -179,6 +179,9 @@
1.27 colour as the "colourkey" which is to be considered transparent, and only
1.28 overwriting the main screen pixels with pixel values for other colours.
1.29
1.30 +Even without an intermediate memory buffer, the colourkey concept could still
1.31 +be used in combining pixel values from sprites and the normal pixel data.
1.32 +
1.33 Additional Screen Mode Configurations
1.34 -------------------------------------
1.35
1.36 @@ -250,30 +253,37 @@
1.37 configured to not produce pixel values.
1.38
1.39 A whole byte used for colour information for a whole character would result in
1.40 -a choice of 256 colours, and this might be somewhat excessive. By only reading
1.41 -attribute bytes at every other opportunity, a choice of 16 colours could be
1.42 -applied individually to two characters.
1.43 +a choice of 256 colours (or 512 colours if the attribute data were combined
1.44 +with the pixel data), and this might be somewhat excessive. By only reading
1.45 +attribute bytes at every other opportunity, a choice of 16 (or 32) colours
1.46 +could be applied individually to two characters.
1.47
1.48 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.49 Reads: B A B -
1.50 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.51
1.52 +Further reductions in attribute data access, offering 4 (or 8) colours for
1.53 +every character in a four character block, for example, might also be worth
1.54 +considering.
1.55 +
1.56 Consider the following configurations for screen modes with a colour depth of
1.57 1 bit per pixel for bitmap information:
1.58
1.59 Screen width Columns Scaling Bytes (B) Bytes (A) Colours
1.60 ------------ ------- ------- --------- --------- -------
1.61 - 320 40 x2 40 40 256
1.62 - 320 40 x2 40 20 16
1.63 - 208 26 x3 26 26 256
1.64 - 208 26 x3 26 13 16
1.65 + 320 40 x2 40 40 256/512
1.66 + 320 40 x2 40 20 16/32
1.67 + 320 40 x2 40 10 4/8
1.68 + 208 26 x3 26 26 256/512
1.69 + 208 26 x3 26 13 16/32
1.70
1.71 Here, a mode resembling MODE 4 would occupy the same amount of space as MODE 1
1.72 if 40 attribute (A) bytes were read in addition to the 40 bitmap (B) bytes.
1.73 This would offer limited benefit over the mode with the higher colour depth,
1.74 especially if palette definition lists were also available. However, if only
1.75 20 attribute bytes were read, the screen memory would be only 150% of the
1.76 -original.
1.77 +original, and if only 10 bytes were read, the screen memory would be a more
1.78 +reasonable 125% of the original.
1.79
1.80 Similarly, if an additional configuration pixel-tripled mode were to require
1.81 as many attribute bytes as bitmap bytes, it would occupy as much space as its
1.82 @@ -281,8 +291,13 @@
1.83 attribute bytes for every 26 bitmap bytes, it would actually be more efficient
1.84 than MODE 6 (a screen start address of &6600 versus MODE 6's &6000).
1.85
1.86 -MODE 7 Emulation
1.87 -----------------
1.88 +One significant limitation of this scheme is the effect on memory bandwidth.
1.89 +It is arguably unattractive to effectively limit the bandwidth available in
1.90 +modes similar to MODE 4 or 5, merely to gain attribute colours, particularly
1.91 +in the most extreme application of the scheme.
1.92 +
1.93 +MODE 7 Emulation using Character Attributes
1.94 +-------------------------------------------
1.95
1.96 If the scheme of applying attributes to character regions were employed to
1.97 emulate MODE 7, in conjunction with the MODE 6 display technique, the
1.98 @@ -291,10 +306,14 @@
1.99 Screen width Columns Rows Bytes (B) Bytes (A) Colours Screen start
1.100 ------------ ------- ---- --------- --------- ------- ------------
1.101 320 40 25 40 20 16 &5120 -> &5100
1.102 + 320 40 25 40 10 8 &58f0 -> &5800
1.103
1.104 Although this requires much more memory than MODE 7 (12000 bytes versus
1.105 MODE 7's 1000 bytes) and more memory than even MODE 6, it would at least make
1.106 -a limited 40-column multicolour mode available as a substitute for MODE 7.
1.107 +a limited 40-column multicolour mode available as a substitute for MODE 7. If
1.108 +only 8 colours were permitted, eliminating any use of an extra bit to indicate
1.109 +flashing colours, the same amount of memory as MODE 4 or MODE 5 would be
1.110 +needed.
1.111
1.112 Enhanced Graphics and Mode Layouts
1.113 ----------------------------------
