Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > C64 Coding > Ghostbyte / garbage / $3FFF
2008-12-05 11:57
Mace

Registered: May 2002
Posts: 1799
Ghostbyte / garbage / $3FFF

Discussion about the ghostbyte in the comment of Aliens:

Quoting Jammer
so 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...
2008-12-05 12:01
Jammer

Registered: Nov 2002
Posts: 1288
thanks a lot! i play with kick assembler recently so i have to try it out :)
2008-12-05 13:00
algorithm

Registered: May 2002
Posts: 702
It does not need to cover the entire width of the screen. Just like horizontal color splits you can change the ghostbyte half way through etc and combine with $d016 etc. A camelot demo and some crest demo's use similar methods
2008-12-05 14:45
Graham
Account closed

Registered: Dec 2002
Posts: 990
Also it's not always at $3FFF, depending on the VIC-bank selected it can also be at $7FFF, $BFFF or $FFFF. And if you enable ECM mode it can be found at $39FF, $79FF, $B9FF and $F9FF.
2008-12-05 14:48
Mace

Registered: May 2002
Posts: 1799
Graham, of course... I was keeping it simple :-)
2008-12-05 16:25
Cruzer

Registered: Dec 2001
Posts: 1048
Quote: Also it's not always at $3FFF, depending on the VIC-bank selected it can also be at $7FFF, $BFFF or $FFFF. And if you enable ECM mode it can be found at $39FF, $79FF, $B9FF and $F9FF.


Guess that's why they invented the term "ghostbyte".
2008-12-05 16:37
Oswald

Registered: Apr 2002
Posts: 5007
and to further extend this exciting coder dick size compo: I have found the ghostbyte myself when playing with a ripped fld routine being 14 years old, even made these pattern effects with it. anyone has better bets? :)
2008-12-05 20:42
pernod
Account closed

Registered: Nov 2004
Posts: 25
A fun thing is that when you do a transfer to RAM from a REU, you can lock the destination address counter, so $3fff gets updated every cycle ==> free (black + other color) hires gfx in upper and lower borders. Me and Mastermind/HZ played around with this back then.
2008-12-05 20:42
Mace

Registered: May 2002
Posts: 1799
Well... I found that byte myself too, but I was 2 years older and never exploited the possibilities :)
But boy, was I pleased that I finally got that garbage away in Get Life+!
2008-12-05 20:44
Oswald

Registered: Apr 2002
Posts: 5007
yeah, my initial goal was to get rid of the garbage too :)
2008-12-05 20:56
Skate

Registered: Jul 2003
Posts: 490
@Oswald: Same here. When I opened upper/lower borders for the first time, I've met with this "bug" personally. I found the address causing this irritating "bug" by clearing random memory addresses. I was so happy when it's gone. I've never thought of anything useful about it. :)
2008-12-05 21:49
Ksubi
Account closed

Registered: Nov 2007
Posts: 87
My favourite ghost byte piece of code from 1987: Gauntlet the intro by the Cult is simple and cool.
2008-12-05 21:57
JackAsser

Registered: Jun 2002
Posts: 1987
I think Graham made the coolest application of it so far (C128 only though) in RFO - The VIC experience. If you open the top/bottom border and disable the screen at the same time u get the classic sprites+3fff without chars screen. On a C128 in 2Mhz mode the VIC will never issue any memory reads so the $3fff-gfx every VIC-cycle is now instead what was left on the bus, i.e. the bytes that was read by the CPU. So, by using 2c op-codes, like f.e. LDA #$xx u can indirectly alter the $3fff gfx every VIC-cycles by simply align the CPU-read of the immediate value and the VIC. Kinda cool! :)
2008-12-05 22:14
Mace

Registered: May 2002
Posts: 1799
JackAsser... can you translate that to a language I understand, please? :D
2008-12-05 22:52
Danzig

Registered: Jun 2002
Posts: 428
Quote: and to further extend this exciting coder dick size compo: I have found the ghostbyte myself when playing with a ripped fld routine being 14 years old, even made these pattern effects with it. anyone has better bets? :)

