| |
Mace
Registered: May 2002
Posts: 1799 |
Cycles vs raster X-position
I'm trying to visualise the cycles aligned with the X-position of the raster (not a bad line).
How many pixels does the X-position shift in one cycle?
I always assumed it was 8, but I can't find any writing on that.
And what cycle aligns with, say, the left side of the screen? (I mean the 'dark blue' area of the standard C64 boot screen, to make things clear)
Let's assume the shift is 8 pixels and the border is 48 pixels wide, you'd say it's cycle no. 6. Correct?
I have many doubts about the above, but I'm writing it anyway because then we have something to talk about and refer to :-) |
|
... 11 posts hidden. Click here to view all posts....
|
| |
Mixer
Registered: Apr 2008
Posts: 452 |
I hope I understand the question correctly... I believe the VIC article https://sh.scs-trc.net/vic/ - answers to the question of how the cycles align with pixels.
Unless I too am mistaken it is 8 pixels per cycle. Exactly what happens on each cycle (bus stuff) is another matter. |
| |
Mace
Registered: May 2002
Posts: 1799 |
Oh, hey, I came across this but in all that incomprehensible stuff I seem to have missed some crucial stuff about the cycles.
Thanks! |
| |
Burglar
Registered: Dec 2004
Posts: 1101 |
http://www.linusakesson.net/programming/rasterpaper/rasterpaper.. |
| |
Mace
Registered: May 2002
Posts: 1799 |
Burglar, interesting. I kind of get this but some description, explanation or manual would be nice. |
| |
Burglar
Registered: Dec 2004
Posts: 1101 |
watch http://www.linusakesson.net/programming/poems-for-bugs/index.php |
| |
Mace
Registered: May 2002
Posts: 1799 |
I meant this:
http://www.linusakesson.net/programming/vic-timing/victiming.pdf |
| |
Mace
Registered: May 2002
Posts: 1799 |
From this:
6569, no Bad Line, no sprites (abbreviated):
Cycl-# 6 1 1 1 1 1 1 1 1 1 1 |5 5 5 5 5 5 5 6 6 6 6
3 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 |3 4 5 6 7 8 9 0 1 2 3 1
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _| _ _ _ _ _ _ _ _ _ _ _ _
�0 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |_ _ _ _ _ _ _ _ _ _ _ _
__ |
IRQ ______________________________________|________________________
________________________________________|________________________
BA |
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _| _ _ _ _ _ _ _ _ _ _ _ _
AEC _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |_ _ _ _ _ _ _ _ _ _ _ _
|
VIC i 3 i 4 i 5 i 6 i 7 i r r r r r g g g g |g g g i i 0 i 1 i 2 i 3
6510 x x x x x x x x x x x x x x x x x x x x| x x x x x x x x x x x x
|
Graph. |===========0102030|7383940=========
|
X coo. \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\|\\\\\\\\\\\\\\\\\\\\\\\\
1111111111111111111111111110000000000000|111111111111111111111111
89999aaaabbbbccccddddeeeeff0000111122223|344445555666677778888999
c048c048c048c048c048c048c04048c048c048c0|c048c048c048c048c048c048
So, is it a correct assumption that there's a 4 pixel difference between a cycle and the characters? In other words, the CPU goes from cycle 16 to cycle 17 halfway character 01? |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
From the VIC article:
Quote:ΦIN This is the feed for the pixel clock of 8.18 MHz (NTSC) or 7.88 MHz
(PAL) that is generated from the crystal frequency. Eight pixels
are displayed per bus clock cycle (Φ2).
So 1 cycle = 1 character.
In the graph you posted, the left border ends at cycle 16, so at this very cycle, the first character is displayed.
A cycle is shared by VIC and the CPU with regard to bus access, such that VIC reads memory at a high->low edge, and the CPU reads or writes at a low->high edge. This means that the bus and the RAM operate at an effective clock of 2 MHz.
You could say the CPU lags behind VIC by half a cycle, but this doesn't mean anything when seen from a software-only perspective. They still operate at one step per full cycle each. E.g., when setting the background colour ($d021), the change will always be at a multiple of 8 pixels with regard to changes of the beam y-position ($d012). |
| |
Mace
Registered: May 2002
Posts: 1799 |
 |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:E.g., when setting the background colour ($d021), the change will always be at a multiple of 8 pixels with regard to changes of the beam y-position ($d012).
at this point i want to mention the "splittests" directory in the vice testprograms repository. because all these color registers have a slightly different delay, and do NOT always line up with character boundaries :) |
| Previous - 1 | 2 | 3 - Next |
