| |
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! |
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11300 |
Sure its not just a scaling artefact? |
| |
HCL
Registered: Feb 2003
Posts: 727 |
A quick guess would be that the bug is caused by the reset of $d016 (STY $d016). Since you do DEC $d016 you effectively sets it to $ff which sets the x-fine-scroll value to 7, then the STY sets it back to $00 and x-fine-scroll to 0. |
| |
trident
Registered: May 2002
Posts: 91 |
i agree with hcl, definitely an effect of the scroll register being offset by one pixel.
one way to fix it could be to use the asl instruction to open the border, as it will set the scroll register to $d0, which won't have that pixel offset. but it will also set the multicolor mode, which will affect the ghostbyte too. (maybe lsr will work instead, since it will set the scroll register to $4, which won't affect this particular ghostbyte pattern.) |
| |
Skate
Registered: Jul 2003
Posts: 494 |
just to make sure, you can try to change sty $d016 position by a few cycles back and forth and see if one of the glitch positions also change. |
| |
Starfox
Registered: Jul 2014
Posts: 42 |
Quote: Sure its not just a scaling artefact?
Yeah, if I resize, it's still there.
Ahh it makes sense with the scroll register. Thanks! :) 👍
Like I'm seeing the aftereffects of the dec/sty cycles? |
| |
Starfox
Registered: Jul 2014
Posts: 42 |
Quote: i agree with hcl, definitely an effect of the scroll register being offset by one pixel.
one way to fix it could be to use the asl instruction to open the border, as it will set the scroll register to $d0, which won't have that pixel offset. but it will also set the multicolor mode, which will affect the ghostbyte too. (maybe lsr will work instead, since it will set the scroll register to $4, which won't affect this particular ghostbyte pattern.)
I tried fiddling with asl/lsr, but I guess the timing on the write cycles are different from dec?
Skate: I tried, but it just pushes the glitch further to the right.
HCL: won't this be happening everywhere in effects of this type, but we don't notice it? |
| |
HCL
Registered: Feb 2003
Posts: 727 |
@Starfox Either you have to set $d016 back during the sideborder where the ghost pattern is not visible, or you have to use an instruction that can open the sideborder without affecting the x-fine-scroll value.
I don't have the solution for you, and i also don't want to spoil the fun for you finding the solution yourself! :D |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
I'm simply guessing: couldn't it happen that the vic switches from hires to multicolor and vice versa showing a single pixel in multicolor (therefore doubled in width)? |
| |
Starfox
Registered: Jul 2014
Posts: 42 |
Quote: @Starfox Either you have to set $d016 back during the sideborder where the ghost pattern is not visible, or you have to use an instruction that can open the sideborder without affecting the x-fine-scroll value.
I don't have the solution for you, and i also don't want to spoil the fun for you finding the solution yourself! :D
Haha, no spoiling it wouldn't be any fun =P
I can't do it with 8 sprites, but should be possible without/less of course :)
Flavioweb: Interesting. I don't know how to check this other than fiddling with scroll values to see what happens. |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
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. |
| |
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: 674 |
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? |
| |
tlr
Registered: Sep 2003
Posts: 1763 |
EDIT: double post |
| |
Jetboy
Registered: Jul 2006
Posts: 271 |
Quoting tlr Was Tramiel still there when that was done?
I have no idea, and i'm too lazy/do not care enough to dig it up :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11300 |
Quote:To me it seems like an oversight of whoever did the die shrink.
My guess would be they simply didn't care - or even knew about the "problem" :) |
| |
Martin Piper
Registered: Nov 2007
Posts: 700 |
I'm really surprised they apparently didn't run a set of recorded signals through the old and new VIC chips and test the outputs for identical (or even roughly close) video. Even a simple test of repeatedly writing black to the border register would have shown important differences. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11300 |
I'm not - mid-line register changes would probably be simply considered "wrong". |
| |
Starfox
Registered: Jul 2014
Posts: 42 |
Quote: 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.
I didn,y (lol i've been coding too much) know about C64DebugGUI for c64debugger. Cool! 😎
BTW, thing happening was already suggested by HCL and Trident in the first 3 replies, so I'm happy with that 😉 |
| |
tlr
Registered: Sep 2003
Posts: 1763 |
Quote: I'm not - mid-line register changes would probably be simply considered "wrong".
Probably, but it is still occasionally visible even from basic.
Assuming it relies on the external clocks it might not even have shown up in initial testing. Could have been only noticed after the full redesign of the c64 was done, and then it would have been far to expensive to correct.
For the 6569 there were quite a few die revisions. For the 8565 most of them are R2 IIRC. |
| |
ws
Registered: Apr 2012
Posts: 250 |
does anybody know what causes the halting of the system mentioned in post #12 when #$c0 is used? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11300 |
I'm sure that was caused by something else, not the value in $d016 |
| |
Starfox
Registered: Jul 2014
Posts: 42 |
Quote: I'm sure that was caused by something else, not the value in $d016
It seemed like it was frozen. I has testing using $d016,x not noticing I was using x in the loop as well, so everything from d016+ got set to $c0.
But in the debugger, none of the code in the irq was running. Only the jmp outside the irq.
ws:
Here's the prg:
https://www.dropbox.com/scl/fi/9bm26wubyz2c8lssei3nv/whatsgoing.. |
| |
tlr
Registered: Sep 2003
Posts: 1763 |
Quoting StarfoxIt seemed like it was frozen. I has testing using $d016,x not noticing I was using x in the loop as well, so everything from d016+ got set to $c0.
But in the debugger, none of the code in the irq was running. Only the jmp outside the irq.
Yeah, well writing $c0 to $d01a will kill further raster irqs. |
| |
ws
Registered: Apr 2012
Posts: 250 |
ah. i see. thanks! |
