| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Right-most sideborder sprite bug
If you remove the sideborder and place any sprite at the very right most place in the border you will see about 8 pixels wide garbage on the line before the actual sprite (all 21 sprite lines are accounted for below this point). This is also some kind of sprite data and share the colors from the sprite that is about to be shown. VICE emulates it somewhat correct. This means that the sprite is actually 22 lines high?!
How and why does this occur and from where are the pixels fetched when the bug is outputed (or is it a bus-lock of some kind)? |
|
| |
WVL
Registered: Mar 2002
Posts: 902 |
All I know is that normally a sprite is displayed one line below the y-position you set it at, this is because the VIC has to fetch the contents. One thing that is unclear to me is at what point the VIC decides to start showing the sprite, but I've noticed before that this is somewhere in the right sideborder, one line before the sprite should start (better : exactly at the line it should start).
I think Krill's emufuxxor also relies on this effect.. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
I thought same newbie asks this but Im suprised that its you, jack :D Have you checked the vic article ? IMHO the sprite data is not yet fetched at that point, I think I've read this somewhere :) |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
@oswald: The more you know the more you realize how much more there is to know. :D The VIC-article doesn't cover this phenomena as far as I'm know. It just puzzles me that the VIC actually output anything at all at that point.
What happens at that area is, as Werner pointer out, that some sprite data is fetched.
@oswald (again): What do you mean by that sprite data isn't fetched at that point? Of course it isn't, it's BEING fetched at that point, but still, WHY does the VIC output anything at all?
It would be nice with some explanation using flip/flops and counters and other easy-to-understand binary logics. :D
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
is the garbage static ? maybe the vic reads whats left on the bus by the cpu. try to change the code used for the display ;)
edit: you should check where is the sprite gfx fetched, and where is the sprite actually displayed, maybe that will reveal something.
edit2: try to stretch it vertically, does it display the same data on each rasterline?
edit3: I bet the 24 bit shift register starts to shift as soon as the sprite x coord is matched with the rasterbeam, regardless wether the needed s acesses were done or not, you only have to find out where that data comes from.
edit4: if the sprite data is being fetched right when it is displayed the garbage might be cause by the interference of the data both being written into the shift reg, and at the same time the shift reg is being shifted
edit5: the above could be approved by changing the x coord slightly and checking if the garbage changes |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
@oswald: yep, I've had almost all of those ideas myself. The thing was, I thought I asked here before rediscover the wheel again since I'm rather lazy. ;) Sometime later, if the answer doesn't pop up here, I'll investigate it myself. |
| |
Danzig
Registered: Jun 2002
Posts: 440 |
this seems to be a question ROLAND should reply on!?! ;) |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
The garbage is always the same $00 $FF $00 pattern one line above the actual sprite data. The $00's are just what is left in the sprite data shift register, and the $FF is propably a result of the shift register receiving tristate mode while wanting to receive non existant data. Just an assumption though. |
| |
Style
Registered: Jun 2004
Posts: 498 |
with my sideborder dysp I cheated and set the sprite colour to the background colour for the first row :)
edit: Graham, were early VIC-IIs tri-state? I read somewhere that 6581's arent.......
|
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
@graham: makes some kind of sence at least. ;)
@style: I have an old VIC-II chip with the old colors and cheramic casing etc.. The bug is visible there too. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Hmm, the only way to get rid of that ug is indeed setting the corresponding colour register to background. |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
You can also use X-position, or just move the sprite 1 pixel up... Or cover the bug with another sprite... or... or... or... |
| |
Danzig
Registered: Jun 2002
Posts: 440 |
or pronounce a BUG as a FEATURE like some silly east-european visual-basic-coder did... |
| |
MRT
Account closed
Registered: Sep 2005
Posts: 149 |
You mean, like opening up the borders? ;-) |
| |
Danzig
Registered: Jun 2002
Posts: 440 |
no, i mean like creating recordset1, open NONE-EXISTING recordset2 and looping over recordset3... NOT WORKING :) ... and as i removed >>On Error Resume Next<< all these ERROR-Messages appeard and he claimed: its all FEATURES in the program.... but yeah, i ment bugs like opening the borders ;) |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Graham: true. I should do some nifty sideborder code again, seems too much chunkyness and drive shit have paid their toll on me. :D |
| |
Style
Registered: Jun 2004
Posts: 498 |
graham: moving the sprite 1 pixel up just moves the corrupt gfx 1 pixel up :D
|
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
@style: but usually the side border is closed there... that's probably what Graham referred too... Personally I used the change-color-fix in one part, and move-in-x in another part. Both equally effective to squach that bug to oblivion. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
could we have a screenshot of the bug ? |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Oswald: Check 1 Year Totally Stoned by Booze Design, the greetings part (BD.4*), the bug also occurs when using VICE.
I think nobody mentioned it before, but not only is there garbage one line before the sprite is displayed, but also that very sprite is prematurely cut off in its last line at the x-position where that bug occurs. |
| |
Style
Registered: Jun 2004
Posts: 498 |
yes, thats true also.
For my sideborder DYSP I cheated and ignored that fact :D
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
style, would you please stop acting like wanderer ? open a sepearete thread about ur sideborder dysp instead of polluting this one. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
vic article:
"4. In the first phase of cycle 58, the MC of every sprite is loaded from its belonging MCBASE (MCBASE->MC) and it is checked if the DMA for the sprite is turned on and the Y coordinate of the sprite matches the lower 8 bits of RASTER. If this is the case, ____the display of the sprite is turned on._____"
now the question left is that where does the data come from. |
| |
Style
Registered: Jun 2004
Posts: 498 |
Quote: style, would you please stop acting like wanderer ? open a sepearete thread about ur sideborder dysp instead of polluting this one.
errrm, since my allborder DYSP was a) done recently so it's fresh in my mind and b) had the sprite bug that I had to work around, I though it was kind of topical :)
|
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
@Oswald: I answered the question already. |
| |
HCL
Registered: Feb 2003
Posts: 728 |
Yepp, check the greetings part in 1 year Totally Stoned / Booze Design as Krill mentioned. That part is a perfect display of all possible sprite bugs when opening the sideborder :). |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
graham, you havent answered the "why" part of the question :P |
