diff -r 5072524fcc79 -r 80ef3a206772 Symbian3/PDK/Source/GUID-76A30EC4-4B99-5471-9E80-F853C91485BC.dita
--- a/Symbian3/PDK/Source/GUID-76A30EC4-4B99-5471-9E80-F853C91485BC.dita	Fri Jul 02 12:51:36 2010 +0100
+++ b/Symbian3/PDK/Source/GUID-76A30EC4-4B99-5471-9E80-F853C91485BC.dita	Fri Jul 16 17:23:46 2010 +0100
@@ -66,7 +66,7 @@
 interrupt sources. These are usually prioritised by connecting the interrupt
 output of a lower-priority controller to an interrupt input of a higher-priority
 controller. This is called chaining. </p> <fig id="GUID-49264B94-DF6D-5F11-8815-D42CDBF94E39">
-<image href="GUID-0DB79535-E4E6-50BD-852D-B2F177202C9C_d0e375610_href.png" placement="inline"/>
+<image href="GUID-0DB79535-E4E6-50BD-852D-B2F177202C9C_d0e381454_href.png" placement="inline"/>
 </fig> <p>An interrupt from a lower priority controller will appear as an
 interrupt on the highest-priority controller. </p> <p>When the interrupt dispatcher
 of the higher-priority controller detects that it is the chained interrupt
@@ -77,7 +77,7 @@
 <section id="GUID-ED6F2F47-7A16-5AE6-8E5B-B2475F6EDEAA"><title>Multiple interrupt
 sources and pseudo interrupt sources</title> <p>It is possible that a single
 input to an interrupt controller is shared by several interrupt sources. </p> <fig id="GUID-DC96E3A8-9820-5CD4-8020-3B55398388D9">
-<image href="GUID-DCBBDFA7-1E6C-5B00-A13E-A25794668E12_d0e375632_href.png" placement="inline"/>
+<image href="GUID-DCBBDFA7-1E6C-5B00-A13E-A25794668E12_d0e381476_href.png" placement="inline"/>
 </fig> <p>It appears necessary to bind multiple ISRs to the same interrupt.
 However, this is not possible. There are two ways of dealing with this: </p> <ul>
 <li id="GUID-0D954444-C2C3-51CC-8E1D-7EB063CDACAA"><p>Maintain a list of all
@@ -122,7 +122,7 @@
 the pure virtual functions: <codeph>InterruptBind()</codeph>, <codeph>InterruptUnbind()</codeph>, <codeph>InterruptEnable()</codeph> etc,
 all with signatures that are the same for the comparable functions defined
 by <xref href="GUID-E7A7083C-97B9-39B9-A147-4A6E314EE3A3.dita"><apiname>Interrupt</apiname></xref>, and which are implemented by the <codeph>Template</codeph> class. </p> <fig id="GUID-458C7825-5B35-583C-BDF6-7DCD21DAE670">
-<image href="GUID-B7E7E6D6-7824-505C-BA0B-B7861897E78F_d0e375726_href.png" placement="inline"/>
+<image href="GUID-B7E7E6D6-7824-505C-BA0B-B7861897E78F_d0e381570_href.png" placement="inline"/>
 </fig> </section>
 <section id="GUID-9D98586F-AD1D-5C50-9AD8-F81D72135382"><title>Spurious interrupts</title> <p>In
 the Kernel Architecture 2, it is a convention that unbound interrupts should
@@ -177,7 +177,7 @@
 (or at least, different registers) then you will need to arrange the table
 so that you can determine from the <xref href="GUID-76A30EC4-4B99-5471-9E80-F853C91485BC.dita#GUID-76A30EC4-4B99-5471-9E80-F853C91485BC/GUID-8E58F4C9-0290-55E0-A4FD-B6C2361BE205">interrupt
 ID</xref> whether the interrupt is an IRQ or FIQ. </p> <p>For example: </p> <fig id="GUID-9DD2CC92-A5DB-5C78-A9A6-64402FF04FE2">
-<image href="GUID-60949ACD-AAA9-540E-85AE-BB173382D548_d0e375842_href.png" placement="inline"/>
+<image href="GUID-60949ACD-AAA9-540E-85AE-BB173382D548_d0e381686_href.png" placement="inline"/>
 </fig> </section>
 <section id="GUID-EACCBDFD-46CD-4D67-B60C-D705867C9116"><title>Location of
 interrupt handling code</title> <p>Most of the interrupt dispatching code