paul@71 | 1 | The Acorn Electron ULA
|
paul@71 | 2 | ======================
|
paul@71 | 3 |
|
paul@46 | 4 | Principal Design and Feature Constraints
|
paul@46 | 5 | ----------------------------------------
|
paul@46 | 6 |
|
paul@116 | 7 | The features of the ULA are limited in sophistication by the amount of time
|
paul@116 | 8 | and resources that can be allocated to each activity supporting the
|
paul@116 | 9 | fundamental features and obligations of the unit. Maintaining a screen display
|
paul@116 | 10 | based on the contents of RAM itself requires the ULA to have exclusive access
|
paul@116 | 11 | to various hardware resources for a significant period of time.
|
paul@116 | 12 |
|
paul@116 | 13 | Whilst other elements of the ULA can in principle run in parallel with the
|
paul@116 | 14 | display refresh activity, they cannot also access the RAM at the same time.
|
paul@116 | 15 | Consequently, other features that might use the RAM must accept a reduced
|
paul@116 | 16 | allocation of that resource in comparison to a hypothetical architecture where
|
paul@116 | 17 | concurrent RAM access is possible at all times.
|
paul@46 | 18 |
|
paul@46 | 19 | Thus, the principal constraint for many features is bandwidth. The duration of
|
paul@46 | 20 | access to hardware resources is one aspect of this; the rate at which such
|
paul@46 | 21 | resources can be accessed is another. For example, the RAM is not fast enough
|
paul@46 | 22 | to support access more frequently than one byte per 2MHz cycle, and for screen
|
paul@46 | 23 | modes involving 80 bytes of screen data per scanline, there are no free cycles
|
paul@46 | 24 | for anything other than the production of pixel output during the active
|
paul@46 | 25 | scanline periods.
|
paul@46 | 26 |
|
paul@116 | 27 | Another constraint is imposed by the method of RAM access provided by the ULA.
|
paul@116 | 28 | The ULA is able to access RAM by fetching 4 bits at a time and thus managing
|
paul@116 | 29 | to transfer 8 bits within a single 2MHz cycle, this being sufficient to
|
paul@116 | 30 | provide display data for the most demanding screen modes. However, this
|
paul@116 | 31 | mechanism's timing requirements are beyond the capabilities of the CPU when
|
paul@116 | 32 | running at 2MHz.
|
paul@116 | 33 |
|
paul@116 | 34 | Consequently, the CPU will only ever be able to access RAM via the ULA at
|
paul@116 | 35 | 1MHz, even when the ULA is not accessing the RAM. Fortunately, when needing to
|
paul@116 | 36 | refresh the display, the ULA is still able to make use of the idle part of
|
paul@116 | 37 | each 1MHz cycle (or, rather, the idle 2MHz cycle unused by the CPU) to itself
|
paul@116 | 38 | access the RAM at a rate of 1 byte per 1MHz cycle (or 1 byte every other 2MHz
|
paul@116 | 39 | cycle), thus supporting the less demanding screen modes.
|
paul@116 | 40 |
|
paul@22 | 41 | Timing
|
paul@22 | 42 | ------
|
paul@22 | 43 |
|
paul@40 | 44 | According to 15.3.2 in the Advanced User Guide, there are 312 scanlines, 256
|
paul@40 | 45 | of which are used to generate pixel data. At 50Hz, this means that 128 cycles
|
paul@40 | 46 | are spent on each scanline (2000000 cycles / 50 = 40000 cycles; 40000 cycles /
|
paul@40 | 47 | 312 ~= 128 cycles). This is consistent with the observation that each scanline
|
paul@37 | 48 | requires at most 80 bytes of data, and that the ULA is apparently busy for 40
|
paul@37 | 49 | out of 64 microseconds in each scanline.
|
paul@22 | 50 |
|
paul@78 | 51 | (In fact, since the ULA is seeking to provide an image for an interlaced
|
paul@78 | 52 | 625-line display, there are in fact two "fields" involved, one providing 312
|
paul@78 | 53 | scanlines and one providing 313 scanlines. See below for a description of the
|
paul@78 | 54 | video system.)
|
paul@78 | 55 |
|
paul@33 | 56 | Access to RAM involves accessing four 64Kb dynamic RAM devices (IC4 to IC7,
|
paul@33 | 57 | each providing two bits of each byte) using two cycles within the 500ns period
|
paul@36 | 58 | of the 2MHz clock to complete each access operation. Since the CPU and ULA
|
paul@36 | 59 | have to take turns in accessing the RAM in MODE 4, 5 and 6, the CPU must
|
paul@36 | 60 | effectively run at 1MHz (since every other 500ns period involves the ULA
|
paul@115 | 61 | accessing RAM) during transfers of screen data.
|
paul@33 | 62 |
|
paul@115 | 63 | The CPU is driven by an external clock (IC8) whose 16MHz frequency is divided
|
paul@115 | 64 | by the ULA (IC1) depending on the screen mode in use. Each 16MHz cycle is
|
paul@115 | 65 | approximately 62.5ns. To access the memory, the following patterns
|
paul@115 | 66 | corresponding to 16MHz cycles are required:
|
paul@37 | 67 |
|
paul@99 | 68 | Time (ns): 0-------------- 500------------- ...
|
paul@99 | 69 | 2 MHz cycle: 0 1 ...
|
paul@99 | 70 | 16 MHz cycle: 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 ...
|
paul@99 | 71 | /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ ...
|
paul@100 | 72 | ~RAS: /---\___________/---\___________ ...
|
paul@100 | 73 | ~CAS: /-----\___/-\___/-----\___/-\___ ...
|
paul@101 | 74 | Address events: A B C A B C ...
|
paul@101 | 75 | Data events: F S F S ...
|
paul@37 | 76 |
|
paul@101 | 77 | ~RAS ops: 1 0 1 0 ...
|
paul@101 | 78 | ~CAS ops: 1 0 1 0 1 0 1 0 ...
|
paul@101 | 79 |
|
paul@101 | 80 | Address ops: a b c a b c ...
|
paul@101 | 81 | Data ops: s f s f ...
|
paul@101 | 82 |
|
paul@101 | 83 | ~WE: ......W ...
|
paul@100 | 84 | PHI OUT: \_______________/--------------- ...
|
paul@100 | 85 | CPU (RAM): L D ...
|
paul@101 | 86 | RnW: R ...
|
paul@99 | 87 |
|
paul@100 | 88 | PHI OUT: \_______/-------\_______/------- ...
|
paul@100 | 89 | CPU (ROM): L D L D ...
|
paul@100 | 90 | RnW: R R ...
|
paul@97 | 91 |
|
paul@101 | 92 | ~RAS must be high for 100ns, ~CAS must be high for 50ns.
|
paul@101 | 93 | ~RAS must be low for 150ns, ~CAS must be low for 90ns.
|
paul@101 | 94 | Data is available 150ns after ~RAS goes low, 90ns after ~CAS goes low.
|
paul@101 | 95 |
|
paul@64 | 96 | Here, "A" and "B" respectively indicate the row and first column addresses
|
paul@64 | 97 | being latched into the RAM (on a negative edge for ~RAS and ~CAS
|
paul@64 | 98 | respectively), and "C" indicates the second column address being latched into
|
paul@64 | 99 | the RAM. Presumably, the first and second half-bytes can be read at "F" and
|
paul@64 | 100 | "S" respectively, and the row and column addresses must be made available at
|
paul@99 | 101 | "a" and "b" (and "c") respectively at the latest. Data can be read at "f" and
|
paul@99 | 102 | "s" for the first and second half-bytes respectively.
|
paul@64 | 103 |
|
paul@97 | 104 | For the CPU, "L" indicates the point at which an address is taken from the CPU
|
paul@97 | 105 | address bus, on a negative edge of PHI OUT, with "D" being the point at which
|
paul@97 | 106 | data may either be read or be asserted for writing, on a positive edge of PHI
|
paul@97 | 107 | OUT. Here, PHI OUT is driven at 1MHz. Given that ~WE needs to be driven low
|
paul@97 | 108 | for writing or high for reading, and thus propagates RnW from the CPU, this
|
paul@97 | 109 | would need to be done before data would be retrieved and, according to the
|
paul@97 | 110 | TM4164EC4 datasheet, even as late as the column address is presented and ~CAS
|
paul@97 | 111 | brought low.
|
paul@97 | 112 |
|
paul@64 | 113 | The TM4164EC4-15 has a row address access time of 150ns (maximum) and a column
|
paul@99 | 114 | address access time of 90ns (maximum), which appears to mean that ~RAS must be
|
paul@99 | 115 | held low for at least 150ns and that ~CAS must be held low for at least 90ns
|
paul@99 | 116 | before data becomes available. 150ns is 2.4 cycles (at 16MHz) and 90ns is 1.44
|
paul@99 | 117 | cycles. Thus, "A" to "F" is 2.5 cycles, "B" to "F" is 1.5 cycles, "C" to "S"
|
paul@99 | 118 | is 1.5 cycles.
|
paul@37 | 119 |
|
paul@38 | 120 | Note that the Service Manual refers to the negative edge of RAS and CAS, but
|
paul@38 | 121 | the datasheet for the similar TM4164EC4 product shows latching on the negative
|
paul@38 | 122 | edge of ~RAS and ~CAS. It is possible that the Service Manual also intended to
|
paul@38 | 123 | communicate the latter behaviour. In the TM4164EC4 datasheet, it appears that
|
paul@38 | 124 | "page mode" provides the appropriate behaviour for that particular product.
|
paul@38 | 125 |
|
paul@76 | 126 | The CPU, when accessing the RAM alone, apparently does not make use of the
|
paul@76 | 127 | vacated "slot" that the ULA would otherwise use (when interleaving accesses in
|
paul@76 | 128 | MODE 4, 5 and 6). It only employs a full 2MHz access frequency to memory when
|
paul@103 | 129 | accessing ROM (and potentially sideways RAM). The principal limitation is the
|
paul@103 | 130 | amount of time needed between issuing an address and receiving an entire byte
|
paul@103 | 131 | from the RAM, which is approximately 7 cycles (at 16MHz): much longer than the
|
paul@103 | 132 | 4 cycles that would be required for 2MHz operation.
|
paul@76 | 133 |
|
paul@57 | 134 | See: Acorn Electron Advanced User Guide
|
paul@57 | 135 | See: Acorn Electron Service Manual
|
paul@115 | 136 | http://chrisacorns.computinghistory.org.uk/docs/Acorn/Manuals/Acorn_ElectronSM.pdf
|
paul@57 | 137 | See: http://mdfs.net/Docs/Comp/Electron/Techinfo.htm
|
paul@76 | 138 | See: http://stardot.org.uk/forums/viewtopic.php?p=120438#p120438
|
paul@121 | 139 | See: One of the Most Popular 65,536-Bit (64K) Dynamic RAMs The TMS 4164
|
paul@121 | 140 | http://smithsonianchips.si.edu/augarten/p64.htm
|
paul@76 | 141 |
|
paul@119 | 142 | A Note on 8-Bit Wide RAM Access
|
paul@119 | 143 | -------------------------------
|
paul@119 | 144 |
|
paul@119 | 145 | It is worth considering the timing when 8 bits of data can be obtained at once
|
paul@119 | 146 | from the RAM chips:
|
paul@119 | 147 |
|
paul@119 | 148 | Time (ns): 0-------------- 500------------- ...
|
paul@119 | 149 | 2 MHz cycle: 0 1 ...
|
paul@119 | 150 | 8 MHz cycle: 0 1 2 3 0 1 2 3 ...
|
paul@119 | 151 | /-\_/-\_/-\_/-\_/-\_/-\_/-\_/-\_ ...
|
paul@119 | 152 | ~RAS: /---\___________/---\___________ ...
|
paul@119 | 153 | ~CAS: /-------\_______/-------\_______ ...
|
paul@119 | 154 | Address events: A B A B ...
|
paul@120 | 155 | Data events: E E ...
|
paul@119 | 156 |
|
paul@119 | 157 | ~RAS ops: 1 0 1 0 ...
|
paul@119 | 158 | ~CAS ops: 1 0 1 0 ...
|
paul@119 | 159 |
|
paul@119 | 160 | Address ops: a b a b ...
|
paul@119 | 161 | Data ops: f s f ...
|
paul@119 | 162 |
|
paul@119 | 163 | ~WE: ........W ...
|
paul@119 | 164 | PHI OUT: \_______/-------\_______/------- ...
|
paul@119 | 165 | CPU: L D L D ...
|
paul@119 | 166 | RnW: R R ...
|
paul@119 | 167 |
|
paul@120 | 168 | Here, "E" indicates the availability of an entire byte.
|
paul@120 | 169 |
|
paul@119 | 170 | Since only one fetch is required per 2MHz cycle, instead of two fetches for
|
paul@119 | 171 | the 4-bit wide RAM arrangement, it seems likely that longer 8MHz cycles could
|
paul@119 | 172 | be used to coordinate the necessary signalling.
|
paul@119 | 173 |
|
paul@120 | 174 | Another conceivable simplification from using an 8-bit wide RAM access channel
|
paul@120 | 175 | with a single access within each 2MHz cycle is the possibility of allowing the
|
paul@120 | 176 | CPU to signal directly to the RAM instead of having the ULA perform the access
|
paul@120 | 177 | signalling on the CPU's behalf.
|
paul@120 | 178 |
|
paul@110 | 179 | CPU Clock Notes
|
paul@110 | 180 | ---------------
|
paul@110 | 181 |
|
paul@111 | 182 | "The 6502 receives an external square-wave clock input signal on pin 37, which
|
paul@111 | 183 | is usually labeled PHI0. [...] This clock input is processed within the 6502
|
paul@111 | 184 | to form two clock outputs: PHI1 and PHI2 (pins 3 and 39, respectively). PHI2
|
paul@111 | 185 | is essentially a copy of PHI0; more specifically, PHI2 is PHI0 after it's been
|
paul@111 | 186 | through two inverters and a push-pull amplifier. The same network of
|
paul@111 | 187 | transistors within the 6502 which generates PHI2 is also tied to PHI1, and
|
paul@111 | 188 | generates PHI1 as the inverse of PHI0. The reason why PHI1 and PHI2 are made
|
paul@111 | 189 | available to external devices is so that they know when they can access the
|
paul@111 | 190 | CPU. When PHI1 is high, this means that external devices can read from the
|
paul@111 | 191 | address bus or data bus; when PHI2 is high, this means that external devices
|
paul@111 | 192 | can write to the data bus."
|
paul@111 | 193 |
|
paul@111 | 194 | See: http://lateblt.livejournal.com/88105.html
|
paul@111 | 195 |
|
paul@110 | 196 | "The 6502 has a synchronous memory bus where the master clock is divided into
|
paul@110 | 197 | two phases (Phase 1 and Phase 2). The address is always generated during Phase
|
paul@110 | 198 | 1 and all memory accesses take place during Phase 2."
|
paul@110 | 199 |
|
paul@111 | 200 | See: http://www.jmargolin.com/vgens/vgens.htm
|
paul@110 | 201 |
|
paul@111 | 202 | Thus, the inverse of PHI OUT provides the "other phase" of the clock. "During
|
paul@111 | 203 | Phase 1" means when PHI0 - really PHI2 - is high and "during Phase 2" means
|
paul@111 | 204 | when PHI1 is high.
|
paul@110 | 205 |
|
paul@76 | 206 | Bandwidth Figures
|
paul@76 | 207 | -----------------
|
paul@76 | 208 |
|
paul@76 | 209 | Using an observation of 128 2MHz cycles per scanline, 256 active lines and 312
|
paul@76 | 210 | total lines, with 80 cycles occurring in the active periods of display
|
paul@76 | 211 | scanlines, the following bandwidth calculations can be performed:
|
paul@76 | 212 |
|
paul@76 | 213 | Total theoretical maximum:
|
paul@76 | 214 | 128 cycles * 312 lines
|
paul@76 | 215 | = 39936 bytes
|
paul@76 | 216 |
|
paul@76 | 217 | MODE 0, 1, 2:
|
paul@76 | 218 | ULA: 80 cycles * 256 lines
|
paul@76 | 219 | = 20480 bytes
|
paul@76 | 220 | CPU: 48 cycles / 2 * 256 lines
|
paul@76 | 221 | + 128 cycles / 2 * (312 - 256) lines
|
paul@76 | 222 | = 9728 bytes
|
paul@76 | 223 |
|
paul@76 | 224 | MODE 3:
|
paul@76 | 225 | ULA: 80 cycles * 24 rows * 8 lines
|
paul@76 | 226 | = 15360 bytes
|
paul@76 | 227 | CPU: 48 cycles / 2 * 24 rows * 8 lines
|
paul@76 | 228 | + 128 cycles / 2 * (312 - (24 rows * 8 lines))
|
paul@76 | 229 | = 12288 bytes
|
paul@76 | 230 |
|
paul@76 | 231 | MODE 4, 5:
|
paul@76 | 232 | ULA: 40 cycles * 256 lines
|
paul@76 | 233 | = 10240 bytes
|
paul@76 | 234 | CPU: (40 cycles + 48 cycles / 2) * 256 lines
|
paul@76 | 235 | + 128 cycles / 2 * (312 - 256) lines
|
paul@76 | 236 | = 19968 bytes
|
paul@76 | 237 |
|
paul@76 | 238 | MODE 6:
|
paul@76 | 239 | ULA: 40 cycles * 24 rows * 8 lines
|
paul@76 | 240 | = 7680 bytes
|
paul@76 | 241 | CPU: (40 cycles + 48 cycles / 2) * 24 rows * 8 lines
|
paul@76 | 242 | + 128 cycles / 2 * (312 - (24 rows * 8 lines))
|
paul@76 | 243 | = 19968 bytes
|
paul@76 | 244 |
|
paul@76 | 245 | Here, the division of 2 for CPU accesses is performed to indicate that the CPU
|
paul@76 | 246 | only uses every other access opportunity even in uncontended periods. See the
|
paul@76 | 247 | 2MHz RAM Access enhancement below for bandwidth calculations that consider
|
paul@76 | 248 | this limitation removed.
|
paul@57 | 249 |
|
paul@40 | 250 | Video Timing
|
paul@40 | 251 | ------------
|
paul@40 | 252 |
|
paul@40 | 253 | According to 8.7 in the Service Manual, and the PAL Wikipedia page,
|
paul@40 | 254 | approximately 4.7µs is used for the sync pulse, 5.7µs for the "back porch"
|
paul@40 | 255 | (including the "colour burst"), and 1.65µs for the "front porch", totalling
|
paul@40 | 256 | 12.05µs and thus leaving 51.95µs for the active video signal for each
|
paul@40 | 257 | scanline. As the Service Manual suggests in the oscilloscope traces, the
|
paul@40 | 258 | display information is transmitted more or less centred within the active
|
paul@40 | 259 | video period since the ULA will only be providing pixel data for 40µs in each
|
paul@40 | 260 | scanline.
|
paul@39 | 261 |
|
paul@39 | 262 | Each 62.5ns cycle happens to correspond to 64µs divided by 1024, meaning that
|
paul@39 | 263 | each scanline can be divided into 1024 cycles, although only 640 at most are
|
paul@40 | 264 | actively used to provide pixel data. Pixel data production should only occur
|
paul@40 | 265 | within a certain period on each scanline, approximately 262 cycles after the
|
paul@40 | 266 | start of hsync:
|
paul@40 | 267 |
|
paul@40 | 268 | active video period = 51.95µs
|
paul@40 | 269 | pixel data period = 40µs
|
paul@40 | 270 | total silent period = 51.95µs - 40µs = 11.95µs
|
paul@40 | 271 | silent periods (before and after) = 11.95µs / 2 = 5.975µs
|
paul@40 | 272 | hsync and back porch period = 4.7µs + 5.7µs = 10.4µs
|
paul@40 | 273 | time before pixel data period = 10.4µs + 5.975µs = 16.375µs
|
paul@40 | 274 | pixel data period start cycle = 16.375µs / 62.5ns = 262
|
paul@40 | 275 |
|
paul@40 | 276 | By choosing a number divisible by 8, the RAM access mechanism can be
|
paul@84 | 277 | synchronised with the pixel production. Thus, 256 is a more appropriate start
|
paul@84 | 278 | cycle, where the HS (horizontal sync) signal corresponding to the 4µs sync
|
paul@84 | 279 | pulse (or "normal sync" pulse as described by the "PAL TV timing and voltages"
|
paul@84 | 280 | document) occurs at cycle 0.
|
paul@84 | 281 |
|
paul@84 | 282 | To summarise:
|
paul@84 | 283 |
|
paul@84 | 284 | HS signal starts at cycle 0 on each horizontal scanline
|
paul@84 | 285 | HS signal ends approximately 4µs later at cycle 64
|
paul@84 | 286 | Pixel data starts approximately 12µs later at cycle 256
|
paul@84 | 287 |
|
paul@84 | 288 | "Re: Electron Memory Contention" provides measurements that appear consistent
|
paul@84 | 289 | with these calculations.
|
paul@40 | 290 |
|
paul@40 | 291 | The "vertical blanking period", meaning the period before picture information
|
paul@78 | 292 | in each field is 25 lines out of 312 (or 313) and thus lasts for 1.6ms. Of
|
paul@78 | 293 | this, 2.5 lines occur before the vsync (field sync) which also lasts for 2.5
|
paul@78 | 294 | lines. Thus, the first visible scanline on the first field of a frame occurs
|
paul@84 | 295 | half way through the 23rd scanline period measured from the start of vsync
|
paul@84 | 296 | (indicated by "V" in the diagrams below):
|
paul@40 | 297 |
|
paul@40 | 298 | 10 20 23
|
paul@40 | 299 | 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 | 300 | Line from 1: 0 22 3
|
paul@40 | 301 | Line on screen: .:::::VVVVV::::: 12233445566
|
paul@40 | 302 | |_________________________________________________|
|
paul@40 | 303 | 25 line vertical blanking period
|
paul@40 | 304 |
|
paul@40 | 305 | In the second field of a frame, the first visible scanline coincides with the
|
paul@40 | 306 | 24th scanline period measured from the start of line 313 in the frame:
|
paul@40 | 307 |
|
paul@40 | 308 | 310 336
|
paul@40 | 309 | 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@78 | 310 | Line from 313: 0 23 4
|
paul@40 | 311 | Line on screen: 88:::::VVVVV:::: 11223344
|
paul@40 | 312 | 288 | |
|
paul@40 | 313 | |_________________________________________________|
|
paul@40 | 314 | 25 line vertical blanking period
|
paul@40 | 315 |
|
paul@40 | 316 | In order to consider only full lines, we might consider the start of each
|
paul@40 | 317 | frame to occur 23 lines after the start of vsync.
|
paul@40 | 318 |
|
paul@40 | 319 | Again, it is likely that pixel data production should only occur on scanlines
|
paul@40 | 320 | within a certain period on each frame. The "625/50" document indicates that
|
paul@40 | 321 | only a certain region is "safe" to use, suggesting a vertically centred region
|
paul@84 | 322 | with approximately 15 blank lines above and below the picture. However, the
|
paul@84 | 323 | "PAL TV timing and voltages" document suggests 28 blank lines above and below
|
paul@84 | 324 | the picture. This would centre the 256 lines within the 312 lines of each
|
paul@84 | 325 | field and thus provide a start of picture approximately 5.5 or 5 lines after
|
paul@84 | 326 | the end of the blanking period or 28 or 27.5 lines after the start of vsync.
|
paul@84 | 327 |
|
paul@84 | 328 | To summarise:
|
paul@84 | 329 |
|
paul@84 | 330 | CSYNC signal starts at cycle 0
|
paul@84 | 331 | CSYNC signal ends approximately 160µs (2.5 lines) later at cycle 2560
|
paul@84 | 332 | Start of line occurs approximately 1632µs (5.5 lines) later at cycle 28672
|
paul@40 | 333 |
|
paul@57 | 334 | See: http://en.wikipedia.org/wiki/PAL
|
paul@57 | 335 | See: http://en.wikipedia.org/wiki/Analog_television#Structure_of_a_video_signal
|
paul@57 | 336 | See: The 625/50 PAL Video Signal and TV Compatible Graphics Modes
|
paul@57 | 337 | http://lipas.uwasa.fi/~f76998/video/modes/
|
paul@57 | 338 | See: PAL TV timing and voltages
|
paul@57 | 339 | http://www.retroleum.co.uk/electronics-articles/pal-tv-timing-and-voltages/
|
paul@57 | 340 | See: Line Standards
|
paul@57 | 341 | http://www.pembers.freeserve.co.uk/World-TV-Standards/Line-Standards.html
|
paul@84 | 342 | See: Horizontal Blanking Interval of 405-, 525-, 625- and 819-Line Standards
|
paul@84 | 343 | http://www.pembers.freeserve.co.uk/World-TV-Standards/HBI.pdf
|
paul@84 | 344 | See: Re: Electron Memory Contention
|
paul@84 | 345 | http://www.stardot.org.uk/forums/viewtopic.php?p=134109#p134109
|
paul@57 | 346 |
|
paul@56 | 347 | RAM Integrated Circuits
|
paul@56 | 348 | -----------------------
|
paul@56 | 349 |
|
paul@65 | 350 | Unicorn Electronics appears to offer 4164 RAM chips (as well as 6502 series
|
paul@65 | 351 | CPUs such as the 6502, 6502A, 6502B and 65C02). These 4164 devices are
|
paul@65 | 352 | available in 100ns (4164-100), 120ns (4164-120) and 150ns (4164-150) variants,
|
paul@73 | 353 | have 16 pins and address 65536 bits through a 1-bit wide channel. Similarly,
|
paul@73 | 354 | ByteDelight.com sell 4164 devices primarily for the ZX Spectrum.
|
paul@65 | 355 |
|
paul@56 | 356 | The documentation for the Electron mentions 4164-15 RAM chips for IC4-7, and
|
paul@64 | 357 | the Samsung-produced KM41464 series is apparently equivalent to the Texas
|
paul@56 | 358 | Instruments 4164 chips presumably used in the Electron.
|
paul@56 | 359 |
|
paul@56 | 360 | The TM4164EC4 series combines 4 64K x 1b units into a single package and
|
paul@57 | 361 | appears similar to the TM4164EA4 featured on the Electron's circuit diagram
|
paul@57 | 362 | (in the Advanced User Guide but not the Service Manual), and it also has 22
|
paul@56 | 363 | pins providing 3 additional inputs and 3 additional outputs over the 16 pins
|
paul@57 | 364 | of the individual 4164-15 modules, presumably allowing concurrent access to
|
paul@57 | 365 | the packaged memory units.
|
paul@56 | 366 |
|
paul@56 | 367 | As far as currently available replacements are concerned, the NTE4164 is a
|
paul@57 | 368 | potential candidate: according to the Vetco Electronics entry, it is
|
paul@57 | 369 | supposedly a replacement for the TMS4164-15 amongst many other parts. Similar
|
paul@57 | 370 | parts include the NTE2164 and the NTE6664, both of which appear to have
|
paul@57 | 371 | largely the same performance and connection characteristics. Meanwhile, the
|
paul@58 | 372 | NTE21256 appears to be a 16-pin replacement with four times the capacity that
|
paul@58 | 373 | maintains the single data input and output pins. Using the NTE21256 as a
|
paul@57 | 374 | replacement for all ICs combined would be difficult because of the single bit
|
paul@57 | 375 | output.
|
paul@56 | 376 |
|
paul@57 | 377 | Another device equivalent to the 4164-15 appears to be available under the
|
paul@57 | 378 | code 41662 from Jameco Electronics as the Siemens HYB 4164-2. The Jameco Web
|
paul@57 | 379 | site lists data sheets for other devices on the same page, but these are
|
paul@57 | 380 | different and actually appear to be provided under the 41574 product code (but
|
paul@57 | 381 | are listed under 41464-10) and appear to be replacements for the TM4164EC4:
|
paul@57 | 382 | the Samsung KM41464A-15 and NEC µPD41464 employ 18 pins, eliminating 4 pins by
|
paul@57 | 383 | employing 4 pins for both input and output.
|
paul@57 | 384 |
|
paul@64 | 385 | Pins I/O pins Row access Column access
|
paul@64 | 386 | ---- -------- ---------- -------------
|
paul@64 | 387 | TM4164EC4 22 4 + 4 150ns (15) 90ns (15)
|
paul@64 | 388 | KM41464AP 18 4 150ns (15) 75ns (15)
|
paul@64 | 389 | NTE21256 16 1 + 1 150ns 75ns
|
paul@64 | 390 | HYB 4164-2 16 1 + 1 150ns 100ns
|
paul@64 | 391 | µPD41464 18 4 120ns (12) 60ns (12)
|
paul@64 | 392 |
|
paul@40 | 393 | See: TM4164EC4 65,536 by 4-Bit Dynamic RAM Module
|
paul@40 | 394 | http://www.datasheetarchive.com/dl/Datasheets-112/DSAP0051030.pdf
|
paul@65 | 395 | See: Dynamic RAMS
|
paul@65 | 396 | http://www.unicornelectronics.com/IC/DYNAMIC.html
|
paul@73 | 397 | See: New old stock 8x 4164 chips
|
paul@73 | 398 | http://www.bytedelight.com/?product=8x-4164-chips-new-old-stock
|
paul@56 | 399 | See: KM4164B 64K x 1 Bit Dynamic RAM with Page Mode
|
paul@56 | 400 | http://images.ihscontent.net/vipimages/VipMasterIC/IC/SAMS/SAMSD020/SAMSD020-45.pdf
|
paul@57 | 401 | See: NTE2164 Integrated Circuit 65,536 X 1 Bit Dynamic Random Access Memory
|
paul@57 | 402 | http://www.vetco.net/catalog/product_info.php?products_id=2806
|
paul@56 | 403 | See: NTE4164 - IC-NMOS 64K DRAM 150NS
|
paul@56 | 404 | http://www.vetco.net/catalog/product_info.php?products_id=3680
|
paul@56 | 405 | See: NTE21256 - IC-256K DRAM 150NS
|
paul@56 | 406 | http://www.vetco.net/catalog/product_info.php?products_id=2799
|
paul@56 | 407 | See: NTE21256 262,144-Bit Dynamic Random Access Memory (DRAM)
|
paul@56 | 408 | http://www.nteinc.com/specs/21000to21999/pdf/nte21256.pdf
|
paul@57 | 409 | See: NTE6664 - IC-MOS 64K DRAM 150NS
|
paul@57 | 410 | http://www.vetco.net/catalog/product_info.php?products_id=5213
|
paul@57 | 411 | See: NTE6664 Integrated Circuit 64K-Bit Dynamic RAM
|
paul@57 | 412 | http://www.nteinc.com/specs/6600to6699/pdf/nte6664.pdf
|
paul@57 | 413 | See: 4164-150: MAJOR BRANDS
|
paul@57 | 414 | http://www.jameco.com/webapp/wcs/stores/servlet/Product_10001_10001_41662_-1
|
paul@57 | 415 | See: HYB 4164-1, HYB 4164-2, HYB 4164-3 65,536-Bit Dynamic Random Access Memory (RAM)
|
paul@57 | 416 | http://www.jameco.com/Jameco/Products/ProdDS/41662SIEMENS.pdf
|
paul@57 | 417 | See: KM41464A NMOS DRAM 64K x 4 Bit Dynamic RAM with Page Mode
|
paul@57 | 418 | http://www.jameco.com/Jameco/Products/ProdDS/41662SAM.pdf
|
paul@57 | 419 | See: NEC µ41464 65,536 x 4-Bit Dynamic NMOS RAM
|
paul@57 | 420 | http://www.jameco.com/Jameco/Products/ProdDS/41662NEC.pdf
|
paul@57 | 421 | See: 41464-10: MAJOR BRANDS
|
paul@57 | 422 | http://www.jameco.com/webapp/wcs/stores/servlet/Product_10001_10001_41574_-1
|
paul@39 | 423 |
|
paul@43 | 424 | Interrupts
|
paul@43 | 425 | ----------
|
paul@43 | 426 |
|
paul@43 | 427 | The ULA generates IRQs (maskable interrupts) according to certain conditions
|
paul@43 | 428 | and these conditions are controlled by location &FE00:
|
paul@43 | 429 |
|
paul@43 | 430 | * Vertical sync (bottom of displayed screen)
|
paul@43 | 431 | * 50MHz real time clock
|
paul@43 | 432 | * Transmit data empty
|
paul@43 | 433 | * Receive data full
|
paul@43 | 434 | * High tone detect
|
paul@43 | 435 |
|
paul@43 | 436 | The ULA is also used to clear interrupt conditions through location &FE05. Of
|
paul@43 | 437 | particular significance is bit 7, which must be set if an NMI (non-maskable
|
paul@43 | 438 | interrupt) has occurred and has thus suspended ULA access to memory, restoring
|
paul@43 | 439 | the normal function of the ULA.
|
paul@43 | 440 |
|
paul@43 | 441 | ROM Paging
|
paul@43 | 442 | ----------
|
paul@43 | 443 |
|
paul@43 | 444 | Accessing different ROMs involves bits 0 to 3 of &FE05. Some special ROM
|
paul@43 | 445 | mappings exist:
|
paul@43 | 446 |
|
paul@43 | 447 | 8 keyboard
|
paul@43 | 448 | 9 keyboard (duplicate)
|
paul@43 | 449 | 10 BASIC ROM
|
paul@43 | 450 | 11 BASIC ROM (duplicate)
|
paul@43 | 451 |
|
paul@43 | 452 | Paging in a ROM involves the following procedure:
|
paul@43 | 453 |
|
paul@43 | 454 | 1. Assert ROM page enable (bit 3) together with a ROM number n in bits 0 to
|
paul@43 | 455 | 2, corresponding to ROM number 8+n, such that one of ROMs 12 to 15 is
|
paul@43 | 456 | selected.
|
paul@43 | 457 | 2. Where a ROM numbered from 0 to 7 is to be selected, set bit 3 to zero
|
paul@43 | 458 | whilst writing the desired ROM number n in bits 0 to 2.
|
paul@43 | 459 |
|
paul@81 | 460 | See: http://stardot.org.uk/forums/viewtopic.php?p=136686#p136686
|
paul@81 | 461 |
|
paul@117 | 462 | Keyboard Access
|
paul@117 | 463 | ---------------
|
paul@117 | 464 |
|
paul@117 | 465 | The keyboard pages appear to be accessed at 1MHz just like the RAM.
|
paul@117 | 466 |
|
paul@117 | 467 | See: https://stardot.org.uk/forums/viewtopic.php?p=254155#p254155
|
paul@117 | 468 |
|
paul@37 | 469 | Shadow/Expanded Memory
|
paul@37 | 470 | ----------------------
|
paul@37 | 471 |
|
paul@37 | 472 | The Electron exposes all sixteen address lines and all eight data lines
|
paul@37 | 473 | through the expansion bus. Using such lines, it is possible to provide
|
paul@37 | 474 | additional memory - typically sideways ROM and RAM - on expansion cards and
|
paul@37 | 475 | through cartridges, although the official cartridge specification provides
|
paul@37 | 476 | fewer address lines and only seeks to provide access to memory in 16K units.
|
paul@37 | 477 |
|
paul@37 | 478 | Various modifications and upgrades were developed to offer "turbo"
|
paul@37 | 479 | capabilities to the Electron, permitting the CPU to access a separate 8K of
|
paul@37 | 480 | RAM at 2MHz, presumably preventing access to the low 8K of RAM accessible via
|
paul@37 | 481 | the ULA through additional logic. However, an enhanced ULA might support
|
paul@37 | 482 | independent CPU access to memory over the expansion bus by allowing itself to
|
paul@37 | 483 | be discharged from providing access to memory, potentially for a range of
|
paul@37 | 484 | addresses, and for the CPU to communicate with external memory uninterrupted.
|
paul@33 | 485 |
|
paul@72 | 486 | Sideways RAM/ROM and Upper Memory Access
|
paul@72 | 487 | ----------------------------------------
|
paul@72 | 488 |
|
paul@72 | 489 | Although the ULA controls the CPU clock, effectively slowing or stopping the
|
paul@72 | 490 | CPU when the ULA needs to access screen memory, it is apparently able to allow
|
paul@72 | 491 | the CPU to access addresses of &8000 and above - the upper region of memory -
|
paul@72 | 492 | at 2MHz independently of any access to RAM that the ULA might be performing,
|
paul@72 | 493 | only blocking the CPU if it attempts to access addresses of &7FFF and below
|
paul@72 | 494 | during any ULA memory access - the lower region of memory - by stopping or
|
paul@72 | 495 | stalling its clock.
|
paul@72 | 496 |
|
paul@72 | 497 | Thus, the ULA remains aware of the level of the A15 line, only inhibiting the
|
paul@72 | 498 | CPU clock if the line goes low, when the CPU is attempting to access the lower
|
paul@72 | 499 | region of memory.
|
paul@72 | 500 |
|
paul@79 | 501 | Hardware Scrolling (and Enhancement)
|
paul@79 | 502 | ------------------------------------
|
paul@0 | 503 |
|
paul@0 | 504 | On the standard ULA, &FE02 and &FE03 map to a 9 significant bits address with
|
paul@0 | 505 | the least significant 5 bits being zero, thus limiting the scrolling
|
paul@0 | 506 | resolution to 64 bytes. An enhanced ULA could support a resolution of 2 bytes
|
paul@0 | 507 | using the same layout of these addresses.
|
paul@0 | 508 |
|
paul@0 | 509 | |--&FE02--------------| |--&FE03--------------|
|
paul@0 | 510 | XX XX 14 13 12 11 10 09 08 07 06 XX XX XX XX XX
|
paul@0 | 511 |
|
paul@0 | 512 | XX 14 13 12 11 10 09 08 07 06 05 04 03 02 01 XX
|
paul@0 | 513 |
|
paul@4 | 514 | Arguably, a resolution of 8 bytes is more useful, since the mapping of screen
|
paul@4 | 515 | memory to pixel locations is character oriented. A change in 8 bytes would
|
paul@4 | 516 | permit a horizontal scrolling resolution of 2 pixels in MODE 2, 4 pixels in
|
paul@4 | 517 | MODE 1 and 5, and 8 pixels in MODE 0, 3 and 6. This resolution is actually
|
paul@4 | 518 | observed on the BBC Micro (see 18.11.2 in the BBC Microcomputer Advanced User
|
paul@4 | 519 | Guide).
|
paul@4 | 520 |
|
paul@4 | 521 | One argument for a 2 byte resolution is smooth vertical scrolling. A pitfall
|
paul@4 | 522 | of changing the screen address by 2 bytes is the change in the number of lines
|
paul@4 | 523 | from the initial and final character rows that need reading by the ULA, which
|
paul@9 | 524 | would need to maintain this state information (although this is a relatively
|
paul@9 | 525 | trivial change). Another pitfall is the complication that might be introduced
|
paul@9 | 526 | to software writing bitmaps of character height to the screen.
|
paul@4 | 527 |
|
paul@81 | 528 | See: http://pastraiser.com/computers/acornelectron/acornelectron.html
|
paul@81 | 529 |
|
paul@82 | 530 | Enhancement: Mode Layouts
|
paul@82 | 531 | -------------------------
|
paul@82 | 532 |
|
paul@82 | 533 | Merely changing the screen memory mappings in order to have Archimedes-style
|
paul@82 | 534 | row-oriented screen addresses (instead of character-oriented addresses) could
|
paul@82 | 535 | be done for the existing modes, but this might not be sufficiently beneficial,
|
paul@82 | 536 | especially since accessing regions of the screen would involve incrementing
|
paul@82 | 537 | pointers by amounts that are inconvenient on an 8-bit CPU.
|
paul@82 | 538 |
|
paul@82 | 539 | However, instead of using a Archimedes-style mapping, column-oriented screen
|
paul@82 | 540 | addresses could be more feasibly employed: incrementing the address would
|
paul@82 | 541 | reference the vertical screen location below the currently-referenced location
|
paul@82 | 542 | (just as occurs within characters using the existing ULA); instead of
|
paul@82 | 543 | returning to the top of the character row and referencing the next horizontal
|
paul@82 | 544 | location after eight bytes, the address would reference the next character row
|
paul@82 | 545 | and continue to reference locations downwards over the height of the screen
|
paul@82 | 546 | until reaching the bottom; at the bottom, the next location would be the next
|
paul@82 | 547 | horizontal location at the top of the screen.
|
paul@82 | 548 |
|
paul@82 | 549 | In other words, the memory layout for the screen would resemble the following
|
paul@82 | 550 | (for MODE 2):
|
paul@82 | 551 |
|
paul@82 | 552 | &3000 &3100 ... &7F00
|
paul@82 | 553 | &3001 &3101
|
paul@82 | 554 | ... ...
|
paul@82 | 555 | &3007
|
paul@82 | 556 | &3008
|
paul@82 | 557 | ...
|
paul@82 | 558 | ... ...
|
paul@82 | 559 | &30FF ... &7FFF
|
paul@82 | 560 |
|
paul@82 | 561 | Since there are 256 pixel rows, each column of locations would be addressable
|
paul@82 | 562 | using the low byte of the address. Meanwhile, the high byte would be
|
paul@82 | 563 | incremented to address different columns. Thus, addressing screen locations
|
paul@82 | 564 | would become a lot more convenient and potentially much more efficient for
|
paul@82 | 565 | certain kinds of graphical output.
|
paul@82 | 566 |
|
paul@82 | 567 | One potential complication with this simplified addressing scheme arises with
|
paul@82 | 568 | hardware scrolling. Vertical hardware scrolling by one pixel row (not supported
|
paul@82 | 569 | with the existing ULA) would be achieved by incrementing or decrementing the
|
paul@82 | 570 | screen start address; by one character row, it would involve adding or
|
paul@82 | 571 | subtracting 8. However, the ULA only supports multiples of 64 when changing the
|
paul@82 | 572 | screen start address. Thus, if such a scheme were to be adopted, three
|
paul@82 | 573 | additional bits would need to be supported in the screen start register (see
|
paul@82 | 574 | "Hardware Scrolling (and Enhancement)" for more details). However, horizontal
|
paul@82 | 575 | scrolling would be much improved even under the severe constraints of the
|
paul@82 | 576 | existing ULA: only adjustments of 256 to the screen start address would be
|
paul@82 | 577 | required to produce single-location scrolling of as few as two pixels in MODE 2
|
paul@82 | 578 | (four pixels in MODEs 1 and 5, eight pixels otherwise).
|
paul@82 | 579 |
|
paul@82 | 580 | More disruptive is the effect of this alternative layout on software.
|
paul@82 | 581 | Presumably, compatibility with the BBC Micro was the primary goal of the
|
paul@82 | 582 | Electron's hardware design. With the character-oriented screen layout in
|
paul@82 | 583 | place, system software (and application software accessing the screen
|
paul@82 | 584 | directly) would be relying on this layout to run on the Electron with little
|
paul@82 | 585 | or no modification. Although it might have been possible to change the system
|
paul@82 | 586 | software to use this column-oriented layout instead, this would have incurred
|
paul@82 | 587 | a development cost and caused additional work porting things like games to the
|
paul@82 | 588 | Electron. Moreover, a separate branch of the software from that supporting the
|
paul@82 | 589 | BBC Micro and closer derivatives would then have needed maintaining.
|
paul@82 | 590 |
|
paul@82 | 591 | The decision to use the character-oriented layout in the BBC Micro may have
|
paul@82 | 592 | been related to the choice of circuitry and to facilitate a convenient
|
paul@82 | 593 | hardware implementation, and by the time the Electron was planned, it was too
|
paul@82 | 594 | late to do anything about this somewhat unfortunate choice.
|
paul@82 | 595 |
|
paul@89 | 596 | Pixel Layouts
|
paul@89 | 597 | -------------
|
paul@89 | 598 |
|
paul@89 | 599 | The pixel layouts are as follows:
|
paul@89 | 600 |
|
paul@89 | 601 | Modes Depth (bpp) Pixels (from bits)
|
paul@89 | 602 | ----- ----------- ------------------
|
paul@89 | 603 | 0, 3, 4, 6 1 7 6 5 4 3 2 1 0
|
paul@89 | 604 | 1, 5 2 73 62 51 40
|
paul@89 | 605 | 2 4 7531 6420
|
paul@89 | 606 |
|
paul@89 | 607 | Since the ULA reads a half-byte at a time, one might expect it to attempt to
|
paul@89 | 608 | produce pixels for every half-byte, as opposed to handling entire bytes.
|
paul@89 | 609 | However, the pixel layout is not conducive to producing pixels as soon as a
|
paul@89 | 610 | half-byte has been read for a given full-byte location: in 1bpp modes the
|
paul@89 | 611 | first four pixels can indeed be produced, but in 2bpp and 4bpp modes the pixel
|
paul@89 | 612 | data is spread across the entire byte in different ways.
|
paul@89 | 613 |
|
paul@89 | 614 | An alternative arrangement might be as follows:
|
paul@89 | 615 |
|
paul@89 | 616 | Modes Depth (bpp) Pixels (from bits)
|
paul@89 | 617 | ----- ----------- ------------------
|
paul@89 | 618 | 0, 3, 4, 6 1 7 6 5 4 3 2 1 0
|
paul@89 | 619 | 1, 5 2 76 54 32 10
|
paul@89 | 620 | 2 4 7654 3210
|
paul@89 | 621 |
|
paul@89 | 622 | Just as the mode layouts were presumably decided by compatibility with the BBC
|
paul@89 | 623 | Micro, the pixel layouts will have been maintained for similar reasons.
|
paul@89 | 624 | Unfortunately, this layout prevents any optimisation of the ULA for handling
|
paul@89 | 625 | half-byte pixel data generally.
|
paul@89 | 626 |
|
paul@79 | 627 | Enhancement: The Missing MODE 4
|
paul@79 | 628 | -------------------------------
|
paul@79 | 629 |
|
paul@79 | 630 | The Electron inherits its screen mode selection from the BBC Micro, where MODE
|
paul@79 | 631 | 3 is a text version of MODE 0, and where MODE 6 is a text version of MODE 4.
|
paul@79 | 632 | Neither MODE 3 nor MODE 6 is a genuine character-based text mode like MODE 7,
|
paul@79 | 633 | however, and they are merely implemented by skipping two scanlines in every
|
paul@79 | 634 | ten after the eight required to produce a character line. Thus, such modes
|
paul@79 | 635 | provide a 24-row display.
|
paul@79 | 636 |
|
paul@79 | 637 | In principle, nothing prevents this "text mode" effect being applied to other
|
paul@79 | 638 | modes. The 20-column modes are not well-suited to displaying text, which
|
paul@79 | 639 | leaves MODE 1 which, unlike MODEs 3 and 6, can display 4 colours rather than
|
paul@79 | 640 | 2. Although the need for a non-monochrome 40-column text mode is addressed by
|
paul@79 | 641 | MODE 7 on the BBC Micro, the Electron lacks such a mode.
|
paul@79 | 642 |
|
paul@79 | 643 | If the 4-colour, 24-row variant of MODE 1 were to be provided, logically it
|
paul@79 | 644 | would occupy MODE 4 instead of the current MODE 4:
|
paul@79 | 645 |
|
paul@79 | 646 | Screen mode Size (kilobytes) Colours Rows Resolution
|
paul@79 | 647 | ----------- ---------------- ------- ---- ----------
|
paul@79 | 648 | 0 20 2 32 640x256
|
paul@79 | 649 | 1 20 4 32 320x256
|
paul@79 | 650 | 2 20 16 32 160x256
|
paul@79 | 651 | 3 16 2 24 640x256
|
paul@79 | 652 | 4 (new) 16 4 24 320x256
|
paul@79 | 653 | 4 (old) 10 2 32 320x256
|
paul@79 | 654 | 5 10 4 32 160x256
|
paul@79 | 655 | 6 8 2 24 320x256
|
paul@79 | 656 |
|
paul@79 | 657 | Thus, for increasing mode numbers, the size of each mode would be the same or
|
paul@79 | 658 | less than the preceding mode.
|
paul@79 | 659 |
|
paul@76 | 660 | Enhancement: 2MHz RAM Access
|
paul@76 | 661 | ----------------------------
|
paul@76 | 662 |
|
paul@76 | 663 | Given that the CPU and ULA both access RAM at 2MHz, but given that the CPU
|
paul@76 | 664 | when not competing with the ULA only accesses RAM every other 2MHz cycle (as
|
paul@76 | 665 | if the ULA still needed to access the RAM), one useful enhancement would be a
|
paul@76 | 666 | mechanism to let the CPU take over the ULA cycles outside the ULA's period of
|
paul@76 | 667 | activity comparable to the way the ULA takes over the CPU cycles in MODE 0 to
|
paul@76 | 668 | 3.
|
paul@76 | 669 |
|
paul@76 | 670 | Thus, the RAM access cycles would resemble the following in MODE 0 to 3:
|
paul@76 | 671 |
|
paul@76 | 672 | Upon a transition from display cycles: UUUUCCCC (instead of UUUUC_C_)
|
paul@76 | 673 | On a non-display line: CCCCCCCC (instead of C_C_C_C_)
|
paul@76 | 674 |
|
paul@76 | 675 | In MODE 4 to 6:
|
paul@76 | 676 |
|
paul@76 | 677 | Upon a transition from display cycles: CUCUCCCC (instead of CUCUC_C_)
|
paul@76 | 678 | On a non-display line: CCCCCCCC (instead of C_C_C_C_)
|
paul@76 | 679 |
|
paul@76 | 680 | This would improve CPU bandwidth as follows:
|
paul@76 | 681 |
|
paul@118 | 682 | Standard ULA Enhanced ULA % Total Bandwidth Speedup
|
paul@118 | 683 | MODE 0, 1, 2 9728 bytes 19456 bytes 24% -> 49% 2
|
paul@118 | 684 | MODE 3 12288 bytes 24576 bytes 31% -> 62% 2
|
paul@118 | 685 | MODE 4, 5 19968 bytes 29696 bytes 50% -> 74% 1.5
|
paul@118 | 686 | MODE 6 19968 bytes 32256 bytes 50% -> 81% 1.6
|
paul@76 | 687 |
|
paul@118 | 688 | (Here, the uncontended total 2MHz bandwidth for a display period would be
|
paul@118 | 689 | 39936 bytes, being 128 cycles per line over 312 lines.)
|
paul@115 | 690 |
|
paul@76 | 691 | With such an enhancement, MODE 0 to 3 experience a doubling of CPU bandwidth
|
paul@76 | 692 | because all access opportunities to RAM are doubled. Meanwhile, in the other
|
paul@76 | 693 | modes, some CPU accesses occur alongside ULA accesses and thus cannot be
|
paul@76 | 694 | doubled, but the CPU bandwidth increase is still significant.
|
paul@76 | 695 |
|
paul@103 | 696 | Unfortunately, the mechanism for accessing the RAM is too slow to provide data
|
paul@109 | 697 | within the time constraints of 2MHz operation. There is no time remaining in a
|
paul@118 | 698 | 2MHz cycle for the CPU to receive and process any retrieved data once the
|
paul@118 | 699 | necessary signalling has been performed. The only way for the CPU to be able
|
paul@118 | 700 | to access the RAM quickly enough would be to do away with the double 4-bit
|
paul@118 | 701 | access mechanism and to have a single 8-bit channel to the memory. This would
|
paul@118 | 702 | require twice as many 1-bit RAM chips or a different kind of RAM chip, but it
|
paul@118 | 703 | would also potentially simplify the ULA.
|
paul@103 | 704 |
|
paul@55 | 705 | Enhancement: Region Blanking
|
paul@55 | 706 | ----------------------------
|
paul@4 | 707 |
|
paul@4 | 708 | The problem of permitting character-oriented blitting in programs whilst
|
paul@4 | 709 | scrolling the screen by sub-character amounts could be mitigated by permitting
|
paul@4 | 710 | a region of the display to be blank, such as the final lines of the display.
|
paul@4 | 711 | Consider the following vertical scrolling by 2 bytes that would cause an
|
paul@4 | 712 | initial character row of 6 lines and a final character row of 2 lines:
|
paul@4 | 713 |
|
paul@4 | 714 | 6 lines - initial, partial character row
|
paul@4 | 715 | 248 lines - 31 complete rows
|
paul@4 | 716 | 2 lines - final, partial character row
|
paul@4 | 717 |
|
paul@4 | 718 | If a routine were in use that wrote 8 line bitmaps to the partial character
|
paul@4 | 719 | row now split in two, it would be advisable to hide one of the regions in
|
paul@4 | 720 | order to prevent content appearing in the wrong place on screen (such as
|
paul@4 | 721 | content meant to appear at the top "leaking" onto the bottom). Blanking 6
|
paul@4 | 722 | lines would be sufficient, as can be seen from the following cases.
|
paul@4 | 723 |
|
paul@4 | 724 | Scrolling up by 2 lines:
|
paul@4 | 725 |
|
paul@4 | 726 | 6 lines - initial, partial character row
|
paul@4 | 727 | 240 lines - 30 complete rows
|
paul@4 | 728 | 4 lines - part of 1 complete row
|
paul@4 | 729 | -----------------------------------------------------------------
|
paul@4 | 730 | 4 lines - part of 1 complete row (hidden to maintain 250 lines)
|
paul@4 | 731 | 2 lines - final, partial character row (hidden)
|
paul@4 | 732 |
|
paul@4 | 733 | Scrolling down by 2 lines:
|
paul@4 | 734 |
|
paul@4 | 735 | 2 lines - initial, partial character row
|
paul@4 | 736 | 248 lines - 31 complete rows
|
paul@4 | 737 | ----------------------------------------------------------
|
paul@4 | 738 | 6 lines - final, partial character row (hidden)
|
paul@4 | 739 |
|
paul@24 | 740 | Thus, in this case, region blanking would impose a 250 line display with the
|
paul@24 | 741 | bottom 6 lines blank.
|
paul@24 | 742 |
|
paul@55 | 743 | See the description of the display suspend enhancement for a more efficient
|
paul@74 | 744 | way of blanking lines than merely blanking the palette whilst allowing the CPU
|
paul@74 | 745 | to perform useful work during the blanking period.
|
paul@74 | 746 |
|
paul@74 | 747 | To control the blanking or suspending of lines at the top and bottom of the
|
paul@74 | 748 | display, a memory location could be dedicated to the task: the upper 4 bits
|
paul@74 | 749 | could define a blanking region of up to 16 lines at the top of the screen,
|
paul@74 | 750 | whereas the lower 4 bits could define such a region at the bottom of the
|
paul@74 | 751 | screen. If more lines were required, two locations could be employed, allowing
|
paul@74 | 752 | the top and bottom regions to occupy the entire screen.
|
paul@55 | 753 |
|
paul@55 | 754 | Enhancement: Screen Height Adjustment
|
paul@55 | 755 | -------------------------------------
|
paul@24 | 756 |
|
paul@24 | 757 | The height of the screen could be configurable in order to reduce screen
|
paul@24 | 758 | memory consumption. This is not quite done in MODE 3 and 6 since the start of
|
paul@24 | 759 | the screen appears to be rounded down to the nearest page, but by reducing the
|
paul@24 | 760 | height by amounts more than a page, savings would be possible. For example:
|
paul@24 | 761 |
|
paul@24 | 762 | Screen width Depth Height Bytes per line Saving in bytes Start address
|
paul@24 | 763 | ------------ ----- ------ -------------- --------------- -------------
|
paul@24 | 764 | 640 1 252 80 320 &3140 -> &3100
|
paul@24 | 765 | 640 1 248 80 640 &3280 -> &3200
|
paul@24 | 766 | 320 1 240 40 640 &5A80 -> &5A00
|
paul@24 | 767 | 320 2 240 80 1280 &3500
|
paul@0 | 768 |
|
paul@55 | 769 | Screen Mode Selection
|
paul@55 | 770 | ---------------------
|
paul@55 | 771 |
|
paul@55 | 772 | Bits 3, 4 and 5 of address &FE*7 control the selected screen mode. For a wider
|
paul@55 | 773 | range of modes, the other bits of &FE*7 (related to sound, cassette
|
paul@55 | 774 | input/output and the Caps Lock LED) would need to be reassigned and bit 0
|
paul@55 | 775 | potentially being made available for use.
|
paul@55 | 776 |
|
paul@58 | 777 | Enhancement: Palette Definition
|
paul@58 | 778 | -------------------------------
|
paul@0 | 779 |
|
paul@0 | 780 | Since all memory accesses go via the ULA, an enhanced ULA could employ more
|
paul@0 | 781 | specific addresses than &FE*X to perform enhanced functions. For example, the
|
paul@0 | 782 | palette control is done using &FE*8-F and merely involves selecting predefined
|
paul@0 | 783 | colours, whereas an enhanced ULA could support the redefinition of all 16
|
paul@0 | 784 | colours using specific ranges such as &FE18-F (colours 0 to 7) and &FE28-F
|
paul@0 | 785 | (colours 8 to 15), where a single byte might provide 8 bits per pixel colour
|
paul@0 | 786 | specifications similar to those used on the Archimedes.
|
paul@0 | 787 |
|
paul@4 | 788 | The principal limitation here is actually the hardware: the Electron has only
|
paul@4 | 789 | a single output line for each of the red, green and blue channels, and if
|
paul@4 | 790 | those outputs are strictly digital and can only be set to a "high" and "low"
|
paul@4 | 791 | value, then only the existing eight colours are possible. If a modern ULA were
|
paul@81 | 792 | able to output analogue values (or values at well-defined points between the
|
paul@81 | 793 | high and low values, such as the half-on value supported by the Amstrad CPC
|
paul@81 | 794 | series), it would still need to be assessed whether the circuitry could
|
paul@81 | 795 | successfully handle and propagate such values. Various sources indicate that
|
paul@81 | 796 | only "TTL levels" are supported by the RGB output circuit, and since there are
|
paul@81 | 797 | 74LS08 AND logic gates involved in the RGB component outputs from the ULA, it
|
paul@81 | 798 | is likely that the ULA is expected to provide only "high" or "low" values.
|
paul@4 | 799 |
|
paul@58 | 800 | Short of adding extra outputs from the ULA (either additional red, green and
|
paul@81 | 801 | blue outputs or a combined intensity output), another approach might involve
|
paul@81 | 802 | some kind of modulation where an output value might be encoded in multiple
|
paul@81 | 803 | pulses at a higher frequency than the pixel frequency. However, this would
|
paul@81 | 804 | demand additional circuitry outside the ULA, and component RGB monitors would
|
paul@81 | 805 | probably not be able to take advantage of this feature; only UHF and composite
|
paul@81 | 806 | video devices (the latter with the composite video colour support enabled on
|
paul@81 | 807 | the Electron's circuit board) would potentially benefit.
|
paul@58 | 808 |
|
paul@51 | 809 | Flashing Colours
|
paul@51 | 810 | ----------------
|
paul@51 | 811 |
|
paul@51 | 812 | According to the Advanced User Guide, "The cursor and flashing colours are
|
paul@51 | 813 | entirely generated in software: This means that all of the logical to physical
|
paul@51 | 814 | colour map must be changed to cause colours to flash." This appears to suggest
|
paul@51 | 815 | that the palette registers must be updated upon the flash counter - read and
|
paul@51 | 816 | written by OSBYTE &C1 (193) - reaching zero and that some way of changing the
|
paul@51 | 817 | colour pairs to be any combination of colours might be possible, instead of
|
paul@52 | 818 | having colour complements as pairs.
|
paul@52 | 819 |
|
paul@52 | 820 | It is conceivable that the interrupt code responsible does the simple thing
|
paul@54 | 821 | and merely inverts the current values for any logical colours (LC) for which
|
paul@54 | 822 | the associated physical colour (as supplied as the second parameter to the VDU
|
paul@54 | 823 | 19 call) has the top bit of its four bit value set. These top bits are not
|
paul@52 | 824 | recorded in the palette registers but are presumably recorded separately and
|
paul@52 | 825 | used to build bitmaps as follows:
|
paul@52 | 826 |
|
paul@54 | 827 | LC 2 colour 4 colour 16 colour 4-bit value for inversion
|
paul@54 | 828 | -- -------- -------- --------- -------------------------
|
paul@54 | 829 | 0 00010001 00010001 00010001 1, 1, 1
|
paul@54 | 830 | 1 01000100 00100010 00010001 4, 2, 1
|
paul@54 | 831 | 2 01000100 00100010 4, 2
|
paul@54 | 832 | 3 10001000 00100010 8, 2
|
paul@54 | 833 | 4 00010001 1
|
paul@54 | 834 | 5 00010001 1
|
paul@54 | 835 | 6 00100010 2
|
paul@54 | 836 | 7 00100010 2
|
paul@54 | 837 | 8 01000100 4
|
paul@54 | 838 | 9 01000100 4
|
paul@54 | 839 | 10 10001000 8
|
paul@54 | 840 | 11 10001000 8
|
paul@54 | 841 | 12 01000100 4
|
paul@54 | 842 | 13 01000100 4
|
paul@54 | 843 | 14 10001000 8
|
paul@54 | 844 | 15 10001000 8
|
paul@54 | 845 |
|
paul@54 | 846 | Inversion value calculation:
|
paul@54 | 847 |
|
paul@54 | 848 | 2 colour formula: 1 << (colour * 2)
|
paul@54 | 849 | 4 colour formula: 1 << colour
|
paul@54 | 850 | 16 colour formula: 1 << ((colour & 2) + ((colour & 8) * 2))
|
paul@52 | 851 |
|
paul@53 | 852 | For example, where logical colour 0 has been mapped to a physical colour in
|
paul@53 | 853 | the range 8 to 15, a bitmap of 00010001 would be chosen as its contribution to
|
paul@53 | 854 | the inversion operation. (The lower three bits of the physical colour would be
|
paul@53 | 855 | used to set the underlying colour information affected by the inversion
|
paul@53 | 856 | operation.)
|
paul@53 | 857 |
|
paul@52 | 858 | An operation in the interrupt code would then combine the bitmaps for all
|
paul@52 | 859 | logical colours in 2 and 4 colour modes, with the 16 colour bitmaps being
|
paul@52 | 860 | combined for groups of logical colours as follows:
|
paul@52 | 861 |
|
paul@54 | 862 | Logical colours
|
paul@54 | 863 | ---------------
|
paul@52 | 864 | 0, 2, 8, 10
|
paul@52 | 865 | 4, 6, 12, 14
|
paul@52 | 866 | 5, 7, 13, 15
|
paul@52 | 867 | 1, 3, 9, 11
|
paul@52 | 868 |
|
paul@52 | 869 | These combined bitmaps would be EORed with the existing palette register
|
paul@52 | 870 | values in order to perform the value inversion necessary to produce the
|
paul@52 | 871 | flashing effect.
|
paul@51 | 872 |
|
paul@54 | 873 | Thus, in the VDU 19 operation, the appropriate inversion value would be
|
paul@54 | 874 | calculated for the logical colour, and this value would then be combined with
|
paul@54 | 875 | other inversion values in a dedicated memory location corresponding to the
|
paul@54 | 876 | colour's group as indicated above. Meanwhile, the palette channel values would
|
paul@54 | 877 | be derived from the lower three bits of the specified physical colour and
|
paul@54 | 878 | combined with other palette data in dedicated memory locations corresponding
|
paul@54 | 879 | to the palette registers.
|
paul@54 | 880 |
|
paul@72 | 881 | Interestingly, although flashing colours on the BBC Micro are controlled by
|
paul@72 | 882 | toggling bit 0 of the &FE20 control register location for the Video ULA, the
|
paul@72 | 883 | actual colour inversion is done in hardware.
|
paul@72 | 884 |
|
paul@55 | 885 | Enhancement: Palette Definition Lists
|
paul@55 | 886 | -------------------------------------
|
paul@4 | 887 |
|
paul@4 | 888 | It can be useful to redefine the palette in order to change the colours
|
paul@4 | 889 | available for a particular region of the screen, particularly in modes where
|
paul@4 | 890 | the choice of colours is constrained, and if an increased colour depth were
|
paul@4 | 891 | available, palette redefinition would be useful to give the illusion of more
|
paul@4 | 892 | than 16 colours in MODE 2. Traditionally, palette redefinition has been done
|
paul@4 | 893 | by using interrupt-driven timers, but a more efficient approach would involve
|
paul@4 | 894 | presenting lists of palette definitions to the ULA so that it can change the
|
paul@4 | 895 | palette at a particular display line.
|
paul@4 | 896 |
|
paul@4 | 897 | One might define a palette redefinition list in a region of memory and then
|
paul@4 | 898 | communicate its contents to the ULA by writing the address and length of the
|
paul@4 | 899 | list, along with the display line at which the palette is to be changed, to
|
paul@4 | 900 | ULA registers such that the ULA buffers the list and performs the redefinition
|
paul@4 | 901 | at the appropriate time. Throughput/bandwidth considerations might impose
|
paul@4 | 902 | restrictions on the practical length of such a list, however.
|
paul@4 | 903 |
|
paul@79 | 904 | Enhancement: Display Synchronisation Interrupts
|
paul@79 | 905 | -----------------------------------------------
|
paul@79 | 906 |
|
paul@79 | 907 | When completing each scanline of the display, the ULA could trigger an
|
paul@79 | 908 | interrupt. Since this might impact system performance substantially, the
|
paul@79 | 909 | feature would probably need to be configurable, and it might be sufficient to
|
paul@79 | 910 | have an interrupt only after a certain number of display lines instead.
|
paul@79 | 911 | Permitting the CPU to take action after eight lines would allow palette
|
paul@79 | 912 | switching and other effects to occur on a character row basis.
|
paul@79 | 913 |
|
paul@79 | 914 | The ULA provides an interrupt at the end of the display period, presumably so
|
paul@79 | 915 | that software can schedule updates to the screen, avoid flickering or tearing,
|
paul@79 | 916 | and so on. However, some applications might benefit from an interrupt at, or
|
paul@79 | 917 | just before, the start of the display period so that palette modifications or
|
paul@79 | 918 | similar effects could be scheduled.
|
paul@79 | 919 |
|
paul@55 | 920 | Enhancement: Palette-Free Modes
|
paul@55 | 921 | -------------------------------
|
paul@4 | 922 |
|
paul@4 | 923 | Palette-free modes might be defined where bit values directly correspond to
|
paul@4 | 924 | the red, green and blue channels, although this would mostly make sense only
|
paul@4 | 925 | for modes with depths greater than the standard 4 bits per pixel, and such
|
paul@4 | 926 | modes would require more memory than MODE 2 if they were to have an acceptable
|
paul@4 | 927 | resolution.
|
paul@4 | 928 |
|
paul@55 | 929 | Enhancement: Display Suspend
|
paul@55 | 930 | ----------------------------
|
paul@4 | 931 |
|
paul@4 | 932 | Especially when writing to the screen memory, it could be beneficial to be
|
paul@4 | 933 | able to suspend the ULA's access to the memory, instead producing blank values
|
paul@4 | 934 | for all screen pixels until a program is ready to reveal the screen. This is
|
paul@4 | 935 | different from palette blanking since with a blank palette, the ULA is still
|
paul@4 | 936 | reading screen memory and translating its contents into pixel values that end
|
paul@4 | 937 | up being blank.
|
paul@4 | 938 |
|
paul@4 | 939 | This function is reminiscent of a capability of the ZX81, albeit necessary on
|
paul@4 | 940 | that hardware to reduce the load on the system CPU which was responsible for
|
paul@62 | 941 | producing the video output. By allowing display suspend on the Electron, the
|
paul@62 | 942 | performance benefit would be derived from giving the CPU full access to the
|
paul@62 | 943 | memory bandwidth.
|
paul@4 | 944 |
|
paul@74 | 945 | The region blanking feature mentioned above could be implemented using this
|
paul@74 | 946 | enhancement instead of employing palette blanking for the affected lines of
|
paul@74 | 947 | the display.
|
paul@74 | 948 |
|
paul@63 | 949 | Enhancement: Memory Filling
|
paul@63 | 950 | ---------------------------
|
paul@63 | 951 |
|
paul@63 | 952 | A capability that could be given to an enhanced ULA is that of permitting the
|
paul@63 | 953 | ULA to write to screen memory as well being able to read from it. Although
|
paul@63 | 954 | such a capability would probably not be useful in conjunction with the
|
paul@63 | 955 | existing read operations when producing a screen display, and insufficient
|
paul@63 | 956 | bandwidth would exist to do so in high-bandwidth screen modes anyway, the
|
paul@63 | 957 | capability could be offered during a display suspend period (as described
|
paul@63 | 958 | above), permitting a more efficient mechanism to rapidly fill memory with a
|
paul@63 | 959 | predetermined value.
|
paul@63 | 960 |
|
paul@63 | 961 | This capability could also support block filling, where the limits of the
|
paul@63 | 962 | filled memory would be defined by the position and size of a screen area,
|
paul@63 | 963 | although this would demand the provision of additional registers in the ULA to
|
paul@63 | 964 | retain the details of such areas and additional logic to control the fill
|
paul@63 | 965 | operation.
|
paul@63 | 966 |
|
paul@69 | 967 | Enhancement: Region Filling
|
paul@69 | 968 | ---------------------------
|
paul@69 | 969 |
|
paul@69 | 970 | An alternative to memory writing might involve indicating regions using
|
paul@69 | 971 | additional registers or memory where the ULA fills regions of the screen with
|
paul@69 | 972 | content instead of reading from memory. Unlike hardware sprites which should
|
paul@69 | 973 | realistically provide varied content, region filling could employ single
|
paul@69 | 974 | colours or patterns, and one advantage of doing so would be that the ULA need
|
paul@69 | 975 | not access memory at all within a particular region.
|
paul@69 | 976 |
|
paul@69 | 977 | Regions would be defined on a row-by-row basis. Instead of reading memory and
|
paul@69 | 978 | blitting a direct representation to the screen, the ULA would read region
|
paul@69 | 979 | definitions containing a start column, region width and colour details. There
|
paul@69 | 980 | might be a certain number of definitions allowed per row, or the ULA might
|
paul@69 | 981 | just traverse an ordered list of such definitions with each one indicating the
|
paul@71 | 982 | row, start column, region width and colour details.
|
paul@71 | 983 |
|
paul@71 | 984 | One could even compress this information further by requiring only the row,
|
paul@71 | 985 | start column and colour details with each subsequent definition terminating
|
paul@71 | 986 | the effect of the previous one. However, one would also need to consider the
|
paul@71 | 987 | convenience of preparing such definitions and whether efficient access to
|
paul@71 | 988 | definitions for a particular row might be desirable. It might also be
|
paul@71 | 989 | desirable to avoid having to prepare definitions for "empty" areas of the
|
paul@71 | 990 | screen, effectively making the definition of the screen contents employ
|
paul@71 | 991 | run-length encoding and employ only colour plus length information.
|
paul@69 | 992 |
|
paul@69 | 993 | One application of region filling is that of simple 2D and 3D shape rendering.
|
paul@69 | 994 | Although it is entirely possible to plot such shapes to the screen and have
|
paul@69 | 995 | the ULA blit the memory contents to the screen, such operations consume
|
paul@69 | 996 | bandwidth both in the initial plotting and in the final transfer to the
|
paul@69 | 997 | screen. Region filling would reduce such bandwidth usage substantially.
|
paul@69 | 998 |
|
paul@71 | 999 | This way of representing screen images would make certain kinds of images
|
paul@71 | 1000 | unfeasible to represent - consider alternating single pixel values which could
|
paul@71 | 1001 | easily occur in some character bitmaps - even if an internal queue of regions
|
paul@71 | 1002 | were to be supported such that the ULA could read ahead and buffer such
|
paul@71 | 1003 | "bandwidth intensive" areas. Thus, the ULA might be better served providing
|
paul@71 | 1004 | this feature for certain areas of the display only as some kind of special
|
paul@71 | 1005 | graphics window.
|
paul@71 | 1006 |
|
paul@55 | 1007 | Enhancement: Hardware Sprites
|
paul@55 | 1008 | -----------------------------
|
paul@0 | 1009 |
|
paul@0 | 1010 | An enhanced ULA might provide hardware sprites, but this would be done in an
|
paul@0 | 1011 | way that is incompatible with the standard ULA, since no &FE*X locations are
|
paul@34 | 1012 | available for allocation. To keep the facility simple, hardware sprites would
|
paul@34 | 1013 | have a standard byte width and height.
|
paul@34 | 1014 |
|
paul@34 | 1015 | The specification of sprites could involve the reservation of 16 locations
|
paul@34 | 1016 | (for example, &FE20-F) specifying a fixed number of eight sprites, with each
|
paul@34 | 1017 | location pair referring to the sprite data. By limiting the ULA to dealing
|
paul@34 | 1018 | with a fixed number of sprites, the work required inside the ULA would be
|
paul@35 | 1019 | reduced since it would avoid having to deal with arbitrary numbers of sprites.
|
paul@0 | 1020 |
|
paul@35 | 1021 | The principal limitation on providing hardware sprites is that of having to
|
paul@35 | 1022 | obtain sprite data, given that the ULA is usually required to retrieve screen
|
paul@35 | 1023 | data, and given the lack of memory bandwidth available to retrieve sprite data
|
paul@35 | 1024 | (particularly from multiple sprites supposedly at the same position) and
|
paul@35 | 1025 | screen data simultaneously. Although the ULA could potentially read sprite
|
paul@35 | 1026 | data and screen data in alternate memory accesses in screen modes where the
|
paul@35 | 1027 | bandwidth is not already fully utilised, this would result in a degradation of
|
paul@35 | 1028 | performance.
|
paul@34 | 1029 |
|
paul@55 | 1030 | Enhancement: Additional Screen Mode Configurations
|
paul@55 | 1031 | --------------------------------------------------
|
paul@24 | 1032 |
|
paul@24 | 1033 | Alternative screen mode configurations could be supported. The ULA has to
|
paul@24 | 1034 | produce 640 pixel values across the screen, with pixel doubling or quadrupling
|
paul@24 | 1035 | employed to fill the screen width:
|
paul@24 | 1036 |
|
paul@24 | 1037 | Screen width Columns Scaling Depth Bytes
|
paul@24 | 1038 | ------------ ------- ------- ----- -----
|
paul@24 | 1039 | 640 80 x1 1 80
|
paul@24 | 1040 | 320 40 x2 1, 2 40, 80
|
paul@24 | 1041 | 160 20 x4 2, 4 40, 80
|
paul@24 | 1042 |
|
paul@24 | 1043 | It must also use at most 80 byte-sized memory accesses to provide the
|
paul@24 | 1044 | information for the display. Given that characters must occupy an 8x8 pixel
|
paul@24 | 1045 | array, if a configuration featuring anything other than 20, 40 or 80 character
|
paul@24 | 1046 | columns is to be supported, compromises must be made such as the introduction
|
paul@24 | 1047 | of blank pixels either between characters (such as occurs between rows in MODE
|
paul@24 | 1048 | 3 and 6) or at the end of a scanline (such as occurs at the end of the frame
|
paul@55 | 1049 | in MODE 3 and 6). Consider the following configuration:
|
paul@24 | 1050 |
|
paul@24 | 1051 | Screen width Columns Scaling Depth Bytes Blank
|
paul@24 | 1052 | ------------ ------- ------- ----- ------ -----
|
paul@24 | 1053 | 208 26 x3 1, 2 26, 52 16
|
paul@24 | 1054 |
|
paul@24 | 1055 | Here, if the ULA can triple pixels, a 26 column mode with either 2 or 4
|
paul@24 | 1056 | colours could be provided, with 16 blank pixel values (out of a total of 640)
|
paul@24 | 1057 | generated either at the start or end (or split between the start and end) of
|
paul@24 | 1058 | each scanline.
|
paul@24 | 1059 |
|
paul@55 | 1060 | Enhancement: Character Attributes
|
paul@55 | 1061 | ---------------------------------
|
paul@24 | 1062 |
|
paul@24 | 1063 | The BBC Micro MODE 7 employs something resembling character attributes to
|
paul@24 | 1064 | support teletext displays, but depends on circuitry providing a character
|
paul@24 | 1065 | generator. The ZX Spectrum, on the other hand, provides character attributes
|
paul@24 | 1066 | as a means of colouring bitmapped graphics. Although such a feature is very
|
paul@24 | 1067 | limiting as the sole means of providing multicolour graphics, in situations
|
paul@24 | 1068 | where the choice is between low resolution multicolour graphics or high
|
paul@24 | 1069 | resolution monochrome graphics, character attributes provide a potentially
|
paul@24 | 1070 | useful compromise.
|
paul@24 | 1071 |
|
paul@24 | 1072 | For each byte read, the ULA must deliver 8 pixel values (out of a total of
|
paul@24 | 1073 | 640) to the video output, doing so by either emptying its pixel buffer on a
|
paul@24 | 1074 | pixel per cycle basis, or by multiplying pixels and thus holding them for more
|
paul@24 | 1075 | than one cycle. For example for a screen mode having 640 pixels in width:
|
paul@24 | 1076 |
|
paul@24 | 1077 | Cycle: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
|
paul@24 | 1078 | Reads: B B
|
paul@24 | 1079 | Pixels: 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
|
paul@24 | 1080 |
|
paul@24 | 1081 | And for a screen mode having 320 pixels in width:
|
paul@24 | 1082 |
|
paul@24 | 1083 | Cycle: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
|
paul@24 | 1084 | Reads: B
|
paul@24 | 1085 | Pixels: 0 0 1 1 2 2 3 3 4 4 5 5 6 6 7 7
|
paul@24 | 1086 |
|
paul@24 | 1087 | However, in modes where less than 80 bytes are required to generate the pixel
|
paul@24 | 1088 | values, an enhanced ULA might be able to read additional bytes between those
|
paul@24 | 1089 | providing the bitmapped graphics data:
|
paul@24 | 1090 |
|
paul@24 | 1091 | Cycle: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
|
paul@24 | 1092 | Reads: B A
|
paul@24 | 1093 | Pixels: 0 0 1 1 2 2 3 3 4 4 5 5 6 6 7 7
|
paul@24 | 1094 |
|
paul@24 | 1095 | These additional bytes could provide colour information for the bitmapped data
|
paul@24 | 1096 | in the following character column (of 8 pixels). Since it would be desirable
|
paul@24 | 1097 | to apply attribute data to the first column, the initial 8 cycles might be
|
paul@24 | 1098 | configured to not produce pixel values.
|
paul@24 | 1099 |
|
paul@35 | 1100 | For an entire character, attribute data need only be read for the first row of
|
paul@35 | 1101 | pixels for a character. The subsequent rows would have attribute information
|
paul@35 | 1102 | applied to them, although this would require the attribute data to be stored
|
paul@35 | 1103 | in some kind of buffer. Thus, the following access pattern would be observed:
|
paul@35 | 1104 |
|
paul@112 | 1105 | Reads: A B _ B _ B _ B _ B _ B _ B _ B ...
|
paul@112 | 1106 |
|
paul@112 | 1107 | In modes 3 and 6, the blank display lines could be used to retrieve attribute
|
paul@112 | 1108 | data:
|
paul@112 | 1109 |
|
paul@112 | 1110 | Reads (blank): A _ A _ A _ A _ A _ A _ A _ A _ ...
|
paul@112 | 1111 | Reads (active): B _ B _ B _ B _ B _ B _ B _ B _ ...
|
paul@112 | 1112 | Reads (active): B _ B _ B _ B _ B _ B _ B _ B _ ...
|
paul@112 | 1113 | ...
|
paul@112 | 1114 |
|
paul@112 | 1115 | See below for a discussion of using this for character data as well.
|
paul@35 | 1116 |
|
paul@24 | 1117 | A whole byte used for colour information for a whole character would result in
|
paul@35 | 1118 | a choice of 256 colours, and this might be somewhat excessive. By only reading
|
paul@35 | 1119 | attribute bytes at every other opportunity, a choice of 16 colours could be
|
paul@35 | 1120 | applied individually to two characters.
|
paul@24 | 1121 |
|
paul@24 | 1122 | 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 | 1123 | Reads: B A B -
|
paul@24 | 1124 | 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 | 1125 |
|
paul@35 | 1126 | Further reductions in attribute data access, offering 4 colours for every
|
paul@35 | 1127 | character in a four character block, for example, might also be worth
|
paul@34 | 1128 | considering.
|
paul@34 | 1129 |
|
paul@24 | 1130 | Consider the following configurations for screen modes with a colour depth of
|
paul@24 | 1131 | 1 bit per pixel for bitmap information:
|
paul@24 | 1132 |
|
paul@35 | 1133 | Screen width Columns Scaling Bytes (B) Bytes (A) Colours Screen start
|
paul@35 | 1134 | ------------ ------- ------- --------- --------- ------- ------------
|
paul@35 | 1135 | 320 40 x2 40 40 256 &5300
|
paul@35 | 1136 | 320 40 x2 40 20 16 &5580 -> &5500
|
paul@35 | 1137 | 320 40 x2 40 10 4 &56C0 -> &5600
|
paul@35 | 1138 | 208 26 x3 26 26 256 &62C0 -> &6200
|
paul@35 | 1139 | 208 26 x3 26 13 16 &6460 -> &6400
|
paul@34 | 1140 |
|
paul@113 | 1141 | Enhancement: Text-Only Modes using Character and Attribute Data
|
paul@113 | 1142 | ---------------------------------------------------------------
|
paul@112 | 1143 |
|
paul@112 | 1144 | In modes 3 and 6, the blank display lines could be used to retrieve character
|
paul@112 | 1145 | and attribute data instead of trying to insert it between bitmap data accesses,
|
paul@112 | 1146 | but this data would then need to be retained:
|
paul@112 | 1147 |
|
paul@112 | 1148 | Reads: A C A C A C A C A C A C A C A C ...
|
paul@112 | 1149 | Reads: B _ B _ B _ B _ B _ B _ B _ B _ ...
|
paul@112 | 1150 |
|
paul@112 | 1151 | Only attribute (A) and character (C) reads would require screen memory
|
paul@112 | 1152 | storage. Bitmap data reads (B) would involve either accesses to memory to
|
paul@112 | 1153 | obtain character definition details or could, at the cost of special storage
|
paul@112 | 1154 | in the ULA, involve accesses within the ULA that would then free up the RAM.
|
paul@112 | 1155 | However, the CPU would not benefit from having any extra access slots due to
|
paul@112 | 1156 | the limitations of the RAM access mechanism.
|
paul@112 | 1157 |
|
paul@113 | 1158 | A scheme without caching might be possible. The same line of memory addresses
|
paul@113 | 1159 | might be visited over and over again for eight display lines, with an index
|
paul@113 | 1160 | into the bitmap data being incremented from zero to seven. The access patterns
|
paul@113 | 1161 | would look like this:
|
paul@113 | 1162 |
|
paul@113 | 1163 | Reads: C B C B C B C B C B C B C B C B ... (generate data from index 0)
|
paul@113 | 1164 | Reads: C B C B C B C B C B C B C B C B ... (generate data from index 1)
|
paul@113 | 1165 | Reads: C B C B C B C B C B C B C B C B ... (generate data from index 2)
|
paul@113 | 1166 | Reads: C B C B C B C B C B C B C B C B ... (generate data from index 3)
|
paul@113 | 1167 | Reads: C B C B C B C B C B C B C B C B ... (generate data from index 4)
|
paul@113 | 1168 | Reads: C B C B C B C B C B C B C B C B ... (generate data from index 5)
|
paul@113 | 1169 | Reads: C B C B C B C B C B C B C B C B ... (generate data from index 6)
|
paul@113 | 1170 | Reads: C B C B C B C B C B C B C B C B ... (generate data from index 7)
|
paul@113 | 1171 |
|
paul@113 | 1172 | The bandwidth requirements would be the sum of the accesses to read the
|
paul@113 | 1173 | character values (repeatedly) and those to read the bitmap data to reproduce
|
paul@113 | 1174 | the characters on screen.
|
paul@113 | 1175 |
|
paul@55 | 1176 | Enhancement: MODE 7 Emulation using Character Attributes
|
paul@55 | 1177 | --------------------------------------------------------
|
paul@24 | 1178 |
|
paul@24 | 1179 | If the scheme of applying attributes to character regions were employed to
|
paul@24 | 1180 | emulate MODE 7, in conjunction with the MODE 6 display technique, the
|
paul@24 | 1181 | following configuration would be required:
|
paul@24 | 1182 |
|
paul@24 | 1183 | Screen width Columns Rows Bytes (B) Bytes (A) Colours Screen start
|
paul@24 | 1184 | ------------ ------- ---- --------- --------- ------- ------------
|
paul@35 | 1185 | 320 40 25 40 20 16 &5ECC -> &5E00
|
paul@35 | 1186 | 320 40 25 40 10 4 &5FC6 -> &5F00
|
paul@24 | 1187 |
|
paul@35 | 1188 | Although this requires much more memory than MODE 7 (8500 bytes versus MODE
|
paul@35 | 1189 | 7's 1000 bytes), it does not need much more memory than MODE 6, and it would
|
paul@35 | 1190 | at least make a limited 40-column multicolour mode available as a substitute
|
paul@35 | 1191 | for MODE 7.
|
paul@24 | 1192 |
|
paul@113 | 1193 | Using the text-only enhancement with caching of data or with repeated reads of
|
paul@113 | 1194 | the same character data line for eight display lines, the storage requirements
|
paul@112 | 1195 | would be diminished substantially:
|
paul@112 | 1196 |
|
paul@112 | 1197 | Screen width Columns Rows Bytes (C) Bytes (A) Colours Screen start
|
paul@112 | 1198 | ------------ ------- ---- --------- --------- ------- ------------
|
paul@112 | 1199 | 320 40 25 40 20 16 &7A94 -> &7A00
|
paul@112 | 1200 | 320 40 25 40 10 4 &7B1E -> &7B00
|
paul@112 | 1201 | 320 40 25 40 5 2 &7B9B -> &7B00
|
paul@112 | 1202 | 320 40 25 40 0 (2) &7C18 -> &7C00
|
paul@112 | 1203 | 640 80 25 80 40 16 &7448 -> &7400
|
paul@112 | 1204 | 640 80 25 80 20 4 &763C -> &7600
|
paul@112 | 1205 | 640 80 25 80 10 2 &7736 -> &7700
|
paul@112 | 1206 | 640 80 25 80 0 (2) &7830 -> &7800
|
paul@112 | 1207 |
|
paul@112 | 1208 | Note that the colours describe the locally defined attributes for each
|
paul@112 | 1209 | character. When no attribute information is provided, the colours are defined
|
paul@112 | 1210 | globally.
|
paul@112 | 1211 |
|
paul@112 | 1212 | Enhancement: Compressed Character Data
|
paul@112 | 1213 | --------------------------------------
|
paul@112 | 1214 |
|
paul@112 | 1215 | Another observation about text-only modes is that they only need to store a
|
paul@112 | 1216 | restricted set of bitmapped data values. Encoding this set of values in a
|
paul@112 | 1217 | smaller unit of storage than a byte could possibly help to reduce the amount
|
paul@112 | 1218 | of storage and bandwidth required to reproduce the characters on the display.
|
paul@112 | 1219 |
|
paul@82 | 1220 | Enhancement: High Resolution Graphics
|
paul@82 | 1221 | -------------------------------------
|
paul@0 | 1222 |
|
paul@82 | 1223 | Screen modes with higher resolutions and larger colour depths might be
|
paul@82 | 1224 | possible, but this would in most cases involve the allocation of more screen
|
paul@82 | 1225 | memory, and the ULA would probably then be obliged to page in such memory for
|
paul@82 | 1226 | the CPU to be able to sensibly access it all.
|
paul@0 | 1227 |
|
paul@55 | 1228 | Enhancement: Genlock Support
|
paul@55 | 1229 | ----------------------------
|
paul@46 | 1230 |
|
paul@46 | 1231 | The ULA generates a video signal in conjunction with circuitry producing the
|
paul@46 | 1232 | output features necessary for the correct display of the screen image.
|
paul@46 | 1233 | However, it appears that the ULA drives the video synchronisation mechanism
|
paul@46 | 1234 | instead of reacting to an existing signal. Genlock support might be possible
|
paul@46 | 1235 | if the ULA were made to be responsive to such external signals, resetting its
|
paul@46 | 1236 | address generators upon receiving synchronisation events.
|
paul@46 | 1237 |
|
paul@55 | 1238 | Enhancement: Improved Sound
|
paul@55 | 1239 | ---------------------------
|
paul@0 | 1240 |
|
paul@55 | 1241 | The standard ULA reserves &FE*6 for sound generation and cassette input/output
|
paul@55 | 1242 | (with bits 1 and 2 of &FE*7 being used to select either sound generation or
|
paul@55 | 1243 | cassette I/O), thus making it impossible to support multiple channels within
|
paul@0 | 1244 | the given framework. The BBC Micro ULA employs &FE40-&FE4F for sound control,
|
paul@0 | 1245 | and an enhanced ULA could adopt this interface.
|
paul@0 | 1246 |
|
paul@9 | 1247 | The BBC Micro uses the SN76489 chip to produce sound, and the entire
|
paul@9 | 1248 | functionality of this chip could be emulated for enhanced sound, with a subset
|
paul@9 | 1249 | of the functionality exposed via the &FE*6 interface.
|
paul@9 | 1250 |
|
paul@9 | 1251 | See: http://en.wikipedia.org/wiki/Texas_Instruments_SN76489
|
paul@81 | 1252 | See: http://www.smspower.org/Development/SN76489
|
paul@9 | 1253 |
|
paul@55 | 1254 | Enhancement: Waveform Upload
|
paul@55 | 1255 | ----------------------------
|
paul@0 | 1256 |
|
paul@0 | 1257 | As with a hardware sprite function, waveforms could be uploaded or referenced
|
paul@0 | 1258 | using locations as registers referencing memory regions.
|
paul@0 | 1259 |
|
paul@55 | 1260 | Enhancement: Sound Input/Output
|
paul@55 | 1261 | -------------------------------
|
paul@46 | 1262 |
|
paul@46 | 1263 | Since the ULA already controls audio input/output for cassette-based data, it
|
paul@46 | 1264 | would have been interesting to entertain the idea of sampling and output of
|
paul@46 | 1265 | sounds through the cassette interface. However, a significant amount of
|
paul@46 | 1266 | circuitry is employed to process the input signal for use by the ULA and to
|
paul@46 | 1267 | process the output signal for recording.
|
paul@46 | 1268 |
|
paul@46 | 1269 | See: http://bbc.nvg.org/doc/A%20Hardware%20Guide%20for%20the%20BBC%20Microcomputer/bbc_hw_03.htm#3.11
|
paul@46 | 1270 |
|
paul@55 | 1271 | Enhancement: BBC ULA Compatibility
|
paul@55 | 1272 | ----------------------------------
|
paul@0 | 1273 |
|
paul@0 | 1274 | Although some new ULA functions could be defined in a way that is also
|
paul@0 | 1275 | compatible with the BBC Micro, the BBC ULA is itself incompatible with the
|
paul@0 | 1276 | Electron ULA: &FE00-7 is reserved for the video controller in the BBC memory
|
paul@0 | 1277 | map, but controls various functions specific to the 6845 video controller;
|
paul@0 | 1278 | &FE08-F is reserved for the serial controller. It therefore becomes possible
|
paul@0 | 1279 | to disregard compatibility where compatibility is already disregarded for a
|
paul@0 | 1280 | particular area of functionality.
|
paul@0 | 1281 |
|
paul@0 | 1282 | &FE20-F maps to video ULA functionality on the BBC Micro which provides
|
paul@0 | 1283 | control over the palette (using address &FE21, compared to &FE07-F on the
|
paul@0 | 1284 | Electron) and other system-specific functions. Since the location usage is
|
paul@0 | 1285 | generally incompatible, this region could be reused for other purposes.
|
paul@31 | 1286 |
|
paul@55 | 1287 | Enhancement: Increased RAM, ULA and CPU Performance
|
paul@55 | 1288 | ---------------------------------------------------
|
paul@49 | 1289 |
|
paul@49 | 1290 | More modern implementations of the hardware might feature faster RAM coupled
|
paul@49 | 1291 | with an increased ULA clock frequency in order to increase the bandwidth
|
paul@49 | 1292 | available to the ULA and to the CPU in situations where the ULA is not needed
|
paul@49 | 1293 | to perform work. A ULA employing a 32MHz clock would be able to complete the
|
paul@49 | 1294 | retrieval of a byte from RAM in only 250ns and thus be able to enable the CPU
|
paul@49 | 1295 | to access the RAM for the following 250ns even in display modes requiring the
|
paul@49 | 1296 | retrieval of a byte for the display every 500ns. The CPU could, subject to
|
paul@49 | 1297 | timing issues, run at 2MHz even in MODE 0, 1 and 2.
|
paul@49 | 1298 |
|
paul@49 | 1299 | A scheme such as that described above would have a similar effect to the
|
paul@49 | 1300 | scheme employed in the BBC Micro, although the latter made use of RAM with a
|
paul@49 | 1301 | wider bandwidth in order to complete memory transfers within 250ns and thus
|
paul@49 | 1302 | permit the CPU to run continuously at 2MHz.
|
paul@49 | 1303 |
|
paul@49 | 1304 | Higher bandwidth could potentially be used to implement exotic features such
|
paul@49 | 1305 | as RAM-resident hardware sprites or indeed any feature demanding RAM access
|
paul@49 | 1306 | concurrent with the production of the display image.
|
paul@49 | 1307 |
|
paul@80 | 1308 | Enhancement: Multiple CPU Stacks and Zero Pages
|
paul@80 | 1309 | -----------------------------------------------
|
paul@75 | 1310 |
|
paul@75 | 1311 | The 6502 maintains a stack for subroutine calls and register storage in page
|
paul@75 | 1312 | &01. Although the stack register can be manipulated using the TSX and TXS
|
paul@75 | 1313 | instructions, thereby permitting the maintenance of multiple stack regions and
|
paul@75 | 1314 | thus the potential coexistence of multiple programs each using a separate
|
paul@75 | 1315 | region, only programs that make little use of the stack (perhaps avoiding
|
paul@75 | 1316 | deeply-nested subroutine invocations and significant register storage) would
|
paul@75 | 1317 | be able to coexist without overwriting each other's stacks.
|
paul@75 | 1318 |
|
paul@75 | 1319 | One way that this issue could be alleviated would involve the provision of a
|
paul@75 | 1320 | facility to redirect accesses to page &01 to other areas of memory. The ULA
|
paul@75 | 1321 | would provide a register that defines a physical page for the use of the CPU's
|
paul@75 | 1322 | "logical" page &01, and upon any access to page &01 by the CPU, the ULA would
|
paul@75 | 1323 | change the asserted address lines to redirect the access to the appropriate
|
paul@75 | 1324 | physical region.
|
paul@75 | 1325 |
|
paul@75 | 1326 | By providing an 8-bit register, mapping to the most significant byte (MSB) of
|
paul@75 | 1327 | a 16-bit address, the ULA could then replace any MSB equal to &01 with the
|
paul@75 | 1328 | register value before the access is made. Where multiple programs coexist,
|
paul@75 | 1329 | upon switching programs, the register would be updated to point the ULA to the
|
paul@75 | 1330 | appropriate stack location, thus providing a simple memory management unit
|
paul@75 | 1331 | (MMU) capability.
|
paul@75 | 1332 |
|
paul@80 | 1333 | In a similar fashion, zero page accesses could also be redirected so that code
|
paul@80 | 1334 | could run from sideways RAM and have zero page operations redirected to "upper
|
paul@80 | 1335 | memory" - for example, to page &BE (with stack accesses redirected to page
|
paul@80 | 1336 | &BF, perhaps) - thereby permitting most CPU operations to occur without
|
paul@80 | 1337 | inadvertent accesses to "lower memory" (the RAM) which would risk stalling the
|
paul@80 | 1338 | CPU as it contends with the ULA for memory access.
|
paul@80 | 1339 |
|
paul@80 | 1340 | Such facilities could also be provided by a separate circuit between the CPU
|
paul@80 | 1341 | and ULA in a fashion similar to that employed by a "turbo" board, but unlike
|
paul@80 | 1342 | such boards, no additional RAM would be provided: all memory accesses would
|
paul@80 | 1343 | occur as normal through the ULA, albeit redirected when configured
|
paul@80 | 1344 | appropriately.
|
paul@80 | 1345 |
|
paul@31 | 1346 | ULA Pin Functions
|
paul@31 | 1347 | -----------------
|
paul@31 | 1348 |
|
paul@31 | 1349 | The functions of the ULA pins are described in the Electron Service Manual. Of
|
paul@31 | 1350 | interest to video processing are the following:
|
paul@31 | 1351 |
|
paul@31 | 1352 | CSYNC (low during horizontal or vertical synchronisation periods, high
|
paul@31 | 1353 | otherwise)
|
paul@31 | 1354 |
|
paul@31 | 1355 | HS (low during horizontal synchronisation periods, high otherwise)
|
paul@31 | 1356 |
|
paul@31 | 1357 | RED, GREEN, BLUE (pixel colour outputs)
|
paul@31 | 1358 |
|
paul@31 | 1359 | CLOCK IN (a 16MHz clock input, 4V peak to peak)
|
paul@31 | 1360 |
|
paul@31 | 1361 | PHI OUT (a 1MHz, 2MHz and stopped clock signal for the CPU)
|
paul@31 | 1362 |
|
paul@31 | 1363 | More general memory access pins:
|
paul@31 | 1364 |
|
paul@31 | 1365 | RAM0...RAM3 (data lines to/from the RAM)
|
paul@31 | 1366 |
|
paul@31 | 1367 | RA0...RA7 (address lines for sending both row and column addresses to the RAM)
|
paul@31 | 1368 |
|
paul@38 | 1369 | RAS (row address strobe setting the row address on a negative edge - see the
|
paul@38 | 1370 | timing notes)
|
paul@31 | 1371 |
|
paul@38 | 1372 | CAS (column address strobe setting the column address on a negative edge -
|
paul@38 | 1373 | see the timing notes)
|
paul@31 | 1374 |
|
paul@31 | 1375 | WE (sets write enable with logic 0, read with logic 1)
|
paul@31 | 1376 |
|
paul@31 | 1377 | ROM (select data access from ROM)
|
paul@31 | 1378 |
|
paul@31 | 1379 | CPU-oriented memory access pins:
|
paul@31 | 1380 |
|
paul@31 | 1381 | A0...A15 (CPU address lines)
|
paul@31 | 1382 |
|
paul@31 | 1383 | PD0...PD7 (CPU data lines)
|
paul@31 | 1384 |
|
paul@31 | 1385 | R/W (indicates CPU write with logic 0, CPU read with logic 1)
|
paul@31 | 1386 |
|
paul@31 | 1387 | Interrupt-related pins:
|
paul@31 | 1388 |
|
paul@31 | 1389 | NMI (CPU request for uninterrupted 1MHz access to memory)
|
paul@31 | 1390 |
|
paul@31 | 1391 | IRQ (signal event to CPU)
|
paul@31 | 1392 |
|
paul@31 | 1393 | POR (power-on reset, resetting the ULA on a positive edge and asserting the
|
paul@31 | 1394 | CPU's RST pin)
|
paul@31 | 1395 |
|
paul@31 | 1396 | RST (master reset for the CPU signalled on power-up and by the Break key)
|
paul@31 | 1397 |
|
paul@31 | 1398 | Keyboard-related pins:
|
paul@31 | 1399 |
|
paul@31 | 1400 | KBD0...KBD3 (keyboard inputs)
|
paul@31 | 1401 |
|
paul@31 | 1402 | CAPS LOCK (control status LED)
|
paul@31 | 1403 |
|
paul@31 | 1404 | Sound-related pins:
|
paul@31 | 1405 |
|
paul@31 | 1406 | SOUND O/P (sound output using internal oscillator)
|
paul@31 | 1407 |
|
paul@31 | 1408 | Cassette-related pins:
|
paul@31 | 1409 |
|
paul@31 | 1410 | CAS IN (cassette circuit input, between 0.5V to 2V peak to peak)
|
paul@31 | 1411 |
|
paul@31 | 1412 | CAS OUT (pseudo-sinusoidal output, 1.8V peak to peak)
|
paul@31 | 1413 |
|
paul@31 | 1414 | CAS RC (detect high tone)
|
paul@31 | 1415 |
|
paul@31 | 1416 | CAS MO (motor relay output)
|
paul@31 | 1417 |
|
paul@31 | 1418 | ÷13 IN (~1200 baud clock input)
|
paul@46 | 1419 |
|
paul@72 | 1420 | ULA Socket
|
paul@72 | 1421 | ----------
|
paul@72 | 1422 |
|
paul@72 | 1423 | The socket used for the ULA is a 3M/TexTool 268-5400 68-pin socket.
|
paul@72 | 1424 |
|
paul@46 | 1425 | References
|
paul@46 | 1426 | ----------
|
paul@46 | 1427 |
|
paul@46 | 1428 | See: http://bbc.nvg.org/doc/A%20Hardware%20Guide%20for%20the%20BBC%20Microcomputer/bbc_hw.htm
|
paul@71 | 1429 |
|
paul@71 | 1430 | About this Document
|
paul@71 | 1431 | -------------------
|
paul@71 | 1432 |
|
paul@71 | 1433 | The most recent version of this document and accompanying distribution should
|
paul@71 | 1434 | be available from the following location:
|
paul@71 | 1435 |
|
paul@71 | 1436 | http://hgweb.boddie.org.uk/ULA
|
paul@71 | 1437 |
|
paul@71 | 1438 | Copyright and licence information can be found in the docs directory of this
|
paul@71 | 1439 | distribution - see docs/COPYING.txt for more information.
|