When i set a timer to lets say 1000 ms, does it send the wm_timer msg every second ?
Posted on 2001-04-12 20:34:00 by Typhoon
if you do push 1000h call SetTimer windows should send WM_TIMER message every 1000 ms and so on.. you can retrieve the message with GetMessageA
Posted on 2001-04-12 21:04:00 by Shaolinwu
ehrm,actually it's push 0 push 1000h push 0 push 0 call SetTimer or 4 saving bytes: cdq push edx push 1000h push edx push edx call SetTimer
Posted on 2001-04-12 21:10:00 by Shaolinwu
The correct way to use the timer function in windows is to use. invoke SetTimer,hWin,4,1000,0 The 4 is just a number to Id the time so you can have many timers with different settings. when you catch your WM_TIMER Message you then check wParam for the Value here it would be the 4 if you wanted to check on that timer. Remember that when a WM_TIMER is sent to your window wParam holds which timer it is.
Posted on 2001-04-13 02:52:00 by Zcoder
zCoder is half right, there are two ways to use timers, having the WM_TIMER message sent to a windows message que, OR a having Windows call your TimerProc directly. It gets a little complicated because TimerProc's are in the same format as WndProc's. There are a couple of differences between the two methods, the first above, is not very accurate, as the timer goes through the default windows message que processing, which means if your app is in the middle of a complex painting operation, the timer wont get through until the painting is finished, which could be easily half a second later, which is bad if you are relying on timers getting through every 100ms. The latter method, is where windows saves the context of the thread that created the timer (Check the Thread ID of each context of timer that comes through, it is the same), and then executes the timer proc restoring the threads context when finished
Posted on 2001-04-13 03:33:00 by George
If I recall correctly, WM_TIMER messages aren't actually put into the message queue, they are generated by GetMessage when the queu is empty, and a timer has expired, so if you queue never empties then you'll never get a timer message, they are also terribly inaccurate! These days you're better off using a separate thread to do the work. Unless timing really not that important. umbongo
Posted on 2001-04-13 15:06:00 by umbongo
George, Your right, but I did not want to tell a newbie about the proc stuff, wanted to make it easy on them. LOL
Posted on 2001-04-14 18:32:00 by Zcoder
this procedure is working fine for me and I use it quite often:? ... msg MSG<> ... cdq invoke SetTimer,edx,edx,250h,edx timer_id,eax ;save timer id,for use with KillTimer loop: cdq invoke GetMessage,offset msg,edx,edx,edx cmp eax, 0 je error mov eax,msg.message cmp eax,WM_TIMER jne loop ...timer elapsed,KillTimer and do something indeed it's a little inaccurate tho:(
Posted on 2001-04-14 19:42:00 by Shaolinwu
It's more out of curiosity... but "How do Timers work" ? What are they comparing to know that a second just went by? Is there some algo which lasts exactly one second or how does the processor know that 1 second is 1 second... definitively curious, jimmyclif Happy Easter
Posted on 2001-04-14 20:10:00 by JimmyClif
I am assuming, that it reads the system clock chip and counts the miliseconds and when your set time has been reached a WM_TIMER message it sent to your app. along with the TIMER ID.
Posted on 2001-04-15 11:07:00 by Zcoder
Thanks you guys, my question was answered way more than i expected, and Zcoder thanks for making it easy for me :) Regards
Posted on 2001-04-15 20:00:00 by Typhoon
JimmyCliff, Heres a bit of overkill, but the CPU timer is as follows: In every CPU there is the Timer chip (Intel 8253) which has 3 independent timers, each timer has a 16-bit counter, one master clock input, and three output signals. The master clock frequency is 1.19318 MHz (Not your CPU rated frequency). This timmer chip generates a unique interupt event for each timer, every time the timmer counts down to zero (drive by the master clock). The output from timer 0 is connected to IR0 (Interupt Zero which has the highest priority) and is used for the master clock in the CPU. Write a VxD to change the counter value of timer zero, and your cpu's idea of a second will change. Since the input frequecy is constant (~ 1.2 Mhz), the counter value can be determined for its Interupt frequecy as follows: 1) For a Timmer resolution of 1 ms. Find the frequecy of needed output interupts: Every 1 ms is proportional to 1/(1 ms) Hz, or 1 Khz Output interupting freq. 2) Calcutlate: Counter Value = 1.19 Mhz / 1 Khz = 1193.18 Therfor the OS has set the counter to ~1193 on timer 0 for an interupt every millisecond. Higher will values have 'slower' seconds, and lower values have 'faster' seconds. Every hardware interupt generated is monitored by software (ISR ~ Interupt Subroutine). Somewhere in windows a little subroutine is jumped into to keep track of these interupts 1000 times a second (even as your reading this). From there, software flags etc. and higher software processes determine when events are to be sent to windows registered for timmer events etc. If your interested i can dig up the port addresses to change timmer values.. BTW: The two other timers and interupts are used for other hardware processes, one is for RAM refresh, and the other is a spin timmer for your hard-drive (if i remember correctly). Long story short, they are not to be tinkered with :) NaN
Posted on 2001-04-15 21:38:00 by NaN
NaN, any info you could give me programming _anything_ via IO ports would be greatly appreciated, because the other day i was reading the Intel Protected mode programming document, and i noticed that the concepts behind an OS were not half as complicated as I thought, so I went, "I wonder if I can do that" :) , but at the moment I am having more trouble finding documents with specs such as IO ports etc than doing the actual programming itself. Thanks aye George
Posted on 2001-04-15 22:05:00 by George
I would be glad to help you if i can, but to 'download' what i know in such respects is a little too general :) I can give you reference to a great text i bought 4 years ago.. there has since been a revision or two.. its: The 80x86 IBM PC and Compatible Computers (Volumes 1 and 2) Assembly Language, Design, and Interfacing Second Edition Prentice-Hall Inc. ISBN: 0-13-758509-8 (983 pages) It covers EVERYTHING including DOS level assembly and port addressing, schematic architecture of a motherboard and its components (ie] How DMA is wired to work), vector tables, hardware interfacing (mouse, printer, cards etc.), BIOS and more. Another great resource and very under appreciated is an old dos program (and/or) TSR called HelpPC21. It was my best friend in college (were you really learn how to do something ~~ grumpy with University, but anyways ~~), this progam will fit on a floppy no problem, which is what makes it so handy when your coding for hardware etc. It is quite simply a menu driven reference tool to the entire 80x86 CPU, i've seen information in this 500kb program that is was not in university texts (Ie, scan codes for keyboard hardware). Anywho, download it and check it out: Here..... I guess this is a good head start. While i praise HelpPC, its not complete, i know i have at least once come up short of info with it (can't remember what) but i know i have. Regardless, im sure it will answer many questions quickly.. The text however will give you volumes of infomation to back up the quick answers (still worth the buy). In return, lemme know how your efforts are going with the OS design idea... I personally thought it would be beyond my grasp, so im currious of any progress you make :), good luck. NaN
Posted on 2001-04-15 23:23:00 by NaN
Thanks NaN :) You thought it was overkill, I think it's good to know... Really interesting to know/understand how a computer works... I wonder if I keep on coding I'll be able to create my 25 hour day ;)
Posted on 2001-04-16 07:50:00 by JimmyClif