NTSC VIC-II timing

classic Classic list List threaded Threaded
51 messages Options
123
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

NTSC VIC-II timing

silverdr-2
According to the famous document by Chris Bauer, there are three timing variants of the VIC-II. While PAL is always 63 cycles per  line, with NTSC there can be either 64 or 65 cycles per line and I am in fact able to reproduce the difference with -model ntsc and -model oldntsc in the current VICE.

The question (before I spend weekend on trial'n error counting cycles and possibly reinventing the hammer ;-) is: do we have ane established, reliable software method for detecting which NTSC VIC-II is installed in the machine? I guess it must have been done multiple times by now and used in some NTSC games/demos..

--
SD! - http://e4aws.silverdr.com/


       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: NTSC VIC-II timing

Groepaz
On Wednesday 21 June 2017, 16:40:03 [hidden email] wrote:

> According to the famous document by Chris Bauer, there are three timing
> variants of the VIC-II. While PAL is always 63 cycles per  line, with NTSC
> there can be either 64 or 65 cycles per line and I am in fact able to
> reproduce the difference with -model ntsc and -model oldntsc in the current
> VICE.
>
> The question (before I spend weekend on trial'n error counting cycles and
> possibly reinventing the hammer ;-) is: do we have ane established,
> reliable software method for detecting which NTSC VIC-II is installed in
> the machine? I guess it must have been done multiple times by now and used
> in some NTSC games/demos..

most demos or games probably dont care about detecting the difference - as the
64 cycle VIC is extremely rare.

however, iirc on codebase there are some detection routines. basically just
count the cycles for a line (or a frame) using a CIA timer.

--

http://www.hitmen-console.org    http://magicdisk.untergrund.net
http://www.pokefinder.org        http://ar.pokefinder.org

The weirder you are going to behave, the more normal you should look... When I
see a kid with three or four rings in his nose, I know there is absolutely
nothing extraordinary about that person.
<P.J. O'Rourke>



       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: NTSC VIC-II timing

silverdr-2

> On 2017-06-21, at 17:01, [hidden email] wrote:
>
>> According to the famous document by Chris Bauer, there are three timing
>> variants of the VIC-II. While PAL is always 63 cycles per  line, with NTSC
>> there can be either 64 or 65 cycles per line and I am in fact able to
>> reproduce the difference with -model ntsc and -model oldntsc in the current
>> VICE.
>>
>> The question (before I spend weekend on trial'n error counting cycles and
>> possibly reinventing the hammer ;-) is: do we have ane established,
>> reliable software method for detecting which NTSC VIC-II is installed in
>> the machine? I guess it must have been done multiple times by now and used
>> in some NTSC games/demos..
>
> most demos or games probably dont care about detecting the difference - as the
> 64 cycle VIC is extremely rare.

Maybe I am impractical indeed, yet I can't envision a commercial product (game f.e.) that would just break because the machine has a different but still valid VIC chip inside.

> however, iirc on codebase there are some detection routines.

I found a routine on codebase that is supposed to distinguish between the NMOS and HMOS variants of the PAL VIC:

http://codebase64.org/doku.php?id=base:detect_vic_type

interesting in its own if it works, but that's not what I need.

> basically just count the cycles for a line (or a frame) using a CIA timer.

Exactly what I meant with spending lots of time counting cycles ;-)

--
SD! - http://e4aws.silverdr.com/


       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: NTSC VIC-II timing

Groepaz
On Wednesday 21 June 2017, 18:12:12 [hidden email] wrote:

> > On 2017-06-21, at 17:01, [hidden email] wrote:
> >> According to the famous document by Chris Bauer, there are three timing
> >> variants of the VIC-II. While PAL is always 63 cycles per  line, with
> >> NTSC
> >> there can be either 64 or 65 cycles per line and I am in fact able to
> >> reproduce the difference with -model ntsc and -model oldntsc in the
> >> current
> >> VICE.
> >>
> >> The question (before I spend weekend on trial'n error counting cycles and
> >> possibly reinventing the hammer ;-) is: do we have ane established,
> >> reliable software method for detecting which NTSC VIC-II is installed in
> >> the machine? I guess it must have been done multiple times by now and
> >> used
> >> in some NTSC games/demos..
> >
> > most demos or games probably dont care about detecting the difference - as
> > the 64 cycle VIC is extremely rare.
>
> Maybe I am impractical indeed, yet I can't envision a commercial product
> (game f.e.) that would just break because the machine has a different but
> still valid VIC chip inside.

