Timing

------

According to the above (15.3.2 in the AUG), there are 312 scanlines, 256 of

which are used to generate pixel data. At 50Hz, this means that 128 cycles are

used to produce pixel data (2000000 / 50 = 40000; 40000 / 312 ~= 128). This is

consistent with the observation that each scanline requires at most 80 bytes

of data, and that the ULA is apparently busy for 40 out of 64 microseconds in

each scanline.

See: Acorn Electron Advanced User Guide

See: http://mdfs.net/Docs/Comp/Electron/Techinfo.htm

Access to RAM involves accessing four 64Kb dynamic RAM devices (IC4 to IC7,

each providing two bits of each byte) using two cycles within the 500ns period

of the 2MHz clock to complete each access operation.

See: Acorn Electron Service Manual

Hardware Scrolling

------------------

On the standard ULA, &FE02 and &FE03 map to a 9 significant bits address with

the least significant 5 bits being zero, thus limiting the scrolling

resolution to 64 bytes. An enhanced ULA could support a resolution of 2 bytes

using the same layout of these addresses.

|--&FE02--------------| |--&FE03--------------|

XX XX 14 13 12 11 10 09 08 07 06 XX XX XX XX XX

   XX 14 13 12 11 10 09 08 07 06 05 04 03 02 01 XX

Arguably, a resolution of 8 bytes is more useful, since the mapping of screen

memory to pixel locations is character oriented. A change in 8 bytes would

permit a horizontal scrolling resolution of 2 pixels in MODE 2, 4 pixels in

MODE 1 and 5, and 8 pixels in MODE 0, 3 and 6. This resolution is actually

observed on the BBC Micro (see 18.11.2 in the BBC Microcomputer Advanced User

Guide).

One argument for a 2 byte resolution is smooth vertical scrolling. A pitfall

of changing the screen address by 2 bytes is the change in the number of lines

from the initial and final character rows that need reading by the ULA, which

would need to maintain this state information (although this is a relatively

trivial change). Another pitfall is the complication that might be introduced

to software writing bitmaps of character height to the screen.

Region Blanking

---------------

The problem of permitting character-oriented blitting in programs whilst

scrolling the screen by sub-character amounts could be mitigated by permitting

a region of the display to be blank, such as the final lines of the display.

Consider the following vertical scrolling by 2 bytes that would cause an

initial character row of 6 lines and a final character row of 2 lines:

    6 lines - initial, partial character row

  248 lines - 31 complete rows

    2 lines - final, partial character row

If a routine were in use that wrote 8 line bitmaps to the partial character

row now split in two, it would be advisable to hide one of the regions in

order to prevent content appearing in the wrong place on screen (such as

content meant to appear at the top "leaking" onto the bottom). Blanking 6

lines would be sufficient, as can be seen from the following cases.

Scrolling up by 2 lines:

    6 lines - initial, partial character row

  240 lines - 30 complete rows

    4 lines - part of 1 complete row

  -----------------------------------------------------------------

    4 lines - part of 1 complete row (hidden to maintain 250 lines)

    2 lines - final, partial character row (hidden)

Scrolling down by 2 lines:

    2 lines - initial, partial character row

  248 lines - 31 complete rows

  ----------------------------------------------------------

    6 lines - final, partial character row (hidden)

Thus, in this case, region blanking would impose a 250 line display with the

bottom 6 lines blank.

Screen Height Adjustment

------------------------

The height of the screen could be configurable in order to reduce screen

memory consumption. This is not quite done in MODE 3 and 6 since the start of

the screen appears to be rounded down to the nearest page, but by reducing the

height by amounts more than a page, savings would be possible. For example:

  Screen width  Depth  Height  Bytes per line  Saving in bytes  Start address

  ------------  -----  ------  --------------  ---------------  -------------

  640           1      252     80              320              &3140 -> &3100

  640           1      248     80              640              &3280 -> &3200

  320           1      240     40              640              &5A80 -> &5A00

  320           2      240     80              1280             &3500

