Accurate 2600 digital clock rom?

[godzillajoe]

Is there one that doesn't get out of sync in Windows Stella after a few minutes?

 

Not sure if it's the emu or the rom but every one I've tried doesn't stay synced to the Windows clock after a few minutes.

[Thomas Jentzsch]

No surprise. That would require 100% perfect emulation and a real-time OS.

[SeaGtGruff]

Is there one that doesn't get out of sync in Windows Stella after a few minutes?

 

Not sure if it's the emu or the rom but every one I've tried doesn't stay synced to the Windows clock after a few minutes.

It's probably the ROM, because most Atari 2600 programs that keep track of time generally assume a frame rate of 60 Hz, hence they update a seconds counter every 60 frames. But the actual frame rate on an Atari 2600 (with a 262-line display) is about 59.922751 Hz, so 60 Atari frames are equal to about 1.001289 seconds. After 388 "Atari seconds," the difference grows to about half of an actual second, so the difference starts to become noticeable after about 6.5 minutes. I'll see if I can write a quick bB program to create a more accurate timer. However, the emulator's frame rate will also be a factor, since I don't think it's equal to the Atari's frame rate, in which case a ROM that keeps pretty accurate time on a real Atari will still be inaccurate when run on an emulator.

 

Michael

[godzillajoe]

Is there one that doesn't get out of sync in Windows Stella after a few minutes?

 

Not sure if it's the emu or the rom but every one I've tried doesn't stay synced to the Windows clock after a few minutes.

It's probably the ROM, because most Atari 2600 programs that keep track of time generally assume a frame rate of 60 Hz, hence they update a seconds counter every 60 frames. But the actual frame rate on an Atari 2600 (with a 262-line display) is about 59.922751 Hz, so 60 Atari frames are equal to about 1.001289 seconds. After 388 "Atari seconds," the difference grows to about half of an actual second, so the difference starts to become noticeable after about 6.5 minutes. I'll see if I can write a quick bB program to create a more accurate timer. However, the emulator's frame rate will also be a factor, since I don't think it's equal to the Atari's frame rate, in which case a ROM that keeps pretty accurate time on a real Atari will still be inaccurate when run on an emulator.

 

Michael

 

 

I think I'll just use the Windows clock.

 

Just thought it would be cool using the Stella emu since the computer is right there and just loading the rom "resets" it.

 

But I guess not.

[+Propane13]

It's probably the ROM, because most Atari 2600 programs that keep track of time generally assume a frame rate of 60 Hz, hence they update a seconds counter every 60 frames. But the actual frame rate on an Atari 2600 (with a 262-line display) is about 59.922751 Hz, so 60 Atari frames are equal to about 1.001289 seconds. After 388 "Atari seconds," the difference grows to about half of an actual second, so the difference starts to become noticeable after about 6.5 minutes. I'll see if I can write a quick bB program to create a more accurate timer. However, the emulator's frame rate will also be a factor, since I don't think it's equal to the Atari's frame rate, in which case a ROM that keeps pretty accurate time on a real Atari will still be inaccurate when run on an emulator.

 

Michael

 

Actually, someone did make a ROM that I thought was extremely accurate (tested over a 24-hour period). This was years ago.

http://www.biglist.com/lists/stella/archiv...9/msg00044.html

 

-John

[+stephena]

Is there one that doesn't get out of sync in Windows Stella after a few minutes?

 

Not sure if it's the emu or the rom but every one I've tried doesn't stay synced to the Windows clock after a few minutes.

However, the emulator's frame rate will also be a factor, since I don't think it's equal to the Atari's frame rate, in which case a ROM that keeps pretty accurate time on a real Atari will still be inaccurate when run on an emulator.

 

Michael

Yes, this is correct, and for the second reason Thomas mentioned in a previous post. For an NTSC ROM, Stella syncs to 60fps, not 59.xxxx. It will never be possible to be this accurate on a system that doesn't have a real-time OS, and even if one did, the timing code in Stella would have to be rewritten (although the former is the more difficult problem to solve).

 

