| |
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! :=) |
... 7 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 - Next |
