| |
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. |
|
| |
DKT
Registered: Aug 2004
Posts: 99 |
Didn't noticed such behavior on my C64C. |
| |
encore
Registered: Aug 2010
Posts: 67 |
Don't forget it only happens one time per sprite per power-cycling. If you use TFC3 cartridge it has already enabled some of the sprites for the GUI. AR6 doesn't afaik. |
| |
Mr. SID
Registered: Jan 2003
Posts: 424 |
 |
| |
DKT
Registered: Aug 2004
Posts: 99 |
I run it using 1541U2 without any cart image, using "Run disk" option for d64.
Maybe my eye is to slow ;-). |
| |
Oswald
Registered: Apr 2002
Posts: 5086 |
looks like the sprite crunch misalignment, maybe the counter is not initialised by 0. |
| |
lft
Registered: Jul 2007
Posts: 369 |
Suggestion: Use normal d017-stretch on all 312 rasterlines to make the sprite counters stick at their powerup state. Use sprite/bg collision detection to read out the powerup state and display it in a convenient format, e.g. as text. Determine whether the behaviour is consistent (e.g. always starting at offset $15), random or perhaps correlated with chroma phase (and therefore possibly with vsp crashability). Profit? |
| |
encore
Registered: Aug 2010
Posts: 67 |
I did some testing on my c64's, about 3-4 times per machine (unless it happened immediately)
happens:
c64c (c64e p) (pcb assy no.250469, pcb 25311 rev 4) with vic-ii (8565r2 4387 22) and CSG8701 replacement (icomp).
c64c (c64b3 p) (assy no. 250466) with vic-ii (mos 6569r5 5286)
c64reloaded with 'mos f6 8701 4587 21' and following vic-ii's:
mos 6569r3 3684
mos 6569r1 2383
mos 6567r8 3984 (ntsc)
didn't happen:
c128 (c128l ww) (w-7794v-0) with vic-ii (mos 8566r3 v, 4685)
c64c (c64e) (pcb assy no.250469, pcb no.252311 rev.4) with vic-ii 8565r2 (3188 22) |
| |
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. |