Palette Definition

------------------

Since all memory accesses go via the ULA, an enhanced ULA could employ more

specific addresses than &FE*X to perform enhanced functions. For example, the

palette control is done using &FE*8-F and merely involves selecting predefined

colours, whereas an enhanced ULA could support the redefinition of all 16

colours using specific ranges such as &FE18-F (colours 0 to 7) and &FE28-F

(colours 8 to 15), where a single byte might provide 8 bits per pixel colour

specifications similar to those used on the Archimedes.

The principal limitation here is actually the hardware: the Electron has only

a single output line for each of the red, green and blue channels, and if

those outputs are strictly digital and can only be set to a "high" and "low"

value, then only the existing eight colours are possible. If a modern ULA were

able to output analogue values, it would still need to be assessed whether the

circuitry could successfully handle and propagate such values.

Palette Definition Lists

------------------------

It can be useful to redefine the palette in order to change the colours

available for a particular region of the screen, particularly in modes where

the choice of colours is constrained, and if an increased colour depth were

available, palette redefinition would be useful to give the illusion of more

than 16 colours in MODE 2. Traditionally, palette redefinition has been done

by using interrupt-driven timers, but a more efficient approach would involve

presenting lists of palette definitions to the ULA so that it can change the

palette at a particular display line.

One might define a palette redefinition list in a region of memory and then

communicate its contents to the ULA by writing the address and length of the

list, along with the display line at which the palette is to be changed, to

ULA registers such that the ULA buffers the list and performs the redefinition

at the appropriate time. Throughput/bandwidth considerations might impose

restrictions on the practical length of such a list, however.

Palette-Free Modes

------------------

Palette-free modes might be defined where bit values directly correspond to

the red, green and blue channels, although this would mostly make sense only

for modes with depths greater than the standard 4 bits per pixel, and such

modes would require more memory than MODE 2 if they were to have an acceptable

resolution.

Display Suspend

---------------

Especially when writing to the screen memory, it could be beneficial to be

able to suspend the ULA's access to the memory, instead producing blank values

for all screen pixels until a program is ready to reveal the screen. This is

different from palette blanking since with a blank palette, the ULA is still

reading screen memory and translating its contents into pixel values that end

up being blank.

This function is reminiscent of a capability of the ZX81, albeit necessary on

that hardware to reduce the load on the system CPU which was responsible for

producing the video output.

Hardware Sprites

----------------

An enhanced ULA might provide hardware sprites, but this would be done in an

way that is incompatible with the standard ULA, since no &FE*X locations are

available for allocation. To keep the facility simple, hardware sprites would

have a standard byte width and height.

The specification of sprites could involve the reservation of 16 locations

(for example, &FE20-F) specifying a fixed number of eight sprites, with each

location pair referring to the sprite data. By limiting the ULA to dealing

with a fixed number of sprites, the work required inside the ULA would be

reduced since it would avoid having to deal with arbitrary numbers of sprites.

The principal limitation on providing hardware sprites is that of having to

obtain sprite data, given that the ULA is usually required to retrieve screen

data, and given the lack of memory bandwidth available to retrieve sprite data

(particularly from multiple sprites supposedly at the same position) and

screen data simultaneously. Although the ULA could potentially read sprite

data and screen data in alternate memory accesses in screen modes where the

bandwidth is not already fully utilised, this would result in a degradation of

performance.

Additional Screen Mode Configurations

-------------------------------------

Alternative screen mode configurations could be supported. The ULA has to

produce 640 pixel values across the screen, with pixel doubling or quadrupling

employed to fill the screen width:

  Screen width      Columns     Scaling     Depth       Bytes

  ------------      -------     -------     -----       -----

  640               80          x1          1           80

  320               40          x2          1, 2        40, 80

  160               20          x4          2, 4        40, 80

It must also use at most 80 byte-sized memory accesses to provide the

information for the display. Given that characters must occupy an 8x8 pixel

array, if a configuration featuring anything other than 20, 40 or 80 character

