OKI09
|
|
« Respuesta #105 : 04 de Junio de 2008, 05:40:15 pm » |
|
Bueno Robsy.
He ensamblado mi juego con esta version del asmsx y te comento:
line 1117 : undefinid identifier
Dicha linea contiene lo siguiente:
.print (FINAL-C000h)
Son las instrucciones que se encargan de crear el fichero txt con el tamaño del codigo. (En la version que yo estaba utilizando hasta ahora funcionaba bien) Al quitar dicha linea va perfecto, una rapidez increible, ensamblado en 0.06 sg. Despues he probado el .bin resultante y creo que va bien.
Espero que mi pequeña ayuda te sirva de algo.
Bye.
|
|
|
En línea
|
La derrota no es una opción y no hay excusas. "Parasiempre"
|
|
|
pitpan
|
|
« Respuesta #106 : 05 de Junio de 2008, 12:06:32 am » |
|
Detectado y explicado: he cambiado la regla de detección de hexadecimales porque daba algún problema de estabilidad. Los hexadecimales se pueden expresar de las siguientes formas:
$C000 0xC000 0C000h
Pero no se admite ya C000h, y se adopta el criterio de otros ensambladores, que requieren que si la identificación de formato es un terminador (h), deban empezar necesariamente con un número. Por eso habría que añadir el 0 inicial.
Con esto, no deberías tener problemas. De todos modos, ¿has usado Windows o Linux?
Gracias por las pruebas, OKI!!!
|
|
|
En línea
|
|
|
|
OKI09
|
|
« Respuesta #107 : 05 de Junio de 2008, 04:38:31 pm » |
|
¿has usado Windows o Linux? He usado Windows. Probadas las 3 opciones que me citas anteriormente y funcionan a la perfeccion, incluso se ha mejorado el tiempo de compilacion a 0,05sg. (Una pasada) Gracias por mejorar el asmsx, Robsy. Seguiremos de cerca todas las mejoras que quieres incluir.
|
|
|
En línea
|
La derrota no es una opción y no hay excusas. "Parasiempre"
|
|
|
pitpan
|
|
« Respuesta #108 : 19 de Septiembre de 2008, 10:22:16 am » |
|
EUREKA. Tras un encontronazo fortuito con la documentación oficial de flex (me refiero al "Fast LEXical scanner generator" de GNU), he conseguido - aparentemente - solucionar el problema de colisión de etiquetas que infestaba asMSX desde la primera versión. Evidentemente, supone un coste en cuanto a tiempo de proceso y tamaño del programa, pero merece la pena y tampoco debería preocuparnos mucho. Con esto, asMSX da un paso más hacia una versión estable y completa. Por lo tanto, falta comprobar que con los nuevos cambios no se haya roto nada en ningún otro sitio, y aprovechar también para depurar algún otro bug menor. En cualquier caso, evitando la colisión de etiquetas y, con lo que ya se corregía en la versión 0.15 previa, que era la desaparición arbitraria de etiquetas, la herramienta ha ganado mucho en estabilidad. Y la versión para Linux ya es una realidad, así que estoy satisfecho por estos pequeños logros. El otro objetivo a la vista es conseguir que se compile en Mac, ampliar la colección de ejemplos y herramientas de apoyo, y actualizar la documentación además de hacer una versión en inglés. No me queda nada En cualquier caso, creo que para octubre podría haber una versión oficial del asMSX 0.15. Dependerá de los ratos libres que consiga atesorar.
|
|
|
En línea
|
|
|
|
pitpan
|
|
« Respuesta #109 : 19 de Septiembre de 2008, 11:48:36 am » |
|
Por cierto, que respecto a lo que comentaba Jos'b en el código fuente de ZONE, contesto directamente: ; Posibles fallos detectados en el ensamblador AsMSX 0.12g durante el desarrollo de este juego ; ; - No reconoce la etiqueta DSPFNK (00CFh) de llamada a la BIOS para activar teclas función -CORREGIDO-Se trataba de una colisión entre etiquetas y pseudoinstrucciones.; - ADD IX, HL - No se envía mensaje de error -CORREGIDO-Un error monumental, lo ensamblaba como ADD IX,IX. También aceptaba ADD IY,HL y la ensamblaba como ADD IY,IY.; - Colocando la directiva "db" entre directivas "ds" la toma como otra "ds"¿? -NO ES UN ERROR-Si se reserva espacio (DS) y después se escriben datos (DB), el puntero de programa ha de avanzar necesariamente. DS reserva un número de bytes sin definir y a continuación se ensamblan los datos siguientes. DS ocupará espacio siempre que no sea la última instrucción en cuanto a direcciones de memoria.; - Error al colocar como dato Hex. "DBh" ¿lo interpreta como directiva la "db"? -CORREGIDO-De todos modos, el formato debería ser 0DBh o $DB o 0xDB con la sintaxis normalizada para evitar colisiones.Gracias por detectar y diagnosticar los errores, Jos'b. Siento haber tardado tanto en responder, pero ahora el asMSX es un poco mejor. Si alguien más ha hecho bug-hunting con las últimas versiones (0.12 en adelante), que hable ahora o calle hasta la próxima versión
|
|
|
En línea
|
|
|
|
pitpan
|
|
« Respuesta #110 : 19 de Septiembre de 2008, 02:10:01 pm » |
|
Parece que agunta bastante bien, así que os dejo una versión de pruebas, sólo para Windows esta vez: asMSX v.0.15a (19/09/2008) - Windows. Si alguien tiene código por ahí y se anima a probarla, que me cuente el resultado. Gracias
|
|
|
En línea
|
|
|
|
Jon_Cortazar
|
|
« Respuesta #111 : 21 de Septiembre de 2008, 08:08:14 am » |
|
Descagando, socio! Felicidades por el release
|
|
|
En línea
|
Jon Cortázar Abraido (aka El Viejo Archivero) RELEVO Videogames [Dioniso: La cafeína está haciendo su trabajo; yo espero hacer el mío.] [pitpan: Me sigue pareciendo más productivo jugar al SNAIL MAZE que seguir esta discusión.]
|
|
|
jltursan
|
|
« Respuesta #112 : 21 de Septiembre de 2008, 11:52:27 am » |
|
Me lo descargo y de hecho lo voy a probar ahora mismo...
|
|
|
En línea
|
Doom dee doom dee doom
|
|
|
jltursan
|
|
« Respuesta #113 : 21 de Septiembre de 2008, 01:35:34 pm » |
|
¡Enhorabuena, ahora si que me da buen rollo!, compila mucho mejor que antes Un pequeño reporte de fallos que le he encontrado de momento: Errores asociados a REPT REPT <n>: n no permite expresiones de ningun tipo (supongo que es una limitación; pero...) ...en general no aparece el nombre del archivo en la cadena del error. Casos especiales: - Si la expresion contiene una expresion con equivalencias (SPRITE_WIDTH/2) elmensaje de error es "number expected in REPT" y la linea es correcta. - Si la expresion contiene una expresion sin equivalencias (24/2) el mensaje de error es "syntax error" y la linea reportada incorrectamente es la anterior Error asociado al archivo de salida En algunos casos y dependiendo de la extensión del archivo fuente, el archivo de salida ROM generado no tiene exactamente la extensión .rom. Ejemplo: sprites.asm -> sprites.rom sprites.msx -> sprites.rom sprites.asmx -> sprites.asrom sprites.pepe -> sprites.prom Ala, que esto va por buen camino
|
|
« Última modificación: 21 de Septiembre de 2008, 01:37:55 pm por jltursan »
|
En línea
|
Doom dee doom dee doom
|
|
|
pitpan
|
|
« Respuesta #114 : 21 de Septiembre de 2008, 07:38:09 pm » |
|
Hola! Gracias por el report, JL! Te contesto lo que puedo/sé: - El REPT, como tú bien dices, sólo funciona con números en formato decimal, no admite expresiones. Esto es así porque está implementado a nivel de preprocesador, y no quise añadir más complejidad a éste. El evaluador de expresiones está en el módulo ensamblador propiamente dicho. El tema de que no indique el archivo erróneo lo detecté, pero no lo he podido investigar. Lo que sucede es que tendría que dar siempre un mismo error al usar REPT 20+1 o REPT num. En fin, seguiré con ello. - Las extensiones de los ficheros tienen que petar necesariamente. El código que uso para generar los nombres está heredado de la primera versión para MS-DOS (formato 8.3). Por lo tanto, con extensiones de más de 3 letras es posible que haga algunas cosillas raras. Eso te pasa por no usar .ASM siempre, como cualquier programador responsable En fin. Revisaré el código y lo puliré un poco, porque manipulaba los punteros "a mano", sin ninguna rutina de strings. Pero bueno, me alegra mucho que te dé buen feeling esta nueva versión. Creo que ahora sí estoy en el buen camino. Además, no puedo añadirle más funcionalidades hasta que no haya solucionado los problemas de base, que son principalmente la estabilidad. Gracias por las pruebas. Si alguien más tiene algo que decir, que dispare
|
|
|
En línea
|
|
|
|
kabish
|
|
« Respuesta #115 : 21 de Septiembre de 2008, 09:41:02 pm » |
|
Bueno, lo primero agradecerte el curro que estas haciendo con el 'asmsx'. Yo no he probado esta version todavia pero esta semana tengo vacaciones y sacare tiempo para probarlo. Espero que no tardes mucho en sacar la version de linux, pero poco a poco, ya me entiendes Un saludo.
|
|
|
En línea
|
|
|
|
Jos'b
|
|
« Respuesta #116 : 22 de Septiembre de 2008, 07:14:26 am » |
|
Me alegro por la nueva versión, ya sabes que soy un fiel usuario del asMSX. Y por supuesto sigo manteniendo las propuestas de mejora que hice antes del último crash del foro.
|
|
|
En línea
|
|
|
|
WYZ
Visitante
|
|
« Respuesta #117 : 22 de Septiembre de 2008, 12:34:18 pm » |
|
Me alegro por la nueva versión, ya sabes que soy un fiel usuario del asMSX. Y por supuesto sigo manteniendo las propuestas de mejora que hice antes del último crash del foro.
Idem! y enhorabuena Robsy. El caso es que ya me habia acostumbrado tanto que lo voy a echar de menos Yo lo uso para cualquier plataforma con un algo parecido a un z80, incluyendo el Sam Coupé.
|
|
|
En línea
|
|
|
|
pitpan
|
|
« Respuesta #118 : 22 de Septiembre de 2008, 01:36:45 pm » |
|
Ese WYZ! El usuario más fiel (y también probablemente el más antiguo) del asMSX. Me encantaría darle soporte para otras plataformas, pero no estoy seguro de que pudiera alcanzar un nivel de funcionalidad equivalente al que le he dado para MSX hasta el momento. Meditaré un poco al respecto. De hecho, me da hasta miedo incluirle un modo R800, por el tema de que el asMSX soporta todas las instrucciones no documentadas del Z80 y el R800 no. Discriminar unas de otras puede hacerme la vida muy difícil Vale. Pensaré en la viabilidad de una pseudoinstrucción llamada STRICT o algo así, que te de avisos/errores en el caso de usar instrucciones no documentadas. Así se podría hacer algo parecido. Y ahora que lo pienso, ¿qué haces tú tirando código para un SamCoupé? ¿Producciones de CEZ? Se intuye quizás una versión del Phantomas Infinity...
|
|
|
En línea
|
|
|
|
jltursan
|
|
« Respuesta #119 : 22 de Septiembre de 2008, 10:09:38 pm » |
|
Vale. Pensaré en la viabilidad de una pseudoinstrucción llamada STRICT o algo así, que te de avisos/errores en el caso de usar instrucciones no documentadas. Así se podría hacer algo parecido. O alguna del estilo .R800 para habilitar (y deshabilitar) las instrucciones que corresponda. Lo del STRICT me recuerda mucho al Perl - El REPT, como tú bien dices, sólo funciona con números en formato decimal, no admite expresiones. Esto es así porque está implementado a nivel de preprocesador, y no quise añadir más complejidad a éste. El evaluador de expresiones está en el módulo ensamblador propiamente dicho. El tema de que no indique el archivo erróneo lo detecté, pero no lo he podido investigar. Lo que sucede es que tendría que dar siempre un mismo error al usar REPT 20+1 o REPT num. En fin, seguiré con ello. Me lo imaginaba, no problem. Es de esas comodidades de las que puedes prescindir. Las extensiones de los ficheros tienen que petar necesariamente. El código que uso para generar los nombres está heredado de la primera versión para MS-DOS (formato 8.3). Por lo tanto, con extensiones de más de 3 letras es posible que haga algunas cosillas raras. Eso te pasa por no usar .ASM siempre, como cualquier programador responsable Grin En fin. Revisaré el código y lo puliré un poco, porque manipulaba los punteros "a mano", sin ninguna rutina de strings. Tsk, tsk, esos punteros... Aunque supongo que sera todo C, si por alguna casualidad es C++ no dejes de echarle un vistazo a las STL (Standard Template Libraries). Yo ya hace años que no uso otra cosa y creo que hasta me costaría manipular cadenas en C puro En cualquier caso, échale un vistazo anda, que como no tenga extensiones de más de tres letras voy listo
|
|
|
En línea
|
Doom dee doom dee doom
|
|
|
|