Author: Christophe Theron
Date: 09:58:30 10/03/99
Go up one level in this thread
On October 03, 1999 at 12:08:01, Ratko V Tomic wrote:
>> Right now I think there are 2 possibilities what causes the programs play
>> strange with auto232:
>> 1) DOS program
>> 2) Nimzo7.32 autoplayer which would let me suspect that the other CB
>> products produce the same behaviour, Fritz5, Junior5, Nimzo99 and
>> Hiarcs7.32. But it will take time to find this out.
I think there is no need to suspect CB programs. The cause is certainly the DOS
auto232 drivers, simply because what they do is very messy, and likely to cause
problems to DOS extenders.
>There is also possibility that your serial port (UART) is one of those
>which occasionally get in a mode where they continuosly generate
>transmit interrupt (indicating that transmit buffer is redy to transmit).
>Normally this interrupt is one shot i.e. it kicks in when the transmit
>buffer on the chip becomes empty so that a COM program can feed another byte.
>Over years I had run into some chips which keep reissuing this interrupt
>at the baud rate of the port. If the program uses extended memory via some
>protected mode DOS extender, the severity of the interrupt overhead
>increases dramatically over the plain real mode DOS.
>
>By setting the baud rate to a very slow one (e.g. 300 baud, that's
>plenty for sporadic few byte packets in an autoplay) and comparing
>the Rebel's nps, you could test whether this was the problem. In any
>case, good or bad serial chip, a positive correlation of baud rate and
>decrease in nps would indicate excessive or otherwise faulty serial
>port activity.
That's an interesting information I was not aware of, unfortunately I don't
think it is possible to change the Auto232 baud rate, so we will not be able to
experiment on this.
Well... of course we could insert instructions in a chess program to change the
baud rate of a given COM port, but...
>Another issue is whether Rebel is communicating with the driver supplied,
>or whether the communication somehow fails (from the start or at some point)
>and the driver reverts to a brute-force scan of video memory which could
>slow things down quite a bit.
Another possibility, yes. As we see, there are plenty of ways for the auto232
driver to do something wrong.
Also, as far as I know, some VGA ports are READ ONLY (at least in the original
specs). That means that an interrupt program cannot safely access the VGA
display memory without taking the risk to be unable to restore the VGA system in
the correct state.
I have done assembly interrupt and VGA programming several years ago and I can
tell you this issue is really a problem. I cannot imagine that the Auto232
driver can safely avoid the trouble.
Christophe
>Are there somewhere the specs for programs
>communicating with the auto232 DOS drivers? (The Gambitsoft free file
>auto232p.zip has only the specs for windows programs.)
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.