1 Timing
2 ------
3
4 According to the above (15.3.2 in the AUG), there are 312 scanlines, 256 of
5 which are used to generate pixel data. At 50Hz, this means that 128 cycles are
6 used to produce pixel data (2000000 cycles / 50 = 40000 cycles; 40000 cycles /
7 312 ~= 128 cycles). This is consistent with the observation that each scanline
8 requires at most 80 bytes of data, and that the ULA is apparently busy for 40
9 out of 64 microseconds in each scanline.
10
11 See: Acorn Electron Advanced User Guide
12 See: http://mdfs.net/Docs/Comp/Electron/Techinfo.htm
13
14 Access to RAM involves accessing four 64Kb dynamic RAM devices (IC4 to IC7,
15 each providing two bits of each byte) using two cycles within the 500ns period
16 of the 2MHz clock to complete each access operation. Since the CPU and ULA
17 have to take turns in accessing the RAM in MODE 4, 5 and 6, the CPU must
18 effectively run at 1MHz (since every other 500ns period involves the ULA
19 accessing RAM). The CPU is driven by an external clock (IC8) whose 16MHz
20 frequency is divided by the ULA (IC1) depending on the screen mode in use.
21
22 See: Acorn Electron Service Manual
23 http://acorn.chriswhy.co.uk/docs/Acorn/Manuals/Acorn_ElectronSM.pdf
24
25 Each 16MHz cycle is approximately 62.5ns. To access the memory, the following
26 patterns corresponding to 16MHz cycles are required:
27
28 Time (ns): 0-------------- 500------------
29 2 MHz cycle: 0 1 ...
30 16 MHz cycle: 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 ...
31 ~RAS: 0 1 0 1 ...
32 ~CAS: 0 1 0 1 0 1 0 1 ...
33 A B
34 F S
35
36 Here, "A" indicates the row and column addresses being latched into the RAM
37 (on a negative edge for RAS and CAS respectively), and "B" indicates the
38 second column address being latched into the RAM. Presumably, the first and
39 second half-bytes can be read at "F" and "S" respectively.
40
41 Shadow/Expanded Memory
42 ----------------------
43
44 The Electron exposes all sixteen address lines and all eight data lines
45 through the expansion bus. Using such lines, it is possible to provide
46 additional memory - typically sideways ROM and RAM - on expansion cards and
47 through cartridges, although the official cartridge specification provides
48 fewer address lines and only seeks to provide access to memory in 16K units.
49
50 Various modifications and upgrades were developed to offer "turbo"
51 capabilities to the Electron, permitting the CPU to access a separate 8K of
52 RAM at 2MHz, presumably preventing access to the low 8K of RAM accessible via
53 the ULA through additional logic. However, an enhanced ULA might support
54 independent CPU access to memory over the expansion bus by allowing itself to
55 be discharged from providing access to memory, potentially for a range of
56 addresses, and for the CPU to communicate with external memory uninterrupted.
57
58 Hardware Scrolling
59 ------------------
60
61 On the standard ULA, &FE02 and &FE03 map to a 9 significant bits address with
62 the least significant 5 bits being zero, thus limiting the scrolling
63 resolution to 64 bytes. An enhanced ULA could support a resolution of 2 bytes
64 using the same layout of these addresses.
65
66 |--&FE02--------------| |--&FE03--------------|
67 XX XX 14 13 12 11 10 09 08 07 06 XX XX XX XX XX
68
69 XX 14 13 12 11 10 09 08 07 06 05 04 03 02 01 XX
70
71 Arguably, a resolution of 8 bytes is more useful, since the mapping of screen
72 memory to pixel locations is character oriented. A change in 8 bytes would
73 permit a horizontal scrolling resolution of 2 pixels in MODE 2, 4 pixels in
74 MODE 1 and 5, and 8 pixels in MODE 0, 3 and 6. This resolution is actually
75 observed on the BBC Micro (see 18.11.2 in the BBC Microcomputer Advanced User
76 Guide).
77
78 One argument for a 2 byte resolution is smooth vertical scrolling. A pitfall
79 of changing the screen address by 2 bytes is the change in the number of lines
80 from the initial and final character rows that need reading by the ULA, which
81 would need to maintain this state information (although this is a relatively
82 trivial change). Another pitfall is the complication that might be introduced
83 to software writing bitmaps of character height to the screen.
84
85 Region Blanking
86 ---------------
87
88 The problem of permitting character-oriented blitting in programs whilst
89 scrolling the screen by sub-character amounts could be mitigated by permitting
90 a region of the display to be blank, such as the final lines of the display.
91 Consider the following vertical scrolling by 2 bytes that would cause an
92 initial character row of 6 lines and a final character row of 2 lines:
93
94 6 lines - initial, partial character row
95 248 lines - 31 complete rows
96 2 lines - final, partial character row
97
98 If a routine were in use that wrote 8 line bitmaps to the partial character
99 row now split in two, it would be advisable to hide one of the regions in
100 order to prevent content appearing in the wrong place on screen (such as
101 content meant to appear at the top "leaking" onto the bottom). Blanking 6
102 lines would be sufficient, as can be seen from the following cases.
103
104 Scrolling up by 2 lines:
105
106 6 lines - initial, partial character row
107 240 lines - 30 complete rows
108 4 lines - part of 1 complete row
109 -----------------------------------------------------------------
110 4 lines - part of 1 complete row (hidden to maintain 250 lines)
111 2 lines - final, partial character row (hidden)
112
113 Scrolling down by 2 lines:
114
115 2 lines - initial, partial character row
116 248 lines - 31 complete rows
117 ----------------------------------------------------------
118 6 lines - final, partial character row (hidden)
119
120 Thus, in this case, region blanking would impose a 250 line display with the
121 bottom 6 lines blank.
122
123 Screen Height Adjustment
124 ------------------------
125
126 The height of the screen could be configurable in order to reduce screen
127 memory consumption. This is not quite done in MODE 3 and 6 since the start of
128 the screen appears to be rounded down to the nearest page, but by reducing the
129 height by amounts more than a page, savings would be possible. For example:
130
131 Screen width Depth Height Bytes per line Saving in bytes Start address
132 ------------ ----- ------ -------------- --------------- -------------
133 640 1 252 80 320 &3140 -> &3100
134 640 1 248 80 640 &3280 -> &3200
135 320 1 240 40 640 &5A80 -> &5A00
136 320 2 240 80 1280 &3500
137
138 Palette Definition
139 ------------------
140
141 Since all memory accesses go via the ULA, an enhanced ULA could employ more
142 specific addresses than &FE*X to perform enhanced functions. For example, the
143 palette control is done using &FE*8-F and merely involves selecting predefined
144 colours, whereas an enhanced ULA could support the redefinition of all 16
145 colours using specific ranges such as &FE18-F (colours 0 to 7) and &FE28-F
146 (colours 8 to 15), where a single byte might provide 8 bits per pixel colour
147 specifications similar to those used on the Archimedes.
148
149 The principal limitation here is actually the hardware: the Electron has only
150 a single output line for each of the red, green and blue channels, and if
151 those outputs are strictly digital and can only be set to a "high" and "low"
152 value, then only the existing eight colours are possible. If a modern ULA were
153 able to output analogue values, it would still need to be assessed whether the
154 circuitry could successfully handle and propagate such values.
155
156 Palette Definition Lists
157 ------------------------
158
159 It can be useful to redefine the palette in order to change the colours
160 available for a particular region of the screen, particularly in modes where
161 the choice of colours is constrained, and if an increased colour depth were
162 available, palette redefinition would be useful to give the illusion of more
163 than 16 colours in MODE 2. Traditionally, palette redefinition has been done
164 by using interrupt-driven timers, but a more efficient approach would involve
165 presenting lists of palette definitions to the ULA so that it can change the
166 palette at a particular display line.
167
168 One might define a palette redefinition list in a region of memory and then
169 communicate its contents to the ULA by writing the address and length of the
170 list, along with the display line at which the palette is to be changed, to
171 ULA registers such that the ULA buffers the list and performs the redefinition
172 at the appropriate time. Throughput/bandwidth considerations might impose
173 restrictions on the practical length of such a list, however.
174
175 Palette-Free Modes
176 ------------------
177
178 Palette-free modes might be defined where bit values directly correspond to
179 the red, green and blue channels, although this would mostly make sense only
180 for modes with depths greater than the standard 4 bits per pixel, and such
181 modes would require more memory than MODE 2 if they were to have an acceptable
182 resolution.
183
184 Display Suspend
185 ---------------
186
187 Especially when writing to the screen memory, it could be beneficial to be
188 able to suspend the ULA's access to the memory, instead producing blank values
189 for all screen pixels until a program is ready to reveal the screen. This is
190 different from palette blanking since with a blank palette, the ULA is still
191 reading screen memory and translating its contents into pixel values that end
192 up being blank.
193
194 This function is reminiscent of a capability of the ZX81, albeit necessary on
195 that hardware to reduce the load on the system CPU which was responsible for
196 producing the video output.
197
198 Hardware Sprites
199 ----------------
200
201 An enhanced ULA might provide hardware sprites, but this would be done in an
202 way that is incompatible with the standard ULA, since no &FE*X locations are
203 available for allocation. To keep the facility simple, hardware sprites would
204 have a standard byte width and height.
205
206 The specification of sprites could involve the reservation of 16 locations
207 (for example, &FE20-F) specifying a fixed number of eight sprites, with each
208 location pair referring to the sprite data. By limiting the ULA to dealing
209 with a fixed number of sprites, the work required inside the ULA would be
210 reduced since it would avoid having to deal with arbitrary numbers of sprites.
211
212 The principal limitation on providing hardware sprites is that of having to
213 obtain sprite data, given that the ULA is usually required to retrieve screen
214 data, and given the lack of memory bandwidth available to retrieve sprite data
215 (particularly from multiple sprites supposedly at the same position) and
216 screen data simultaneously. Although the ULA could potentially read sprite
217 data and screen data in alternate memory accesses in screen modes where the
218 bandwidth is not already fully utilised, this would result in a degradation of
219 performance.
220
221 Additional Screen Mode Configurations
222 -------------------------------------
223
224 Alternative screen mode configurations could be supported. The ULA has to
225 produce 640 pixel values across the screen, with pixel doubling or quadrupling
226 employed to fill the screen width:
227
228 Screen width Columns Scaling Depth Bytes
229 ------------ ------- ------- ----- -----
230 640 80 x1 1 80
231 320 40 x2 1, 2 40, 80
232 160 20 x4 2, 4 40, 80
233
234 It must also use at most 80 byte-sized memory accesses to provide the
235 information for the display. Given that characters must occupy an 8x8 pixel
236 array, if a configuration featuring anything other than 20, 40 or 80 character
237 columns is to be supported, compromises must be made such as the introduction
238 of blank pixels either between characters (such as occurs between rows in MODE
239 3 and 6) or at the end of a scanline (such as occurs at the end of the frame
240 in MODE 3 and 6). Consider the following configuration:
241
242 Screen width Columns Scaling Depth Bytes Blank
243 ------------ ------- ------- ----- ------ -----
244 208 26 x3 1, 2 26, 52 16
245
246 Here, if the ULA can triple pixels, a 26 column mode with either 2 or 4
247 colours could be provided, with 16 blank pixel values (out of a total of 640)
248 generated either at the start or end (or split between the start and end) of
249 each scanline.
250
251 Character Attributes
252 --------------------
253
254 The BBC Micro MODE 7 employs something resembling character attributes to
255 support teletext displays, but depends on circuitry providing a character
256 generator. The ZX Spectrum, on the other hand, provides character attributes
257 as a means of colouring bitmapped graphics. Although such a feature is very
258 limiting as the sole means of providing multicolour graphics, in situations
259 where the choice is between low resolution multicolour graphics or high
260 resolution monochrome graphics, character attributes provide a potentially
261 useful compromise.
262
263 For each byte read, the ULA must deliver 8 pixel values (out of a total of
264 640) to the video output, doing so by either emptying its pixel buffer on a
265 pixel per cycle basis, or by multiplying pixels and thus holding them for more
266 than one cycle. For example for a screen mode having 640 pixels in width:
267
268 Cycle: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
269 Reads: B B
270 Pixels: 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
271
272 And for a screen mode having 320 pixels in width:
273
274 Cycle: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
275 Reads: B
276 Pixels: 0 0 1 1 2 2 3 3 4 4 5 5 6 6 7 7
277
278 However, in modes where less than 80 bytes are required to generate the pixel
279 values, an enhanced ULA might be able to read additional bytes between those
280 providing the bitmapped graphics data:
281
282 Cycle: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
283 Reads: B A
284 Pixels: 0 0 1 1 2 2 3 3 4 4 5 5 6 6 7 7
285
286 These additional bytes could provide colour information for the bitmapped data
287 in the following character column (of 8 pixels). Since it would be desirable
288 to apply attribute data to the first column, the initial 8 cycles might be
289 configured to not produce pixel values.
290
291 For an entire character, attribute data need only be read for the first row of
292 pixels for a character. The subsequent rows would have attribute information
293 applied to them, although this would require the attribute data to be stored
294 in some kind of buffer. Thus, the following access pattern would be observed:
295
296 Cycle: A B ... _ B ... _ B ... _ B ... _ B ... _ B ... _ B ... _ B ...
297
298 A whole byte used for colour information for a whole character would result in
299 a choice of 256 colours, and this might be somewhat excessive. By only reading
300 attribute bytes at every other opportunity, a choice of 16 colours could be
301 applied individually to two characters.
302
303 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
304 Reads: B A B -
305 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
306
307 Further reductions in attribute data access, offering 4 colours for every
308 character in a four character block, for example, might also be worth
309 considering.
310
311 Consider the following configurations for screen modes with a colour depth of
312 1 bit per pixel for bitmap information:
313
314 Screen width Columns Scaling Bytes (B) Bytes (A) Colours Screen start
315 ------------ ------- ------- --------- --------- ------- ------------
316 320 40 x2 40 40 256 &5300
317 320 40 x2 40 20 16 &5580 -> &5500
318 320 40 x2 40 10 4 &56C0 -> &5600
319 208 26 x3 26 26 256 &62C0 -> &6200
320 208 26 x3 26 13 16 &6460 -> &6400
321
322 MODE 7 Emulation using Character Attributes
323 -------------------------------------------
324
325 If the scheme of applying attributes to character regions were employed to
326 emulate MODE 7, in conjunction with the MODE 6 display technique, the
327 following configuration would be required:
328
329 Screen width Columns Rows Bytes (B) Bytes (A) Colours Screen start
330 ------------ ------- ---- --------- --------- ------- ------------
331 320 40 25 40 20 16 &5ECC -> &5E00
332 320 40 25 40 10 4 &5FC6 -> &5F00
333
334 Although this requires much more memory than MODE 7 (8500 bytes versus MODE
335 7's 1000 bytes), it does not need much more memory than MODE 6, and it would
336 at least make a limited 40-column multicolour mode available as a substitute
337 for MODE 7.
338
339 Enhanced Graphics and Mode Layouts
340 ----------------------------------
341
342 Screen modes with different screen memory mappings, higher resolutions and
343 larger colour depths might be possible, but this would in most cases involve
344 the allocation of more screen memory, and the ULA would probably then be
345 obliged to page in such memory for the CPU to be able to sensibly access it
346 all. Merely changing the memory mappings in order to have Archimedes-style
347 row-oriented screen addresses (instead of character-oriented addresses) could
348 be done for the existing modes, but this might not be sufficiently beneficial,
349 especially since accessing regions of the screen would involve incrementing
350 pointers by amounts that are inconvenient on an 8-bit CPU.
351
352 Enhanced Sound
353 --------------
354
355 The standard ULA reserves &FE*6 for sound generation and cassette
356 input/output, thus making it impossible to support multiple channels within
357 the given framework. The BBC Micro ULA employs &FE40-&FE4F for sound control,
358 and an enhanced ULA could adopt this interface.
359
360 The BBC Micro uses the SN76489 chip to produce sound, and the entire
361 functionality of this chip could be emulated for enhanced sound, with a subset
362 of the functionality exposed via the &FE*6 interface.
363
364 See: http://en.wikipedia.org/wiki/Texas_Instruments_SN76489
365
366 Waveform Upload
367 ---------------
368
369 As with a hardware sprite function, waveforms could be uploaded or referenced
370 using locations as registers referencing memory regions.
371
372 BBC ULA Compatibility
373 ---------------------
374
375 Although some new ULA functions could be defined in a way that is also
376 compatible with the BBC Micro, the BBC ULA is itself incompatible with the
377 Electron ULA: &FE00-7 is reserved for the video controller in the BBC memory
378 map, but controls various functions specific to the 6845 video controller;
379 &FE08-F is reserved for the serial controller. It therefore becomes possible
380 to disregard compatibility where compatibility is already disregarded for a
381 particular area of functionality.
382
383 &FE20-F maps to video ULA functionality on the BBC Micro which provides
384 control over the palette (using address &FE21, compared to &FE07-F on the
385 Electron) and other system-specific functions. Since the location usage is
386 generally incompatible, this region could be reused for other purposes.
387
388 ULA Pin Functions
389 -----------------
390
391 The functions of the ULA pins are described in the Electron Service Manual. Of
392 interest to video processing are the following:
393
394 CSYNC (low during horizontal or vertical synchronisation periods, high
395 otherwise)
396
397 HS (low during horizontal synchronisation periods, high otherwise)
398
399 RED, GREEN, BLUE (pixel colour outputs)
400
401 CLOCK IN (a 16MHz clock input, 4V peak to peak)
402
403 PHI OUT (a 1MHz, 2MHz and stopped clock signal for the CPU)
404
405 More general memory access pins:
406
407 RAM0...RAM3 (data lines to/from the RAM)
408
409 RA0...RA7 (address lines for sending both row and column addresses to the RAM)
410
411 RAS (row address strobe setting the row address on a negative edge)
412
413 CAS (column address strobe setting the column address on a negative edge)
414
415 WE (sets write enable with logic 0, read with logic 1)
416
417 ROM (select data access from ROM)
418
419 CPU-oriented memory access pins:
420
421 A0...A15 (CPU address lines)
422
423 PD0...PD7 (CPU data lines)
424
425 R/W (indicates CPU write with logic 0, CPU read with logic 1)
426
427 Interrupt-related pins:
428
429 NMI (CPU request for uninterrupted 1MHz access to memory)
430
431 IRQ (signal event to CPU)
432
433 POR (power-on reset, resetting the ULA on a positive edge and asserting the
434 CPU's RST pin)
435
436 RST (master reset for the CPU signalled on power-up and by the Break key)
437
438 Keyboard-related pins:
439
440 KBD0...KBD3 (keyboard inputs)
441
442 CAPS LOCK (control status LED)
443
444 Sound-related pins:
445
446 SOUND O/P (sound output using internal oscillator)
447
448 Cassette-related pins:
449
450 CAS IN (cassette circuit input, between 0.5V to 2V peak to peak)
451
452 CAS OUT (pseudo-sinusoidal output, 1.8V peak to peak)
453
454 CAS RC (detect high tone)
455
456 CAS MO (motor relay output)
457
458 ÷13 IN (~1200 baud clock input)