you explored it yesterday? that makes dick size * -1 ;)
2008-12-05 22:52
Zyron

Registered: Jan 2002
Posts: 2381
Quote: JackAsser... can you translate that to a language I understand, please? :D

You can make cool effect! ;)
2008-12-06 08:18
Hein

Registered: Apr 2004
Posts: 933
There is also simple but practical use, I used it in The Good, the Bad and the Ugly with split raster to create a lovely black rectangle in the top border.
2008-12-06 10:09
Mace

Registered: May 2002
Posts: 1799
LOL @ Zyron :-)
2008-12-06 13:40
Krill

Registered: Apr 2002
Posts: 2804
Mace: You do lda #$55 : lda #$f0 : lda #$0f and it shows this pattern: .*.*.*.*****........**** - fill a whole screen with it plus sideborder sprites and you have full-screen hires.
2008-12-06 15:55
Mace

Registered: May 2002
Posts: 1799
@ Krill: ah, I see! Interesting.
2008-12-07 18:44
Monte Carlos

Registered: Jun 2004
Posts: 350
Did you know, that the ghostbyte
in multicolor mode is behind / before
Sprites dependent on $d01d and the pixel combination
of a ghostbyte double pixel?
2008-12-07 19:05
Mace

Registered: May 2002
Posts: 1799
Monte Carlos, please rephrase... what do you mean with 'double pixel'?
2008-12-07 21:16
Krill

Registered: Apr 2002
Posts: 2804
Mace: The idle byte is rendered with double-width pixels in multicolour mode.
2008-12-07 21:18
Mace

Registered: May 2002
Posts: 1799
@ Krill: ah, I see! Interesting.

:-)
2008-12-08 09:23
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.
2016-05-26 21:32
Scan

Registered: Dec 2015
Posts: 110
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?
2021-03-05 11:58
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.
2021-03-05 12:14
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.
2021-03-05 14:38
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.
2021-03-05 15:59
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.
2021-03-05 16:21
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.
2021-03-05 16:55
Copyfault

Registered: Dec 2001
Posts: 466
Quoting Compyx
...
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.
Can confirm, used it in some -yet unreleased- code ;)
2021-03-05 17:30
Krill

Registered: Apr 2002
Posts: 2804
You both seem to be ignoring or misreading what w4rp8 is implying here.

If i understand correctly, this is about glitching the rendering of the idle byte by just writing to seemingly unrelated colour registers, and that glitching causes it to be briefly rendered with black hires pixels in multicolour mode rather than black brick pixels.
2021-03-05 17:35
w4rp8

Registered: Oct 2010
Posts: 9
If it's not a bug in Vice. And the timing of the glitch seems to shift with the index of the color-register you write into.
2021-03-05 17:53
Compyx

Registered: Jan 2005
Posts: 631
Quoting Krill
You both seem to be ignoring or misreading what w4rp8 is implying here.

If i understand correctly, this is about glitching the rendering of the idle byte by just writing to seemingly unrelated colour registers, and that glitching causes it to be briefly rendered with black hires pixels in multicolour mode rather than black brick pixels.


And that would then display some multicolor pixels in a single 'char'?
2021-03-05 17:58
Copyfault

Registered: Dec 2001
Posts: 466
Quoting Krill
...
If i understand correctly, this is about glitching the rendering of the idle byte by just writing to seemingly unrelated colour registers, and that glitching causes it to be briefly rendered with black hires pixels in multicolour mode rather than black brick pixels.
Oh that sounds like "something new"... good point, will have to investigate deeper on this "feature".

Thanks for bringing it up, Warp8!
2021-03-05 18:10
chatGPZ

Registered: Dec 2001
Posts: 11088
I strongly suggest to try it on real hardware, and come up with a test program :)
2021-03-05 21:11
Krill

Registered: Apr 2002
Posts: 2804
Quoting w4rp8
If 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. =)
2021-03-06 10:02
tlr

Registered: Sep 2003
Posts: 1701
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.
2021-03-06 10:26
Laurent

Registered: Apr 2004
Posts: 40


This is from a real c64 (so, same behavior as Vice)
Fresh has some explanation here GhostbyteInSprite
2021-03-06 10:33
tlr

