How to? Indexed addressing of 16-bit values.

[JimDandy]

What I want to know is probably easy-peasy once you already know how...

I want to read a value of 0-255 from the outside world and depending on this value, look down a list of 255 16-bit values and select a corresponding value.

Down the bottom somewhere I suppose I would have a list:

ORG $whatever

FDB      #12345

FDB      #65535

FDB      #35

and to read one of these values I would have

LDX       POSITION_ON_LIST (outside-world value)

LDHX    $whatever,X

and then hopefully HX gets loaded with the value on the list corresponding to the value that was placed in X. Seeing that my list of values are 16 bit they take up pairs of memory locations, so does X really know to point to only every even value address, not even and odd like if it were addressing a list of 8 bit values?

[tonyp]

No automatic way, you first need to shift the value to the left once to multiply
it by two, and then use the offset.  You need something like:

                    clrh                    ldx       POSITION_ON_LIST                    lslx                    bcc       LookUp                    pshh                    inc       1,sp                    pulhLookUp              ldhx      WordTable,x

[donw]

or in the same vein.... but maybe faster ?

clra

ldx POSITION_ON_LIST

lslx

rola

psha

pulh

       ldhx WordTable,x

[JimDandy]

Okay - starting to look good.

But if I want to LDHX I can only do it in direct mode, i.e. from $00 to $FF.

Flash memory starts WAY above this and that is where the Wordtable would be.

There is not enough RAM to copy it all to there. What now?

[tonyp]

So, you're not using a 9S08.  Then, some more work is needed.  Right off the top of my head, one (untested/unoptimized) possibility is this:

                    lda       POSITION_ON_LIST    ;stack a word with value                    lsla                          ;(multiplied by two)                    psha                    clra                    rola                    psha                    lda       2,sp                ;now, add table address                    add       #[WordTable                    sta       2,sp                    pula                    adc       #]WordTable                    psha                    pulhx                         ;HX -> table entry                    lda       1,x                 ;now, load HX with word value                    psha                    lda       ,x                    psha                    pulhx

Notes: ASM8-based example. So, macro PULHX is PULH followed by PULX, [ gets lower part of word, while ] get higher part of word. One possible optimization (one byte, same cycles) would be a TSX before the lda 2,sp and then lda 1,x ... sta 1,x

[tonyp · Accepted solution]

On second look, the only instruction that causes problems is the LDHX WordTable,x

So, keep it the same as the first and change only the LookUp section to this:

LookUp              lda       WordTable+1,x                    psha                    lda       WordTable,x                    psha                    pulhx

[JimDandy]

I think you have it, tonyp. I'll give that a try. It's 11:26 pm here and the brain is getting more foggy than usual.

In the meantime I was thinking of spltting the words into two separate lists of MS and LS bytes and then doing something like this, but your approach seems MUCH better. Splitting the words is messy.

  LDA LS_BYTE_TABLE,POSITION_ON_LIST  PSHA  LDA MS_BYTE_TABLE,POSITION_ON_LIST    PSHA  PULH  PULX

[JimDandy]

This line:

LookUp              lda       WordTable+1,x

 would have an offset of up to 511 so X by itself would not cut it. Only HX would and I can't use it

[tonyp]

The LDA supports 16-bit offset for X index even with the HC08, so I don't see the problem.  From the CPU08 reference:

[JimDandy]

tonyp, you are dead right. I just now ran it on some hardware and it was perfect.

Thank you very much for all your help. 12:17 pm - time to go to bed.

[bigmac]

Hello,

I am not sure what the perceived problem is about?  The LDHX instruction for the 9S08 has a 16-bit offset version.  So the original expression should be quite OK.

LDHX  WordTable,X

Regards,

Mac

[tonyp]

The problem was he  is using a HC08 (not a 9S08) and certain addressing modes many of us (who have completely abandoned the HC08) take for granted are missing, including the indexed LDHX

[bigmac]

Hello,

This sort of confusion can easily be avoided if the derivative used is mentioned within the OP.  I admit that my psychic powers are somewhat limited in the mind reading department.

Regards,

Mac

[JimDandy]

Until now I thought that anything ending in "08" had identical instructions, just that some had extra ones. LDHX I thought was uniform across the range.

I'm predominantly a hardware engineer, that's the problem :smileywink: