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