[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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).

> 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.

> 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?

-- 
David Empson
dempson@actrix.gen.nz