Author: Robert Hyatt
Date: 06:55:20 02/03/99
Go up one level in this thread
On February 03, 1999 at 07:49:38, Ed Schröder wrote:
>>Posted by HF on February 03, 1999 at 12:03:13:
>
>>>It's about AUTO232 and its involved risks. The problem keeps me busy for
>>>almost a half year by now and maybe some of you can enlighten me.
>>>Ed Schroder
>>>
>>>---------------------------------------------------------------------------
>>>
>>>There will be at least a delay of one week for the release of Rebel10.0c
>>>and maybe more. An estimated date for the release is set to February 15.
>>>
>>>Note that this easily might change too. As already written before the
>>>Rebel10.0c update is mainly meant to fulfill my promise to include
>>>the AUTO232 option again in Rebel10.
>>>
>>>About 5-6 months ago I seriously started to doubt the auto232 results
>>>this due strange results only in auto232 games. I then came to the
>>>conclusion something was very wrong with the auto232 driver (and
>>>probably for a very long time already) and started to take the problem
>>>very serious.
>>>
>>>I did many experiments. I like to mention 2 of the most shocking ones:
>>>
>>>Experiment (1)
>>>Playing auto232 matches:
>>>- Rebel10 (60 Mb hash) vs comp XYZ
>>>- Rebel10 (13 Mb hash) vs comp XYZ
>>>I noticed Rebel10 (13 Mb) scored a lot better than Rebel10 (60 Mb)
>>>
>>>I came to the conclusion that the auto232 driver might damage Rebel.
>>
>>Do you have an idea how that works? What harms Rebel? In which way?
>
>Each program when started gets its own memory pool (area). Of course
>when programs start to write in each others memory you get problems.
>This the suspect auto232, writing in Rebel's memory ruining data as well
>as the code. HIMEM.SYS is meant to prevent that.
>
unless something has changed drastically, it doesn't do that. It _allows_ a
program to access memory beyond 640K, but it doesn't 'protect' it. Otherwise
you couldn't run something like this and hang the system:
main() {
int a[1000];
int i;
for (i=i;i<10000000;i++) a[i]=0;
}
Dos has never had the concept of 'a task' which is why "TSR (terminate and stay
resident)" programs were developed. They sit in memory, can write _anywhere_
and you don't ever know unless they blow you up...
>
>>>Here is one game I found in the database.
>>>
>>>1. e2xa8=Q e7xh3ep
>>>2. d2xh1 d7xh4ep
>
>>Oops, this looks very strange. Possible that it was no auto232-phenomenon
>>but a bug in saving the game?
>
>Nope.
>
>
>>>I never have seen such a crazy thing. A small wonder the auto232
>>>match still continued and didn't crash.
>>
>>I am very curious getting the whole game. :-)
>
>That was the whole game :-)
>
>
>>>Experiment (2)
>>>Based on the theory that auto232 damaged Rebel (writing in Rebel's
>>>memory)
>
>>Tel me if I am right thinking that Rebel in autoplayer mode plays different
>>than in normal tournament games without autoplayer mode because of
>>some lines of code you implemented for memory (learning?) effects?
>
>No it is not that. Wish it was true but it isn't.
>
>
>>>At the moment experiment (3) is (just) started:
>>>- Normal Rebel10 (maximum hash table)
>>>- Make sure that HIMEM.SYS is loaded (just run auto232 from W95/98)
>
>>Does auto232 work under W95/98?
>
>Rebel10.0c (with auto232) is currently running on 2 autoplayer pairs
>under Win98 and a third autoplayer pair is running under Win95. No
>incompatible problems noticed sofar.
I assume your autoplayer 'bug' was not under windows? Because if it was,
then this changes things. The only thing that can access your memory is part
of _your_ program (including the auto232 driver code you include, of course,
but 'other programs/processes' can't touch you in win98. Only things that are
part of your code..
>
>
>>I thought it would "capture" the commands directed to the serial port?
>
>To be more precise, the printer and the keyboard are connected to each
>other (re-directed). This allows chess programs to send moves to the
>printer and then the auto232 driver catches that move and send the move
>to the keyboard buffer of the other computer and vice versa.
>
>
>>>Note that most auto232 lovers boot their PC in "safe mode" to get the
>>>maximum speed and hash tables and I am no exception either. But
>>>doing so HIMEM.SYS is *NOT* loaded in that case.
>>
>>I'll check this tonight at home if I use Himem or not for max. hash.
>>
>>>And here is what the documentation says about HIMEM.SYS:
>>>
>>> HIMEM is an Extended Memory Manager--a program that controls the
>>> use of extended memory and HMA (High Memory Area). This to
>>> prevent that (2) programs can use (write) the same memory at the
>>> same time.
>>>
>>>Quite revealing.
>
>>So this sounds OK, auto232 is a TSR program (right?) and Rebel
>>is the other program so the use of HIMEM seems to be necessary.
>>BTW AFAIK MCP also works with himem.
>
>Yes, auto232 is a TSR program. It is started first (before a chess program
>is loaded) in order to catch all the moves and commands.
>
>I remember the CCL Mchess 7.1 case when Marty told me Mchess needs
>HIMEM.SYS. I was surprised then, now I understand better. But in the end
>the Rebel case has to be proven as I don't have the hard evidence yet.
>
>
>>>All in all we need some time to figure this all out and in order to release
>>>an auto232 version that plays chess as the normal Rebel10 does and
>>>is not handicapped by external drivers.
>>>Ed Schroder
>
>>Did you check this phenomenon also with Rebel9 or 8?
>
>At that time the thought never crossed my mind.
>
>Ed Schroder
>
>
>>BTW this seems to be another reason to port Rebel to Windows. ;-)
>
>Harald, this is cruel :-)
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.