Displaying P0 twice more than 64 pixels appart ?

[Windless]

Hi,

 

I want to display P0 twice (P1 is used for something else). Using NUSIZ0 I can have a copy up to 64 pixel away from the first instance. But I'd like to have more distance than that.

I can RESP0, but then I can only position P0 every 3 pixels. I can then ASL / LSR the pixels, but I loose two pixels (can only have a 6px width P0.

I can't HMOVE the second P0, because RESP0 will reset the +7/-8 offset, and an HMOVE made after RESP0 apparently prevents sprites from being display or the next 72 pixels.

 

Is a possibility with making an HMOVE then making a RESP0 or changing HMP0 during the 24 forbidden cycles to achieve the +1/-1 on the modulo 3 position I need ? Or something else I don't know about yet ? (I've only been into 2500 for a week )

 

Thank you,

Windless.

[+SpiceWare]

You can by hitting RESP0 extra times. It's an advanced technique and does have limits on where the copies can be positioned. Read about it in this topic, especially the replies by SeaGtGruff on page 2.

[ZackAttack]

You could also position the first copy far enough right so the second copy wraps around to the left side of the screen.

[Windless]

You can by hitting RESP0 extra times. It's an advanced technique and does have limits on where the copies can be positioned. Read about it in this topic, especially the replies by SeaGtGruff on page 2.

 

Ok, reading this lead me to more questions, which made me find the TIA HW Notes with an important information I missed : the players start being drawn not 0 but 160 TIA clocks after the RESP0, but also 16, 32, and/or 64 depending on NUSIZ0.

 

With 1 CPU clock equal to 3 TIA clock, it means that without RESP0 you can position a player drawing at 16, 32, 64 or 160 + n*3 pixels.

 

Then if you can position a player at X = (32 + (n+1)*3), you can also position it at (16 + (n+6)*3) = (32 + n*3) - 1 = X-1 and of course (32 + (n)*3) = X-3. This means I no longer loose 2 bits but only 1. I'll continue to digg the doc to try understanding if I can do a +0 instead of +160 drawing, or if there is another trick to get a +1, that would solve my problem if the horizontal distance between the sprites is more than 32px.

 

Wlss.

[+SpiceWare]

It's definitely tricky stuff, but by hitting RESP0 a extra times that +160 goes away. Over at MiniDig - best of stella you'll find some useful info, it's a "best of" the defunct Stella Mailing list which still exists as an searchable archive.

 

On MiniDig's Tricks page is a link to an explanation of the Multi-Sprite trick, which is done by hitting RESP0 (and RESP1) extra times to get extra copies of the players to display.

[Windless]

You could also position the first copy far enough right so the second copy wraps around to the left side of the screen.

 

Mmm, I think I get the idea. I would still need a second hmove between the two of them but it would probably saves cycles when compared to my other solution.

 

Reading th TIA HW Notes, I seems to me it would be possible to :

-Start drawing 'main' player 1 with NUSIZ0 set at 0 for 3x3 cycles

-Switch NUSIZ0 to either 5 or 7 so the Player Horizontal Position Counter only gets incremented every two or four crystal clock

-Wait for for the PHPC to reach up to 64[1] and switch NUSIZ0 to 6 to get just before drawing of the third (which will be actually) second copy.

 

With this, and mixing 3x1, 3*1/2 and 3*1/4 PHPC increments, it seems I could achieve what I need ?

I will try to test that on the emulator, I still need to find a 2600

 

Wlss

 

1 : (it starts at 8, so that's 56 increments, with PHPC incrementing every 4 color clocks it takes up to 224 pixels)

[Windless]

Ok, that can not work. Here is what I understood after some test (nothing new, everything was in the doc, but learning by doing is great)

 

The code :

 

• P0 is positioned on left of the screen
• NUSIZ0 is set to %00000111 (1:4 clock speed)
• Wait for a few ticks for P0 to be partly drawn, then switch NUSIZ0 to %000001100 (1:1 clock speed, 3 copies medium spacing)

 

Top and bottom halves of the screen keep the clock 1:4 for different time spawn.

 

What I understood :

 

• The start signal is triggered by value of the Player Horizontal Position Counter
• The Player Graphic Scan Counter is the one which goes divided by 1:2 or 1:4 to stretch the Player, not the PHPC

 

Next step

 

• trying to understand this :

 

but by hitting RESP0 a extra times that +160 goes away

I think this is refering to the fact that on next line, I will need to RSP0 the player, hence reset the PHPC before it reaches 160, hence the first/third copy will never be drawn.

 

• Trying to do the same thing using HMOVE during a scanline.

Windless

 

The test :

test.asm

test.bin

Edited June 11, 2019 by Windless