| |
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....
|
| |
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. |
| Previous - 1 | 2 | 3 - Next |
