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...
 
... 46 posts hidden. Click here to view all posts....
 
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: 351
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: 2847
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: 11123
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: 2847
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: 2847
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. =)
Previous - 1 | 2 | 3 | 4 | 5 | 6 - Next
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
K-reator/CMS/F4CG
Guests online: 129
Top Demos
1 Next Level  (9.8)
2 Mojo  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 Comaland 100%  (9.6)
6 No Bounds  (9.6)
7 Uncensored  (9.6)
8 Wonderland XIV  (9.6)
9 Memento Mori  (9.6)
10 Bromance  (9.5)
Top onefile Demos
1 It's More Fun to Com..  (9.7)
2 Party Elk 2  (9.7)
3 Cubic Dream  (9.6)
4 Copper Booze  (9.5)
5 TRSAC, Gabber & Pebe..  (9.5)
6 Rainbow Connection  (9.5)
7 Wafer Demo  (9.5)
8 Dawnfall V1.1  (9.5)
9 Quadrants  (9.5)
10 Daah, Those Acid Pil..  (9.5)
Top Groups
1 Nostalgia  (9.3)
2 Oxyron  (9.3)
3 Booze Design  (9.3)
4 Censor Design  (9.3)
5 Crest  (9.3)
Top Graphicians
1 Sulevi  (10)
2 Mirage  (9.8)
3 Lobo  (9.7)
4 Mikael  (9.7)
5 Archmage  (9.7)

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