| |
ChristopherJam
Registered: Aug 2004
Posts: 1381 |
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
|
|
... 57 posts hidden. Click here to view all posts....
|
| |
HCL
Registered: Feb 2003
Posts: 717 |
..so noone wants to talk FLI and unexpected linecrunch anymore?! ..and worst thing is, everyone will blame me and my mis-post for it :P |
| |
Peacemaker
Registered: Sep 2004
Posts: 243 |
hcl, you destroy the discussion ;) |
| |
lft
Registered: Jul 2007
Posts: 369 |
Well, back on topic then. Here's a neat idea:
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.
Use e.g. linecrunch to get started at the top of the screen. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1381 |
Quoting lftIf 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
|
| |
HCL
Registered: Feb 2003
Posts: 717 |
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.. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1381 |
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? |
| |
Digger
Registered: Mar 2005
Posts: 421 |
Is it possible to somehow delay Color RAM reads vs Screen RAM reads with this? Or does CR + SR read always come in sync? |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1381 |
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. |
| |
Oswald
Registered: Apr 2002
Posts: 5026 |
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 ? |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1381 |
Quoting Oswaldthats 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 |
