El otro día estaba comprando en Bon Area, y me fijé en que los terminales de pago (TPV), usaban aún modo texto, un paradigma que poco a poco había ido desapareciendo de nuestras vidas en ordenadores, cajeros automáticos, dispositivos móviles, puntos de información, etc; de los que hoy apenas nos queda el Teletexto.
Los que trabajamos con ordenadores remotos basados en UNIX, o de vez en cuando usamos la consola de comandos de Windows, seguimos viendo interficies basadas en texto, sin embargo, estas están en realidad simuladas sobre los modos gráficos de nuestro PC. Enseguida me vino a la mente el artículo sobre pictogramas.
Si bien los interfaces gráficos llevan ya con nosotros mucho tiempo, recordemos que el primer concepto fue el Xerox Alto, de 1973, no fue hasta la entrada de Windows, y su popularización con Windows 3, que pasaríamos de entornos basados completamente en texto, a entornos puramente gráficos.
Debemos admitir que una metáfora de escritorio gráfico, facilita el uso del ordenador, sin embargo, requiere de mucha mayor potencia de cálculo, que a veces no se justifica.
Por ejemplo Ashton-Tate Framework, a pesar de correr sobre DOS, ya ofrecía todo ello en 1984, de manera que podía ofrecer un modo pseudo WYSIWYG para el procesador de textos, o combinar hojas de cálculo y gráficos de las mismas sobre la misma ventana.
Las últimas versiones de Wordperfect a mediados de los 90, cambiaban la filosofía, y ahora en vez de usar la interfaz de texto, con una vista previa gráfica, trabajaba en modo gráfico, con un modo alternativo más ágil en modo texto. Ahora, veíamos representadas en pantalla las diferentes tipografías, sus tamaños, y sus formatos.
Lamentablemente, otras soluciones, abandonaron también el modo texto. El maravilloso entorno de Turbo C, basado en Turbo Vision, fue reemplazado por sus correspondientes entornos gráficos para Windows, y OS/2.
Hay que reconocer, que un editor de textos en modo gráfico, apenas aporta ventajas al usuario, y por contra, requiere de un mayor uso de CPU. El tradicional modo de 80×25 con 16 colores que ofrecía CGA/EGA, requería solamente mover 4 Kb. de información; el más avanzado de 80×50 de la VGA, 8 Kb., y modos más elaborados como el de 132×50, menos de 14 Kb. Comparado con el modo gráfico de escritorio más básico de 640×480 con 16 colores, son 10 veces menos, es decir, era 10 veces más rápido. O dicho de otro modo, era capaz de funcionar con procesadores 10 veces menos potentes, y su consiguiente ahorro energético.
De hecho con las capacidades de VGA de redefinir el juego de caracteres, aplicaciones como Norton Desktop, llegaban a ofrecer una sensación gráfica, pero basada totalmente en texto.
Vivimos en una época en donde sobran recursos… memoria y ciclos de procesador no son un problema asi que se desperdician!
Me acuerdo de ese Norton con caracteres redefinidos 🙂
Exactamente Josepzin.
El problema es que después, los usuarios siguen quejándose de eso… El rendimiento de su Windows, los renders en 3D Studio que tardan, o incluso que guardar un documento de Word necesite varios segundos.
Javier, me dio curiosidad la cuarta imagen (Turbo Editor 2.0): esa aplicacion la programaste vos?
Así es Dario, la programé yo hace cerca de 20 años. No era nada del otro mundo, pues partía de la base de uno de los ejemplos que se incluían en Turbo Vision, al que se le implementaron algunas mejoras, y ciertas optimizaciones.
Aún está disponible si tienes curiosidad.
Yo creo que el Norton Desktop estaba en modo gráfico porque de lo contrario la flechita del ratón no podría moverse pixel a pixel sino caracter a caracter y tampoco ofrecería la «transparencia» que se ve tras la flechita invirtiendo los colores de lo que hay tras ella. A no ser, claro, que cada vez que se moviese el ratón se redefinieran 9 caracteres con todo el bitmap que hay justo alrededor de la flechita del ratón y dibujara esos 9 caracteres en tiempo real por cada evento de movimiento del ratón, lo cual creo que sería muy costoso.
Tiene sentido lo que dices Daniel, pero basta ejecutar Norton Desktop en DosBOX o similar y forzarlo a 4,77 Mhz para ver que la velocidad de ejecución es puramente de texto. Piensa que una página de texto son 4K, mientras que en 640x480x16 son más de 150, es decir casi 40 veces más, y encima con la complejidad de cambiar de banco. Aún así para mi la prueba definitiva es que en las preferencias menciona «Colores EGA/VGA» y no «Modo EGA/VGA», de hecho si fuera modo gráfico tendría que pedirte la resolución a la que trabajar, y en cambio no lo hace.
Pues es curioso por lo del tema del ratón. Supongo que por cada movimiento del ratón se modifican en tiempo real los caracteres que están en torno al puntero de éste llamando a la interrupción de DOS para que dibuje una flechita justo en el lugar donde estaríamos apuntando. Vamos, que se han complicado la vida una barbaridad y debe dejar agotado al DOS de llamar tantas veces seguidas a la interrupción, aunque me sigue chocando porque se supone que un caracter de texto no podría tener más de un color ni en «foreground» ni «background» y donde está el puntero del ratón se muestran varios colores al mismo tiempo, un misterio cómo habrán conseguido esto en modo texto.
Es curioso porque acabo de probar Norton Desktop sobre Dosbox-X Daniel. El puntero del ratón es un cuadrado en modo texto, y se mueve en modo texto. Es decir, tal vez lo que tu recuerdas lo hacía el driver de mouse en cuestión y no el propio ND.
En cuanto a lo que comentas, en realidad no sería necesario llamar muchas veces a la interrupción. Recuerda que la mayoría de software accedía directamente al hardware. Así que sería interceptar la 33h y al detectarse movimiento, manipular los caracteres bajo el cursor.
Fíjate en la captura de pantalla que hay arriba, ahí se ve el ratón en forma de flechita. Lo que comentas de la prueba que acabas de hacer ya cuadra más, que sea un cuadrado en modo texto.
Sea como sea les quedó muy bien, parece realmente como si fuera un modo gráfico pero con las ventajas del modo texto. Aquella época de la informática hacía sacar más el talento de los programadores que la actual.
¡Saludos!
Me has hecho tirar del hilo DANIEL APARICIO GARCÍA. Esa captura la hice para el post sobre Norton Desktop que corría con una máquina virtual «real» sobre VirtualBox (no una emulación con DOSBOX). En mi configuración típica usaba MS-DOS 7.1 con el driver CuteMouse (cutemouse.sourceforge.net).
Revisando rápidamente el código parece que la clave está en restoresprite que usa copysprite que llama a makerow que es la que en modo EGA/VGA implementa la «magia». Es decir, como yo anticipaba, Norton Desktop, igual que Norton Utilities 8 que usaban la misma librería corren en modo texto. Es el driver de ratón en cuestión el que si soporta modo gráfico lo gestionaba.
Extraído de ctmouse.asm:
;ßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßß
; Transform the cursor mask row to screen
;ÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜ
;
; In: DX = screenmask[row] (which pixels will combine with screen color)
; BX = cursormask[row] (which pixels will be white/inverted, rather than black/transparent)
; SI = [spritewidth]
; CL (sprite shift when mode 13h)
; CH (sprite shift when non 13h modes) (??)
; ES:DI (video memory pointer)
; Out: none
; Use: bitmapshift (1 if mode 13h MCGA)
; Modf: AX, CX, DX, BX, SI, DI
; Call: none
;
makerow proc
assume es:nothing
cmp [bitmapshift],1 ; =1 for 13h mode
; if_ eq
jnz @@mrnz
;—–
; countloop_ ,si ; loop over x pixels
@@pixloop:
shl bx,cl ; if MSB=0
; sbb al,al ; …then AL=0
db 1ah, 0c0h ; JWASM and TASM use opposite encoding
and al,0Fh ; …else AL=0Fh (WHITE color)
shl dx,cl
; if_ carry ; if most sign bit nonzero
jnc @@mrnc
xor al,es:[di]
; end_
@@mrnc:
stosb
mov cl,1
; end_ countloop
dec si
jnz @@pixloop
ret
; end_ if
@@mrnz:
;—– display cursor row in modes other than 13h
makerowno13: call backup3ce
mov ax,0FFh
; loop_ ; shift masks left until ch++ is 0
@@m13zloop:
add dx,dx
adc al,al
inc dx ; al:dh:dl shifted screenmask
add bx,bx
adc ah,ah ; ah:bh:bl shifted cursormask
inc ch
; until_ zero
jnz @@m13zloop
; xchg dh,bl ; al:bl:dl – ah:bh:dh
xchg bl,dh ; JWASM and TASM use opposite encoding
; countloop_ ,si
@@m13loop:
push dx
; *** push bx ; must be omitted, but why?
mov dx,es
cmp dh,0A0h
; if_ ne ; if not planar mode 0Dh-12h
jz @@m13z
and al,es:[di]
xor al,ah
stosb
; else_
jmp short @@m13nz
@@m13z:
xchg cx,ax ; OPTIMIZE: instead MOV CX,AX
if 1 ; OLD BUT WORKING
; out_ 3CEh,5,0 ; set write mode 0: «color: reg2 mask: reg8»
mov dx,3ceh
mov ax,5
out dx,ax
; out_ ,3,8h ; data ANDed with latched data
mov ax,803h
out dx,ax
xchg es:[di],cl
; out_ ,3,18h ; data XORed with latched data
mov ax,1803h
out dx,ax
xchg es:[di],ch
else ; NEW BUT NO TRANSPARENCY
mov dx,3ceh ; graphics controller
mov ax,word ptr SEQ5[1] ; mode reg, ax=nn05
and ah,0f4h ; zap mode bits
or ah,2 ; set write mode 2: «color: ram, mask: reg8»
out dx,ax
mov dx,3ceh ; graphics controller
mov ax, 803h ; 8 pan 0, mode AND (TODO: preserve pan)
out dx,ax ; set operation
mov al,8 ; mask reg
mov ah,cl ; AND mask
out dx,ax ; set mask
mov byte ptr es:[di],12 ; color
mov ax,1803h ; 18 pan 0, mode XOR (TODO: preserve pan)
out dx,ax ; set operation
mov al,8
mov ah,ch ; XOR mask
out dx,ax ; set mask
mov byte ptr es:[di],15 ; color
endif
inc di
; end_
@@m13nz:
xchg ax,bx ; OPTIMIZE: instead MOV AX,BX
pop bx ; why was this push dx – pop bx?
; *** pop dx ; must be omitted, but why?
; end_ countloop
dec si
jnz @@m13loop
restore3ce:: push dx
push ax
mov dx,3ceh ; graphics controller
SEQ3 db 0b8h,3,0 ; mov ax,0003
out dx,ax
SEQ4 db 0b8h,4,0 ; mov ax,0004
out dx,ax
SEQ5 db 0b8h,5,0 ; mov ax,0005
out dx,ax
SEQ8 db 0b8h,8,0 ; mov ax,0008
out dx,ax
pop ax
pop dx
ret
;—– backup 4 EGA+ graphics controller registers, can only read VGA, not from EGA
backup3ce:: push dx
push ax
mov dx,3ceh ; graphics controller
mov al,3 ; operator / pan, pan is 3 LSB
out dx,al
inc dx
in al,dx
mov cs:SEQ3[2],al
dec dx
mov al,4 ; plane: 2 LSM, only for read
out dx,al
inc dx
in al,dx
mov cs:SEQ4[2],al
dec dx
mov al,5 ; mode: read, write, memmode/depth
out dx,al
inc dx
in al,dx
mov cs:SEQ5[2],al
dec dx
mov al,8 ; bit mask (…)
out dx,al
inc dx
in al,dx
mov cs:SEQ8[2],al
pop ax
pop dx
ret
makerow endp
¡Impresionante! ¿Cómo se consigue que en modo texto se pueda ver el cursor del ratón en modo gráfico?
No lo he revisado entero Daniel pero me da la impresión que lo que hace es redefinir el carácter de texto en base a lo que hay en el fondo. Entiendo que redefinirá hasta 4 caracteres para así simular el movimiento píxel a píxel. Lo más impresionante de Cute Mouse es que además es muy ágil y consume una fracción de memoria que otros divers de mouse para DOS.