paul@22 | 1 | Timing
|
paul@22 | 2 | ------
|
paul@22 | 3 |
|
paul@22 | 4 | According to the above (15.3.2 in the AUG), there are 312 scanlines, 256 of
|
paul@22 | 5 | which are used to generate pixel data. At 50Hz, this means that 128 cycles are
|
paul@22 | 6 | used to produce pixel data (2000000 / 50 = 40000; 40000 / 312 ~= 128). This is
|
paul@22 | 7 | consistent with the observation that each scanline requires at most 80 bytes
|
paul@22 | 8 | of data, and that the ULA is apparently busy for 40 out of 64 microseconds in
|
paul@22 | 9 | each scanline.
|
paul@22 | 10 |
|
paul@22 | 11 | See: The Advanced User Guide for the Acorn Electron
|
paul@22 | 12 | See: http://mdfs.net/Docs/Comp/Electron/Techinfo.htm
|
paul@22 | 13 |
|
paul@0 | 14 | Hardware Scrolling
|
paul@0 | 15 | ------------------
|
paul@0 | 16 |
|
paul@0 | 17 | On the standard ULA, &FE02 and &FE03 map to a 9 significant bits address with
|
paul@0 | 18 | the least significant 5 bits being zero, thus limiting the scrolling
|
paul@0 | 19 | resolution to 64 bytes. An enhanced ULA could support a resolution of 2 bytes
|
paul@0 | 20 | using the same layout of these addresses.
|
paul@0 | 21 |
|
paul@0 | 22 | |--&FE02--------------| |--&FE03--------------|
|
paul@0 | 23 | XX XX 14 13 12 11 10 09 08 07 06 XX XX XX XX XX
|
paul@0 | 24 |
|
paul@0 | 25 | XX 14 13 12 11 10 09 08 07 06 05 04 03 02 01 XX
|
paul@0 | 26 |
|
paul@4 | 27 | Arguably, a resolution of 8 bytes is more useful, since the mapping of screen
|
paul@4 | 28 | memory to pixel locations is character oriented. A change in 8 bytes would
|
paul@4 | 29 | permit a horizontal scrolling resolution of 2 pixels in MODE 2, 4 pixels in
|
paul@4 | 30 | MODE 1 and 5, and 8 pixels in MODE 0, 3 and 6. This resolution is actually
|
paul@4 | 31 | observed on the BBC Micro (see 18.11.2 in the BBC Microcomputer Advanced User
|
paul@4 | 32 | Guide).
|
paul@4 | 33 |
|
paul@4 | 34 | One argument for a 2 byte resolution is smooth vertical scrolling. A pitfall
|
paul@4 | 35 | of changing the screen address by 2 bytes is the change in the number of lines
|
paul@4 | 36 | from the initial and final character rows that need reading by the ULA, which
|
paul@9 | 37 | would need to maintain this state information (although this is a relatively
|
paul@9 | 38 | trivial change). Another pitfall is the complication that might be introduced
|
paul@9 | 39 | to software writing bitmaps of character height to the screen.
|
paul@4 | 40 |
|
paul@4 | 41 | Region Blanking
|
paul@4 | 42 | ---------------
|
paul@4 | 43 |
|
paul@4 | 44 | The problem of permitting character-oriented blitting in programs whilst
|
paul@4 | 45 | scrolling the screen by sub-character amounts could be mitigated by permitting
|
paul@4 | 46 | a region of the display to be blank, such as the final lines of the display.
|
paul@4 | 47 | Consider the following vertical scrolling by 2 bytes that would cause an
|
paul@4 | 48 | initial character row of 6 lines and a final character row of 2 lines:
|
paul@4 | 49 |
|
paul@4 | 50 | 6 lines - initial, partial character row
|
paul@4 | 51 | 248 lines - 31 complete rows
|
paul@4 | 52 | 2 lines - final, partial character row
|
paul@4 | 53 |
|
paul@4 | 54 | If a routine were in use that wrote 8 line bitmaps to the partial character
|
paul@4 | 55 | row now split in two, it would be advisable to hide one of the regions in
|
paul@4 | 56 | order to prevent content appearing in the wrong place on screen (such as
|
paul@4 | 57 | content meant to appear at the top "leaking" onto the bottom). Blanking 6
|
paul@4 | 58 | lines would be sufficient, as can be seen from the following cases.
|
paul@4 | 59 |
|
paul@4 | 60 | Scrolling up by 2 lines:
|
paul@4 | 61 |
|
paul@4 | 62 | 6 lines - initial, partial character row
|
paul@4 | 63 | 240 lines - 30 complete rows
|
paul@4 | 64 | 4 lines - part of 1 complete row
|
paul@4 | 65 | -----------------------------------------------------------------
|
paul@4 | 66 | 4 lines - part of 1 complete row (hidden to maintain 250 lines)
|
paul@4 | 67 | 2 lines - final, partial character row (hidden)
|
paul@4 | 68 |
|
paul@4 | 69 | Scrolling down by 2 lines:
|
paul@4 | 70 |
|
paul@4 | 71 | 2 lines - initial, partial character row
|
paul@4 | 72 | 248 lines - 31 complete rows
|
paul@4 | 73 | ----------------------------------------------------------
|
paul@4 | 74 | 6 lines - final, partial character row (hidden)
|
paul@4 | 75 |
|
paul@24 | 76 | Thus, in this case, region blanking would impose a 250 line display with the
|
paul@24 | 77 | bottom 6 lines blank.
|
paul@24 | 78 |
|
paul@24 | 79 | Screen Height Adjustment
|
paul@24 | 80 | ------------------------
|
paul@24 | 81 |
|
paul@24 | 82 | The height of the screen could be configurable in order to reduce screen
|
paul@24 | 83 | memory consumption. This is not quite done in MODE 3 and 6 since the start of
|
paul@24 | 84 | the screen appears to be rounded down to the nearest page, but by reducing the
|
paul@24 | 85 | height by amounts more than a page, savings would be possible. For example:
|
paul@24 | 86 |
|
paul@24 | 87 | Screen width Depth Height Bytes per line Saving in bytes Start address
|
paul@24 | 88 | ------------ ----- ------ -------------- --------------- -------------
|
paul@24 | 89 | 640 1 252 80 320 &3140 -> &3100
|
paul@24 | 90 | 640 1 248 80 640 &3280 -> &3200
|
paul@24 | 91 | 320 1 240 40 640 &5A80 -> &5A00
|
paul@24 | 92 | 320 2 240 80 1280 &3500
|
paul@0 | 93 |
|
paul@0 | 94 | Palette Definition
|
paul@0 | 95 | ------------------
|
paul@0 | 96 |
|
paul@0 | 97 | Since all memory accesses go via the ULA, an enhanced ULA could employ more
|
paul@0 | 98 | specific addresses than &FE*X to perform enhanced functions. For example, the
|
paul@0 | 99 | palette control is done using &FE*8-F and merely involves selecting predefined
|
paul@0 | 100 | colours, whereas an enhanced ULA could support the redefinition of all 16
|
paul@0 | 101 | colours using specific ranges such as &FE18-F (colours 0 to 7) and &FE28-F
|
paul@0 | 102 | (colours 8 to 15), where a single byte might provide 8 bits per pixel colour
|
paul@0 | 103 | specifications similar to those used on the Archimedes.
|
paul@0 | 104 |
|
paul@4 | 105 | The principal limitation here is actually the hardware: the Electron has only
|
paul@4 | 106 | a single output line for each of the red, green and blue channels, and if
|
paul@4 | 107 | those outputs are strictly digital and can only be set to a "high" and "low"
|
paul@4 | 108 | value, then only the existing eight colours are possible. If a modern ULA were
|
paul@4 | 109 | able to output analogue values, it would still need to be assessed whether the
|
paul@4 | 110 | circuitry could successfully handle and propagate such values.
|
paul@4 | 111 |
|
paul@4 | 112 | Palette Definition Lists
|
paul@4 | 113 | ------------------------
|
paul@4 | 114 |
|
paul@4 | 115 | It can be useful to redefine the palette in order to change the colours
|
paul@4 | 116 | available for a particular region of the screen, particularly in modes where
|
paul@4 | 117 | the choice of colours is constrained, and if an increased colour depth were
|
paul@4 | 118 | available, palette redefinition would be useful to give the illusion of more
|
paul@4 | 119 | than 16 colours in MODE 2. Traditionally, palette redefinition has been done
|
paul@4 | 120 | by using interrupt-driven timers, but a more efficient approach would involve
|
paul@4 | 121 | presenting lists of palette definitions to the ULA so that it can change the
|
paul@4 | 122 | palette at a particular display line.
|
paul@4 | 123 |
|
paul@4 | 124 | One might define a palette redefinition list in a region of memory and then
|
paul@4 | 125 | communicate its contents to the ULA by writing the address and length of the
|
paul@4 | 126 | list, along with the display line at which the palette is to be changed, to
|
paul@4 | 127 | ULA registers such that the ULA buffers the list and performs the redefinition
|
paul@4 | 128 | at the appropriate time. Throughput/bandwidth considerations might impose
|
paul@4 | 129 | restrictions on the practical length of such a list, however.
|
paul@4 | 130 |
|
paul@4 | 131 | Palette-Free Modes
|
paul@4 | 132 | ------------------
|
paul@4 | 133 |
|
paul@4 | 134 | Palette-free modes might be defined where bit values directly correspond to
|
paul@4 | 135 | the red, green and blue channels, although this would mostly make sense only
|
paul@4 | 136 | for modes with depths greater than the standard 4 bits per pixel, and such
|
paul@4 | 137 | modes would require more memory than MODE 2 if they were to have an acceptable
|
paul@4 | 138 | resolution.
|
paul@4 | 139 |
|
paul@4 | 140 | Display Suspend
|
paul@4 | 141 | ---------------
|
paul@4 | 142 |
|
paul@4 | 143 | Especially when writing to the screen memory, it could be beneficial to be
|
paul@4 | 144 | able to suspend the ULA's access to the memory, instead producing blank values
|
paul@4 | 145 | for all screen pixels until a program is ready to reveal the screen. This is
|
paul@4 | 146 | different from palette blanking since with a blank palette, the ULA is still
|
paul@4 | 147 | reading screen memory and translating its contents into pixel values that end
|
paul@4 | 148 | up being blank.
|
paul@4 | 149 |
|
paul@4 | 150 | This function is reminiscent of a capability of the ZX81, albeit necessary on
|
paul@4 | 151 | that hardware to reduce the load on the system CPU which was responsible for
|
paul@4 | 152 | producing the video output.
|
paul@4 | 153 |
|
paul@9 | 154 | Hardware Sprites and Colour Planes
|
paul@9 | 155 | ----------------------------------
|
paul@0 | 156 |
|
paul@0 | 157 | An enhanced ULA might provide hardware sprites, but this would be done in an
|
paul@0 | 158 | way that is incompatible with the standard ULA, since no &FE*X locations are
|
paul@0 | 159 | available for allocation. In a special ULA mode, one might allocate a pair of
|
paul@0 | 160 | locations (for example, &FE20 and &FE21) as a pair of registers referencing a
|
paul@0 | 161 | region of memory from which a sprite might be found and potentially copied
|
paul@0 | 162 | into internal RAM, with other locations (for example, &FE22 and &FE23)
|
paul@4 | 163 | providing the size of the region. Alternatively, one might write the region
|
paul@4 | 164 | location and size through a single ULA location, with the ULA being put into a
|
paul@4 | 165 | particular state after each write. For example: read LSB of region, read MSB
|
paul@4 | 166 | of region, read size, read height.
|
paul@0 | 167 |
|
paul@9 | 168 | Providing hardware sprites can be awkward without having some kind of working
|
paul@9 | 169 | area, since the ULA would need to remember where each sprite is to be plotted
|
paul@9 | 170 | and then deduce which sprites would be contributing to any given pixel. An
|
paul@9 | 171 | alternative is to use memory into which the sprites would be plotted, and this
|
paul@9 | 172 | memory would be combined with the main screen memory, taking a particular
|
paul@9 | 173 | colour as the "colourkey" which is to be considered transparent, and only
|
paul@9 | 174 | overwriting the main screen pixels with pixel values for other colours.
|
paul@9 | 175 |
|
paul@24 | 176 | Additional Screen Mode Configurations
|
paul@24 | 177 | -------------------------------------
|
paul@24 | 178 |
|
paul@24 | 179 | Alternative screen mode configurations could be supported. The ULA has to
|
paul@24 | 180 | produce 640 pixel values across the screen, with pixel doubling or quadrupling
|
paul@24 | 181 | employed to fill the screen width:
|
paul@24 | 182 |
|
paul@24 | 183 | Screen width Columns Scaling Depth Bytes
|
paul@24 | 184 | ------------ ------- ------- ----- -----
|
paul@24 | 185 | 640 80 x1 1 80
|
paul@24 | 186 | 320 40 x2 1, 2 40, 80
|
paul@24 | 187 | 160 20 x4 2, 4 40, 80
|
paul@24 | 188 |
|
paul@24 | 189 | It must also use at most 80 byte-sized memory accesses to provide the
|
paul@24 | 190 | information for the display. Given that characters must occupy an 8x8 pixel
|
paul@24 | 191 | array, if a configuration featuring anything other than 20, 40 or 80 character
|
paul@24 | 192 | columns is to be supported, compromises must be made such as the introduction
|
paul@24 | 193 | of blank pixels either between characters (such as occurs between rows in MODE
|
paul@24 | 194 | 3 and 6) or at the end of a scanline (such as occurs at the end of the frame
|
paul@24 | 195 | in MODE 3 and 6). Consider the following configuration:
|
paul@24 | 196 |
|
paul@24 | 197 | Screen width Columns Scaling Depth Bytes Blank
|
paul@24 | 198 | ------------ ------- ------- ----- ------ -----
|
paul@24 | 199 | 208 26 x3 1, 2 26, 52 16
|
paul@24 | 200 |
|
paul@24 | 201 | Here, if the ULA can triple pixels, a 26 column mode with either 2 or 4
|
paul@24 | 202 | colours could be provided, with 16 blank pixel values (out of a total of 640)
|
paul@24 | 203 | generated either at the start or end (or split between the start and end) of
|
paul@24 | 204 | each scanline.
|
paul@24 | 205 |
|
paul@24 | 206 | Character Attributes
|
paul@24 | 207 | --------------------
|
paul@24 | 208 |
|
paul@24 | 209 | The BBC Micro MODE 7 employs something resembling character attributes to
|
paul@24 | 210 | support teletext displays, but depends on circuitry providing a character
|
paul@24 | 211 | generator. The ZX Spectrum, on the other hand, provides character attributes
|
paul@24 | 212 | as a means of colouring bitmapped graphics. Although such a feature is very
|
paul@24 | 213 | limiting as the sole means of providing multicolour graphics, in situations
|
paul@24 | 214 | where the choice is between low resolution multicolour graphics or high
|
paul@24 | 215 | resolution monochrome graphics, character attributes provide a potentially
|
paul@24 | 216 | useful compromise.
|
paul@24 | 217 |
|
paul@24 | 218 | For each byte read, the ULA must deliver 8 pixel values (out of a total of
|
paul@24 | 219 | 640) to the video output, doing so by either emptying its pixel buffer on a
|
paul@24 | 220 | pixel per cycle basis, or by multiplying pixels and thus holding them for more
|
paul@24 | 221 | than one cycle. For example for a screen mode having 640 pixels in width:
|
paul@24 | 222 |
|
paul@24 | 223 | Cycle: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
|
paul@24 | 224 | Reads: B B
|
paul@24 | 225 | Pixels: 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
|
paul@24 | 226 |
|
paul@24 | 227 | And for a screen mode having 320 pixels in width:
|
paul@24 | 228 |
|
paul@24 | 229 | Cycle: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
|
paul@24 | 230 | Reads: B
|
paul@24 | 231 | Pixels: 0 0 1 1 2 2 3 3 4 4 5 5 6 6 7 7
|
paul@24 | 232 |
|
paul@24 | 233 | However, in modes where less than 80 bytes are required to generate the pixel
|
paul@24 | 234 | values, an enhanced ULA might be able to read additional bytes between those
|
paul@24 | 235 | providing the bitmapped graphics data:
|
paul@24 | 236 |
|
paul@24 | 237 | Cycle: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
|
paul@24 | 238 | Reads: B A
|
paul@24 | 239 | Pixels: 0 0 1 1 2 2 3 3 4 4 5 5 6 6 7 7
|
paul@24 | 240 |
|
paul@24 | 241 | These additional bytes could provide colour information for the bitmapped data
|
paul@24 | 242 | in the following character column (of 8 pixels). Since it would be desirable
|
paul@24 | 243 | to apply attribute data to the first column, the initial 8 cycles might be
|
paul@24 | 244 | configured to not produce pixel values.
|
paul@24 | 245 |
|
paul@24 | 246 | A whole byte used for colour information for a whole character would result in
|
paul@24 | 247 | a choice of 256 colours, and this might be somewhat excessive. By only reading
|
paul@24 | 248 | attribute bytes at every other opportunity, a choice of 16 colours could be
|
paul@24 | 249 | applied individually to two characters.
|
paul@24 | 250 |
|
paul@24 | 251 | 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
|
paul@24 | 252 | Reads: B A B -
|
paul@24 | 253 | 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
|
paul@24 | 254 |
|
paul@24 | 255 | Consider the following configurations for screen modes with a colour depth of
|
paul@24 | 256 | 1 bit per pixel for bitmap information:
|
paul@24 | 257 |
|
paul@24 | 258 | Screen width Columns Scaling Bytes (B) Bytes (A) Colours
|
paul@24 | 259 | ------------ ------- ------- --------- --------- -------
|
paul@24 | 260 | 320 40 x2 40 40 256
|
paul@24 | 261 | 320 40 x2 40 20 16
|
paul@24 | 262 | 208 26 x3 26 26 256
|
paul@24 | 263 | 208 26 x3 26 13 16
|
paul@24 | 264 |
|
paul@24 | 265 | Here, a mode resembling MODE 4 would occupy the same amount of space as MODE 1
|
paul@24 | 266 | if 40 attribute (A) bytes were read in addition to the 40 bitmap (B) bytes.
|
paul@24 | 267 | This would offer limited benefit over the mode with the higher colour depth,
|
paul@24 | 268 | especially if palette definition lists were also available. However, if only
|
paul@24 | 269 | 20 attribute bytes were read, the screen memory would be only 150% of the
|
paul@24 | 270 | original.
|
paul@24 | 271 |
|
paul@24 | 272 | Similarly, if an additional configuration pixel-tripled mode were to require
|
paul@24 | 273 | as many attribute bytes as bitmap bytes, it would occupy as much space as its
|
paul@24 | 274 | equivalent with twice the colour depth. However, by requiring only 13
|
paul@24 | 275 | attribute bytes for every 26 bitmap bytes, it would actually be more efficient
|
paul@24 | 276 | than MODE 6 (a screen start address of &6600 versus MODE 6's &6000).
|
paul@24 | 277 |
|
paul@24 | 278 | MODE 7 Emulation
|
paul@24 | 279 | ----------------
|
paul@24 | 280 |
|
paul@24 | 281 | If the scheme of applying attributes to character regions were employed to
|
paul@24 | 282 | emulate MODE 7, in conjunction with the MODE 6 display technique, the
|
paul@24 | 283 | following configuration would be required:
|
paul@24 | 284 |
|
paul@24 | 285 | Screen width Columns Rows Bytes (B) Bytes (A) Colours Screen start
|
paul@24 | 286 | ------------ ------- ---- --------- --------- ------- ------------
|
paul@24 | 287 | 320 40 25 40 20 16 &5120 -> &5100
|
paul@24 | 288 |
|
paul@24 | 289 | Although this requires much more memory than MODE 7 (12000 bytes versus
|
paul@24 | 290 | MODE 7's 1000 bytes) and more memory than even MODE 6, it would at least make
|
paul@24 | 291 | a limited 40-column multicolour mode available as a substitute for MODE 7.
|
paul@24 | 292 |
|
paul@24 | 293 | Enhanced Graphics and Mode Layouts
|
paul@24 | 294 | ----------------------------------
|
paul@0 | 295 |
|
paul@0 | 296 | Screen modes with different screen memory mappings, higher resolutions and
|
paul@0 | 297 | larger colour depths might be possible, but this would in most cases involve
|
paul@0 | 298 | the allocation of more screen memory, and the ULA would probably then be
|
paul@0 | 299 | obliged to page in such memory for the CPU to be able to sensibly access it
|
paul@0 | 300 | all. Merely changing the memory mappings in order to have Archimedes-style
|
paul@0 | 301 | row-oriented screen addresses (instead of character-oriented addresses) could
|
paul@0 | 302 | be done for the existing modes, but this might not be sufficiently beneficial,
|
paul@0 | 303 | especially since accessing regions of the screen would involve incrementing
|
paul@0 | 304 | pointers by amounts that are inconvenient on an 8-bit CPU.
|
paul@0 | 305 |
|
paul@0 | 306 | Enhanced Sound
|
paul@0 | 307 | --------------
|
paul@0 | 308 |
|
paul@0 | 309 | The standard ULA reserves &FE*6 for sound generation and cassette
|
paul@0 | 310 | input/output, thus making it impossible to support multiple channels within
|
paul@0 | 311 | the given framework. The BBC Micro ULA employs &FE40-&FE4F for sound control,
|
paul@0 | 312 | and an enhanced ULA could adopt this interface.
|
paul@0 | 313 |
|
paul@9 | 314 | The BBC Micro uses the SN76489 chip to produce sound, and the entire
|
paul@9 | 315 | functionality of this chip could be emulated for enhanced sound, with a subset
|
paul@9 | 316 | of the functionality exposed via the &FE*6 interface.
|
paul@9 | 317 |
|
paul@9 | 318 | See: http://en.wikipedia.org/wiki/Texas_Instruments_SN76489
|
paul@9 | 319 |
|
paul@0 | 320 | Waveform Upload
|
paul@0 | 321 | ---------------
|
paul@0 | 322 |
|
paul@0 | 323 | As with a hardware sprite function, waveforms could be uploaded or referenced
|
paul@0 | 324 | using locations as registers referencing memory regions.
|
paul@0 | 325 |
|
paul@0 | 326 | BBC ULA Compatibility
|
paul@0 | 327 | ---------------------
|
paul@0 | 328 |
|
paul@0 | 329 | Although some new ULA functions could be defined in a way that is also
|
paul@0 | 330 | compatible with the BBC Micro, the BBC ULA is itself incompatible with the
|
paul@0 | 331 | Electron ULA: &FE00-7 is reserved for the video controller in the BBC memory
|
paul@0 | 332 | map, but controls various functions specific to the 6845 video controller;
|
paul@0 | 333 | &FE08-F is reserved for the serial controller. It therefore becomes possible
|
paul@0 | 334 | to disregard compatibility where compatibility is already disregarded for a
|
paul@0 | 335 | particular area of functionality.
|
paul@0 | 336 |
|
paul@0 | 337 | &FE20-F maps to video ULA functionality on the BBC Micro which provides
|
paul@0 | 338 | control over the palette (using address &FE21, compared to &FE07-F on the
|
paul@0 | 339 | Electron) and other system-specific functions. Since the location usage is
|
paul@0 | 340 | generally incompatible, this region could be reused for other purposes.
|