Pixel or not Pixel...

Zitat von Ultimax

and #Tmp1 ;(????)

Have you ever tried without the '#'?

When calculating the memory address: Did you consider the offset between the first pixel of the bitmap screen (0,0) and the x,y values of the sprite (their 0,0 is in the border)?

Zitat von Ultimax

In any case, Tmp1 does not contain an address, but a value.

Something is fishy there. You are storing a value into Tmp1 ("sta Tmp1"), so it cannot be a value but must be an address.

In general, the approach looks correct and AND should work perfectly fine.

EDIT: oh, I see that you BNE after the AND and set the pixel. But you will get a 0 as result of the AND when the pixel was OFF, so you should BEQ instead.

EDIT: I'm too slow...

Zitat von Hexworx

Have you ever tried without the '#'?

Zitat von Ultimax

Yeah, I tried, it doesn’t work.
In any case, Tmp1 does not contain an address, but a value.
hence the immediate 'AND #' test.

There is a "sta Tmp1" instruction in your code, so "Tmp1" must be the name of an address (where a value gets stored). Therefore, "AND #Tmp1" is definitely a mistake, and "AND Tmp1" would be correct.
If the program still does not work as intended, the reason must be in a part of the code you did not post.
I'm particularly suspicious about the label "PixOn", because it is defined twice in what you posted. Please post your source without editing parts out.

As you did not include your lookup table for address calculation your affice_pixel _might_ be in reversed order.

Please, post the part of the address calculation ...

Ich glaube so müsste es gehen.

Zitat von Acorn

Ich glaube so müsste es gehen.

...

For sure a much better way and a pretty condensed code, which makes it very clear. However, it's left in the dark whether Temp0 is properly calculated. I suspect that this could be the cause Temp1 doesn't contain the expected value beside the obvious wrong and #Temp1 (I know, just for testing reasons only).

Zitat von Acorn

lax .Affiche_Pixel,y

Oh, I somehow thought that lax was not stable except for lax #0. The Oxyron page seems a bit unclear on that. Do you have a source where the reliability of lax is more clearly specified?

Zitat von Claus

Oh, I somehow thought that lax was not stable except for lax #0. The Oxyron page seems a bit unclear on that. Do you have a source where the reliability of lax is more clearly specified?

LAX is only unstable when used with immediate addressing (opcode 0xab), all other addressing modes are fine. See groepaz's "NMOS 6510 Unintended Opcodes" document for details.