[CSDb] - User Forums - Unexpected linecrunch

You are not logged in - nap

CSDb User Forums

Forums > C64 Coding > Unexpected linecrunch

2016-09-06 08:58

ChristopherJam

Registered: Aug 2004
Posts: 1408

Unexpected linecrunch

I'm sure in the past I've displayed full screen FLI just by writing a new value to $d011 every 23 cycles, and using some of the intervening time to update $d018 (ie, writing to $d011 on what vic artikel refers to as cycle 14).
However, if I have sprites zero to five enabled, and am only writing d011 every second line, it appears that I need to perform the first $d011 write for new char rows at least one cycle earlier, lest I get a linecrunch.

Any idea what's going on here?

(every two lines, I'm running something like this:

	lda#efy0+ 71:sta $d007
	lda#d18v0
	ldx#$38+1
	ldy#0
	sta $d018
	sty VM0+$3f8:iny
	sty VM0+$3f9:iny
	sty VM0+$3fa:iny
	sty VM0+$3fb:iny
	sty VM0+$3fc:iny
	sty VM0+$3fd:nop
	stx $d011

Also: not sure if it's relevant, but I stabilise the interrupt by forcing a DMA one and a half lines before the first such block of code is run, ie the first block is preceded by

	sta $d011 ; trigger badline just before effct starts; this one's just to stabilise
	nop:nop:nop:nop:nop:nop  ;extra nops because there's no sprite DMA at the end of the above DMA

... 60 posts hidden. Click here to view all posts....

2016-09-18 10:36

ChristopherJam

Registered: Aug 2004
Posts: 1408

Quoting lft

If you want FLI on every other line, and consistent timing for all line pairs, then my suggestion is to do FLI on the "other" lines, i.e. when RC is 1, 3, 5 and 7. Doing FLI on line 7 will then also trigger a repeat-row effect, so the subsequent line 0 will be in display mode, with VCBASE updated for the next row but with the old row contents still in the row buffer..

Ah, nice! If that works, I can free up a couple of cycles for a 7th sprite

2016-09-19 08:16

HCL

Registered: Feb 2003
Posts: 727

Quote:

when RC is 1, 3, 5 and 7.

Yeah, that's how i usualy end up doing it.. and i guess most others also.

Another way is of course to trigger badline on line 2, 4, and 6. ..and on line 6 you directly store $d011 (and $d018?) to trigger badline on line 0 also (common 4x4-timing-style). Non-symetric code, but sometimes a good choice..

2016-09-22 04:27

ChristopherJam

Registered: Aug 2004
Posts: 1408

I've been studying the diagram Lft posted, and playing with a little sample program, and have a nice example of enabling a badline at around cycle 55 of line 7 in order to start a char row repetition after some normal display lines (thinking about doing a DMA every 3 lines for Reasons).

But it got me thinking - is there any practical reason why you might want to start a badline at the start of line 7, but then abort it in the three cycles before cycle 58? And could you even do that if you wanted to? (I'm not clear on how the cycle stealing interacts..)

Theoretically that would put you into idle mode, setting you up for an VSP immediately after a badline. I guess you might want to scroll an area directly below a FLI image with only a single black line of pixels between then?

2016-09-24 22:22

Digger

Registered: Mar 2005
Posts: 427

Is it possible to somehow delay Color RAM reads vs Screen RAM reads with this? Or does CR + SR read always come in sync?

2016-09-25 06:35

ChristopherJam

Registered: Aug 2004
Posts: 1408

Quote: Is it possible to somehow delay Color RAM reads vs Screen RAM reads with this? Or does CR + SR read always come in sync?

Doubtful I'm afraid. They happen on exactly the same cycle (there's a 12 bit wide data bus on the chip), so the reads aren't even interleaved.

2016-09-25 06:54

Oswald

Registered: Apr 2002
Posts: 5086

thats a topic I've never thought of, how does the VIC manage to adress screen and color mem at the SAME time ? lower adress lines doubled to d800 ?

2016-09-25 08:29

ChristopherJam

Registered: Aug 2004
Posts: 1408

Quoting Oswald

thats a topic I've never thought of, how does the VIC manage to adress screen and color mem at the SAME time ? lower address lines doubled to d800 ?

Pretty much, though the details are a bit messy.

Main address bus is multiplexed low byte/high byte, so the same latch that holds the low 8 bits for ROM access also feeds d800, and address bits 8 to 11 leaving VIC are also duplicated non-multiplexed, for reading from d800 and charrom; at least if I'm reading the circuit diagram from the back of the c64 PRG correctly. The D800 chip only has 10 address line inputs, of course.

Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 - Next

Refresh

Subscribe to this thread: