| |
Copyfault
Registered: Dec 2001
Posts: 475 |
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. |
|
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
I would assume they're equally hardwired to ff just like the char fetches prior to char dma (i.e. The fli-bug) |
| |
Oswald
Registered: Apr 2002
Posts: 5086 |
nice discovery, not even the famous VIC article mentions this behaviour IIRC.
#$ff comes from at FLI according to the VIC article: AEC is high and so the internal data bus drivers D0-D7 of the VIC are closed and as the chip is manufactured in NMOS technology, it reads the value $ff.
not sure if the same happens for sprites. why would VIC connect to the bus on/off on different cycles ? maybe its that sprite DMA is not yet turned on, CPU is not halted, and as VIC gets the bus alternatively normally, when it gets the bus it goes for the ghostbyte when it doesnt it reads $ff.
while thinking of it, ghostbyte is probably an NMOS feature aswell, undriven bus lines are pointing to $3fff (%11111111111111) ? |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
Some time ago, i investigated, for fun and profit, on how to read and write RAM locations $00 and $01.
Not the CPU internal "registers", but the REAL ram.
I learned that when cpu access $00 or $01 for read or write, set up the data-bus "normally" as if it were a normal ram access, but returns or write the "internal" cpu addresses.
Then i thought that the only chip can access ram independently from cpu is vic-ii.
When VIC-II does an "uncontrolled" ram access?
During the "idle-access" that cause, in some circumstances, the display of the idle graphic pattern.
The most easy way to show idle-gfx pattern, is to open the lower border without zeroing the $3FFF location (in -normal- conditions...), so here there is a idle-ram access.
If we wait the "right moment" and read or write $00/$01, we have the "register" value written/readed in/from $00/$01, but a "pending" value on the data-bus.
To write into $00/$01 we need to store the value at vic-ii idle address ($3FFF usually) then write to the "register", but for read a value from $00/$01, we need to read from $00/$01 then, just after that, read a NOT-CONNECTED address (like $DE00 if no CRTs are used) to grab "pending" data from bus.
I think some code can explain better than 1.000 words:
.> c000 a9 7f lda #$7f
.> c002 cd 12 d0 cmp $d012
.> c005 d0 fb bne $c002
.> c007 ad 11 d0 lda $d011
.> c00a 10 fb bpl $c007
.> c00c a5 01 lda $01
.> c00e a0 e0 ldy #$e0
.> c010 8c ff 3f sty $3fff
.> c013 85 01 sta $01
.> c015 a5 01 lda $01
.> c017 ad 00 de ldx $de00
.> c01a 60 rts
This code write and read value $E0 (ending content of .X) from RAM location $01.
(Works also with Vice)
All that to say what?
Maybe other value used for sprite GFX comes from one of this 2 locations.
For eg, Vice (and also RH should) have $FF stored at RAM address $00 after a "normal" reset...
Now is up to you =P |
| |
chatGPZ
Registered: Dec 2001
Posts: 11354 |
no, the VIC doesnt access $00/$01 ... its either idle access or hardwired $ff. someone could check if it is already working properly in x64sc, and then look up what it is in the source... i'd start with this test program |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
I researched this and implemented it for x64sc and it should be working properly AFAIK. I'm sure the knowledge was known by others before that.
Those $ff bytes come from whatever is on the internal VIC-II bus at the cycles when the sprite fetch should have occured.
To change the value from the default pulled up state, perform a write (or read) access that generates the desired byte on the internal bus on the right cycles. |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
Groepaz, this is the result of test.prg on RH/Vice x64 2.4.5 r27742M.
From what i can see ... they are the same thing:
http://i59.tinypic.com/1zbrwar.jpg
IIRC on RH i have a ceramic VIC R1... but can be a R3, i need to check if it should be interesting... |
| |
Copyfault
Registered: Dec 2001
Posts: 475 |
Quoting tlr...
Those $ff bytes come from whatever is on the internal VIC-II bus at the cycles when the sprite fetch should have occured.
To change the value from the default pulled up state, perform a write (or read) access that generates the desired byte on the internal bus on the right cycles.
Thanks for the hint! I already tried that but I wasn't able to change the bit pattern. Maybe I have to do smth else than senseful placements of "lda #<bitpattern>"??? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11354 |
making it appear on the internal bus probably needs some more fiddling :) |
| |
Oswald
Registered: Apr 2002
Posts: 5086 |
"To change the value from the default pulled up state, perform a write (or read) access that generates the desired byte on the internal bus on the right cycles."
the ghostbyte is shown between two $ff's, so I dont think thats gonna work. its probably like the FLI bug, VIC tries to read but it doesnt has the bus, cpu has it. VIC gets $ff.
the end. |
| |
Copyfault
Registered: Dec 2001
Posts: 475 |
The question is if it is possible at all to squeeze _any_ byte into the internal vic bus floating by at the correct raster cycle.
My explanation (up to now) looks like this: as the described behaviour occurs on the same rasterline as the ypos-value of the sprite, there has not been a valid sprite data fetch before during the cycles belonging to that sprite. What happend instead during those two sprite fetch cycles?
1. In the first halfcycle (with the bus connected to the vic) the sprite pointer was read
2. in the second halfcycle (now with bus connected to cpu) the next cpu cycle is executed
-> some mechanism must generate the first $ff-byte at this point
3. in the next halfcycle (now again bus connected to vic) the vic does an idle access to $3fff as the normal sprite data fetch is not active yet
4. in the last halfcycle (bus belongig to cpu again) the same should happen as in the 2nd halfcycle
Due to this first theory I was trying to put the wanted bytevalues on the bus via "lda #bytepattern", but this did not change anything. How could it be done correctly - if it can be done at all? |
... 22 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 | 3 | 4 - Next |
