English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Language > Coders. Blitz Basic

 
 
Thread Tools
Old 02 November 2019, 14:44   #1
Nightshft
Registered User

Nightshft's Avatar
 
Join Date: Mar 2018
Location: Austria
Age: 44
Posts: 230
Busy Waiting or avoiding it

I found an old program named KlockWatch (by Hippomus) which opens a small window and shows date and time.

It works fine, but I think it's busy waiting
Code:
[pseudocode]
repeat
  get systemDate  (edit: time of course)
  format and print it
  vWait
until (close window event)
Could this easily be changed to avoid busy waiting?

Last edited by Nightshft; 03 November 2019 at 14:44.
Nightshft is online now  
Old 02 November 2019, 20:14   #2
Daedalus
Registered User

Daedalus's Avatar
 
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 4,342
The VWait should put the program to sleep until the vertical blank, so that shouldn't really be busy waiting and should free up the CPU for the remainder of the frame. However, I think that in more recent releases, VWait is a little broken and is itself busy wait (apparently it busy-waits when the OS is shut down, which is fine, but it should switch to a wait until interrupt method in a multitasking environment.

There are several ways of avoiding the VWait altogether, depending on what exactly the program is doing. First off though: If it's only printing the date, why does it need to do that 50 times a second? If another part of the program is dealing with time, why not only print the date when the hour changes? The date can't change if the hour doesn't change. If it also needed to deal with the date preferences being changed, even checking once a second should be enough, and even then it should only need to be printed if it changed from the previous value.

There are two main ways of slowing the program down to free up all that busy-looping time: First, use WaitEvent to put the program asleep until an event happens. The #IDCMP_INTUITICKS event fires 10 times a second, so enabling that on the window will make the loop run only 10 times a second instead of the 50, and will put it asleep for the rest of the time.

The second option is to use a fixed delay with the Delay() system call. This puts your program asleep for the given number of frames and can be used instead of the VWait:

Code:
Delay_ 10
for example will make the loop run only 5 times a second, and will sleep for the rest of the time. You have to be careful to cycle through all your events before letting the program go back to sleep though, or you could end up with a long queue of events that take some time to get through.
Daedalus is offline  
Old 03 November 2019, 02:15   #3
Nightshft
Registered User

Nightshft's Avatar
 
Join Date: Mar 2018
Location: Austria
Age: 44
Posts: 230
Quote:
Originally Posted by Daedalus View Post
First [method]: use WaitEvent to put the program asleep until an event happens. The #IDCMP_INTUITICKS event fires 10 times a second, so enabling that on the window will make the loop run only 10 times a second instead of the 50, and will put it asleep for the rest of the time.
Just learning Blitz. No idea at the moment how to do this sorry.
So this means no simple timers can trigger eventhandlers in Blitz?

Guess I come back to events later.

Quote:
Originally Posted by Daedalus View Post
The second option is to use a fixed delay with the Delay() system call. This puts your program asleep for the given number of frames and can be used instead of the VWait:
"Delay_ 10" for example will make the loop run only 5 times a second, and will sleep for the rest of the time.
This works absolutely fine (as expected also with higher values up to 50), thanks again!
Nightshft is online now  
Old 03 November 2019, 11:40   #4
EmilAmiga90
Registered User

 
Join Date: Sep 2018
Location: Rome / Italy
Posts: 17
Quote:
Originally Posted by Daedalus View Post

The #IDCMP_INTUITICKS event fires 10 times a second, so enabling that on the window will make the loop run only 10 times a second instead of the 50, and will put it asleep for the rest of the time.
Interesting. I am wondering if #IDCMP_INTUITICKS fires 10 times a second both NTSC and PAL. I mean: is #IDCMP_INTUITICKS frame dependent?

I am also wondering if CIA timers are frame dependent.

Last (I am being annoying ) I wonder if timer.device is frame dependent.

I fear (I hope I am wrong) that every AMIGA clock is NTSC/PAL related.
EmilAmiga90 is offline  
Old 03 November 2019, 14:24   #5
Daedalus
Registered User

Daedalus's Avatar
 
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 4,342
Quote:
Originally Posted by Nightshft View Post
Just learning Blitz. No idea at the moment how to do this sorry.
No worries, we all have to start somewhere. The event handling is an Amiga OS thing rather than a Blitz thing, and will follow the same general pattern in any language.
Quote:
So this means no simple timers can trigger eventhandlers in Blitz?
That's exactly what #IDCMP_INTUITICKS is - a simple timer that fires a few times a second, mainly for the purpose of updating GUIs without user interaction. You add it to the window's list of reportable events with AddIDCMP, and then you can check for the value in your event loop, just as you would for the close window event. Using WaitEvent then instead of Event will put your program to sleep when there's no event to answer. In fact, you don't even need to check for it really if you want to make things very simple.

