kenjennings Posted November 1, 2014 Share Posted November 1, 2014 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?? Quote Link to comment Share on other sites More sharing options...
MaPa Posted November 1, 2014 Share Posted November 1, 2014 (edited) 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 November 1, 2014 by MaPa Quote Link to comment Share on other sites More sharing options...
Rybags Posted November 1, 2014 Share Posted November 1, 2014 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. Quote Link to comment Share on other sites More sharing options...
phaeron Posted November 1, 2014 Share Posted November 1, 2014 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. 2 Quote Link to comment Share on other sites More sharing options...
Rybags Posted November 1, 2014 Share Posted November 1, 2014 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. Quote Link to comment Share on other sites More sharing options...
dmsc Posted November 1, 2014 Share Posted November 1, 2014 (edited) 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 November 1, 2014 by dmsc 2 Quote Link to comment Share on other sites More sharing options...
+slx Posted February 19, 2015 Share Posted February 19, 2015 (edited) 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 February 21, 2015 by slx Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.