| |
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....
|
| |
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. |
| |
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. |
| |
Copyfault
Registered: Dec 2001
Posts: 467 |
Quoting tlrIf 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. |
| |
Krill
Registered: Apr 2002
Posts: 2855 |
Quoting w4rp8the 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.) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11149 |
Can we direct all complains about x64 no more being there to Krill then? =D |
| |
Krill
Registered: Apr 2002
Posts: 2855 |
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: 2855 |
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: 351 |
come on, csdb is not s.o. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 - Next |
