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

[Luis Manuel Asensio Royo]

Atari Emulación España (Gabriel Huertas) wrote:

> 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

Son las mismas en todos los compiladores de C. Simplemente te
encontrarás las mismas funciones del sistema operativo que encontrarás
en el manual The Atari Compendium.

> 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

Lo de manejar menús y demás mira bien mis programas. Si te fijas bien,
todos siguen los mismos pasos.

> 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

El problema del Basic original es que es muy fácil hacer un 'spaghetti'
de código, con saltos hacia adelanta y hacia atrás, y definir una
variable en cualquier lugar, a diferencia del Pascal y el Modula-2, que
te obliga a definir lo que necesitas desde el principio...

> tengo la documentación , lo que no tengo es documentación de ninguno para el
> Atari.

Con el The Atari Compendium tienes de sobra. Si no recuerdo mal viene
con bastantes ejemplos y, junto con los programas que he liberado con el
código fuente, verás que la mecánica es practicamente la misma...

> 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

Lo que pasa es que en el Gfa, lo que se hace con una instrucción, en
realidad la implementa con bastante más código, ya que hace de manera
oculta al programador los pasos que tendrías que hacer con otros
lenguajes. Y en cuanto al tamaño, si usamos las funciones de
entrada/salida, conversión, etc, genéricas del C como el printf o el
scanf, lógicamente el código crece bastante más. Una cosa que aprendí
con el Modula-2 es la de importar las funciones que hacen exactamente lo
que necesito, ni más ni menos, y entonces tienes un código más pequeño.

> 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

Cuando entiendas el funcionamiento interno de las llamadas de la barra
de menús, crear/abrir/cerrar ventanas y manejo de cajas de diálogos,
igual te haces una serie de funciones para acelerar el trabajo de
programación.

> 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

Es que es muy alemán, y claro, ellos implementaron lo que creyeron
oportuno. De hecho, con el Basic hay una gran multitud de 'sabores'
(como gusta decir ahora)

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

Pues me parece lamentable, ya que el visual Basic te genera un código
pequeño, pero cuando lo quieres 'empaquetar' para usar en otras
máquinas, te mete tal cantidad de librerías dinámicas que el resulta
acaba engordando varios megas, y total para una consa relativamente
sencilla. Yo he encontrado un compilador gratuíto de c para PeCes que es
capaz de generar código dde 16 y 32 bits, e incluso ficheros .DLL para
NT, y con él tengo más que de sobra y no necesito el monstruo del Visual
C++ para nada.

> 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

Lo realmente importante es saber programar código limpio y eficiente, y
es algo que no es nada fácil. El tema de manejo de gráficos es
simplemente tener la lista de las diferentes funciones, una breve
explicación de los parámentros y su función, y un pequeño ejemplo.

> 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

Con el Atari no pasa lo mismo. Las funciones de gráficos son comunes a
todos los compiladores. Tienes desde la funciones que usan la excepción
del código de operación Line-F (0xf000) del 68K, que aunque sean muy
rápidas se recomienda no usar ya que no se soportarán en procesadores
futuros, hasta las funciones de gráficos del VDI. En cuando a sonido
tienes las funciones estándar de las XBIOS, y en cuanto al MIDI, lo
puedes manejar tanto desde la BIOS como desde las XBIOS o el GEMDOS.
Como ves, es otro mundo...

> 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

Con Atari si tienes un control de lo que haces. Para el caso de las
ventanas, primero has de averiguar las dimensiones del Desktop 0, luego
has de iniciar la creación de la misma pasando los parámetros obtenidos,
más una serie de flags en los que indicas qué elementos de ventana
quieres que tenga, sus dimensiones, etc, y te devolverá un entero que es
el manejador de ésa ventana y ya tan solo te queda abrirla. Lo realmente
complicado es indicar el rectángulo de recorte, la inicialización del
contenido de la ventana, el manejo de los desplazadores, etc, pero todo
éso se hace con un gestor de eventos. Con el Gfa, todo ésto resulta más
sencillo porque él tiene implementadas una serie de librerías que
facilitan la labor, pero en C no.

> 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

La configuración del compilador no es dificil. Una vez que lo has
logrado no lo tocas en mucho tiempo, y con cualquier compilador de C de
cualquier plataforma puedes programar en ANSI C perfectamente, ya que
todos tienen una serie de librerías comunes.

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

