[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