| |
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....
|
| |
Mace
Registered: May 2002
Posts: 1799 |
Monte Carlos, please rephrase... what do you mean with 'double pixel'? |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Mace: The idle byte is rendered with double-width pixels in multicolour mode. |
| |
Mace
Registered: May 2002
Posts: 1799 |
@ Krill: ah, I see! Interesting.
:-) |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Monte Carlos: ah, I see! Interesting.
Not sure what it can be used for, but always fascinating to learn something new about something you thought you knew everything about.
|
| |
Scan
Registered: Dec 2015
Posts: 111 |
Today I ran into something I think is odd. I've got the ghostbyte in a sprite when displaying it in the right side border from X position $68 and up. I get a line the width of a sprite a line above the sprite, of which the middle 8 pixels can be changed using the ghostbyte at $3fff. I've uploaded a demonstration here. GhostbyteInSprite Anyone an idea why this is happening? |
| |
w4rp8
Registered: Oct 2010
Posts: 9 |
I see, atleast in vice, that some bits of the ghostbyte could be masked by writing to $d020, $d021 ($d022, $d023 too, but not that stable without further stabilzising timing on the writes).
This works with unstable writes:
ldy color
lda #$27
!:cmp $d012
bcs !-
sty $d020
For such a line the ghostbyte goes from 0x33 to 0x21 without touching $7fff.
I saw this appearing in vice 2.4 only with 7 sprites enabled over that lines. vice 3.3 shows that behaviour, and also in areas without sprites enabled, but not as stable, more like writing to $d022. |
| |
w4rp8
Registered: Oct 2010
Posts: 9 |
Actually i just realised that ghost byte content is set to 0x21 and gets changed to 0x33 in lines without writing to $d020 but also with the sprite layer over it.
When incrementing $7fff each frame, it can be seen that it follows some pattern for different ghostbyte values. |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
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. |
| |
w4rp8
Registered: Oct 2010
Posts: 9 |
Ok, so I looked a bit into it. Following is happening:
- the enabled sprites were just shifting the timing, the thing also works with sprites disabled
- mode ist multicolor bitmap, so $3fff is displayed in what Krill called double pixel mode
- if you write to $d020, $d021 the $3fff is displayed in its original pattern on that line
so I assume beside a change of the $3fff pattern by setting the rastercolor, this wouldn't gain anything more. |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Well with the ghostbyte you can render black pixels over whatever $d021 displays. I think you can also set sprite priority so the ghostbyte will cover the sprites. Not sure about that one, I'd have to check that. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 - Next |