but thats how it is :) or well perhaps not - it never was a real problem,
because in the early days games wouldnt use anything that needs that perfect
timing. and as said, the 64 cycles VIC is so rare, you can just ignore it.

that said - think of the "drean" PAL VIC - there is not one game that was
fixed for it :)

> > however, iirc on codebase there are some detection routines.
>
> I found a routine on codebase that is supposed to distinguish between the
> NMOS and HMOS variants of the PAL VIC:
>
> http://codebase64.org/doku.php?id=base:detect_vic_type
>
> interesting in its own if it works, but that's not what I need.
>
> > basically just count the cycles for a line (or a frame) using a CIA timer.
>
> Exactly what I meant with spending lots of time counting cycles ;-)

well, there is no other way :) it isnt a problem in practise though, imho

--

http://www.hitmen-console.org    http://magicdisk.untergrund.net
http://www.pokefinder.org        http://ar.pokefinder.org

Trying to outsmart a compiler defeats much of the purpose of using one.
<Kernighan & Plauger>



       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: NTSC VIC-II timing

Spiro Trikaliotis
In reply to this post by silverdr-2
Hello,

* On Wed, Jun 21, 2017 at 06:12:12PM +0200 [hidden email] wrote:

> > most demos or games probably dont care about detecting the difference - as the
> > 64 cycle VIC is extremely rare.
>
> Maybe I am impractical indeed, yet I can't envision a commercial
> product (game f.e.) that would just break because the machine has a
> different but still valid VIC chip inside.

There were commercial products that just broke because the user had the
-02 KERNAL ROM in the C64, setting the text color to the background
color whenver the screen was cleared.

The -02 KERNAL was much more widespread the the old NTSC VIC-II.

Thus, your argument is not completely valid, because they just did it.

Regards,
Spiro.

--
Spiro R. Trikaliotis
http://www.trikaliotis.net/

       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: NTSC VIC-II timing

Marko Mäkelä
In reply to this post by silverdr-2
On Wed, Jun 21, 2017 at 04:40:03PM +0200, [hidden email] wrote:
>According to the famous document by Chris Bauer, there are three timing
>variants of the VIC-II. While PAL is always 63 cycles per  line, with
>NTSC there can be either 64 or 65 cycles per line and I am in fact able
>to reproduce the difference with -model ntsc and -model oldntsc in the
>current VICE.

You should have the 6567R56A and 6567R8 that I gave you, right?

>The question (before I spend weekend on trial'n error counting cycles
>and possibly reinventing the hammer ;-) is: do we have ane established,
>reliable software method for detecting which NTSC VIC-II is installed
>in the machine? I guess it must have been done multiple times by now
>and used in some NTSC games/demos..

The simple way is to disable interrupts and write a loop that samples
$d012, counting the cycles that go between changes. I do not know if
exactly such implementation is available anywhere.

Andreas Boose introduced me to an algorithm that first does a "coarse"
synchronization, like this:

        sei
        lda $d012
        bit $d012
        bne .-2

This creates a jitter of 4+3=7 cycles, assuming that .-2 is on the same
page than .+2 (the bne takes 3 cycles until the loop is exited).

Then, for 7 lines, spend N_CYCLES_PER_LINE-1, sampling $d012 at the end
of each iteration. Do a conditional branch to .+2 (relative offset $00)
if you were ahead of the schedule. After these 7 lines, you should be in
perfect sync (a deterministic number of cycles have elapsed since $d012
last changed).

You should revise this algorithm so that it can somehow detect the
N_CYCLES_PER_LINE, which can be 63 (PAL), 64 (6567R56A), or 65 (6569).

One possibility could be to start a CIA timer after the coarse
synchronization, but bear in mind that there are some differences in the
CIA timer operation. I think that it is doable with the processor only.

        Marko

       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: NTSC VIC-II timing

Marko Mäkelä
In reply to this post by silverdr-2
On Wed, Jun 21, 2017 at 06:12:12PM +0200, [hidden email] wrote:
>Exactly what I meant with spending lots of time counting cycles ;-)

Some KERNAL versions do the counting for you. If I remember correctly,
R1 does not, but later ones do. I would guess that the R1 is as rare as
the 6567R56A.

The later KERNAL counts the number of cycles per line and then sets some
flag to indicate whether the machine is PAL or NTSC.

The old NTSC VIC-II has 64*262 cycles per frame and the later ones have
65*263.

        Marko

       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: NTSC VIC-II timing

Groepaz
In reply to this post by Marko Mäkelä
On Wednesday 21 June 2017, 19:27:48 Marko Mäkelä <[hidden email]> wrote:

