¿Cómo pueden MS-DOS y otros programas en modo texto mostrar caracteres CJK de doble ancho?

9

He visto muchas pantallas de configuración del BIOS en modo texto en japonés y chino. Recientemente, incluso he visto la configuración de Windows XP en japonés. MS-DOS también tenía versiones japonesas. ¡Modo DOS real , no símbolo del sistema de Windows!

Configuración de BIOS japonesa

Japonés MS-DOS 6.2

Una pantalla de modo de texto típico tiene el tamaño de 80x25 . Dado que los caracteres japoneses tienen el doble de ancho de caracteres latinos normales, el número máximo de caracteres japoneses que se pueden mostrar al mismo tiempo en la pantalla es de aproximadamente 1000. Por lo tanto, necesitamos 2000 puntos de código para mostrar la parte izquierda y derecha de los caracteres.

Como modo de texto predeterminado solo puede mostrar 256 caracteres, pero los primeros 128 se usan para ASCII, por lo que los que se pueden usar están limitados a los 128 puntos de código altos. Si es necesario, podemos expandirlo a 512, pero esto aún no puede admitir suficientes puntos de código para la pantalla. Siempre me pregunto cómo lograron mostrar el gran conjunto de caracteres con un número tan limitado de caracteres.

[ Instalador XP japonés] 8]

El modo de texto en Linux parece usar el controlador de modo de gráficos porque puede mostrar Unicode y tiene muchos más colores. Pero no puedo explicar cómo lo hacen en las pantallas de configuración de MS-DOS y BIOS.


EDITAR: incluso he encontrado una entrada de texto en japonés para DOS

IME japonés

¡También hay coreano en modo texto!

coreano

VMWare Korean DOS

phuclv
fuente
Probablemente no esté mirando "caracteres" japoneses, es decir , kanji , sino hiragana o katakana , que tienen mapeos Unicode.
aserrín
@sawdust: mira la imagen de arriba y verás que puede mostrar no solo kana sino también kanji
phuclv
1
Tenga en cuenta que la página de la que probablemente tomó la captura de pantalla del instalador de OS / 2 dice justo al lado de la captura de pantalla que "la compatibilidad con el modo de texto gráfico se inicializó casi inmediatamente al iniciar OS / 2". Palabra clave gráfica .
un CVn
@ MichaelKjörling no solo es OS / 2, sino que los programas de configuración de MS-DOS y BIOS también tienen esta capacidad en modo de texto
phuclv

Respuestas:

6

El modo normal de "80x25 caracteres" es en realidad 720x350 píxeles (lo que significa que cada celda de caracteres tiene 9 píxeles de ancho por 14 píxeles de alto). Los modos de caracteres de doble ancho ("40x25") pueden simplemente interpolar esto al ancho más grande duplicando cada columna para guardar en la memoria de contenido de video (cortando la cantidad requerida de memoria de contenido de video a la mitad), o usar una memoria de glifos adicional e idéntica cantidad de memoria de contenido de video para aumentar las celdas de caracteres a 18 * 14 píxeles.

Bastante temprano (creo que se hizo cuando se introdujo EGA ), se agregó soporte para glifos de caracteres definidos por el usuario al modo de visualización de texto de la PC IBM.

El modo de texto normal de la PC IBM es simplemente una secuencia de 4000 bytes de RAM de contenido de video en una dirección particular. Estos se leen como un byte de atributos de caracteres (originalmente parpadeante, negrita, subrayado, etc .; luego se reutilizan para los colores de primer plano y fondo y parpadeo / resaltado, de ahí la limitación a 16 colores en modo texto) y un byte que describe el carácter a se visualizará. El glifo real que se mostrará para cada valor de byte de caracteres se almacena en otro lugar.

Esto significa que siempre que pueda conformarse con 256 glifos distintos en la pantalla en cualquier momento, y cada glifo se pueda representar como un mapa de bits de un bit de 9x14, simplemente puede reemplazar los glifos en la memoria para que los caracteres se vean de manera diferente . En parte, esto fue una parte de lo que mode con codepage selecthizo en DOS. Esto es relativamente trivial.

