[ATARI] Re: Atari digest, Vol 1 #181 - 5 msgs

Atari Emulación España (Gabriel Huertas) gabrielhuertas at terra.es
Tue Nov 27 08:47:47 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 tuviera 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 usarás 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 lo 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
funcione por ejemplo el CAF. Asemás hay tarjets con 4 dsps PCI bastante más
baratas (no tarjetas de sonido, sino tarjetas con DSP, de hecho se está
creando un protocolo para utilizar DSPS reales en caso de que existan en vez
de simularlos). Me refiero a que la Deesse o baja mucho o mejor va a ser
crearle drivers a las DSP que ya existen para slot PCI

>No se si considerarlas emulaciones. Todas las versiones de windows,
>exceptuando el NT y sus 'derivados', se ejecutan sobre DOS, es decir,

Esto es cierto, pero las sesiones de DOS una vez que has entrado en Windows
no son lo Mismo que el dos que arranca inicialmente, este es Dos auténtico,
de hecho Microsoft lo llama MsDos 7.xx y puede manejar los programas de dos
reales sin problemas, pero cuando abres una ventana de Dos, ya si estás
emulando, por ejemplo, en vez de llamar al hardware directamente estás
pasando por Windows, y ya no hay acceso a tiempo real.

>que en realidad el windows es sólo un entorno gráfico que usa el DOS. En
No exactamente, de ahí derivan precisamente muchos problemas de sincro.



>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?

Si le dices eso te mata!!! Está harto de explicar que todo el código es
suyo. No se ha basado en nada, lo ha reescrito desde el principio pare tener
pleno control del sistema.



>hasta la fecha el Java todavía no sirve para entornos de tiempo crítico.
Ni creo que sirva nunca. Borlan (inprise) y Microsoft están abandonando el
lenguaje en sus paquetes de desarrollo.

>probablementepublicaremos los resultados en un artículo. Ést es el plan
>que tengo pensado.
Me parece muy bién , así los que no se atrevan a comprarlo desde el
principio, siempre podrán tener una opinión antes de hacer la inversión. La
verdad, es que hoy por hoy, no es tan difícil diseñar un ordenador, y con
las ayudas que se tienen de siftware y demás, menos. En principio debería de
funcionar correctamente. Todavía recuerdo los tiempos lejanos en los que en
la Revista Resistor te enseñaban a fabricar un ordenador íntegramente. Había
varios artículos que te permitían desarrollar tu propia máquina de 8 bits. Y
con posterioridad apareció en varias revistas el montaje íntegro de un
ordenador PC, desde la placa base hasta la VGA. Hoy en dia sin duda no vale
la pena el trabajo de fabricarnos nuestras propias placas y tal, pero pensar
que no es tan imposible ayuda a desmitificar un poco el asunto.


>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.
Ni más ni menos :-)

>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

Hombre, en mie empresa la verdad es que funcionan algo mejor. No dan fallos
a veces hasta 4 dias encendidos sin interrupción. Pero si se hacen cada vez
mas lentos, llega un momento en que abrir un directorio puede durar hasta 10
segundos. También influye en la estabilidad, que no tenemos la obsesión por
actualizar el software, cuando encontramos algo que funciona
satisfactoriamente, seguimos usándolo mientras sirva para su tarea. La
mayoría de nuestros PC corren W95 OSR2 , Windows 98 SEy DR.DOS . Windows
Millenium nos bastó verlo el único dia que lo instalamos para borrarlo y no
pensar más en él. Y windows XP, muchos clientes nos indican que da problemas
con muchísimo software.
Pero de todad ormas, un ejemplo atariano ¿Se acuerda alguien de la BBS
Microduende? Se tiró dos años seguidos funcionando con un SH20 que tengo yo
en mi "museo" todavía funcionando, y estaba hecha con un 520ST de los
primeros que tenían la disquetera y fuente de alimentación fuera. El
software era el mítico michtron multiuser BBS y funcionó durante 2 años
seguidos sin error y sin parar (siempre enchufada). A los dos años se fundió
un condensador de la fuente que costó 30 pesetas recambiar y a rular de
nuevo. No creo que ningún PC sea capaz de durar dis años funcionando por las
buenas, por simples cuestiones de mecánica, sería impoble, pues antes se
gripará el ventilador de la CPU y eres capaz de tener hasta un incendio...
(desde el punto de vista electrónico, siempre me ha parecido cutrrísimo que
un integrado necesite ventilación forzada, como si se tratara de un motro de
combustión).


>Seguramente autómatas equipados con el Z80, un buen procesador de 8 bits

Los siemens llevan 8085, también hemos usado Altair y similares , o incluso
autómatas hechos por nosotros con microcontroladores PIC e interfaces de la
casa. Estos se programan con extensiones para Visual Basic que te da el
fabricante o cuando tienes suerte directamente en C, te facilitan un
compilador y un programa para pasar el binario a la memoria. También se han
usado procesadore de 4 bits que no recuerdo, pero de diseño moderno a pesar
de ser de 4 bits. Ya ne se usan porque los microcontroladores cada vez dan
más por menos.



>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

