change the color 0 in realtime with the copper

[Raislin77it]

i think it's possible, but how ?

i want to recreate this image and unfortunately i can use only the 0 color



i've understood how to select the right scanline.
but how can i select the correct x position?

for now i have someting like that :

MyCustomCop$ = Mki$($3f31)+Mki$($FFFE) , so from what i understtod the copper wait to the scanline $3f (so 63 or line 19) and xpos $30 (48 in pixel)

but i obtain this image in winuae



the yellow line begin very early not at the 48th pixel.
why ?
how can i count the exact xpos of a pixel in a screen ?

[roondar]

This is because copper positions are not relative to displayed bitmap, but to chipset DMA timeslot 0, which is different altogether. Because I didn't know off the top of my head, I checked the docs* to find the right value to use.

The relevant bit says that horizontal blanking runs from $0F to $35. It also implies the default 320x256 screen starts at horizontal position $48.

So assuming a default screen, horizontal pixel 48 and that I read the documentation correctly, you should set it to $78.


*) You can find them here: http://amigadev.elowar.com/read/ADCD.../node004C.html

[Raislin77it]

Originally Posted by roondar

This is because copper positions are not relative to displayed bitmap, but to chipset DMA timeslot 0, which is different altogether. Because I didn't know off the top of my head, I checked the docs* to find the right value to use.

The relevant bit says that horizontal blanking runs from $0F to $35. It also implies the default 320x256 screen starts at horizontal position $48.

So assuming a default screen, horizontal pixel 48 and that I read the documentation correctly, you should set it to $78.


*) You can find them here: http://amigadev.elowar.com/read/ADCD.../node004C.html

unfortunately it doesn't work

by the way i've founded an utility to convert an iff file to a copperlist but crashes winuae the utility is "futurecproducer" anyone have used this tool ?

[roondar]

Hmm.. That's strange though.. Maybe Blitz Basic doesn't use the default screen positions?

I do wonder: where did it end up with MyCustomCop$ = Mki$($3f79)+Mki$($FFFE)?
Maybe you can use the two different values you checked to determine what the correct values would be.

[Raislin77it]

Originally Posted by roondar

Hmm.. That's strange though.. Maybe Blitz Basic doesn't use the default screen positions?

I do wonder: where did it end up with MyCustomCop$ = Mki$($3f79)+Mki$($FFFE)?
Maybe you can use the two different values you checked to determine what the correct values would be.

i don't know

here the pic with this values of customcop :

MyCustomCop$ = Mki$($3f31)+Mki$($FFFE)
MyCustomCop$ + Mki$($180)+Mki$($FF0);
MyCustomCop$ + Mki$($3f79)+Mki$($FFFE)
MyCustomCop$ + Mki$($180)+Mki$($F00);

here the image

[roondar]

Hmm, I did think of something.
The WAIT instruction waits until a given position, then the MOVE instruction fires and will be completed slightly later (as it takes time as well).

Thinking about this, I remembered an article over at coppershade.org: http://coppershade.org/articles/AMIG...t_WAIT_Timing/

The relevant bit:

Originally Posted by coppershade.org

For palette colors as in the above example, it's enough that it's ready in time for the left edge of the screen, or $38 for the above standard screen. When this position is reached, DMA will load up to 6 bitplanes in 16 cycles.
The corresponding raster wait position for a MOVE to match up with the left edge is then position $3d.

So, the left edge of the screen is actually $3d and not $48. The right position for pixel 48 would then be $6d.

I can't test this right now, but it should be correct.

[Raislin77it]

Originally Posted by roondar

Hmm, I did think of something.
The WAIT instruction waits until a given position, then the MOVE instruction fires and will be completed slightly later (as it takes time as well).

Thinking about this, I remembered an article over at coppershade.org: http://coppershade.org/articles/AMIG...t_WAIT_Timing/

The relevant bit:


So, the left edge of the screen is actually $3d and not $48. The right position for pixel 48 would then be $6d.

I can't test this right now, but it should be correct.

from your link and my experiments is 5D because :

the screen start at $3d so in decimal 61
my x is 48 so 61+48=109 =>$6d
but the MOVE takes at max 16 pixels, so 109-16=93 => $5D

with $5D effectively the color change at the 48th pixel

[roondar]

That's only correct if the move does take 16 pixels though, which it only will if you use 6 bitplanes. If you use less bitplanes, you need to wait for a later position or your move will be done prematurely.

Besides, the article says that position $3d for wait means the move is completed at pixel 0 of the screen, so $6d should be correct for a screen up to 4 bitplanes, $69 should be correct for a 5 bitplane screen and $65 should be the right value for 6 bitplanes.