Si necesita más de 256 glifos distintos pero puede vivir con la cantidad reducida de glifos en la pantalla, puede elegir un esquema de 40x25 con glifos de doble ancho (18 píxeles de ancho). Suponiendo que la cantidad total de RAM de contenido de video es fija y suponiendo que puede aumentar la memoria de mapa de bits de glifo, puede pasar a usar dos bytes de cada cuatro bytes para representar un glifo en pantalla, lo que le da acceso a 2 ^ 16 = 65,536 glifos diferentes (incluido el glifo en blanco). Si te sientes atrevido, incluso podrías saltarte el segundo byte de atributo que te da acceso a 2 ^ 24 ~ 16,7M de glifos diferentes. Ambos enfoques se basan en un soporte de software especial, pero la parte de hardware y firmware debería ser bastante fácil de hacer. 65,536 glifos a 18x14 píxeles de un bit se traducen en aproximadamente 2 MiB, una cantidad considerable pero no insuperable de memoria en ese momento.

El inglés básico de EE. UU. Necesita al menos 62 glifos dedicados (números 0-9, letras AZ en mayúsculas y minúsculas), por lo que tiene algo como 180-190 glifos para jugar si también desea poder mostrar el texto en inglés de EE. UU. Al mismo tiempo tiempo e ir con 8 bits por glifo. Si puede vivir sin soporte simultáneo en inglés de EE. UU., Lo que podría elegir hacer en un entorno con recursos limitados, como la arquitectura de PC de IBM temprana, tendrá acceso a la cantidad completa de glifos.

Con algunos trucos, probablemente también puedas mezclar y combinar los dos esquemas.

No sé cómo se hizo realmente, pero ambos son esquemas viables sobre cómo obtener alfabetos "elegantes" con un recuento de caracteres particularmente limitado en una pantalla de PC de IBM en modo de texto que se me ocurre simplemente sentado delante de Stack Exchange por un momento. Es perfectamente posible que haya modos gráficos adicionales que lo hagan más fácil en la práctica.

Además, tenga en cuenta la distinción entre el modo de texto y el modo gráfico que muestra texto . Si está en modo gráfico, tal vez a través de VESA, que es bastante universalmente compatible, está solo en lo que respecta a dibujar glifos de personajes, pero también tiene mucha más libertad para dibujarlos. Por ejemplo, estoy bastante seguro de que las partes basadas en texto de Windows NT (que es la familia de productos a la que pertenece Windows XP) usan un modo gráfico para mostrar texto, incluida la pantalla de inicio de Windows NT 4.0 y BSOD.

un CVn
fuente
Puede ver que hay caracteres latinos de ancho normal junto a los japoneses / coreanos de doble ancho, por lo que no puede ser el modo de doble ancho de 40x25. Por lo tanto, no puede combinar 2 bytes de cada 4 bytes para representar el glifo. Usando el bit 3 del color de primer plano, puede representar 512 glifos al mismo tiempo, pero aún no es suficiente si los caracteres llenan la mayor parte de la pantalla en.wikipedia.org/wiki/VGA-compatible_text_mode#Fonts
phuclv
@ LưuVĩnhPhúc Puede recuperar la parte alta, o usar cualquier número de otros trucos posibles para mezclar caracteres que requieren varios bytes con caracteres de un solo byte. Todavía creo que la respuesta es reconocer la afirmación hecha en el párrafo inicial: incluso cuando se muestran caracteres, en algún nivel todavía se trata de píxeles, y esos píxeles se pueden trabajar aunque quizás no directamente.
un CVn
Sé todo lo relacionado con el texto y el modo de visualización de texto en modo gráfico, solo confundo cómo tienen suficientes puntos de código para multibyte ya que las partes izquierda y derecha requieren 2 puntos de código. Pero por lo que dijiste, he pensado en otra forma de hacerlo. Creo que su respuesta es aceptable
phuclv
1

Esto está simplificando lo que dice @Michael Kjörling.

En el modo de texto, tiene "memoria de pantalla" que tiene 1 byte por carácter en pantalla que le indica al adaptador qué carácter aparece en cada posición de la pantalla. (También hay bytes de "atributo" que le dicen al adaptador de qué color y cosas como subrayado, parpadeo, etc.).

El adaptador usa este byte para indexar en otra "tabla de caracteres" que tiene el pequeño 8x12 o cualquier mapa de bits del carácter. DOS llama a esta tabla de caracteres una página de códigos.

Comenzando con CGA, puede decirle al adaptador que obtenga la tabla de caracteres en un lugar específico en la RAM del adaptador. Cada adaptador tiene una ROM de caracteres que tiene la "fuente" predeterminada para esa tarjeta (que es la fuente estándar de IBM), pero puede indicarle al adaptador que cambie a una ubicación en la RAM y coloque sus propias imágenes allí.