Sin duda esto te da mas control, pero si vamos al caso, se debe de tener la
posibilidad de crear programs con rapidez, de forma que no te de pereza y
tiendas a acordarte de "lo facil que era programar en el otro". A veces ni
siquiera es que sea más fácil, sino menos complejo. Hay cuestiones por
ejmplo, la de la estética en el programa, reconocerás que es un poco rollo
tener que aandar escribiéndo código para cambiar colores o dibujar
ornamentos en los formularios, estos aspectos no afectan la funcionalidad
del programa y te pueden ahorrar dias de trabajo en un proyecto de
envergadura si los haces en un entrono visual. En la empresa que trabajaba
antes , teníamos un programa en el laboratorio que sirve para leer los
códigos de colores de componentes electrónicos de dificil acceso visual.
Funciona con un pequeño colorímetro.El simple hecho de poder seleccionar los
colores  de los rangos a utilizar en el programa cliqueando en la paleta (lo
hice yo), me ahorró ya bastantes quebraderos de cabeza y bastante dinero en
sueldo a la empresa.


>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.

Aquel costó más de un millón y tenias que firmar un contrato por el que
contraías serias responsabilidades si cruzabas el telón de acero con la
máquina...
Pero el contrato valía la pena, se trataba de desarrollar un sistema que
corrigiera el atasco de los servidores de la Expo, que se atascaban tanto
que eran capaces de hacer reservas de clientes que llegaban a procesarse
hasta dos dias después de pasado el día en que se quería la rserva (era
rápido el sistema IBM :-) )  . El contrato se encargó a un viejo amigo que
trabajó com ingenieo de software para Atari en la época "dorada". Y lo
compró porque el mega ST "se le quedaba pequeño" (ya el sólo hecho de que se
pudiera utilizar , aunque se "quedase pequeño creo que era todo un honor
para Atari" teniendo en cuenta la envergadura del trabajo, lo que desde
luego no era una opción eran los 286 de la época)

Tenía si no recuerdo mal 16 megas de memoria pero era capaz de tener abierto
cerca de 90 aplicaciones corriendo a la vez.

> procesador de textos y nada más. El entorno debería contar con algunas
> herramientas orientadas a clases u objetos, y ya está.



>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...

pues si que no lo conoces, yo tengo todso los modelos desde el 500 al 4000,
pasando por engendros como la CDTV. El amiga es si te digo es peor para un
desarrollador que un PC de la época. Muy virgero de cara a la galería, pero
muy poco documentado. Ha cosas que el sitema operativo debería hacer según
el manual, pero no hacía, y por otro lado era lentísimo. Espectacular en las
demos que aprovechaban lo que si que podía hacer bien los chips custom
especialmete desarrollados para la máquina, pero daban una falsa impresión
de rapidez. El ordenador no era rápido, sólo era capaz de producir buenos
efectos visuales, si te ciñes a lo que los custom chips podían hacer,
asombrarás al personal, si te pones a programr en c aplicaciones como bases
de datos, etc, el mundo se te cae encima. La lectura de los directorios es
lentísima, el acceso a los discos igual. Luego presumían mucho de modos
gráficos espectaculares, pero los entrelazados eran sencillamente un "mata
ojos". Los modos de colores extendidos tampoco eran tan espectaculares, para
obtenerlos se usaban trucos que también son posible en el Atari, sólo que en
el amiga si hicieron estándard, el propio amiga 4000 manejaba menos colores
que un falcon . (el 4000 podría utilizar 16.800.000 colores pero en Ham8,
los miles de colores que te daba el falcon eran reales, y el amiga se
quedaba en 256).

En cualquier caso voy a lo que interesa, yo tuve el pagestream en los dos, y
en Amiga era muy lento comparado con un 1040 ST. Tuve el Superbase 4 en
amiga (el que quisiera tener en el Atari) y era muchísimo más lento que en
el 1040, aunque usara en el amiga el disco duro SCSI (un a2000 ) y en el
Atari un disquete. Y lo más fuerte, el Superbase Gem, que hoy es freeware,
cualquiera puede probarlo y ver que en un 286 es mucho más rápido que en un
Amiga 2000, y que es comparable a la velocidad que alcanza en un 8088 con
GEM corriendo el Superbase Gem (el que no se lo crea que lo pruebe).

Por último el Amiga no tiene el entorno gráfico tan integrado como el Gem,
arrancar el workbench de disco lleva su tiempo, y apenas deja espacio para
meter nada más en el disco (a menos que dejes lo imprescindible y elimines
cosas). Necesiaba además reinsertar el disco de sistema para hacer
operaciones como copiar ficheros de un disco a otro o ejecutar otros
comandos, por lo que tener una sola disquetera se convertía en el mismo
infierno que en un PC,  su sistema operativo es una especie de cpm +
entrono gráfico aparte, y en Rom está el kernel, pero ni el intérprete de
comandos (cli o shell, equivalente al MSDOS del PC) ni el Workbench
(programa equivalente a Windows, que corre sobre el AmigaDOS). Tambien tenía
limitaciones en cuanto a memoria baja y alta, usando paginación y la memoria
baja, llamada "chip" era de 1 mega y hasta 2 si no recuerdo mal en el 2000,
en el 4000 aumentó creo que a cuatro o 8, pero el TOS sabemos que puede
manejar como memoria ST 14 o 16 megas desde el principio (incluso había kits
para instalar estas ampliaciones en un ST, eso si, necesitaban un mmu).Una
cosa si, lo que realmente era virguero y me impresionó siempre era su
multitarea, muy estable alucinante para la época (aunque sin protección de
memoria, lo que daba en muchas ocasiones sus famosos "errores gurú
meditation").

Y que conste que siempre me gustaron y que todabia los conservo.

>> Saludos y perdón por el exceso.

>Lo mismo digo. :-D
>
y lo vuelvo a decir...

Saludos






More information about the Atari mailing list