Registered: Sep 2003
Posts: 1701
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.
2021-03-06 10:53
Laurent

Registered: Apr 2004
Posts: 40
Thanks for the link TLR :)
2021-03-06 17:26
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 ;-)
2021-03-06 18:34
Monte Carlos

Registered: Jun 2004
Posts: 350
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.
2021-03-07 20:08
Rastah Bar

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.
2021-03-07 20:24
Copyfault

Registered: Dec 2001
Posts: 466
Quoting tlr
If 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.
2021-03-07 21:29
Krill

Registered: Apr 2002
Posts: 2804
Quoting w4rp8
the 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.)
2021-03-07 21:48
chatGPZ

Registered: Dec 2001
Posts: 11088
Can we direct all complains about x64 no more being there to Krill then? =D
2021-03-07 21:54
Krill

Registered: Apr 2002
Posts: 2804
Well, just rename x64sc to x64 and the old x64 to x64linebased or x64inaccurate or x64forunderpoweredhardware or x64game or something. Have the more accurate thing be the default. :)
(Or just have x64sc be x64demo and x64 be x64game, then deliver both with their respective quite different default settings.)
2021-03-07 23:10
Compyx

Registered: Jan 2005
Posts: 631
I symlinked ~/bin/x64-not-krill to /usr/local/bin/x64 and ~/bin/x64 to /usr/local/bin/x64sc.

I had to change the order of adding stuff to $PATH in .bashrc and obviously this is a terrible idea.

Perhaps rename the old x64 to x64fuc (fast unaccurate core)?
2021-03-07 23:18
Krill

Registered: Apr 2002
Posts: 2804
This is getting way off topic, but the question is probably mostly who the main user base of VICE (for C-64) are, and thus what would the default be.

x64 seems to be wanted by a sizeable part of the users - probable reasons aside, it happens to run almost all games just fine, not so much demos.

Then again, it should be common knowledge by now that x64 is a lot less to trust than x64sc when it comes to accurate emulation, and the x64/sc defaults geared towards gaming are routinely changed to saner (by some definition) settings upon first install by demo sceners. Mhhh. =)
2021-03-08 00:35
Compyx

Registered: Jan 2005
Posts: 631
Yeah this is getting off topic. I'll alter configure to build x64sc as x64.

Back to the ghostbyte.
2021-03-08 13:21
Monte Carlos

Registered: Jun 2004
Posts: 350
come on, csdb is not s.o.
2022-03-29 04:52
ws

Registered: Apr 2012
Posts: 225
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.
2022-03-29 13:32
Jammer

Registered: Nov 2002
Posts: 1288
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.
2022-03-29 15:14
chatGPZ

Registered: Dec 2001
Posts: 11088
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)
2022-03-30 00:46
ws

Registered: Apr 2012
Posts: 225
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!
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
Freeze/Blazon
A3/AFL
psych
Guests online: 364
Top Demos
1 Next Level  (9.8)
2 Mojo  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 No Bounds  (9.6)
6 Comaland 100%  (9.6)
7 Uncensored  (9.6)
8 The Ghost  (9.6)
9 Wonderland XIV  (9.6)
10 Bromance  (9.6)
Top onefile Demos
1 Party Elk 2  (9.7)
2 Cubic Dream  (9.6)
3 Copper Booze  (9.5)
4 Rainbow Connection  (9.5)
5 TRSAC, Gabber & Pebe..  (9.5)
6 Onscreen 5k  (9.5)
7 Dawnfall V1.1  (9.5)
8 Quadrants  (9.5)
9 Daah, Those Acid Pil..  (9.5)
10 Birth of a Flower  (9.5)
Top Groups
1 Booze Design  (9.3)
2 Nostalgia  (9.3)
3 Oxyron  (9.3)
4 Censor Design  (9.3)
5 Crest  (9.3)
Top Original Suppliers
1 Derbyshire Ram  (9.5)
2 Black Beard  (9.4)
3 hedning  (9.2)
4 Baracuda  (9.1)
5 Irata  (8.5)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.094 sec.