Author: Ed Schröder
Date: 06:11:05 10/05/99
Go up one level in this thread
>Posted by Ratko V Tomic on October 05, 1999 at 07:35:41: > >> The problem is not the baud-rate, the problem is that the slow-down >> isn't reproducible. In most cases there is no problem (slow-down) at all. > >On his machine it seems that the problem repeats itself. The varying >of baud rate test (with monitoring of nps) was meant to eliminate >some possible causes (which could appear sporadic). Other system and auto232 >settings ought to be varied as well. For finding the causes of problems >there is nothing better than finding a system which reproduces the problem reliably. If this is true and a slow-down is reproducible we have a new case I am not aware of. I have never seen it in all the years I have used auto232. I know the DOS auto232 will slow down programs because the driver polls for input. I noticed that in the early days of auto232 (486/66 and P90) the slow-down was 10%. Nowadays on fast machines the slow-down is zero to none, at least on my PC's. >I am also curious whether there is somewhere an interface spec for DOS program >and the auto232 DOS driver. The file auto232p.zip (from gambitsoft) has only >windows protocol). You mentioned in one note here that Rebel communicates with >that DOS driver. I have not been able to find (on the web) the spec for that >communication, but with that spec (and the one for Windows), I could probably >write (in few hours with the TSR production tools I have) a small, reliable >and non-intrusive DOS device driver which would allow two auto232 compliant >programs (on DOS or windows) to play using that protocol. There is no documentation of the DOS auto232 driver. Chrilly Donninger the author of auto232 (and NIMZO) once gave me some info. As far as I remember the system works as follows: #1. A chess program outputs the move it plays to the printer in a specific (ASCII) format. (That was all there was to do to make Rebel auto232 compatible). #2. The auto232 driver (when launched) redefines the printer to the serial port (COM1 or COM2). Then from the serial port the move is read, translated and send via the serial port of the other computer. #3. The other computer scans the serial port and puts all info received in its keyboard buffer. #4. Then everything should be ok as the chess program recognizes it has a move in the keyboard buffer. Of course if certain IO devices are slow (or broken) you can get unacceptable delays but I actually never noticed such cases. Ed Schroder
This page took 0 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.