Mientras el software sepa lo que está sucediendo, los códigos en la memoria de la pantalla que apuntan a las imágenes en la tabla de caracteres no se alinean con ningún código ASCII, aunque es más fácil si lo hacen. Notarás que hay códigos de memoria de pantalla (y formas de tabla de caracteres) para 1-31 que son caracteres ASCII no imprimibles, pero escribiendo directamente en la memoria de pantalla (recuerdos agradables de DEFSEG = &HB800 : POKE 0,1GW-BASIC para cambiar el carácter más superior a un smiley) mente) todavía puedes mostrarlos.

Por lo tanto, mostrar otros idiomas está bien, si puede colocar las imágenes correctas en la RAM del adaptador y tener el soporte de software necesario.

LawrenceC
fuente
¿Fue tan temprano como CGA? Debo estar envejeciendo. (Para mi defensa, lo hice escribir esa respuesta en gran medida de la memoria, y en realidad no han utilizado estas técnicas, incluso para la diversión en una eternidad.)
un CVn
Creo que tienes razón después de investigarlo, fue EGA.
LawrenceC
Sé que podemos cambiar la fuente del texto cambiando el puntero, he aprendido cómo hacerlo años antes, simplemente no sé cómo pueden representar el conjunto de caracteres de doble byte, ya que 256 o 512 puntos de código ni siquiera pueden contener suficiente el número máximo de caracteres diferentes en la pantalla, sin contar todo el conjunto de caracteres complejo
phuclv
1

Encontré algo en la página "Modo de texto compatible con VGA" en Wikipedia y también en algunos libros de programación VGA:

Los modos de texto EGA y VGA permiten 512 glifos simultáneos en pantalla, o 2 bancos con 256 glifos cada uno. El bit de atributo 3 (Intensidad de color de primer plano) también puede seleccionar entre el banco A o B. Lo que normalmente ocurre es que, de forma predeterminada, los registros de fuente A y B apuntan a la misma dirección, lo que le da solo 256 glifos. Entonces, para que funcione, debe configurar los registros de fuentes en las direcciones correctas.

Cada banco tiene 8192 bytes, y cada uno de los 256 glifos en el banco tiene 32 bytes (8 píxeles de ancho y 32 píxeles de alto). Puede configurar el registro de Scanline Count para indicar la altura correcta de sus caracteres. Las tarjetas VGA imprimen 400 líneas de escaneo en pantalla mientras que EGA imprime 350 líneas de escaneo en pantalla, por lo tanto, para proporcionarle 25 filas de caracteres, establecen su altura de caracteres en 16 y 14 líneas de escaneo respectivamente. Además, en VGA cada glifo puede tener 8 o 9 puntos de ancho, pero la novena columna está en blanco o solo una repetición de la octava columna. Todos estos glifos en ambos bancos pueden ser definidos por el usuario.

¿Cómo puede obtener más de 256 caracteres diferentes en pantalla en algunos idiomas? En los ejemplos anteriores, cada carácter extranjero especial está formado por dos glifos (izquierdo y derecho), o más. Podría establecer los primeros, por ejemplo, 128 glifos del banco A para el texto ASCII, y aún tendría 128 glifos del banco A + 256 glifos del banco B = 384 glifos para que los personalice.

¡Además, puedes combinar diferentes lados izquierdo y derecho para crear un gran conjunto de personajes! Digamos, por ejemplo, que de los 384 glifos definidos por el usuario, desea reservar 184 para el lado izquierdo y 200 para el lado derecho: ¡puede tener 184 * 200 = 36800 caracteres diferentes! (claro, la mayoría de ellos probablemente serían caracteres no válidos para ese idioma, pero aún así puede obtener una buena cantidad de combinaciones válidas).

En el ejemplo del idioma japonés anterior, tiene los caracteres "ha" y "ba" que comparten el glifo del lado izquierdo. Lo mismo para los personajes "si" y "zi". Los lados derechos "ko" y "ni" son tan similares que podrían compartir el mismo glifo del lado derecho. Lo mismo podría decirse de los caracteres "ru" y "ro". Con un buen diseño, podría ampliar su conjunto de caracteres muy bien. El glifo del lado derecho del carácter "le" aparece en la parte superior izquierda de la pantalla (en gris), y en la barra de desplazamiento vertical, también se cambiaron los botones arriba y abajo, lo que significa que al menos una parte del banco A También se utilizó para acomodar los nuevos glifos.

