| Re: VIC-II [message #141872] |
Mon, 05 December 2005 19:48  |
David Horrocks
Messages: 34
Registered: December 2012
Karma: 0
|
Member |
|
|
Hi
As promised, I will help clarify some points about VIC-II sprite behaviour.
In Christian Bauer's VIC article it is suggested that the VIC maintains an
internal "expansion flip-flop" and an internal sprite data pointer called
MCBASE for every sprite. The internal "expansion flip-flop" is not to be
confused with the Y Expand register at $D017. The Y Expand register is
separate read/write register. Writing a zero to a Y Expand register bit will
set the corresponding sprite expansion flip-flop. In the first phase of
clock 55 the expansion flip-flop is inverted only for those Y Expand bits
that are set. Writing a one to a Y Expand register bit during clock 55 will
prevent the inversion and result in the corresponding sprite expansion
flip-flop being cleared. Writing a one during a clock other than cycle 55
does not affect the flip-flop. [This is not mentioned in the article and was
required to make the "Booze Design-Starion" demo display properly. I can not
guarantee that this behaviour is true but I have seen the "Booze
Design-Starion" demo display properly on a real PAL C64 with the newer VIC
chip].
The following notes 7 and 8 are from Christian Bauer's VIC-II Article and
are known to be incomplete.
{
7. In the first phase of cycle 15, it is checked if the expansion flip flop
is set. If so, MCBASE is incremented by 2.
8. In the first phase of cycle 16, it is checked if the expansion flip flop
is set. If so, MCBASE is incremented by 1. After that, the VIC checks if
MCBASE is equal to 63 and turns of the DMA and the display of the sprite
if it is.
}
This is what I believe happens:
If a sprite expansion flip-flop is already set at the first phase of cycle
15 then the corresponding sprite pointer MCBASE will incremented by 3 by the
end of cycle 16. If the flip-flop transitions from clear to set at the
second phase of clock 15 then it appears that a "magic sprite pointer
increment" MSPI value gets added to MCBASE. It turns out that the value of
MSPI is variable depending on the value (MCBASE & 63). Someone on the VICE
team must have discovered the MSPI table. Here is the MSPI table taken from
VICE1.7.
const int vic_ii_sprites_crunch_table[64] =
{
1, 4, 3, /* 0 */
4, 1, 0, /* 3 */
-1, 0, 1, /* 6 */
4, 3, 4, /* 9 */
1, 8, 7, /* 12 */
8, 1, 4, /* 15 */
3, 4, 1, /* 18 */
0, -1, 0, /* 21 */
1, 4, 3, /* 24 */
4, 1, -8, /* 27 */
-9, -8, 1, /* 30 */
4, 3, 4, /* 33 */
1, 0, -1, /* 36 */
0, 1, 4, /* 39 */
3, 4, 1, /* 42 */
8, 7, 8, /* 45 */
1, 4, 3, /* 48 */
4, 1, 0, /* 51 */
-1, 0, 1, /* 54 */
4, 3, 4, /* 57 */
1, -40, -41, /* 60 */
0
};
As an example: if MCBASE is 62 and the flip-flop transitions from clear to
set at the second phase of clock 15 then MSPI will equal -41. MCBASE will
become 21 in cycle 16. This corresponds to
=((MCBASE - vic_ii_sprites_crunch_table[62 & 63]) & 63)
=((MCBASE - vic_ii_sprites_crunch_table[62]) & 63)
=((MCBASE - 41) & 63)
=21
Comments welcome
David
----- Original Message -----
From: "Stefano Tognon" <ice00@libero.it>
To: <support@hoxs64.com>
Sent: Saturday, December 03, 2005 12:39 PM
Subject: Vic II
> Hi,
>
> even if I don't use windows anymore, I always be happy to see some C64
> emulator progress, so your Hoxs64 is a great program!
>
>
> I just read at comp.sys.sbm thead about vic article
>
>> A couple of points are missing from the article. These points may seem
>> minor
>> compared with the huge amount of correct information in the doc.
>
>> 2) The explanation of what happens when writting to Sprite Y Expand
>> register
>> is not really wrong but is not the full story. I believe I have an
>>> answer
>> for this if anyone needs it.
>
> I'm interesting to know what do you think about the beaviour of this.
>
> I develop at java c64 emulator some time ago totally based onto vic
> article, but I stop to develop it when I see that Vic Article rules can't
> do all the stuff around the sprites.
>
> thanks
>
> bye
> Stefano Tognon
>
> --
> visit: http://digilander.iol.it/ice00
|
|
|
|
| Re: VIC-II [message #141879 is a reply to message #141872] |
Tue, 06 December 2005 04:37  |
Lars Haugseth
Messages: 231
Registered: April 2012
Karma: 0
|
Senior Member |
|
|
* "David Horrocks" <davidhorrocks@btinternet.com> wrote:
|
| const int vic_ii_sprites_crunch_table[64] =
| {
| 1, 4, 3, /* 0 */
| 4, 1, 0, /* 3 */
| -1, 0, 1, /* 6 */
| 4, 3, 4, /* 9 */
| 1, 8, 7, /* 12 */
| 8, 1, 4, /* 15 */
| 3, 4, 1, /* 18 */
| 0, -1, 0, /* 21 */
| 1, 4, 3, /* 24 */
| 4, 1, -8, /* 27 */
| -9, -8, 1, /* 30 */
| 4, 3, 4, /* 33 */
| 1, 0, -1, /* 36 */
| 0, 1, 4, /* 39 */
| 3, 4, 1, /* 42 */
| 8, 7, 8, /* 45 */
| 1, 4, 3, /* 48 */
| 4, 1, 0, /* 51 */
| -1, 0, 1, /* 54 */
| 4, 3, 4, /* 57 */
| 1, -40, -41, /* 60 */
| 0
| };
|
| As an example: if MCBASE is 62 and the flip-flop transitions from clear to
| set at the second phase of clock 15 then MSPI will equal -41. MCBASE will
| become 21 in cycle 16. This corresponds to
|
| =((MCBASE - vic_ii_sprites_crunch_table[62 & 63]) & 63)
| =((MCBASE - vic_ii_sprites_crunch_table[62]) & 63)
| =((MCBASE - 41) & 63)
| =21
|
| Comments welcome
Nice.
Is there some kind of logic to these numbers? Have they been confirmed
to be the same on different revisions of the C64 and VIC-II? And finally,
how were this numbers discovered? I guess it could be automated by using
sprite-to-sprite or sprite-to-background collision detection.
--
Lars Haugseth
|
|
|
|
| Re: VIC-II [message #141881 is a reply to message #141872] |
Tue, 06 December 2005 14:11 |
Andreas Boose
Messages: 46
Registered: September 2003
Karma: 0
|
Member |
|
|
On Tue, 6 Dec 2005 00:48:07 +0000 (UTC), "David Horrocks"
<davidhorrocks@btinternet.com> wrote:
> Someone on the VICE
> team must have discovered the MSPI table. Here is the MSPI table taken from
> VICE1.7.
>
>
> const int vic_ii_sprites_crunch_table[64] =
> {
> 1, 4, 3, /* 0 */
> 4, 1, 0, /* 3 */
Notice this table was first published in the demo Krestage by Crest.
If RUNSTOP is pressed in the second part, 64 sets of values are shown.
If you subtract the first from the trird value of each set, you will
get the table from the VICE source.
We verified the entries, but of course it is easier to verify
something (just try hard enough to get the same numbers) than to
retrive the values from scratch. I think it is time to add a comment
to the source to give some credit to Crest.
Of course the values are not random, but I never had the nerve to
deduce a formular from the table, as this is not necessary to improve
the quality of emulation. It might improve the understanding of the
counter though.
MfG Andreas
|
|
|
|
Members
Search
Help
Register
Login
Home