Theoretically, one could write an emulator that took over the entire system, essentially booting into the emulator itself. The emulator itself would be the OS, for example. In that case, perhaps a very accurate emulation could be created (wrt timing). But that's not something I'm interested in creating

[+Nathan Strum]

It'd probably be simpler to write something in Java that looked like a 2600 clock, if you just wanted something on your desktop.

[SeaGtGruff]

Actually, someone did make a ROM that I thought was extremely accurate (tested over a 24-hour period). This was years ago.

http://www.biglist.com/lists/stella/archiv...9/msg00044.html

 

-John

Thank you for the link, John! I downloaded the BIN and read the thread, but I think I'll skip doing a disassembly. I'd like to give it a try on my own, since it's something I've been curious about.

 

Michael

[SeaGtGruff]

For an NTSC ROM, Stella syncs to 60fps, not 59.xxxx.

Stephen, are you saying that Stella displays exactly 60 Atari frames per second? If that's the case, then an accurate Atari 2600 clock would be a snap if it's run *only* in the Stella emulator, since no adjustments would be necessary!

 

Michael

[godzillajoe]

It's probably the ROM, because most Atari 2600 programs that keep track of time generally assume a frame rate of 60 Hz, hence they update a seconds counter every 60 frames. But the actual frame rate on an Atari 2600 (with a 262-line display) is about 59.922751 Hz, so 60 Atari frames are equal to about 1.001289 seconds. After 388 "Atari seconds," the difference grows to about half of an actual second, so the difference starts to become noticeable after about 6.5 minutes. I'll see if I can write a quick bB program to create a more accurate timer. However, the emulator's frame rate will also be a factor, since I don't think it's equal to the Atari's frame rate, in which case a ROM that keeps pretty accurate time on a real Atari will still be inaccurate when run on an emulator.

 

Michael

 

Actually, someone did make a ROM that I thought was extremely accurate (tested over a 24-hour period). This was years ago.

http://www.biglist.com/lists/stella/archiv...9/msg00044.html

 

-John

 

It might be accurate on real hardware but in Stella it's already about 10 seconds off after just 3 minutes.

[TimsterAA]

I realize I may be complete idiot, but how do I use this rom with Stella? It doesn't seem to recognize it.

 

--Timster--

[+stephena]

For an NTSC ROM, Stella syncs to 60fps, not 59.xxxx.

Stephen, are you saying that Stella displays exactly 60 Atari frames per second? If that's the case, then an accurate Atari 2600 clock would be a snap if it's run *only* in the Stella emulator, since no adjustments would be necessary!

 

Michael

No, I'm saying it aims for 60fps, and it does so by 'doing' a frame and then waiting the remaining time. For example, at 60fps, each frame will take 16.6666... ms (ignore the rounding error for now). Now, most computers can do this work in much less than 16.7ms; my lowly 800MHz laptop takes about 3ms The rest of this time is spent waiting. However, there are several issues:

 

(1) we can't wait for sub-milliseconds (ie, 13.7, non integer values)

(2) we're not guaranteed to sleep for the time we do ask for

(3) the rounding mentioned above isn't taken into account

 

All these occur because we're not running on a real-time OS. And on top of that, even if we could be guaranteed to run/sleep at sub-millisecond accurate time, the real Atari didn't run at 60fps!

 

Anyway, sorry for the boring timing explanation. I'd say take the previous advice, and write a Java applet or something.

 

Edit: I forgot to mention, if you're using the latest version, and have access to OpenGL and vsync enabled drivers, you can turn on vertical synchronization, which syncs the OpenGL updates to the refresh rate of your monitor. If the monitor is running at 60Hz, you get a cleaner 60fps, and as a bonus, no tearing in the onscreen image.

Edited December 29, 2006 by stephena

[SeaGtGruff]

I realize I may be complete idiot, but how do I use this rom with Stella? It doesn't seem to recognize it.

 

--Timster--