> On Wed, Jun 21, 2017 at 04:40:03PM +0200, [hidden email] wrote:
> >According to the famous document by Chris Bauer, there are three timing
> >variants of the VIC-II. While PAL is always 63 cycles per  line, with
> >NTSC there can be either 64 or 65 cycles per line and I am in fact able
> >to reproduce the difference with -model ntsc and -model oldntsc in the
> >current VICE.
>
> You should have the 6567R56A and 6567R8 that I gave you, right?
>
> >The question (before I spend weekend on trial'n error counting cycles
> >and possibly reinventing the hammer ;-) is: do we have ane established,
> >reliable software method for detecting which NTSC VIC-II is installed
> >in the machine? I guess it must have been done multiple times by now
> >and used in some NTSC games/demos..
>
> The simple way is to disable interrupts and write a loop that samples
> $d012, counting the cycles that go between changes. I do not know if
> exactly such implementation is available anywhere.
[snip]

i wouldnt call that exactly simple :) counting cycles always needs to be cycle
exact code - which is far from that.

instead, simply check the number of scanlines -
http://codebase64.org/doku.php?id=base:detect_pal_ntsc has a couple examples

--

http://www.hitmen-console.org    http://magicdisk.untergrund.net
http://www.pokefinder.org        http://ar.pokefinder.org

Very few people do anything creative after the age of thirty-five. The reason
is that very few people do anything creative before the age of thirty-five
<Joel Hildebrand>



       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: NTSC VIC-II timing

silverdr-2
In reply to this post by Spiro Trikaliotis

> On 2017-06-21, at 18:25, Spiro Trikaliotis <[hidden email]> wrote:
>
>>> most demos or games probably dont care about detecting the difference - as the
>>> 64 cycle VIC is extremely rare.
>>
>> Maybe I am impractical indeed, yet I can't envision a commercial
>> product (game f.e.) that would just break because the machine has a
>> different but still valid VIC chip inside.
>
> There were commercial products that just broke because the user had the
> -02 KERNAL ROM in the C64, setting the text color to the background
> color whenver the screen was cleared.
>
> The -02 KERNAL was much more widespread the the old NTSC VIC-II.
>
> Thus, your argument is not completely valid, because they just did it.

I understand (and know, in fact). But it seems I wasn't entirely clear. The sentence should be read as: "I can't envision [myself writing] a commercial product (game f.e.) that would just break because the machine has a different but still valid VIC chip inside". Not that I am writing one now ;-) but the old habits never die...

--
SD! - http://e4aws.silverdr.com/


       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: NTSC VIC-II timing

Groepaz
In reply to this post by Marko Mäkelä
On Wednesday 21 June 2017, 19:33:00 Marko Mäkelä <[hidden email]> wrote:
> On Wed, Jun 21, 2017 at 06:12:12PM +0200, [hidden email] wrote:
> >Exactly what I meant with spending lots of time counting cycles ;-)
>
> Some KERNAL versions do the counting for you. If I remember correctly,
> R1 does not, but later ones do. I would guess that the R1 is as rare as
> the 6567R56A.
>
> The later KERNAL counts the number of cycles per line and then sets some
> flag to indicate whether the machine is PAL or NTSC.

the kernal routine is buggy though, and sometimes gives wrong result - which
is why crackers started using their own detection routines sometime in late
80s :)

--

http://www.hitmen-console.org    http://magicdisk.untergrund.net
http://www.pokefinder.org        http://ar.pokefinder.org

Atheism is a nonprophet organization.
<Steve Wright>



       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: NTSC VIC-II timing

Spiro Trikaliotis
In reply to this post by silverdr-2
Hello,

* On Wed, Jun 21, 2017 at 06:35:24PM +0200 [hidden email] wrote:
 
> I understand (and know, in fact). But it seems I wasn't entirely
> clear. The sentence should be read as: "I can't envision [myself
> writing] a commercial product (game f.e.) that would just break
> because the machine has a different but still valid VIC chip inside".
> Not that I am writing one now ;-) but the old habits never die...

But now, we know of all these variants, so we can take them into
account. Back in the days, I suspect most people did not know about
these differences.

Regards,
Spiro.

--
Spiro R. Trikaliotis
http://www.trikaliotis.net/

       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: NTSC VIC-II timing

silverdr-2
In reply to this post by Groepaz

> On 2017-06-21, at 18:25, [hidden email] wrote:
>
>>> basically just count the cycles for a line (or a frame) using a CIA timer.
>>
>> Exactly what I meant with spending lots of time counting cycles ;-)
>
> well, there is no other way :) it isnt a problem in practise though, imho

