Navigation

Illegal Op-codes

I wrote this as an article to Dragon Update (the newsletter
of the National Dragon User's Group) and it got published in the February 1994
issue. It documents the effects of executing certain op-codes in the 6809 that
are marked in the data sheet as 'illegal'.

Whilst looking through your 'Inside The Dragon', you may have come across
the bit under TFR/EXG where it says "...all other combinations are undefined
and invalid..." Fair enough, looks like a reasonable restriction... WELL IT
ISN'T! It's a plot by Motorola to force you to pay attention to what they say!
You CAN use other combinations (or at least you can on mine), and the
functionality is as follows:

When transferring from register M to register N, as many bits are filled
from bit 0 in N as can be obtained from M, and the rest (if any) are filled
with 1s. So, transferring A to B transfers the 8 bits of A into the lower bits
of B, and that's it ... nothing left to fill with 1s.

BUT, transferring B into Y, for example, would take the 8 bits of B and
shove them into the lower 8 bits of Y, and since it has run out of B, would
fill the upper 8 bits of Y with 1s. Transferring X into A would mean A equals
the lower 8 bits of X.

Good, eh? Useful? No? Well, what about when you're using X as a screen
pointer, and need to know how far along you are? Usually you might

PSHS A
TFR X,D
ANDB $1F

and B would then be the amount of character positions across the screen you
were. You then, of course, need to PULS A again (assuming B is a scratch var,
so doesn't need value stored). But, using illegal transfers, all you have to
do is

TFR X,B
ANDB $1F

...EASY!

There is, of course, one slight snag, and that is that Dream will chuck out
any transfers where the registers are of unequal size, so to get round that you
have to include a line saying something like

FDB $1F19 ; TFR X,B

which directly includes the code for TFR ($1F) and the parameter X,B (X=1,
B=9). Look at your data sheet for register values.

For an EXG, you would just use $1E instead of $1F ... EXG operation follows
the same guidelines as TFR.

Another useful hint is that an undefined register value (say 7) is treated
as a register of 0 bits, i.e. FDB $1F72 (tranfer reg 7 into Y) would act the
same as LDY #$FFFF, but in one less byte. The disadvantage is that the
transfer takes two more clock cycles, so is slower - decide which trade-off you
want for the application you have in mind.

Also, I think that executing $3E (undefined in data sheet) calls the reset
vector ($FFFE/F) in a similar way that SWI ($3F) invokes the SWI vector
($FFFA/B). Can't really think of any uses for this except if you needed to
automatically reset the machine to install something.