The Acorn Electron ULA

======================

Principal Design and Feature Constraints

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

The features of the ULA are limited in sophistication by the amount of time

and resources that can be allocated to each activity supporting the

fundamental features and obligations of the unit. Maintaining a screen display

based on the contents of RAM itself requires the ULA to have exclusive access

to various hardware resources for a significant period of time.

Whilst other elements of the ULA can in principle run in parallel with the

display refresh activity, they cannot also access the RAM at the same time.

Consequently, other features that might use the RAM must accept a reduced

allocation of that resource in comparison to a hypothetical architecture where

concurrent RAM access is possible at all times.

Thus, the principal constraint for many features is bandwidth. The duration of

access to hardware resources is one aspect of this; the rate at which such

resources can be accessed is another. For example, the RAM is not fast enough

to support access more frequently than one byte per 2MHz cycle, and for screen

modes involving 80 bytes of screen data per scanline, there are no free cycles

for anything other than the production of pixel output during the active

scanline periods.

Another constraint is imposed by the method of RAM access provided by the ULA.

The ULA is able to access RAM by fetching 4 bits at a time and thus managing

to transfer 8 bits within a single 2MHz cycle, this being sufficient to

provide display data for the most demanding screen modes. However, this

mechanism's timing requirements are beyond the capabilities of the CPU when

running at 2MHz.

Consequently, the CPU will only ever be able to access RAM via the ULA at

1MHz, even when the ULA is not accessing the RAM. Fortunately, when needing to

refresh the display, the ULA is still able to make use of the idle part of

each 1MHz cycle (or, rather, the idle 2MHz cycle unused by the CPU) to itself

access the RAM at a rate of 1 byte per 1MHz cycle (or 1 byte every other 2MHz

cycle), thus supporting the less demanding screen modes.

Timing

------

According to 15.3.2 in the Advanced User Guide, there are 312 scanlines, 256

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

are spent on each scanline (2000000 cycles / 50 = 40000 cycles; 40000 cycles /

312 ~= 128 cycles). 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.

(In fact, since the ULA is seeking to provide an image for an interlaced

625-line display, there are in fact two "fields" involved, one providing 312

scanlines and one providing 313 scanlines. See below for a description of the

video system.)

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. Since the CPU and ULA

have to take turns in accessing the RAM in MODE 4, 5 and 6, the CPU must

effectively run at 1MHz (since every other 500ns period involves the ULA

accessing RAM) during transfers of screen data.

The CPU is driven by an external clock (IC8) whose 16MHz frequency is divided

by the ULA (IC1) depending on the screen mode in use. Each 16MHz cycle is

approximately 62.5ns. To access the memory, the following patterns

corresponding to 16MHz cycles are required:

     Time (ns):  0-------------- 500------------- ...

   2 MHz cycle:  0               1                ...

  16 MHz cycle:  0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7  ...

                 /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ ...

          ~RAS:  /---\___________/---\___________ ...

          ~CAS:  /-----\___/-\___/-----\___/-\___ ...

Address events:      A B     C       A B     C    ...

   Data events:        ...F  ...S      ...F  ...S ...

           ~WE:        W               W          ...

      ~RAS ops:  1   0           1   0            ...

      ~CAS ops:  1     0   1 0   1     0   1 0    ...

   Address ops:     a.b.    c.      a.b.    c.    ...

      Data ops:  s         f     s         f      ...

       PHI OUT:  ----\_______/------------------- ...

     CPU (RAM):      .....L  ....D                ...

           RnW:      .....R                       ...

       PHI OUT:  ----\_______/-------\_______/--- ...

     CPU (ROM):  D   .....L  ....D   .....L  .... ...

           RnW:      .....R          .....R       ...

~RAS must be high for 100ns, ~CAS must be high for 50ns.

~RAS must be low for 150ns, ~CAS must be low for 90ns.

Data is available 150ns after ~RAS goes low, 90ns after ~CAS goes low.

Here, "A" and "B" respectively indicate the row and first column addresses

being latched into the RAM (on a negative edge for ~RAS and ~CAS

respectively), and "C" indicates the second column address being latched into

the RAM. Presumably, the first and second half-bytes can be read at "F" and

"S" respectively, and the row and column addresses must be made available at

"a" and "b" (and "c") respectively at the latest. The TM4164EC4 datasheet

suggests that the addresses can be made available as the ~RAS and ~CAS levels

are brought low. Data can be read at "f" and "s" for the first and second

half-bytes respectively.

The TM4164EC4-15 has a row address access time of 150ns (maximum) and a column

address access time of 90ns (maximum), which appears to mean that ~RAS must be

held low for at least 150ns and that ~CAS must be held low for at least 90ns

before data becomes available. 150ns is 2.4 cycles (at 16MHz) and 90ns is 1.44

cycles. Thus, "A" to "F" is 2.5 cycles, "B" to "F" is 1.5 cycles, "C" to "S"

is 1.5 cycles.

Note that the Service Manual refers to the negative edge of RAS and CAS, but

the datasheet for the similar TM4164EC4 product shows latching on the negative

edge of ~RAS and ~CAS. It is possible that the Service Manual also intended to

communicate the latter behaviour. In the TM4164EC4 datasheet, it appears that

"page mode" provides the appropriate behaviour for that particular product.

The CPU, when accessing the RAM alone, apparently does not make use of the

vacated "slot" that the ULA would otherwise use (when interleaving accesses in

MODE 4, 5 and 6). It only employs a full 2MHz access frequency to memory when

accessing ROM (and potentially sideways RAM). The principal limitation is the

amount of time needed between issuing an address and receiving an entire byte

from the RAM, which is approximately 7 cycles (at 16MHz): much longer than the

4 cycles that would be required for 2MHz operation.

