| |
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: 447 |
Quoting OswaldI dont agree/understand on how your $00/$01 trick works internally.
Ok, you are right.
I noticed that $00/$01 values changes during normal c64 activity, also if, apparently, nothing write to $00/$01 cpu internal "registers".
This is untrue, because if kernel, during normal operations, access $01 and then VIC make an access to $3FFF, also ram $01 value change.
This is why i noticed $3FFF/$01 value matching.
Quoting Oswald
Reading: the cpu has its own read accesses while performing lda $01 ldx $de00, so why should the "unconnected bus line" contain the data from about 4 read cycles before ? what does exactly happen when reading from $de00 ? how does the value from the lda gets preserved on the bus, when there's more read accesses for performing ldx ?
LDA read and put in .A the content of cpu internal $01, but setup data bus to access RAM $01... but don't read RAM value.
The next LDX to "unconnected address"... i don't know exactly how act on the bus, but grab "pending" value from previuos "$01" bus setup but "not executed"... |
| |
Oswald
Registered: Apr 2002
Posts: 5022 |
"LDA read and put in .A the content of cpu internal $01, but setup data bus to access RAM $01..."
and then cpu sets up the bus to read the opcode for ldx then it reads $00 and then $de. where is the read $01 value is magically stored for us while this happens? :)
writing: CPU sets the bus to write $01 but it doesnt puts data on the bus, but the VIC does in the next cycle the favor ? one possible way that it drives the bus value to its last read value, before setting bus address and R/W line ? but why would it do that?
what if simply the cpu throws the $01 data to both internal and ram, both when reading/writing? |
| |
Flavioweb
Registered: Nov 2011
Posts: 447 |
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: 11127 |
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: 5022 |
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: 447 |
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: 5022 |
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: 447 |
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)? |
| Previous - 1 | 2 | 3 | 4 - Next |
