Jump to content
IGNORED

Exact freq of the (NTSC) real-time/jiffy clock?


Recommended Posts

I recall reading a long time ago that the real-time/jiffy clock is not exactly 60 ticks (frames) per second. (NTSC). It's some small fraction off, but enough so that the clock noticeably deviates for intervals longer than a few minutes. Does anyone know the exact divisor for the real_seconds = jiffy_ticks / something.fraction formula??

Link to comment
Share on other sites

I don't know if this is what you mean, but on wiki article about NTSC is "frequency of approximately 59.94 Hz (actually 60 Hz/1.001)" so I assume that after 1000 seconds of realtime, you will count 1001 seconds on NTSC Atari when calculating 60 ticks per second. So after 16minutes and 40 seconds, the difference will be one second, almost 1,5 minutes per day.

Edited by MaPa
Link to comment
Share on other sites

You can work out the difference by dividing the CPU clock by number of cycles in a frame.

 

Or just look at the "Speed Options" in Altirra where it's already been done for us.

Actual frame rates are 59.9227 NTSC, 49.8607 PAL.

 

As mentioned, NTSC broadcast isn't 60, actually a little under at 59.97.

 

In order to maintain a more exact clock, there's various methods you could use.

Probably the easiest would be to insert "leap jiffies" at specific intervals so that a software clock resyncs to the real time.

PAL requires a "speedup" of 0.27937834807774459644569771383073 percent. Obviously you could throw away probably all but the first several significant digits of that to work out what's needed to make a reasonably accurate clock.

Link to comment
Share on other sites

The Atari's timing deviates from standard NTSC because does not invert the color subcarrier on each scan line (no half color cycle) and produces a non-interlaced display. The difference is noticeable if you try to synchronize music playback from an emulator running at 60Hz or 59.94Hz with a real Atari -- the two will diverge quickly.

 

Derivation of NTSC frame rate:

  • Color clock is at NTSC color subcarrier rate: 315/88MHz = 3.579545MHz
  • Machine clock: 3.579545MHz/2 = 1.7897725MHz
  • Horizontal scan rate: 1.7897725MHz / 114 = 15.69976KHz
  • Frame rate: 15.69976KHz / 262 = 59.9227Hz

The exact ratio should be 1640625/27379 frames per second, which gives an error of about a couple of minutes per day in time calcs that use 60.0Hz. Note that in order to match standard NTSC, the Atari would have to have 113.75 machine cycles per scan line and 262.5 scan lines per frame. Since this ain't an Apple II, we don't do goofy things like make every 65th cycle a seventh longer....

 

PAL derivation is similar, except starting with the PAL CPU clock and using 312 scan lines per frame instead of 262.

  • Like 2
Link to comment
Share on other sites

The other thing is the number of scanlines - 262 and 312 rather than .5 extra for broadcast.

 

Quick and dirty "leap jiffy" method that would make a soft-clock more accurate:

 

PAL - insert extra tick every 359

NTSC - insert extra tick every 776

 

Without doing further calculation, that would make timing somewhat more accurate but probably still off to the point of at least several seconds per day. An extra level of periodic correction would probably bring it to the point where you'd have something better than most cheap digital watches.

Link to comment
Share on other sites

Hi,

 

 

Quick and dirty "leap jiffy" method that would make a soft-clock more accurate:

 

PAL - insert extra tick every 359

NTSC - insert extra tick every 776

 

Without doing further calculation, that would make timing somewhat more accurate but probably still off to the point of at least several seconds per day.

 

If you want a better approximation, you can get an error of 4ppm using the fraction 13962/233 = 59.9227467811, this is the best fraction with denominator less than 256. Another good fraction is 56627/945 = 59.9227513228 with 0.3ppm of error, this is the best with numerator less than 65536.

 

Using the fraction 13962/233, a clock routine should be like:

        clc
        lda count
        adc #233
        sta count
        bcc noinc
        inc count+1
noinc:
        lda count
        cmp #<13962
        lda count+1
        sbc #>13962
        bcs end

        sta count+1
        sec
        lda count
        sbc #<13962
        sta count

        ; .... increment clock here.

Attached is a demo clock program using this code and incrementing the counter on the VBI.

 

Daniel.

 

clock.zip

Edited by dmsc
  • Like 2
Link to comment
Share on other sites

  • 3 months later...

I figure that a "perfect" 50 Hz jiffy counter would produce 4.320.000 jiffies per day whereas the actual PAL Atari produces 4.307.964.48.

 

If I divide the 4.307.964.48 by the missing 12.035,52 I'd need an extra jiffy every 357,94. Rounding up to 358 results in 12.033,42 "extra" jiffies, only about 2 short of the required correction. That could be fixed with an extra jiffy at noon and midnight.

 

I think it does not make sense to use the sytem RTCLCK at $12-14 to count as I can't figure a way to "overlay" the correction.

 

As my fridge shorted out last night I have to tend to more worldly chores today and can't try this out for now =;-o

Edited by slx
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...