[ATARI] Re: Atari digest, Vol 1 #186 - 2 msgs

[Atari Emulación España (Gabriel Huertas)]

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


La verdad es que nunca he leido una manual de ANSI Basic, pero me da la
impresión de que el Ansi Basic an la práctica no existe, pues tengo
entendido que en Ansi, el Basic no permitiría la llamada de funciones,
procedimientos o rutinas, que los bucles no tendrían las posibilidades que
veo en el GFA,  que el lenguaje es interpretado y no compilado (esto creo
que no es cierto ni en el Visual Basic, o si VB no compila, VC tampoco,
porque funcionan de forma similar en el sentido que ninguno de los dos puede
generar programas que funcionen por sí solos, los dos necesitan un paquete
de librerías y rollos que se necesitan utilizar sobre la marcha durante la
ejecución). Recuerdo varias versiones de Basic que cuando creaban un
ejecutable lo que hacían era incluir el código y un runtime juntos. Con un
poco de habilidad se podía incluso recuperar el código fuente íntegro. Sin
embargo GFA si que compila (si tienes el compilador que no venía con el
intérprete).



>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

La verdad es qeu no he visto ejemplos, lo hab´re mirado demasiado
superficialmente, será cuestión de cogerlo seriamente.

>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

Pues claro, igual que todo Basic, pero a diferencia de muchos Basic
modernos, el GFA está hecho en máquina directamente y no en C (como sucede
con Dark Basic o incluso el propio Visual Basic), o al menos eso dice su
creador, por lo que se aprovecha mucho más el sistema. A STOS le pasa tres
cuartos de lo mismo.




>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

No si en realidad el VB no se utiliza para crear el programa del
microcontrolador, sino para generar el Binario que habrá que grabar en el
micro. Creo que no me he explicado bién , lo que quiero decir es que en
realidad el VB no compila nada para el microcontrolador (pues éste tendría
que ser ni más ni menos que compatible con un PC y llevar windows, más bién
sería un "macrocontrolador" :-)) ) . El VB es digamos "el interface" para
programar el micro. Y a lo que me refería es que me parece cutre que en
muchos casos se tenga que hacer así, parece que vamos "para atrás" en vez de
para adelante, pués antes con el C lo hacías todo y ahora por narices hay
que aprender algo de Basic.

>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

¿Y por qué no dices cuál es :-) ? (y dónde se consigue) Espero que no te
refieras al Bloodshell, pues éste no me ha gustado nada, el binario que
produce es muy grande, parece más lento que el Borland, e incluso en modo de
cónsola necesitas  dll a parte del binario que creas. Además el Borland
también es freeware (v. 5.5)




>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

Parece ser que si que existe, la última versión de Face Valúe y para C
EazyGem, que por desgracia trae toda la documentación en francés, pero habrá
que echarle un vistazo, pues según su creador ofrece todo lo que el paquete
Visual de microsoft (generador de aplicaciones, cajas de texto, botones,
barras desplazadoras,  etc. con inserción de código directo asociado al
objeto). Trabaja con Pure C y otros.


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

Si pero hay veces (muchas veces...) en las que sólo programas un micro "una
vez" , y a veces el simple hecho de tener que andar aprendiendo nada mas que
el nombre del micro es ya contraproducente (desde el punto de vista
económico). Muchos fabricantes te dan paquetes de desarrollo que entienden
el AnsiC, y metiéndoles el fuente te generan el binario para cargar en el
micro, con lo que ni siquiera te tienes que preocupar de para que micro
estás trabajando, sólo tienes que tener unas ideas muy generales y a nivel
cualitativo, por lo que "te separas del hardwae" , que es para lo que se
inventó el C después de todo. Es precisamente por esto que los
microcontroladores están desplazando a muchos autómatas clásicos como lo
Altair, porque los fabricantes ofrecen paquetes de desarrollo en AnsiC u
otros lenguajes sencillos. Hasta no hace mucho, los únicos que hacían ésto
eran los fabricantes de autómatas programables de toda la vida, que dicho
sea de paso te cobraban de sobra por el servicio.

>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.
Que son las que tienes que manejar si le quiers sacar partido al mismo , en
PC al menos, si no usas recursos específicos de Borland, en la mayoría de
los casos no portables, hay infinidad de cosas qeu no puedes hacer , o que
son muy tediosas (por ejemplo todo lo que tenga que ver con gráficos, sonido
o MIDI).


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

Te habrás confundido con STEM, que es otro emulador de ST, pero no para
Windows. Ëse si se basa en Winston.
En cuanto al sonido, te tengo que decir que winston con las tarjetas de
sonido ISIS, Gina, y Layla, sencillamente no funciona, sólo peoduce ruidos
ininteligibles, y Steem 1.2 iba "relativamente bien", aunque Paciist sonaba
mucho mejor debido al pedazo de emulador de chip que lleva integrado, el
leonardo como ya sabes. De todas formas el sonido se ha corregido bastante,
e incluso se han tenido en cuenta trjtas particulares que daban problemas
con el , como las Maxi Sound y otros bodrios similares.



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

Se que las fuentes parece que dan problemas a muchos usuarios, pero a mi no
me los han dado, tengo más de una decena de STs funcionando perfectamente
todavía. En cualquier caso, parece que un problema está en la universalidad
de las fuentes atarianas, que son las mismas para cualquier lugar del munco,
y esto produce (en otros aparatos tambien pasa, véanse los samplers Mirage y
los teclados antiguos de Ensoniq como el SQ80) que según el sitio sean más
propensas a fallar , sobre todo por excesos de calentamiento queterminan con
los condensadores. No obstante, como ya dije , la de microduende se llevó
funcionando 2 años sin parar.


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

¡Será broma!!! ¿lo dices en serio? ¿que será lo proximo? ¿Compresores de
nitrógeno líquido?


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

Y con el Amiga

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

pués me vuelve a sorprender, la falta de protección hoy en dia creo que es
sencillamente inadmisible. Y si hasta l FreeMint la incorpora, ¿para qué
sirve le MagiC? Supongo que sólo para emular STs en PC y Mac, y con más
problemas que otros emuladores. Para un ST me estoy convenciendo que es
mejor el Mint, que además tien más posibilidades en redes ¿no es así?



>tarjeta y los controladores sólo cuesta uno 168,22 euros (IVA incluído),
>que como se ve, no es tan cara como se suponía... :-)


--La verdad es que la cria mucho más cara, pero aún así, mira estos precios
(y hablo de tarjetas de gama pofesional, baja pero profesional):

DARLA24 (89.900 pts) 8 salidas de 24 bits analógicas y SPdif. El conexionado
se realiza en un rack externo, para mejorar la relación señal ruido. En el
rack estan los convertidores AD. La salida se conecta a una controladora en
tarjta que va en el PC.

Sekd : desde 70.000 pts con 8 entradas y 8 salidas analógicas, entradas y
salidas digitales y 2 interfaces MIDI, DSP hardware. Señal ruido sobre 98 dB
(medido por nosostros en el laboratorio).

MIA: 2 entradas y nos salidas analógicas balanceadas, interface SPDIF
entrada y salida (57.500)

por eso digo que quizás no sería mala idea tratar de hacer drivers para las
tarjetas, más que diseñar otras que aunque sean más baratas, no lo son en
modo alguno si se consideran las prestaciones omitidas.


Hasta otra.