Author: Ratko V Tomic
Date: 05:22:04 10/07/99
Go up one level in this thread
> 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). 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).
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.