How to read sprite #0 collision detection in huc ??

[touko]

YEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHHHHH   

Code: [Select]

#asm         
     lda #low(_logo_pic_pal)     
     sta <__pointr
     lda #high(_logo_pic_pal)
     sta <__pointr+1
     lda [__pointr]
     sta _val
 #endasm

this is working fine and it's equate to ..

Code: [Select]

int logo_pic_pal[16];
int *pointr;
int val;

pointr = logo_pic_pal; /* pointr take logo_pic_pal address */
val = *pointr;  /* take the content of pointr address */

Arf f*ck, it's working only for byte 


i have seen my problem 
i take only the low part of variable.

YEAAAAAAAAAAAAAAAAAAAAAH touko 2 asm 0 

Code: [Select]

#asm       
     lda #low(_logo_pic_pal)
     sta <__pointr      
     lda #high(_logo_pic_pal)
     sta <__pointr+1
     lda [__pointr]
     sta _val
     inc <__pointr
     lda [__pointr]
     sta _val+1
#endasm       

Thanks tom for your patience and exemples, i have a good start for make in line ASM now 

[Tom]

hi i have included

Code: [Select]

#asm
  .zp
  __pointer1: .ds 2 
#endasm

before any huc code.

now <__pointer1 or [__pointer1] is working, but this pointer is not available directly in HUC 

 Yes But... the whole point of using asm for pointer handling is, is that HuC's pointer handling is extremely slow. Remember, you can declare a lot of pointers in ZP.

 So this:

Code: [Select]

#incpal(logo_pic_pal,"pcx/tg16.pcx") (array containing all the bcgnd colors)

int *datas_pointer;
int var;
.
.
.
.
datas_pointer = logo_pic_pal;
becomes this:

Code: [Select]

#incpal(logo_pic_pal,"pcx/tg16.pcx") (array containing all the bcgnd colors)
#asm
  .zp
  _datas_pointer: .ds 2
#endasm
int var;
.
.
.
.
#asm
 lda #low(_logo_pic_pal)
 sta <_datas_pointer
 lda #high(_logo_pic_pal)
 sta <_datas_pointer+1
#endasm

 You can skip the intermediate step and directly name the pointer in ASM. The only downside to this is, it looks kinda ugly. HuC doesn't support inline macros. It would be nice because you could have a C inline macro be an ASM chunk of code, and have it function more C like. Another poor thing with HuC is that you can't have #asm and #endasm on the same line, otherwise you could use the define directive in conjunction with ASM macros.

i have tried this

Code: [Select]

#asm     
     ldx #$0
     lda logo_pic_pal,x
     sta #low(__pointr)
     inx
     lda logo_pic_pal,x
     sta #high(__pointr)     
#endasm

And " incorrect addressing mode"   re 

 You can't write to a #. "#" means immediate, not address. Also, logo_pic_pal needs a "_" in front of it. Any global label, variable, array defined in HuC gets a underscore in front of the name. This is so HuC declarations don't conflict with the ASM side. Remember, HuC builds out a complete ASM file, not a binary. HuC calls the assembler to build the binary file of the ASM file, that HuC builds itself. And lastly, you don't want to use "x" indexing for logo_pic_pal. It's not an array of pointers. It's a single address. Think of "#" in front of the label as "&" in C.

I thing that i must use only < and [] for ZP pointers .

I have tried this

Code: [Select]

#asm         
     lda #low(_logo_pic_pal)
     sta <__pointr     
     lda #high(_logo_pic_pal)
     sta <__pointr+1   
  #endasm

Equate to :

Code: [Select]

int logo_pic_pal[16];
int *pointr;

pointr = logo_pic_pal;


 Correct. ZP is a special place in ram. To access it as fastram, you need to use the "<" operator. But ZP is also used as address vectors. If you think about it, the 65x processors have no internal 'address' registers. The z80, has up to 3 address registers (IIRC) using pairs of normal registers. It uses half your registers just for 2 address vectors. 68k has 8 address registers, with 1 being reserved for stack. So 7 address vectors. The 65x can have up to 128 address registers, but you rarely need more than say.. 10-20 address vectors or "pointers".

 To access ZP ram as address vectors, you need to use the "[]" brackets. You also don't need to use the "<" operator, because only ZP address range can be accessed as vectors.


 Here's a few examples of EA syntax:

Code: [Select]

lda #$00   ;<- load an immediate into register Acc. There's also LDX and LDY. LD stands for load and A/X/Y is the register. It's equivalent to move.b #$00,A


Code: [Select]

lda _logo_pic_pal   ;<- _logo_pic_pal is a label for an address. This is a 16bit address, so it equates to lda $1234 (if $1234 is the address). This loads a byte from memory


Code: [Select]

lda #_logo_pic_pal   ;<- # means load an immediate. Like the first example. But _logo_pic_pal is a 16bit address. Since the processor is little endian, the assembler will ignore the top half of the 16bit address number and only load the LSB of that 16bit number.


Code: [Select]

lda #low(_logo_pic_pal)   ;<- this is the same as the above example, but we use instead to make the code more clearer. That we are getting the LSB.
 sta somwhere
 lda #high(_logo_pic_pal)  ;<- The same thing as low(), but instead we grab the MSB of a 16bit value.
 sta somewhere+1

 Let's say you have a ZP address label as _pointer. Let's say _pointer is ZP address $05. ZP address range is 8bit. So the only addresses you can define are $00 to $ff. So _pointer is ZP address $05. Now, ZP address range IS external. So it has to exist somewhere in the CPU's logical address range. On the HuC6280, this is logical/local address range $2000-$20ff. So _pointer is actually $2005.

 sta <_pointer
 sta _pointer

 Are both the same address. They translate to:
 sta $05
 sta $2005

 As you can see, one of the instructions is using a shorter addressing mode. This means 1 less byte is required to form the address. This translates to a faster addressing mode. Other 65x assemblers, you don't need to use the "<" operator. They see "sta $05" as short addressing. PCEAS (the PCE assembler) doesn't see this. It requires that you use a "<" to tell the assembler to use short addressing mode. If you use "sta $05" directly in PCEAS, it will pad that to "sta $0005". Which is totally incorrect. So it's really important that you use the "<" when you're using ZP as either "fast ram" or address registers/vectors/pointers.

 And like I said, if you're using any ZP address range for vectors/pointers - you need to use the "[]" brackets. And without the "<" operator. That trips up some people.

 And one more thing to remember; you don't always need to use pointers to access arrays that are in ram. You can use direct addressing with indexing. It's faster than using a pointer.

 Question: Do you know 68000 assembly?

[Tom]

YEAAAAAAAAAAAAAAAAAAAAAH touko 2 asm 0 

Code: [Select]

#asm       
     lda #low(_logo_pic_pal)
     sta <__pointr      
     lda #high(_logo_pic_pal)
     sta <__pointr+1
     lda [__pointr]
     sta _val
     inc <__pointr
     lda [__pointr]
     sta _val+1
#endasm       


 Yup, you got it!

[touko]

Thanks for explanations tom, with your exemples they are a gold mine  ..

In my student period, i have learn a little bit of 6809 and 68K assembly, but it's faaaaaar in my mind ..

It's very funny to use inline assembly in a huc project, but not an entire game  ..
I have noticed with your first exemples, the difference between

 - #low/#high and low/high
 - </[]

I have noticed something strange in HUC ..

if i do

Code: [Select]

#incpal(logo_pic_pal,"pcx/tg16.pcx")

Datas in logo_pic_pal are not accessible (in C ,like ASM) until i do
logo_pic_pal[0];

Do you know why