China DOS Union

Not bad, I'll give you points.

Thanks for the points! I will continue to work hard!

Re All:
Preview: The next version's Chinese character replacement rules will be simplified to facilitate the merging of character patterns and text! More functions are being added! The name will be changed to VTFmagic.COM, the program structure will imitate DEBUG, and it will allow inline control codes to be added in Chinese character strings (such as font selection, underscore, horizontal expansion, inversion, etc.), support input and automatic replacement of text files, separation and integration of character pattern files and loading programs, even replacing character patterns directly without generating files, restoring extended ASCII characters with regular glyphs while maintaining the display mode, allowing on-site editing of glyphs, etc. Now, everything is just an idea, and it will take some time to be launched. During this period, please put forward various opinions and suggestions!

Moderator willsort's suggestions are very standard, meticulous, and inspiring, and we would like to express our special thanks here!!!

[ Last edited by 本是 on 2005-11-7 at 12:29 ]

Pretty damn impressive!

Re 本是:

（http://www.cn-dos.net/forum/viewthread.php?tid=6916#pid104147）

In this version, the replacement is to split each Chinese character into two extended ASCII characters, respectively located in the left and right half-character model areas starting from C0h and 80h. So the new Chinese character internal code must be a combination of C0h + n and 80h + n (n = non-repeating Chinese character serial number).

　　Based on this hint of yours, I thought of another character model replacement scheme, that is, directly replacing the character models corresponding to the two bytes of the Chinese GB code with extended ASCII characters. For example, "start (C6 F4 B6 AF)", that is, respectively replace the character models of these four extended ASCII characters "C6 F4 B6 AF".

　　The advantage of this is that Chinese characters use the same encoding in the Chinese system and the VTF environment, which has high compatibility and relatively strong readability; the disadvantage is that two Chinese characters with the same bytes cannot be displayed at the same time. For example, "really (D5 E6 D5 FD)", the D5 on the left half-character model of the two characters "really" cannot be displayed at the same time.

　　Then, can the new version of the program simultaneously adopt two schemes? First try the above scheme. If the same bytes of non-identical characters are detected, then we will switch to the scheme of sequentially replacing the extended ASCII character set. Of course, this will greatly increase the complexity of the program. The decision to adopt it is still up to you.

Restore the extended ASCII characters of the regular glyphs under the premise of maintaining the display mode

　　Do you mean: Can the character model be restored without setting the mode, or set the mode before use?

　　If it is the former, then is there such a possibility: the same character in adjacent rows can correspond to different character models? That is, after using the program to modify the original character model of a character, this character previously displayed on the screen still remains unchanged.

　　If there is really such an ideal situation, then theoretically, it should be possible to use the method of modifying one line and displaying one line to gradually display all Chinese characters on the screen, not just 64 (or 128) Chinese characters. This limit will still exist within a single line, but usually a line displays up to 40 Chinese characters at most, so it can be ignored.

RE re-sort:
1. The "another font replacement scheme, that is, directly replacing the font of the extended ASCII characters corresponding to the two bytes of the Chinese GB code" you mentioned doesn't work. The reason is that for example, "start (C6 F4 B6 AF)", that is, after respectively replacing the fonts of these four extended ASCII characters "C6 F4 B6 AF", it will be troublesome to reorganize other Chinese characters ("破贫漂羝趑舳舣镀遏抖") from C6 F4 B6 AF! We need to remember: at this time, we are not under the Chinese character system, and no one is handling double bytes. In the Western text mode, single bytes are handled - one Western character represents half a Chinese character. So the replaced characters in the VGA TEXT SCREEN will have mismatched Chinese characters: randomly matching Chinese characters!
Of course, it can be barely possible when there are no its compatriots.

2. "Restoring the font doesn't need to set the mode" is completely possible. Actually, it is to replace the current character set with the standard font. Here, a distinction should be made: the video mode and the VGA character dot matrix 8 or 9 dot mode ("seamless or seamed" Chinese characters come from this). Changing the video mode will completely change everything, while changing the VGA character dot matrix 8 or 9 dot mode does not necessarily require changing the video mode.

3. Characters must correspond to the same font as long as they are displayed on the same screen! Because it is produced by the character generator (hardware). Unless you make a multi-byte system or display characters in graphic mode, the efficiency and resource occupancy will be completely different!

4. However, we can display 16X16 dot matrix Chinese characters horizontally expanded into 16X32 dot matrix characters. But it will occupy 4 Western characters. 24 dot matrix Chinese characters need 6 Western characters, 32 dot matrix Chinese characters need 8 Western characters,... Effects such as black-and-white inversion, with/without underline/wavy line, framing, inversion, mirroring, rotation, translation, etc., can all be done. Even vertically expanded characters - that is, a Chinese character occupies more than one line vertically - can be achieved!

