WSYNC timing question.

[Bryan]

I've got a DLI that does a WSYNC and then goes into color/screen modifying code for a few lines. The code is the same on each line (all linear and unrolled) and ends in WSYNC. The lines commands are the same in the DLIST (mode F).

 

So, why is the first line always unaligned with the others by a little bit? I can put 10 WSYNCs before the first line and it is still shifted. I have to adjust my NOP timing in the first line, and then all the rest line up.

 

So far I'm just dinking around in Altirra so I haven't seen it on real hardware but I tend to trust that I'll see the same thing since Avery has done his homework so well.

[Xuel]

Can you post an executable and/or source?

[kenjennings]

EVERYTHING happens during the first scan line of a display list instruction. ( In this case this is the instruction that belongs to the first scan line after the display list instruction with the DLI) The stuff that happens includes the DMA for the Display list instruction, the DMA for the screen memory, and (if applicable) the DMA for the character set. Less happens on other lines of the display list instruction.

 

I did a demo program that banged on COLBAK continuously on a screen of blank line instructions. Every 8 lines the colors were offfset a bit and then I realized what I was looking at.

[Bryan]

Can you post an executable and/or source?

 

I'll do that if there isn't a simple answer I've overlooked and if it does the same thing on real hardware.

 

EVERYTHING happens during the first scan line of a display list instruction.

 

These are mode F lines, so every line is exactly the same and includes an instruction fetch.

[phaeron]

There's a one cycle variance in where the CPU pulls out of a WSYNC wait depending on whether there was a DMA cycle at the start of the wait. Essentially, the CPU can get one cycle of the next instruction in before the wait, but only if it isn't taken by DMA. A mode F scan line has DMA cycle every other cycle, so this is guaranteed to happen if your STA WSYNC lands anywhere in the middle of the first scanline. This is why if you're doing exact cycle timing you usually need two STA WSYNCs in a row to ensure that you're precisely lined up with the scanline timing. INC WSYNC will also do it by always burning the extra cycle, but it gives you one cycle less margin.

[Bryan]

I have a simple mode F screen where I trigger a DLI a few lines in. The main code stays in an infinite loop. In the DLI, I do this:

	pha			;Push A
	txa
	pha
	tya
	pha

	sta WSYNC
;--load some colors here--

	ldy #16
dli_lp
	sta WSYNC		;Wait until end of line
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	stx COLPF2
	nop
	nop
	sta COLPF2
	dey
	bpl dli_lp

I tried stripping the program down to just this and now it appears to line up and draw a proper rectangle. I'm sure it wasn't doing that last night but obviously I have more research to do.

[Bryan]

One other question...

 

If I want to hit a certain cycle and a refresh is in the way (high-DMA modes), I can only affect it by HSCROLing half a byte, meaning I can then hit the cycle I want, but I affect the pixel/byte alignment (and DMA length) of that line.

 

I'm trying to decide if my background coloring method is worth the overhead.

[Rybags]

Yep, you have to scroll by 2 or 3 colour-clocks. 1 CC, the DMA stays the same. 4 CC, it reverts back to where it was though you still have that "indentation" of the graphics DMA and truncation at the finish for high HSCROL values.

 

"Worth the overhead" - one possible problem is such tricks mightn't be emulated properly in older emualators though I see no reason not to be using recent versions of the common ones.

[Bryan]

Thanks. Personally, I mostly worry about how it runs on real hardware and how it looks on a CRT. There are too many variables nowadays to optimize for every situation.

[Heaven/TQA]

I Care about Altirra and real HW. If it runs ok on Atari800macx than fine.... But no checks there. And Atari800win is legacy for me.

[Heaven/TQA]

Bryan and all...

 

Why are you using pha etc and pla except Dli is running from ROM?

 

I am using

 

Sta rega+1

Stx regx+1

...

Rega lda #0

Regx ldx #0

Rti

 

To save some overhead?

[Bryan]

Bryan and all...

 

Why are you using pha etc and pla except Dli is running from ROM?

Agreed. This is just a test for mid-screen changes so it's not nearly optimized yet. I was mainly seeing if I could make the shapes I needed. Now I'm re-thinking it. I would love some control over refresh for critical parts of the screen... oh well.