La documentación del The Atari Compendium te ayudará en ello. No es sólo
una lista de los diferentes servicios de todas las capas del sistema
operativo, también habla del hard, de las recomendaciones de
programación, etc. Con él no necesitas mucho más.

> 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

La verdad, nunca se me hubiera ocurrido 'diseccionar' un programa
observando el diseño de sus diferentes menús y cajas de diálogo, pero si
fuera así, con usar el programar y 'navegar' por sus diferentes cajas de
diálogo haces exactamente lo mismo. Supongo que si estás acostumbrado al
Visual Basic, asocias el diseño de las cajas a la implementación
inmediata del código que la maneja, pero en Atari los editores de RSC
sólo te permiten el diseño de los menús, cajas, etc, no implementas
ningún código, éso lo haces más tarde desde el editor de textos e
importando las etiquetas de los elementos de cada menú y caja que el
editor de RSC ha grabado cuando salvas el fichero RSC.

> 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

Pues has de acostumbrarte a que ésto no existe, o por lo menos no lo he
visto. Cierto que para un principiante dificulta bastante el programar
una aplicación GEM, pero para alguien como yo que esta acostumbrado a
picar todo el código del programa desde el principio hasta el fin, los
entornos visuales me despintan más que ayudar. Tradicional que soy...
:-)

> 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

También está el AGNUS, más económico que el ACS Pro. No he probado
ninguno de los dos, por lo que no se qué tal van para diseñar
aplicaciones...

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

¡Pero qué dices! X-D, con lo guapo que es programar en ensamblador. Yo
hice mis pinitos con el Z-80, luego programé bastante con el 68K, que
por cierto tiene el ensamblador más fácilde programar junto con los
PDP-11 y los VAX-11. El 8086 es realmente muy asqueroso de programar
cuando te acostumbras a los buenos...
}X'-DD

a la hora de la verdad, si sabes programar el procesador es lo de menos.
Lo único que necesitas es el manual con la descripción de todas las
instrucciones y ya está.

> 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

Repito, del compilador no necesitas practicamente nada. Todos los
compiladores de C de Atari tienen las mismas librerías de las funciones
del sistema operativo del Atari. Lo que hagas con uno lo puedes compilar
con otro. Sólo tendrás problemas si usas las funciones específicas de
cada compilador. Del ADK2 tengo dos verisiones, una para Turbo/Pure C y
otra para Lattice C, y solo se diferencian en detalles que no tienen
nada que ver con las funciones del TOS.

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

Todo ello lo encontrarás en el The Atari Compendium. Para los Atarianos
es como la Biblia, allí está practicamente todo lo que se necesita para
conocer las diferentes versiones de hard, todas las funciones del TOS
hasta la versión 5 más las del MiNT/MultiTOS, etc.

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

El puerto del cartucho no es más que un puerto de sólo lectura de como
máximo 128Kwords. En la documentación que te digo también se especifica
en qué espacio de direcciones del 68K se localiza y cómo se detecta la
presencia de un cartucho en función de un número 'mágico'.

> 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

La verdad es que no se cuánto cuesta, pero hal fabricarla una pequeña
empresa seguro que ha de ser algo más cara que una estándar de PC que
fabrique alguna empresa de Taiwan o similar. También has de tener en
cuenta la calidad de factura de la tarjeta. Las tarjetas 'profesionales'
de sonido con varios DSPs cuantan tanto como un PC entero, o sea, que yo
no sé dónde se pueden encontrar tarjetas que lleven al menos un DSP a
preció asequible y de buena calidad. De Creative lo dudo, porque sus
tarjetas de 'sonido' se las conoce com las 'Chungoblaster'...

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

Entonces lo que leí hace tiempo era erróneo. bueno, si lo creó desde el
principio entonces sabe muy bien qué es lo que hay, tiene como dices
control completo del programa. Lo del sonido lo he de probar en la
versión 2.06, porque cuando probé la versión 1.2 era de menor calidad
que el WinSTon...

> Ni creo que sirva nunca. Borlan (inprise) y Microsoft están abandonando el
> lenguaje en sus paquetes de desarrollo.

Al final SUN se quedará sola con su 'criatura'. Yo, cada vez que me meto
en ello más odio éste lenguaje, te lo juro...

> satisfactoriamente, seguimos usándolo mientras sirva para su tarea. La
> mayoría de nuestros PC corren W95 OSR2 , Windows 98 SEy DR.DOS . Windows