5. In addition, double character set characters can be displayed on the same screen, that is, 512 characters. That is to say, up to 256 Chinese characters can be displayed! EGA can load up to 4 character sets at the same time, and VGA can load up to 8 character sets at the same time, but at most 2 character sets can be displayed on the same screen, and attributes need to be added to the characters for display! (It's relatively complicated!!!)

[ Last edited by 本是 on 2005-11-9 at 18:22 ]

Re 本是:

1、When I was discussing this replacement solution, I also considered the "compatriot" Chinese character issue you mentioned, so I first checked whether there were "compatriot" characters; or it could also be used in a special environment where only very few Chinese characters are displayed on one screen, and these Chinese characters are all non-"compatriot" ones, such as in the config menu. In this way, this function is separately made into a parameter, and the user judges whether the Chinese characters are compatriots and decides whether to adopt this compatibility replacement solution.

2、Then can what you call "restore the font" be understood as that what is reset is not the display mode, but the character set fon? And the reason why resetting the mode can restore the font is also because it also resets the character set font by the way?

3、I also predicted that the situation of displaying different fonts on the same screen may not be as I guessed. In addition, I once saw such a situation in Chinese character systems like UCDOS that intelligently recognize table line characters: if the same character is not followed by the corresponding table line character, the font changes; otherwise, it does not change. Is this the multi-byte system you mentioned?

5、I really haven't heard of the existence of "multi-character sets". I only know that there are multiple pages in the screen buffer, which realizes flicker-free screen switching.

Re regarding re-sorting:

1. The comparison and maintenance of identical Chinese characters and replacement of the original internal code is not technically more difficult: one character can be replaced one by one.

2. Your understanding of restoring the character pattern is correct! However, restoring the video mode is much more complicated – it involves the values of dozens of registers!

3. An n-byte system refers to a system where a "character" or word is defined by "n bytes", that is, treating "n bytes" as a whole code to map to the "character" set system (the "characters" in the "character" set system and the "characters" corresponding to "words" are not the same concept!!). These "n bytes" cannot be split and used, otherwise there will be garbled characters!

4. The intelligent recognition of table line characters in Chinese character systems such as UCDOS is precisely the conflict between the n-byte internal code and the single-byte character, which is a manifestation of the imperfect code system. Intelligent recognition is a kind of "remedy" to make up for this.

5. "Multi-character sets" do exist, but they do not have the usual meaning. It means that multiple "character sets" can be loaded in memory at the same time, but only a "single" or "double" character set can be used on the same screen. This is a technical regulation for E/VGA. The books on E/VGA hardware all introduce it like this. I have also tried displaying two character sets on the same screen, which requires resetting the color palette and displaying characters with attributes – it's not extremely complicated, but it's not simple either.

Learn, it seems I have too little knowledge.

Wait for the mature version and example tutorials.

Good news:
　　VTHZ.COM will be able to use the original Chinese internal encoding to display Chinese on the VGA text screen! If every byte in your Chinese string has no duplicates -- don't clone yourself!
　　The sample program for loading the Chinese character font is VTHZ2.COM, and the one that displays Chinese information in the original Chinese internal encoding is VTHZ22.BAT.
　　For comparison, the program that loads the Chinese character font is VTHZ1.COM, and the one that displays Chinese information in the new Chinese internal encoding is VTHZ11.BAT.
　　What's interesting is: aside from the different internal encoding replacements (18 bytes total for 9 Chinese characters), the rest of the program is exactly the same in VTHZ1.COM and VTHZ2.COM!!!
Note:
　　Friends using LCD screens, please run VTHZ1.COM and VTHZ2.COM with any parameter, such as VTHZ1 A or VTHZ2 /. Otherwise it may cause a hang!

Please wait patiently for the parent program that generates the above programs!

[ Last edited by 本是 on 2005-11-18 at 12:27 ]

Sorry. Deleted.

[ Last edited by 本是 on 2005-11-21 at 11:22 ]

Re 本是:

First, here are my test results for the demoVTHZ package. I combined the test batch files in the package (code shown later); the mode line is uncommented in MSDOS, and remains commented in XPCMD.

Report:

1. The effect is the same under XP CMD/COMMAND; see the quoted content for the results.

2. Used in a virtual machine, I tried various cases with MSDOS6.22/7.10, normal boot/F5 boot, VTHZ1.COM/VTHZ2.COM, direct invocation/invocation with parameters. In all cases, after the screen cleared, nothing else happened. After trying to type mode co80, the screen recovered. Running the test batch file, there was no display at all before pressing Enter twice, regardless of whether parameters were added.

3. In real-machine MSDOS, loading Wengier's boot disk through Grub, after running the test batch file, the result was normal, whether parameters were loaded or not.

After that, I tested the vtfse package. The usable platforms were the same as vthz1/2, and it could not run in the virtual machine's config environment. I found no problems with its functional parameters, but I did find that vtfse 8 and vtfse had the same effect.

Discussion:

1. Since the test machine uses an LCD screen, I did some testing with parameters/without parameters and found no difference; therefore, the issue discussed by yaya in the thread {6916} Chinese can be displayed even without loading a Chinese character support system? may need to be limited in scope, for example to the config environment. At present I can't test entering the config environment on a real machine, so this still needs discussion.

2. The virtual machine failure may be due to a problem with the virtual machine environment, because when I used debug in it to trace vthz1/2.com and other com programs, I found that both the p（roceed） and t（race） instructions could not change the IP register, which is abnormal. But in this environment, the original vthz.com can execute normally.

3. Looking at the encoding space used by vthz11.bat, it really is that the first byte goes from c0-c8 in the order the Chinese characters appear, while the second byte goes from 80-88, for a total of eight Chinese characters plus one full-width exclamation mark. The duplicate-character issue has already been taken into account, so it should have been handled manually; it probably hasn't yet been implemented in the generation stage. However, I still don't understand the significance of "partitioning" the first and second bytes?

4. After the successful real-machine test, the Chinese characters in the display result of vtzh1/2 look like the sans-serif font from Pocket China Dragon (XZL), so it shouldn't be taken from hzk16, right?

5. vtfse 0 should directly reset the display mode to 0, so it clears the original display mode, such as background color and foreground color.

6. As for the case issue in vtfse e "message", I guess it may come from DOS's own command-line parsing code; whether that is so or not, I suggest forcing users to put quotation marks around the displayed message in the prompt, to encapsulate the complicated details of command-line case conversion.

7. Above you mentioned that Chinese characters with gaps are 9*16; I don't quite understand that. As I understand it, in 640*480/80*25 display mode, each character can get at most 640/80=8 pixels of width, and in normal display, ASCII set characters mask off the outermost column of pixels, leaving 7*16. When displaying Chinese characters, following the display path of ASCII base characters, because one column is masked off, both the first and second byte of the Chinese character get masked off, so the Chinese characters show gaps and missing edges (if I remember right, the missing edge is on the right side, and from that I infer that ASCII display masks off the rightmost column of pixels).

@echo off

vthz1.com %1

echo 纮羴聜脙膭艆茊菄脙膭葓

echo Nei Ma = Gai Bian!

echo.

pause

::mode co80

vthz2.com %1

echo 不启动中文系统看中文！

echo Nei Ma = Bu Bian!

echo.

pause

::mode co80

└Ç┴ü┬é├â─ä┼à╞å╟ç├â─ä╚ê
Nei Ma = Gai Bian!

Press any key to continue . . .
▓╗╞⌠╢»╓╨╬─╧╡═│┐┤╓╨╬─úí
Nei Ma = Bu Bian!

Press any key to continue . . .

[ Last edited by willsort on 2005-11-20 at 14:21 ]

Re willsort:

About "Report: 2.":
　　VTHZ1/2.COM only replaces the character font and does not display the font. Whether there is a command-line parameter or not only changes the Western character width between 9 and 8.

About "Discussion: 1.":
　　I don't use an LCD screen, so I can't answer that.

About "Discussion: 2.":
　　I've also done virtual machine tests, and there shouldn't be any problem.

About "Discussion: 3.":
　　In VTHZ1.COM, the order of the new internal encoding is left byte=0C0h+character sequence-1, right byte=080h+character sequence-1, that is, both left and right bytes are arranged in order. The purpose is to make full use of the automatic expansion of the tab character into a 9-column display, although there are only 32 characters. In VTHZ2.COM, the new internal encoding order follows the string order of the original conventional internal encoding, that is, unordered, but convenient -- the original information doesn't need replacing. "After executing vthz2.com, the display result of vthz1 changed only in a few bytes" is purely caused by overlaying: once a replaced character font is not overwritten or restored in the next round, it just stays there, producing that result. I was puzzled by this too, but if I restored the font or screen before the next test each time, there was no temporary font residue.

About "Discussion: 4.":
　　The glyphs really do look like the sans-serif font of Pocket China Dragon (XZL). I use it not because it looks better, but because it is visually easier to recognize.

About "Discussion: 5.":
　　vtfse 0 resets using the original display mode and restores everything, including the character font, foreground/background colors, etc.

About "Discussion: 6.":
　　The complexity of the case issue in vtfse e "message" is determined by the rules followed when CONFIG.SYS is processed by IO.SYS: everything is converted to uppercase. Simplifying that is almost impossible, because for a program, the text of CONFIG.SYS is only "visible" after it has all been uppercased. Unless IO.SYS is rewritten, it is impossible to display the information "as is". The ECHO.SYS display method used in Wengier's Super DOS boot disk is even more troublesome -- it has to add / one character at a time in order to preserve lowercase! This is Microsoft's stupidity and high-handedness!!!

About "Discussion: 7.":
　　The "total number of rows" of dots in character display is a virtual concept; it doesn't actually exist, because the dot count of characters is another hardware concept! It is an adjustment brought about by the requirement for nicer-looking tab display, just as Chinese tab characters are correspondingly beautified in Chinese character support systems, and has absolutely nothing to do with the number of pixels in the scan lines of the 12h VGA text screen.

BTW：
　　My integrated VTFSE.EXE version combining device driver and command execution actually benefited from the moderator's reply to Wengier's post, thanks!

[ Last edited by 本是 on 2005-11-20 at 22:01 ]

Re: Originally:

　　Discussion 2: The main content in Report 2 is that the virtual machine test failed. In Discussion 2, I attributed it to a virtual machine problem, and the subsequent test result using another virtual machine Qemu was normal, which proved this point; however, there is also a counterexample I mentioned earlier, that is, the vthz generated by the original version of vthzmk can completely run normally in VPC. This seems to indicate that the virtual machine is not very compatible with the new version of VTHZ. For VTHZ1, through single-step tracking test, the problem occurs at Seg:129 (first loop), and it is guessed that this is the code for modifying the shape of the second half of the Chinese character. After executing int10, there is no display on the screen and it does not return to the command line. The reason for this is unknown. As for the virtual machine, the reason has not been found so far, and reinstalling VPC and the client system several times has not worked.

seg000:011D mov dl,
seg000:011F xor dh, dh
seg000:0121 int 10h
seg000:0124 add bp, 10h
seg000:0127 mov dl,
seg000:0129 int 10h

Discussion 3: Thanks for the reminder, I have understood this problem. Once again, I would like to provide a relatively simple explanation of this part from the help document of BatTool 3.2. I am very grateful for this document, which corrected many wrong understandings I had about VTF and DOS display modes.

The principle of displaying Chinese characters or graphics in English text mode is: The characters in VGA03 mode are 8*16 dot matrix English characters. The font program generated by BT modifies the character shapes of ASCII codes 128￣255, changing the original English symbols to Chinese characters. Since Chinese characters are 16*16 dot matrix, two characters form one Chinese character. In this way, 64 Chinese characters can be displayed (128 characters). Although it is a bit less, it is enough in batch processing and does not occupy memory! BT can help you generate a COM file that can modify the character shape. As soon as you run it, it will modify the English symbols to Chinese characters or graphics.
The scanning resolution of VGA03 mode is 720X400, and the display character resolution is 80X25. So each character is actually 9X16 dot matrix, but with an 8X16 dot matrix font, the 9th vertical line of general characters is blank. For the English tab characters with ASC values 192 to 224, the 9th vertical line is the same as the 8th vertical line, which is to make the table continuous instead of in segments. We change the shapes from ASC192 to the first character of each Chinese character, and change the shapes from ASC128 to the second character of each Chinese character, so as to form one Chinese character, and there is a line gap between each Chinese character (the 9th vertical line of the second byte). Note that when the ASC value of a character exceeds 224, it is not a tab character. Therefore, when the number of input characters exceeds 32, there will be a vertical line between each Chinese character. BT will directly read the Chinese character shapes from the screen (this is to be compatible with Chinese systems such as Yitian). Therefore, you should enter the Chinese system first and then use BT to generate the.COM file for modifying the character shapes. You can use BTE M to restore the original character shapes.

Quoted from the help document of BatTool 3.2 , author: Wang Haicheng, Beijing

　　Discussion 6: After your reminder, I also remembered that IO.SYS will capitalize all of it during the CONFIG.SYS loading process (except the set statements in multi-boot); but are a pair of quotes the "refuge" for lowercase letters? I checked the relevant source code and did not get such an answer. Does your program have special processing? In addition, the original intention of my previous text was to directly point out in the parameter description that the display information must be enclosed in double quotes, and the information that is not enclosed will be capitalized as an undocumented secret, so that the program can be more concise; and even directly use double quotes as the switch for display information, replacing the original parameter E.

　　Discussion 7: You explained it more abstractly here. I try to explain it more simply by using the knowledge obtained from the BT document.

First of all, 80*25 and 640*480 are not the same display mode. The former mode number is 02/03H (usually 03H under the DOS command line), which belongs to text mode, and the resolution unit is characters; the latter mode number is 12/13H, which belongs to graphic mode, and the resolution unit is pixels. The specific modes are shown in the following table. The pixel resolution of the text mode mentioned in the BT document is 720*400 (note: this statement is not supported by relevant materials and can only be used as a single evidence). According to this, the pixel resolution of each character is indeed 9*16.

But the characters in the standard ASCII set use only 8*16 pixel space for proper gaps (for aesthetic needs) when displayed. At the same time, part of the tab symbols (192~223) in the extended ASCII set use 9*16 pixel space for seamless connection of horizontal lines (also for aesthetic needs). The 9th column shape is directly copied from the 8th column, that is, the so-called "double-side" feature. Characters with this feature are temporarily called "double-side characters".

When displaying Chinese characters, because the first half of the Chinese character only modifies the 8*16 character shape space, the 9th column is left empty but still displayed, becoming the "gap" of the Chinese character; and the seamless Chinese characters displayed by BT exactly use the special display method of "double-side characters" to fill the gap with the shape of the column on the left side of the gap. Therefore, this display method is accurately called "gap filling" rather than "seamless". Of course, the method used by VTF is different, which will be described below.

Mode Display mode attributes
00H 40×25 16 colors Text
01H 40×25 16 colors Text
02H 80×25 16 colors Text
03H 80×25 16 colors Text
04H 320×200 4 colors
05H 320×200 4 colors
06H 640×200 2 colors
07H 80×25 2 colors Text
08H 160×200 16 colors
09H 320×200 16 colors
0AH 640×200 4 colors
0BH Reserved　
0CH Reserved
0DH 320×200 16 colors
0EH 640×200 16 colors
0FH 640×350 2 (monochrome)
10H 640×350 4 colors
10H 640×350 16 colors
11H 640×480 2 colors
12H 640×480 16 colors
13H 640×480 256 colors

The above is quoted from the book "Assembly Language", with some format adjustments

Similarities and differences between the principles of BT and VTF

1. The ways of obtaining Chinese character shapes of the two are similar: now they both prompt and then accept the Chinese characters input by the user from the keyboard, and do not support specifying Chinese characters on the command line. This will have a defect, that is, collecting character shapes usually requires entering the Chinese system, and modifying character shapes must exit the Chinese system or change the display mode, which is more troublesome to switch; but the sources of character shape collection of the two are different: BT directly reads Chinese character shapes from the screen. According to the author, this method is to be compatible with Chinese systems such as Yitian, while VTF obtains from the font files of the DOS Chinese system.

2. The default character shape modification encoding schemes of the two are the same: the first half of the Chinese character occupies the encoding space of 192～255, and the second half of the Chinese character occupies the encoding space of 128～191. In this way, the 32 characters from 192～223 can be fully utilized for the "double-side" feature; but they each have a set of different alternative schemes: BT allows character shape replacement not to implement partitioning in order to display the shapes converted from bitmaps, and all use the 192～223 double-side area characters; while VTF allows modifying the corresponding character shapes according to the original encoding of Chinese characters in order to omit the step of changing Chinese character encoding .

In addition, I noticed that 192～224 are not completely matched to the tab symbols. The tab symbols are from 179～218, a total of 40. The tab symbols from 179～191 do not enjoy the "double-side treatment" because their symbol graphics do not use the right side. On the contrary, the five square-shaped characters from 219～223 enjoy the honor because they use the right side and get the "kinship".

3. Both realize the display of seamless Chinese characters, but the implementation methods of the two are different: BT is realized by using 32 "double-side" characters, that is, the so-called "gap filling" display, while VTF can also modify the EGA/VGA registers to display characters in 8*16 mode in addition to the above method. This implementation ensures that Chinese characters are not deformed, and at the same time, more seamless Chinese characters can be displayed.

References:
BatTool 3.2 help information
http://bbs.wwwfox.net/cgi-bin/printpage.cgi?forum=2&topic=11034

Assembly language online courseware -> Appendix 3 Interrupt list -> BIOS interrupt - 1 Display service
http://www.mdjx.net/course/hep/huibianyuyan/Appendix/course.htm

ASCII code table
http://www.asciitable.com/

[ Last edited by willsort on 2005-11-29 at 22:38 ]