It seems to be the same BIN as "Video Time Machine," at least that's what Stella 2.3 says it is when I run it. If you need the MD5, it's 93acd5020ae8eb5673601e2edecbc158. Which version of Stella are you trying to run it on?

 

Michael

[Urchlay]

 

All these occur because we're not running on a real-time OS. And on top of that, even if we could be guaranteed to run/sleep at sub-millisecond accurate time, the real Atari didn't run at 60fps!

 

Edit: I forgot to mention, if you're using the latest version, and have access to OpenGL and vsync enabled drivers, you can turn on vertical synchronization, which syncs the OpenGL updates to the refresh rate of your monitor. If the monitor is running at 60Hz, you get a cleaner 60fps, and as a bonus, no tearing in the onscreen image.

 

If you really wanted to, you could probably get your monitor to run at 59.922751 Hz. That plus vsync would get you a lot closer to accurate Atari timing.

 

It's easy in Linux, just edit your xorg.conf, fill in values from here: http://xtiming.sourceforge.net/cgi-bin/xtiming.pl

 

Unfortunately, very few Linux OpenGL drivers support vsync (last I checked, neither NVidia nor ATI's closed-source drivers did, but it's been a while since I looked).

 

I'm sure there's some registry editing you could do in Windows to set the refresh to 59.922751 Hz instead of 60... if someone knows how, post it here.

[AtariRx]

Ever so slightly off topic, but what ever happened to Video Time Machine? I have a signed and numbered cart from Hozer I had bought many years back, but when I looked it up in the AA guide for more info nothing came up. Just wondering.

[Thomas Jentzsch]

It seems to be the same BIN as "Video Time Machine," at least that's what Stella 2.3 says it is when I run it. If you need the MD5, it's 93acd5020ae8eb5673601e2edecbc158.

That ROM displays 272 scanlines, thus running at ~57.8Hz.

[SeaGtGruff]

Okay, here's my preliminary version of an Atari 2600 clock. Right now you can't set the time or date, so it's really just a timer, but my initial test runs on z26 and Stella seem to show that the timing is good-- i.e., if I watch the time on my VCR, the minutes keep changing whenever the Atari 2600 timer reaches a certain number of seconds. But I didn't watch it long enough to tell if the timer stays accurate after any length of time. The only reason I'm posting this preliminary version is so other people can try it out and let me know if the seconds count holds up over a period of time, since I won't be able to work on it any more until much later tonight.

 

I haven't studied any other timer/clock programs, so I don't know if my approach is original, but the way it works is by computing a "target" value for the frame counter, using an NTSC 262-line frame rate of about 59.92275 Hertz-- or to be exact, 59 and 25264/27379, which is the value I get when I divide the NTSC color clock frequency by 262 and 228 (i.e., the exact fraction is 1640625/27379, if you express all the numbers in prime factor form, combine them, and reduce to lowest terms). I'd struggled (on paper) with other approaches before I finally thought of the "target frame" approach, but I don't know if it's been used before.

 

I'm including the source, which is heavily commented, so hopefully it should be clear how it works-- but keep in mind that the program is horribly unfinished, and the code is a little messy in the second half because I was just trying to get something to display, and there were some dumb logic errors that I was trying different things to correct before I realized what the problems actually were.

 

