| |
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....
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11092 |
Can we direct all complains about x64 no more being there to Krill then? =D |
| |
Krill
Registered: Apr 2002
Posts: 2822 |
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.) |
| |
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)? |
| |
Krill
Registered: Apr 2002
Posts: 2822 |
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. =) |
| |
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. |
| |
Monte Carlos
Registered: Jun 2004
Posts: 350 |
come on, csdb is not s.o. |
| |
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: 11092 |
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 - Next |
