Author: Ed Schröder
Date: 10:38:50 10/07/99
Go up one level in this thread
>Posted by Ratko V Tomic on October 07, 1999 at 08:22:04: > >> Every program needs to poll for input. Asking the keyboard / >> mouse for input are expensive (slow) operations. In Rebel >> I have a counter that makes sure to look for input after 500 >> evaluations. If I decrease the value to say 50 or 10 the NPS >> of Rebel drops tremendously (forgot about the exact slow-down). > >When I was looking for the cause of Rebel hangup in Windows DOS Box >(and ended up writing that utility, fix.exe), I noticed that Rebel is >taking mouse and keyboard interrupts in real time (I found mouse >interrupt reentry was occasionally resulting in a lockup; the fix.exe >TSR manages reentry of mouse interupt and precludes reentry). That >would suggest Rebel need not do any polling at all, but it could >handle all such tasks either within interrupt service or periodically >based on the main timer interrupt (18.2 times/sec which is plenty >responsevness for user input). Or an interrupt from mouse or kbd or >system timer could redirect a function pointer for the call to evaluation >to go through input processing (and then continue with the original call >it intercepted), whenever there is input. Even the last option is faster >than decrement+branch_on_0 combination which now occurs on every >evaluation (if you're already calling using function pointers, there >is no overhead at all, unless the input data has arrived). I could use the main timer interrupt indeed but I have chosen to be in control myself for reasons of being as flexible as possible. One day it might be needed to port Rebel and then I have one porting problem less. The system I use comes from my 6502 days when I wrote chess programs for the dedicated Mephisto series. Every prototype I received had its own interrupt frequency (300, 600, 1200 you name it) and needed specific hardware tuning because of that. My routine then simply blocked the 6502 interrupt (just a RETURN) until my counter reached its value. >In any case, checking input every 500 evaluations, on a CPU doing >150,000 nps means about 300 checks per second, which is about 10 >times more checks than human perception needs. If you have an >address of the variable (within the Rebel 10b &c executable) which >contains this number 500, I would like to patch it to 5000 or more. >This can be found with debugger, but it would be quicker if you have >a number (e.g. from your MAP file produced by the linker). I have tried this and it gave me no speed-up. Actually the "500" number I mentioned depends on the processor Rebel is running. On a fast PC the number is much higher, on a slow 386SX-25 Mhz the number is "50" which is (if I remember well the lowest value possible). I am still happy with the system. Ed
This page took 0.01 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.