I understand. Just thought the problem's been solved before so I could just reuse what's already been done.

--
SD! - http://e4aws.silverdr.com/


       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: NTSC VIC-II timing

Gerrit Heitsch
In reply to this post by Marko Mäkelä
On 06/21/2017 06:27 PM, Marko Mäkelä wrote:

> On Wed, Jun 21, 2017 at 04:40:03PM +0200, [hidden email] wrote:
>> According to the famous document by Chris Bauer, there are three
>> timing variants of the VIC-II. While PAL is always 63 cycles per  
>> line, with NTSC there can be either 64 or 65 cycles per line and I am
>> in fact able to reproduce the difference with -model ntsc and -model
>> oldntsc in the current VICE.
>
> You should have the 6567R56A and 6567R8 that I gave you, right?
>
>> The question (before I spend weekend on trial'n error counting cycles
>> and possibly reinventing the hammer ;-) is: do we have ane
>> established, reliable software method for detecting which NTSC VIC-II
>> is installed in the machine? I guess it must have been done multiple
>> times by now and used in some NTSC games/demos..
>
> The simple way is to disable interrupts and write a loop that samples
> $d012, counting the cycles that go between changes. I do not know if
> exactly such implementation is available anywhere.

Before you do that, check if there are other software detectable
differences between the 6567R56A (and older) and the 6567R7 (and newer).
Those might be easier to detect.

I suggest this since it's possible by software if you have a 6569R1 or a
later VIC and if later, if it's a 6569 or a 8565.

Here's what Segher wrote about it:

Excellent fun!  It sees if the light pen interrupt can be triggered
between raster lines x'136 and 2; if so, it's a 6569R1, if not, not.

The 8565 vs. 6569 test seems to be if sprite-background collision
is triggered for a sprite with ECM colour 2 (bits 10) (on 8565 it
is, on 6569 not).




  Gerrit





       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: NTSC VIC-II timing

silverdr-2
In reply to this post by Marko Mäkelä

> On 2017-06-21, at 18:27, Marko Mäkelä <[hidden email]> wrote:
>
> On Wed, Jun 21, 2017 at 04:40:03PM +0200, [hidden email] wrote:
>> According to the famous document by Chris Bauer, there are three timing variants of the VIC-II. While PAL is always 63 cycles per  line, with NTSC there can be either 64 or 65 cycles per line and I am in fact able to reproduce the difference with -model ntsc and -model oldntsc in the current VICE.
>
> You should have the 6567R56A and 6567R8 that I gave you, right?

I should. Although it might be hard to quickly recall where. I still haven't entirely arranged the stuff I brought back from those two trips ;-) I shall have to find it eventually in order to test on the real hardware.

>> The question (before I spend weekend on trial'n error counting cycles and possibly reinventing the hammer ;-) is: do we have ane established, reliable software method for detecting which NTSC VIC-II is installed in the machine? I guess it must have been done multiple times by now and used in some NTSC games/demos..
>
> The simple way is to disable interrupts and write a loop that samples $d012, counting the cycles that go between changes.

Yes but we talk about a difference of 1 cycle per line so it seems impractical to do lots of init in order to get one cycle-exact. It should be easier to count frame cycles, where the difference is going to be orders of magnitude bigger and should not require such exact synchronisation.

> One possibility could be to start a CIA timer after the coarse synchronization, but bear in mind that there are some differences in the CIA timer operation. I think that it is doable with the processor only.

What kind of differences [if I set it to count CPU cycles]?

--
SD! - http://e4aws.silverdr.com/


       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: NTSC VIC-II timing

silverdr-2
In reply to this post by Groepaz

> On 2017-06-21, at 18:34, [hidden email] wrote:
>
>> The simple way is to disable interrupts and write a loop that samples
>> $d012, counting the cycles that go between changes. I do not know if
>> exactly such implementation is available anywhere.
> [snip]
>
> i wouldnt call that exactly simple :) counting cycles always needs to be cycle
> exact code - which is far from that.
>
> instead, simply check the number of scanlines -

It's could be expected but I only now noticed that the two NTSC variants in question differ also in number of scanlines. Difference, which may possibly be used to detect the variants similarly to the method used for PAL/NTSC detection.

--
SD! - http://e4aws.silverdr.com/


       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: NTSC VIC-II timing

Groepaz
On Wednesday 21 June 2017, 18:53:45 [hidden email] wrote:

