| |
Mantiz
Account closed
Registered: Apr 2006
Posts: 36 |
VICE, difference between 6569 and 8565
Howdy Hackers!
Just found my own half finished projects from 2008 on an old drive and decided to have a look at them and downloaded latest VICE (3.5 (GTK3 3.24.24, GLib 2.66.3)), since VICE was what I used back then.
One part I made contains a few raster splits which looked more bugged than I remembered, in fact it looked complete garbage with a vertical grey line before every split which I did not remember.
After a bit of investigation, this seemed to depend on the VIC setting in the emulator. It seems to show a grey pixel before every raster change if using 8565 VIC-II. I tried Hoxs and everything looks good there but I do not know what settings it uses and which to trust. One reason I did not get around at finishing my own stuff back then was exactly that I did not have access to a real C64 to try it on, and I was convinced the emulator did not show everything so I wanted to be sure. Then I eventually forgot about it all.
My question is that if this is a known VICE behaviour or just anerror on my PC? I checked the demo Raster Crime by Cyberbrain and sure this issue very evident there too.
Am I missing something important or is this a known issue?
Attached are two screenshots explaining what I am seeing (apologies for shitty screenshots).
 |
|
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
This is how these chip behave in the real deal, so VICE is correct. This is called ”the grey dot bug” and occurs if you set a color register when it’s displayed. You can not avoid it. |
| |
Raistlin
Registered: Mar 2007
Posts: 552 |
Yeah, I actually never knew about this issue until I "returned" to the scene in 2018. I never saw it on my old breadbin .. but apparently it happened on all the C64c's.
As you see, even where you don't actually change the colour, eg. when you're setting the border colour to black when it's already black, you still get the grey dot - causing some nasty "grey dots bugs".
These bugs are even quite common on modern demos and intros actually - sometimes just for a single frame, sometimes throughout. Demos need a proper QA department nowadays ;-) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
Quote:These bugs are even quite common on modern demos and intros actually
Which was one of the main reasons for making it default in VICE - raise the awareness and perhaps make more ppl fix it. |
| |
Conrad
Registered: Nov 2006
Posts: 833 |
Too bad you can't toggle the grey dot on/off (I asked about this before here) ... otherwise you could code a borderless starfield, among other things. ;) |
| |
Mantiz
Account closed
Registered: Apr 2006
Posts: 36 |
Thanks a lot for explaining, it was actually the response I was most afraid of. |
| |
Silver Dream !
Registered: Nov 2005
Posts: 107 |
Quote: Too bad you can't toggle the grey dot on/off (I asked about this before here) ... otherwise you could code a borderless starfield, among other things. ;)
In fact with appropriate hardware add-on you can turn it on and off with single cycle accuracy. Provided your particular machine shows them in the first place... The problem though is that while you can safely turn them off, the opposite is not entirely true. This is caused by the fact that not all HMOS-II VICs exhibit them in the first place, and even those which do, may still fade them out over time due to rising core temperature. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
Not that delaying CS is safe either, its a really ugly hack at best =) |
| |
Silver Dream !
Registered: Nov 2005
Posts: 107 |
Quote: Not that delaying CS is safe either, its a really ugly hack at best =)
Right. As we discussed that on the mailing list. But in BR we do it nicely :-) |
