| |
Copyfault
Registered: Dec 2001
Posts: 466 |
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....
|
| |
Flavioweb
Registered: Nov 2011
Posts: 442 |
Quoting Oswaldwhat 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? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11100 |
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 |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
Quote: Quoting Oswaldwhat 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. |
| |
Flavioweb
Registered: Nov 2011
Posts: 442 |
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... |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
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? |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
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. |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
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. |
| |
Flavioweb
Registered: Nov 2011
Posts: 442 |
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)? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11100 |
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 :) |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
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 |
