Double Byte Data - Revision history

Mr z: Protected "Double Byte Data" ([edit=autoconfirmed] (indefinite) [move=autoconfirmed] (indefinite))

2010-12-04T08:14:54Z

Protected "Double Byte Data" ([edit=autoconfirmed] (indefinite) [move=autoconfirmed] (indefinite))

Mr z at 16:56, 8 November 2007

2007-11-08T16:56:58Z

Mr z at 15:29, 8 November 2007

2007-11-08T15:29:08Z

Mr z: Double Byte Data Flag moved to Double Byte Data

2007-11-08T15:26:33Z

Double Byte Data Flag moved to Double Byte Data

Mr z at 16:33, 7 November 2007

2007-11-07T16:33:56Z

Mr z at 16:30, 7 November 2007

2007-11-07T16:30:34Z

Mr z at 16:23, 7 November 2007

2007-11-07T16:23:07Z

Mr z at 21:36, 7 October 2007

2007-10-07T21:36:14Z

Mr z at 19:45, 12 January 2005

2005-01-12T19:45:46Z

Mr z at 19:44, 12 January 2005

2005-01-12T19:44:32Z

@@ Line 5: / Line 5: @@
 [[Image:sdbd_mvii.png|center|SDBD prefix used with Immediate Mode instruction]]
 <br/>
-For [[Indirect]] mode accesses, if the indirect register is auto-incrementing (R4 or R5), the two values read come from consecutive addresses, as shown:
+For [[Indirect]] mode accesses, if the indirect register is auto-incrementing (R4 or R5), the two values read come from consecutive addresses, as shown below.  The pointer also increments twice, so it points to the first location after the two locations the CPU ended up reading.
 [[Image:sdbd_mvi_r4.png|center|SDBD prefix with Indirect via an auto-incrementing pointer]]
 <br/>

@@ Line 10: / Line 10: @@
 If the indirect register is not auto-incrementing (R1, R2 or R3), the instruction reads the same location twice. <br/>
 [[Image:sdbd_mvi_r3.png|center|SDBD prefix with Indirect via a non-incrementing pointer]]
 <br/>
 The [[CP1610]] does not specifically support SDBD with [[Indirect]] accesses through the stack pointer.  Programs also must be careful not to use the same register both as a numeric operand and an indirect register when accessing Double Byte Data.  In both of these cases, [[Undocumented SDBD Behavior|strange behavior results]].<br/>

@@ Line 1: / Line 1: @@
 [[Category:CP1610]]
-The [[SDBD|Set Double Byte Data]] instruction sets the Double Byte Data Flag (D).  This flag causes the next instruction, if it is an [[Indirect Mode]] or [[Immediate Mode]] instruction, to issue two memory reads instead of one, and construct a 16-bit operand from the lowest 8 bits from the values it read.  The first read fills the lower 8 bits of the result, and the second read fills the upper 8 bits.  SDBD also [[Undocumented SDBD Behavior|modifies the behavior]] of [[Direct Mode]] accesses.<br/>
+The [[SDBD|Set Double Byte Data]] instruction sets the Double Byte Data Flag (D).  This flag causes the next instruction, if it is an [[Indirect Mode]] or [[Immediate Mode]] instruction, to issue two memory reads instead of one, and construct a 16-bit operand from the lower 8 bits of each value it read.  The CPU ignores whatever is in the upper 8 bits of each value read.  The first read fills the lower 8 bits of the result, and the second read fills the upper 8 bits.  SDBD also [[Undocumented SDBD Behavior|modifies the behavior]] of [[Direct Mode]] accesses.<br/>
 <br/>
 For [[Immediate]] mode accesses, the CPU reads the two locations immediately following the instruction.  This allows ROMs narrower than 16 bits to hold immediate constants up to 16 bits long.  The following diagram illustrates:<br/>

@@ Line 13: / Line 13: @@
 The [[CP1610]] does not specifically support SDBD with [[Indirect]] accesses through the stack pointer.  Programs also must be careful not to use the same register both as a numeric operand and an indirect register when accessing Double Byte Data.  In both of these cases, [[Undocumented SDBD Behavior|strange behavior results]].<br/>
 <br/>
-Note that the D flag only remains set for the next executed opcode, regardless of whether of not the next opcode is actually affected by the status of the Double Byte Data Flag. After execution of the next opcode, the CPU clears the Double Byte Data Flag automatically.<br/>
+Note that the D flag only remains set for the next executed opcode, regardless of whether of not the next opcode is actually affected by the status of the Double Byte Data Flag. After execution of the next opcode, the CPU clears the Double Byte Data Flag automatically. As a result, [[SDBD]] acts as like a prefix instruction.<br/>
 <br/>
 The Double Byte Data Flag affects the behavior of the following instructions:<br/>

