| |
Starfox
Registered: Jul 2014
Posts: 42 |
Weird ghostbyte glitch (8 sprites+borders open)
Hello
I'm fiddling with some border sprites and ghostbyte patterns/colors.
I'm alternating the bit pattern $aa (10101010) and $55 (01010101) on each rasterline, but at two points there's like a glitch where the same pixel is repeated twice.
Ohh and, I have 8 sprites displayed on each rasterline,and the borders are all open (the sprites are blank to show the problem).
Here's a screenshot:
https://www.dropbox.com/scl/fi/g6nt8giewsfp2rdw5g4tl/weird-ghos..
EDIT: It's not a VICE bug. I suspect its because of the timing of the writes or something sinister?
Cheers! |
|
... 22 posts hidden. Click here to view all posts....
|
| |
Starfox
Registered: Jul 2014
Posts: 42 |
Quote: Quoting StarfoxFlavioweb: Interesting. I don't know how to check this other than fiddling with scroll values to see what happens.
If you leave the 4th bit of $D016 always at zero then i'm wrong.
But if you use inc/dec or some other opcodes that change the bit value you can try to avoid it and see what happens.
I tried fiddling a little bit. Somehow got $d016 set to $c0. whole screen went black, no interrupts, only jmp * was happening 😂 |
| |
Martin Piper
Registered: Nov 2007
Posts: 700 |
Does it behave differently on new and old VIC revisions? |
| |
Starfox
Registered: Jul 2014
Posts: 42 |
Quote: Does it behave differently on new and old VIC revisions?
If I change the vic model, it's still the same.
If anyone is curious, here's the prg:
https://www.dropbox.com/scl/fi/9ltel0fexyzuhqmwuad81/full-scree..
Don't mind the rest of the screen. It's just an experiment :) |
| |
Martin Piper
Registered: Nov 2007
Posts: 700 |
Quote: If I change the vic model, it's still the same.
If anyone is curious, here's the prg:
https://www.dropbox.com/scl/fi/9ltel0fexyzuhqmwuad81/full-scree..
Don't mind the rest of the screen. It's just an experiment :)
It's probably the $d016 change with the fine pixel scroll mid scan line. C64DebugGUI is clearly showing the d016 updates happen around those positions on the screen.
Although a thought comes to mind, you know how when writing the same value to $d020 we get single pixel grey dots on new VIC and old VIC doesn't show grey dots? This is due to the written latch internally showing the wrong value for a tiny portion of time and this gets displayed for a pixel.
I was wondering if this "written latch showing the wrong value for a small amount of time" also happens with the other internal registers like X scroll for a pixel?
Unfortunately I don't have a real new VIC C64 working at home to test this anymore. |
| |
tlr
Registered: Sep 2003
Posts: 1763 |
Quoting Martin PiperAlthough a thought comes to mind, you know how when writing the same value to $d020 we get single pixel grey dots on new VIC and old VIC doesn't show grey dots? This is due to the written latch internally showing the wrong value for a tiny portion of time and this gets displayed for a pixel.
There is no single "written latch" in the VIC-II. The grey dots appear where the color registers are clocked out from the dotclock domain. There is a race condition when simultaneously clocking in a value from the CPU side. This probably relies on the exact relation between the external clocks and that the HMOS process used for the 8565 is faster.
Quoting Martin PiperI was wondering if this "written latch showing the wrong value for a small amount of time" also happens with the other internal registers like X scroll for a pixel?
It is true that a bunch of other register bits are passing to the dotclock domain. These exhibit various differences in timing between 6569 and 8565 but there doesn't seem to be a glitch like this, rather it shows as differing delays for transitions. Note that there also are differing delays between low-to-high and high-to-low transitions over this crossing on both generations of the VIC-II.
Not to say that there couldn't be such an effect, but the symptoms of it would probably be buried much deeper.
Note: here I use the PAL 6569 (old vic) and 8565 (new vic) as terminology. It should apply to NTSC and others too. |
| |
Martin Piper
Registered: Nov 2007
Posts: 700 |
Quote: Quoting Martin PiperAlthough a thought comes to mind, you know how when writing the same value to $d020 we get single pixel grey dots on new VIC and old VIC doesn't show grey dots? This is due to the written latch internally showing the wrong value for a tiny portion of time and this gets displayed for a pixel.
There is no single "written latch" in the VIC-II. The grey dots appear where the color registers are clocked out from the dotclock domain. There is a race condition when simultaneously clocking in a value from the CPU side. This probably relies on the exact relation between the external clocks and that the HMOS process used for the 8565 is faster.
Quoting Martin PiperI was wondering if this "written latch showing the wrong value for a small amount of time" also happens with the other internal registers like X scroll for a pixel?
It is true that a bunch of other register bits are passing to the dotclock domain. These exhibit various differences in timing between 6569 and 8565 but there doesn't seem to be a glitch like this, rather it shows as differing delays for transitions. Note that there also are differing delays between low-to-high and high-to-low transitions over this crossing on both generations of the VIC-II.
Not to say that there couldn't be such an effect, but the symptoms of it would probably be buried much deeper.
Note: here I use the PAL 6569 (old vic) and 8565 (new vic) as terminology. It should apply to NTSC and others too.
I didn't say there was a "single written latch", I was just making the explanation more understandable to a wider audience.
Values like this are obviously contained in groups of latches, which might be clocked by various timing signals, these might also be co-located on the die or might not, depending on their layout. There are quite a few latches internally that might be susceptible to this kind of timing, it's rather complex. |
| |
Fungus
Registered: Sep 2002
Posts: 675 |
This isn't Melon64, you're wasting your breath. |
| |
Jetboy
Registered: Jul 2006
Posts: 271 |
Quoting tlrQuoting Martin PiperAlthough a thought comes to mind, you know how when writing the same value to $d020 we get single pixel grey dots on new VIC and old VIC doesn't show grey dots? This is due to the written latch internally showing the wrong value for a tiny portion of time and this gets displayed for a pixel.
There is no single "written latch" in the VIC-II. The grey dots appear where the color registers are clocked out from the dotclock domain. There is a race condition when simultaneously clocking in a value from the CPU side. This probably relies on the exact relation between the external clocks and that the HMOS process used for the 8565 is faster.
I always thought it was because they saved a few transistors not doing hazard elimination. Because mr. Tramiel was very stingy.
btw. Is the code provided here supposed to be run in NTSC? |
| |
Martin Piper
Registered: Nov 2007
Posts: 700 |
Quoting Jetboy
btw. Is the code provided here supposed to be run in NTSC?
I ran it in PAL and got the same screenshot. :) Because for me PAL is the best, obviously.
When pondering race conditions in digital logic, I'm always reminded of threads like this that look at the die shots to try to find an explanation: https://www.lemon64.com/forum/viewtopic.php?p=986181#p986181
Later posts in that thread seemed to indicate it can be heat related. Which reminds me when the Super FX was being prototyped, we used to have cans of coolant to spray on the chips, or put them in a freezer.
Anyway, for VIC-II die shots these links are useful:
http://mail.lipsia.de/~enigma/neu/6581.html
https://retronn.de/imports/commodore_chips.html#VIC2R1
Myself I try to look at behaviour that is observable and testable outside the chip, i.e. effects that are testable via software. |
| |
tlr
Registered: Sep 2003
Posts: 1763 |
Quoting JetboyI always thought it was because they saved a few transistors not doing hazard elimination. Because mr. Tramiel was very stingy
To me it seems like an oversight of whoever did the die shrink. On the 6569 it works reliably, albeit with a one pixel delay. Was Tramiel still there when that was done? |
| Previous - 1 | 2 | 3 | 4 - Next |
