[ATARI] Re: Atari digest, Vol 1 #181 - 5 msgs
Atari Emulación España (Gabriel Huertas)
gabrielhuertas at terra.es
Tue Nov 27 09:04:27 CET 2001
>Para la programación del C en sí te sirve el libro de Kernighan y
>Ritchie, los creadores del lenguaje. Ahí podrás aprender la sintaxis y
>manejo del lenguaje. Del compilador, créeme si te digo que con el
>Turbo/Pure C, salvo por el tema de las funciones del sistema oerativo,
Diablos!!!! Me refiero a las funciones específicas que supongo que
implementará el turbo C para manejar un entorno gráfico como el del Atari,
no a aprender C standard, sino a las funciones si es que las tiene para
generar menús, manejar gráficos, sonidos, MIDi, etc. El C ansi ya lo manejo
, fue el primer lenguaje que aprendí, en el que soy un principiante es en el
Basic, del que no acabo de comprender porque se dice que es el mas sencillo,
mas bién es el más "guarrete". También manejo el Visual para windows porque
tengo la documentación , lo que no tengo es documentación de ninguno para el
Atari.
>bastante más complejo, pero no muy dificil. Para coger práctica, empieza
>por hacer algo sencillo.
No si de dificil no hay nada, pero si tienes la documentación, cuando he
visto lo fácil que era hacer con GFA un programa con menús , diálogos, etc,
y encima lo compilas (porque compila de verdad) y te ocupa menos de 10 k, y
no necesita resources (como a mi me gusta), pues la verdad es que me he
quedado pasmado. Y eso es lo que me da un poco de rabia. que, estoy teniendo
que trabajar con Basic, cuando podría etar trabajando con C si tuviera los
manuales. Por otro lado, también me ha sorprendido que el GFA basic no se
parece en nada al Visual Basic en cuanto al propio lenguaje se refiere, éste
último es el que he tenido que aprender a utilizar para programar unos
microcontroladores (a donde vamos a llegar si los fabricantes te ofrecen ya
el software de desarrolllo para basic en vez de para C). Vamos el parecido
es poco más que anecdótico. No conozco el ansi Basic, así que en realidad
no se cual de los dos es el que es "menos Basic" (probablemente el GFA, pues
te permite trabajar con muchos recursos que tradicionalmente he oido que no
tiene el BASIC, desde introducir lineas en ensamblador directo , hasta
trabajar en bajo nivel con acceso al hardware real y isar punteros, y esto
sin contar conque el resultado es un programa enteramente compilado, y no un
ejecutable interpretado, como el de Microsoft)
>Ten en cuenta que el C es un lenguaje de medio nivel, entre el
>ensambdlar y un lenguaje de alto nivel como el Basic. Puedes definir
>funciones, procedimientos, tipos de datos y estructuras como lenguajes
>de alto nivel como el Pascal, pero también tienes el control de punteros
>y la posibilidad de inserta código en ensamblador cuando lo necesites.
"Please", no me expliques más lo que es el C que me esta poniendo "colorao".
:-) No en serio, ya te he dicho que es el lenguaje que utilizo para
programar autómatas (cuando está disponible) y para programar PC y otras
cosas raras. Convendrás conmigo en que saber programar en C para windows no
te convierte en un programador de Atari. El ansi abarca muy pocas cosas, por
ejemplo los manejos de gráficos y de multimedia en General, son exclusovos
de cada compilador, conque más variarán entre distintas máquinas. Cuando Uso
el Borland C 4.5 y 5.5 , que son los que uso en PC mayoritariamente, la
mayoría de las funciones que manejan cualquier aspecto multimedia son
propias del compilador y no portables. Y si uso el Visual Studio, ya no te
digo nada, ahí es que ni te enteras realmente de lo que pasa por dentro del
ordenador, das órdenes muy generales para que el genial windows se encargue
de todo. Por ejemplo, confieso que no se abrir un ventana directamente
(esto no viene ni en el manual de VS v.6 en adelante), lo hago "visualmente"
con el entorno de desarrollo. Además de que los únicos experimentos que hice
para manejo real de las api en windows 3.11, por alguna razón no funcionan
en los win 32. Incluso muchas fuentes de versiones de visual Studio 5, dan
problemas inesperados en versiones posteriores a las del 98 . Hasta algunos
comandos cambian y son reemplazados por otros, y lo que es peor, algunos
siguen existiendo pero cambian de significado (hablo del VB que es el que he
podido comparar). Por eso digo, que sin documentación ¿como te vas a
enfrentar a un compilador determinado, a menos que quieras trabajar en
Ansi.? En ansi ya me va bien con el Borland, desde que lo hice funcionar en
el Atari, entiende bién el Ansi y todo va a las mil maravillas, pero claro ,
lo que necesito no son programas de cónsola, o con miserables ansi gráficos
y chorradas así, lo que quiero es explotar el entrono gráfico, el sonido y
el MIDI.
>¿Hackearlos?, no entiendo bien lo que quieres decir. La principal
Me refiero a la acepción del diccionario de "hack" no a las connotaciones
que conlleva. Tener los RSC fuera permite diseccionar muy facilmente el
programa, para modificar su presentación, he incluso te sirve de guía para
cambiar más cosas.
>El mejor de todos es el Interface. Te permite importar ficheros en
>formato IMG entre otros pocos, y tienes un gran control sobre los
>elementos de diseño de los menús y cajas de diálogo. También hay otro
>editor de RSC que se llama K-Resource, que tampoco esta nada mal...
Ya he tenido ocasión de probar el Interface, y no está mal, aunque le hecho
en falta ciertas cosas (el vicio y el apego a la comodidad que coges cuando
te acpstimbras a los entornos "visuales" de PC). Desde luego está mil veces
mejor que el de atari. El otro no lo he visto todavía. En cualquier caso,
desde el GFA por ejemplo es hasta más rápido crear menus desde el popuo
lenguaje que usar resources, y además los programas compilados ocupan 10
veces menos de memoria, a eso es a lo que me refería. Consigo programas sin
usar resources qe ocupan sobre los 10 k (me ha sorprendido bastante) y
usando los resources, se acercan a los 100k.
--__--__--
>¿Te refieres a algo similar a programación visual pero en C?, que yo
>sepa está el ACS Pro, que es un entorno de desarrollo visual para GNU
>C/C++, Pure C, Lattice C, Turbo C y Pure Pascal. Cuesta unos 59 euros.
Gracias por la información, no me cuesta nada porque ya lo tengo (je,je...
me traje todo lo que había relacionado con Atari cuando me fui de la
empresa... lo que pasa es que ni se lo que tengo, todo está catalogado en
bases de datos y hasta que no se lo que tengo que buscar no me pongo)
>conozco el Fave Value y el ACS Pro. Creo que hay otro pensado para
>ensamblador, pero ahora no recuerdo el nombre.
El ensamblador si que no lo toco... si uviera que programar
microcontroladores, por ejemplo, en ensamblador, tendría que aprender uno
distinto para cada uno. Demasiado fuerte para mí.
>Desde luego no es fácil la gestión de los menús y cajas de diálogo, pero
>yo lo hacía en C programando yo mismo las rutinas, e incluso me hice mis
En realidad no será tan dificil (en el GFA por si solo no se me hubiera
ocurrido como dominar el Gem, pero con el manual ha sido un juego de niños,
unas horas han bastado para poder crear y compilar programas con cierta
seriedad), lo que si convendrás conmigo es que usaras elementos que no son
del ANSI, así que por mucho que sepas programar en C, si vas a tratar de
hacer algo serio para una máquina concreta, tendrás que tener en el mejor de
los casos la documentación del compilador, o al menos en el peor muchos
ejemplos para dedicarte al análisis.
>Bueno, puede tomar otra postura, el crear un grupo de trabajo y
>liderarlo para llevar el proyecto. Es lo que se suele hacer en Linux con
>algunas aplicaciones de código abierto.
La verdad es que mientras los vaya haciendo todo y deprisa el solito con su
hermano tampoco hay que quejarse :-)
>Lo de las ampliaciones del modo de vídeo es interesante. Incorporar los
>modos de vídeo del Falcon supongo que puede ser relativamente fácil. El
>modo de 256 colores es similar al de 16, los bits que forman el número
>de registro de color con el bit del mismo valor de 8 byes seguidos, y el
>de 64K colores, los primeros 6 bits corresponden al color rojo, los
>siguientes 5 al verde y el resto al azul, si no recuerdo mal.
¿Tienes completa documentación al respecto? Como ya he dicho en otras
ocasiones, no se han implementado mejoras en modos gráficos porque no se
dispone de la documentación completa para poder emular un hardware en
concreto. Ahora por ejmeplo, se está intentando conseguir informaciñón sobre
las gal de muchas llaves de cartucho para crear un "llavero" virtual para el
Steem (¡la repera!!). He incluso se ha comentado la posibilidad de dotar de
hardware real de puerto de cartucho al PC, pero falta documentación seria.
>No, no lleva el DSP incorporado, sino que se le podrá conectar la
>tarjeta Déesee, inicialmente desarrollada por Rodolphe Czuba para el
>Milan II, y que al final la compró Frontier Systems, el cual se encarga
>del desarrollo y fabricación. La info se puede sacar de varios sitios:
:-( Mala cosa )-: Pues esto me suena ya a no poder competir en precio con el
mercado PC. Las tarjeta Deesse si no recuerdo más cuesta más que un falcon
enterito, y esto no es buena cosa, sobre todo cuando está por ver que
funciones por ejemplo el CAF.
MagiC OS: http://www.magical-sides.de/ (inglés)
Atari.Org: http://www.atari.org/ (inglés)
XTOS.DE http://xtos.de/ (inglés/alemán)
> simulación de los DSP es mejor que los DSP hardware, y en algunos sentidos
> esto es cierto, está claro que para trabajos a tiempo real tener un DSP
> posibilita las cosas, y digo "posibilita" en vez de "facilita" porque sin
un
Estoy de acuerdo contigo. Con la emulación puedes manipular ficheros de
audio previamente grabados en disco, añadirle efectos, etc, pero en
tiempo real, cuando se tienen que aplicar no sólo uno, sino varios
efectos de los datos que se van recibiendo de las entradas, es muy
dificil, e imposible bajo windows. Si fuera posible, en el caso de los
Mac no exitirían esas placas con varios DSP que se controlan con algunos
programas de audio, que por cierto, son muy bonitos visualmente pero por
lo que he oído, como no tengas una 'bestia parda', no son de mucha
utilidad...
> No olvidemos que las sesiones Dos de cualquier Win32 son simples
> emulaciones. Muchos programas dan problemas, el que no se lo qurea que
No se si considerarlas emulaciones. Todas las versiones de windows,
exceptuando el NT y sus 'derivados', se ejecutan sobre DOS, es decir,
que en realidad el windows es sólo un entorno gráfico que usa el DOS. En
el ME intentaron engañar (parece que se vuelve costumbre) a los usuarios
ocultándolo durante el arranque, pero con algunos trucos se le puede
hacer 'salir a la luz'. Patético, pero cierto...
> la claqueta pierde el ritmo y en MSDOS no. A parte de este fallo en los
> relojes internos (fallo que imposibilita utilizar aplicaciones "realtime"
> críticas de DOS bajo Windows, hay programas que nisiquiera cargan.
Para empezar el windows solo puede trabajar 'bien' si tiene activa la
memoria virtual. Se puede desactivar, pero no lo recomiendan. Encima,
salvo alguna honrosa excepción, las 'aplicaciones' tienen para mi punto
de vista una tamaño exagerado, y ésto hace que cuando tienes abiertas
cuatro o cinco aplicaciones, haga un uso frecuente de la memoria
virtual, frenando el sistema e interfiriendo las transferencias de
disco. Encima, por su 'diseño', no distribuye correctamente la carga de
trabajo, y ésto lo he notado con el Netscape, que cuando intenta acceder
a un sitio concreto, parece que se haya quedado 'clavado', e incluso
afecte al resto del sistema imposibilándote cambiar de tarea con el
ratón, y luego tiene 'poltergeist', como el último que he tenido con el
PC del trabajo, que sin encomendarse ni a Dios ni al Diablo, se
'preparaba para pasar a modo suspendido' sin yo indicárselo. Me lo ha
hecho dos veces en una semana y me ha obligado a deshabilitar de la BIOS
la gestión de energía. Si a ésto le sumamos que le han 'embutido' el
Internet Explorer en el sistema (otro freno), la larga lista de
librerías dinámicas que tiene, de manejo de dispositivos, etc, un
entorno gráfico sobrecargado de tonterías, etc, todo ésto lo anula por
completo para cualquier tarea que requiera precisión temporal.
Lamentable, pero cierto...
> De hecho, empecé a hacer una lista de programas que funcionaban al 100%
bajo
> Steem, y tuve que abandonar... es mucho más práctico hacer una lista de
los
> programas que no funcionan. Hasta ahora, el único que me falla es Degas
Vamos, que es mucho más corta la lista de programas que no van, ¿eh? :-D
'Esto demuestra el buen trabajo de Russell. Creo recordar que el Steem
se basó en el código original del WinSTon, el cual se dejó de
desarrollar, ¿no?
> Élite 1.0 y Psion Chess (que también falla en versiones distintas de ST
> real). Para los programas que no funcionan, Russ está creando parches
Yo recuerdo que ciertos juegos y programas necesitan la versión 1.00 del
TOS. Yo tuve un 520St con el TOS 1.02, y para un juego (ahora no
recuerdo cuál), tenía que cargar el TOS 1.00 para poder ejecutarlo...
> expresos desde la última versión de Steem (opción nueva), pués se ha
> empeñado en que todo tiene que funcionar. De hecho cuando algunos usuarios
Ya lo he visto. Muy interesante la opción. De esta forma te aseguras que
funcionará el programa/juego.
> reportan errores, casi siempre es por usar el ile system de windows en vez
> de imágenes (algunos pogramas on sensibles a esto) o por no trabajar con
una
> configuración o versión de TOS apropiada. por el momento no se conocen ni
Quizás no les gusta acceder a ficheros cuyo nombre no es de DOS puro y
duro (8+3), o que quieren acceder a las FAT directamente, petando porque
en el Windows la FAT es de 32 bits y la del ST de 16, como para con
algunos programas como el Cheetah, un copiador de alta velocidad.
> diez juegos que falles (otra cosa es que el movimiento sea tan lineal como
> en un ST original, cosa que no siempre se consigue)
Aquí ya dependes de cómo tienes 'cargado' el windows, su versión, la
memoria disponible y el tipo de procesador y su velocidad. Todo éstos
parámetros son mucho menos críticos bajo DOS, pero lógicamente está cada
vez más abandonado...
> La expereincia me demuestra que acelerar un ordenador no es una gran
> solución, y trae problemas de incompatibilidad. La DMX workstation que
Puede ser una solución temporal hasta que salga una nueva máquina capaz
de un rendimiento mayor y un grado de incompatibilidad lo más bajo
posible, ya que al ser un nuevo diseño el hard es diferente...
> trabajaba con Atari, me dió problemas cuando ampliamos las CPU de los ST a
> 16Mghz (uno de los programas, un simulador de fairlight muy atractivo para
En muchas aceleradoras se tiene la opción de conectar un conmutador para
pasar de modo normal al acelerado y a la inversa, para poder mantener el
100% de compatibilidad, aunque sea sin acelerar...
> su época no funcionába) , para que veas... y después con el TT
> funcionaron... Cuando hablamos de bajo nivel, cualquier cambio puede ser
Porque todo el sistema estaba diseñado para tener un funcionamiento
óptimo y sin problemas con el nuevo procesador y su frecuencia de
trabajo, con lo cual los temporizadores se podían utilizar sin problemas
de culegues, retrasos, etc...
> crítico, por eso mismo a veces hay que afrontar la realidad y cambiar.
Otra
> cosas es hacer como el sistema de Amiga, que no es que cambie, es que es
> otra cosa con el nombre de Amiga puesto.
con el tiempo se sabrá cuál fué el mejor camino que se adoptó. Lo del
Amiga, aún no lo tengo claro, pero una de las posibilidades era hacer un
sistema completo bajo Java para que cualquier tipo de ordenador equipado
con una máquina virtual (VM) Java lo pudiera instalar. Por lo que sé (y
sufro) de Java, me parece la peor de las soluciones. Dejando de lado lo
farragoso de la programación en éste lenguaje, al ser tan inpedendiente
del hard de la máquina, el uso de éste lo tienes que confiar a las
librerías que disponga su VM. Ésto y otros factores lo hacen mucho más
lento que si el código estuviera compilado para el propio procesador, y
hasta la fecha el Java todavía no sirve para entornos de tiempo crítico.
> Si el precio es razonable y asequible, mi empresa estaría dispuesta ha
hacer
> pequeñas compras masivas, una vez probados claro. Pués trabajamos haciendo
> autómatas y controladores industriales, rehuyendo expresamente a windows ,
y
Hombre, antes de hacer una inversión de este calibre, primero se compra
una o dos unidades, se prueban bien, se mira qué funciona y qué no, qué
posibilidades tiene, su expansibilidad y facilidad de programación, y
una vez hecho todo esto, con los resultados en la mano se decide que
hacer. Yo compraré una placa y la montaré. La someteremos a varias
pruebas para ver su rendimiento y compatibilidad, compararemos la nueva
máquina con el Milan que tenemos en el club, y muy
probablementepublicaremos los resultados en un artículo. Ést es el plan
que tengo pensado.
> si es posible a los PC. Un ordenador de estas caracteíosticas, con un
> entorno eficaz , gráfico y rápido, que no corre peligro ante un corte de
> energía, y que arranca al instante..., y cuyo sistema operativo estuviera
Tu lo has dicho, que no corra peligro con un corte de luz. Yo tengo un
Linux instalado en un PC. Se me ocurrió comprobar si el demonio apmd, el
administrado de energía, si pulsaba el interruptor cerraba el sistema y
se apagaba. Cuando pulsé el botón, se apagó sin realizar ninguna otra
tarea. Cuando lo volví ha encender a ver qué hacía el Linux, detectó que
se apagó indebidamente, inició una exploración de disco, y cuando estaba
acabandola dió un error de inconsistencia del sistema, y sólo te daba
dos posibilidades, rebotar o arrancar en un modo especial. Lo he
conseguido arreglar, pero me dió un buen susto. Ésto sólo sucede con
sistemas 'dsico-dependientes'. El TOS, como esta en ROM, por mucho corte
del suministro eléctrico que se produzca no corre riesgo. En el peor de
los casos puede afectar a los datos del disco duro, pero si haces copias
de seguridad de manera regular, con reinstalar lo que necesitas ya es
suficiente, no tienes que volver a instalar todo el sistema operativo.
> parches, reinstalaciones, etc... Lo que yo necesito es un máquina que sólo
> necesite para funcionar un programa cargado, y que no necesite el contínuo
> mantenimiento que tanto Windows como Unix en todas sus variantes
necesitan.
O sea, un Atari con TOS, que aunque sea monotarea, para lo que se
necesita ya va perfectamente, no necesita mantenimiento, ni memoria
virtual, ni configurar 'demonios' ni demás, encender y ejecutar. El TOS
sería perfecto para un entorno industrial, requiere muy poco hard para
funcionar.
> de él hasta qeu tenga una avería de hardware. Con los PC, lo de menos son
> los fallos de hardware, no puedes confiar en el sistema para por ejemplo
> realizar una tarea en la que te juegues la vida. Un ejemplo: uno de mis
Los windows 9x y Me, por experiencia, son incapaces de funcionar 24
horas seguidas sin que dé un problema. cuando llevan mucho tiempo
funcionando, empiezan ellos solos a tener problemas, y si quieres que
recuperen la normalidad hay que reiniciarlos. Con los NT les pasa algo
parecido, pero con un margen de tiempo mucho más amplio.
> una pequeña producción de cine. Os imaginais que por alguna razón a
windows
> le de por testar algo del sistema, automejorarse o simplemente dormirse y
al
> detectar el paso de la persona, tarde más de lo debido y la detonación se
Lo que cuentas no es descabellado. En cualquier momento al windows le
puede dar por volcar datos al disco duro, passar a modo suspendido por
su propia cuenta, o lanzar un protector de pantalla que le provoque un
error grave y lo deje en un estado aún más inestable de lo habitual,
sino un cuelge) (he sido testigo de ésto con un ME)
> sabe... El resultado es que tienes que andar programando puñeteros
autómatas
> que si que trabajan a tiempo real, como los siemens, que cuestan como un
PC
> y son simples monoplacas sin pantalla gráfica, y con cpus de 8 bits y
Seguramente autómatas equipados con el Z80, un buen procesador de 8 bits
por cierto, pero si no tienen un entorno de programación es algo
incómodo de programar. En la Facultad, en la asignatura de robótica
teníamos un pequeño brazo robot de fabricación israelí para hacer las
prácticas de programación. Llevaba un 68.000 y su programación era
bastante sencilla, tenñias una lista de comandos que se introducían a
través de un PC al que se conectaaba por línea serie.
> Para mi lo fundamental sería que el ordenador trajera un buen entorno de
> desarrollo de aplicaciones. Hubo un tiempo en que esto es lo que
importaba,
Hummm... quizás sea nuestro pequeño punto flaco. De programación visual
no hay mucho donde elegir. Yo sinceramente prefiero programar al 'viejo
estilo', editor de textos integrado en un entorno de programación la
estilo del Lattice C o Turbo/Pure C. Por mis prácticas con programación
visual en Basic y Java, con éllos pierdo la 'perspectiva' de lo que
estoy haciendo, tengo la sensación que no controlo lo que programo, no
se, me encuentro muy incómodo. De la otra forma veo en todo momento el
código que introduzco, y sé muy bien lo que hay. Reconozco que paara
programar aplicaciones que usen el GEM pueda resultar difícil si no se
tiene un buen entorno que te ayude, pero una vez que empiezas a
comprender cómo funcionan por dentro, es bastante más sencillo de lo que
parece.
> la gente era usuaria de ordenadores y no de "programas" Recuerdo un
> compañero que se compró un SUN a principio de los 90, y en el hizo
> importantes programas de control de comunicaciones para la Expo92. El
Pues un SUN no es precisamente un sistema al alcance de cualquier
persona, son equipos profesionales de precio elevado. Yo te puedo decir
que la música de las olimpiadas de Barcelona'92 se hizo con Ataris, por
lo menos es lo que me han contado.
> procesador de textos y nada más. El entorno debería contar con algunas
> herramientas orientadas a clases u objetos, y ya está.
El Java es un lenguaje orientado a objetos. Yo estoy intentando (y digo
bien) realizar pequeños programas y applets con él, y pierdo más tiempo
peleándome con el propio lenguaje que con la programación en sí. Yo lo
veo demasiado complejo para meterse de lleno sin tener una idea clara, y
encima la documentación existente no ayuda mucho, incluso la que
proporciona la propia Sun. He leído comentarios que dicen que el Pascal
es muy dificil para un principiante. ¡Nada mñas lejos de la realidad!,
el Pascal al lado del Java es un juego de niños. Una vez que entiendes
su sisntaxis hacer cualquier programa es fácil. Niklaus diseñó el
lenguaje precisamente para la enseñanza de la programación, con éste
lenguaje aprender a tener una idea clara de cómo has de hacer la
aplicación, de definir las variables y estructuras que necesite, etc.
> De hecho, pregunto de paso ¿ es posible adquirir algún paquete de
desarrollo
> para esta máquina ahora mismo? Seria buena cosa poder empezar a
desarrollar
> antes de que la máquina esté en el mercado.
Que yo sepa no. En estos momentos los promotores del proyecto XTOS
quieren contactar con el mayor número de desarrolladores posible. Su
dirección es webmaster at xtos.de.
> Si te digo la verdad, para un Mac prefiero un PC, los he tenido y lo he
> ODIADO. Son el ejemplo más claro de lo lento que puede ser un gran hardwre
> gracias a su sitema operativo. El Logic corriendo en un Mac con 32 Megas
de
Lo se muy bien. Todo un MegaSTE, con su 68K a 16 MHz, y ejecutando el
Spectre, era mucho más rápido que un Lc con un 68020 a 20MHz.
Actualmente la situación tampoco ha cambiado mucho, es más, se te pueden
quedar colgados visitnado uan página web con el Internet Explorer...
> Parcen sencillas tus peticiones... que son también las mias, pero sin
> embargo los ST han sido los únicos ordenadores de la historia capaces de
> hacer esto (a partir de 16 bits).
Sencillo, es lo que estaba acostumbra con los Atari, y lo quiero
recuperar. Ésto no lo he visto en niguna otra plataforma, salvo quizás
el Amiga, el cual no conozco mucho pero por lo poco que sé era por un
estilo. Lo que no se es cómo acabará el nuevo planteamiento del Amiga...
> Saludos y perdón por el exceso.
Lo mismo digo. :-D
--
||| Saludos | Salutations | Greetings | Grüße
_/|\_ Luis Manuel Asensio Royo
"La violencia es el último recurso del incompetente". Isaac Asimov
--__--__--
_______________________________________________
Atari mailing list
Atari at argo.es
http://mailman.argo.es/listinfo/atari
End of Atari Digest
More information about the Atari
mailing list