| |
Monte Carlos
Registered: Jun 2004
Posts: 350 |
New VIC grey flickering dots with rastersplits
Because i'm just considering some rastersplits for an upcoming part, i wonder if there has ever been technical analysis which difference in new and old vic causes these snowy pixels?
Or has this always been accepted as a non avoidable side effect? |
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11092 |
i dont understand the question. every (*) write to a color register will cause a grey (color $f) dot on the HMOS chips.
(*) not entirely correct because on some chips the effect will vanish depending on temperature |
| |
Smasher
Registered: Feb 2003
Posts: 512 |
Monte Carlos, I don't know if you mean this, but at last X my part with splits started with grey dots on the black screen: https://youtu.be/7aHRZT9kaUE?t=139
now I know the demo had 3286 known bugs, but that one was new and unexpected as we tested it on different machines and that never happened. If you know the reason and the solution we'll credit you in our next demo :) |
| |
Axis/Oxyron
Registered: Apr 2007
Posts: 91 |
I fear there is no solution. Except of not changing colors in the visible area of the raster-beam. In other words, no color-splits. Ofcourse you hit the worst-case scenario, showing them in a big area on a black screen. |
| |
algorithm
Registered: May 2002
Posts: 702 |
I guess if you really want to minimise it, then try and ensure there are no writes if next color is the same as previous. (or have a visual check at beginning - e.g "if you see gray dots, turn off and back on again".
On some C64's I guess the gray dot bug will be there all the time, but I think once the gray dot has disappeared on power cycle (or due to temperature) it will not come back on during that power cycle? Is that correct? |
| |
tlr
Registered: Sep 2003
Posts: 1702 |
Quote: I fear there is no solution. Except of not changing colors in the visible area of the raster-beam. In other words, no color-splits. Ofcourse you hit the worst-case scenario, showing them in a big area on a black screen.
To be more precise: the dot will only show when changing a color register that is currently being displayed. You can always mask the change by having the VIC-II show a different color source in that spot, e.g a piece of foreground graphics or a different ECM background, etc... |
| |
soci
Registered: Sep 2003
Posts: 473 |
Quote: I guess if you really want to minimise it, then try and ensure there are no writes if next color is the same as previous. (or have a visual check at beginning - e.g "if you see gray dots, turn off and back on again".
On some C64's I guess the gray dot bug will be there all the time, but I think once the gray dot has disappeared on power cycle (or due to temperature) it will not come back on during that power cycle? Is that correct?
Yes, that's how there were no grey dots shown for Epic Comeback on our C64C compo machine.
The IDEDOS on boot cartridge self test contains INC $D020, STY $D020 so it's easy to see if another power cycle is needed or not. |
| |
Zer0-X
Registered: Aug 2008
Posts: 78 |
I'll blame it on the custom, faster, logic on the late model board vs the old board logic, letting VIC-II on the bus a wee bit earlier.
There's a simple fix (IIRC discussed on the forums before), but it will be argued if it could cause other problems. |
| |
Monte Carlos
Registered: Jun 2004
Posts: 350 |
Thank you, i try to circumvent the issue by using some sprites to cover the splits. Think i have enough rastertime left.
Yes, rasterdemos should indeed be tested on new vic before the presentation to avoid surprises.
Still, i have been lucky as i did not do so much rastersplits. |
| |
Devia
Registered: Oct 2004
Posts: 401 |
Quote: I'll blame it on the custom, faster, logic on the late model board vs the old board logic, letting VIC-II on the bus a wee bit earlier.
There's a simple fix (IIRC discussed on the forums before), but it will be argued if it could cause other problems.
Can't seem to find any mention of that, do you care to elaborate?
I only seem to remember messing with the XTal In or /RESET pins could toggle the grey dots on/off, although I suspect that method will likely cause other problems.
Also, touching øDOT appears in some cases to "reduce" the occurence of the dots.
@algorithm: No, once they have faded away, they will come back in my experience. It's is my experience that the occurence of the grey dots fades in and out at a very low frequency.. something like 30-40 mins duty cycle. |
| |
Zer0-X
Registered: Aug 2008
Posts: 78 |
http://csdb.dk/forums/?roomid=11&topicid=78186&showallposts=1 for the old discussion.
And indeed, messing with the crystal / clock generator chip does affect the dots. You can also use freeze-spray on the VIC-II to make the effect fade in and out. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11092 |
or just spray it on your balls for a similar effect |
| |
The Phantom
Registered: Jan 2004
Posts: 360 |
I used put LDA #$00 and STA $0646, STA $d020 and STA $d021 at the very start of my code back in the day to stop the dots.
I don't know if that still works, just thought it was worth a mention. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11092 |
it never worked, that has zero effect on those dots |
| |
enthusi
Registered: May 2004
Posts: 674 |
Eight years ago some people thought it was stupid to consider their emulation even:
Emusuxx0r+ |
| |
TWW
Registered: Jul 2009
Posts: 541 |
Quote: or just spray it on your balls for a similar effect
Assuming one has balls |
| |
WVL
Registered: Mar 2002
Posts: 885 |
Quote: Eight years ago some people thought it was stupid to consider their emulation even:
Emusuxx0r+
That was me :-) I still don't like those grey Dots!! |
