Re: Help with confirmation on a small bit of assembly?

[Tristan Mumford <xtristan.xmumford@xgmail.xcom>]

David Empson wrote:

> Tristan Mumford <xtristan.xmumford@xgmail.xcom> wrote:
> 
>> Hi everyone.
>> I was just after a little help. It's not 100% apple2 related, but it is
>> 6502 related.
>> It's for my uC based USB card. I finally nailed hopefully all the
>> hardware problems. But now I'm back at the problem of it getting stuck
>> during initialisation.
>> I've ported the code to C but there still seem to be a few bugs.
>> 
>> The code below is the original MicroUSB assembly.
>> 
>> 03420          LDY #8
>> 03430 .3       TYA
>> 03440          CLC
>> 03450          ADC #$F
>> 03460          TAX
>> 03470          LDA SETCONF-1,Y
>> 03480          JSR REGSTORE
>> 03490          DEY
>> 03500          BNE .3
>> 
>> 
>> This is my rough interpretation of that small block.
>> Please note the 0x10 is what truly bothers me. If I understand the asm
>> correctly I should have the value 0x11 there to ensure it starts off at
>> 0x18
>> 
>>    for( tmp = 7; tmp >= 0 ; --tmp )
>>       regStore( SETCONF[ tmp ] , ( tmp + 0x10 ) );
> 
> That translation looks right to me, assuming A and X are parameters
> being passed to regStore. The tmp index into SETCONF is equal to Y-1 in
> the original assembly, and X is set to Y + 15, which would be equal to
> (tmp + 1) + 15, or tmp + 16.
> 
> On the first loop, the original code would have Y=8 and X=23 (0x17).
> 

Okay. Great. So I was on the right track. That means I'm looking too hard
for a bug in the wrong place. Thankyou for that.

>> The below code is why it bothers me so. Note: BUFADR and BUFLEN are
>> address values for on the USB IC. BUFADR is 0x01 and BUFLEN is 0x02, not
>> that it's really important anyway.
>> 
>> 02880          LDA #$10    ; $10 ADDR
>> 02890          LDX #BUFADR ; DATABUF
>> 02900          JSR REGSTORE
>> 02910 ;
>> 02920          LDA #$8     ; 8 BYTE
>> 02930          LDX #BUFLEN ; DATABUF
>> 02940          JSR REGSTORE
>> 
>> C equivalent:
>> 
>> regStore(0x10, BUFADR); //databuf base location?
>> regStore(0x08, BUFLEN); //setting an 8 byte buffer
>> 
>> To me that says that there is an 8 byte buffer set up with a base address
>> of 0x10 on chip. This would mean that the buffer is from 0x10 to 0x17,
>> not 0x11 to 0x18 as the assembly suggests to me.
> 
> You seem to be misinterpreting the original assembly. Y starts out at 8,
> then the CLC, ADC #$F sequence adds 15 (0x0F) to the value which was in
> Y, and 0x0F + 0x08 = 0x17 (23 decimal). This means the first call to
> REGSTORE is addressing register 0x17, and it works down until it does
> 0x10 on the last loop (Y = 1, plus 0x0F).
> 
> If it was SEC instead of CLC before the ADC then it would be adding one
> more. ADC adds the operand plus the carry flag to the accumulator.

I see now. You have also made me think that I have to check for dropped
flags in other parts of my code. That could cause some nasty fencepost
errors.
Sorry. 6502 assembly isn't one of my strongest languages. It's even worse
when reading other peoples code.

> 
>> The original source works fine from what I can understand. So the problem
>> must be my misinterpretation. I think.
>> 
>> Is my top little fragment of C correct?, and if so with 0x10 or 0x11 as
>> the value. I'm leaning toward 0x11.
> 
> Why?  Where do you think the assembly is adding one more?
> 
...What's wrong with me.
You've pointed out yet another idiotic mistake I've made of late but
couldn't see. Somehow during my breakdown of it 0xF = 16. Last time I
checked 16 != 15.

Thankyou yet again.

-- 
-----> http://members.dodo.com.au/~izabellion1/tristan/index.html <-----
=====       It's not pretty, it's not great, but it is mine.       =====