Code: Select all
BUG: the IBM EGA and some other EGA cards return in DL the number of rows on
screen rather than the highest row number (which is one less).
Code: Select all
BUG: the IBM EGA and some other EGA cards return in DL the number of rows on
screen rather than the highest row number (which is one less).
Brilliant findings! Yesterday I executed GM Chess in the Open Watcom debugger, only to realize I had no idea how to go about debugging such a complex app. This info. actually saved me hours with unfamiliar tools, trying to track down each instance of CD10 in the binary. I'm looking forward to reading your conclusions, when they become ready.michaln wrote:The fonts are garbled because the VirtualBox VGA BIOS doesn't implement INT 10H/1122H, INT 10H/1123H, and INT 10H/1120H. The chess game uses those calls rather than the much more obvious INT 10H/1130H that mpack pointed out.
I can only speculate that the game engine was originally written to run on the EGA which had no INT 10H/1130H. But the program uses 8x16 fonts that don't exist on the EGA, and runs in VGA mode 12h, so I don't think it'll work anyway. At first I thought the game might be using the BIOS to draw the text, but of course it's not. It calls INT 10H/112xH and saves off the INT 43H vector in order to access each of the three different fonts.
I'll see if I can fix that.
Edit: Actually the EGA supported INT 10H/1130H already. What the game does makes no real sense, although it should still work.
Suggested by whom? That sounds asinine to me. How is the location where the OS loaded the executable from supposed to affect the operation of the graphics BIOS?Jim Comfort wrote:One of the suggested fixes was to put it on a FAT 32 partition, then run it from there.
michaln wrote:The changes will be visible here whenever the public code is synchronized.
A debugger is not generally a bad tool, although debugging a graphical application on a single machine can get very problematic very quickly; remote debugging of some sort may work better. That said, in this case an interrupt tracing utility would do the job too, and it's probably less intrusive than a debugger. I think the book Undocumented DOS came with some such thing.
FWIW, I used the VirtualBox VM debugger which is very "remote" in that there is nothing visible from the guest side at all (it's more like an ICE really). It's not super easy to use but in this case, putting a breakpoint on the INT 10H entry point showed very quickly what the game was doing. The fact that the relevant BIOS functions weren't implemented says a lot about how often they're used.