My goal is to have a calendar and clock display, with the user being able to set the time (otherwise it wouldn't be much use!), and also including an alarm. For instance, I'd like to let the user pick a date and time when the alarm will be triggered, and maybe even display a programmable message when the alarm goes off-- perhaps with multiple alarm times, like a wake-up alarm at 7:00:00 AM, a TV show alarm at 8:00:00 PM, etc. Another option would be to have a countdown instead of a clock, so you could set it to count down to the New Year, or something like that. Or it can have a "stop watch" feature for things like timing something you're cooking for dinner.

 

Although the program is in batari BASIC, it includes some in-line assembly. I'm actually surprised that it seemed to work as well as it did on the emulators; but as I said, I didn't watch it for any long period of time yet (since I only just got it working a little while ago).

 

Michael

Alarm_Clock_Calendar_1.0.bas

Alarm_Clock_Calendar_1.0.bas.bin

[godzillajoe]

This is actually quite accurate but it does crash randomly. The longest I had it run so far is 9 minutes and 40 seconds.

 

But it did stay in sync until that point.

[SeaGtGruff]

This is actually quite accurate but it does crash randomly. The longest I had it run so far is 9 minutes and 40 seconds.

 

But it did stay in sync until that point.

When you say it crashes randomly, could you describe what happens when it crashes? I just let it run and it stopped at 9 minutes and 40 seconds, so I'll look to see what's going on. Is that what you were talking about? ("Randomly" implies that it crashes at different times, so I want to be sure I find out about any and all buggy behavior.) And by the way, thank you for checking it out for me!

 

Tonight I worked out the numbers to use for a 312-line display on a PAL Atari 2600, and I also began to sketch out (on paper) a calendar display for the program. I'm also going to draw a clock face in a paint program, and convert it to a pixel resolution and aspect ratio that's (hopefully) equivalent to an NTSC Atari 2600 screen. Of course, first I need to focus on getting an actual digital clock display (as opposed to a timer), and add the ability to set the time.

 

Michael

[supercat]

It will never be possible to be this accurate on a system that doesn't have a real-time OS...

 

Why not? If one's objective was long-term accuracy, the thing could be as accurate as the system's clock with logic like the following:

 double next_frame_time,delta;

 next_frame_time = current_time();
 do  /* Start of frame loop */
 {
draw_frame();
next_frame_time += scan_lines * 228.0 / 3579545.45;
delta = next_frame_time - current_time();
if (delta > 0.0)
  delay_seconds(delta);
 }

 

Note that if some frames took longer than they should, subsequent frames would run as fast as possible until the emulation caught up. This would be annoying if one were playing a game, but would be just the ticket for accurate long-term timekeeping.

 

To avoid such annoyance, the game could include two or more timekeeping methods:

 double next_frame_time,next_frame_time2,delta,delta2;

 next_frame_time = current_time();
 do  /* Start of frame loop */
 {
next_frame_time2 = current_time() + scan_lines * 220.0 / 379545.45;  /* A little shorter than 'proper' time */
draw_frame();
next_frame_time += scan_lines * 228.0 / 3579545.45;
delta = next_frame_time - current_time();
delta2 =- current_time;
if (delta2 > delta)
  delta = delta2;
if (delta > 0.0)
  delay_seconds(delta);
 }

Here, the maximum allowable speed, even following a lag, would be 220 cycles/scan line. This would avoid disruption of gameplay, but would nonetheless allow the system to regain any time lost in occasional hiccups.

 

No real-time OS required.

[godzillajoe]

This is actually quite accurate but it does crash randomly. The longest I had it run so far is 9 minutes and 40 seconds.

 

But it did stay in sync until that point.

When you say it crashes randomly, could you describe what happens when it crashes? I just let it run and it stopped at 9 minutes and 40 seconds, so I'll look to see what's going on. Is that what you were talking about? ("Randomly" implies that it crashes at different times, so I want to be sure I find out about any and all buggy behavior.) And by the way, thank you for checking it out for me!

 

Tonight I worked out the numbers to use for a 312-line display on a PAL Atari 2600, and I also began to sketch out (on paper) a calendar display for the program. I'm also going to draw a clock face in a paint program, and convert it to a pixel resolution and aspect ratio that's (hopefully) equivalent to an NTSC Atari 2600 screen. Of course, first I need to focus on getting an actual digital clock display (as opposed to a timer), and add the ability to set the time.

 

Michael

 

Yeah it just stopped. Once at 9:40 and maybe once at 3:??

 

I don't remember exactly anymore and I can't be 100% sure I didn't minimize Stella

 

I did notice that minimizing Stella brings any rom to a screeching halt.

 

But the stoppage at 9:40 was certainly not from that as I intended to let it run for 20 minutes and see how in sync it was. When I came back to check on it it was frozen.

[Urchlay]

It will never be possible to be this accurate on a system that doesn't have a real-time OS...

 

Why not? If one's objective was long-term accuracy, the thing could be as accurate as the system's clock with logic like the following:

 

(code removed)

 

No real-time OS required.

 

...except that non-realtime OSes typically don't provide anywhere near that level of accuracy for the system clock. You call your hypothetical delay_seconds(1.23456), but it'll actually delay for an even number of "ticks" (1.2 or 1.25 seconds maybe).

 

You could do it with some hardware support, like the TSC register in the Pentium (and up), or the HPET timer on newer motherboards... but you'd be tied to one hardware platform and one OS (which may not matter to you), or you'd be writing (and debugging, and supporting) many different platform-dependent versions of the timing loop.

 

You could also do it by running at high priority, and instead of using a system sleep() or delay() routine, write a tight loop:

 

while(get_current_time() < next_frame_time)
 /* do nothing */;

 

...but that'd be really annoying for users who want to do anything else at the same time (and if someone has a cheap crappy CPU fan, it might melt the CPU). Also, how you set high priority is platform-dependent, though usually it's a simple function call... but your program might have to run as administrator/root/etc, which means you now have a moral responsibility to audit your code for security holes (yes, my brain really does work this way, I can't help it).

 

Also, on some OSes, the local equivalent of get_local_time() suffers from the same problem as sleep()-like calls: it'll have a granularity of some fixed fraction of a second (say, 0.05 seconds, or 0.01, or whatever), and nothing you can do will make it ever return a value that's not a multiple of that fraction of a second.

 

Most of this discussion came from painful experience acquired while porting z26 to Linux (and BSD)... there are ways to work around all these issues, but it's not as simple as I expected it to be.

 

OK, end of rant, sorry about that...

[+stephena]

It will never be possible to be this accurate on a system that doesn't have a real-time OS...

 

Why not? If one's objective was long-term accuracy, the thing could be as accurate as the system's clock with logic like the following:

 double next_frame_time,delta;

 next_frame_time = current_time();
 do  /* Start of frame loop */
 {
draw_frame();
next_frame_time += scan_lines * 228.0 / 3579545.45;
delta = next_frame_time - current_time();
if (delta > 0.0)
  delay_seconds(delta);
 }

 

Note that if some frames took longer than they should, subsequent frames would run as fast as possible until the emulation caught up. This would be annoying if one were playing a game, but would be just the ticket for accurate long-term timekeeping.

Note that there is something like this is Stella. If one frame goes too slow, the subsequent ones run as fast as possible to make sure the average framerate stays the same. However, delaying for a specific value is the problem, as explained by Urchlay above in greater detail.

Edited December 30, 2006 by stephena

[+stephena]

Yeah it just stopped. Once at 9:40 and maybe once at 3:??

 

I don't remember exactly anymore and I can't be 100% sure I didn't minimize Stella

 

I did notice that minimizing Stella brings any rom to a screeching halt.

 

But the stoppage at 9:40 was certainly not from that as I intended to let it run for 20 minutes and see how in sync it was. When I came back to check on it it was frozen.

Minimizing a ROM causes it to be paused; you have to unpause it again to continue playing (PAUSE key on most systems). I suppose I should add some sort of indicator telling that we're actually paused, and not locked up. In all likelyhood, unpausing would have allowed the ROM to continue normally.

[+stephena]

You could also do it by running at high priority, and instead of using a system sleep() or delay() routine, write a tight loop:

 

while(get_current_time() < next_frame_time)
 /* do nothing */;

 

...but that'd be really annoying for users who want to do anything else at the same time (and if someone has a cheap crappy CPU fan, it might melt the CPU).

It's also terrible for my laptop, since I specifically bought it because it's a low-power Intel chip that can run silently (ie, no fans). Pegging the CPU like that causes the fan to cut in, which is quite annoying. Also, on the GP2X and WinCE devices, doing this would kill the batteries much faster. Stella doesn't work on the just the desktop.