columns is to be supported, compromises must be made such as the introduction

of blank pixels either between characters (such as occurs between rows in MODE

3 and 6) or at the end of a scanline (such as occurs at the end of the frame

in MODE 3 and 6).  Consider the following configuration:

  Screen width      Columns     Scaling     Depth       Bytes       Blank

  ------------      -------     -------     -----       ------      -----

  208               26          x3          1, 2        26, 52      16

Here, if the ULA can triple pixels, a 26 column mode with either 2 or 4

colours could be provided, with 16 blank pixel values (out of a total of 640)

generated either at the start or end (or split between the start and end) of

each scanline.

Character Attributes

--------------------

The BBC Micro MODE 7 employs something resembling character attributes to

support teletext displays, but depends on circuitry providing a character

generator. The ZX Spectrum, on the other hand, provides character attributes

as a means of colouring bitmapped graphics. Although such a feature is very

limiting as the sole means of providing multicolour graphics, in situations

where the choice is between low resolution multicolour graphics or high

resolution monochrome graphics, character attributes provide a potentially

useful compromise.

For each byte read, the ULA must deliver 8 pixel values (out of a total of

640) to the video output, doing so by either emptying its pixel buffer on a

pixel per cycle basis, or by multiplying pixels and thus holding them for more

than one cycle. For example for a screen mode having 640 pixels in width:

  Cycle:    0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15

  Reads:    B                               B

  Pixels:   0   1   2   3   4   5   6   7   0   1   2   3   4   5   6   7

And for a screen mode having 320 pixels in width:

  Cycle:    0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15

  Reads:    B

  Pixels:   0   0   1   1   2   2   3   3   4   4   5   5   6   6   7   7

However, in modes where less than 80 bytes are required to generate the pixel

values, an enhanced ULA might be able to read additional bytes between those

providing the bitmapped graphics data:

  Cycle:    0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15

  Reads:    B                               A

  Pixels:   0   0   1   1   2   2   3   3   4   4   5   5   6   6   7   7

These additional bytes could provide colour information for the bitmapped data

in the following character column (of 8 pixels). Since it would be desirable

to apply attribute data to the first column, the initial 8 cycles might be

configured to not produce pixel values.

For an entire character, attribute data need only be read for the first row of

pixels for a character. The subsequent rows would have attribute information

applied to them, although this would require the attribute data to be stored

in some kind of buffer. Thus, the following access pattern would be observed:

  Cycle:    A B ... _ B ... _ B ... _ B ... _ B ... _ B ... _ B ... _ B ...

A whole byte used for colour information for a whole character would result in

a choice of 256 colours, and this might be somewhat excessive. By only reading

attribute bytes at every other opportunity, a choice of 16 colours could be

applied individually to two characters.

  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

  Reads:    B               A               B               -

  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

Further reductions in attribute data access, offering 4 colours for every

character in a four character block, for example, might also be worth

considering.

Consider the following configurations for screen modes with a colour depth of

1 bit per pixel for bitmap information:

  Screen width  Columns  Scaling  Bytes (B)  Bytes (A)  Colours  Screen start

  ------------  -------  -------  ---------  ---------  -------  ------------

  320           40       x2       40         40         256      &5300

  320           40       x2       40         20         16       &5580 -> &5500

  320           40       x2       40         10         4        &56C0 -> &5600

  208           26       x3       26         26         256      &62C0 -> &6200

  208           26       x3       26         13         16       &6460 -> &6400

MODE 7 Emulation using Character Attributes

-------------------------------------------

If the scheme of applying attributes to character regions were employed to

emulate MODE 7, in conjunction with the MODE 6 display technique, the

following configuration would be required:

  Screen width  Columns  Rows  Bytes (B)  Bytes (A)  Colours  Screen start

  ------------  -------  ----  ---------  ---------  -------  ------------

  320           40       25    40         20         16       &5ECC -> &5E00

  320           40       25    40         10         4        &5FC6 -> &5F00

