Author: Ratko V Tomic
Date: 11:27:05 09/29/99
Go up one level in this thread
> The interrupts were far too slow and somewhat inadequate for correct > display management. Every DOS software developper as written his > own routines, both for text mode output and graphic mode output. For displaying graphics, yes. But for small amount of text (such as move coordinates) the BIOS text routines (function AH=0xE, AL=char still work in graphics modes) would be fine regarding performance. Now, the default may still be direct video-memory output, but in some "safe" modes of operation perhaps programs would operate more conservatively and use BIOS whenever possible. As I recall, Rebel has its own graphics fonts, but also an option, in case these fonts don't show, to switch back to regular (smaller) fonts. Now, if they were outputing font bitmaps directly into video RAM, small or big fonts would work fine (or wouldn't work if output code can't handle given video hardware). OTOH, BIOS has ability to define user fonts of given size, and on most BIOS-es that works fine, but on some the custom fonts may not work in graphics modes. Thus, Rebel seems to be consistent with ability to use BIOS for output (otherwise its behaviour, when it doesn't work with large fonts, and advice in the FAQ wouldn't make sense). Some programs may also have ability to output moves to the printer or a text to speech device, which would make the capture much easier. Also, some programs may be convinced they're playing on an external chessboard (such as Novag's) and they would send moves there. I think even DOS progams can do this (Novag page lists all the main ones). But going into graphics memory and decoding piece bitmaps seems like an error prone and error introducing method, especially when moves are timed on both programs. And doing that kind of expensive check periodcally in timer interrupts is really heavy handed. If one has to look at the bitmaps, one would first ask user, who is setting up the autoplayer, to mark the corners of the board (using mouse), so that program can find easily each square. Similarly, user would mark an area where new move can be detected. Then one would run a set of "learning" tests where the autoplayer finds out other trigger mechanisms correlating with the moment of move being made (it could be DOS/BIOS interrupts for time or file i/o, or access to sound, pattern of various BIOS/DOS calls, etc). But for most existent DOS programs, whose number is dropping anyway, and they're starting to freeze any UI changes, the autoplayer manufacturer could manually find the right trigger mechanism for video RAM checks. Also, since the chess programs allow operation on lower end VGA hardware, the autoplayer would trick the program into the simplest VGA hardware, so that graphics access and decoding is simplified and speeded up. In any case, it can be done well, especially with a small set of top programs still running on DOS. And if program is cooperative, there should be no problems at all. I see no reason for drastic slowdowns (under 1 percent in the worst case, when graphics screen has to be checked, say, twice per second), crashes, BIOS setting corruption or any such. BTW, is there somewhere an auto232 spec for cooperative chess programs as well as its serial communication protocol? (If I get some time, I would like to write at least a better DOS driver for it.)
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.