Source: http://www.retronia.cl/foro/viewtopic.php?f=6&t=121
Timestamp: 2019-01-24 06:31:26+00:00

Document:
Modos de texto - Retronia
Inicio Índice general Retro Computadores General
Modos de texto
Retrocomputadores en general. Computadores ATARI, Commodore, Sinclair, MSX, AMSTRAD, Texas Instruments... y un laaaargo etc...
Mensaje por vitoco » Vie Feb 15, 2013 5:21 pm
Haciendo las capturas de pantalla de diversos retro computadores para animarlas y ponerlas en la portada del sitio, me di cuenta que cada marca o modelo de equipo tenía en su "modo terminal" características propias como colores por defecto y tamaño (columnas x filas).
Con "modo terminal" o "modo de texto" me refiero a la interfaz pura de texto, en donde se programaba BASIC, se interactuaba con el S.O. respectivo, y se corrían programas que usaban PRINT e INPUT para interactuar con el usuario.
Lo que aquí escribo es mi visión respecto a cómo Atari operaba, pero me gustaría conocer un poco más de otros computadores de la época, y de la boca de la misma comunidad: ¡ustedes!
NOTA: Yo hablo en pasado para darle el toque retro....
En la línea Atari de 8-bits, la "ventana de texto" era de 40 caracteres por 24 filas, aunque sólo se usaban 38 columnas por defecto, dejando las primeras 2 para margen. La zona de texto sólo podía tener un color y 2 tonos (uno para los caracteres y otro para el fondo). En BASIC, uno podía moverse libremente por la pantalla durante la edición de programas, pero seguía siendo modalidad de líneas de comando, permitiendo reingresar algo que aún permanece en pantalla tan sólo poniendo el cursor sobre algun caracter de esa línea y presionando "RETURN" (equivale a "Enter" o "Intro").
Pero Atari ofrecía 2 modos más de texto: uno que permite 20 carateres por línea pero usando 4 colores más el fondo y con el set de caracteres reducido a la mitad, y otro similar, pero del doble de alto (o sea, había espacio para un máximo de 12 líneas en pantalla). En estos modos no se podía usar el modo de texto libre para editar código, pero como las líneas de distintos tipos podían usarse para armar una misma pantalla especial para algún programa, en el sistema venía un par de modos especiales en que las 4 líneas inferiores eran en modo editable de 40 columnas y el resto tenía alguno de los otros 2 modos de texto (o de gráficos).
Dadas las caracteríasticas del hardware, era posible cambiar la definición del set de caracteres que venía en ROM, reemplazándola por una en RAM. Así se podía cambiar la tipografía o definir caracteres gráficos que representen sprites y generar animaciones cambiando la definición del caracter en memoria o el reemplazando el caracter en pantalla.
También era posible crear DL (Display List o lístas de despliege) que definían qué tipo de líneas usar en la pantalla, de arriba hacia abajo, por lo que se podía generar pantallas con textos y gráficos mixtos, e incluso espacio vacío que no ocupaba memoria.
Tambiés era posible generar líneas más anchas o más angostas, con lo que se podía ampliar el área visible (incluso saliendo por los costados de la pantalla, ideal para juegos con scroll horizontal) o más angostas (para ahorrar memoria, con solo 32 caracteres normales por línea).
Esos tres modos de texto eran todo lo que se necesitaba para hacer juegos y aplicaciones de ofimática, ¿pero era realmente así?
Para competir contra el importante mercado de los computadores de oficina, había que igualar su interfaz: los PCs usaban 80 columnas por 25 filas. Diversos proveedores introdujeron algún módulo de expansión, cartucho o modificación del HW interno. Incluso Atari liberó la XEP80. ¿Resultado? Programas incompatibles!!! Pero qué importa si lo que se quería era un computador de bajo costo para una secretaria acostumbrada a una máquina de escribir.
se veía asi:
Otro momento en que se requería de muchas columnas fue cuando se comenzó a usar el Atari para aceder a BBS's y a emular terminales VT-100 (80x24 u 80x25). Algunos programas de comunicaciones hacían uso de las expansiones disponibles (con ese costo adicional), en tanto que otros se las arreglaron para simular (emular) las 80 columnas. Para ello se usaron diversas técnicas, siendo la más usual la de dibujar texto en modo gráfico nativo, y la más creativa la del uso de flickering.
La técnica gráfica consistía en dibujar letras de 3x7 pixeles en modo gráfico 8, el de mayor resolución: 320x192, pero con sólo 1 color y dos tonos disponibles, similar al modo de texto por defecto. Si bien se lograba una legibilidad decente, su manipulación resultaba lenta en ciertas ocasiones, por ejemplo, durante un refresco de pantalla. Imaginen lo que sería avanzar una página al leer o editar un documento. Además, recordemos que a veces se perdían bytes en los modems si no se rescataban a tiempo, pues los buffers eran pequeños, y por otro lado la memoria del computador escasa, e incluso utilizada mayoremente por los pixeles del modo gráfico. Sin embargo, hubo programas que lograron optimizar rutinas mediante la manipulación de DL para obtener terminales VT-100 con respuesta a tiempo real. ICE-T es un programa de comunicaciones que se destacó en esta técnica. Un procesador de texto que usó esta técnica fue The Last Word.
La técnica del flickering se basaba en la utilización de un modo especial de texto de 40 columnas con 2 frames alternados a la fecuencia de refresco de la pantalla. En un frame se ponían sólo los caracteres que estaban en las columnas pares y en la otra iban aquellos de las impares. Como resultado se tenía cada par de caracteres utilizando la misma posición en pantalla. Para que no se superpusieran visualmente, cada frame tenía su propia definición del set de caracteres: uno cargadito para la izquierda y otro a la derecha, usando sólo los 4 bits respectivos para el caracter a definir en cada uno de sus respectivos 8 bytes. FlickerTerm fue un programa de comunicaciones que usó esta técnica. ¿Ventajas? No se requiere HW especial, ni tanta CPU o memoria RAM comparado al método gráfico. ¿Contras? El parpadeo constante termina cansando la vista, vienen los dolores de cabeza, etc...
Como indiqué al comienzo, me gustaría que otros aportaran información adicional para Atari o comparativa para otros computadores. Recuerdo que el ZX81 tenía una resolución en blanco y negro de 32x24, y el editor no era libre (sólo se podía editar la línea de más abajo), pero que era más que el VIC-20, que tenía 22x23!!! ¿Qué pasa con los MSX, Spectrum y el resto de los Commodore? ¿Se podía llegar a 80 columnas?
ModosDeTextoAtari.rar
(por si se opierden las imágenes remotas)
(47.81 KiB) Descargado 118 veces
Re: Modos de texto
Mensaje por renix » Vie Feb 15, 2013 5:36 pm
Yo cuando chico tuve Con mi Commodore 64 el Video Pak 80, que era un hardware adicional que se insertaba en el slot trasero de cartridges... la salida del monitor se conectaba a una entrada del cartucho, y del cartucho al monitor (comnutando los modos de video en el monitor a requerimiento del usuario con una combinación de teclas si mal no recuerdo), era bien incompatible con software tradicional, pero yo lo use bien y bastante con la planilla de calculo Multiplan y el procesador de texto speedscript de Commodore cuando estaba en el colegio.
Tambien se logro emular texto de 80 columnas en varios programas para hacer al Commodore una computadora mas de oficina redefiniendo todo el set de caracteres en modo gráfico nativo, un buen ejemplo de esto es GEOS (Licencia GEM) y sus softwares ofimaticos...
c64gboot.gif (1.21 KiB) Visto 2559 veces
c64gmenu1.gif (8.26 KiB) Visto 2559 veces
c64ginfo.gif (9.8 KiB) Visto 2559 veces
c64gpaint.gif (9.84 KiB) Visto 2559 veces
c64gwrite.gif (6.5 KiB) Visto 2559 veces
c64gwritepreview.gif (5.92 KiB) Visto 2559 veces
c64gpublish.gif (7.93 KiB) Visto 2559 veces
fuente de las imágenes: http://toastytech.com/guis/c64g.html
Después el Commodore 128 introdujo hardware nativo compatible con monitores cga de 80 columnas para correr bien el SO CP/M...
Despues coloco referencias y fotos...
Foto y descripcion del video Pack 80
video_pack_80.jpg (14.62 KiB) Visto 2560 veces
The Video Pak 80 switches Commodore 64's between a 40 or 80 column monitor in black and white, or back to the standard color screen. All switching is done through software and no cables need to be moved.
The Video Pak 80 includes a terminal mode, which brings communication with central data bases, at no extra cost. It also supports the advanced screen handling features of all Video Pak models such as erase to end of line, erase to end of screen, and dump screen to printer.
Y como dice ahí pero no me acordaba, era genial la característica de mandar la pantalla a la impresora con una sola tecla...
Que hice con el... bueno, oficialmente se perdió en un cambio de casa... pero con ese aparato conocí las EPROMS y su interior , jajajajaja...
Todo gracias al Hermoso VIC-II, el chip gráfico del C=64 y sus modos de video
Esta cita
Subject: "Re: VIC-II colors"
From: Robert 'Bob' Yannes
To: Philip 'Pepto' Timmermann
Date: 27.09.1999
I was involved with the development of the VIC-II, however the actual implementation of the design, including the Color Palette, was done by someone else. I have forwarded your message to him, but it is up to him if he wants to respond.
I can tell you that the design was based on the principle that adding a sine wave of a particular frequency and amplitude to an inverted version of the same sine wave at a different amplitude produces a phase-shifted sine wave of the same frequency. The amount of phase shift is directly proportional to the amplitudes of the two sine waves.
The VIC-II used the 14.31818 MHz master clock input (4 times the NTSC color burst frequency of 3.579545 MHz) to produce quadrature square-wave clocks. These clock signals were then integrated into triangle waves using analog integrators. The triangle waves were then integrated again into sine waves (actually rounded triangle waves, but good enough for this application). This produced a 3.579545 MHz sine wave, inverse sine wave, cosine wave and inverse cosine wave.
An analog summer was used to create the phase-shifts in the Chroma signal by adding together the appropiate two waveforms at the appropiate amplitudes. The Color Palette data went to a look-up table that specified the amplitude of the waves by selecting different resistors in the gain path of the summer. The end result was that we could create any hue we wanted by looking at the NTSC color wheel to determine the phase-shift and then picking the appropiate resistor values to produce that phase-shift.
Color Saturation was controlled by scaling the gain of the summer. When we picked the resistor values to determine the output phase-shift, we also scaled them to produce the desired output amplitude. Luminance was controlled using a simple voltage divider which switched different pull-down resistors into the open-drain output. We could create any Luminance we wanted by choosing the desired resistor value.
I'm afraid that not nearly as much effort went into the color selection as you think. Since we had total control over hue, saturation and luminance, we picked colors that we liked. In order to save space on the chip, though, many of the colors were simply the opposite side of the color wheel from ones that we picked. This allowed us to reuse the existing resistor values, rather than having a completely unique set for each color.
I believe that Commodore actually got a patent on this technique. It was certainly superior to the Apple or Atari approach at the time, as they ended up with whatever colors that came out--ours allowed the designer to freely select Hue, Saturation and Luminance.
Since all of this was based on selecting different resistor values and resistance varied from chip lot to chip lot, there was variation from one Commodore 64 to another. It wasn't as bad as it could have been though, since all of the Chrominance selection was based on resistor ratios, which could be kept constant even if the actual resistor values varied. Luminance was more of a problem. A trimmer resistor should really have been used to pull up the output. This would have allowed the Luminance to be adjusted for consistency from unit to unit, however Commodore didn't care enough about consistency to bother with adjusting each unit.
Robert 'Bob' Yannes
de este artìculo http://unusedino.de/ec64/technical/misc ... index.html me parece soñada...
Última edición por renix el Vie Feb 15, 2013 9:25 pm, editado 4 veces en total.
Razón: Agreguè fotos y texto
Mensaje por fcatrin » Vie Feb 15, 2013 8:18 pm
Aca va mi aporte con el modo de texto del ZX Spectrum.
No conozco mucho de esta máquina, pero algo puedo ayudar.
El ZX Spectrum tenía un único modo de video, y éste era gráfico. Para generar los caracteres, simplemente se pintaban uno a uno a partir de una definición en ROM.
La organización de este modo de video está diseñada para ocupar la menor cantidad posible de memoria. Cada linea está formada por 32 bytes que indican qué puntos de la pantalla tendrán el colore de foreground (INK) y cuales tendrán el color de background (PAPER).
Por ejemplo, si tenemos el byte 200, que en binario corresponde al 11001000, entonces el chip de video usará los colores INK, INK, PAPER, PAPER, INK, PAPER, PAPER, PAPER.
Los colors de INK y PAPER se obtienen desde una paleta de 8 colores: negro, azul, rojo, magenta, verde, cyan, amarillo y blanco. Aplicando avanzadas matemáticas sabemos que basta con 3 bits para representar uno de estos colores, por lo que se requieren 6 bits para representar un par INK/PAPER. No recuerdo para qué diablos eran los otros dos bits que sobran.
Cada par INK/PAPER seleccionado es válido para un bloque de 64 pixels (8x8pixels). Por lo tanto, en otra area de memoria tendremos la definición de cada par INK/PAPER para todos los bloques que forman la memoria de video.
El Spectrum tenía una resolución máxima de 256x192. Para representar los pixeles (INK o PAPER) se requieren 32 bytes por cada fila, hasta completar las 192 lineas. Es decir 6144 bytes de RAM.
Por otro lado, cada linea requiere 32 bytes para definir los colores que se usarán, y como son bloques de 8x8 entonces sólo se requieren 24 "filas de colores", es decir sólo 768 bytes, una ganga.
Con menos de 8KB ya tenía suficiente para desplegar una linda pantalla en colores. Sólo había que ser ingenioso en cómo usar los bloques. En un juego basado en tiles no hay problema, pero en una imagen "normal" se pueden sacar aplausos. Por ejemplo pueden observar detenidamente esta imagen para tratar de detectar los bloques ocultos:
Aca otro ejemplo en donde se pueden ver los bloques, sin embargo estan MUY bien utilizados
Cómo usaron estas avanzadas capacidades en la ROM del Spectrum?
Se incluía un editor de texto que aceptaba el ingreso de programas BASIC o comandos directos. Para los noobs del mundo de la programación esto quiere decir que podías escribir el código de un programa entero para ejecutarlo más tarde, o bien ejecutar un comando en forma inmediata y por única vez, sin concursos ni sorteos.
Para "facilitar" la vida del programador, el Spectrum usaba un modo de edición que con pocas combinaciones de teclas podías escribir complejos comandos BASIC, el que necesitaras aprender cientos de combinaciones de teclas era un detalle menor. Además que fueron lo suficientemente misericordiosos para incluir etiquetas en el teclado para recordar estas combinaciones.
Si no han visto el teclado de un Spectrum, es hora de que vayan por sus lentes con protección UV:
04-keyboard.png (32.97 KiB) Visto 2542 veces
Cómo se usaba esta cosa? Por ejemplo, al presionar "P" obtenías directamente "PRINT".
Por otro lado, el BASIC tiene comandos para asignar un color a las letras y el fondo, consistemente con la nomenclatura ya utilizada, el comando es INK para el texto y PAPER para el fondo.
Combinando sus infinitos colores, podías lograr pantallas llenas de colorido, como ésta:
Y como nunca nos salimos del modo gráfico, combinar texto y gráficos era nativo:
Volviendo a la pregunta original, y tras esta breve introducción. NO se podían obtener modos de 80 columnas, pero sí de 64 columnas (32 * 2 = 64, lo pueden comprobar con sus calculadoras). Esto pintando uno mismo los caracteres usando hasta 4 bits de ancho por caracter. Afortunadamente para el mundo del texto, el que no se pudieran usar colores diferentes en dos caracteres consecutivos no era problema.
Bonus track: El chip de video también te permitía definir el color del borde.
Y eso! Espero preparar el equivalente en el mundo MSX. COMING SOON.
Disclaimer: Ninguna membrana de Spectrum fue maltratada en la producción de este artículo.
Última edición por fcatrin el Dom Feb 17, 2013 9:21 pm, editado 1 vez en total.
Mensaje por renix » Sab Feb 16, 2013 4:47 am
Se fueron tus imagenes Franco... mejor subelas al foro (pestaña de abajo) y las insertas en el texto... se autoescalan..
Mensaje por fcatrin » Dom Feb 17, 2013 9:21 pm
Ahora sí que sí. Listas la imágenes
Mensaje por renix » Dom Feb 17, 2013 9:32 pm
fcatrin escribió: Ahora sí que sí. Listas la imágenes
Mensaje por Idk » Mar Feb 19, 2013 3:02 pm
Excelentes reviews
Siempre me quedó la duda de si el XEP80 será emulable, ¿esa imagen es de emulador?
Por otra parte, recuerdo hace varios años haber encontrado en un romset de atari, un cargador que pasaba programas normales al modo que tenía Ice-T, pero obviamente todo era más lento y algunos programas se caían xD
Mensaje por vitoco » Mar Feb 19, 2013 4:46 pm
Idk escribió: Excelentes reviews
El emulador Atari800 emula XEP80, pero por falta de tiempo no logré hacerlo andar correctamente, así que tomé una imagen básica y representativa que pillé en la red, pero estaba en JPG, así que algo de ruido tiene.
Hubo un controlador que permitía escribir en 80 columnas usando el método de ICE-T. ¿Era "X:"? Nunca lo probé, pero es probable que el resultado fuera como el que explicó Franco para Spectrum, claro que sin colores
Mensaje por Idk » Mar Feb 19, 2013 11:41 pm
Era un programa binario que se le indicaba que se quería ejecutar. Efectivamente era sin colores xD
Interesante eso del Atari800, le echaré un ojo
Registrado: Lun Mar 11, 2013 10:47 am
Mensaje por AsCrNet » Mié Mar 13, 2013 2:46 pm
vitoco escribió: En estos modos no se podía usar el modo de texto libre....
Mijo no es tan así, hay una forma de texto libre aunque no lo crea. Claro que debe ser algún bug del atari basic.
1.	Escriba GR.1 o GR.2 y enter.
2.	Escriba L. y presione simultáneamente las teclas entel y break.
3.	Si todo sale bien el cursor del atari desaparecerá, y puede escribir en el modo grafico 1 o 2.
4.	Si no resulta, intente paso 2 hasta que resulte.
Eso sería.. Y buen post...
Mensaje por Manuelink64 » Jue Mar 14, 2013 12:43 am
Tengo hato pa' leer, ahora tengo sueño, pero se ve mas que interesante
Saludos gurús!
Mensaje por bighead » Dom Mar 24, 2013 8:58 pm
yo he cargado el the las t word en mi atari y es cierto, parpadea raro, pero igual es legible.
que hardwatre utilizan los cartuchos para aumentar la resolución?
Mensaje por 133MHz » Mar Dic 10, 2013 1:10 am
Aquí se me va a notar lo joven, para mí el modo texto por excelencia es el 80x25 de IBM MDA/EGA/VGA. Van casi 33 años y me lo sigo encontrando!
MDA en particular, con su resolución de 720x350 y caracteres de 9x14, en un monitor de fósforo verde o ámbar de alta persistencia, es una delicia visual. Cuando el fósforo es continuo (sin triadas RGB) la resolución horizontal teóricamente aumenta al triple y la nitidez es incomparable a un display en colores. Aparte del papel impreso y la tinta electrónica creo que lo mejor que hay para lectura de texto es un buen monitor MDA. El ghosting provocado por la persistencia del fósforo lo hace aún más hermoso.
La fuente en particular me parece tan limpia, clásica e icónica, me encantaría saber quién la diseñó (algún empleado de IBM seguramente) y qué piensa cuando va al supermercado o a la farmacia el 2013 y ve la fuente que él diseñó (quizás durante los años 70) en un terminal POS moderno. Pocas cosas en el mundo de la tecnología tienen semejante 'inmortalidad'.
Según estuve leyendo IBM no protegió con copyright el character ROM que contiene estas fuentes y por eso se esparció como la plaga en tarjetas de vídeo Hercules, EGA, VGA, etc. Las únicas diferencias que he visto son:
Notebooks con fuentes especiales para la resolución nativa de sus paneles LCD
Las tarjetas de vídeo ATi por alguna razón traen una fuente distinta, más redondeada
Cero con y sin slash o punto en el medio
Z con una línea horizontal al medio
Una vez me dio por dumpear la ROM de una tarjeta de vídeo CGA para ver si podía extraer la fuente, es de 8 KB y lleva ambas fuentes para MDA y CGA, abrí el dump con el Tile Layer Pro, típico de la escena del ROM hacking de principios de siglo, y ahí estaban ambos sets de caracteres en toda su gloria y majestad:
También está en la Wikipedia:
Me agrada tanto la estética del IBM MDA que en mis máquinas uso la terminal en verde sobre negro
y el editor de texto plano con la fuente Perfect DOS VGA
Para obtener mi dosis diaria recomendada de perfección monocromática tengo:
Un monitor TTL de fósforo verde coreano genérico de alrededor de 1988 con el tubo en excelente estado:
Me es muy difícil capturar en fotografía la nitidez de la imagen, por el brillo del fósforo y porque apenas se usar una point-and-shoot, de pura suerte me salió esta con tremendo flash:
Monitor TTL de fósforo ámbar marca Amdek de 1983, lamentablemente tiene burn-in de una hoja de cálculo, pero aún tiene buen brillo y enfoque:
Lleva un filtro anti-reflejo que es como una pantimedia negra estirada, lo dejé fuera por estar algo rayado pero luego lo volví a poner porque ayuda a ocultar el burn-in, además le conseguí perillas de repuesto.
Un clásico del IBM PC corriendo gracias a un emulador de CGA para Hércules:
Monitor de vídeo compuesto de fósforo verde marca Talent (fabricado por Daewoo) de alrededor de 1986, tubo en excelente estado, fósforo de baja persistencia y parlante integrado:
Les debo la foto en funcionamiento, pero aprendí algo bastante importante gracias a este monitor. Al tener entrada CVBS y fósforo de baja persistencia es más idóneo para vídeo, y a diferencia de los TV blanco y negro fabricados en la era del color (que traen un filtro pasabanda con corte alrededor de los 3.5 MHz para que no se vean las 'hormigas' del color) este monitor pasa los 6 MHz completos de vídeo sin filtrar, haciendo que los chroma dots sean enormes y prominentes en un señal a color pero produciendo un aumento considerable de la resolución en una señal de luminancia pura. Con esto CGA compuesto monocromático de 80 columnas se vuelve usable, francamente no imaginaba que una señal de vídeo compuesto pudiera verse tan bien. Le he conectado la SNES y la C64 por luminancia pura y la nitidez es deslumbrante.
Todo esto de los modos de texto lo vemos desde un enfoque muy occidental, después de todo la informática nació en inglés y es muy fácil para las máquinas manejar las 26 letras del alfabeto romano, sin embargo otro de mis intereses es la cultura asiática, donde sus sistemas de escritura ideográficos de miles de caracteres les han puesto una barrera de entrada muy alta al mundo de las tecnologías de la información.
Japón no experimentó el surgimiento y la dominancia de la plataforma IBM PC como lo vivimos nosotros, por un tema netamente de lenguaje. Las bajas resoluciones de los adaptadores MDA/CGA, que si bien son suficientes para representar texto legible en el alfabeto romano simplemente no sirven a la hora de representar Kanji (caracteres ideográficos adoptados de China usados en la escritura japonesa). Mientras que con una celda de 8x8 píxeles es suficiente para representar una letra romana legiblemente, para representar el Kanji promedio se necesitan al menos 16x16 píxeles, ojalá 20x20. No solo las resoluciones de las pantallas no daban para mostrar un número decente de caracteres de 20x20, también al necesitarse al menos 2000 caracteres para la escritura del diario vivir los requerimientos de poder computacional y almacenamiento de datos del IBM PC simplemente no alcanzaban.
NEC fue como el IBM de Japón con su serie PC-9800, equipos basados en procesadores x86 de Intel pero con distinta arquitectura, distintos buses y de diseño propietario. Así como acá teníamos Apple, Atari, Commodore, TI, etc. ellos tenían Sharp, Fujitsu, Hitachi, Toshiba, etc fabricando máquinas de 8 y 16 bits incompatibles entre sí. Al igual que IBM logró establecer una reputación de "máquina poderosa para negocios" con su PC de 1981, NEC lo hizo con su PC-9800 de 1982. Para poder mostrar texto en japonés a una legibilidad y velocidad adecuada la máquina estaba dotada de dos ASICs de vídeo y un monitor capaz de mostrar 640x400 a 8 colores, junto con una ROM gorda llena de Kanji y un DOS de Microsoft adaptado para esta arquitectura propietaria y para trabajar con esos miles de caracteres en ROM a gran velocidad, algo muy avanzado y costoso para 1982 comparado con su contraparte occidental, pero que le aseguró el 90% del mercado y un lugar en cada oficina nipona.
Modo texto del PC98 en MS-DOS (640x400):
En 1986 varias compañías japonesas se unieron y trataron de destronar a NEC adaptando el PC AT para trabajar en japonés, llamándola AX. La idea era un adaptador de vídeo EGA con más VRAM que pudiera mostrar 640x480 y las ROM de Kanji junto con software modificado para darle la capacidad al PC occidental de 'hablar japonés' por hardware. AX no logró mover a NEC de su posición dominante sobre el mercado.
Tomó hasta 1990 con la masificación del VGA para que el PC occidental fuera un competidor serio al PC propietario de NEC. IBM desarrolló una versión de DOS llamada DOS/V (V de VGA) que es capaz de manejar texto en japonés puramente por software, aprovechando las capacidades del adaptador VGA y los avances en almacenamiento y poder computacional. Con esto recién el IBM compatible se volvió una plataforma viable en Japón, permitiendo la entrada de clones baratos y con la introducción de Windows 95 finalmente la brecha de compatibilidad entre PC y PC98 se cerró, terminando el reinado de NEC y uniendo a Japón con el resto del mundo de una vez por todas.
Lo interesante es como las fortalezas y limitaciones del hardware determinaron el tipo de juegos que se desarrollaron. La baja resolución y pocos colores de los equipos occidentales se prestaba para juegos de acción tipo arcade, mientras que el vídeo de alta resolución optimizado para texto de los equipos japoneses no era muy idóneo para ser manipulado a alta velocidad, por lo que allá fueron más populares los juegos tipo aventura gráfica, de mucho texto y gran presentación visual.
PC98 es un caldo de cultivo de juegos de historias de detectives, simuladores de citas y otras cosas no aptas para menores, pregúntenle a ya saben quién .
China no tenía una industria tecnológica sólida como la japonesa para desarrollar sus propios computadores que cumplieran sus necesidades lingüísticas, por lo que desde un principio tuvieron que adaptar a como de lugar el IBM PC occidental a su complejo sistema de escritura. Varias compañías taiwanesas desarrollaron sus propios sistemas propietarios sobre DOS incompatibles entre sí, hasta que llegó una compañía llamada ETen y desarrolló su propio sistema operativo compatible con DOS capaz de manejar texto en chino, llamado ETen Chinese System (倚天中文系統).
Al igual que los japoneses, partieron con una solución por hardware, en este caso tarjetas de vídeo occidentales modificadas con más VRAM y enormes ROMs llenas de caracteres, pasando por MDA, EGA, MCGA y VGA:
Al parecer esta es la primera, la Kingsun Hanzi Card:
Estas parecen VGA genéricas con mucha ROM a la izquierda:
Con el aumento del poder de procesamiento y almacenamiento, ETen fue evolucionando a una solución completamente por software, lo que lo consolidó en el mercado producto de la rampante piratería.
Con el lanzamiento de Microsoft Windows 3.1 y 95 en chino el desarrollo de aplicaciones rápidamente migró de ETen DOS a Windows, poniéndolos al corriente con el resto del mundo. Sin embargo, tal como aún en el space year 2013 encontramos sistemas DOS trabajando en tareas específicas en occidente, en China también es común encontrar terminales de supermercados, estaciones de buses/trenes, etc. corriendo ETen DOS como si el tiempo nunca hubiera pasado.
Hay mucha información sobre ETen en la Wikipedia en chino que lamentablemente está sin traducir, una pena puesto que me encantaría leerla.
Mensaje por renix » Mar Dic 10, 2013 1:53 am
Genial aporte 133Mhz... ¿Y como lo hacían con los teclados? Había algún híbrido qwerty recuerdo donde aparecían en el teclado los caracteres de inicio y fin de las letras chinas/japonesas según recuerdo en algún capítulo de Mundo 8X de Hernan Olguin...
Mensaje por vitoco » Mar Dic 10, 2013 10:47 am
Excelente artículo, 133MHz. ¡Gracias por el aporte! ¿Experiencia o investigación?
Durante la universidad tuve la posibilidad de trabajar con diversos tipos computadores con pantallas de fósforo monocromo. Lo normal era verde, por lo que el ámbar era considerado exclusividad. Cuando se armó la primer red de PC-compatibles en un laboratorio, éstos tenían pantalla con fondo blanco y letras negras, dejando en el olvido las otras. No recuerdo si eran Hércules o qué, pero sí era notable la "calidad" de la tipografía: letras con cachitos y curvas redonditas, nada pixelado. El otro extremo lo introdujeron los Mac: letras pixeladas como a propósito, pero de ancho variable (en modo gráfico, nunca de texto).
Sin embargo, siempre preferí el contraste de letras claras sobre fondo oscuro. Todos mis últimos programas utilitarios en el Atari eran de fondo azul más oscuro y con letras más brillantes que el modo gráfico 0 normal, y sin margen negro sino que del mismo azul oscuro. A unos pocos los dejé en fondo negro. No tenía sentido modificar el set de caracteres para poner cachitos a las letras, porque normalmente necesitaba toda la RAM disponible para buffer de algún tipo.
Mensaje por fcatrin » Mar Dic 10, 2013 5:10 pm
Tremendo aporte 133Mhz!
Mensaje por 133MHz » Mar Dic 10, 2013 10:28 pm
vitoco escribió: ¿Experiencia o investigación?
De todo un poco. Dados mi intereses por la tecnología y la cultura asiática el crossover es natural.
Mi poca experiencia ha sido a través de la emulación y Windows JP/CN en IBM compatibles. PC98 y el ecosistema de computadores japoneses es como un universo paralelo muy parecido al nuestro y único a la vez. Tendríamos como para llenar otro Retronia (レトロニア？)
renix escribió: ¿Y como lo hacían con los teclados?
Ese es otro gran problema que tienen. La entrada directa de Kanji/Hanzi es imposible (a menos que se tuviera un teclado de 2000+ teclas) por lo que hay que tirarle sí o sí software al asunto, ya sea reconocimiento de manuscrita o algoritmos heurísticos de conversión, ambos requieren más poder de procesamiento y almacenamiento del que podían entregar los equipos de la época de los 8 bits.
Afortunadamente el japonés tiene dos alfabetos fonéticos (hiragana y katakana) que son silabarios de 46 símbolos c/u, caben en un teclado QWERTY:
Las teclas extra tienen relación con las funciones de conmutación inglés/japonés y la conversión a Kanji que es manejada por el Input Method Editor (IME) en el sistema operativo. Teniendo tantas teclas de función extra con razón existe ese estereotipo que los japoneses la tienen chica (la barra espaciadora).
El IME es el software que se encarga de analizar lo que uno escribe en kana y hacer la conversión a kanji. El idioma está lleno de homófonos y palabras muy cortas, por lo que una palabra puede tener muchos kanji asociados, todos con significados y usos distintos dependiendo del contexto, además un kanji puede tener varias pronunciaciones! Al escribir algo fonéticamente y apretar la tecla de conversión el IME tiene que tratar de adivinar qué quisiste decir y tirar su mejor estimativa - si no es correcta se aprieta la tecla de conversión nuevamente para que despliegue una lista de todos los kanji posibles y seleccionar el correcto. El IME va aprendiendo de esta información que uno lo alimenta y agarra tu forma/estilo de escribir.
Se puede usar el IME japonés con un teclado occidental escribiendo con letras romanas, la conversión a kana se realiza automáticamente y para convertir a kanji se usa la barra espaciadora.
El chino no dispone de alfabeto fonético por lo que obligadamente deben usar métodos de entrada basados en la romanización de la pronunciación de los caracteres (pinyin) o en la descomposición de ellos en partes más simples (cangjie, wubi, zhuyin). Los métodos fonéticos son los más simples de aprender pero limitan la velocidad máxima de escritura alcanzable por la ambigüedad (muchos homófonos) igual que en el japonés, mientras que los métodos por composición tienen una exactitud muy alta y permiten escribir a gran velocidad, pero requieren aprender un montón de reglas para poder usarlos eficientemente. Por esto mismo no existe un método estándar de entrada de hanzi por teclado, y los teclados que se venden allá traen impresos los tres sistemas más conocidos: zhuyin, cangjie y dayi, haciendo que se vean muy 'cargados' visualmente, cuando en realidad no todos los símbolos se usan.
Un chino común puesto frente a un computador puede defenderse escribiendo lentito con el IME de Pinyin (ya que se enseña en los colegios desde 1958) un geek de la vieja escuela seguramente se peina con el cangjie, los más jóvenes con el wubi y el abuelo milenario cagó a menos que le pasen un tablet con reconocimiento de manuscrita. Da para pensar lo fácil que la tenemos nosotros.
Mensaje por dubcl » Mar Dic 10, 2013 11:06 pm
te pasastetete wn, la media explicación
Registrado: Vie Feb 15, 2013 1:25 am
Mensaje por Yoru » Mar Dic 10, 2013 11:32 pm
dubcl escribió: te pasastetete wn, la media explicación
Yo estaba leyendo lo de 133, pero tengo que seguir estudiando, se podria colocar como pinned en un thread aparte o fijar este? asi como para que no se pierda, todo el hilo esta bueno enrealidad.
Mensaje por renix » Mié Dic 11, 2013 12:32 am
Colocado como Fijo...

References: resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución