1.1 --- a/ULA.txt Mon Dec 05 01:20:39 2011 +0100
1.2 +++ b/ULA.txt Tue Dec 06 00:28:16 2011 +0100
1.3 @@ -11,11 +11,57 @@
1.4
1.5 XX 14 13 12 11 10 09 08 07 06 05 04 03 02 01 XX
1.6
1.7 -In practice, a resolution of 8 bytes is more useful, since the mapping of
1.8 -screen memory to pixel locations is character oriented. A change in 8 bytes
1.9 -would permit a scrolling resolution of 2 pixels in MODE 2, 4 pixels in MODE 1
1.10 -and 5, and 8 pixels in MODE 0, 3 and 6. This resolution is actually observed
1.11 -on the BBC Micro (see 18.11.2 in the BBC Microcomputer Advanced User Guide).
1.12 +Arguably, a resolution of 8 bytes is more useful, since the mapping of screen
1.13 +memory to pixel locations is character oriented. A change in 8 bytes would
1.14 +permit a horizontal scrolling resolution of 2 pixels in MODE 2, 4 pixels in
1.15 +MODE 1 and 5, and 8 pixels in MODE 0, 3 and 6. This resolution is actually
1.16 +observed on the BBC Micro (see 18.11.2 in the BBC Microcomputer Advanced User
1.17 +Guide).
1.18 +
1.19 +One argument for a 2 byte resolution is smooth vertical scrolling. A pitfall
1.20 +of changing the screen address by 2 bytes is the change in the number of lines
1.21 +from the initial and final character rows that need reading by the ULA, which
1.22 +would need to maintain this state information. Another pitfall is the
1.23 +complication that might be introduced to software writing bitmaps of character
1.24 +height to the screen.
1.25 +
1.26 +Region Blanking
1.27 +---------------
1.28 +
1.29 +The problem of permitting character-oriented blitting in programs whilst
1.30 +scrolling the screen by sub-character amounts could be mitigated by permitting
1.31 +a region of the display to be blank, such as the final lines of the display.
1.32 +Consider the following vertical scrolling by 2 bytes that would cause an
1.33 +initial character row of 6 lines and a final character row of 2 lines:
1.34 +
1.35 + 6 lines - initial, partial character row
1.36 + 248 lines - 31 complete rows
1.37 + 2 lines - final, partial character row
1.38 +
1.39 +If a routine were in use that wrote 8 line bitmaps to the partial character
1.40 +row now split in two, it would be advisable to hide one of the regions in
1.41 +order to prevent content appearing in the wrong place on screen (such as
1.42 +content meant to appear at the top "leaking" onto the bottom). Blanking 6
1.43 +lines would be sufficient, as can be seen from the following cases.
1.44 +
1.45 +Scrolling up by 2 lines:
1.46 +
1.47 + 6 lines - initial, partial character row
1.48 + 240 lines - 30 complete rows
1.49 + 4 lines - part of 1 complete row
1.50 + -----------------------------------------------------------------
1.51 + 4 lines - part of 1 complete row (hidden to maintain 250 lines)
1.52 + 2 lines - final, partial character row (hidden)
1.53 +
1.54 +Scrolling down by 2 lines:
1.55 +
1.56 + 2 lines - initial, partial character row
1.57 + 248 lines - 31 complete rows
1.58 + ----------------------------------------------------------
1.59 + 6 lines - final, partial character row (hidden)
1.60 +
1.61 +Thus, region blanking would impose a 250 line display with the bottom 6 lines
1.62 +blank. The height of the screen could be configurable still further.
1.63
1.64 Palette Definition
1.65 ------------------
1.66 @@ -28,6 +74,55 @@
1.67 (colours 8 to 15), where a single byte might provide 8 bits per pixel colour
1.68 specifications similar to those used on the Archimedes.
1.69
1.70 +The principal limitation here is actually the hardware: the Electron has only
1.71 +a single output line for each of the red, green and blue channels, and if
1.72 +those outputs are strictly digital and can only be set to a "high" and "low"
1.73 +value, then only the existing eight colours are possible. If a modern ULA were
1.74 +able to output analogue values, it would still need to be assessed whether the
1.75 +circuitry could successfully handle and propagate such values.
1.76 +
1.77 +Palette Definition Lists
1.78 +------------------------
1.79 +
1.80 +It can be useful to redefine the palette in order to change the colours
1.81 +available for a particular region of the screen, particularly in modes where
1.82 +the choice of colours is constrained, and if an increased colour depth were
1.83 +available, palette redefinition would be useful to give the illusion of more
1.84 +than 16 colours in MODE 2. Traditionally, palette redefinition has been done
1.85 +by using interrupt-driven timers, but a more efficient approach would involve
1.86 +presenting lists of palette definitions to the ULA so that it can change the
1.87 +palette at a particular display line.
1.88 +
1.89 +One might define a palette redefinition list in a region of memory and then
1.90 +communicate its contents to the ULA by writing the address and length of the
1.91 +list, along with the display line at which the palette is to be changed, to
1.92 +ULA registers such that the ULA buffers the list and performs the redefinition
1.93 +at the appropriate time. Throughput/bandwidth considerations might impose
1.94 +restrictions on the practical length of such a list, however.
1.95 +
1.96 +Palette-Free Modes
1.97 +------------------
1.98 +
1.99 +Palette-free modes might be defined where bit values directly correspond to
1.100 +the red, green and blue channels, although this would mostly make sense only
1.101 +for modes with depths greater than the standard 4 bits per pixel, and such
1.102 +modes would require more memory than MODE 2 if they were to have an acceptable
1.103 +resolution.
1.104 +
1.105 +Display Suspend
1.106 +---------------
1.107 +
1.108 +Especially when writing to the screen memory, it could be beneficial to be
1.109 +able to suspend the ULA's access to the memory, instead producing blank values
1.110 +for all screen pixels until a program is ready to reveal the screen. This is
1.111 +different from palette blanking since with a blank palette, the ULA is still
1.112 +reading screen memory and translating its contents into pixel values that end
1.113 +up being blank.
1.114 +
1.115 +This function is reminiscent of a capability of the ZX81, albeit necessary on
1.116 +that hardware to reduce the load on the system CPU which was responsible for
1.117 +producing the video output.
1.118 +
1.119 Hardware Sprites
1.120 ----------------
1.121
1.122 @@ -37,7 +132,10 @@
1.123 locations (for example, &FE20 and &FE21) as a pair of registers referencing a
1.124 region of memory from which a sprite might be found and potentially copied
1.125 into internal RAM, with other locations (for example, &FE22 and &FE23)
1.126 -providing the size of the region.
1.127 +providing the size of the region. Alternatively, one might write the region
1.128 +location and size through a single ULA location, with the ULA being put into a
1.129 +particular state after each write. For example: read LSB of region, read MSB
1.130 +of region, read size, read height.
1.131
1.132 Enhanced Graphics
1.133 -----------------