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