Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in 
CSDb User Forums


Forums > C64 Coding > Controlling that colour change bug thing
2010-08-13 19:36
Conrad
Account closed

Registered: Nov 2006
Posts: 715
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....
 
2010-09-03 15:45
tlr

Registered: Sep 2003
Posts: 1246
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... ;)
2010-09-03 19:44
Skoe
Account closed

Registered: Jan 2008
Posts: 33
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.

2010-09-03 19:59
tlr

Registered: Sep 2003
Posts: 1246
Quoting Skoe
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.)

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.
2012-04-01 12:34
Zer0-X

Registered: Aug 2008
Posts: 77
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...
2012-04-23 21:56
JAC

Registered: Aug 2002
Posts: 56
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 :-)
2012-04-24 06:05
Mr. SID

Registered: Jan 2003
Posts: 369
VIC doesn't think that those pixels are set, so it will not report a collision...
2012-04-24 07:49
ready.

Registered: Feb 2003
Posts: 438
CPU temperature monitoring was done already using adresses $00 or $01, can't remember exaclty.
2012-04-24 07:53
yago

Registered: May 2002
Posts: 331
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.
2012-04-24 08:36
JAC

Registered: Aug 2002
Posts: 56
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 :-)
2012-04-24 14:23
Groepaz

Registered: Dec 2001
Posts: 9100
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
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
DocSnyder
Mythus/Delysid
O'Dog
Radd Maxx/SWIM
Hydrogen/Glance
FunFun/Triangle
Grue
Alakran_64
Guests online: 96
Top Demos
1 Uncensored  (9.7)
2 Unboxed  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.7)
5 Comaland 100%  (9.6)
6 Lunatico  (9.6)
7 The Shores of Reflec..  (9.5)
8 Rivalry  (9.5)
9 C=Bit 18  (9.5)
10 X Marks the Spot  (9.5)
Top onefile Demos
1 Instinct  (9.6)
2 Crystal Gazer  (9.6)
3 The Tuneful Eight [u..  (9.5)
4 Dawnfall V1.1  (9.5)
5 Smile to the Sky  (9.5)
6 Space Demo  (9.5)
7 Field Sort  (9.5)
8 Je t'aime mon Monstre  (9.5)
9 The Tuneful Eight (U..  (9.5)
10 Daah, Those Acid Pil..  (9.5)
Top Groups
1 Oxyron  (9.5)
2 Fossil  (9.4)
3 PriorArt  (9.4)
4 Booze Design  (9.4)
5 Arsenic  (9.4)
Top Organizers
1 cTrix  (10)
2 Burglar  (9.9)
3 Sixx  (9.9)
4 Taper  (9.8)
5 hedning  (9.8)

Home - Disclaimer
Copyright © No Name 2001-2019
Page generated in: 0.044 sec.