> > On 2017-06-21, at 18:34, [hidden email] wrote:
> >> The simple way is to disable interrupts and write a loop that samples
> >> $d012, counting the cycles that go between changes. I do not know if
> >> exactly such implementation is available anywhere.
> >
> > [snip]
> >
> > i wouldnt call that exactly simple :) counting cycles always needs to be
> > cycle exact code - which is far from that.
> >
> > instead, simply check the number of scanlines -
>
> It's could be expected but I only now noticed that the two NTSC variants in
> question differ also in number of scanlines. Difference, which may possibly
> be used to detect the variants similarly to the method used for PAL/NTSC
> detection.

yup, look at the "graham method" on that codebase page - it cant get any
simpler :)

--

http://www.hitmen-console.org    http://magicdisk.untergrund.net
http://www.pokefinder.org        http://ar.pokefinder.org

It is essential to understand that everybody sucked in the beginning.
<Kristofer Dahl>



       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: NTSC VIC-II timing

silverdr-2
In reply to this post by Gerrit Heitsch

> On 2017-06-21, at 18:43, Gerrit Heitsch <[hidden email]> wrote:
>
> Before you do that, check if there are other software detectable differences between the 6567R56A (and older) and the 6567R7 (and newer). Those might be easier to detect.

As just noticed - there is a difference in the number of scan lines, which might in fact be easier to abuse.

> I suggest this since it's possible by software if you have a 6569R1 or a later VIC and if later, if it's a 6569 or a 8565.
>
> Here's what Segher wrote about it:
>
> Excellent fun!  It sees if the light pen interrupt can be triggered
> between raster lines x'136 and 2; if so, it's a 6569R1, if not, not.

That's very interesting too! How does one trigger LP IRQ from within software alone? Is it a kind of raster position / CIA port combination?

> The 8565 vs. 6569 test seems to be if sprite-background collision
> is triggered for a sprite with ECM colour 2 (bits 10) (on 8565 it
> is, on 6569 not).

Yes, that one I've seen.

--
SD! - http://e4aws.silverdr.com/


       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: NTSC VIC-II timing

Gerrit Heitsch
On 06/21/2017 07:12 PM, [hidden email] wrote:
>
>> On 2017-06-21, at 18:43, Gerrit Heitsch <[hidden email]> wrote:
>>
>> Before you do that, check if there are other software detectable differences between the 6567R56A (and older) and the 6567R7 (and newer). Those might be easier to detect.
>
> As just noticed - there is a difference in the number of scan lines, which might in fact be easier to abuse.

Yes, see if the line counter max values differ between them.


>> I suggest this since it's possible by software if you have a 6569R1 or a later VIC and if later, if it's a 6569 or a 8565.
>>
>> Here's what Segher wrote about it:
>>
>> Excellent fun!  It sees if the light pen interrupt can be triggered
>> between raster lines x'136 and 2; if so, it's a 6569R1, if not, not.
>
> That's very interesting too! How does one trigger LP IRQ from within software alone? Is it a kind of raster position / CIA port combination?

Well, the LP Input is connected to the joystick ports and shares a Pin
with PB4 of the CIA on U1. So you can trigger LP IRQs via software.

  Gerrit


       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: NTSC VIC-II timing

silverdr-2
In reply to this post by Groepaz

> On 2017-06-21, at 19:01, [hidden email] wrote:
>
>> It could be expected but I only now noticed that the two NTSC variants in
>> question differ also in number of scanlines. Difference, which may possibly
>> be used to detect the variants similarly to the method used for PAL/NTSC
>> detection.
>
> yup, look at the "graham method" on that codebase page - it cant get any
> simpler :)

That's basically the solution I was looking for, thanks.

--
SD! - http://e4aws.silverdr.com/


       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: NTSC VIC-II timing

silverdr-2
In reply to this post by Gerrit Heitsch

> On 2017-06-21, at 19:17, Gerrit Heitsch <[hidden email]> wrote:
>
>>> Excellent fun!  It sees if the light pen interrupt can be triggered
>>> between raster lines x'136 and 2; if so, it's a 6569R1, if not, not.
>> That's very interesting too! How does one trigger LP IRQ from within software alone? Is it a kind of raster position / CIA port combination?
>
> Well, the LP Input is connected to the joystick ports and shares a Pin with PB4 of the CIA on U1.

Hardware side sure. What I meant was...

> So you can trigger LP IRQs via software.

... that I never used LP IRQs but thought that it would trigger only when the button line is grounded within a specific timing window so some kind of synchronisation with raster position would be required for the IRQ to happen. But that's a different subject anyway.

--
SD! - http://e4aws.silverdr.com/


       Message was sent through the cbm-hackers mailing list
123
Loading...