| |
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. |
|
... 14 posts hidden. Click here to view all posts....
|
| |
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: 11360 |
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". |
| Previous - 1 | 2 | 3 - Next |
