CTMOUSE corrupts the second video page in VGA mode 12h

[mateuszviste]

I found out that when in VGA mode 12h, CTMOUSE uses the VRAM past the default visible area to store the content of the screen that has been overdrawn by the cursor. The location seems to be somewhere around row 510 in VRAM.

My application is using this part of the screen for storing offscreen graphics, so in effect CTMOUSE is corrupting my sprites.
I have tested MS MOUSE 11.0 and it does apparently the same thing, albeit the location it chooses for storing the under-cursor sprite is lower in memory, at row 480 (ie. the row immediately past the last visible row) of the VRAM.

It is worth noting that this VRAM area can not only be used for graphic storage, but can also be displayed by changing the indexes 0Ch and 0Dh of the 3D4h register, which makes the issue immediately obvious.

I'm not saying there is anything wrong with CTMOUSE, but I'd like to make two respectful suggestions:

1. This internal sprite-storage behavior does not seem to be documented. Perhaps it would be nice to add a word or two about it in CTMOUSE's doc so other developers are not surprised that mode 0x12 usage should be restricted to page 0 when using CTMOUSE's cursor.
2. It might be better for CTMOUSE to use the same location as MS MOUSE for its under-cursor sprite storage. There may be applications out there that expect the row 480 to be corrupted by the mouse driver but still use locations past it. Such applications would work with MS MOUSE but exhibit corrupted sprites with CTMOUSE.

This issue may or may not be common to more video modes, I do not know. I have only tested mode 12h.

[mateuszviste]

I double-checked the MS MOUSE 11.0 driver: in VGA mode 12h it (ab)uses in fact not 1, but 4 rows of VRAM, from 480 to 483. It seems to use VRAM not only for the under-cursor backup, but also some other things.

I have also checked the Logitech Mouseware driver ver 6.30: it acts almost exactly like MS MOUSE 11.0, ie. it destroys a total of 4 VRAM rows, from row 480 to 483 (different data pattern, but same location as MS MOUSE).

CTMOUSE is destroying only one row as it uses VRAM exlusively for the under-cursor sprite backup, but the location it uses is much more inconvenient (row 507), effectively forcing the application to waste almost 9K of VRAM.