Después de esta brainstorn, y después de haberme quedado media noche acostado
pero pensando en el desarrollo del MNBIOS, me dí cuenta que después de todo
estas críticas por parte de Adriano, después de todos van a tener su efecto
constructivo.
Conceptos a saber:
1. Adriano me prguntaba que porque una aplicación NO SELECCIONADA podía
redibujar o REDISEÑAR su ventana y la misma aplicación en proceso de fondo no
iba a poder....lo que implicaba que el simple ejemplo del relojito del sistema
no iba a poder ser.
La respuesta era obvia para mí, el re-dibujado de cualquier ventana es un
evento que se lleva a cabo solo durante la ejecución de ciertas funciones por
parte de la aplicación activa..... mientras que un proceso de fondo
generalmente interrumpe a la aplicación activa en cualquier momento de su
código y si ambos accesan al VDP van a surgir conflictos....el conflicto más
común que se me ocurre es que el proceso de fondo alteraría el puntero a la
VRAM que tiene el VDP... y si la aplicación activa justo estaba haciendo uso
del mismo sería un desastre...
En el sistema UZIX de mi querido Adriano así como según él me contó los
sistemas UNIX en general, solo dan soporte a consolas virtuales de texto. (lo
que no sé es si cada aplicación está en fullscreen o puede haber visualizandose
2 aplicaciones al mismo tiempo en ventanas). Y si una aplicación desea usar
gráficos es problema de la aplicación cuidar que no haya conflictos. Claro,
tengamos en cuenta que el sistema UNIX fué diseñado para aplicaciones de
servidores, de ahí que es multiusiarios - grupos de usuarios, multitarea en
general. Es decir, son diferentes metas que motivaron su desarrollo.
Es una meta del MNBIOS ser el sistema operativo más completo para el ambiente
MSX y diseñado exclusivamente para tal. Por lo tanto no nos podemos quedar en
los modos textos, ni siquiera soportarlos porque para hacer un sistema así ya
existe el MSX-DOS...
El MNBIOS no solo pretende ser completo sino también ser una capa para aislar a
las aplicaciones del hardware. Para el día de mañana no depender tanto de los
chips que dejaron de producirse. Pero al mismo tiempo se diseñaron las
funciones de acceso al VDP más rápidas posibles de armar, cualquier programador
que haga algunos timings estará sorprendido.
A que vamos con decir que queremos las rutinas más rápidas. Ya que de esa forma
el programador no encontrará razones para hacer acceso directo al chip mediante
I/O y usará la capa del kernel porque da lo mismo en cuanto a timing.
Si yo insertara código en esas rápidas funciones para evitar el problema del
conflicto que se generaría con el puntero de I/O a la VRAM estaría en contra de
la regla 1 que es "VELOCIDAD". Esta opción es guardar en memoria en forma
actualizada el valor del puntero y antes de volver de los procesos de fondo
usar esa información para reestablecer el valor del puntero.
Pero el puntero es solo 1 tema en conflicto cuando ambos procesos (aplicación
activa y procesos de fondo) hacen uso sinmultaneo del VDP.
Acá quiero aclarar algo, el objetivo del MNBIOS es ser una capa que aisle a las
aplicaciones del chip, sin embargo soporta funciones de acceso directo a la
VRAM y acceso a los registros... Si la aplicación hace uso de ese juego de
funciones, la aplicación automáticamente es CHIP dependiente....como el mnbios
soporta un juego de funciones alternativas, esta es una decisión que debe tomar
el programador y la pregunta es ¿Puedo programar lo que tengo pensado hacer sin
accesar a la VRAM o registros?, si por cuestiones de complejidad la respuesta
es NO, entonces tendrá una aplicación chip dependiente.
Cual es la solución para evitar que ambos procesos, el de fondo, y el activo no
se molesten en el VDP...la respuesta que cumple con los objetivos de
"VELOCIDAD" y "EXPANDIBILIDAD" es crear 1 función que deberá ser ejecutada por
cualquier aplicación que sea desarrollado para el MNBIOS.
Cuestiones a considerar....
. Normalmente cuando una aplicación hace uso de funciones de acceso a la VRAM,
es porque quiere realizar un proceso de dibujado de una complejidad tal que no
es suficiente las funciones que trabajan con vectores del bitmap.
. Ahora esa función a ejecutar va a consistir solamente en un LD A,valor + LD
(flag),A + RET... algo sencillisimo, que a nadie le va a molestar ejecutarlo
antes de empezar el proceso de dibujado, y otra vez después de concluir ese
proceso de dibujado.
Que se busca aca?, que ese FLAG indique si los procesos de fondo pueden o no
ser ejecutados... de modo que un proceso de fondo no se ejecute en un mal
momento...
A no abusar... la idea es activar el FLAG solo en momentos puntuales y
pasajeros... este sistema sería útil también para salvar otros posibles puntos
de conflictos..
Aclarando que un proceso de fondo solo puede ejecutarse si se interrumpe código
pertenecienta a la aplicación activa.... no puede durante la ejecución de
código drivers o kernel.
Mediante este sistema y una apadpación del sistema windowing es posible que
cualquier aplicación tenga salida a la pantalla en forma de proceso de fondo.
Por lo tanto el MNBIOS sí será multitarea según los requisitos de Adriano...y
sin perder velocidad...
Adaptar el sistema windowing, requerirá abrir un código que desde hace 3 años
que está cerrado y perfectamente programado.... son rutinas en extremo
complejas... y esto solo trae postergar la fecha de lanzamiento un o dos meses.
Saludos
Flyguille
[Se han eliminado los trozos de este mensaje que no contenían texto]
