| |
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...
|
|
... 52 posts hidden. Click here to view all posts....
|
| |
ws
Registered: Apr 2012
Posts: 228 |
Quote:The ghostbyte is always black.
Yes, but does anybody know what those are (red and orange):
http://dl.dataelephant.net/ghostbyt.d64 ? (sys4096)
The black ghostbyte is changed just as visual feedback. |
| |
Jammer
Registered: Nov 2002
Posts: 1289 |
Default pattern when VIC doesn't know what to write, I guess. Colour of these is dependent on value in ghostbyte but I might be totally wrong on this. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11118 |
It's just the good old FLI bug, color depends on whatever was on the bus -> see "Blackmail FLI" (and yes, it's internal bus precharged to $ff, same reason for why the grey dot is light grey) |
| |
ws
Registered: Apr 2012
Posts: 228 |
Quote: It's just the good old FLI bug, color depends on whatever was on the bus
ah yes, nice, the color depends indeed on what byte comes next after the $d011 write. funny. and the content of the char is ofcourse whats in the font as char nr $ff.
thanks! i wasn't aware that the fli-bug was "moveable".
i have added a second .prg to the disk above, that makes the fli-bug-byte blink.
and now i finally understand why some demos/intros would have byte reads all over the place where there is nothing one would need! |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 - Next |
