| |
Conrad
Registered: Nov 2006
Posts: 847 |
Controlling that colour change bug thing
Would any hardware gurus/coders care to explain what causes this bug to appear and is it possible to control its visibility, code wise?
Thanks. |
|
| |
tlr
Registered: Sep 2003
Posts: 1787 |
The way to control it is stable rasters...
On 856x based machines (i.e newer C64s and C128s) when writing a color register ($D020-$D02E) currently being used to display graphics a grey dot (color 15) appears at the first pixel of the cycle.
The reason for the grey dot appears to be a glitch in the color register bank itself, not in the mapping from color enables to actual 4-bit color. This effect is thus independent of the previous color register displayed.
It has been reported that the dot can be smaller than 1 pixel, and that it does not show or randomly appears on some machines. |
| |
Conrad
Registered: Nov 2006
Posts: 847 |
Thanks tlr for explaining that.
Control it by stable rasters? Well sure, that would help stop it from jittering :) but I kinda meant how to switch the grey dot on/off, i.e. to do with the glitch in the colour register bank as you mentioned. |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
The way to avoid the dots is to only update a color register in a cycle where that register is _not_ used to display the first pixel.
The way to force them is to do the exact opposite, only update a color register at a cycle where it _is_ used to display the first pixel.
|
| |
WVL
Registered: Mar 2002
Posts: 895 |
Best controlled use of the grey-pixel ever is in Risen From Oblivion, the VIC part. Xbow made a scroller using the light grey pixel bug. Pretty neat, except it doesnt work on my c128 at all.. Pixels are very unsteady and are constantly flickering.
Anyway, I think the whole grey pixel thing is very annoying and it's the biggest reason not to use a c64 with a newer VIC.
BTW, in your picture the vertical lines have gaps because of the badlines. |
| |
Conrad
Registered: Nov 2006
Posts: 847 |
WVL: On my C64C the grey dots only appear occasionally. When switching the machine off/on, those dots are either visible or gone. It seems bizarre to me why this happens and just wondered if those dots can be forced to be visible or hidden via some machine code, but in any case I'll try what tlr mentioned. I agree it is annoying to see these grey dots in demos that make use of $d020-$d02e for raster colour splits and stuff similar to that, but I plan to use them for something useful (even it it's pointless for people with an old VIC or emulator ;)) |
| |
Ninja
Registered: Jan 2002
Posts: 411 |
I have one C128 where those dots are usually(!) stable when the machine is cold. After some minutes they start flickering and sometimes they disappear completely after some more time. All too random for my taste... |
| |
TPM
Registered: Jan 2004
Posts: 110 |
Very annoying indeed..
On my c64 the dots/stripes appeared and were increasingly present more and more when the VIC got warm, usually after a couple of hours or so. Cool down the c64 for an hour and it was okay again. |
| |
Ed
Registered: May 2004
Posts: 173 |
Grey dots for the emulator would be nice!
Eventhough they could be a pain in the arse (Microtop's Starion demos) or beautiful (Wizball loading screen) I never experienced them as unstable. Well, not more unstable than a unstable rasterbar for example.
|
| |
Martin Piper
Registered: Nov 2007
Posts: 718 |
It is bus timing bug in the VIC hardware where it can output the wrong signal and the wrong time for a very short amount of time. It depends on the exact hardware version of the VIC, how hot it is etc.
|
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quote: Grey dots for the emulator would be nice!
Eventhough they could be a pain in the arse (Microtop's Starion demos) or beautiful (Wizball loading screen) I never experienced them as unstable. Well, not more unstable than a unstable rasterbar for example.
Grey dots have been emulated in x64sc since r22786.
Note that the grey dot is not the only thing that differs color reg-wise between a 656x and a 856x.
On a 656x (the one without the grey dots) color changes appear one pixel later than on a 856x, i.e one pixel into the cycle.
To avoid differences between the machines you should never change a color register when it's visible in the first pixel. |
| |
Skoe
Account closed
Registered: Jan 2008
Posts: 34 |
tlr, I don't know how well the reason for the grey dot effect is known already. I'm sorry if I repeat known facts here.
Segher is working on reversing the VIC-II photos. We discussed about how the color registers work today.
I can't explain the exact technical background, would be full of mistakes if I did it with my words :) As far as I understood, the registers are only simple latches made of two inverters. When the register is written, the (VIC internal) data bus is connected to the first gate.
Apparently the address decoding and R/W stuff seems to be faster then the data bus drivers. There for an undriven databus (all 1s) is put to the latch. After a while the data bus gets its final state and the right color appears.
With this explanation we had the idea to delay the CS line a bit to make it slower than the data bus. I brutally took a 10 nF capacitor (don't try this at home!) and really: The grey dots can be made disappear. If I put the capacitor there or remove it while the C64 is running I can switch the dots on and off easily.
Segher will try to write it down more detailed or possibly make a drawing later.
|
| |
Devia
Registered: Oct 2004
Posts: 401 |
interresting.. |
| |
Mr. SID
Registered: Jan 2003
Posts: 424 |
Awesome! |
| |
Krill
Registered: Apr 2002
Posts: 2968 |
There's no way to turn it off by software. |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quote: tlr, I don't know how well the reason for the grey dot effect is known already. I'm sorry if I repeat known facts here.
Segher is working on reversing the VIC-II photos. We discussed about how the color registers work today.
I can't explain the exact technical background, would be full of mistakes if I did it with my words :) As far as I understood, the registers are only simple latches made of two inverters. When the register is written, the (VIC internal) data bus is connected to the first gate.
Apparently the address decoding and R/W stuff seems to be faster then the data bus drivers. There for an undriven databus (all 1s) is put to the latch. After a while the data bus gets its final state and the right color appears.
With this explanation we had the idea to delay the CS line a bit to make it slower than the data bus. I brutally took a 10 nF capacitor (don't try this at home!) and really: The grey dots can be made disappear. If I put the capacitor there or remove it while the C64 is running I can switch the dots on and off easily.
Segher will try to write it down more detailed or possibly make a drawing later.
The exact implementation on the silicon is not currently known AFAIK.
To do the VIC-II improvements in x64sc we've written numerous test programs.
For my parts of the implementation I've then inferred as much as possible of the (non-known)
behaviour using the results on different chips combined with my electronics expertise.
I've focused on the pixel generation (graphics/sprites/border) parts and differences between the chips.
Reverse-engineered parts of the 656xR* and 856xR* chips will obviously be very helpful in improving emulation further.
Although to get much further temperature and process variation will eventually have to find it's way into the equation... ;) |
| |
Skoe
Account closed
Registered: Jan 2008
Posts: 34 |
Quote:Reverse-engineered parts of the 656xR* and 856xR* chips will obviously be very helpful in improving emulation further.
I wanted to ask him to have a closer look at the sprite pointers. groepaz told me that there are still open questions. Can somebody explain what exactly can be done with it and what is not know about the implementation? (Possibly it's written somewhere here in the forum, mhh.)
Quote:There's no way to turn it off by software.
No, since it is a glitch in the hardware. The only thing one can do is to try to avoid the situation as somebody has written above already.
|
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quoting SkoeQuote:Reverse-engineered parts of the 656xR* and 856xR* chips will obviously be very helpful in improving emulation further.
I wanted to ask him to have a closer look at the sprite pointers. groepaz told me that there are still open questions. Can somebody explain what exactly can be done with it and what is not know about the implementation? (Possibly it's written somewhere here in the forum, mhh.)
I'm not sure what he ment. He'll have to elaborate himself.
I would like a full trace of the chips if possible. :)
Feel free to discuss this on #vice-dev @freenode.net.
One thing I found out during analysis is that MCBASE is not being reset at the start of sprite DMA, it is reset at the _end_ of sprite DMA.
Now you may ask if that even matters...
Actually it does on 656x because MCBASE is not reset at power up.
On my 6569R3 it seems to be 63 (all ones) mostly. On the 8565R2's I've gotten reports from it is 0.
This means the sprites will glitch the first time a sprite is enabled after power up, i.e one frame only, and only after a power cycle. ;)
In Box Check "Sprite A" I had to include a MCBASE reset, otherwise it would fail on a 6569 if run as the first program after a power on. |
| |
Zer0-X
Account closed
Registered: Aug 2008
Posts: 78 |
Wouldn't this be fitting for April 1st?
Grounding VIC /CS line with 10nF cap didn't work for here, C64C wouldn't start. But 1nF cap works ok. No stripes.
I've only been running few demos so far but I've yet to see a VSP effect crash this C64C. And many of those used to crash this fast'n'quick...
Humm... |
| |
JAC
Registered: Aug 2002
Posts: 57 |
Quote: Very annoying indeed..
On my c64 the dots/stripes appeared and were increasingly present more and more when the VIC got warm, usually after a couple of hours or so. Cool down the c64 for an hour and it was okay again.
Then how about putting a sprite above the pixel and use collision registers to count and implement a CPU temperature display for C64 :-) |
| |
Mr. SID
Registered: Jan 2003
Posts: 424 |
VIC doesn't think that those pixels are set, so it will not report a collision... |
| |
ready.
Registered: Feb 2003
Posts: 441 |
CPU temperature monitoring was done already using adresses $00 or $01, can't remember exaclty. |
| |
yago
Registered: May 2002
Posts: 333 |
Measuring CPU tempereature is already possible.
Its done via $00/$01.
Set up the DDR ($00) as output for unused (upper) bits, then to input, and measure the Time it takes to discharge the bits at $01.
Repeat this often, and you will see clear difference between cold and hot CPU.
|
| |
JAC
Registered: Aug 2002
Posts: 57 |
That's the cool thing about coder forums. Even if you post complete nonsense or jokes you get a proper answer stating it has already been implemented :-) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11350 |
Quote:Measuring CPU tempereature is already possible.
well, not at all. you can read some value which somehow changes over time, in a completely non predictable way. this is far away from "measuring temperature". |