En conclusión, las funciones de la cadena del BIOS en la era temprana de la PC no eran compatibles con Unicode, pero no tiene que serlo. Todo lo que tenía que hacer era personalizar sus 512 glifos y establecer los registros EGA o VGA correctos. Por ejemplo, puede personalizar los glifos "! @" "# $" "% ^" "& *" "Çé" "ñÑ" a sus caracteres extranjeros (en el banco A o B), ¡y luego hacer que el BIOS imprima "! @ # S% ^ & * çéñÑ "a la vez. BIOS no verificaría los glifos. Tampoco podría usar las funciones del BIOS, ya que podría escribir directamente en la memoria de video. Para usar un glifo del banco B, simplemente configure el atributo Color de primer plano del carácter en un valor entre 8 y 15 (color brillante).

(perdón mi Inglés es malo)

Fabiano Freitas
fuente
Sé que podemos tener 512 caracteres como se menciona en la pregunta. Sin embargo, la cuestión es que los programas anteriores muestran los verdaderos caracteres Kanji , no Kana, lo que aumenta significativamente la cantidad de cosas que se muestran al mismo tiempo. En sistemas con codificación limitada de medio ancho, se usará Katakana, que tiene maru y tenten separadas, por lo que se puede usar el mismo punto de código para し y じ, o は y ば, sin necesidad de compartir las partes izquierda y derecha
phuclv
0

Investigué un poco y, como anticipé, debe usar el modo de gráficos o necesita soporte de hardware especial porque no hay forma de usar más de 512 caracteres en el modo de texto VGA

Bueno, el DOS en sí mismo no puede imprimir en charsets más allá de 1 byte por char, porque usa las funciones del BIOS que a su vez usan el hardware VGA que no puede tener más de 2 x 256 caracteres de tamaño. Así que esto nuevamente suena como un trabajo para un DRIVER, uno que usa el modo de gráficos para representar fuentes extensas. Ya tenemos soporte para las fuentes Unicode en algunos editores gráficos de texto DOS y similares (gracias :-)) y si se utiliza DBCS o UTF-8, ambos comparten el "tamaño del carácter puede ser uno o más bytes" manejando "anomalía" .

¿Alguna vez habrá algún soporte oficial para el idioma japonés en FreeDOS?

La versión japonesa de DOS (DOS / V) utiliza el primer enfoque y simula el modo de texto al representar los caracteres en modo gráfico utilizando un controlador especial. El controlador sigue el estándar IBM V-Text, que es un mecanismo para extender las capacidades de visualización de texto del DOS. Puede elegir entre varias fuentes de 16/24/32/48 puntos como esta

Fuente DOS / V

Algunos otros sistemas de modo de texto también usan la misma técnica. En FreeDOS puede cargar algún controlador especial para soporte japonés

FreeDOS controlador japonés

El procesador interceptará las llamadas int 10h e int 21h y dibujará el texto manualmente, por lo que funcionará incluso para los programas normales de inglés. Pero no funcionará para programas que escriben directamente en la memoria VGA. Para imprimir caracteres japoneses int 5h e int 17h también están enganchados.

De acuerdo con el manual de DOS / V, el BIOS de IBM también agregó soporte para V-Text a través de int 15h con las siguientes 4 nuevas funciones

5010H Video extension information acquisition
5011H Video extension function registration
5012H Video extension driver release
5013H Video extension driver lock setting

Supongo que esta es también la razón por la que vi soporte japonés en los BIOS de mis PC antiguas

Sin embargo, la lentitud del modo gráfico puede introducir fallas mientras se desplaza, lo que requiere un manejo especial.

DOS / V es en realidad la primera solución de software para el modo de texto japonés

Mientras tanto, se había realizado una investigación seria en IBM Japón desde principios de la década de 1980 para producir una solución de software al problema de mostrar caracteres japoneses. Con la llegada de los monitores VGA de alta resolución, procesadores más rápidos y memorias y discos duros más grandes, los diseñadores de los laboratorios de investigación Fujisawa y Yamato de IBM se dieron cuenta de que la información sobre la forma y el tamaño de los caracteres kanji podía almacenarse en el disco, cargarse en una memoria extendida, y se muestra a través de VRAM en modo gráfico. (La "V" en DOS / V, por cierto, proviene del monitor VGA necesario para mostrar los caracteres japoneses a través del software).

DOS / V: la solución de software (software) a los problemas de software (software)

Según el mismo artículo, antes de la invención del DOS / V, todos los otros sistemas necesitan una ROM Kanji en el hardware.

