Radastan ZX Editor

[radastan]

En base a las tropocientas herramientas que estoy usando, que quiero continuar mi curso sencillo de programación en ensamblador, y que muchos buscan algo simple que les facilite la vida para programar en este lenguaje... nace, fruto de una tarde loca...

Radastan ZX Editor



La primera "beta" la podéis descargar aquí:

http://www.bytemaniacos.com/ficheros/zx_editor/zxeditor_beta.zip

No hay documentación, ni ayuda, ni nada, pero os puede ir haciendo una idea de lo que pretende ser:

- Editor visual para Pasmo
- Programación separada de código principal, subrutinas, y sprites
- Generación y ejecución automática de TAP

Requiere pasmo/bin2tap, que podéis conseguir con el kit de mi curso:

http://www.bytemaniacos.com/ficheros/curso_asm/kit_ensamblador.zip

En esta beta no podemos definir el nombre del fichero a generar, se llamará programa.tap.

La idea es que puedes importar un fichero ASM con subrutinas de terceros, que saldrá en su ventanita, e igualmente con sprites de código ASM (como los que genera SevenuP). En ambos casos cuando importas un fichero se anexa a lo que tuvieras (para unir subrutinas y sprites en ficheros separados).

Cuando ensamblas todo a nivel interno se une y así podemos trabajar con mayor comodidad.

Estoy trabajando en la importación de ficheros SevenuP de forma nativa, ya que los ficheros ASM de esa aplicación salen por defecto en RTF y hay que abrirlos y volverlos a grabar con Notepad para que queden legibles.

