| |
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 :-) |
|
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
http://www.zimmers.net/cbmpics/cbm/c64/vic-ii.txt |
| |
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 :) |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Yes, i restricted my answer to $d021 for the sake of simplicity :)
Just wanted to get the point across that when seen from a software perspective, you can simply assume VIC and CPU being perfectly clock-aligned on whole cycles. |
| |
Mace
Registered: May 2002
Posts: 1799 |
The reason I asked was that I am doing some explanatory graphic representations for Codebase64.
There's no need to make it pixelperfect for all registers, but thanks for mentioning the splittest. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
Quote: 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 :)
Interesting. I've never seen a color change at a non char boundary, how can this be provoked exactly? |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quoting OswaldInteresting. I've never seen a color change at a non char boundary, how can this be provoked exactly?
For example split $d020 or $d021. On a 6569 this will consistently be one pixel late. On a 8565 that first pixel will instead be either a "grey dot" _or_ the correct color. You can never get portable/reliable behaviour if the actual split point is visible. |
| |
algorithm
Registered: May 2002
Posts: 705 |
Quote: Quoting OswaldInteresting. I've never seen a color change at a non char boundary, how can this be provoked exactly?
For example split $d020 or $d021. On a 6569 this will consistently be one pixel late. On a 8565 that first pixel will instead be either a "grey dot" _or_ the correct color. You can never get portable/reliable behaviour if the actual split point is visible.
Yes, this is what i had noticed when i was experimenting in the MUCSU/Split method based color splitting. (seems to affect sprite color changes as well (d025/d026) Color update seem to be a pixel too late (or grey dot) - luckily it did not affect the overall quality of the image conversion too much |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
ah the grey snow thingie. are those exact hires pixel grey dots? to me it always seemed a bit analogue / vague, but that might be cause by that on a real CRT hires pixels are always a smear, compared to modern displays. and while we're at it, on some VICs and Monitors you can even see the character boundaries vaguely, on a single color screen, the voltage swims a lil bit. |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
They need not be exactly one pixel but in practice I haven't encountered anything different from it (see: https://sourceforge.net/p/vice-emu/code/HEAD/tree/testprogs/VIC..) For the sake of emulation I choose it to be exactly one pixel.
The character boundary fluctuations are AEC related. That's groepaz´ domain. |
| |
algorithm
Registered: May 2002
Posts: 705 |
Micro64 emulates these character boundaries vertical and horizontal and a lot more besides. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:he character boundary fluctuations are AEC related. That's groepaz´ domain.
i think it was zero-x who provided this nice illustration. (its not only AEC :=P) |
| |
Mace
Registered: May 2002
Posts: 1799 |
Nice one, thanks. |