Sin duda de todos los windowzes el mejor es el primero. Es más pequeño,
más rápido y más estable.

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

Y con hardware. En mi trabajo tuvimos que pedir una tarjeta PCI Ethernet
porque el muy asqueroso se negaba a reconocer una NE2000 ISA, mientras
que el 2000 no dió ningún problema con ella.

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

Es que antes se hacían las cosas de otra manera. Ahora si te fijas un
poco, todo está fabricado para que funcione un tiempo determinado, y
luego pete. Me paso con las fuentes del 520ST y del 520STE. ambas
petaron al cabo de algo más de 6 meses, junto el periodo de garantía...

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

Pues espera, que para los PeCes ya han aparecido sistema de
refrigeración por agua...

> 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

Yo recuerdo uno, el 4004, proceaador de 4 bits de Intel creo...

> 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

Pues a mi la programación 'visual' me 'descontrola'. No me siento cómodo
con ello...

> 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

Esto con el editor de RSC vas que chutas, y no tocas nada de código a no
ser que hayas cambiado el orden de los elementos o quitado/agregado
alguno. Pero para diseñan primero has de tener muy claro qué quieres que
haga el programa, sino se te puede pasar el tiempo modificando hasta que
lo tienes como quieres. Es como todo en programación.

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

Hombre, tampoco cueta tanto poner el valor numérico del color en formato
RGB. :-D

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

Lo que me suponía, y encima tener que aguantar la habitual y muy molesta
paranoia yanki... :-(

> 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

Lo de la documentación si que había oído algo, de que falta buena
documentación. Con los Atair pasa lo contrario, todo esta documentado, y
lo que se dice es cierto en su practica totalidad. Por eso recomiendo
repetidamente el libro The Atari Compendium, porque es nuestra 'biblia'
particular. Parafraseando al Mulder, 'la verdad está ahí dentro' X-DD

> 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

Supongo que por el sistam de ficheros del Amiga, que me dijeron que
usaba funciones hash para colocar los datos, pero todo se enlaza en
forma de lista, por lo que para leer el contenido del disco se tenía que
leer la lista completa, a diferencia del Atari que implementaro el
sistema FAT, que con leer el contenido del directorio raiz y de los
subdirectorios es más rápido.

> gráficos espectaculares, pero los entrelazados eran sencillamente un "mata
> ojos". Los modos de colores extendidos tampoco eran tan espectaculares, para

Lo recuerdo muy bien.

> 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

En Atari se cambiaba de paleta con cada interrupción horizontal.

> 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 el Falcon son 64K colores reales completamente, no hay truco alguno.

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

Es que con el GEM, todo lo que una aplicación necesita para funcionar se
lo da el sistema operativo, no se requieren librerías de carga dinñamica
ni demás tonterías, como para con el Windows, pasa también con el Linux,
y creo que también pasa con los Macs...

> 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

En el Atari el sistema operativo se divide en capas. La primera es la
BIOS, le sigue la XBIOS, luego el GEMDOS, el GEM se divide en tres más,
el VDI encargado del manejo de gráficos y de dispositivos de entrada y
salida, el AES que es quien da el soporte para el manejo de menús,
ventanas, cajas de diálogo y comunicación entre procesos, y el GDOS.
Claro está también existen las rutinas de atencióin de interupción de
excepciones e interrupciones, las rutinas de manejo de periféricos, etc.
Hasta el TOS 1.4 todo eso cabe en una ROM de 192KBytes, hoy en día, ¿qué
sistema puede ofrecer tanto con tan poco?, NINGUNO, bueno, quizás el
PalmOS

> 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

Para ello hace falta instalar el TOS 2, que ya puede manejar ST-RAM y
TT-RAM, sino como máximo 4 megas.

> multitarea, muy estable alucinante para la época (aunque sin protección de
> memoria, lo que daba en muchas ocasiones sus famosos "errores gurú
> meditation").

Éste problema también lo tiene el MagiC, y de vez en cuando te sale con
un rotundo 'system haltented' o algo así... El MiNt y sus derivados es
activable la protección de memoria, por ello es bastante más estable que
el MagiC.
-- 
 |||   Saludos | Salutations | Greetings | Grüße
_/|\_  Luis Manuel Asensio Royo

"La violencia es el último recurso del incompetente". Isaac Asimov