@@ Line 2: / Line 2: @@
 The [[SDBD|Set Double Byte Data]] instruction sets the Double Byte Data Flag (D).  This flag causes the next instruction, if it is an [[Indirect Mode]] or [[Immediate Mode]] instruction, to issue two memory reads instead of one, and construct a 16-bit operand from the lowest 8 bits from the values it read.  The first read fills the lower 8 bits of the result, and the second read fills the upper 8 bits.  SDBD also [[Undocumented SDBD Behavior|modifies the behavior]] of [[Direct Mode]] accesses.<br/>
 <br/>
-For [[Immediate]] mode accesses, the CPU reads the two locations immediately following the instruction.  This allows ROMs narrower than 16 bits to hold immediate constants up to 16 bits long.<br/>
+For [[Immediate]] mode accesses, the CPU reads the two locations immediately following the instruction.  This allows ROMs narrower than 16 bits to hold immediate constants up to 16 bits long.  The following diagram illustrates:<br/>
 <br/>
-For [[Indirect]] mode accesses, if the indirect register is auto-incrementing (R4 or R5), the two values read come from consecutive addresses.  If the indirect register is not auto-incrementing (R1, R2 or R3), the instruction reads the same location twice.  The [[CP1610]] does not specifically support SDBD with [[Indirect]] accesses through the stack pointer.  Programs also must be careful not to use the same register both as a numeric operand and an indirect register when accessing Double Byte Data.  In both of these cases, [[Undocumented SDBD Behavior|strange behavior results]].<br/>
+For [[Indirect]] mode accesses, if the indirect register is auto-incrementing (R4 or R5), the two values read come from consecutive addresses, as shown:
 <br/>
 Note that the D flag only remains set for the next executed opcode, regardless of whether of not the next opcode is actually affected by the status of the Double Byte Data Flag. After execution of the next opcode, the CPU clears the Double Byte Data Flag automatically.<br/>

← Older revision	Revision as of 08:14, 4 December 2010
(No difference)

← Older revision	Revision as of 15:26, 8 November 2007
(No difference)

@@ Line 12: / Line 12: @@
 <table cellpadding=5 border=1>
 <tr><th>[[Indirect Mode]]</th><th>[[Immediate Mode]]</th><th>[[Direct Mode]]</th></tr>
-<tr><td>[[MVI@]]</td><td>[[MVII]]</td><td>[[MVI]]</td></tr>
+<tr><td align=center>[[MVI@]]</td><td align=center>[[MVII]]</td><td align=center>[[MVI]]</td></tr>
-<tr><td>[[ADD@]]</td><td>[[ADDI]]</td><td>[[ADD]]</td></tr>
+<tr><td align=center>[[ADD@]]</td><td align=center>[[ADDI]]</td><td align=center>[[ADD]]</td></tr>
-<tr><td>[[SUB@]]</td><td>[[SUBI]]</td><td>[[SUB]]</td></tr>
+<tr><td align=center>[[SUB@]]</td><td align=center>[[SUBI]]</td><td align=center>[[SUB]]</td></tr>
-<tr><td>[[CMP@]]</td><td>[[CMPI]]</td><td>[[CMP]]</td></tr>
+<tr><td align=center>[[CMP@]]</td><td align=center>[[CMPI]]</td><td align=center>[[CMP]]</td></tr>
-<tr><td>[[AND@]]</td><td>[[ANDI]]</td><td>[[AND]]</td></tr>
+<tr><td align=center>[[AND@]]</td><td align=center>[[ANDI]]</td><td align=center>[[AND]]</td></tr>
-<tr><td>[[XOR@]]</td><td>[[XORI]]</td><td>[[XOR]]</td></tr></table>
+<tr><td align=center>[[XOR@]]</td><td align=center>[[XORI]]</td><td align=center>[[XOR]]</td></tr></table>
 </center></td></tr></table>
 <br/>
 The D flag also changes the timing of the instruction it modifies.  Generally, it adds 2 cycles to most [[Indirect]] and [[Immediate]] instructions.  Thus, where MVI@ might take 8 cycles, SDBD + MVI@ takes 14: 4 for the SDBD, 10 for the MVI@ modified by the D flag.