| |
dyme
Registered: Nov 2018
Posts: 14 |
Bright pixels beside sprite in lower border
Hi all!
I dug out my real C64 to test a new PSU and revisited my demo Hello World. In the transition screen a bug showed up: on the left side of the sprites containing the READY.-prompt, just as they enter the lower border, a bright line appears.
This only happens on real hardware, VICE and Ultimate64 do not emulate this behaviour. It also showed up on the party hardware, which I now remember irked me no end (lesson learned: always test on the real thing...)
I've seen it on two other machines as well, so it's reproducible.
What is that effect, and how to counteract it?
I probably could move the sprites 1 pixel left and even have the first pixel column set to mask that line... but if it is so common it feels strange that this bug doesn't come up more often in discussion about border sprites. |
|
| |
tlr
Registered: Sep 2003
Posts: 1714 |
Quote: Hi all!
I dug out my real C64 to test a new PSU and revisited my demo Hello World. In the transition screen a bug showed up: on the left side of the sprites containing the READY.-prompt, just as they enter the lower border, a bright line appears.
This only happens on real hardware, VICE and Ultimate64 do not emulate this behaviour. It also showed up on the party hardware, which I now remember irked me no end (lesson learned: always test on the real thing...)
I've seen it on two other machines as well, so it's reproducible.
What is that effect, and how to counteract it?
I probably could move the sprites 1 pixel left and even have the first pixel column set to mask that line... but if it is so common it feels strange that this bug doesn't come up more often in discussion about border sprites.
Cool! Can we have a clip of it happening? |
| |
trident
Registered: May 2002
Posts: 74 |
It looks like the VIC gray dot bug, which is triggered by writing to a visible color register on the new VIC chip. In this case, I would assume that you are writing to $d021 at the exact same cycle that the border ends, which results in a color $f pixel at that location.
In newer Vice versions it is possible to enable emulation of this bug by enabling the 8565 VIC chip in Settings -> Machine -> Model. It is visible when I run the demo in Vice 3.7 here. |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
Quoting tridentIt looks like the VIC gray dot bug, which is triggered by writing to a visible color register on the new VIC chip. In this case, I would assume that you are writing to $d021 at the exact same cycle that the border ends, which results in a color $f pixel at that location.
In newer Vice versions it is possible to enable emulation of this bug by enabling the 8565 VIC chip in Settings -> Machine -> Model. It is visible when I run the demo in Vice 3.7 here.
Didn't see that at first, good eye! Was looking for a white horizontal line. :) There is also an occasional grey dot in the right border.
If you run the demo with 6569 emulation you will one extra pixel in the top left corner at the same point in the demo instead. This is because color changes are 1 pixel delayed on the 6569 compared to the 8565. |
| |
dyme
Registered: Nov 2018
Posts: 14 |
Thanks trident, you're of course right, it's easily seen on newer VICE versions, I'll have to get used to the "new" GTK-gui after all.
Puh, this really shows how much there is to know about all the different machine versions out there.
So the solution would be to ensure the screen color change is either a few cycles earlier in the border or adjust the end of the screen via $D011 to be on a different line than any color change?
Screengrab of a relevant frame from scenesat: https://imgur.com/a/kxGai0C |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
Quoting dymeSo the solution would be to ensure the screen color change is either a few cycles earlier in the border or adjust the end of the screen via $D011 to be on a different line than any color change?
Like trident writes, as long as the color register being written isn't currently being displayed you'll be fine. Note that when stepping through the frames, sometimes a line appears in the right border instead. This suggests you are writing $d020 when it is displayed.
Not sure what you mean by the $d011 part. |
| |
dyme
Registered: Nov 2018
Posts: 14 |
I got confused by "exact same cycle the border ends", I thought it had something to do with the horizontal borders...
I think now I got the gist of the problem, already discussed here: Controlling that colour change bug thing
TLDR: It seems whenever you write to a VIC-II color register, that register behaves as if it contains $f for the duration of the first pixel of that cycle.
Although the magnitude of the effect is reported to vary even within different VIC-II models and temperatures
I wonder how all these raster-splits were done that I remember, because they sure must have run into the same problem. But maybe I had a different VIC model back then. |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
Quoting dymeI wonder how all these raster-splits were done that I remember, because they sure must have run into the same problem. But maybe I had a different VIC model back then.
As I hinted above, on the 6569 the color change will appear one pixel late instead of producing a grey dot. Emulating 8565 vs 6569 can be switched on the fly in vice. |
| |
trident
Registered: May 2002
Posts: 74 |
@tlr: very cool, I didn't know that the 6569 would delay the color change by one pixel - very visible, now that you mention it! |
