Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in 
CSDb User Forums


Forums > C64 Coding > Sprite data fetch in sideborder
2014-03-03 22:43
Copyfault

Registered: Dec 2001
Posts: 312
Sprite data fetch in sideborder

I'm playing around with sprites in the sideborder. Usually the ypos for a sprite is one less than the rasterline it should actually show up, e.g. if you want to see a sprite in rasterline $33, you have to put $32 in its ypos-reg.

Now if a sprite has xpos >= $164, the sprite display is turned on in the very same line. For sprite 0, this behaviour can be exploited as the sprite data is read in the cycles directly before. This was done e.g. to get 9 sprites in one rasterline.


If we put any other sprite at this position (xpos >= $164), the display will also start immediatly on the same rasterline (not on the following one). But the sprite data that was fetched looks like a [$ff $00 $ff]-pattern.

I found out that the '$00' in the middle comes from the last byte of the active vic bank (ghostbyte) and that it can be changed accordingly.

Still not clear is the origin of the other $ff-bytes. Are they hardwired just like the $ff-bytes the vic reads as vram on fli-lines? Are they coupled to the adress/data bus somehow?

Maybe someone has already examined this and could explain the behaviour.
 
... 22 posts hidden. Click here to view all posts....
 
2014-03-12 19:33
Flavioweb

Registered: Nov 2011
Posts: 413
Quoting Oswald
what if simply the cpu throws the $01 data to both internal and ram, both when reading/writing?

Actually there is, at least, one opcode in excess in my theory...
What you mean, exactly, with "throws both data"?
LDA $00 read value from RAM $00 but result is "discarded"?
But the problem still here: "where" this vaule is discarded?
Where LDX $DE00 -rises- this value?
The value of .X is correct only if, previously, $00 or $01 are accessed by a "read" opcode...
If isn't "on bus"... where this value is?
2014-03-12 19:56
Groepaz

Registered: Dec 2001
Posts: 9571
i really wish we could split the thread, as the 0/1 issue is completely unrelated to this VIC stuff :)

as for the 0/1 thing, just look it up in that c=hacking issue on codebase, the explanation was quite accurate iirc
2014-03-13 11:34
Oswald

Registered: Apr 2002
Posts: 4612
Quote: Quoting Oswald
what if simply the cpu throws the $01 data to both internal and ram, both when reading/writing?

Actually there is, at least, one opcode in excess in my theory...
What you mean, exactly, with "throws both data"?
LDA $00 read value from RAM $00 but result is "discarded"?
But the problem still here: "where" this vaule is discarded?
Where LDX $DE00 -rises- this value?
The value of .X is correct only if, previously, $00 or $01 are accessed by a "read" opcode...
If isn't "on bus"... where this value is?


I mean, the the cpu could just simply write both ram at $01 and its internal register at the same time ? and all this trickyng around is not needed ?

and tell me how is the bus value from 3 reads earlier magicallly preserved "at" $de00 ? shouldnt the next 3 reads (ldx $de 00) erase the earlier bus contents ?

even if it works, the explanation doesnt.

and back to spritefetch: even if you put data into VICII internal bus (does this even exists?), before it fetches sprite data. the fetch will happen and overwrite whatever there is. IMHO.
2014-03-13 11:46
Flavioweb

Registered: Nov 2011
Posts: 413
Quoting Oswald

even if it works, the explanation does.

I opened another thread for this.
There is something strange about bytes and bus here.
Theoretically should not works... but work!
C64 have left some magic dust for us...
2014-03-13 20:47
Copyfault

Registered: Dec 2001
Posts: 312
Quoting Oswald
...

and back to spritefetch: even if you put data into VICII internal bus (does this even exists?), before it fetches sprite data. the fetch will happen and overwrite whatever there is. IMHO.


It really works like tlr stated - I have the code done and already tested on the real thing! I'll do my best to put a testprog together this weekend and will up it here lateron (the code I have done contains to much that I don't want to release yet, so I have to sort out the relevant part for the "sprite fetch feature").

