| |
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. |
|
... 7 posts hidden. Click here to view all posts....
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11354 |
interesting observations.... i test program that works like LFT suggested would be nice indeed. my guess is that the counter would either have all bits set, or its completely random after powerup :)
that said, it doesnt seem to happen on my C64C (250469, 8565R2)
edit: it would be nice if those test programs came with source and perhaps a proper readme... so i can throw them into the VICE testrepo :) |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
I personally encountered this while doing research for x64sc. My conclusion was that it is due to MCBASE not being $00 from start, rather $3f on the 6569 machines I tested.
Now, this wouldn't matter if MCBASE was reset on the start of sprite display (see: vic article "3.8.1. Memory access and display") but if MCBASE is reset _after_ the end of sprite display it makes sense. This shouldn't make any observable difference other than on the initial anomaly.
An MCBASE of $3f means 3 full laps (IIRC) through the data before reaching the end condition, and that the reset is after the displaying means that it would only happen once, which is consistent with what we are seeing.
Sometimes (very seldom) glitches of different length appeared which would indicate a different initial MCBASE. The initial value is probably just an artifact of the NMOS implementation.
On the 8565 this is not seen/was corrected, most likely by adding a reset to MCBASE at start up.
Summary:
- MCBASE cleared _after_ sprite display end.
- 6569: MCBASE=$3f after power up (sometimes different).
- 8565: MCBASE=$00 after power up
I wrote a simple (manual) test program for it and put it in the VICE TODO list but never bothered to emulate it. Maybe it should be in the bug tracker? :)
Test program: testprogs/VICII/spritemcbase/
VICE TODO: http://vice-emu.pokefinder.org/index.php/Todo#VIC-II
This anomaly matters in some cases. In Box Check "Type" for instance I have a piece of code (at $08f9) to clear MCBASE in the beginning, otherwise the first test run would fail and the whole test marked unstable.
EDIT: I briefly mentioned this here: http://csdb.dk/forums/?roomid=11&topicid=78186#78793 Wasn't too clear on the details though. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11354 |
tested again with my breadbox (250407, 6569 R5) and now i get the described behaviour.... indeed seems to be an NMOS vs HMOS issue :)
tlr: so fix it! :=) |
| |
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 |
