[ATARI] aRANYM

[Jaime Cagigal Bordonaba]

El Fri, 30 Aug 2002 20:25:58 +0200
Luis Manuel Asensio Royo <lasensio at airtel.net> escribió:
> 
> El punto más flaco de los Macs es el propio sistema operativo, que más que un 
> sistema parece un freno de mano, porque lo hace más lento de lo que es...
> 
ciertamente si... luego no se si el aprovechamiento del hard es
óptimo... me refiero a emuladores en Amiga/Atari corriendo más deprisa
que un Mac con el mismo procesador a los mismos Mhz.

De todas formas el kernel del MacOS X debe trabajar bastante bien en
multiprocesador por lo que he leido. Y la version 10.1 ha solucionado
muchos problemas de lentitud que había.

> en Linux pasa exactamente lo mismo, con sendos 'mamotretos' como son el Gnome 
> y el KDE, verdaderos 'vampiros' de recursos...
> 
Incluso unas simples X con un fvwm95 son tragonas. Coges mi ordenador
con linux y ese entorno y desde luego va muchisimo más lento que MacOS8
o AmigaOS. Si, ya se que hace virguerías para poder ser manejado
remotamente... pero para el usuario de casa que? el usuario de casa no
suele necesitar controlar remotamente un ordenador desde otro.
> 
> O sea, usa del dispositivo dsp que implementa el Linux, ¿no?
> 
Querían emular el DSP del Falcon... aunque me parece que aun no habían
empezado con esto.

> En su día pensé en el MiNT porque hasta donde yo se era el único sistema cuyas 
> fuentes estaban disponibles, pero ahora tenemos el EmuTOS, y podemos ir aún 
> más lejos, adaptarlo para grabarlo en las FlashROM  de las placas PeCeras al 
> estilo del Milan, y poder tener un 'Atari' real sin que nos cueste un ojo de 

El problema es que además de que cada bios cambia con cada placa y no
suele haber espacio para meter más cosas.

> la cara, que es otro de los problemas del XTos, que la placa base ella solita 
> es posible que acabe con un precio de alrededor de 1000 euros (más o menos lo 
> mísmo en dólares), demasiado caro...
> 
Lo malo es que hacer tiradas pequeñas de placas eso es lo que suele
valer. Mucha gente piensa que se pasan en el precio pero el problema es
que sale así de caro hacer placas modernas con tantas capas. Por cierto
habeis visto el commodore one? muy gracioso. Aunque vaya, creo que tiene
más gracia un 64 de los clásicos.

> Me parece perfecto. Si además se incluye un emulador dde ST/STE y herramientas 
> de desarrollo entonces es posible que la plataforma tenga futuro. Lo del 

Eso no forma parte del proyecto, pero alguien puede portar un emulador
de Atari y correrlo dentro del TOS como una aplicación más. Suena bruto,
pero con los micros actuales corriendo nativamente no hay problema.

> acceso al hard directamente me preocupa, ya que hay partes que no son fijas en 
> los PeCes, como son las tarjetas de red, de vídeo, de sonido, de firewire, 
> etc, que hemos de reconocerlo, no quedará más remedio que acceder a dichos 
> dispositivos a través de librerías.
> 
A la mayoría de estas cosas se accederá por medio de drivers en caso de
que a alguien le de por hacerlos (francamente, lo dudo mucho). Supongo
que de hacerse drivers nativos (insisto en que es mucho trabajo) se
harán para las tarjetas más famosas por ej en red para las RealTek, de
video para las BT878, de sonido para las Soundblaster... en fín, de
todas formas yo no contaría mucho con las ultimas tecnologías como USB o
Firewire con soporte nativo, porque necesitan un Stack USB o Firewire.
La solución de usar el kernel de linux para acceder a los drivers a
través del framebuffer device en el apartado gráfico es la más realista.
A los dispositivos se suele acceder por drivers, y a estos drivers por
medio de librerías. El uso de librerias dinámicas es una ventaja para
cualquier sistema con un sistema operativo moderno.
Un ejemplo sencillo de la ineficacia del uso de librerías estáticas. El
puerto de la librería SDL tiene bugs en algunso modos gráficos usando
P96. Si alguien compila un programa con una librería estática el
programa se compila con ese bug. La version 1.2.4 no lo tiene, los
programas que usaban librerias dinámicas pueden funcionar sin el fallo,
pero los nuevos no. Que pasa, que la nueva librería introduce un fallo
nuevo? en ese caso si el programa requiere obligatoriamente esa version,
la copias al directorio del programa que la requiera y a funcionar.
Las librerias se suelen usar cuando se van a usar durante un rato y se
cierran cuando se van a dejar de usar. Cerrarlas y abrirlas
continuamente sería tan estúpido como capturar video cerrando y abriendo
el dispositivo de captura cada frame. Por favor, otra discusión sobre
librerías dinámicas vs estáticas no, que carece de fundamento. Si te
refieres al problema de que haya que tener un driver específico para
cada cosa la solución es usar el driver genérico que aprovecha la
abstracción que ofrece Linux, por ejemplo usando el framebuffer tal y
como he comentado.

> > La versión final será autoinstalable desde CD, sin necesidad de instalar
> > Linux ni nada previamente, pero mientras esto llega, tampoco es tan difícil
> > instalarla de momento.
> 
> Cuando llegue ésto, sería muy interesante el poder tener la posibilidad de que 
> el sistema se pueda instalar en la FlasROM de la placa base, y así acelerar el 

Eso es bastante inviable ya que las placas madre no soportan varios
tamaños de bios (al menos el 99%), no queda espacio para meter más datos
y cada bios es específica para cada placa. La bios es la capa de
abstracción que te evita conocer cada placa. La única opción viable para
usar una FlashROM sería una tarjeta PCI que la contuviera para que se
ejecutase el código. Aunque sinceramente yo tiraría de disco duro y me
dejaría de tarjetas. si todo va mal, metes el cdrom, autoarrancas el
sistema desde el CD y recuperas los datos del HD/Arreglas el arranque/lo
que sea.


Saludos
Jaime Cagigal Bordonaba