But I think it really makes sense: if you read or write something from/to vic exactly during the sprite fetch cycles (e.g. cycles #1+2 for sprite 3), you make the vic "see" the read/sent data during the cpu-halfcycles. But the vic also writes something to its internal sprite buffer (for sprite 3) during these halfcycles, so it's highly probable that it just writes the data that it "sees" in the very same moment. Note: there is no normal sprite fetch as sprite dma is not turned on before cycle 58 (~ xpos $164).

What exactly makes you wonder about this explanation?
2014-03-13 22:17
Oswald

Registered: Apr 2002
Posts: 4612
if there's no normal sprite dma (ie the vic doesnt drives the bus) then it makes sense, that it simply reads whats left there by the cpu.
2015-04-02 00:29
Copyfault

Registered: Dec 2001
Posts: 312
More than a year has passed already since my last post promising a little test prog.

I wanted to keep my promise and uploaded it here as Sideborder Sprite Data Fetch TestProg.
2015-04-02 16:36
Flavioweb

Registered: Nov 2011
Posts: 413
Since i can't test it on RH now...
...using vice X64SC, the test prg act as on rh, or the "pattern"
displayed on the first sprite line could be "wrong" (use other addresses/data)?
2020-05-18 20:34
Groepaz

Registered: Dec 2001
Posts: 9571
5 years later i looked at this program and added it to the VICE testbench: https://sourceforge.net/p/vice-emu/code/HEAD/tree/testprogs/VIC..

Some questions are open (to me anyway):

- apparently this problem applies to all sprites. (to my surprise) the problem always start at xpos $164. however, the cycles where the sta vicreg,x must be performed is different for each sprite - which are they? just all spaced 3 cycles apart? or 4? a little table would be a great addition to that readme i copypasted together :) it would also be nice to have this proved in testprogram(s) :)
- how does all this relate to sprite-sprite (and perhaps even sprite-background) collisions? i would guess that it works as expected, ie pixels that get displayed will also cause collisions. but is that really what happens? another test for this would nice to have :)

keep it coming :)
2020-05-18 22:16
Copyfault

Registered: Dec 2001
Posts: 312
Quoting Groepaz
[...]- apparently this problem applies to all sprites. (to my surprise) the problem always start at xpos $164. however, the cycles where the sta vicreg,x must be performed is different for each sprite - which are they? just all spaced 3 cycles apart? or 4? a little table would be a great addition to that readme i copypasted together :) it would also be nice to have this proved in testprogram(s) :)
I'd say you need to set the sta abs,x-command two cycles apart, i.e. the last two cycles of that opcode must match with the sprite fetch cycles of the corresponding sprite (with spr0 being an exception, as the sprite fetch cycles have been correctly executed at this pos. of the rasterline).

Quoting Groepaz
- how does all this relate to sprite-sprite (and perhaps even sprite-background) collisions? i would guess that it works as expected, ie pixels that get displayed will also cause collisions. but is that really what happens? another test for this would nice to have :)

keep it coming :)
You're right, this calls for a proper update of the test prog... oh boy /o\

CF
Previous - 1 | 2 | 3 | 4 - 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
Tim/Silicon Limited
sebalozlepsi
6R6/shape/[n0]
hedning/G★P
Guests online: 65
Top Demos
1 Uncensored  (9.7)
2 Coma Light 13  (9.6)
3 Edge of Disgrace  (9.6)
4 Memento Mori  (9.6)
5 Comaland 100%  (9.6)
6 Unboxed  (9.6)
7 Lunatico  (9.6)
8 The Shores of Reflec..  (9.6)
9 Remains  (9.5)
10 C=Bit 18  (9.5)
Top onefile Demos
1 Crystal Gazer  (9.5)
2 Dawnfall V1.1  (9.5)
3 Smile to the Sky  (9.5)
4 Daah, Those Acid Pil..  (9.5)
5 Rewind  (9.5)
6 Instinct  (9.4)
7 Tribute to Ben - Las..  (9.4)
8 In Memoriam BHF  (9.4)
9 Coro(l)na Nuthouse  (9.4)
10 Cuarentenauta  (9.4)
Top Groups
1 Booze Design  (9.4)
2 Censor Design  (9.4)
3 PriorArt  (9.4)
4 Oxyron  (9.3)
5 Triad  (9.2)
Top Crackers
1 Mr. Z  (10)
2 S!R  (9.9)
3 Erhan  (9.9)
4 Mr Zero Page  (9.8)
5 Mitch  (9.8)

Home - Disclaimer
Copyright © No Name 2001-2020
Page generated in: 0.059 sec.