DR DOS 6.0/V

[roytam1]

The most notable feature is that, ViewMAX(GEM) with DBCS support!


@John Elliott, How does GEM(ViewMAX) support DBCS?

[roytam1]

and its font file looks like ordinary DRFONT file, but with DBCS included.

[roytam1]

without loading DR's $font.sys, ViewMAX can display SCBS katakana only.

[John Elliott]

@John Elliott, How does GEM(ViewMAX) support DBCS?

I don't know without disassembling it.

The VDI / driver API passes characters as counted sequences of 16-bit words, while the AES is more inclined to use ASCIIZ strings, so it would seem logical for the AES to decode each DBCS pair to a character ID word. But it might pass each pair to the VDI as two words, and let the VDI handle the decoding.

[John Elliott]

@John Elliott, How does GEM(ViewMAX) support DBCS?

Here's an outline of the support in the video driver (SDJVG9.VGA).

• At startup, it calls INT 15h/AX=5000h to get the address of the DOS/V 'read font' function. If this is present, it sets a 'supports DBCS' flag on the system font.
• Also at startup, it uses INT 21h/AX=6507h to get the DBCS lead byte table.
• When a string is passed to any of the text output functions, if a DBCS font is in use and the DBCS lead byte table is loaded, the code checks for DBCS lead/trail bytes in the string passed to it, and combines each pair into a 16-bit character ID.
• When drawing a character, it checks to see if the character ID is above 256. If so, it calls the DOS/V 'read font' function to get that character's bitmap, and instructs the drawing code to draw 16 pixels from offset 0 of that bitmap, rather than 8 pixels from the system font bitmap at a given offset.
• There are similar checks in the optimised monospaced text drawing code, allowing characters to be 8 or 16 pixels wide.

Possibly to reduce the size of the driver, the following functions are no-ops:

Marker drawing: v_pmarker, vsm_type, vsm_height, vsm_color, vqm_attr
General drawing primitives: v_bar, v_arc, v_pieslice, v_circle, v_ellipse etc.
Support for loadable fonts: dt_loadfont, dt_unloadfont
Text queries: vqt_attr, dqt_extent, dqt_width, dqt_name, dqt_fontinfo, dqt_just
Line / fill queries: vql_attr, vqf_attr

[roytam1]

@John Elliott, How does GEM(ViewMAX) support DBCS?

Here's an outline of the support in the video driver (SDJVG9.VGA).

• At startup, it calls INT 15h/AX=5000h to get the address of the DOS/V 'read font' function. If this is present, it sets a 'supports DBCS' flag on the system font.
• Also at startup, it uses INT 21h/AX=6507h to get the DBCS lead byte table.
• When a string is passed to any of the text output functions, if a DBCS font is in use and the DBCS lead byte table is loaded, the code checks for DBCS lead/trail bytes in the string passed to it, and combines each pair into a 16-bit character ID.
• When drawing a character, it checks to see if the character ID is above 256. If so, it calls the DOS/V 'read font' function to get that character's bitmap, and instructs the drawing code to draw 16 pixels from offset 0 of that bitmap, rather than 8 pixels from the system font bitmap at a given offset.
• There are similar checks in the optimised monospaced text drawing code, allowing characters to be 8 or 16 pixels wide.

Possibly to reduce the size of the driver, the following functions are no-ops:

Marker drawing: v_pmarker, vsm_type, vsm_height, vsm_color, vqm_attr
General drawing primitives: v_bar, v_arc, v_pieslice, v_circle, v_ellipse etc.
Support for loadable fonts: dt_loadfont, dt_unloadfont
Text queries: vqt_attr, dqt_extent, dqt_width, dqt_name, dqt_fontinfo, dqt_just
Line / fill queries: vql_attr, vqf_attr

Cool! Thanks for figuring it out!