fastbasic Question about fastbasic TIME command

[markmiller]

I'm running into an issue with the TIME command. I'm using Ver. 4.6.

 

I've been running some benchmarks in fastbasic, and on a couple of the really long ones, the output is dramatically off. One example, I had a process running for 30 min's, and TIME/60/60 reported that about 8 min's had elapsed!

 

I just ran another process as a test, for 35 min's, and TIME/60 reports 224.816666 seconds (3.7 min's).

 

The coding pattern I've used with it is I start off the process with TIMER, to reset the registers, let the process run, and then get TIME at the end. I do not include TIMER in any loops.

 

It seems like the value is rolling over. Is the command only intended for processes that might run for 10 min's?

[+skr]

See how damn fast FB really is 😆

[TGB1718]

Maybe just use the system locations at 18,19 and 20 if it's causing issues  

 

[Rybags]

It would be fair to assume it uses the frame counter as basis - but in both PAL and NTSC cases it is slightly out, slower than broadcast and slower than 50/60 FPS.

But what you describe is out by orders of magnitude rather than the small % factor you'd get over that time period by counting frames.

 

Assuming a 16 bit counter only, 65535 frames in NTSC would equate to about 1092 seconds or 18 minutes.

Possibly it uses only the positive part of a signed integer which would equal half that.

 

Maybe trim your BM down such that it executes in about 7 minutes and see what the result is (hint - do it in Altirra so you can use the F1 turbo button so you're running in seconds rather than minutes - although running much quicker the time result will still reflect what real hardware would see)

Edited May 4 by Rybags

[vitoco]

The point is that FastBasic uses signed integer algebra, so it will count up to 32767 jiffies, whichever the time it takes (655 seconds for PAL, 546 seconds for NTSC). Then, the time jumps to -32768 and counts back to zero.

 

TIME and TIMER uses only adresses 20 and 19 of RTCLOK register. Address 18 is ignored.

 

If you want a 24-bits timer, you should use floating point version of FastBasic with an FP variable and an expression like:

T%=(65536.0*PEEK(18)+256*PEEK(19)+PEEK(20))/60/60
PRINT T%

 

To test that with higher values, initialize RTCLOK like this:

POKE 20,0:POKE 19,254:POKE 18,254

 

To reset that FP timer, you should use:

POKE 20,0:DPOKE 18,0

 

This should be avoided:

MSET 18,3,0

because it could happen that address 18 or 19 could change to 1 just after being updated to 0 and before address 20 is set to 0.

 

Edited May 4 by vitoco

[markmiller]

@vitoco - The longer benchmarks were, of course, putting the Atari into attract mode. Since I like to check in on their progress, I'd tap the space bar. I was wondering for a bit if that was affecting fastbasic's clock routine, but after doing a test on it, not touching the keyboard for about a half-hour, and then getting the time, I was seeing the same thing. I had the suspicion that it was just using a shorter version of the clock registers. Thanks for confirming that.

 

Kinda interesting about your suggestion that I use a floating-point formula. I've been using that same formula in Forth, since I've been running the same benchmarks on it, and I needed times that could go up to hours. This method of getting the time has worked out well.

[dmsc]

Hi all!

 

I just added a clarification in the manual to the 9 minute limit of the TIME variable, and the next version will feature a "%TIME" that returns the number in floating point, so it will not wrap until more than 3 days, you can use like:

 

START% = %TIME

Exec MyLongBenchmark

? "Ellapsed: "; %TIME - START%

 

I selected the name "%TIME" to not clash with any existing variable, also using "TIME%" is problematic as it is confused by the parser with "TIME".

 

A few weeks ago I also added a "workflow" on github that automatically compiles and test FastBasic for the Atari, Linux, MacOS and Windows, and automatically uploads the results. For example, the last compilation with those changes is over here https://github.com/dmsc/fastbasic/actions/runs/8963403908 , you can download the different versions from that page (the "artifacts" at the bottom). Note that those version are not the same as the releases, as they have debugging enabled and correspond to the current development.

 

Have Fun!

 

[vitoco]

19 minutes ago, dmsc said:

the next version will feature a "%TIME" that returns the number in floating point, so it will not wrap until more than 3 days

What about TIMER? Will it reset all 3 bytes of RTCLOK?

[dmsc]

Hi!

22 hours ago, vitoco said:

What about TIMER? Will it reset all 3 bytes of RTCLOK?

Not at the moment - for simplicity I kept it as before, adding the clearing of $12 would conflict with the code for the 5200 (that only uses the integer implementation). I documented in the manual that you should not use %TIME and TIMER together.

 

Have Fun!