In the VGA graphics modes the cursor is not displayed but BIOS does keep track of its position. For every available display page, BIOS records the cursor's column and row coordinates (certainly not the X and Y coordinates) in the Cursor Save Area, 16 bytes starting at linear address 0450h. Fun fact: BIOS also updates unnecessarily the CRT Controller registers Cursor Location High and Cursor Location Low.
Since the beginning of time applications that run on a graphics screen therefore have had to create their own cursor, and so I fully realize that I too will have to provide a cursor of my own.
There is one glitch though. Apparently DOS expects users to be able to edit the command line without the help of any cursor when operating on a graphics screen! The same applies to the DOS.BufferedInput function 0Ah invoked from an application.
Then how can I add a cursor to the graphics video modes both within my application and at the command prompt?
(This is a self-answer)
To get cursor functionality both in the user application and on the DOS command line, writing a Terminate and Stay Resident (TSR) program is the solution. And if you add it to AUTOEXEC.BAT you won't have to keep thinking about installing it!
A preliminary concern though. It will harm to force a cursor on an application that was probably written many years ago and was build upon the premise that no cursor exists. Said application will have provided its own cursor.
Design choices for this cursor driver (TSR)
A cursor available while inputting. It is not desirable to display a cursor in permanence. There's little point in seeing the underline shoot across the screen when characters get outputted. A cursor is useful and necessary when a program expects input from the user at the keyboard.
The cursor driver mainly focusses on the Keyboard BIOS, more specifically functions 00h (10h,20h) GetKeystroke and 01h (11h,21h) CheckForKeystroke. There is no need to also look at any relevant DOS input functions since ultimately those functions will call upon the underlying Keyboard BIOS. This is also true in DOSBox.
The phrase "cursor available while inputting" is tantamount to saying that the cursor should be disabled most of the time (...). Then in order to have the cursor show up automatically while at the command prompt the driver hooks the int28h interrupt that DOS continually invokes while the input is in progress. The int28h signal is used as a temporary enabling of the cursor. Very soon after, the int08h signal will disable the cursor again.
A faithful imitation of the text video cursor. That means an underbar for overwrite mode and an half-cell for insertion mode. The cursor must blink at approximately 2 Hz. To obtain the blinking effect the driver looks at the BIOS 18.2 Hz timer. Every fourth tick the cursor changes phase (ON/OFF). This rate is very close to what we get in a text video mode. The cursor will correctly toggle shape between underbar (for overwriting) and half-cell (for insertion), in accordance with bit 7 of the BIOS.KeyboardFlags located at linear address 0417h. The cursor driver supports the following screen modes: 13: 320x200x4, 14: 640x200x4, 15: 640x350x2, 16: 640x350x4, 17: 640x480x1, 18: 640x480x4, 19: 320x200x8.
A small footprint. My willingness to have any (useful) TSR installed is inversely proportional to the size of the TSR program. I'm happy to say that this TSR is very compact at 624 bytes, including the Memory Control Block (MCB)! Of course to arrive at this small footprint, concessions had to be made resulting in some imperfections (an occasional visual remnant). Going for the perfect cursor could have demanded an inordinate amount of memory.
Reclaim the PSP This is a 3-step process. Firstly the installation program moves the resident code down in memory overwriting most of the Program Segment Prefix (PSP) but guarding to not destroy the important data in front, secondly the DOS.TerminateAndStayResident function 31h is invoked, and thirdly the remaining bytes in the old PSP are used as the driver's background buffer. Reclaiming the entire PSP is possible because this driver never has to invoke any DOS functions!
Limit the api The necessary api was added to the BIOS.GetModeInfo function 0Fh that normally reports about: the video mode number, the number of columns and the active display page. Those items are returned in the
AXandBHregisters. The 2 subfunctions that were added use those same registers. The subfunctionsAX=0F01h EBX="CURS"EnableGraphicsCursor andAX=0F02h EBX="CURS"DisableGraphicsCursor expect a signature in theEBXregister so as to differentiate old from new. On return the unmodified contents ofAXconstitutes prove that the driver is installed, because the normal Video BIOS function 0Fh can never produce these values!Forget about speed This was one of those ocassions where speed just couldn't be an issue. If you scrutinize the source, you can find many speedwise inefficiencies such as the use of Self Modifying Code and the redundant preservation of a number of VGA registers, but because my cursor object is so terribly small and hardly has to change over time, it does not matter.
How to use
To install the driver just run the naked CURSOR.COM program.
To uninstall the driver just run the naked CURSOR.COM program again.
When installed you can communicate with the driver.
From within an application you use the new Video BIOS subfunctions:
AX=0F01h EBX="CURS"EnableGraphicsCursorAX=0F02h EBX="CURS"DisableGraphicsCursorAt the command prompt you run CURSOR.COM with a command tail:
CURSOR ?Reports whether the cursor is currently enabled or disabled.CURSOR 1Enables the cursor now. (Added for DOSBox)CURSOR 0Disables the cursor now. (Added for DOSBox)CURSOR *Shows help text. (* is any text)In order to minimize the impact on non-aware applications, the driver is installed with the cursor disabled by default. An aware application that operates in the graphics mode needs to enable the cursor explicitly. It is recommended to enable and also disable the cursor closely around any input procedure. Remember the driver was not designed to provide an omnipresent cursor!
DOSBox is special
Just like normal MS-DOS (6.20), DOSBox (0.74) does not show any cursor while in a graphics mode. Installing the driver will provide one!
However:
An unaware application
Some time ago I posted the Rich Edit Form Input program on CodeReview. It is an application that is all about inputting. Although the program does not target the graphics screens specifically, there's nothing in the program to prevent it from running on a graphics screen. Just the lack of a cursor would then be really annoying.
Well... No longer if today's CURSOR driver is installed. And because all inputs in this application use DOS input functions, the cursor will appear automatically if running on a true DOS. If on DOSBox you will have to enable the cursor manually from a command prompt.