home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ARM Club 3
/
TheARMClub_PDCD3.iso
/
hensa
/
documentation
/
documents
/
a252eur3
< prev
next >
Wrap
Text File
|
1999-04-27
|
53KB
|
1,096 lines
|
EEEEEEEE K A |
EE R R EE K AA | The BITS ArcSIG
EE U U RR RR E E K K A A | Newsletter
EEEEEEE U U R EEEE KK AA A |
EE U U R E K K A AA | Issue #03
EEEEEEEE UUUU R EEE K K A A |
| Compiled & linked by Dave
--------------------------------------------------------------------------
STOP PRESS: We're now in circulation on Monochrome, the multi-user "everything"
system at City University; TNX*1.0E6, Pelago!
In its current incarnation, which has been running for over a year now, Mono
has grown into a highly sophisticated messaging and bulletin board system,
covering just about every topic under the sun (and, of course, Suns!). Acorn
machines have their own dedicated section, known as A-Corner, which has a great
deal of technical info available, sections to post questions, and occasionally
some information kindly leaked by Acorn themselves concerning future
developments...
You can find Monochrome at paddington.city.ac.uk, UID mono, password mono.
Editorial
~~~~~~~~
To be quite frank, I really can't believe how EurekA's taken off. This
is only the third issue, and we already have, via Monochrome, an international
circulation...
In addition, as more people have got in touch with me and given me ideas as to
what _really_ goes on inside these machines, we've become more technical.
Thanks here are due to tony Duell, Rob Wheeler & Graham Willmott, all of whom
have helped make EurekA what it is. For two released issues, we're doing OK.
Indeed, this issue is probably the most technical of the three so far; if any
of you have ever wanted to build a podule, I've detailed everything I can dig
up on the subject in this issue. This may have something to do with my latest
plans to interface an Arc to a Transputer array, but then again....:-)
Now we're live on mono, of course, I hope that those of you who run user groups
which support the Arc will get in touch and tell us what _you're_ up to.
Recently, especially from the hardware point of view, I've started to have
problems making sure that my articles are relevant to all Archimedes systems;
for instance, in order to complete the podule article, I had to borrow an A3000
tech ref (thanks, Tom) to get the mini-podule pinouts. Needless to say, I was
shocked to see the absence of a +12V and -5V line... what are Acorn playing at?
It worries me to think that this acceptance of differing standards for
expansion cards may eventually result in Arc hardware compatibility becoming as
big a farce as PC hardware compatibility. Please, Acorn, don't let this be the
start of a trend....
Dave Walker, ArcSIG Leader (phdw@siva.bris.ac.uk Monochrome ID gabriel)
PS. Just noticed, while reading the ARM data book... the designers at
Acorn/VLSI have a very dry sense of humour. The base series number for the ARM
chipset is 86000... reverse the first two digits, and won't Motorola be pleased!
*OBEY !RUN
~~~~~~~~~
SWI "OS_GenerateError"
----------------------
Many thanks for the feedback on last issue's Assembler
Programmer's Pocket Guide; in addition to several typos, I managed to get one
important fact wrong and forget to document two very obvious and very useful
mnemonics. Thanks to Graham Willmott and KJB1003 (Kevin Bracey) for spotting
this lot.
First of all, the errors. In the documentation of the floating point system,
R0-R7 should be F0-F7. In the memory map, I forgot to document the fact that
the RAM filing system maps in at &1000000. Also, in the Floating point
again, the suffix refers to conditional execution, whereas the precision
is chosen from:
----------------------------------------------------------------------------
IEEE Single Precision (S)
IEEE Double Precision (D)
Double Extended (E)
Precision
BCD Packed Decimal (P)
The rounding mode is then chosen from:
Round to nearest (no mnemonic)
Round to + infinity (P)
Round to - infinity (M)
Round to Zero (Z)
------------------------------------------------------------------------------
Apologies to all concerned if my nomenclature was insufficiently clear.
Second, the mnemonics. I somehow missed documenting the LDR and STR
instructions; don't ask me how, I guess I must have been rowing. Here they
are, described in Pocket Ref. format. However, as this gives me the chance to
cover the various addressing modes available, I think they can go in a separate
section and you can cross-reference to it within the opcode mnemonic list.
------------------------------------------------------------------------------
Addressing Modes in ARM Assembler
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
As R15 has a 26-bit wide address field, it is
obviously not possible to fit an absolute address description into a 32 bit
instruction which also has to contain the opcode, conditional(s) and operand
registers. Hence, when specifying absolute addresses in ARM code, it is
necessary to use indirection.
The basic operands to load and store single-word registers are LDR and STR. LDR
will be used in the examples illustrating addressing modes.
Pre-Indexed Addressing
----------------------
Syntax: LDR <suffix><destination>, [<base>{,<offset>}]
<base> is a simple register.
<offset> is an optional quantity such that the memory word loaded
into <destination> is the contents of address (base+offset).
<offset> may be a simple register, a shifted register or an immediate
constant in the range -4095 to +4095.
Write-back is also implemented, so the instruction
LDR R0,[R3,R8,LSL#2] has the effect Load R0 with the contents of (R3+4*R8) and
set R3=R3+4*R8.
Post-Indexed Addressing
-----------------------
Syntax: LDR <suffix><destination> [<base>],<offset>
The contents of <base> are taken as the address to load <destination> from,
and then the contents of <offset> are added to it. Write-back is implicit.
Hence:
LDR R8,[R2],R5,LSL#4 ; Load R8 from address R2: R2=R2+16*R5.
------------------------------------------------------------------------------
In addition, although I have seen no information as to changes in the segment
of proprietary Acorn code included to re-sync the registers, an official
statement has been made that the conditional extender NV is not to be used in
future software, as Acorn plan to reassign the current NV bit pattern to
another instruction. However, MOV R0,R0 should provide an equally effective
no-op.
APPEND
------
KJB1003, a student at Cambridge (this newsletter is spreading!), also
suggested that I add documentation about the OPT assembly directive. Here goes;
update your copies of the Pocket Reference, everyone, as I expect the CC would
be unamused if I crunch as much net.bandwidth as last time...
------------------------------------------------------------------------------
This bit can be included under:
Register Assignment, Parameter Passing and Assembler Directives.
OPT <var> is a pseudo-opcode which directs the assembler to perform specific
functions, and when used, is always the first operator after the [.
When OPT is not explicitly specified, the default value is set to 3.
<var> is an integer, or variable containing an integer, which has
bits flagged to produce the following effects:
Bit 0 clear = No listing produced
set = Listing produced
Bit 1 clear = No errors reported
set = Errors reported
Bit 2 clear = No offset assembly
set = Offset assembly performed
Bit 3 clear = No range check performed
set = Range check performed (via L%)
The "no errors" bit is necessary for the first pass of a multi-pass assembly
(ie where forward-referenced labels have been used).
------------------------------------------------------------------------------
Digging through the PRMs, I also found the mnemonic to opcode conversion tables
for the floating point system. However, the latest news from our erstwhile BITS
Librarian (Rob Wheeler) is that he has some PD software available which allows
the FP system to be used in assembler. If you'd like a copy, contact him direct
as se1043@seqa.bris.ac.uk.
------------------------------------------------------------------------------
Unary Operations
----------------
Command format <unaryop><suffix><precision>{rounding mode} <Fdest>,(<Fop> #val)
Mnemonic Effect Calculation Opcode
-------- ------ ----------- ------
MVF Move Fdest=Fop 00001
MNF Move negated Fdest=-Fop 00011
ABS Absolute value Fdest=ABS(Fop) 00101
RND Round to integer Fdest=INT(Fop) 00111
SQT Square root Fdest=SQR(Fop) 01001
LOG Log to base #10d Fdest=LOG(Fop) 01011
LGN Natural log Fdest=LN(Fop) 01101
EXP Exponent Fdest=EXP(Fop) 01111
SIN Obvious Fdest=SIN(Fop) 10001
COS Equally obvious Fdest=COS(Fop) 10011
TAN Ditto Fdest=TAN(Fop) 10101
ASN ] Fdest=ASN(Fop) 10111
ACS ] (Obvious)^-1 Fdest=ACS(Fop) 11001
ATN ] Fdest=ATN(Fop) 11011
Binary Operations
-----------------
Command format:
<binaryop><suffix><precision>{rounding mode} <Fdest>,<Fop1>,(<Fop2> #value)
Mnemonic Effect Calculation Opcode
-------- ------ ----------- ------
ADF Add Fdest=Fop1+Fop2 00000
MUF Multiply Fdest=Fop1*Fop2 00010
SUB subtract Fdest=Fop1-Fop2 00100
RSF Reverse subtract Fdest=Fop2-Fop1 00110
DVF Divide Fdest=Fop1/Fop2 01000
RDF Reverse divide Fdest=Fop2/Fop1 01010
POW Raise to power Fdest=Fop1^Fop2 01100
RPW Reverse raise... Fdest=Fop2^Fop1 01110
RMF Remainder Fdest=Fop1 MOD Fop2 10000
FML Fast multiply Fdest=Fop1*Fop2 10010
FDV Fast divide Fdest=Fop1/Fop2 10100
FRD Fast reverse divide Fdest=Fop2/Fop1 10110
POL Polar angle Fdest=angle between 11000
Fop1 and Fop2
Note that the "fast" instructions only produce single-figure accuracy,
regardless of the precision specified in the mnemonic.
Also, more useful entry points, to be appended to your Pocket Programmer's
Reference (perhaps I should do a Mk. II memory map sometime, with all these
locations listed) for those of you who wish to access the I/O devices in your
Arcs directly.
Cycle Type Base Address Device Device IC
---------- ------------ ------ ---------
Fast &3310000 Floppy disc controller WD1772
Sync &33A0000 Econet controller 6854
Sync &33B0000 Serial controller 6551
Fast &3350000 Printer data LS374
As you'll see later, I'm doing some work on podules this issue. Here's some
useful podule entry points to know... however, including all of these in your
Pocket Reference means you'll either have bad eyesight shortly from reading the
small print, or you already have a very large pocket.
Fast &3360000 Podule IRQ register
Fast &3360004 Podule IRQ mask
register
Slow &3270000 Extended external
podule space
Slow &3240000 Podule 0
Med &32C0000 Podule 0
Fast &3340000 Podule 0
Sync &33C0000 Podule 0
Slow &3244000 Podule 1
Med &32C4000 Podule 1
Fast &3344000 Podule 1
Sync &33C4000 Podule 1
Slow &3248000 Podule 2
Med &32C8000 Podule 2
Fast &3348000 Podule 2
Sync &33C8000 Podule 2
Slow &324C000 Podule 3
Med &32CC000 Podule 3
Fast &334C000 Podule 3
Sync &33CC000 Podule 3
Although these are the current lookup addresses, Acorn make no guarantees that
they will stay here in future incarnations of the OS. Writing to and reading
from these addresses is currently the fastest way to interact with a podule,
but for future compatibility, it's safer to use the SWIs detailed later this
issue. Alternatively, build your own lookup table using SWI
"Podule_HardwareAddress", or (from what I've heard about it) take a look at
!StrongHlp.
Please keep me posted with any errors you find in the Pocket Programmer's
Reference, along with your wishlists of features to be covered in future.
Marginal Hacks (Part 11 of 1<<31)
--------------
Differences between the A3010 and A3020: tony Duell
---------------------------------------
These 2 machines, based on the ARM250 (integrated ARM CPU, MEMC, IOC, VIDC -
all on one chip) are very similar. In fact the main differences are
A3010 (designed as a home computer)
Joystick port, RF modulator, No hard disk, No network, Green function keys,
Silly label on the back (No, not a DEC 'Silly Sticker' :-))
A3020 (designed as a replacement for the BBC micro in education)
Network option, IDE hard disk internally, Red function keys.
Well, they are actually built on the same PCB, and you can in principle add
options to either machine that are only present in the other one. One thing
that is worth knowing (all reviews so far have said that it is impossible), is
that the A3010's disk controller is capable of controlling an IDE hard disk -
it's just that the socket is not fitted. It is possible to add it, and thus
save your single mini-podule slot for something else.
If you want to try this, you should obtain the technical reference manual
from Acorn (I don't have it), as there _may_ be decoupling capacitors and
similar to add as well.
Identifying monitor type on an A540; where to look
--------------------------------------------------
The 540 is unique among
old-style (pre-A5000) Arcs in that it can accept a very wide range of monitors,
and has a VIDC Accelerator built in. For those of you who didn't know or hadn't
worked it out, VIDC will clock at several speeds, dependent on the monitor type
configured. The video sync polarity and VIDC clock speed are stored in a
write-only register at &3350048, with the bit patterns
Clock Speed Bit 1 Bit 0 Sync Polarity Bit 3 Bit 2
----------- ----- ----- ------------- ----- -----
V H
24 MHz 0 0 + + 0 0
25.175 MHz 0 1 + - 0 1
36 MHz 1 0 - + 1 0
Reserved 1 1 - - 1 1
OK, so this is a write-only register... maybe we'll just have to convince MEMC
otherwise!
Sound Improvements
------------------
On implementing the Arc sound system, Acorn added a number of
low-pass filters before the headphone output; whether they didn't envisage
people connecting this output to anything other than a pair if headphones I
don't know, but it sounds pretty awful through my hi-fi. Needless to say, this
is no fault of my hi-fi!
Fortunately, these filters can be bypassed by rewiring a socket on the
motherboard. PLEASE NOTE: After this modification, the headphone socket signal
will have insufficient power to drive a pair of headphones. It may, however, be
fed into a stereo amplifier.
Find LK9. (Likely to be a different designation on a 300/400/5000/30n0 machine;
there is _NO_ equivalent socket on an A3000; the job would require taking
wiretaps direct off ICs. Mail me if you want to know which ones...) It's a 10
pin in-line, and should be close to the headphone socket at the rear of the
machine. In release configuration, the left headphone channel comes off pin 3,
and the right channel comes off pin 7. The 'raw' (unfiltered) left and right
channels come from pins 1 and 9 respectively; 2,4,6,8 and 10 are ground, and 5
is an auxiliary input.
There is a possibility that this will cause the headphone amplification stages
to go into oscillation; although this will do no harm to the computer, it could
well ruin the sound quality (but not your hi-fi...).
However, I haven't heard of this happening yet...
1 2 3 Testing...
----------------
On the A540 (I don't know whether it's in the 400 or 5000
series; it certainly isn't in the 300 or 3000 series, and I wouldn't expect it
to be in the 30n0 series) Acorn included a socket for their own test hardware.
This socket, LK4, has the pinout
P1 +5V
P2 D<0> (Lowest bit of Data bus)
P3 La<21> (Bit 21 of Logical Address bus.... should go high when accessing
the high ROM area)
P4 RomCS (ROM Select)
P5 Rst (System Reset)
P6 0V
Graham tells me (I haven't looked here yet) that RISC OS 3.10 and 3.00 have an
extensive self-test routine branched to at the start of ROM space (&3800000),
which puts all sorts of bits on the bus, checks the integrity of ROM and RAM,
and finds out how much RAM your machine has and which ARM is present.
If anyone can find a use for this, let me know!
Features
~~~~~~~
A Chip off the Old !block: ARM3 and ARM610 compared; ARM7 rumours
-------------------------
Recently (OK, not _too_ recently!) the ARM family was
joined by a new member; the 610. This processor has received a great deal of
speculative press, having been selected as the processor for Apple's Newton
Palmtop machine. Also, Acorn forums on the net have been rife with rumours of
yet another, incredibly high-end pair of ARMs, so far designated (for want of a
better name) ARM 7 and ARM 8.
To add a little light relief to this issue of EurekA, I thought I'd distil what
I've heard, and compare it to our friend the ARM 3; not only does this make a
change from reading about my perennial wars with the PCM, but I haven't much
choice; I deleted my emulator last week. Not from disgust at MS DOS, I hasten
to add (although it was more than a passing contributor to the reasons why it
didn't get reinstated!) but because of the dreaded "disc full" message. From my
internal 120Mb hard drive (the 100Mb external hard drive being reserved for
UNIX). One vaped PC partition and some rearranging later, I'm now happy with
45Mb free on it, and the partition ain't coming back. :-)
Anyhow, to work.
The ARM 610 is the first implementation of the ARM 6 macrocell, released
jointly with the ARM 60 (an unaugmented ARM 600 package, pin-compatible with
the ARM 2). I don't think an ARM 600 was ever released, although it was
designed. Not surprisingly, it was designed to look like an ARM 3.
The ARM 6 cell is built out of fully static CMOS, which means that the clock
signal to it can be turned off without losing information on the chip's state
or the data contained therein. As the macro is based on micron-scale data
paths, the final cell is sufficiently small to be included wholesale on a
custom wafer of standard size, (2.8 mm^2) with physical room to spare for cache,
controllers etc. Indeed, the cell is already in use as an embedded controller
in some of the latest laser printers.
At most levels, the 610 is instruction-compatible with the ARM 3. However, the
address space has been expanded to the full 32 bits possible (the processor
flags & status mode bits have been moved to a new register, making 17 registers
visible), and an extra pair of data lines (PROG32 and DATA32) which switch
between full 32 bit instruction and data paths, and the 26 bit versions for ARM
1,2 & 3 compatibility. (Does anyone out there have an old ARM 1 evaluation
system? If so, please let me know!) Also note that BYTE (second-sourcing the
relevant bits of a December 1991 article, here) seem to have it wrong again...
the data path (even the coprocessor data path) is the full 32 bits wide! My
print set says so!
In addition, there is a status line to switch the processor addressing mode
between big and little-endian. This makes the ARM 610 compatible with EVERYBODY
else!
Virtual memory drivers have been implemented in hardware; instead of the old
address exception error, the system now calls the drive controller via a
software service routine to load the missing page into RAM, and the specific
instruction into cache. These exceptions may be handled in both supervisor and
user mode.
Recalling the Pre-Fetch and Data-Abort vectors in Archimedes zero page (see
EurekA #2), it's interesting to see that on the 610, there are moves towards
delaying the last possible abort until even later in the cycle. This would
result in far less strain on the cache, but require extra garbage collection.
The feature is not implemented on the ARM 6; expect it on the ARM 8. However, a
LATEABT signal has been added, which when high, will simulate this extra
feature.
Pages, and indeed page size (4-64K, variable) is controlled by the on-chip
MMU. Virtual and real page numbers are stored in a cached translation lookaside
buffer (TLB), which also stores memory protection level data. When accessing a
page, the processor checks to see if the TLB contains a translation from the
virtual address to a real address in RAM; if so, the physical address is
output.
However, the interface to this (fairly conventional) memory model is based on
an object-oriented user view of memory. If the page is not in RAM, the MMU
allocates an index into the translation table, ofset by an address held in the
translation table base register.
If the table entry is for a section (number of pages), the index will contain
the section's base address, which may be combined with a virtual-address index
to give a physical address to load the data at.
If the entry is for a single page, the index contains a pointer to the page
table, where the address can be found.
One of the nicest tricks used in the new ARM is that lists of pointers are
terminated by dummy instructions not on word boundaries. As the MMU traps
accesses to all such words, the end of a list may be detected by intercepting
the error raised by the MMU.
Access permissions are mapped separately from the virtual addresses, and
can be manipulated in isolation. Page faults and permission faults are also
handled by independent hardware. Access permissions are held in a 'domain
space,' which is a contiguous arbitrary-sized block of pages. The chip supports
up to 16 of these domains, each of which may be assigned an access level by the
task managing it. Tasks are divided into clients, which may be denied access to
a domain if the relevant access bits are set, and managers, which can always
grab a domain directly. Each task may (and usually will) use multiple domains.
The trouble with this kind of management is that it generates huge amount of
garbage, as tasks claim and release domains. It is predicted that the ARM 610
will support (not had the specs on this) a garbage collection program, running
concurrently with whatever other task are present, which will release areas of
memory which were claimed by a task since terminated by changing the
permissions; I'm still not sure that this wouldn't leave some tasks stranded,
though. Further info on this would be appreciated.
Rumours of the ARMs 7 and 8 exist, and it is believed that a prototype ARM 8
(probably built from ECL) has been run on Acorn's testbeds. Both ICs are said
to be fully parallel-capable, and rumour has it that the ARM 8 is capable of
asynchronous processing (although the current Arcs canbe considered asynch, as
each of the four main ICs runs at a different speed; I'd be interested to know
how an ARM 250 clocks the various parts of its mega-wafer). If this is so, an
Archimedes n (where n is large!) would basically put mainframe processing power
squarely on the desk. Thank you, Intel, and goodnight.
A CALL to ARMs
--------------
In my humble opinion, it's about time that BITS produced
something useful, other than the occasional Newsletter. The HP SIG already has
a serial to IR converter, so I thought some Archimedes hardware projects
wouldn't go amiss, especially as the podule interface seems easy enough to
design for. In order to cater for control of the final boards, I'm documenting
the podule control SWIs later in this issue.
Ideas so far: Archimedes to Transputer card; offload some of the processing
time from your ARM to a (or more than one!) T800(s).
I'm looking into this at the moment; hence the podule stuff in
this issue!
For those of you on Monochrome (you know who you are...) who have
a spare ARM and RISC OS 2 ROM set, here's an idea. The ARM was
first sprung on the world in the form of the ARM 1 evaluation
system, which ran as a second processor on an Acorn Proton. This
means that, at a pinch, an ARM Tube is possible, although it may
be less than 32 bits wide. If it can be coaxed into giving us 16
bits, how about building an ARM second processor and going for
true multiprocessing? I'd be most impressed if anyone out there
has the ARM 1 system schematic...
I/O Podule; catch up with those interfaces on the 8 bit machines.
If anyone out there reads Elektor, check out the July / August
1991 issue; John Kortink (of !Translator, !Creator and !AIM fame)
supplies the circiut diagrams and PCB masks for a cheap black and
white video digitiser, which includes an I2C interface...
Econet upgrade; to be ported from the BBC Master document set.
See if it will run on an existing network.
FPA: Acorn haven't released it, & I don't know why. However, we
have the FPE, which is a full software model of the FPA, and the
pinout of the FPA socket. If the worst comes to the worst, is
anyone prepared to try out a pin-remapped ARM 2 and assorted
interfacing chippery running the FPE (from an old RISC OS 2 ROM
set) in the FPA socket?
System clock modification; I heard from Rob Wheeler, who was at
the BAU show, that Aleph One had a 540 which they had reclocked
using a voltage controlled oscillator, just to see how fast it
would go. Rob believes it ran stably at 50MHz, which should put
the machine (assuming basic 13.5 MIPS out of a 27 MHz ARM 3) up
to about 20 MIPS, without an FPA. If you have any ideas
concerning motherboard mods to do this (ie loading the RISC OS
ROMs into fast RAM on system reset so they don't have to keep
up, and indeed if 70ns on the RAM is fast enough), or if you saw
more than Rob did, please let me know.
For your information, a feasible Transputer interface has already been built on
a podule, and is going into testing, now that my old 310 is down at the lab.
I'll have a T425 (wish I could afford a T800...) or several hung off the back
of my 540 yet!
Down to the Metal: Of Acorn, Inmos and non-von Neumann machines....
-----------------
As those of you who've talked to me recently will know, I've
gone just about sufficiently mad to decide that interfacing my Arc(s) to a
Transputer system would not only be a serious hack and a major factor in
speeding my machines up (I have had my 540 overloaded before now...), but that
it shouldn't be too difficult a job. Also (this shows I've lost any remaining
sanity!) I think OCCAM is cute.
Anyhow. After a long, hard look at the Transputer Data Book, it appears that
the IC for the interfacing job is the IMS CO11.
Basically, transputers are very simple entities to treat as black boxes. They
clock universally off a 5MHz signal, which does not have to be in synch on all
the chips (no worries about board size here!), and communicate with eachother
via a pair of unidirectional serial links. The external clock is stepped up
inside the chip using a phase-locked loop system, which is regulated by an
external high-quality capacitor. However (implementers beware) they're very
tricky to start up; like all CMOS devices, they have to be soft-started,
otherwise they'll hang and eventually blow.
The CO11 is designed with two purposes in mind; in operating mode 1 it can be
used as a peripheral interface on a transputer array, and in mode 2 it can act
as an interface between the transputer serial system and an 8-bit
microcomputer bus. Needless to say, I'll be configuring it in mode 2. Although
the CO11 is only capable of handling 8 bit data, it's enough to handle the
transputer instruction set; a more ambitious project could be to run a pair of
CO11s off the podule bus, interfaced to two separate transputer networks...
However, even I'm not that mad yet!
-----------
Linkout 1 [| U |] 28 VCC
Linkin 2 [| |] 27 CapMinus
RnotW 3 [| |] 26 InputInt
Outputint 4 [| |] 25 notCS
RS0 5 [| |] 24 D0
RS1 6 [| |] 23 D1
DoNotWire 7 [| IMS |] 22 D2
D3 8 [| CO11 |] 21 DoNotWire
DoNotWire 9 [| |] 20 D4
D5 10 [| |] 19 DoNotWire
HoldToGND 11 [| |] 18 D6
D7 12 [| |] 17 LinkSpeed
Reset 13 [| |] 16 SeparateIQ
GND 14 [| |] 15 ClockIn
-----------
Pin Name Data Direction Function
-------- -------------- --------
D0-D7 in/out Bidirectional microprocessor data bus
notCS in Chip select
RS0-RS1 in Register select
RnotW in Read/Write control signal
InputInt out Interrupt; link receive buffer full
OutputInt out Interrupt; link transmit buffer empty
LinkSpeed in Set link speed as 10 or 20 Mbits/sec
HoldToGND Must be connected to 0V
DoNotWire Must be left disconnected.
VCC, GND Power supply (+5V) and return
CapMinus External capacitor for clock
ClockIn in Input clock
Reset in System reset
SeparateIQ in Chip mode select
LinkIn in Transputer bus input channel
LinkOut out Transputer bus output channel
As with most ICs these days, VCC must be decoupled to GND via at least one
100nF low inductance (eg ceramic) capacitor.
The capacitor to control the internal clock should be connected between VCC
and CapMinus, with the negative terminal to CapMinus if the capacitor is of the
polarised type. The capacitor should be of value 1uF, preferably ceramic, and
with impedance less than 3 Ohm between 100 kHz and 10 MHz.
The clock signal for the system, input at ClockIn, must be derived from a
crystal, as R-C oscillators aren't stable enough for this job. A decent 10 MHz
crystal, fed through a divide-by-two, should suffice. Mark/space ratio is
unimportant. Although I have the data, I'm not bothering to put the info in
about rise & fall times, etc.... if you want them, email me.
To configure the IC for mode 2, SeparateIQ should be connected to GND.
Standard Transputer bus speed is 10 Mbits/sec, selected by pulling LinkSpeed
low. The CO11 may also communicate at 20 Mbits/sec, and this is affected by
holding LinkSpeed high.
Communicating with the CO11
---------------------------
The microprocessor bus D0-D7 is bidirectional, and
is high impedance unless the CO11 is selected (see below) and RnotW is high.
D0 is the least significant bit.
RnotW is the read/write select. RnotW high = read from CO11
RnotW low = write to CO11
RnotW is latched by notCS going low; if timing allows, it is possible to alter
RnotW before notCS going high.
notCS is used to select the IC for reading/writing by the microprocessor.
Register selectors RS0 and RS1 must be valid before the chip is selected, as
must D0-7 if a microprocessor write operation is specified by RnotW.
The chip is selected by pulling notCS low, and data is read by the chip on the
rising edge of the notCS signal. However, I'm not planning to do this...
The bit pattern on RS0 and RS1 determine which of the four registers in the
CO11 is to be accessed by the microprocessor. A register is addressed by
setting up RS0 and RS1, then taking notCS low. The state of RnotW determines
whether the register is to be read from or written to.
RS0 RS1 RnotW Register
--- --- ----- --------
0 0 1 Read data
0 0 0 Invalid
0 0 1 Invalid
0 1 0 Write data
1 0 1 Read input status
1 0 0 Write input status
1 1 1 Read output status
1 1 0 Write output status
Input Data Register:
Holds the last data packet received from the serial link.
The data is valid only when the "data present" flag is set in the input status
register.Reading the data herein is destructive (ie cannot read the same data
twice). Writing to this register has no effect.
Input Status Register:
bit 0 = data present flag
bit 1 = interrupt enable flag for InputInt line.
When writing to this register, bits 2-7 must be set to 0.
Output Data Register:
Data written to this register is transmitted out of the
serial link as a transputer data packet. Data should only be written when the
"output ready" bit of the output status register is high. This register should
not be read from; the resulting data is undefined.
Output Status Register:
bit 0 = output ready flag
bit 1 = interrupt enable
When writing to this register, bits 2-7 must be set to 0.
The InputInt output is set high to indicate that a transputer packet has been
received. It is inhibited from going high when the interrupt enable bit has
been set low, which occurs on a Reset, and when data is read from the input
data register.
The OutputInt output is set high to insicate that the CO11 is ready to receive
data for packeting and transmission. It is inhibited from going high when the
interrupt enable bit is set, and is reset low when the CO11 is Reset or data is
written to the data output register.
Well, that's it for this instalment. While writing it, it's amazing how much
comms handling code you think up to handle the signals...
Anyway, in conjunction with the Podule Interface article below, I hope that I
can get this unit fitted on a podule, and exchanging pleasantries with a T425.
More next issue....
Down to the Metal: Another Article! This time, Podule Interfacing
-----------------
The Hardware
~~~~~~~~~~~
Before you start working on devices to plug into the back of
your precious Arc(s), you'll need to know the pinout and signal levels of the
podule interface. As these aren't documented in the User Guide or the PRM set,
I guess I'd better produce them here.
An application note, "A Series Podules," which contains a more complete
specification of the podule interface, is available on request from Acorn.
This note should also cover the A3000/A30n0 (where n>=1) mini-podule.
First of all, the power available per podule can be worked out from the
backplane ratings:
+5V 1A maximum
+12V 250mA maximum
-5V 50mA maximum
Once you've worked out your power requirements, you'll need the pinout.
The Podule socket is a 64-way DIN 41612; the a side is to the bottom of the
podule, the b (centre) line is unused, and the c side is the top.
Pin Number a side c side Description
---------- ------ ------ -----------
1 0V 0V Ground
2 LA[15] -5V
3 LA[14] 0V Ground
4 LA[13] 0V Ground
5 LA[12] Reserved
6 LA[11] MS[0] MEMC Podule select
7 LA[10] Reserved
8 LA[9] Reserved
9 LA[8] Reserved
10 LA[7] Reserved
11 LA[6] Reserved
12 LA[5] RST Reset
13 LA[4] PR/W Read/not write
14 LA[3] PWE Write strobe
15 LA[2] PRE Read strobe
16 BD[15] PIRQ Normal interrupt
17 BD[14] PFIQ Fast interrupt
18 BD[13] S[6]
19 BD[12] C1 IIC serial bus clock (SCL)
20 BD[11] C0 IIC serial data (SDA)
21 BD[10] S[7] External podule select
22 BD[9] PS[0] Simple podule select
23 BD[8] IOGT MEMC podule handshake
24 BD[7] IORQ MEMC podule request
25 BD[6] BL I/O data latch control
26 BD[5] 0V Supply
27 BD[4] CLK2 2MHz synchronous clock
28 BD[3] CLK8 8MHz synchronous clock
29 BD[2] REF8M 8MHz reference clock
30 BD[1] +5V Supply
31 BD[0] Reserved
32 +5V +12V
LA[0] and LA[1] are not routed.
Note that RST is the system reset signal, which is driven by IOC on power-up
or by the system reset switch. The signal is open-collector, and may be driven
by podules. Pulse width on this line to affect a reset should be at least 50ms.
The podule data bus BD[0:15] connects to the main system bus D[0:31] via a set
of bidirectional latches, and is mapped such that during a write (ARM to
podule) D[16:31] is mapped to BD[0:15], and during a read (peripheral to ARM)
BD[0:15] is mapped to D[0:15].
The podule is read & identified (when PRE goes low) by the following bits on
the data bus.
BD[0] 0 = Podule generates IRQ
1 = Podule does not generate IRQ
BD[1] 0 = Podule absent
1 = Podule present
BD[2] 0 = Podule generates FIRQ
1 = Podule doesn not generate FIRQ
BD[7] 0 = Acorn podule
1 = Third party
BD[3:6] are the podule identification nybble.
When PS goes low, the address (from the table in previous article) is made
available on address lines LA[2] to LA [15], and the data appears at BD[0] to
BD[32].
A3000 Users
-----------
The A3000 mini-podule is a slightly cut-down version of the above
pinout. Pin 2c is re-designated Reserved, as is pin 32c. Also, you have a
separate, internal I2C connection,
I'll see if I can get a better source of the Podule system calls for the next
issue; the PRMs aren't particularly clear on this, especially on the chunk
handling side.
The I2C bus - what is it? tony Duell
-------------------------
This information originally appeared in Coredump, the newsletter of the BITS
Hardware and Old Systems SIG, and is reprinted here with permission of the SIG
Leader.
The I2C bus (it stands for Inter Ic Communication) is a 2-wire (clock and data)
multi-device bus designed by Philips originally for consumer electronics
(Televisions, Video Recorders, etc). One of the main problems in such devices
was the large number of peripheral devices (Teletext decoders, front-panel
displays, remote control systems, etc) that were controlled by the central
microcontroller, and which thus required the microcontroller's address and data
busses to be routed around the complete device. However, none of these devices
really required fast control (I mean, you don't change channels every
microsecond, now do you?), and a serial bus was the obvious answer.
_The_ reference on the I2C bus is the Philips data book. In my set, it's book
4, parts 12a and 12b. I think that may have changed now. If I find out any more
information, I'll report it in Coredump. These books give complete
specifications of the signals to be sent on the bus, and of the chips designed
to connect to it. However, I'll summerise the most important aspects here.
Both the clock (called SCA), and data (called SDA) are driven by open-collector
(or equivalent in non-bipolar technologies) drivers, and are pulled up by
resistors, external to all the IC's. If you have a personal computer on the
bus, it's normal for the computer to be fitted with these resistors. So, in the
idle state, both lines are in the logic 1 state, and can be forced to the
logic 0 state by any device on the bus.
Its important at this point to define 4 important terms :
Transmitter - the device that outputs data
Receiver - the device that inputs data
Master - the device that controls the transfer, and generates the clock signal
Slave - the device controlled by the master. A particular IC may be designed to
be a slave only, and in that case, it will be incapable of driving the clock
line (although, of course, it will still monitor it).
Data is passed serially, MSB first, on the data line. The data line is sampled
by the slave when the clock is high, and thus, except in special circumstances,
the data line may only change state when the clock is low. Data is transfered
in 8-bit bytes, and after the last bit is transfered, the transmitter allows
the data line to float high, and the master generates one more clock pulse.
During this time, the receiver pulls the data line low as an acknowledge
signal.
2 special conditions must also be defined - those to start and stop a
transfer. They are the only time the data line changes state when the clock is
high. In fact, a 1->0 change on the data line defines a start, a 0->1 change
defines a stop.
I've not said anything about addressing the various devices on the bus yet. The
first byte transfered after the start signal is interpreted as an address. The
LSB is 0 for a write, and 1 for a read. The other 7 bits select the device. It
is normal for the top for bits to be permanently defined within a particular
chip, and to allow some of the other bits (from 1 to 3) to be selected by
external pins, thus allowing multiple devices of the same type on the same I2C
bus - every device must have a unique address of course.
Here are some typical sequences of data transfer on the I2C bus
Write to slave IC
Start | Address (LSB=0) | data | Ack | data | Ack | Stop
Read from slave IC (a simple IC, with only 1 register)
Start | Address (LSB=1) | data (from slave) | Ack | Stop
Write to IC to select register, then read back
Start | Address (LSB=0) | data (to slave - here a register select) | Ack |
Start (here called a repeated start) | Address (LSB=1) | data (from slave) |
Ack | Stop
How to get your computer talking on the I2C bus
-----------------------------------------------
If you have an Acorn Archimedes, then you are lucky. It has a I2C port built
in, accessible on 2 pins of the podule connector. If you have some other
machine, you will have to build a port yourself. Elektor magazine did an
article describing a plug-in card for the IBM PC, for which both the etched
circuit board, and a disk of driver software (including source code) are
available. It uses the Philips PCF8584 device, available from RS components,
under stock number 296-699. The examples I give will assume that you have this
card, and the software. You will have to translate them for some other machine.
In fact, the PCF8584 is a very easy-to-use device. It takes an 8-bit data bus,
1 address line, an 8MHz clock (or other values can be used), and control
signals. It even looks at the first access after a reset (which should be a
write to the chip's register 0), and works out if it is being driven by an
Intel-bus (the Arc is generally classed as an Intel bus-alike : Dave) or
Motorola-bus CPU. It then defines the rest of the signals accordingly. I'll
probably be designing boards to use this chip with other personal computers in
due course, and will describe them in future issues of Coredump.
Build a simple real-time clock for the I2C bus
----------------------------------------------
Here's the first of (hopefully) many projects to work in the I2C bus. It's a
real-time clock in 6 components, using the PCF8583 device (RS stock number
296-683). Here's how to wire it up. The PCF8583 has 8 pins
--V--
OSCI--------| |----- +5v
OSCO--------| |-----INT
A0----------| |-----SCL
Ground------| |-----SDA
-----
+5v and ground are obvious!
SCL and SDA are the I2C connections, and should be linked to the correct
connections on whatever computer you are using to control this project
INT is an interupt output. For now, just pull it high by a 1k resistor to +5v
A0 is an address select input. It defines the LSB of the 7 bit address. The
address is either 1010000 or 1010001. To use my software, simply connect it to
ground.
OSCI and OSCO are the connections for a 32.768 kHz crystal (a digital watch
crystal). Just connect it between the pins, and then connect a 5-25pF trimmer
capacitor from OSCI to +5V.
That's it. If you are using the Elektor I2C interface and software, the program
below should run as-is. If you are using some other machine, you can still use
the method.
program real_time_clock (input,output,bus);
{Test PCF 8583 clock chip on I2C bus }
{i2c is a unit provided on the Elektor I2c software disk}
uses i2c,crt;
var
bus:i2cfile;
packet:array[0..7] of byte;
r,p:byte;
i:integer;
{The PCF8583 uses 8 bit BCD numbers (2 digit). The following 2 functions
convert bytes to/from such BCD representations}
function bcd2bin(x:byte):byte;
begin;
bcd2bin:=(x div 16)*10 + (x mod 16);
end;
function bin2bcd(x:byte):byte;
begin;
bin2bcd:=(x div 10)*16 + (x mod 10);
end;
begin;
{the array PACKET will be used to read/write to the PCF8583. The bytes
are mapped to the internal registers. First, we clear them }
for i:=0 to 7 do packet[i]:=0;
{Now, we get the current time, and put it in the correct bytes of PACKET.
Hours are regist 4, minutes 3, seconds 2 - see the PCF8583 data sheet
for more details }
clrscr;
write('hours : ');
readln(p);
packet[4]:=bin2bcd(p);
write('minutes : ');
readln(p);
packet[3]:=bin2bcd(p);
write('seconds : ');
readln(p);
packet[2]:=bin2bcd(p);
{Initialise the I2C system}
start(bus);
{The PCF8583 has an address with high nybble 1010, low nyble either 0
or 2 according to the state of the A0 pin. Bit 0 is the read/write
flag as normal. Here, A0 is tied low }
address(160);
{R is used as the register pointer for the PCF8583. It is set to the
number of the first register to be read or written}
r:=0;
{Now actually send the values to the PCF8583}
write(bus,r,packet[0],packet[1],packet[2],packet[3],packet[4],packet[5],
packet[6],packet[7]);
close(bus);
{Routine to read in the time and display it}
clrscr;
{reselect the PCF8583}
start(bus);
address(160);
repeat;
{We'll read in the 8 registers, starting from 0}
r:=0;
{send the register address to the PCF8583}
write(bus,r);
{Here, we start reading. In fact, the driver generates a repeated start
here}
read(bus,packet[0],packet[1],packet[2],packet[3],packet[4],packet[5],
packet[6],packet[7]);
{display the time}
gotoxy(20,3);
writeln(bcd2bin(packet[4]):2,':',bcd2bin(packet[3]):2,':',
bcd2bin(packet[2]):2);
until keypressed;
close (bus);
end.
Although this third second article is aimed at the design and implementation of
an I2C bus on a certain "other" computer, it's interesting to see both how it's
done (our own I2C comes out direct out of IOC), and to get a PASCAL listing
which those of you with the DDE can test, substituting the SYS"IIC_Control"
call where necessary.
Please mail me with your opinions as to whether you'd like to see the rest of
the I2C series duplicated in EurekA, and if you'd like to receive Coredump (an
excellent hardware Newsletter, especially for DEC hackers) tony can be
contacted as ard@siva.bris.ac.uk. Coredump, like EurekA and Cassini (the HP
Handheld SIG Newsletter) is also available from info.bris.ac.uk.
*LIB
~~~
Yet more freshly-acquired documentation available from your friendly
neighbourhood SIG Leader...
BBC Master blueprints
---------------------
Those were the days... well, indeed they were. However,
these docs (never officially released) will hold a great deal of interest for
those of us who still run Beebs, etc, and for the Arc-only owners as well, this
print set includes schematics of the Econet interface. Fortunately, the Master
Econet interface and the Arc Econet interface are electronically identical...
ARM data book
-------------
If you want to know about the insides of the ARM chipset, look no
further. This is the book designed by hardware developers for same, and tells
you everything you always wanted to know and weren't afraid to ask, but
couldn't find inside the PRM or Hardware Ref. Manual. Time to have some fun
reprogramming the MEMC to tweak RAM protection in Supervisor mode.....
Time to give my Bank Manager nightmares...
------------------------------------------
After much deliberation, I've
decided _NOT_ to buy a RISC OS 3.10 PRM set.
(Pause for dramatic effect)
At least, not on paper. A CD ROM has been released, priced at #99, (but can't
remember the name of the supplier at the moment; ho hum) containing
the following documentation:
RISC OS 2.00 /01 PRM
RISC OS 3.00 PRM (Unreleased on paper)
RISC OS 3.10 PRM
Acorn Desktop Assembler manual
Acorn Desktop C manual
Acorn DDE manual
Technical (Hardware) manual for all hardware variants
Unfortunately, it doesn't contain the ARM data book!
In total, this works out, including the CD ROM drive to play it on, as not
much dearer than buying all the manuals on paper. In conjunction with the
advanced searching options available, I reckon it's well worth it.
*SHUTDOWN
~~~~~~~~
Issue #3 thus bites the dust. I apologise for the delay in getting
this one out, but it's involved rather more work than even Issue #2. Also,
having an Electron Microscopy exam to revise for over Christmas didn't help.
As I have more exams at Easter, I can't say when Issue #4 will happen... I'm
also running a little low on easy-to-implement Arc hacks to write up at the
moment, as horizons widen and projects get bigger, giving me an inevitable
backlog. The time may come when I'll document the homebuilt FPA and the
multitasking BSD UNIX port (from src.doc.ic.ac.uk), including the code for
UNIXFS:, but I doubt they'll be in the same issue, and certainly not in the
same posting (goodbye, net.bandwidth)!
Meantime have a belated Happy 1993 from me, and happy hacking to you all.