| |
encore
Registered: Aug 2010
Posts: 67 |
Release id #140383 : Vic sprite enable register bug
In case you're wondering how it looks on real C64. My TV-setup shows the signal interlaced instead of progressive so this image is likely a mix of 2 frames, but compare with the release-screenshot and you'll get the idea. |
|
... 10 posts hidden. Click here to view all posts....
|
| |
tlr
Registered: Sep 2003
Posts: 1787 |
@gpz: Yeah, I should really fix it, shouldn't I? :)
When I encountered it I was thinking of a way to exploit the presumed fact that MCBASE is cleared after sprite display but couldn't find any.
Anyone can think of a use?
The glitch could possibly be used to to detect a hard power cycle in a cart though, whatever that would be good for. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11354 |
FC3 actually has some hardware to detect that.... iirc it uses it to come up with the desktop after a hard reset only. or something. :) |
| |
WVL
Registered: Mar 2002
Posts: 898 |
Makes me wonder if it's possible to get the sprite into one of the 'impossible' sprite crunch states, prolly not though.. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11354 |
tlr: definately! does it help if i create a ticket and assign it to you? =P |
| |
encore
Registered: Aug 2010
Posts: 67 |
tlr: Interesting. :) So my testing almost shows your conclusions but I was able to get one C64C with 8565r2 to do a sprite glitch, it took several tries though. I'd like to test that again to see just how rare that is.
So if MCBASE supposedly is #$3f (occasionally other values), it would draw a sprite with about 3 sprites length until it gets the correct stop-value? I feel that in my testing it's more random than that (and sometimes it looks like the sprites are smaller, so then the value is probably #$03, #$06 etc. Their initial values would often differ from sprite to sprite. To me it looks random. A videocard would be useful to see it in greater detail. |
| |
BiGFooT
Registered: Mar 2002
Posts: 33 |
On the HMOS VIC-II the default MCBASE value seems to be #$00, but... With fast power cycles the MCBASE value can be anything dividable by 3, aka it's latest state.
sei
lda #$50
sta $d000
sta $d001
lda #$01
sta $d015
lda #$00
sta $07f8
loop lda $d001
- cmp $d012
bne -
- cmp $d012
beq -
adc #21
sta $d001
jmp loop
Then fast power cycle, and run encore's test program.
VIC-II vcc interrupt should work too, but I was too lazy to do any soldering. |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
@encore: Different values is expected if it is an NMOS artifact. I only tested a small population and got mostly $3f but it could certainly be more on the edge for other chips. It can vary with voltage/temperature/process (compare to the behaviour LAX/ANE).
Non $00 on a HMOS chip points to the $00 being an artifact of that process rather than an explicit reset. It seems to confirm that MCBASE is being reset after sprite display is completed on HMOS too.
Lft's suggestion of detection using stretch is interesting.
Back when I found it I was contemplating doing an automatic detection of the initial MCBASE using a clever pattern and sprite to bg collisions without using stretch. Should be doable too.
@bigfoot: Nice find!
I think I tested if it would stick after a reset, but it didn't. It seems very little of the VIC-II is actually initialized on reset so I believe the sprites just finish displaying like normal even if reset in the middle.
BTW, that spritemcbase.prg test program also hooks the reset vector and dumps vicregs on reset. Might be useful for some tests. |
| Previous - 1 | 2 - Next |
