中国DOS联盟

Not bad, I'll give you points.

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

Re All:
:lol: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!

:PModerator 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 ]

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.

Sorry. Deleted.

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

@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

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 ]