Quote:
This works absolutely fine (as expected also with higher values up to 50), thanks again!
Good stuff

Quote:
Originally Posted by EmilAmiga90 View Post
Interesting. I am wondering if #IDCMP_INTUITICKS fires 10 times a second both NTSC and PAL. I mean: is #IDCMP_INTUITICKS frame dependent?
I haven't measured it myself but I suspect it does change between NTSC and PAL. But it's not in any way accurate, even within PAL or NTSC, and shouldn't be used for any sort of accurate timing.

Quote:
I am also wondering if CIA timers are frame dependent.
You've got both: There are frame counters, horizontal sync counters and high resolution timers. The frame and sync counters will change depending on whether the display is in PAL or NTSC mode, but the high resolution timers are dependent on the motherboard crystal (they run at 10% or the original 68000 frequency) and are independent of the refresh rate. This is known as the E-Clock, and is ~716kHz for NTSC machines and ~709kHz for PAL machines, irrespective of selected screenmode.

Quote:
Last (I am being annoying ) I wonder if timer.device is frame dependent.
Again, it depends on the type of timing you're doing. If you're counting hardware ticks like the Eclock, it will differ slightly depending on the hardware. If you're counting frames, it will differ significantly. If you use it for counting seconds and microseconds, it won't differ as the OS will compensate for any differences to get you a true reading of the time. This is what's used for the time of day clock, for example, which of course needs to be accurate regardless of hardware or display mode.

Quote:
I fear (I hope I am wrong) that every AMIGA clock is NTSC/PAL related.
Yeah, they sort of are, but if you use timer.device, you have the option for working with hardware clocks, display clocks or seconds/microseconds, so you can choose the most relevant method for what you're trying to do.

Just to add, for compensatory algorithms if you want to do it yourself, the NTSC function in Blitz will return true if you're running in an NTSC screenmode.
Daedalus is offline  
Old 03 November 2019, 16:48   #6
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 280
Quote:
Originally Posted by EmilAmiga90 View Post
Interesting. I am wondering if #IDCMP_INTUITICKS fires 10 times a second both NTSC and PAL. I mean: is #IDCMP_INTUITICKS frame dependent?
IntuiTicks is, pretty much as everything else in the system, depending on the timer.device, on the VBlank unit. This unit is driven (by default) by the frequency of the power supply and not (as the name suggests) by the vertical blank. So timing does not change between PAL and NTSC.

Beware, however, that there are some (popular) modifications to the Amiga that replace the (custom) power supply that provides a "ticks" source with a generic PC network which does not supply this tick source, and then people would have to set a jumper to drive the timer from the vertical blank.

In such a case, the frame frequency would change the clock speed, of course.

IOWs, do not depend on the unit for accurate timing (in the sense of "driving a clock"), but only for approximately regular tasks.
Thomas Richter is offline  
Old 03 November 2019, 17:20   #7
Daedalus
Registered User

Daedalus's Avatar
 
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 4,342
Quote:
Originally Posted by Thomas Richter View Post
IntuiTicks is, pretty much as everything else in the system, depending on the timer.device, on the VBlank unit. This unit is driven (by default) by the frequency of the power supply and not (as the name suggests) by the vertical blank. So timing does not change between PAL and NTSC.
Indeed, I had forgotten about this aspect on big-box Amigas.

Quote:
Beware, however, that there are some (popular) modifications to the Amiga that replace the (custom) power supply that provides a "ticks" source with a generic PC network which does not supply this tick source, and then people would have to set a jumper to drive the timer from the vertical blank.
Also, aside from users replacing PSUs or changing the tick jumper, many Amigas don't even have this tick signal from the PSU at all - in particular, the A500, A600, A1200 and CD32 don't have the PSU tick signal, and all derive their tick signal from the VSync from the display circuitry.
Daedalus is offline  
Old 03 November 2019, 20:21   #8
EmilAmiga90
Registered User

 
Join Date: Sep 2018
Location: Rome / Italy
Posts: 17
Quote:
Originally Posted by Daedalus View Post
If you use it for counting seconds and microseconds, it won't differ as the OS will compensate for any differences to get you a true reading of the time.
That's what I wanted. Thank you
EmilAmiga90 is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Waiting for the blitter... jayminer Coders. Blitz Basic 8 20 July 2015 03:12
Avoiding copper strobe/blitter bug mc6809e Coders. Asm / Hardware 31 28 November 2013 09:09
Have you played Banshee? If not what are you waiting for? vroom6sri Amiga scene 14 18 June 2013 02:01
stingray being busy extralife request.Demos 30 08 January 2013 17:44
[Found: The Sentinel] creepy music, avoiding eye contact with a statue? lost_lemming Looking for a game name ? 2 14 February 2010 01:08

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 06:21.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Page generated in 0.07008 seconds with 15 queries