Write operations expose some uncertainty about the relationship between the

ULA's RAM access schedule and the PHI OUT clock. The Service Manual shows PHI

IN (which should be the ULA's PHI OUT signal) as being synchronised with ~RAS.

Since the CPU makes its address available potentially as late as 140ns after

its PHI2 clock goes low (this clock being broadly similar to PHI OUT), it

would make no sense to expect the ULA to be able perform a memory access

immediately. What seems more likely is that the CPU makes data available, and

this is written during the next 2MHz cycle.

For the CPU, "L" indicates the point at which an address is taken from the CPU

address bus, following a negative edge of PHI OUT, with "D" being the point at

which data may be asserted for writing, following a positive edge of PHI OUT.

Here, PHI OUT is driven at 1MHz. Given that ~WE needs to be driven low for

writing or high for reading, and thus propagates RnW from the CPU, this would

need to be done before data would be retrieved and, according to the TM4164EC4

datasheet, even as late as the column address is presented and ~CAS brought

low.

It must be concluded that where accesses are interleaved between the CPU and

ULA, the CPU access begins concurrently with the ULA access, with the CPU

address and data retained by the ULA, and after the ULA access, the rest of

the CPU transaction occurs in the following 2MHz cycle.

See: Acorn Electron Advanced User Guide

See: Acorn Electron Service Manual

     http://chrisacorns.computinghistory.org.uk/docs/Acorn/Manuals/Acorn_ElectronSM.pdf

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

See: http://stardot.org.uk/forums/viewtopic.php?p=120438#p120438

See: One of the Most Popular 65,536-Bit (64K) Dynamic RAMs The TMS 4164

     http://smithsonianchips.si.edu/augarten/p64.htm

See: https://www.mups.co.uk/project/hardware/acorn_electron/

See: Rockwell R650X and R651X Microprocessors (CPU)

See: http://wilsonminesco.com/6502primer/

A Note on 8-Bit Wide RAM Access

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

It is worth considering the timing when 8 bits of data can be obtained at once

from the RAM chips:

     Time (ns):  0-------------- 500------------- ...

   2 MHz cycle:  0               1                ...

   8 MHz cycle:  0   1   2   3   0   1   2   3    ...

                 /-\_/-\_/-\_/-\_/-\_/-\_/-\_/-\_ ...

          ~RAS:  /---\___________/---\___________ ...

          ~CAS:  /-------\_______/-------\_______ ...

Address events:      A   B           A   B        ...

   Data events:          ...E            ...E     ...

           ~WE:          W               W        ...

      ~RAS ops:  1   0           1   0            ...

      ~CAS ops:  1       0       1       0        ...

   Address ops:     a.  b.          a.  b.        ...

      Data ops:            f     s         f      ...

       PHI OUT:  ----\_______/-------\_______/--- ...

           CPU:  D   .....L  ....D   .....L  .... ...

           RnW:      .....R          .....R        ...

Here, "E" indicates the availability of an entire byte.

Since only one fetch is required per 2MHz cycle, instead of two fetches for

the 4-bit wide RAM arrangement, it seems likely that longer 8MHz cycles could

be used to coordinate the necessary signalling.

Another conceivable simplification from using an 8-bit wide RAM access channel

with a single access within each 2MHz cycle is the possibility of allowing the

CPU to signal directly to the RAM instead of having the ULA perform the access

signalling on the CPU's behalf. Note that it is this more leisurely signalling

that would allow the CPU to conduct accesses at 2MHz: the "compressed"

signalling being beyond the capabilities of the CPU.

Note that 16MHz cycles would still be needed for the pixel clock in MODE 0,

which needs to output eight pixels per 2MHz cycle, producing 640 monochrome

pixels per 80-byte line.

An obvious consideration with regard to 8-bit wide access is whether the ULA

could still conduct the "compressed" signalling for its own RAM accesses:

     Time (ns):  0-------------- 500------------- ...

   2 MHz cycle:  0               1                ...

  16 MHz cycle:  0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7  ...

                 /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ ...

          ~RAS:  /---\___________/---\___________ ...

          ~CAS:  /-----\___/-\___/-----\___/-\___ ...

Address events:      A B     C       A B     C    ...

   Data events:        ...1  ...2      ...1  ...2 ...

           ~WE:        W               W          ...

      ~RAS ops:  1   0           1   0            ...

      ~CAS ops:  1     0   1 0   1     0   1 0    ...

   Address ops:     a.b.    c       a.b.    c     ...

      Data ops:  s         f     s         f      ...

       PHI OUT:  ----\_______/-------\_______/--- ...

           CPU:  D   .....L  ....D   .....L  .... ...

           RnW:      .....R          .....R        ...

Here, "1" and "2" in the data events correspond to whole byte accesses,

effectively upgrading the half-byte "F" and "S" events in the existing ULA

arrangement.

Although the provision of access for the CPU would adhere to the relevant

timing constraints, providing only one byte per 2MHz cycle, the ULA could

obtain two bytes per cycle. This would then free up bandwidth for the CPU in

screen modes where the ULA would normally be dominant (MODE 0 to 3), albeit at

the cost of extra buffering. Such buffering could also be done for modes where

the bandwidth is shared (MODE 4 to 6), consolidating pairs of ULA accesses into

single cycles and freeing up an extra cycle for CPU accesses.

A further consideration is whether the CPU and ULA could access the memory on

interleaved 4MHz cycles, thus replicating the arrangement used by the CPU and

Video ULA on the BBC Micro. One potential obstacle is that the apparent 4MHz

access rate employed by the ULA does not involve the complete process for

accessing the RAM: upon setting up the address and issuing the ~RAS signal,

the ULA is able to make a pair of column accesses on the same "row" of memory,

effectively achieving an average access rate of 4MHz in an 8-bit

configuration.

However, if arbitrary pairs of column accesses were to be attempted, as would

be required by CPU and ULA interleaving, the ~RAS signal would need to be

re-issued with different addresses being set up. This would expand the time to

access a memory location to beyond the period of a 4MHz cycle, making it

impossible to employ interleaved accesses at such a rate.

In conclusion, a strict interleaving strategy is not possible, but by using

pixel data buffering and employing two ULA accesses per 2MHz cycle to obtain

two bytes in that cycle, each adjacent 2MHz cycle can be given to the CPU,

thus achieving an effective throughput during display update periods of 3

bytes for every pair of cycles (2 bytes for the ULA, 1 byte for the CPU), and

thus 1.5 bytes per cycle, giving an illusion of 3MHz access to RAM.

Some other considerations apply to introducing 8-bit wide access. The ULA

employs four pins for data transfer to and from the memory devices (RAM0..3),

and obviously another four pins would be needed in an 8-bit wide scheme.

However, there may have been a physical limitation on the number of pins

permissible on a ULA package or the device's socket. This would necessitate

the reassignment of pins, although few are readily available for such

reassignment.

One approach might involve connecting the RAM devices to the CPU data bus,

with each line connecting to a different RAM chip. The signalling of the RAM

would remain under the control of the ULA, thus preventing the RAM devices

from interfering with other memory transfer operations, with the ROM

signalling also remaining under the ULA's control. One potential disadvantage

of this scheme would involve the elimination of the separate data paths

between the CPU and ROM and between the ULA and RAM.

Another approach might involve reclaiming the keyboard input pins (KBD0..3) as

data pins for ULA access to RAM. This would necessitate the reorganisation of

the keyboard interface, perhaps integrating the keyboard matrix more directly

as a kind of ROM device. A bus transceiver could be used to isolate the

keyboard inputs, with a pin being used to control the transceiver, since the

keyboard data lines are pulled high. In effect, the transceiver would act as a

kind of output enable for the keyboard.

To make the matrix appear within the sideways ROM region of the memory map,

A15 would need to be set to a high value and A14 to a low value. Signals A13

to A0 would then be brought low to select the appropriate column, with the

individual key states being made available via data lines, perhaps D3 to D0.

This mostly retains the existing addressing arrangement and scanning

mechanism. Internally, the ULA would continue to enable access to the keyboard

through the ROM paging mechanism, but instead of integrating separate data

pins into the CPU's data path, it would integrate the keyboard inputs using

the transceiver.

Enhancement: Keyboard Matrix Scanning

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

The keyboard scanning mechanism is presumably designed to be as inexpensive as

possible, being driven by software and avoiding extra logic, but at the

expense of occupying large regions of the memory map when paged in. A more

efficient mapping of the keyboard columns could possibly be done using

decoders such as the 74xx138 part which permits the decoding of three inputs

to select one of eight outputs. Using two of these parts, six address lines

would be dedicated to the keyboard columns as follows:

  A5...A3 select up to eight columns via one decoder

  A2...A0 select up to eight columns via another decoder

In this arrangement, only one of the two ranges of pins would be used at any

given time. If the ULA were to require a certain combination of the remaining

address bits, a region as small as 64 bytes could be dedicated to the

keyboard.

A more efficient arrangement could be used by introducing logic that allows

the decoders to work together to address the keyboard:

  A2...A0 select up to eight columns via both decoders

  A3 would enable one decoder if low and the other decoder if high

With ULA constraints on the remaining address bits, a 16-byte region could be

used to represent the keyboard.

A further refinement might involve combining the existing columns into groups

of eight keys. This would reduce the number of columns to seven, requiring

only three address lines, with all eight data lines being used to read the

matrix.

On the BBC Micro, the system 6522 VIA is used to monitor and read from the

keyboard. The memory locations involved with this chip are located in the

region from &FE40 to &FE7F inclusive, although the memory is allocated in a

way that is appropriate to operate that chip, as opposed to merely exposing

the keyboard matrix.

Enhancement: Hardware Device Selection

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

An alternative to the existing, rather cumbersome, sideways ROM mapping of the

keyboard might involve making it accessible via a hardware-related memory page

like page FE. With ULA addresses confined to FE0x, and with the ULA itself

having to trap accesses to page FE, the page selection signal might be brought

out of the ULA instead of any dedicated signal for the keyboard. Various

address lines corresponding to A7 through A4, or a subset of these, could be

fed into a decoder to permit the selection of other devices, with the keyboard

being one of these.

Meanwhile, a more efficient keyboard mapping using the above matrix

enhancement would permit the different keyboard columns to appear as a group

of sixteen or eight bytes. Thus:

  A15...A8 select page FE

   A7...A4 select a device or peripheral

   A3...A0 select a register or keyboard column

Conceivably, devices such as sound generators could be mapped to device

regions.

CPU Clock Notes

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

"The 6502 receives an external square-wave clock input signal on pin 37, which

is usually labeled PHI0. [...] This clock input is processed within the 6502

to form two clock outputs: PHI1 and PHI2 (pins 3 and 39, respectively). PHI2

is essentially a copy of PHI0; more specifically, PHI2 is PHI0 after it's been

through two inverters and a push-pull amplifier. The same network of

transistors within the 6502 which generates PHI2 is also tied to PHI1, and

generates PHI1 as the inverse of PHI0. The reason why PHI1 and PHI2 are made

available to external devices is so that they know when they can access the

CPU. When PHI1 is high, this means that external devices can read from the

address bus or data bus; when PHI2 is high, this means that external devices

can write to the data bus."

See: http://lateblt.livejournal.com/88105.html

"The 6502 has a synchronous memory bus where the master clock is divided into

two phases (Phase 1 and Phase 2). The address is always generated during Phase

1 and all memory accesses take place during Phase 2."

See: http://www.jmargolin.com/vgens/vgens.htm

Thus, the inverse of PHI OUT provides the "other phase" of the clock. "During

Phase 1" means when PHI0 - really PHI2 - is high and "during Phase 2" means

when PHI1 is high.

Bandwidth Figures

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

Using an observation of 128 2MHz cycles per scanline, 256 active lines and 312

total lines, with 80 cycles occurring in the active periods of display

scanlines, the following bandwidth calculations can be performed:

Total theoretical maximum:

       128 cycles * 312 lines

     = 39936 bytes

MODE 0, 1, 2:

ULA:    80 cycles * 256 lines

     = 20480 bytes

CPU:    48 cycles / 2 * 256 lines

     + 128 cycles / 2 * (312 - 256) lines

     = 9728 bytes

MODE 3:

ULA:    80 cycles * 24 rows * 8 lines

     = 15360 bytes

CPU:    48 cycles / 2 * 24 rows * 8 lines

     + 128 cycles / 2 * (312 - (24 rows * 8 lines))

     = 12288 bytes

MODE 4, 5:

ULA:    40 cycles * 256 lines

     = 10240 bytes

CPU:   (40 cycles + 48 cycles / 2) * 256 lines

     + 128 cycles / 2 * (312 - 256) lines

     = 19968 bytes

MODE 6:

ULA:    40 cycles * 24 rows * 8 lines

     = 7680 bytes

CPU:   (40 cycles + 48 cycles / 2) * 24 rows * 8 lines

     + 128 cycles / 2 * (312 - (24 rows * 8 lines))

     = 19968 bytes

Here, the division of 2 for CPU accesses is performed to indicate that the CPU

only uses every other access opportunity even in uncontended periods. See the

2MHz RAM Access enhancement below for bandwidth calculations that consider

this limitation removed.

A summary of the bandwidth figures is as follows (with extra timing details

described below):

                Standard ULA    % Total   Slowdown  BBC-10s BBC-34s

MODE 0, 1, 2    9728 bytes      24%       4.11      43s     105s

MODE 3          12288 bytes     31%       3.25      34s

MODE 4, 5       19968 bytes     50%       2         20s

MODE 6          19968 bytes     50%       2         20s     50s

The review of the Electron in Practical Computing (October 1983) provides a

concise overview of the RAM access limitations and gives timing comparisons

between modes and BBC Micro performance. In the above, "BBC-10s" is the

measured or stated time given for a program taking 10 seconds on the BBC

Micro, whereas "BBC-34s" is the apparently measured time given for the

"Persian" program taking 34 seconds to complete on the BBC Micro, with a

"quick" mode presumably switching to MODE 6 using the ULA directly in order to

reduce display bandwidth usage while the program draws to the screen.

Evidently, the measured slowdown is slightly lower than the theoretical

slowdown, most likely due to the running time not being entirely dominated by

RAM access performance characteristics.

Video Timing

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

According to 8.7 in the Service Manual, and the PAL Wikipedia page,

approximately 4.7µs is used for the sync pulse, 5.7µs for the "back porch"

(including the "colour burst"), and 1.65µs for the "front porch", totalling

12.05µs and thus leaving 51.95µs for the active video signal for each

scanline. As the Service Manual suggests in the oscilloscope traces, the

display information is transmitted more or less centred within the active

video period since the ULA will only be providing pixel data for 40µs in each

scanline.

Each 62.5ns cycle happens to correspond to 64µs divided by 1024, meaning that

each scanline can be divided into 1024 cycles, although only 640 at most are

actively used to provide pixel data. Pixel data production should only occur

within a certain period on each scanline, approximately 262 cycles after the

start of hsync:

  active video period = 51.95µs

  pixel data period = 40µs

  total silent period = 51.95µs - 40µs = 11.95µs

  silent periods (before and after) = 11.95µs / 2 = 5.975µs

  hsync and back porch period = 4.7µs + 5.7µs = 10.4µs

  time before pixel data period = 10.4µs + 5.975µs = 16.375µs

  pixel data period start cycle = 16.375µs / 62.5ns = 262

By choosing a number divisible by 8, the RAM access mechanism can be

synchronised with the pixel production. Thus, 256 is a more appropriate start

cycle, where the HS (horizontal sync) signal corresponding to the 4µs sync

pulse (or "normal sync" pulse as described by the "PAL TV timing and voltages"

document) occurs at cycle 0.

To summarise:

  HS signal starts at cycle 0 on each horizontal scanline

  HS signal ends approximately 4µs later at cycle 64

  Pixel data starts approximately 12µs later at cycle 256

"Re: Electron Memory Contention" provides measurements that appear consistent

with these calculations.

The "vertical blanking period", meaning the period before picture information

in each field is 25 lines out of 312 (or 313) and thus lasts for 1.6ms. Of

this, 2.5 lines occur before the vsync (field sync) which also lasts for 2.5

lines. Thus, the first visible scanline on the first field of a frame occurs

half way through the 23rd scanline period measured from the start of vsync

(indicated by "V" in the diagrams below):

                                        10                  20    23

  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

    Line from 1:       0                                          22 3

 Line on screen: .:::::VVVVV:::::                                   12233445566

                  |_________________________________________________|

                           25 line vertical blanking period

In the second field of a frame, the first visible scanline coincides with the

24th scanline period measured from the start of line 313 in the frame:

               310                                                 336

  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

  Line from 313:       0                                            23 4

 Line on screen: 88:::::VVVVV::::                                    11223344

               288 |                                                 |

                   |_________________________________________________|

                            25 line vertical blanking period

In order to consider only full lines, we might consider the start of each

frame to occur 23 lines after the start of vsync.

Again, it is likely that pixel data production should only occur on scanlines

within a certain period on each frame. The "625/50" document indicates that

only a certain region is "safe" to use, suggesting a vertically centred region

with approximately 15 blank lines above and below the picture. However, the

"PAL TV timing and voltages" document suggests 28 blank lines above and below

the picture. This would centre the 256 lines within the 312 lines of each

field and thus provide a start of picture approximately 5.5 or 5 lines after

the end of the blanking period or 28 or 27.5 lines after the start of vsync.

To summarise:

  CSYNC signal starts at cycle 0

  CSYNC signal ends approximately 160µs (2.5 lines) later at cycle 2560

  Start of line occurs approximately 1632µs (5.5 lines) later at cycle 28672

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

See: http://en.wikipedia.org/wiki/Analog_television#Structure_of_a_video_signal

See: The 625/50 PAL Video Signal and TV Compatible Graphics Modes

     http://lipas.uwasa.fi/~f76998/video/modes/

See: PAL TV timing and voltages

     http://www.retroleum.co.uk/electronics-articles/pal-tv-timing-and-voltages/

See: Line Standards

     http://www.pembers.freeserve.co.uk/World-TV-Standards/Line-Standards.html

See: Horizontal Blanking Interval of 405-, 525-, 625- and 819-Line Standards

     http://www.pembers.freeserve.co.uk/World-TV-Standards/HBI.pdf

See: Re: Electron Memory Contention

     http://www.stardot.org.uk/forums/viewtopic.php?p=134109#p134109

RAM Integrated Circuits

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

Unicorn Electronics appears to offer 4164 RAM chips (as well as 6502 series

CPUs such as the 6502, 6502A, 6502B and 65C02). These 4164 devices are

available in 100ns (4164-100), 120ns (4164-120) and 150ns (4164-150) variants,

have 16 pins and address 65536 bits through a 1-bit wide channel. Similarly,

ByteDelight.com sell 4164 devices primarily for the ZX Spectrum.

The documentation for the Electron mentions 4164-15 RAM chips for IC4-7, and

the Samsung-produced KM41464 series is apparently equivalent to the Texas

Instruments 4164 chips presumably used in the Electron.

The TM4164EC4 series combines 4 64K x 1b units into a single package and

appears similar to the TM4164EA4 featured on the Electron's circuit diagram

(in the Advanced User Guide but not the Service Manual), and it also has 22

pins providing 3 additional inputs and 3 additional outputs over the 16 pins

of the individual 4164-15 modules, presumably allowing concurrent access to

the packaged memory units.

As far as currently available replacements are concerned, the NTE4164 is a

potential candidate: according to the Vetco Electronics entry, it is

supposedly a replacement for the TMS4164-15 amongst many other parts. Similar

parts include the NTE2164 and the NTE6664, both of which appear to have

largely the same performance and connection characteristics. Meanwhile, the

NTE21256 appears to be a 16-pin replacement with four times the capacity that

maintains the single data input and output pins. Using the NTE21256 as a

replacement for all ICs combined would be difficult because of the single bit

output.

Another device equivalent to the 4164-15 appears to be available under the

code 41662 from Jameco Electronics as the Siemens HYB 4164-2. The Jameco Web

site lists data sheets for other devices on the same page, but these are

different and actually appear to be provided under the 41574 product code (but

are listed under 41464-10) and appear to be replacements for the TM4164EC4:

the Samsung KM41464A-15 and NEC µPD41464 employ 18 pins, eliminating 4 pins by

employing 4 pins for both input and output.

            Pins    I/O pins    Row access  Column access

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

TM4164EC4   22      4 + 4       150ns (15)  90ns (15)

KM41464AP   18      4           150ns (15)  75ns (15)

NTE21256    16      1 + 1       150ns       75ns

HYB 4164-2  16      1 + 1       150ns       100ns

µPD41464    18      4           120ns (12)  60ns (12)

See: TM4164EC4 65,536 by 4-Bit Dynamic RAM Module

     https://www.rocelec.com/part/REITM4164EC4-15L

See: Dynamic RAMS

     http://www.unicornelectronics.com/IC/DYNAMIC.html

See: New old stock 8x 4164 chips

     http://www.bytedelight.com/?product=8x-4164-chips-new-old-stock

See: KM4164B 64K x 1 Bit Dynamic RAM with Page Mode

     http://images.ihscontent.net/vipimages/VipMasterIC/IC/SAMS/SAMSD020/SAMSD020-45.pdf

See: NTE2164 Integrated Circuit 65,536 X 1 Bit Dynamic Random Access Memory

     http://www.vetco.net/catalog/product_info.php?products_id=2806

See: NTE4164 - IC-NMOS 64K DRAM 150NS

     http://www.vetco.net/catalog/product_info.php?products_id=3680

See: NTE21256 - IC-256K DRAM 150NS

     http://www.vetco.net/catalog/product_info.php?products_id=2799

See: NTE21256 262,144-Bit Dynamic Random Access Memory (DRAM)

     http://www.nteinc.com/specs/21000to21999/pdf/nte21256.pdf

See: NTE6664 - IC-MOS 64K DRAM 150NS

     http://www.vetco.net/catalog/product_info.php?products_id=5213

See: NTE6664 Integrated Circuit 64K-Bit Dynamic RAM

     http://www.nteinc.com/specs/6600to6699/pdf/nte6664.pdf

See: 4164-150: MAJOR BRANDS

     http://www.jameco.com/webapp/wcs/stores/servlet/Product_10001_10001_41662_-1

See: HYB 4164-1, HYB 4164-2, HYB 4164-3 65,536-Bit Dynamic Random Access Memory (RAM)

     http://www.jameco.com/Jameco/Products/ProdDS/41662SIEMENS.pdf

See: KM41464A NMOS DRAM 64K x 4 Bit Dynamic RAM with Page Mode

     http://www.jameco.com/Jameco/Products/ProdDS/41662SAM.pdf

See: NEC µ41464 65,536 x 4-Bit Dynamic NMOS RAM

     http://www.jameco.com/Jameco/Products/ProdDS/41662NEC.pdf

See: 41464-10: MAJOR BRANDS

     http://www.jameco.com/webapp/wcs/stores/servlet/Product_10001_10001_41574_-1

Interrupts

----------

The ULA generates IRQs (maskable interrupts) according to certain conditions

and these conditions are controlled by location &FE00:

  * Vertical sync (bottom of displayed screen)

  * 50MHz real time clock

  * Transmit data empty

  * Receive data full

  * High tone detect

The ULA is also used to clear interrupt conditions through location &FE05. Of

particular significance is bit 7, which must be set if an NMI (non-maskable

interrupt) has occurred and has thus suspended ULA access to memory, restoring

the normal function of the ULA.

ROM Paging

----------

Accessing different ROMs involves bits 0 to 3 of &FE05. Some special ROM

mappings exist:

   8    keyboard

   9    keyboard (duplicate)

  10    BASIC ROM

  11    BASIC ROM (duplicate)

Paging in a ROM involves the following procedure:

 1. Assert ROM page enable (bit 3) together with a ROM number n in bits 0 to

    2, corresponding to ROM number 8+n, such that one of ROMs 12 to 15 is

    selected.

 2. Where a ROM numbered from 0 to 7 is to be selected, set bit 3 to zero

    whilst writing the desired ROM number n in bits 0 to 2.

See: http://stardot.org.uk/forums/viewtopic.php?p=136686#p136686

Keyboard Access

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

The keyboard pages appear to be accessed at 1MHz just like the RAM.

See: https://stardot.org.uk/forums/viewtopic.php?p=254155#p254155

Shadow/Expanded Memory

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

The Electron exposes all sixteen address lines and all eight data lines

through the expansion bus. Using such lines, it is possible to provide

additional memory - typically sideways ROM and RAM - on expansion cards and

through cartridges, although the official cartridge specification provides

fewer address lines and only seeks to provide access to memory in 16K units.

Various modifications and upgrades were developed to offer "turbo"

capabilities to the Electron, permitting the CPU to access a separate 8K of

RAM at 2MHz, presumably preventing access to the low 8K of RAM accessible via

the ULA through additional logic. However, an enhanced ULA might support

independent CPU access to memory over the expansion bus by allowing itself to

be discharged from providing access to memory, potentially for a range of

addresses, and for the CPU to communicate with external memory uninterrupted.

Sideways RAM/ROM and Upper Memory Access

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

Although the ULA controls the CPU clock, effectively slowing or stopping the

CPU when the ULA needs to access screen memory, it is apparently able to allow

the CPU to access addresses of &8000 and above - the upper region of memory -

at 2MHz independently of any access to RAM that the ULA might be performing,

only blocking the CPU if it attempts to access addresses of &7FFF and below

during any ULA memory access - the lower region of memory - by stopping or

stalling its clock.

Thus, the ULA remains aware of the level of the A15 line, only inhibiting the

CPU clock if the line goes low, when the CPU is attempting to access the lower

region of memory.

Hardware Scrolling (and Enhancement)

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

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.

See: http://pastraiser.com/computers/acornelectron/acornelectron.html

Enhancement: Mode Layouts

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

Merely changing the screen 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.

However, instead of using a Archimedes-style mapping, column-oriented screen

addresses could be more feasibly employed: incrementing the address would

reference the vertical screen location below the currently-referenced location

(just as occurs within characters using the existing ULA); instead of

returning to the top of the character row and referencing the next horizontal

location after eight bytes, the address would reference the next character row

and continue to reference locations downwards over the height of the screen

until reaching the bottom; at the bottom, the next location would be the next

horizontal location at the top of the screen.

In other words, the memory layout for the screen would resemble the following

(for MODE 2):

  &3000 &3100       ... &7F00

  &3001 &3101

  ...   ...

  &3007

  &3008

  ...

  ...                   ...

  &30FF             ... &7FFF

Since there are 256 pixel rows, each column of locations would be addressable

using the low byte of the address. Meanwhile, the high byte would be

incremented to address different columns. Thus, addressing screen locations

would become a lot more convenient and potentially much more efficient for

certain kinds of graphical output.

One potential complication with this simplified addressing scheme arises with

hardware scrolling. Vertical hardware scrolling by one pixel row (not supported

with the existing ULA) would be achieved by incrementing or decrementing the

screen start address; by one character row, it would involve adding or

subtracting 8. However, the ULA only supports multiples of 64 when changing the

screen start address. Thus, if such a scheme were to be adopted, three

additional bits would need to be supported in the screen start register (see

"Hardware Scrolling (and Enhancement)" for more details). However, horizontal

scrolling would be much improved even under the severe constraints of the

existing ULA: only adjustments of 256 to the screen start address would be

required to produce single-location scrolling of as few as two pixels in MODE 2

(four pixels in MODEs 1 and 5, eight pixels otherwise).

More disruptive is the effect of this alternative layout on software.

Presumably, compatibility with the BBC Micro was the primary goal of the

Electron's hardware design. With the character-oriented screen layout in

place, system software (and application software accessing the screen

directly) would be relying on this layout to run on the Electron with little

or no modification. Although it might have been possible to change the system

software to use this column-oriented layout instead, this would have incurred

a development cost and caused additional work porting things like games to the

Electron. Moreover, a separate branch of the software from that supporting the

BBC Micro and closer derivatives would then have needed maintaining.

The decision to use the character-oriented layout in the BBC Micro may have

been related to the choice of circuitry and to facilitate a convenient

hardware implementation, and by the time the Electron was planned, it was too

late to do anything about this somewhat unfortunate choice.

Pixel Layouts

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

The pixel layouts are as follows:

  Modes         Depth (bpp)     Pixels (from bits)

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

  0, 3, 4, 6    1               7 6 5 4 3 2 1 0

  1, 5          2               73 62 51 40

  2             4               7531 6420

Since the ULA reads a half-byte at a time, one might expect it to attempt to

produce pixels for every half-byte, as opposed to handling entire bytes.

However, the pixel layout is not conducive to producing pixels as soon as a

half-byte has been read for a given full-byte location: in 1bpp modes the

first four pixels can indeed be produced, but in 2bpp and 4bpp modes the pixel

data is spread across the entire byte in different ways.

An alternative arrangement might be as follows:

  Modes         Depth (bpp)     Pixels (from bits)

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

  0, 3, 4, 6    1               7 6 5 4 3 2 1 0

  1, 5          2               76 54 32 10

  2             4               7654 3210

Just as the mode layouts were presumably decided by compatibility with the BBC

Micro, the pixel layouts will have been maintained for similar reasons.

Unfortunately, this layout prevents any optimisation of the ULA for handling

half-byte pixel data generally.

Enhancement: The Missing MODE 4

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

The Electron inherits its screen mode selection from the BBC Micro, where MODE

3 is a text version of MODE 0, and where MODE 6 is a text version of MODE 4.

Neither MODE 3 nor MODE 6 is a genuine character-based text mode like MODE 7,

however, and they are merely implemented by skipping two scanlines in every

ten after the eight required to produce a character line. Thus, such modes

provide a 24-row display.

In principle, nothing prevents this "text mode" effect being applied to other

modes. The 20-column modes are not well-suited to displaying text, which

leaves MODE 1 which, unlike MODEs 3 and 6, can display 4 colours rather than

2. Although the need for a non-monochrome 40-column text mode is addressed by

MODE 7 on the BBC Micro, the Electron lacks such a mode.

If the 4-colour, 24-row variant of MODE 1 were to be provided, logically it

would occupy MODE 4 instead of the current MODE 4:

  Screen mode  Size (kilobytes)  Colours  Rows  Resolution

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

  0            20                2        32    640x256

  1            20                4        32    320x256

  2            20                16       32    160x256

  3            16                2        24    640x256

  4 (new)      16                4        24    320x256

  4 (old)      10                2        32    320x256

  5            10                4        32    160x256

  6            8                 2        24    320x256

Thus, for increasing mode numbers, the size of each mode would be the same or

less than the preceding mode.

Enhancement: Display Mode Property Control

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

It is rather curious that the ULA supports the mode numbers directly in bits 3

to 5 of &FE07 since these would presumably need to be decoded in order to set

the fundamental properties of the display mode. These properties are as

follows:

 * Screen data retrieval rate: number of fetches per pair of 2MHz cycles

 * Pixel colour depth

 * Text mode vertical spacing

From these, the following properties emerge:

  Property                        Influences

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

  Character row size (bytes)      Retrieval rate

  Number of character rows        Text mode setting

  Display size (bytes)            Retrieval rate (character row size)

                                  Text mode setting (number of rows)

  Pixel frequency                 Retrieval rate

  Horizontal resolution (pixels)  Colour depth

One can imagine a register bitfield arrangement as follows:

  Field             Values                  Formula

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

  Pixel depth       00: 1 bit per pixel     log2(depth)

                    01: 2 bits per pixel

                    10: 4 bits per pixel

  Retrieval rate     0: twice               2 - fetches per cycle pair

                     1: once

  Text mode enable   0: disable/off         text mode enabled

                     1: enable/on

This arrangement would require four bits. However, one bit in &FE07 is

seemingly inactive and might possibly be reallocated.

The resulting combination of properties would permit all of the existing modes

plus some additional ones, including the missing MODE 4 mentioned above. With

the bitfields above ordered from the most significant bits to the least

significant bits providing the low-level "mode" values, the following table

can be produced:

  Screen mode  Depth Rate   Text  Size (K)  Colours  Rows  Resolution

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

  0  (0000)    1     twice  off   20        2        32    640x256    (MODE 0)

  1  (0001)    1     twice  on    16        2        24    640x256    (MODE 3)

  2  (0010)    1     once   off   10        2        32    320x256    (MODE 4)

  3  (0011)    1     once   on    8         2        24    320x256    (MODE 6)

  4  (0100)    2     twice  off   20        4        32    320x256    (MODE 1)

  5  (0101)    2     twice  on    16        4        24    320x256

  6  (0110)    2     once   off   10        4        32    160x256    (MODE 5)

  7  (0111)    2     once   on    8         4        24    160x256

  8  (1000)    4     twice  off   20        16       32    160x256    (MODE 2)

  9  (1001)    4     twice  on    16        16       24    160x256

  10 (1010)    4     once   off   10        16       32    80x256

  11 (1011)    4     once   on    8         16       24    80x256

The existing modes would be covered in a way that is incompatible with the

existing numbering, thus requiring a table in software, but additional text

modes would be provided for MODE 1, MODE 5 and MODE 2. An additional two lower

resolution modes would also be conceivable within this scheme, requiring the

stretching of 16MHz pixels by a factor of eight to yield 80 pixels per

scanline. The utility of such modes is questionable and such modes might not

be supported.

Enhancement: 2MHz RAM Access

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

Given that the CPU and ULA both access RAM at 2MHz, but given that the CPU

when not competing with the ULA only accesses RAM every other 2MHz cycle (as

if the ULA still needed to access the RAM), one useful enhancement would be a

mechanism to let the CPU take over the ULA cycles outside the ULA's period of

activity comparable to the way the ULA takes over the CPU cycles in MODE 0 to

3.

Thus, the RAM access cycles would resemble the following in MODE 0 to 3:

  Upon a transition from display cycles: UUUUCCCC (instead of UUUUC_C_)

  On a non-display line:                 CCCCCCCC (instead of C_C_C_C_)

In MODE 4 to 6:

  Upon a transition from display cycles: CUCUCCCC (instead of CUCUC_C_)

  On a non-display line:                 CCCCCCCC (instead of C_C_C_C_)

This would improve CPU bandwidth as follows:

                Standard ULA    Enhanced ULA    % Total Bandwidth   Speedup

MODE 0, 1, 2    9728 bytes      19456 bytes     24% -> 49%          2

MODE 3          12288 bytes     24576 bytes     31% -> 62%          2

MODE 4, 5       19968 bytes     29696 bytes     50% -> 74%          1.5

MODE 6          19968 bytes     32256 bytes     50% -> 81%          1.6

(Here, the uncontended total 2MHz bandwidth for a display period would be

39936 bytes, being 128 cycles per line over 312 lines.)

With such an enhancement, MODE 0 to 3 experience a doubling of CPU bandwidth

because all access opportunities to RAM are doubled. Meanwhile, in the other

modes, some CPU accesses occur alongside ULA accesses and thus cannot be

doubled, but the CPU bandwidth increase is still significant.

Unfortunately, the mechanism for accessing the RAM is too slow to provide data

within the time constraints of 2MHz operation. There is no time remaining in a

2MHz cycle for the CPU to receive and process any retrieved data once the

necessary signalling has been performed.

The only way for the CPU to be able to access the RAM quickly enough would be

to do away with the double 4-bit access mechanism and to have a single 8-bit

channel to the memory. This would require twice as many 1-bit RAM chips or a

different kind of RAM chip, but it would also potentially simplify the ULA.

The section on 8-bit wide RAM access discusses the possibilities around

changing the memory architecture, also describing the possibility of ULA

accesses achieving two bytes per 2MHz cycle due to the doubling of the memory

channel, leaving every other access free for the CPU during the display period

in MODE 0 to 3...

  Standard display period: UUUUUUUU

  Modified display period: UCUCUCUC

...and consolidating accesses in MODE 4 to 6:

  Standard display period: UCUCUCUC

  Modified display period: UCCCUCCC

Together with the enhancements for non-display periods, such an "Enhanced+ ULA"

would perform as follows:

                Standard ULA    Enhanced+ ULA   % Total Bandwidth   Speedup

MODE 0, 1, 2    9728 bytes      29696 bytes     24% -> 74%          3.1

MODE 3          12288 bytes     32256 bytes     31% -> 81%          2.6

MODE 4, 5       19968 bytes     34816 bytes     50% -> 87%          1.7

MODE 6          19968 bytes     36096 bytes     50% -> 90%          1.8

Of course, the principal enhancement would be the wider memory channel, with

more buffering in the ULA being its contribution to this arrangement.

Enhancement: 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.

See the description of the display suspend enhancement for a more efficient

way of blanking lines than merely blanking the palette whilst allowing the CPU

to perform useful work during the blanking period.

To control the blanking or suspending of lines at the top and bottom of the

display, a memory location could be dedicated to the task: the upper 4 bits

could define a blanking region of up to 16 lines at the top of the screen,

whereas the lower 4 bits could define such a region at the bottom of the

screen. If more lines were required, two locations could be employed, allowing

the top and bottom regions to occupy the entire screen.

Enhancement: 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

Screen Mode Selection

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

Bits 3, 4 and 5 of address &FE*7 control the selected screen mode. For a wider

range of modes, the other bits of &FE*7 (related to sound, cassette

input/output and the Caps Lock LED) would need to be reassigned and bit 0

potentially being made available for use.

Enhancement: 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 (or values at well-defined points between the

high and low values, such as the half-on value supported by the Amstrad CPC

series), it would still need to be assessed whether the circuitry could

successfully handle and propagate such values. Various sources indicate that

only "TTL levels" are supported by the RGB output circuit, and since there are

74LS08 AND logic gates involved in the RGB component outputs from the ULA, it

is likely that the ULA is expected to provide only "high" or "low" values.

Short of adding extra outputs from the ULA (either additional red, green and

blue outputs or a combined intensity output), another approach might involve

some kind of modulation where an output value might be encoded in multiple

pulses at a higher frequency than the pixel frequency. However, this would

demand additional circuitry outside the ULA, and component RGB monitors would

probably not be able to take advantage of this feature; only UHF and composite

video devices (the latter with the composite video colour support enabled on

the Electron's circuit board) would potentially benefit.

Flashing Colours

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

According to the Advanced User Guide, "The cursor and flashing colours are

entirely generated in software: This means that all of the logical to physical

colour map must be changed to cause colours to flash." This appears to suggest

that the palette registers must be updated upon the flash counter - read and

written by OSBYTE &C1 (193) - reaching zero and that some way of changing the

colour pairs to be any combination of colours might be possible, instead of

having colour complements as pairs.

It is conceivable that the interrupt code responsible does the simple thing

and merely inverts the current values for any logical colours (LC) for which

the associated physical colour (as supplied as the second parameter to the VDU

19 call) has the top bit of its four bit value set. These top bits are not

recorded in the palette registers but are presumably recorded separately and

used to build bitmaps as follows:

  LC  2 colour  4 colour  16 colour  4-bit value for inversion

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

   0  00010001  00010001  00010001   1, 1, 1

   1  01000100  00100010  00010001   4, 2, 1

   2            01000100  00100010      4, 2

   3            10001000  00100010      8, 2

   4                      00010001         1

   5                      00010001         1

   6                      00100010         2

   7                      00100010         2

   8                      01000100         4