Y por último, no pretendo inventar la pólvora, no voy a incluir colores por contexto ni nada por el estilo, pero si un par de cosillas que se que facilitan mucho la vida (por lo menos a mi). Cuando tenga una versión definitiva publicaré el código fuente como freeware (es C#, exportable a Linux si no me equivoco).

Probarlo y me contáis.

[Metalbrain]

Estoy trabajando en la importación de ficheros SevenuP de forma nativa, ya que los ficheros ASM de esa aplicación salen por defecto en RTF y hay que abrirlos y volverlos a grabar con Notepad para que queden legibles.

No, salen en TXT plano normal y corriente... el único problema que pueden tener es que solo usa el código 0A para el salto de línea, en lugar de 0D0A más propio de Windows, pero cualquier editor decente (*) es capaz de interpretarlos bien. Creo que es la primera queja que he tenido al respecto, y mira que empecé hace años con el SevenuP.

* En la práctica esto significa: cualquiera que no sea el Notepad de Windows.

[radastan]

* En la práctica esto significa: cualquiera que no sea el Notepad de Windows.

Pues no, desde C# tengo el mismo problema que con Notepad. De todas formas ya me has pasado la estrutura de los ficheros nativos de SevenuP, así que no habrá problema en ese sentido.

Otra cosilla que añadiré en la próxima versión es la importación de ficheros BMP directamente a código ASM, desde C# parece sencilla una conversión básica. Con eso ya podré liarme a lo que realmente quiero poner, que es un resumen de subrutinas y sprites disponibles para la pantalla de código principal.

El último paso será un optimizador de código, que no incluya las subrutinas que no se usen en el código que se pasa a Pasmo, con eso ya tenemos una herramienta sencilla y cómoda para programar.

[JBGV]

Pues también es buena noticia que quieras seguir con el curso

[Z80user]

Aun me falta probarlo (cosas del pasmo, no del editor/DE)
me gusta mas el otro ensamblador de ASM (sjasm algo mas impronunciable)
aun me resisto a ver el simbolo del $ no se porque y el registro A aun siendo algo implicito
ADD A en lugar de ADD A,A, pero bueno, son manias mias, nada que un reemplaze aregle.

Optimizar codigo asm... mientras no se hagan cosas raras con el codigo, puede ser una opcion
la mas tonta cambiar LD A,#00 por XOR A,A puede no sentar bien, ya que cambia los flash.
Cambiar JR por JP si puede ser algo mas practico, a no ser que se hanyan equilibrado a mano las 2 vertientes del salto.
Optimizar el codigo generado desde mas alto nivel (C o basic) que suele generar una estructura mas o menos identica, si es mas facil de buscar algo que optimizar.

Creo que lo de optimizar codigo, puede ser mas doloroso para la cabeza que implementar otro tipo de cosas, De momento estoy utilizando el notepad++, pero como es monosesion (no se puede arrancar 2 veces) tengo que utilizar el block de notas de windows, no es el mejor editor de textos, pero suele venir de serie y salvo el problema que comentais (para eso uso el wordpad de intermediario) y que segun en que version de windows, no permite abrir archivos demasiado grandes.

De todas formas enorabuena por sacar un editor de textos mas, y de los pocos que hay para programar sin dar muchas vueltas para Spectrum

[radastan]

Aun me falta probarlo (cosas del pasmo, no del editor/DE)
me gusta mas el otro ensamblador de ASM (sjasm algo mas impronunciable)

Pues tomo nota, lo mismo le doy soporte y así matamos dos pájaros de un tiro.

Optimizar codigo asm... mientras no se hagan cosas raras con el codigo, puede ser una opcion

Es que no voy a tocar el código. La idea es que se trabaje con tres secciones:

- Código base
- Subrutinas genéricas
- Sprites

El código base es el juego en si, o la aplicación, código único para lo que estás haciendo.

Las subrutinas son como una especie de librería, que puedes usar entre programas/juegos. Puede haber subrutinas de todo tipo, y lo mismo tienes 12 y sólo usas 3.

A eso me refiero con optimizar, que en el ensamblado no se incluiría las subrutinas que no se usen, de igual forma que no se incluirán los sprites que no se usen. Esto facilita mucho la vida, ya que no te tienes que pelear con librerías y sabes que aunque uses una librería monstruosa sólo vas a usar lo justo y necesario.

De momento estoy utilizando el notepad++, pero como es monosesion (no se puede arrancar 2 veces) tengo que utilizar el block de notas de windows, no es el mejor editor de textos, pero suele venir de serie y salvo el problema que comentais (para eso uso el wordpad de intermediario) y que segun en que version de windows, no permite abrir archivos demasiado grandes.

Tomo nota para esto también, la posibilidad de poder trabajar con una pestaña auxiliar para poder abrir código de otro proyecto y fijarte. No es ninguna tontería.

De todas formas enorabuena por sacar un editor de textos mas, y de los pocos que hay para programar sin dar muchas vueltas para Spectrum

[/quote]

Es que de BASIC tenemos BASIN, una maravilla, pero de ensamblador no tenemos nada parecido. Para los expertos notepad++ va muy bien, pero para los novatos les es algo frío.

Y si encima puedo meter cosillas destinadas a facilitar la vida, mejor que mejor, por eso estoy abierto a sugerencias.

[apenao]

Yo uso Context + Pasmo (o el compilador de Boriel, segun para qué) en mis tonterias y de momento es más que suficiente para mí, pero si alguna vez llego a "pasar de nivel" hay cosas que creo que estaría muy bien tener en una herramienta como esta, a ver que te parecen:

1.- Mapa de memoria. De manera que se pueda organizar donde va cada sección del código o ver la memoria disponible en cada momento (bueno, esto no sería exacto por el tema de la pila, por ejemplo, pero aproximado ¿se podría?

2.- Contador de T-states: Esto supongo que es imposible per se (por el tema de que las instrucciones "condicionales" - ¿se llaman así? - duran más o menos según se cumpla o no la condición. Pero, ¿sería posible hacer algo aproximado? Se puede hacer con exactitud en el debugger del emulador (y a mano, claro está) pero tenerlo en una herramienta como esto podría ser interesante.

De momento eso. Si se me ocurren más cosas las pondré. Gracias por el programa y por anunciar que seguirás con el curso.

[radastan]

1.- Mapa de memoria. De manera que se pueda organizar donde va cada sección del código o ver la memoria disponible en cada momento (bueno, esto no sería exacto por el tema de la pila, por ejemplo, pero aproximado ¿se podría?

Por supuesto que se podría. Partiendo del ORG inicial se puede ordenar el código de forma que ocupe el espacio de memoria que se quiera. Lo tendré en cuenta para que se pueda ordenar de laguna manera, no es mala idea (se podría evitar usar la RAM lenta en ciertas partes del código).

2.- Contador de T-states: Esto supongo que es imposible per se (por el tema de que las instrucciones "condicionales" - ¿se llaman así? - duran más o menos según se cumpla o no la condición. Pero, ¿sería posible hacer algo aproximado? Se puede hacer con exactitud en el debugger del emulador (y a mano, claro está) pero tenerlo en una herramienta como esto podría ser interesante.

Hombre, si uso reconocimiento de las instrucciones es posible indicar su duración sin problemas, tiene su trabajo pero no es una locura. Lo veo la mar de interesante para optimizaciones. A las malas puedo hacer un espacio aparte del editor que sea para calcular el tiempo de la rutina de forma aproximada, para poder optimizar código.

Tomo nota que eso me ha gustado MUCHO.

De momento eso. Si se me ocurren más cosas las pondré. Gracias por el programa y por anunciar que seguirás con el curso.

El curso lo voy a retomar en cuento meta un par de cosillas al editor, más que nada porque la idea es proporcionar rutinas de scroll, sprites, mapeado, etc... y que la gente se olvide de dichos asuntos (por eso la pestaña de subrutinas).

Os agradezco las sugerencias, tomo nota de todo.