Although this requires much more memory than MODE 7 (8500 bytes versus MODE

7's 1000 bytes), it does not need much more memory than MODE 6, and it would

at least make a limited 40-column multicolour mode available as a substitute

for MODE 7.

Enhanced Graphics and Mode Layouts

----------------------------------

Screen modes with different screen memory mappings, higher resolutions and

larger colour depths might be possible, but this would in most cases involve

the allocation of more screen memory, and the ULA would probably then be

obliged to page in such memory for the CPU to be able to sensibly access it

all. Merely changing the memory mappings in order to have Archimedes-style

row-oriented screen addresses (instead of character-oriented addresses) could

be done for the existing modes, but this might not be sufficiently beneficial,

especially since accessing regions of the screen would involve incrementing

pointers by amounts that are inconvenient on an 8-bit CPU.

Enhanced Sound

--------------

The standard ULA reserves &FE*6 for sound generation and cassette

input/output, thus making it impossible to support multiple channels within

the given framework. The BBC Micro ULA employs &FE40-&FE4F for sound control,

and an enhanced ULA could adopt this interface.

The BBC Micro uses the SN76489 chip to produce sound, and the entire

functionality of this chip could be emulated for enhanced sound, with a subset

of the functionality exposed via the &FE*6 interface.

See: http://en.wikipedia.org/wiki/Texas_Instruments_SN76489

Waveform Upload

---------------

As with a hardware sprite function, waveforms could be uploaded or referenced

using locations as registers referencing memory regions.

BBC ULA Compatibility

---------------------

Although some new ULA functions could be defined in a way that is also

compatible with the BBC Micro, the BBC ULA is itself incompatible with the

Electron ULA: &FE00-7 is reserved for the video controller in the BBC memory

map, but controls various functions specific to the 6845 video controller;

&FE08-F is reserved for the serial controller. It therefore becomes possible

to disregard compatibility where compatibility is already disregarded for a

particular area of functionality.

&FE20-F maps to video ULA functionality on the BBC Micro which provides

control over the palette (using address &FE21, compared to &FE07-F on the

Electron) and other system-specific functions. Since the location usage is

generally incompatible, this region could be reused for other purposes.

ULA Pin Functions

-----------------

The functions of the ULA pins are described in the Electron Service Manual. Of

interest to video processing are the following:

  CSYNC (low during horizontal or vertical synchronisation periods, high

         otherwise)

  HS (low during horizontal synchronisation periods, high otherwise)

  RED, GREEN, BLUE (pixel colour outputs)

  CLOCK IN (a 16MHz clock input, 4V peak to peak)

  PHI OUT (a 1MHz, 2MHz and stopped clock signal for the CPU)

More general memory access pins:

  RAM0...RAM3 (data lines to/from the RAM)

  RA0...RA7 (address lines for sending both row and column addresses to the RAM)

  RAS (row address strobe setting the row address on a negative edge)

  CAS (column address strobe setting the column address on a negative edge)

  WE (sets write enable with logic 0, read with logic 1)

  ROM (select data access from ROM)

CPU-oriented memory access pins:

  A0...A15 (CPU address lines)

  PD0...PD7 (CPU data lines)

  R/W (indicates CPU write with logic 0, CPU read with logic 1)

Interrupt-related pins:

  NMI (CPU request for uninterrupted 1MHz access to memory)

  IRQ (signal event to CPU)

  POR (power-on reset, resetting the ULA on a positive edge and asserting the

       CPU's RST pin)

  RST (master reset for the CPU signalled on power-up and by the Break key)

Keyboard-related pins:

  KBD0...KBD3 (keyboard inputs)

  CAPS LOCK (control status LED)

Sound-related pins:

  SOUND O/P (sound output using internal oscillator)

Cassette-related pins:

  CAS IN (cassette circuit input, between 0.5V to 2V peak to peak)

  CAS OUT (pseudo-sinusoidal output, 1.8V peak to peak)

  CAS RC (detect high tone)

  CAS MO (motor relay output)

  ÷13 IN (~1200 baud clock input)