Specifications
Acorn Enhanced Expansion Card Issue 5, August 1994 9
Acorn Enhanced Expansion Card
paged) ROM into main memory, and as such is capable
of updating the page register as required. There may be
more than one loader present, to cater for different
operating systems. All the loader code must be
accessible after reset. After the loader is transferred to
main memory, all further chunks are transferred via the
loader. The chunks are again referenced by the chunk
directory as above, starting at virtual address zero. Note
that after the loader has been loaded, the main
expansion card ID area may be mapped out. An
example of a typical use of the chunk directory is shown
in Figure 4. The shaded areas refer to chunks which are
transferred via the loader.
Since RISC OS uses its built-in loader to access any
ROM on the Risc PC Network Card also, there only
needs be one chunk directory.
Since there is no need for a loader when the ECId and
chunk directory are in EASI space there only needs be
one chunk directory.
Operating system identity byte
The operating system identity byte is the first byte of the
chunk directory entry, and determines the type of data
which appears in the chunk to which the chunk directory
entry refers.
OS[3] = 0 reserved
OS[3] = 1 mandatory at present
OS[2:0] = 0 Acorn Operating System #0 (RISC OS)
D[3:0] = 0 loader
= 1 BBC ROM
= 2-15 OS dependent
= 1 Acorn Operating System #1
D[3:0] = 0 loader
= 1-15 reserved
= 2 Acorn Operating System #2
D[3:0] = 0 loader
= 1-2 reserved
= 3 Helios
= 4-15 reserved
= 3-5reserved
D[3:0] = 0-15 reserved
= 6 manufacturer defined
D[3:0] = 0-15 manufacturer specific
= 7 device data
D[3:0] = 0 link
(for 0, the object
pointed to is another
directory)
= 1 serial number
= 2 date of manufacture
= 3 modification status
= 4 place of
manufacture
= 5 description
= 6 part number
(for 1-6, the data in the
pointed-to location con-
tains the ASCII string of
the information.)
=7 Ethernet ID
=8 Hardware revision
=9 ROM CRC
=10-15 reserved
Examples of use
The previous sections explained the system of
expansion card identification. You do not need to use all
of these features on all expansion cards, and the
implementation depends on the needs and complexity of
the expansion card in question. All expansion cards
must implement at least the simplest form of expansion
card identification. Synchronous cycles are used by the
operating system to read and write any locations within
the ECId space (to simplify the design of synchronous
expansion cards).
Non-extended expansion card identity
This is the simplest possible expansion card identity
mechanism. It may be used for temporary expansion
cards or where expansion cards are used in a localised,
closed environment. It should not be used for expansion
cards for general sale. Non-extended ECIds do not need
PR/W factored into their enable, as the operating system
will only read the ECId space. An example is shown in
Figure 2 below.
Figure 2: Non-extended ECld
Extended expansion card identity
The next simplest case which most expansion cards
should implement as a minimum is the case of an
extended ECId but no code in ROM. This can be
achieved by a 32 x 8 bit PROM. An example is in Figure
3 below.
IRQ
FIQ
BD[0:7]
PS
LA13
0V
ACORN
user selectable ID
OE