| |
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....
|
| |
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! |
| Previous - 1 | 2 | 3 | 4 - Next |
