| |
Mace
Registered: May 2002
Posts: 1799 |
Ghostbyte / garbage / $3FFF
Discussion about the ghostbyte in the comment of Aliens:
Quoting Jammerso for what extent can i control this 'garbage'? in terms of chars and colours.
The ghostbyte is always black.
It occurs in the upper and lower border, when opened, but also in the 'void' that is created with an FLD routine.
If you want that effect as seen in Aliens, you have to write values to $3FFF in a raster routine.
The byte is repeated over the entire width and height of the borders, as the patterns shows.
BTW, I can't remember ever seeing a 'split raster' in $3FFF...
|
|
... 46 posts hidden. Click here to view all posts....
|
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting w4rp8If it's not a bug in Vice. Yes, of course. That manipulation apparently only triggering line-wise responses makes it reek a bit like an emulation bug, indeed. And what Groepaz said. =) |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
I'm not sure I fully understand the description, but I'm assuming you're running x64sc right?
A simple screen shot of the effect would be a good start. |
| |
Laurent
Registered: Apr 2004
Posts: 40 |
This is from a real c64 (so, same behavior as Vice)
Fresh has some explanation here GhostbyteInSprite |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote:
This is from a real c64 (so, same behavior as Vice)
Fresh has some explanation here GhostbyteInSprite
If it's that, we have discussed it quite a lot here: Sprite data fetch in sideborder
From the description I thought w4rp8 referred to the screen area idle fetch graphics, not the idle part at the top of sprites. |
| |
Laurent
Registered: Apr 2004
Posts: 40 |
Thanks for the link TLR :) |
| |
w4rp8
Registered: Oct 2010
Posts: 9 |
Quote: Uhm, that isn't quite correct.
Ghostbyte has nothing to do with any color registers, it simply takes the last byte of a VICII bank, or when using ECM it 'folds' the last charset RAM into $01ff and thus uses $39ff vs $3fff or $79ff vs $7fff.
When you use hires ($3x at $d011) and single color ($0x at $d016), the upper and lower border will always be black*.
* = when opening the upper/lower border.
Your reply is actually true as the effect does not show up in x64sc when I checked now. So I highly assume that it’s also not gltching on the real hardware. Sorry for rising false hopes ;-) |
| |
Monte Carlos
Registered: Jun 2004
Posts: 359 |
There is one thing which could explain the observation. If you switch e.g. both $d021 and $3fff then between the actual write access and the display on the screen there is a different delay for the two registers. So you may indeed cover three of the 4-chars targeted by the $3fff write with setting $d021 to 0.
I think this was exploited in one of the Krestage demos for doing 8 sprites with two one char wide $3fff scrollers in the lower border. |
| |
Rastah Bar
Account closed
Registered: Oct 2012
Posts: 336 |
Instead of writing to $3fff you can also switch banks with $dd00, which has the same delay. Another possibility is to toggle ECM, but IIRC the delay in that differs slightly between VIC models. |
| |
Copyfault
Registered: Dec 2001
Posts: 478 |
Quoting tlrIf it's that, we have discussed it quite a lot here: Sprite data fetch in sideborder
... Thanks for the pointer, tlr ;)
My first thoughts were going in exactly this direction, i.e. that it's something connected with the sprite data fetches.
But then Krill stressed that W4rp8's post#27 was about display data delays, so I'm not sure anymore...
So, what Groepaz says: we need a test prog!!! Won't get around fiddling with it too soon, though. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting w4rp8the effect does not show up in x64sc Not really surprised. Now please everybody rename/move x64sc to x64 finally. =) (Also never trust any emulator before confirming on realthing.) |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 - Next |