Todas las marcas de computadoras utilizaron soluciones de hardware para manejar la visualización de caracteres japoneses, almacenando los datos de todos los caracteres en chips especiales conocidos como ROM de kanji. Este método requería que el código de doble byte para cada carácter de entrada de teclado se enviara a la CPU, que a su vez extrajo el carácter correspondiente de la ROM kanji y lo envió a la pantalla a través de VRAM en modo texto. El uso de kanji ROM significaba que la forma de cada carácter era fija, mientras que el uso de VRAM en modo texto estableció un tamaño de punto estándar de 16x16 para cada carácter.

Por ejemplo, el IBM Personal System / 55 que utiliza un adaptador gráfico especial con fuente japonesa, por lo que obtienen el modo de texto real

A principios de la década de 1980, IBM Japón lanzó dos líneas de computadoras personales basadas en x86 para la región del Pacífico asiático, IBM 5550 e IBM JX. El 5550 leyó las fuentes Kanji del disco y dibujó texto como caracteres gráficos en un monitor de alta resolución de 1024 x 768.

https://en.wikipedia.org/wiki/DOS/V#History

Similar a IBM 5550, el modo de texto tenía 1040x725 píxeles (fuente de 12x24 y 24x24 píxeles, caracteres de 80x25) en 8 colores, puede mostrar caracteres japoneses leídos desde la fuente ROM

La arquitectura AX utiliza un adaptador JEGA especial en lugar del EGA estándar.

AX (Architecture eXtended) fue una iniciativa informática japonesa que comenzó alrededor de 1986 para permitir a las PC manejar texto japonés de doble byte (DBCS) a través de chips de hardware especiales, al tiempo que permitía la compatibilidad con el software escrito para PC IBM extranjeras.

...

Para mostrar los caracteres Kanji con suficiente claridad, las máquinas AX tenían pantallas JEGA (ja) con una resolución de 640x480 en lugar de la resolución EGA estándar de 640x350 que prevalecía en otros lugares en ese momento. Los usuarios normalmente pueden cambiar entre los modos japonés e inglés escribiendo 'JP' y 'US', lo que también invocaría el AX-BIOS y un IME que permite la entrada de caracteres japoneses.

Las versiones posteriores también agregan un hardware especial AX-VGA / H y AX-VGA / S para la emulación de software en VGA

Sin embargo, poco después del lanzamiento de AX, IBM lanzó el estándar VGA con el que AX obviamente no era compatible (no eran los únicos que promovían extensiones "súper EGA" no estándar). En consecuencia, el consorcio AX tuvo que diseñar un AX-VGA (ja) compatible. AX-VGA / H era una implementación de hardware con AX-BIOS, mientras que AX-VGA / S era una emulación de software.

Debido a la menor disponibilidad de software y otros problemas, AX falló y no pudo romper el dominio de la PC-9801 en Japón. En 1990, IBM Japón presentó DOS / V que permitía a IBM PC / AT y sus clones mostrar texto en japonés sin ningún hardware adicional utilizando una tarjeta VGA estándar. Poco después, AX desapareció y comenzó el declive de NEC PC-9801.

La serie NEC PC-98 también tiene una ROM de caracteres en el controlador de pantalla

Una PC-98 estándar tiene dos controladores de pantalla µPD7220 (un maestro y un esclavo) con 12 KB de memoria principal y 256 KB de RAM de video, respectivamente. El controlador de pantalla maestro maneja la fuente ROM, mostrando caracteres JIS X 0201 (7x13 píxeles) y JIS X 0208 (15x16 píxeles)

No sé la situación de los chinos y coreanos, pero creo que se utilizan las mismas técnicas. No estoy seguro de si hay otras formas de lograrlo o no

phuclv
fuente
-1

Necesita un modo gráfico en lugar de un modo de texto codificado para poder mostrar los glifos de texto unicode. Luego configura MS-DOS para usar una fuente Unicode y cambia la asignación de idioma para usarla.

http://www.mobilefish.com/tutorials/windows/windows_quickguide_dos_unicode.html

headkase
fuente
No, mira las imágenes que publiqué, es el modo real de DOS, no el símbolo del sistema en Windows
phuclv
El título en el artículo es completamente incorrecto y engañoso. cmd.exe no es DOS a pesar de tener una interfaz de terminal similar a DOS y algunos comandos similares. ¿El símbolo del sistema y MS-DOS son lo mismo?
phuclv