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 > Right-most sideborder sprite bug
2006-09-06 17:38
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)?
2006-09-06 17:53
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..
2006-09-06 19:03
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 :)
2006-09-06 19:07
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
2006-09-06 19:24
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
2006-09-06 19:55
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.
2006-09-06 20:00
Danzig

Registered: Jun 2002
Posts: 440
this seems to be a question ROLAND should reply on!?! ;)
2006-09-06 21:33
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.
2006-09-07 02:05
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.......

2006-09-07 04:49
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.
2006-09-07 14:11
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.
 
... 16 posts hidden. Click here to view all posts....
 
Previous - 1 | 2 | 3 - 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
Andy/AEG
Smasher/F4CG
Hydrogen/Glance
leonofsgr/Singular C..
Scrap/Genesis Project
Asphodel
Guests online: 102
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Mojo  (9.7)
4 Coma Light 13  (9.6)
5 The Demo Coder  (9.6)
6 Edge of Disgrace  (9.6)
7 What Is The Matrix 2  (9.6)
8 Uncensored  (9.6)
9 Comaland 100%  (9.6)
10 Wonderland XIV  (9.6)
Top onefile Demos
1 No Listen  (9.7)
2 Layers  (9.6)
3 Cubic Dream  (9.6)
4 Party Elk 2  (9.6)
5 Copper Booze  (9.6)
6 X-Mas Demo 2024  (9.5)
7 Dawnfall V1.1  (9.5)
8 Rainbow Connection  (9.5)
9 Onscreen 5k  (9.5)
10 Morph  (9.5)
Top Groups
1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Censor Design  (9.3)
5 Triad  (9.3)
Top Organizers
1 Burglar  (9.9)
2 Sixx  (9.8)
3 hedning  (9.7)
4 Irata  (9.7)
5 Tim  (9.7)

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