Branching instruction help!

[McPete]

Hi all,

I'm having a little trouble with branching instructions in the MC68HC11 micro. I've got a situation where I need to hop four bytes forward if I get a zero flag in my CCR. The trick is, if I enter an operand of 04, I get an out of range warning from my assembler.

What've I done wrong?
Thanks,
Pete

[RayJones]

Just blew the dust off a HC11 book I had nearby. 

As I distantly remembered, the PC is adjusted by 2 + Rel operand. ( i wasn't sure if it was + or -)

ie to loop back to the same instruction, you need to use 0xfe (-2).
The default action being 0 is the next logical instruction.
So to jump 4 bytes forward from the location where your instruction lies, use operand = 2.

Anyway, doing it by hand is far too hard, especially these days!
Surely there must be an assembler to do the hard work for you?

[RayJones]

Actually, having re-read your query, are you sure you are not trying to branch to address 0x04?

The branch instructions are limited to +258 / - 253 bytes (based on the +2 offset) (or is it +257 / -254  )

[McPete]

Hi Ray,

 Thanks for the reply- I had no idea there was an offset involved- I have a few questions for my teacher then. The reason I'm hand assembling is because this is a µC basics course at TAFE- Heck, the first week, we were manually entering individual bytes! I'm using a Buffalo sim.

The code should work like this;

<snip>
118 STAB $00,Y
11B INY
11D DECA
11E BEQ *operand*(Jump 4 forward, to TBA)
120 BRA F7 (Should jump to 118)
122 TBA
</snip>

[RayJones]

Yeah no probs.

I cut my teeth on the 6800, then the 6809. All these processors behave in much the same way.

BTW, are you sure about the BRA F7 - I would have thought the value should be even given your src (0x120) and dest (0x118) addresses are even values.
I'm thinking -10d, => F6......

I played around with the Buffulo monitor at some stage way back, and somehow my fiddles made it into a mailing list at the time.

I just found it on google - ouch 1995!:

Date:    19951108
From:    ray@radar.ho.bom.gov.au <ray.jones@bom.gov.au>
To:      Mot-68HC11-Apps@freeware.aus.sps.mot.com
Subject: Re: Getting started with the EVM...

> Message sent by Jaap van Ganswijk <ganswijk@xs4all.nl>

> Buffalo expects a UART at 0x4000. So if you have an SRAM* from
> 0x0000 up to 0x8000, which is currently usual, it doesn't
> download location 0x4000 correctly. This has cost me and others
> already hours (or even days) to find.
>
> You can easily fix this in the opcode, without reassembling.
> Just change the (2?) store instructions in load's. You don't even
> need to burn a new EPROM*, since only one bit goes from 1 to 0.

Ahhh, excellent info, I was just getting a new (Non EVM) system up
and going last weekend using the buffalo monitor.

My S19 file was ORG'ed to start the code at 4000h, but the byte was
always being cleared!!!.  I had no idea what was going on.

Thanks again for this valuable tip.

Cheers Ray

[RayJones]

Hi Pete,

Danger Will Robinson Danger!

I was just packing away my trusty HC11 book, so it could gather more dust, and found on the next page from the BRA instruction (no not related to the SEX instruction damn - that was the 6809! )

Sorry got distracted.
The BRA, Branch Always, instruction uses the formula:  PC = (PC) + $0002 + Rel
The BRCLR, Branch if Bits Clear, instruction uses the formula:  PC = (PC) + $0004 + Rel or PC = (PC) + $0005 + Rel if using indexed mode

It all depends upon how many bytes are used to form the complete opcode instruction.

Safest to use labels and an assembler I'm thinking!

But still I suspect your assembler warning is related to you trying to branch to location $0004, not 4 bytes forward.
Check the syntax of your labels.....

[McPete]

Hi Ray,

You hit the nail on (my) the head... Yes, the assembler automatically fills in the byte with reference to an address. Now I feel like a proper dope :p
One mystery solved! Stop worrying and love the assembler!

Thanks for your help Ray.

Incidentally, my job tomorrow is building up the  Bison Board so I can actually run the hardware. I,ll let you know how I get on.
Peter