[Coco] 6809 opcode map

jdaggett at gate.net jdaggett at gate.net
Tue May 9 22:03:22 EDT 2006


Kevin

While I did work for Motorola for 23 yrs, I was not in the IC group. I did work with a 
few IC engineers but not directly with the 6809 or that group.  So at least some of 
my comments are flavored with a small understanding of the insides of some of the 
processors. 

As far as I can say, the opcode map is rather compact and efficient. 

>From an 8 bit opcode one can derive the addressing mode and one of 59 distinct 
instructions. All of this can be done with combinatorial logic in parallel. Even with 
1979 vintage NMOS fabrication limits, this can done in a matter of less than 50 to 
70 nanoseconds. WIth today's high speed logic,  the logic could decode address 
mode and instruction is the range of 15 to 25 nanoseconds. 

If anything that I could imagine would have been how the "pre-byte" as most call it 
is handled. In reality it is somewhat an instruction on its own. AN opcode of $10 or 
$11 forces the internal state lofic to do another fetch while keeping track of  what 
the "pre-byte" opcode was. IF you follow closely the opcode map and the process 
flow, you will see that the "pre-byte" will alter the register ia particular instruction 
acts on in most of the opcodes. An example is LDX and LDY. They both share the 
base opcode of $8E, $9E, $AE and $BE. The $10 opcode forces the internal logic 
machine to alter the destination regeter from X to Y. What would have been better 
is if this could some way be done in one machine cycle instead of two. This is where 
the 6309 does have its advantage of a psuedo pipeline of one machine cycle. 

Some of the other opcodes on page 2 and page 3 have the instruction slightly 
altered. LIke SUB and CMP. Inside the processor these instructions are the same 
function. Only in compare the result of subtraction is not stored.Only the flags are 
set and the result is lost. 

The real issues do not lie so much in the main opcode map but the post byte 
opcode map and decoding for indexed and indirect indexed modes. This is really 
the time consuming part of an instruction. 16 bit loads would have helped to speed 
things up a bit. Overall there is no real major changes that could have been made 
that would not affect some other instruction.  The opcode map does seemed to be 
optimized for the most commonly used instructions. With an 8 bit map the only way 
to add instructions and address modes is to do a paged map system. A 16 bit 
opcode could make the map rather large and almost unmanagable. The 6809 does 
get a lot out of just an 8 bit opcode. 

just my thoughts 

james

On 9 May 2006 at 17:47, Kevin Diggs wrote:

> Hi,
> 
> 	Anyone know anyone who worked at Moto on the design of the 6809? I 
> would like to ask them something:
> 
> 	If you had it to do over again would you change anything in the opcode map?
> 
> Anyone else feel free to chime in.
> 
> 					kevin
> 
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
> 
> 
> -- 
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.392 / Virus Database: 268.5.5/333 - Release Date: 5/5/2006
> 





More information about the Coco mailing list