paul@46 | 1 | Principal Design and Feature Constraints
|
paul@46 | 2 | ----------------------------------------
|
paul@46 | 3 |
|
paul@46 | 4 | The features of the ULA are limited by the amount of time and resources that
|
paul@46 | 5 | can be allocated to each activity necessary to support such features given the
|
paul@46 | 6 | fundamental obligations of the unit. Maintaining a screen display based on the
|
paul@46 | 7 | contents of RAM itself requires the ULA to have exclusive access to such
|
paul@46 | 8 | hardware resources for a significant period of time. Whilst other elements of
|
paul@46 | 9 | the ULA can in principle run in parallel with this activity, they cannot also
|
paul@46 | 10 | access the RAM. Consequently, other features that might use the RAM must
|
paul@46 | 11 | accept a reduced allocation of that resource in comparison to a hypothetical
|
paul@46 | 12 | architecture where concurrent RAM access is possible.
|
paul@46 | 13 |
|
paul@46 | 14 | Thus, the principal constraint for many features is bandwidth. The duration of
|
paul@46 | 15 | access to hardware resources is one aspect of this; the rate at which such
|
paul@46 | 16 | resources can be accessed is another. For example, the RAM is not fast enough
|
paul@46 | 17 | to support access more frequently than one byte per 2MHz cycle, and for screen
|
paul@46 | 18 | modes involving 80 bytes of screen data per scanline, there are no free cycles
|
paul@46 | 19 | for anything other than the production of pixel output during the active
|
paul@46 | 20 | scanline periods.
|
paul@46 | 21 |
|
paul@22 | 22 | Timing
|
paul@22 | 23 | ------
|
paul@22 | 24 |
|
paul@40 | 25 | According to 15.3.2 in the Advanced User Guide, there are 312 scanlines, 256
|
paul@40 | 26 | of which are used to generate pixel data. At 50Hz, this means that 128 cycles
|
paul@40 | 27 | are spent on each scanline (2000000 cycles / 50 = 40000 cycles; 40000 cycles /
|
paul@40 | 28 | 312 ~= 128 cycles). This is consistent with the observation that each scanline
|
paul@37 | 29 | requires at most 80 bytes of data, and that the ULA is apparently busy for 40
|
paul@37 | 30 | out of 64 microseconds in each scanline.
|
paul@22 | 31 |
|
paul@33 | 32 | Access to RAM involves accessing four 64Kb dynamic RAM devices (IC4 to IC7,
|
paul@33 | 33 | each providing two bits of each byte) using two cycles within the 500ns period
|
paul@36 | 34 | of the 2MHz clock to complete each access operation. Since the CPU and ULA
|
paul@36 | 35 | have to take turns in accessing the RAM in MODE 4, 5 and 6, the CPU must
|
paul@36 | 36 | effectively run at 1MHz (since every other 500ns period involves the ULA
|
paul@36 | 37 | accessing RAM). The CPU is driven by an external clock (IC8) whose 16MHz
|
paul@36 | 38 | frequency is divided by the ULA (IC1) depending on the screen mode in use.
|
paul@33 | 39 |
|
paul@37 | 40 | Each 16MHz cycle is approximately 62.5ns. To access the memory, the following
|
paul@37 | 41 | patterns corresponding to 16MHz cycles are required:
|
paul@37 | 42 |
|
paul@39 | 43 | Time (ns): 0-------------- 500------------ ...
|
paul@37 | 44 | 2 MHz cycle: 0 1 ...
|
paul@37 | 45 | 16 MHz cycle: 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 ...
|
paul@39 | 46 | ~RAS: 0 1 0 1 ...
|
paul@39 | 47 | ~CAS: 0 1 0 1 0 1 0 1 ...
|
paul@39 | 48 | A B B A B B ...
|
paul@39 | 49 | F S F S ...
|
paul@39 | 50 | a b b a b b ...
|
paul@37 | 51 |
|
paul@37 | 52 | Here, "A" indicates the row and column addresses being latched into the RAM
|
paul@38 | 53 | (on a negative edge for ~RAS and ~CAS respectively), and "B" indicates the
|
paul@37 | 54 | second column address being latched into the RAM. Presumably, the first and
|
paul@39 | 55 | second half-bytes can be read at "F" and "S" respectively, and the row and
|
paul@39 | 56 | column addresses must be made available at "a" and "b" respectively at the
|
paul@39 | 57 | latest.
|
paul@37 | 58 |
|
paul@38 | 59 | Note that the Service Manual refers to the negative edge of RAS and CAS, but
|
paul@38 | 60 | the datasheet for the similar TM4164EC4 product shows latching on the negative
|
paul@38 | 61 | edge of ~RAS and ~CAS. It is possible that the Service Manual also intended to
|
paul@38 | 62 | communicate the latter behaviour. In the TM4164EC4 datasheet, it appears that
|
paul@38 | 63 | "page mode" provides the appropriate behaviour for that particular product.
|
paul@38 | 64 |
|
paul@40 | 65 | Video Timing
|
paul@40 | 66 | ------------
|
paul@40 | 67 |
|
paul@40 | 68 | According to 8.7 in the Service Manual, and the PAL Wikipedia page,
|
paul@40 | 69 | approximately 4.7µs is used for the sync pulse, 5.7µs for the "back porch"
|
paul@40 | 70 | (including the "colour burst"), and 1.65µs for the "front porch", totalling
|
paul@40 | 71 | 12.05µs and thus leaving 51.95µs for the active video signal for each
|
paul@40 | 72 | scanline. As the Service Manual suggests in the oscilloscope traces, the
|
paul@40 | 73 | display information is transmitted more or less centred within the active
|
paul@40 | 74 | video period since the ULA will only be providing pixel data for 40µs in each
|
paul@40 | 75 | scanline.
|
paul@39 | 76 |
|
paul@39 | 77 | Each 62.5ns cycle happens to correspond to 64µs divided by 1024, meaning that
|
paul@39 | 78 | each scanline can be divided into 1024 cycles, although only 640 at most are
|
paul@40 | 79 | actively used to provide pixel data. Pixel data production should only occur
|
paul@40 | 80 | within a certain period on each scanline, approximately 262 cycles after the
|
paul@40 | 81 | start of hsync:
|
paul@40 | 82 |
|
paul@40 | 83 | active video period = 51.95µs
|
paul@40 | 84 | pixel data period = 40µs
|
paul@40 | 85 | total silent period = 51.95µs - 40µs = 11.95µs
|
paul@40 | 86 | silent periods (before and after) = 11.95µs / 2 = 5.975µs
|
paul@40 | 87 | hsync and back porch period = 4.7µs + 5.7µs = 10.4µs
|
paul@40 | 88 | time before pixel data period = 10.4µs + 5.975µs = 16.375µs
|
paul@40 | 89 | pixel data period start cycle = 16.375µs / 62.5ns = 262
|
paul@40 | 90 |
|
paul@40 | 91 | By choosing a number divisible by 8, the RAM access mechanism can be
|
paul@40 | 92 | synchronised with the pixel production. Thus, 264 is a more appropriate start
|
paul@40 | 93 | cycle.
|
paul@40 | 94 |
|
paul@40 | 95 | The "vertical blanking period", meaning the period before picture information
|
paul@40 | 96 | in each field is 25 lines out of 312 (strictly 312.5) and thus lasts for
|
paul@40 | 97 | 1.6ms. Of this, 2.5 lines occur before the vsync (field sync) which also lasts
|
paul@40 | 98 | for 2.5 lines. Thus, the first visible scanline on the first field of a frame
|
paul@40 | 99 | occurs half way through the 23rd scanline period measured from the start of
|
paul@40 | 100 | vsync:
|
paul@40 | 101 |
|
paul@40 | 102 | 10 20 23
|
paul@40 | 103 | Line in frame: 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
|
paul@40 | 104 | Line from 1: 0 22 3
|
paul@40 | 105 | Line on screen: .:::::VVVVV::::: 12233445566
|
paul@40 | 106 | |_________________________________________________|
|
paul@40 | 107 | 25 line vertical blanking period
|
paul@40 | 108 |
|
paul@40 | 109 | In the second field of a frame, the first visible scanline coincides with the
|
paul@40 | 110 | 24th scanline period measured from the start of line 313 in the frame:
|
paul@40 | 111 |
|
paul@40 | 112 | 310 336
|
paul@40 | 113 | Line in frame: 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
|
paul@40 | 114 | Line from 313: 0 23
|
paul@40 | 115 | Line on screen: 88:::::VVVVV:::: 11223344
|
paul@40 | 116 | 288 | |
|
paul@40 | 117 | |_________________________________________________|
|
paul@40 | 118 | 25 line vertical blanking period
|
paul@40 | 119 |
|
paul@40 | 120 | In order to consider only full lines, we might consider the start of each
|
paul@40 | 121 | frame to occur 23 lines after the start of vsync.
|
paul@40 | 122 |
|
paul@40 | 123 | Again, it is likely that pixel data production should only occur on scanlines
|
paul@40 | 124 | within a certain period on each frame. The "625/50" document indicates that
|
paul@40 | 125 | only a certain region is "safe" to use, suggesting a vertically centred region
|
paul@40 | 126 | with approximately 15 blank lines above and below the picture. Thus, the start
|
paul@40 | 127 | of the picture could be chosen as 38 lines after the start of vsync.
|
paul@40 | 128 |
|
paul@40 | 129 | See: Acorn Electron Advanced User Guide
|
paul@40 | 130 | See: http://mdfs.net/Docs/Comp/Electron/Techinfo.htm
|
paul@40 | 131 | See: http://en.wikipedia.org/wiki/PAL
|
paul@40 | 132 | See: http://en.wikipedia.org/wiki/Analog_television#Structure_of_a_video_signal
|
paul@40 | 133 | See: The 625/50 PAL Video Signal and TV Compatible Graphics Modes
|
paul@40 | 134 | http://lipas.uwasa.fi/~f76998/video/modes/
|
paul@40 | 135 | See: PAL TV timing and voltages
|
paul@40 | 136 | http://www.retroleum.co.uk/electronics-articles/pal-tv-timing-and-voltages/
|
paul@40 | 137 | See: Line Standards
|
paul@40 | 138 | http://www.pembers.freeserve.co.uk/World-TV-Standards/Line-Standards.html
|
paul@40 | 139 | See: TM4164EC4 65,536 by 4-Bit Dynamic RAM Module
|
paul@40 | 140 | http://www.datasheetarchive.com/dl/Datasheets-112/DSAP0051030.pdf
|
paul@40 | 141 | See: Acorn Electron Service Manual
|
paul@40 | 142 | http://acorn.chriswhy.co.uk/docs/Acorn/Manuals/Acorn_ElectronSM.pdf
|
paul@39 | 143 |
|
paul@43 | 144 | Interrupts
|
paul@43 | 145 | ----------
|
paul@43 | 146 |
|
paul@43 | 147 | The ULA generates IRQs (maskable interrupts) according to certain conditions
|
paul@43 | 148 | and these conditions are controlled by location &FE00:
|
paul@43 | 149 |
|
paul@43 | 150 | * Vertical sync (bottom of displayed screen)
|
paul@43 | 151 | * 50MHz real time clock
|
paul@43 | 152 | * Transmit data empty
|
paul@43 | 153 | * Receive data full
|
paul@43 | 154 | * High tone detect
|
paul@43 | 155 |
|
paul@43 | 156 | The ULA is also used to clear interrupt conditions through location &FE05. Of
|
paul@43 | 157 | particular significance is bit 7, which must be set if an NMI (non-maskable
|
paul@43 | 158 | interrupt) has occurred and has thus suspended ULA access to memory, restoring
|
paul@43 | 159 | the normal function of the ULA.
|
paul@43 | 160 |
|
paul@43 | 161 | ROM Paging
|
paul@43 | 162 | ----------
|
paul@43 | 163 |
|
paul@43 | 164 | Accessing different ROMs involves bits 0 to 3 of &FE05. Some special ROM
|
paul@43 | 165 | mappings exist:
|
paul@43 | 166 |
|
paul@43 | 167 | 8 keyboard
|
paul@43 | 168 | 9 keyboard (duplicate)
|
paul@43 | 169 | 10 BASIC ROM
|
paul@43 | 170 | 11 BASIC ROM (duplicate)
|
paul@43 | 171 |
|
paul@43 | 172 | Paging in a ROM involves the following procedure:
|
paul@43 | 173 |
|
paul@43 | 174 | 1. Assert ROM page enable (bit 3) together with a ROM number n in bits 0 to
|
paul@43 | 175 | 2, corresponding to ROM number 8+n, such that one of ROMs 12 to 15 is
|
paul@43 | 176 | selected.
|
paul@43 | 177 | 2. Where a ROM numbered from 0 to 7 is to be selected, set bit 3 to zero
|
paul@43 | 178 | whilst writing the desired ROM number n in bits 0 to 2.
|
paul@43 | 179 |
|
paul@37 | 180 | Shadow/Expanded Memory
|
paul@37 | 181 | ----------------------
|
paul@37 | 182 |
|
paul@37 | 183 | The Electron exposes all sixteen address lines and all eight data lines
|
paul@37 | 184 | through the expansion bus. Using such lines, it is possible to provide
|
paul@37 | 185 | additional memory - typically sideways ROM and RAM - on expansion cards and
|
paul@37 | 186 | through cartridges, although the official cartridge specification provides
|
paul@37 | 187 | fewer address lines and only seeks to provide access to memory in 16K units.
|
paul@37 | 188 |
|
paul@37 | 189 | Various modifications and upgrades were developed to offer "turbo"
|
paul@37 | 190 | capabilities to the Electron, permitting the CPU to access a separate 8K of
|
paul@37 | 191 | RAM at 2MHz, presumably preventing access to the low 8K of RAM accessible via
|
paul@37 | 192 | the ULA through additional logic. However, an enhanced ULA might support
|
paul@37 | 193 | independent CPU access to memory over the expansion bus by allowing itself to
|
paul@37 | 194 | be discharged from providing access to memory, potentially for a range of
|
paul@37 | 195 | addresses, and for the CPU to communicate with external memory uninterrupted.
|
paul@33 | 196 |
|
paul@0 | 197 | Hardware Scrolling
|
paul@0 | 198 | ------------------
|
paul@0 | 199 |
|
paul@0 | 200 | On the standard ULA, &FE02 and &FE03 map to a 9 significant bits address with
|
paul@0 | 201 | the least significant 5 bits being zero, thus limiting the scrolling
|
paul@0 | 202 | resolution to 64 bytes. An enhanced ULA could support a resolution of 2 bytes
|
paul@0 | 203 | using the same layout of these addresses.
|
paul@0 | 204 |
|
paul@0 | 205 | |--&FE02--------------| |--&FE03--------------|
|
paul@0 | 206 | XX XX 14 13 12 11 10 09 08 07 06 XX XX XX XX XX
|
paul@0 | 207 |
|
paul@0 | 208 | XX 14 13 12 11 10 09 08 07 06 05 04 03 02 01 XX
|
paul@0 | 209 |
|
paul@4 | 210 | Arguably, a resolution of 8 bytes is more useful, since the mapping of screen
|
paul@4 | 211 | memory to pixel locations is character oriented. A change in 8 bytes would
|
paul@4 | 212 | permit a horizontal scrolling resolution of 2 pixels in MODE 2, 4 pixels in
|
paul@4 | 213 | MODE 1 and 5, and 8 pixels in MODE 0, 3 and 6. This resolution is actually
|
paul@4 | 214 | observed on the BBC Micro (see 18.11.2 in the BBC Microcomputer Advanced User
|
paul@4 | 215 | Guide).
|
paul@4 | 216 |
|
paul@4 | 217 | One argument for a 2 byte resolution is smooth vertical scrolling. A pitfall
|
paul@4 | 218 | of changing the screen address by 2 bytes is the change in the number of lines
|
paul@4 | 219 | from the initial and final character rows that need reading by the ULA, which
|
paul@9 | 220 | would need to maintain this state information (although this is a relatively
|
paul@9 | 221 | trivial change). Another pitfall is the complication that might be introduced
|
paul@9 | 222 | to software writing bitmaps of character height to the screen.
|
paul@4 | 223 |
|
paul@4 | 224 | Region Blanking
|
paul@4 | 225 | ---------------
|
paul@4 | 226 |
|
paul@4 | 227 | The problem of permitting character-oriented blitting in programs whilst
|
paul@4 | 228 | scrolling the screen by sub-character amounts could be mitigated by permitting
|
paul@4 | 229 | a region of the display to be blank, such as the final lines of the display.
|
paul@4 | 230 | Consider the following vertical scrolling by 2 bytes that would cause an
|
paul@4 | 231 | initial character row of 6 lines and a final character row of 2 lines:
|
paul@4 | 232 |
|
paul@4 | 233 | 6 lines - initial, partial character row
|
paul@4 | 234 | 248 lines - 31 complete rows
|
paul@4 | 235 | 2 lines - final, partial character row
|
paul@4 | 236 |
|
paul@4 | 237 | If a routine were in use that wrote 8 line bitmaps to the partial character
|
paul@4 | 238 | row now split in two, it would be advisable to hide one of the regions in
|
paul@4 | 239 | order to prevent content appearing in the wrong place on screen (such as
|
paul@4 | 240 | content meant to appear at the top "leaking" onto the bottom). Blanking 6
|
paul@4 | 241 | lines would be sufficient, as can be seen from the following cases.
|
paul@4 | 242 |
|
paul@4 | 243 | Scrolling up by 2 lines:
|
paul@4 | 244 |
|
paul@4 | 245 | 6 lines - initial, partial character row
|
paul@4 | 246 | 240 lines - 30 complete rows
|
paul@4 | 247 | 4 lines - part of 1 complete row
|
paul@4 | 248 | -----------------------------------------------------------------
|
paul@4 | 249 | 4 lines - part of 1 complete row (hidden to maintain 250 lines)
|
paul@4 | 250 | 2 lines - final, partial character row (hidden)
|
paul@4 | 251 |
|
paul@4 | 252 | Scrolling down by 2 lines:
|
paul@4 | 253 |
|
paul@4 | 254 | 2 lines - initial, partial character row
|
paul@4 | 255 | 248 lines - 31 complete rows
|
paul@4 | 256 | ----------------------------------------------------------
|
paul@4 | 257 | 6 lines - final, partial character row (hidden)
|
paul@4 | 258 |
|
paul@24 | 259 | Thus, in this case, region blanking would impose a 250 line display with the
|
paul@24 | 260 | bottom 6 lines blank.
|
paul@24 | 261 |
|
paul@24 | 262 | Screen Height Adjustment
|
paul@24 | 263 | ------------------------
|
paul@24 | 264 |
|
paul@24 | 265 | The height of the screen could be configurable in order to reduce screen
|
paul@24 | 266 | memory consumption. This is not quite done in MODE 3 and 6 since the start of
|
paul@24 | 267 | the screen appears to be rounded down to the nearest page, but by reducing the
|
paul@24 | 268 | height by amounts more than a page, savings would be possible. For example:
|
paul@24 | 269 |
|
paul@24 | 270 | Screen width Depth Height Bytes per line Saving in bytes Start address
|
paul@24 | 271 | ------------ ----- ------ -------------- --------------- -------------
|
paul@24 | 272 | 640 1 252 80 320 &3140 -> &3100
|
paul@24 | 273 | 640 1 248 80 640 &3280 -> &3200
|
paul@24 | 274 | 320 1 240 40 640 &5A80 -> &5A00
|
paul@24 | 275 | 320 2 240 80 1280 &3500
|
paul@0 | 276 |
|
paul@0 | 277 | Palette Definition
|
paul@0 | 278 | ------------------
|
paul@0 | 279 |
|
paul@0 | 280 | Since all memory accesses go via the ULA, an enhanced ULA could employ more
|
paul@0 | 281 | specific addresses than &FE*X to perform enhanced functions. For example, the
|
paul@0 | 282 | palette control is done using &FE*8-F and merely involves selecting predefined
|
paul@0 | 283 | colours, whereas an enhanced ULA could support the redefinition of all 16
|
paul@0 | 284 | colours using specific ranges such as &FE18-F (colours 0 to 7) and &FE28-F
|
paul@0 | 285 | (colours 8 to 15), where a single byte might provide 8 bits per pixel colour
|
paul@0 | 286 | specifications similar to those used on the Archimedes.
|
paul@0 | 287 |
|
paul@4 | 288 | The principal limitation here is actually the hardware: the Electron has only
|
paul@4 | 289 | a single output line for each of the red, green and blue channels, and if
|
paul@4 | 290 | those outputs are strictly digital and can only be set to a "high" and "low"
|
paul@4 | 291 | value, then only the existing eight colours are possible. If a modern ULA were
|
paul@4 | 292 | able to output analogue values, it would still need to be assessed whether the
|
paul@46 | 293 | circuitry could successfully handle and propagate such values. Various sources
|
paul@46 | 294 | indicate that only "TTL levels" are supported by the RGB output circuit, and
|
paul@46 | 295 | since there are 74LS08 AND logic gates involved in the RGB component outputs
|
paul@46 | 296 | from the ULA, it is likely that the ULA is expected to provide only "high" or
|
paul@46 | 297 | "low" values.
|
paul@4 | 298 |
|
paul@51 | 299 | Flashing Colours
|
paul@51 | 300 | ----------------
|
paul@51 | 301 |
|
paul@51 | 302 | According to the Advanced User Guide, "The cursor and flashing colours are
|
paul@51 | 303 | entirely generated in software: This means that all of the logical to physical
|
paul@51 | 304 | colour map must be changed to cause colours to flash." This appears to suggest
|
paul@51 | 305 | that the palette registers must be updated upon the flash counter - read and
|
paul@51 | 306 | written by OSBYTE &C1 (193) - reaching zero and that some way of changing the
|
paul@51 | 307 | colour pairs to be any combination of colours might be possible, instead of
|
paul@52 | 308 | having colour complements as pairs.
|
paul@52 | 309 |
|
paul@52 | 310 | It is conceivable that the interrupt code responsible does the simple thing
|
paul@52 | 311 | and merely inverts the current values for any logical colours for which the
|
paul@52 | 312 | associated physical colour (as supplied as the second parameter to the VDU 19
|
paul@52 | 313 | call) has the top bit of its four bit value set. These top bits are not
|
paul@52 | 314 | recorded in the palette registers but are presumably recorded separately and
|
paul@52 | 315 | used to build bitmaps as follows:
|
paul@52 | 316 |
|
paul@52 | 317 | 2 colour 4 colour 16 colour
|
paul@52 | 318 | -------- -------- ---------
|
paul@52 | 319 | 0 00010001 00010001 00010001
|
paul@52 | 320 | 1 01000100 00100010 00010001
|
paul@52 | 321 | 2 01000100 00100010
|
paul@52 | 322 | 3 10001000 00100010
|
paul@52 | 323 | 4 00010001
|
paul@52 | 324 | 5 00010001
|
paul@52 | 325 | 6 00100010
|
paul@52 | 326 | 7 00100010
|
paul@52 | 327 | 8 01000100
|
paul@52 | 328 | 9 01000100
|
paul@52 | 329 | 10 10001000
|
paul@52 | 330 | 11 10001000
|
paul@52 | 331 | 12 01000100
|
paul@52 | 332 | 13 01000100
|
paul@52 | 333 | 14 10001000
|
paul@52 | 334 | 15 10001000
|
paul@52 | 335 |
|
paul@52 | 336 | An operation in the interrupt code would then combine the bitmaps for all
|
paul@52 | 337 | logical colours in 2 and 4 colour modes, with the 16 colour bitmaps being
|
paul@52 | 338 | combined for groups of logical colours as follows:
|
paul@52 | 339 |
|
paul@52 | 340 | 0, 2, 8, 10
|
paul@52 | 341 | 4, 6, 12, 14
|
paul@52 | 342 | 5, 7, 13, 15
|
paul@52 | 343 | 1, 3, 9, 11
|
paul@52 | 344 |
|
paul@52 | 345 | These combined bitmaps would be EORed with the existing palette register
|
paul@52 | 346 | values in order to perform the value inversion necessary to produce the
|
paul@52 | 347 | flashing effect.
|
paul@51 | 348 |
|
paul@4 | 349 | Palette Definition Lists
|
paul@4 | 350 | ------------------------
|
paul@4 | 351 |
|
paul@4 | 352 | It can be useful to redefine the palette in order to change the colours
|
paul@4 | 353 | available for a particular region of the screen, particularly in modes where
|
paul@4 | 354 | the choice of colours is constrained, and if an increased colour depth were
|
paul@4 | 355 | available, palette redefinition would be useful to give the illusion of more
|
paul@4 | 356 | than 16 colours in MODE 2. Traditionally, palette redefinition has been done
|
paul@4 | 357 | by using interrupt-driven timers, but a more efficient approach would involve
|
paul@4 | 358 | presenting lists of palette definitions to the ULA so that it can change the
|
paul@4 | 359 | palette at a particular display line.
|
paul@4 | 360 |
|
paul@4 | 361 | One might define a palette redefinition list in a region of memory and then
|
paul@4 | 362 | communicate its contents to the ULA by writing the address and length of the
|
paul@4 | 363 | list, along with the display line at which the palette is to be changed, to
|
paul@4 | 364 | ULA registers such that the ULA buffers the list and performs the redefinition
|
paul@4 | 365 | at the appropriate time. Throughput/bandwidth considerations might impose
|
paul@4 | 366 | restrictions on the practical length of such a list, however.
|
paul@4 | 367 |
|
paul@4 | 368 | Palette-Free Modes
|
paul@4 | 369 | ------------------
|
paul@4 | 370 |
|
paul@4 | 371 | Palette-free modes might be defined where bit values directly correspond to
|
paul@4 | 372 | the red, green and blue channels, although this would mostly make sense only
|
paul@4 | 373 | for modes with depths greater than the standard 4 bits per pixel, and such
|
paul@4 | 374 | modes would require more memory than MODE 2 if they were to have an acceptable
|
paul@4 | 375 | resolution.
|
paul@4 | 376 |
|
paul@4 | 377 | Display Suspend
|
paul@4 | 378 | ---------------
|
paul@4 | 379 |
|
paul@4 | 380 | Especially when writing to the screen memory, it could be beneficial to be
|
paul@4 | 381 | able to suspend the ULA's access to the memory, instead producing blank values
|
paul@4 | 382 | for all screen pixels until a program is ready to reveal the screen. This is
|
paul@4 | 383 | different from palette blanking since with a blank palette, the ULA is still
|
paul@4 | 384 | reading screen memory and translating its contents into pixel values that end
|
paul@4 | 385 | up being blank.
|
paul@4 | 386 |
|
paul@4 | 387 | This function is reminiscent of a capability of the ZX81, albeit necessary on
|
paul@4 | 388 | that hardware to reduce the load on the system CPU which was responsible for
|
paul@4 | 389 | producing the video output.
|
paul@4 | 390 |
|
paul@35 | 391 | Hardware Sprites
|
paul@35 | 392 | ----------------
|
paul@0 | 393 |
|
paul@0 | 394 | An enhanced ULA might provide hardware sprites, but this would be done in an
|
paul@0 | 395 | way that is incompatible with the standard ULA, since no &FE*X locations are
|
paul@34 | 396 | available for allocation. To keep the facility simple, hardware sprites would
|
paul@34 | 397 | have a standard byte width and height.
|
paul@34 | 398 |
|
paul@34 | 399 | The specification of sprites could involve the reservation of 16 locations
|
paul@34 | 400 | (for example, &FE20-F) specifying a fixed number of eight sprites, with each
|
paul@34 | 401 | location pair referring to the sprite data. By limiting the ULA to dealing
|
paul@34 | 402 | with a fixed number of sprites, the work required inside the ULA would be
|
paul@35 | 403 | reduced since it would avoid having to deal with arbitrary numbers of sprites.
|
paul@0 | 404 |
|
paul@35 | 405 | The principal limitation on providing hardware sprites is that of having to
|
paul@35 | 406 | obtain sprite data, given that the ULA is usually required to retrieve screen
|
paul@35 | 407 | data, and given the lack of memory bandwidth available to retrieve sprite data
|
paul@35 | 408 | (particularly from multiple sprites supposedly at the same position) and
|
paul@35 | 409 | screen data simultaneously. Although the ULA could potentially read sprite
|
paul@35 | 410 | data and screen data in alternate memory accesses in screen modes where the
|
paul@35 | 411 | bandwidth is not already fully utilised, this would result in a degradation of
|
paul@35 | 412 | performance.
|
paul@34 | 413 |
|
paul@24 | 414 | Additional Screen Mode Configurations
|
paul@24 | 415 | -------------------------------------
|
paul@24 | 416 |
|
paul@24 | 417 | Alternative screen mode configurations could be supported. The ULA has to
|
paul@24 | 418 | produce 640 pixel values across the screen, with pixel doubling or quadrupling
|
paul@24 | 419 | employed to fill the screen width:
|
paul@24 | 420 |
|
paul@24 | 421 | Screen width Columns Scaling Depth Bytes
|
paul@24 | 422 | ------------ ------- ------- ----- -----
|
paul@24 | 423 | 640 80 x1 1 80
|
paul@24 | 424 | 320 40 x2 1, 2 40, 80
|
paul@24 | 425 | 160 20 x4 2, 4 40, 80
|
paul@24 | 426 |
|
paul@24 | 427 | It must also use at most 80 byte-sized memory accesses to provide the
|
paul@24 | 428 | information for the display. Given that characters must occupy an 8x8 pixel
|
paul@24 | 429 | array, if a configuration featuring anything other than 20, 40 or 80 character
|
paul@24 | 430 | columns is to be supported, compromises must be made such as the introduction
|
paul@24 | 431 | of blank pixels either between characters (such as occurs between rows in MODE
|
paul@24 | 432 | 3 and 6) or at the end of a scanline (such as occurs at the end of the frame
|
paul@24 | 433 | in MODE 3 and 6). Consider the following configuration:
|
paul@24 | 434 |
|
paul@24 | 435 | Screen width Columns Scaling Depth Bytes Blank
|
paul@24 | 436 | ------------ ------- ------- ----- ------ -----
|
paul@24 | 437 | 208 26 x3 1, 2 26, 52 16
|
paul@24 | 438 |
|
paul@24 | 439 | Here, if the ULA can triple pixels, a 26 column mode with either 2 or 4
|
paul@24 | 440 | colours could be provided, with 16 blank pixel values (out of a total of 640)
|
paul@24 | 441 | generated either at the start or end (or split between the start and end) of
|
paul@24 | 442 | each scanline.
|
paul@24 | 443 |
|
paul@24 | 444 | Character Attributes
|
paul@24 | 445 | --------------------
|
paul@24 | 446 |
|
paul@24 | 447 | The BBC Micro MODE 7 employs something resembling character attributes to
|
paul@24 | 448 | support teletext displays, but depends on circuitry providing a character
|
paul@24 | 449 | generator. The ZX Spectrum, on the other hand, provides character attributes
|
paul@24 | 450 | as a means of colouring bitmapped graphics. Although such a feature is very
|
paul@24 | 451 | limiting as the sole means of providing multicolour graphics, in situations
|
paul@24 | 452 | where the choice is between low resolution multicolour graphics or high
|
paul@24 | 453 | resolution monochrome graphics, character attributes provide a potentially
|
paul@24 | 454 | useful compromise.
|
paul@24 | 455 |
|
paul@24 | 456 | For each byte read, the ULA must deliver 8 pixel values (out of a total of
|
paul@24 | 457 | 640) to the video output, doing so by either emptying its pixel buffer on a
|
paul@24 | 458 | pixel per cycle basis, or by multiplying pixels and thus holding them for more
|
paul@24 | 459 | than one cycle. For example for a screen mode having 640 pixels in width:
|
paul@24 | 460 |
|
paul@24 | 461 | Cycle: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
|
paul@24 | 462 | Reads: B B
|
paul@24 | 463 | Pixels: 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
|
paul@24 | 464 |
|
paul@24 | 465 | And for a screen mode having 320 pixels in width:
|
paul@24 | 466 |
|
paul@24 | 467 | Cycle: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
|
paul@24 | 468 | Reads: B
|
paul@24 | 469 | Pixels: 0 0 1 1 2 2 3 3 4 4 5 5 6 6 7 7
|
paul@24 | 470 |
|
paul@24 | 471 | However, in modes where less than 80 bytes are required to generate the pixel
|
paul@24 | 472 | values, an enhanced ULA might be able to read additional bytes between those
|
paul@24 | 473 | providing the bitmapped graphics data:
|
paul@24 | 474 |
|
paul@24 | 475 | Cycle: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
|
paul@24 | 476 | Reads: B A
|
paul@24 | 477 | Pixels: 0 0 1 1 2 2 3 3 4 4 5 5 6 6 7 7
|
paul@24 | 478 |
|
paul@24 | 479 | These additional bytes could provide colour information for the bitmapped data
|
paul@24 | 480 | in the following character column (of 8 pixels). Since it would be desirable
|
paul@24 | 481 | to apply attribute data to the first column, the initial 8 cycles might be
|
paul@24 | 482 | configured to not produce pixel values.
|
paul@24 | 483 |
|
paul@35 | 484 | For an entire character, attribute data need only be read for the first row of
|
paul@35 | 485 | pixels for a character. The subsequent rows would have attribute information
|
paul@35 | 486 | applied to them, although this would require the attribute data to be stored
|
paul@35 | 487 | in some kind of buffer. Thus, the following access pattern would be observed:
|
paul@35 | 488 |
|
paul@35 | 489 | Cycle: A B ... _ B ... _ B ... _ B ... _ B ... _ B ... _ B ... _ B ...
|
paul@35 | 490 |
|
paul@24 | 491 | A whole byte used for colour information for a whole character would result in
|
paul@35 | 492 | a choice of 256 colours, and this might be somewhat excessive. By only reading
|
paul@35 | 493 | attribute bytes at every other opportunity, a choice of 16 colours could be
|
paul@35 | 494 | applied individually to two characters.
|
paul@24 | 495 |
|
paul@24 | 496 | 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 | 497 | Reads: B A B -
|
paul@24 | 498 | 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 | 499 |
|
paul@35 | 500 | Further reductions in attribute data access, offering 4 colours for every
|
paul@35 | 501 | character in a four character block, for example, might also be worth
|
paul@34 | 502 | considering.
|
paul@34 | 503 |
|
paul@24 | 504 | Consider the following configurations for screen modes with a colour depth of
|
paul@24 | 505 | 1 bit per pixel for bitmap information:
|
paul@24 | 506 |
|
paul@35 | 507 | Screen width Columns Scaling Bytes (B) Bytes (A) Colours Screen start
|
paul@35 | 508 | ------------ ------- ------- --------- --------- ------- ------------
|
paul@35 | 509 | 320 40 x2 40 40 256 &5300
|
paul@35 | 510 | 320 40 x2 40 20 16 &5580 -> &5500
|
paul@35 | 511 | 320 40 x2 40 10 4 &56C0 -> &5600
|
paul@35 | 512 | 208 26 x3 26 26 256 &62C0 -> &6200
|
paul@35 | 513 | 208 26 x3 26 13 16 &6460 -> &6400
|
paul@34 | 514 |
|
paul@34 | 515 | MODE 7 Emulation using Character Attributes
|
paul@34 | 516 | -------------------------------------------
|
paul@24 | 517 |
|
paul@24 | 518 | If the scheme of applying attributes to character regions were employed to
|
paul@24 | 519 | emulate MODE 7, in conjunction with the MODE 6 display technique, the
|
paul@24 | 520 | following configuration would be required:
|
paul@24 | 521 |
|
paul@24 | 522 | Screen width Columns Rows Bytes (B) Bytes (A) Colours Screen start
|
paul@24 | 523 | ------------ ------- ---- --------- --------- ------- ------------
|
paul@35 | 524 | 320 40 25 40 20 16 &5ECC -> &5E00
|
paul@35 | 525 | 320 40 25 40 10 4 &5FC6 -> &5F00
|
paul@24 | 526 |
|
paul@35 | 527 | Although this requires much more memory than MODE 7 (8500 bytes versus MODE
|
paul@35 | 528 | 7's 1000 bytes), it does not need much more memory than MODE 6, and it would
|
paul@35 | 529 | at least make a limited 40-column multicolour mode available as a substitute
|
paul@35 | 530 | for MODE 7.
|
paul@24 | 531 |
|
paul@24 | 532 | Enhanced Graphics and Mode Layouts
|
paul@24 | 533 | ----------------------------------
|
paul@0 | 534 |
|
paul@0 | 535 | Screen modes with different screen memory mappings, higher resolutions and
|
paul@0 | 536 | larger colour depths might be possible, but this would in most cases involve
|
paul@0 | 537 | the allocation of more screen memory, and the ULA would probably then be
|
paul@0 | 538 | obliged to page in such memory for the CPU to be able to sensibly access it
|
paul@0 | 539 | all. Merely changing the memory mappings in order to have Archimedes-style
|
paul@0 | 540 | row-oriented screen addresses (instead of character-oriented addresses) could
|
paul@0 | 541 | be done for the existing modes, but this might not be sufficiently beneficial,
|
paul@0 | 542 | especially since accessing regions of the screen would involve incrementing
|
paul@0 | 543 | pointers by amounts that are inconvenient on an 8-bit CPU.
|
paul@0 | 544 |
|
paul@46 | 545 | Genlock Support
|
paul@46 | 546 | ---------------
|
paul@46 | 547 |
|
paul@46 | 548 | The ULA generates a video signal in conjunction with circuitry producing the
|
paul@46 | 549 | output features necessary for the correct display of the screen image.
|
paul@46 | 550 | However, it appears that the ULA drives the video synchronisation mechanism
|
paul@46 | 551 | instead of reacting to an existing signal. Genlock support might be possible
|
paul@46 | 552 | if the ULA were made to be responsive to such external signals, resetting its
|
paul@46 | 553 | address generators upon receiving synchronisation events.
|
paul@46 | 554 |
|
paul@0 | 555 | Enhanced Sound
|
paul@0 | 556 | --------------
|
paul@0 | 557 |
|
paul@0 | 558 | The standard ULA reserves &FE*6 for sound generation and cassette
|
paul@0 | 559 | input/output, thus making it impossible to support multiple channels within
|
paul@0 | 560 | the given framework. The BBC Micro ULA employs &FE40-&FE4F for sound control,
|
paul@0 | 561 | and an enhanced ULA could adopt this interface.
|
paul@0 | 562 |
|
paul@9 | 563 | The BBC Micro uses the SN76489 chip to produce sound, and the entire
|
paul@9 | 564 | functionality of this chip could be emulated for enhanced sound, with a subset
|
paul@9 | 565 | of the functionality exposed via the &FE*6 interface.
|
paul@9 | 566 |
|
paul@9 | 567 | See: http://en.wikipedia.org/wiki/Texas_Instruments_SN76489
|
paul@9 | 568 |
|
paul@0 | 569 | Waveform Upload
|
paul@0 | 570 | ---------------
|
paul@0 | 571 |
|
paul@0 | 572 | As with a hardware sprite function, waveforms could be uploaded or referenced
|
paul@0 | 573 | using locations as registers referencing memory regions.
|
paul@0 | 574 |
|
paul@46 | 575 | Sound Input/Output
|
paul@46 | 576 | ------------------
|
paul@46 | 577 |
|
paul@46 | 578 | Since the ULA already controls audio input/output for cassette-based data, it
|
paul@46 | 579 | would have been interesting to entertain the idea of sampling and output of
|
paul@46 | 580 | sounds through the cassette interface. However, a significant amount of
|
paul@46 | 581 | circuitry is employed to process the input signal for use by the ULA and to
|
paul@46 | 582 | process the output signal for recording.
|
paul@46 | 583 |
|
paul@46 | 584 | See: http://bbc.nvg.org/doc/A%20Hardware%20Guide%20for%20the%20BBC%20Microcomputer/bbc_hw_03.htm#3.11
|
paul@46 | 585 |
|
paul@0 | 586 | BBC ULA Compatibility
|
paul@0 | 587 | ---------------------
|
paul@0 | 588 |
|
paul@0 | 589 | Although some new ULA functions could be defined in a way that is also
|
paul@0 | 590 | compatible with the BBC Micro, the BBC ULA is itself incompatible with the
|
paul@0 | 591 | Electron ULA: &FE00-7 is reserved for the video controller in the BBC memory
|
paul@0 | 592 | map, but controls various functions specific to the 6845 video controller;
|
paul@0 | 593 | &FE08-F is reserved for the serial controller. It therefore becomes possible
|
paul@0 | 594 | to disregard compatibility where compatibility is already disregarded for a
|
paul@0 | 595 | particular area of functionality.
|
paul@0 | 596 |
|
paul@0 | 597 | &FE20-F maps to video ULA functionality on the BBC Micro which provides
|
paul@0 | 598 | control over the palette (using address &FE21, compared to &FE07-F on the
|
paul@0 | 599 | Electron) and other system-specific functions. Since the location usage is
|
paul@0 | 600 | generally incompatible, this region could be reused for other purposes.
|
paul@31 | 601 |
|
paul@49 | 602 | Increased RAM, ULA and CPU Performance
|
paul@49 | 603 | --------------------------------------
|
paul@49 | 604 |
|
paul@49 | 605 | More modern implementations of the hardware might feature faster RAM coupled
|
paul@49 | 606 | with an increased ULA clock frequency in order to increase the bandwidth
|
paul@49 | 607 | available to the ULA and to the CPU in situations where the ULA is not needed
|
paul@49 | 608 | to perform work. A ULA employing a 32MHz clock would be able to complete the
|
paul@49 | 609 | retrieval of a byte from RAM in only 250ns and thus be able to enable the CPU
|
paul@49 | 610 | to access the RAM for the following 250ns even in display modes requiring the
|
paul@49 | 611 | retrieval of a byte for the display every 500ns. The CPU could, subject to
|
paul@49 | 612 | timing issues, run at 2MHz even in MODE 0, 1 and 2.
|
paul@49 | 613 |
|
paul@49 | 614 | A scheme such as that described above would have a similar effect to the
|
paul@49 | 615 | scheme employed in the BBC Micro, although the latter made use of RAM with a
|
paul@49 | 616 | wider bandwidth in order to complete memory transfers within 250ns and thus
|
paul@49 | 617 | permit the CPU to run continuously at 2MHz.
|
paul@49 | 618 |
|
paul@49 | 619 | Higher bandwidth could potentially be used to implement exotic features such
|
paul@49 | 620 | as RAM-resident hardware sprites or indeed any feature demanding RAM access
|
paul@49 | 621 | concurrent with the production of the display image.
|
paul@49 | 622 |
|
paul@31 | 623 | ULA Pin Functions
|
paul@31 | 624 | -----------------
|
paul@31 | 625 |
|
paul@31 | 626 | The functions of the ULA pins are described in the Electron Service Manual. Of
|
paul@31 | 627 | interest to video processing are the following:
|
paul@31 | 628 |
|
paul@31 | 629 | CSYNC (low during horizontal or vertical synchronisation periods, high
|
paul@31 | 630 | otherwise)
|
paul@31 | 631 |
|
paul@31 | 632 | HS (low during horizontal synchronisation periods, high otherwise)
|
paul@31 | 633 |
|
paul@31 | 634 | RED, GREEN, BLUE (pixel colour outputs)
|
paul@31 | 635 |
|
paul@31 | 636 | CLOCK IN (a 16MHz clock input, 4V peak to peak)
|
paul@31 | 637 |
|
paul@31 | 638 | PHI OUT (a 1MHz, 2MHz and stopped clock signal for the CPU)
|
paul@31 | 639 |
|
paul@31 | 640 | More general memory access pins:
|
paul@31 | 641 |
|
paul@31 | 642 | RAM0...RAM3 (data lines to/from the RAM)
|
paul@31 | 643 |
|
paul@31 | 644 | RA0...RA7 (address lines for sending both row and column addresses to the RAM)
|
paul@31 | 645 |
|
paul@38 | 646 | RAS (row address strobe setting the row address on a negative edge - see the
|
paul@38 | 647 | timing notes)
|
paul@31 | 648 |
|
paul@38 | 649 | CAS (column address strobe setting the column address on a negative edge -
|
paul@38 | 650 | see the timing notes)
|
paul@31 | 651 |
|
paul@31 | 652 | WE (sets write enable with logic 0, read with logic 1)
|
paul@31 | 653 |
|
paul@31 | 654 | ROM (select data access from ROM)
|
paul@31 | 655 |
|
paul@31 | 656 | CPU-oriented memory access pins:
|
paul@31 | 657 |
|
paul@31 | 658 | A0...A15 (CPU address lines)
|
paul@31 | 659 |
|
paul@31 | 660 | PD0...PD7 (CPU data lines)
|
paul@31 | 661 |
|
paul@31 | 662 | R/W (indicates CPU write with logic 0, CPU read with logic 1)
|
paul@31 | 663 |
|
paul@31 | 664 | Interrupt-related pins:
|
paul@31 | 665 |
|
paul@31 | 666 | NMI (CPU request for uninterrupted 1MHz access to memory)
|
paul@31 | 667 |
|
paul@31 | 668 | IRQ (signal event to CPU)
|
paul@31 | 669 |
|
paul@31 | 670 | POR (power-on reset, resetting the ULA on a positive edge and asserting the
|
paul@31 | 671 | CPU's RST pin)
|
paul@31 | 672 |
|
paul@31 | 673 | RST (master reset for the CPU signalled on power-up and by the Break key)
|
paul@31 | 674 |
|
paul@31 | 675 | Keyboard-related pins:
|
paul@31 | 676 |
|
paul@31 | 677 | KBD0...KBD3 (keyboard inputs)
|
paul@31 | 678 |
|
paul@31 | 679 | CAPS LOCK (control status LED)
|
paul@31 | 680 |
|
paul@31 | 681 | Sound-related pins:
|
paul@31 | 682 |
|
paul@31 | 683 | SOUND O/P (sound output using internal oscillator)
|
paul@31 | 684 |
|
paul@31 | 685 | Cassette-related pins:
|
paul@31 | 686 |
|
paul@31 | 687 | CAS IN (cassette circuit input, between 0.5V to 2V peak to peak)
|
paul@31 | 688 |
|
paul@31 | 689 | CAS OUT (pseudo-sinusoidal output, 1.8V peak to peak)
|
paul@31 | 690 |
|
paul@31 | 691 | CAS RC (detect high tone)
|
paul@31 | 692 |
|
paul@31 | 693 | CAS MO (motor relay output)
|
paul@31 | 694 |
|
paul@31 | 695 | ÷13 IN (~1200 baud clock input)
|
paul@46 | 696 |
|
paul@46 | 697 | References
|
paul@46 | 698 | ----------
|
paul@46 | 699 |
|
paul@46 | 700 | See: http://bbc.nvg.org/doc/A%20Hardware%20Guide%20for%20the%20BBC%20Microcomputer/bbc_hw.htm
|