ccz80

[dinoneno]

Adjunto nueva versión (ejecutable y fuente) de la utilidad para dar formato al código ensamblador para funciones para ccz80. El código se puede escribir así:

function byte Nombre(byte, word)
{
valor: equ 1000
ld a,1
ld hl,valor
ret
} using NombreOtra;

y mediante esta utilidad darle el formato adecuado para ccz80.

[dinoneno]

En las opciones ("Options.vb")

- Desde el editor visual, añadir "ccz80.exe" en la propiedad "Text" de la casilla "ccz80CompilerTextBox"

- Desde el editor visual, añadir "@SOURCE /org=25000" en la propiedad "Text" de la casilla "ccz80CompilerArgumentsTextBox"

- Desde el editor visual, añadir "@CURRENTWINDOW" en la propiedad "Text" de la casilla "SourceFileTextBox"

Para incluir la nueva macro: en "main.vb", dentro de la función "ReplaceValues"

- La linea 433 era: Dim source As String = GetKey("SourceFile")

- Añadir a continuación la siguiente línea: source = source.Replace("@CURRENTWINDOW", Me.ActiveMdiChild.Text)

Para que avise de qué está compilando:

- En la línea 384 añadir el nombre del fuente: If Not RunProcess(p, "Compiling "+ReplaceValues(GetKey("SourceFile")), "ccz80 compiler", "ccz80 compiler") Then Return

(Aun así, aquí me toma el pelo: escribe "Compiling @CURRENTWINDOW...", en vez de su valor reemplazado, a pesar de que sí compila bien. Si escribiera el nombre del fuente exacto quedaría mejor, pero no veo cual es el motivo para que lo use bien en un caso y mal en otro...)


Una pequeña corrección en la traducción:

- En la línea 415, cambiado a: MessagesListBox.Items.Add("Finished")

Hola Nacho, ya he conseguido algo con este tema del IDE:

He tomado tus ideas, pero he cambiado la forma de hacerlo, porque al entrar en la pantalla de opciones de proyecto tomaba los valores del registro y sustituía los que tuvieran por defecto las cajas de texto. Básicamente lo que he hecho es que al iniciar el programa (evento Load de formulario Main) comprueba si en el registro no está definido el compilador y el fichero ccz80.exe existe en la carpeta actual define éste como compilador; además en ese caso define como parámetros @SOURCE /25000 (creo que es un valor válido para compilar en CPC, Spectrum y MSX, ya que esta herramienta no es sólo para Amstrad).

A la hora de compilar he hecho que si no está definido en las opciones (es decir, en el registro) el fichero fuente, compile el fichero de la ventana activa en ese momento, pero sin modificar cual es el fichero fuente en las opciones del proyecto. Lo he hecho así porque si después se abre otro archivo, al quedarse grabado el primer archivo como fichero fuente en las opciones siempre compilaría ese, o habría que entrar ahí a cambiarlo, y eso ya podría volver al principio un poco loco a algún usuario, y creo que tu idea es facilitarles el inicio. He creado una funcion SourceName que devuelve el nombre del fichero fuente definido en las opciones, y si no está definido, devuelve el fichero de la ventana activa.

La idea de definir un fichero fuente en las opciones de proyecto y compilar siempre ese, es porque cuando se trabaja en un proyecto ya mediano puede que en muchos momentos estés modificando, no el fichero principal, sino alguna librería o ficheros secundarios, y es pesado tener que pasar a la ventana del fichero principal siempre antes de compilar. Así que se define cual es el principal en las opciones y puedes estar editando cualquier otro antes de compilar.

Lo de mostrar el nombre del archivo que se está compilando, perfecto. Lo he hecho utilizando esa función SourceName que comentaba. Lo del error en el mensaje "Finished", también perfecto. Adjunto el proyecto con los cambios.

La web también la he cambiado y en breve la voy a subir con los cambios (atención, que el nuevo IDE no está todavía en la web, ahora mismo es el antiguo).

A ver qué te parece todo esto.

EDITO: no me dejar subir el adjunto por exceso de tamaño. Si alguien lo quiere ver se lo envío por e-mail (enviadme un privado con la dirección, por favor).

[nacho]

Lo veo todo perfecto. Lo de que se tome la ventana activa si no está el SourceName es lo ideal, porque permite tanto proyectos de un fuente como tener abiertos varios, entre los que uno sea el principal.

Lo del registro no me mata especialmente, pero entiendo que son manías mías, yo soy más amigo de los .INI. en la carpeta del ejecutable, que te lo puedes llevar de un equipo a otro, que puedes modificar a mano en caso de necesidad, etc.

Ya solo falta una utilidad para cargar los BIN de forma rápida. Quizá una opción /LOADER del compilador que también genere un fichero .BAS con el LOAD y el CALL... y si además empaqueta todo en un paquete de algún tipo, sería la caña (DSK, CDT, SNA o algo de ese estilo). Solo por soltar ideas...

Si puedo ayudarte en cualquier cosa, sólo tienes que decirlo, aprovecha que estoy de vacaciones y tengo algo más de tiempo libre.

De momento, miraré qué emulador me permite leer los BIN y hacer pruebas. Si todo va bien, haré una serie de fuentes básicos, progresivos, y te los mandaré para que los puedas incluir en el ZIP del "todo en uno".

[dinoneno]

Lo del registro no me mata especialmente, pero entiendo que son manías mías, yo soy más amigo de los .INI. en la carpeta del ejecutable, que te lo puedes llevar de un equipo a otro, que puedes modificar a mano en caso de necesidad, etc.

Yo también he pensado en crear mejor un INI para poder portarlo de un sitio a otro más fácilmente. ¿Conoceis cómo gestionar los ficheros INI desde Visual Basic .NET?

Ya solo falta una utilidad para cargar los BIN de forma rápida. Quizá una opción /LOADER del compilador que también genere un fichero .BAS con el LOAD y el CALL... y si además empaqueta todo en un paquete de algún tipo, sería la caña (DSK, CDT, SNA o algo de ese estilo). Solo por soltar ideas...

Para cargar ficheros binarios, tras pensarlo, preferí poner la utilidad que he puesto en este hilo unos mensajes más atrás. Creo que dado el carácter prácticamente estático de estos datos es bastante cómodo crear un fichero definiendo un array con el contenido del binario e incluirlo en el programa principal.

Se puede crear un SNA muy facilmente con una utilidad que hay en la página del CPCBasic (InsSNA). Tú reinicias el emulador y creas un archivo snap. Luego tendrías que crear un fichero por lotes que compile y mediante InsSNA inserte el binario en el archivo snap, creando un nuevo snap con el binario ya incluído, que sería el que cargarías en el emulador. Volviendo a IDE, tiene en las opciones una casilla para un "conversor", que se ejecuta tras compilar y que bien podrías ser este InsSNA.

De todas formas me has dado la idea de añadir al ccz80 una opción /post=<orden> (podrían indicarse varias opciones /post) para que el mismo compilador lanza <orden> tras compilar, conde esta <orden> podrías ser la ejecución de InsSNA, del emulador, o cualquier otra. ¿Pensais que sería útil?

De momento, miraré qué emulador me permite leer los BIN y hacer pruebas. Si todo va bien, haré una serie de fuentes básicos, progresivos, y te los mandaré para que los puedas incluir en el ZIP del "todo en uno".

El WinCPC (pese a sus pegas de asociarte todas las extensiones que le da la gana) puede leer los binario generados por el ccz80. Sin embargo, yo uso el WinApe, escribiend en su ensamblador el siguiente programa:

Código: Seleccionar todo

org #4000
run $
incbin "C:\Ficheros\Fuentes\ccz80\prueba.bin"

y así, tras compilar desde el editor (PSPad, NotePad++, etc.) sólo tengo que irme al ensamblador del WinApe y seleccionar Assembler/Run o F9 y el programa se pone a funcionar sin más. Por cierto, que como al ejecutar de esta forma en la pila no existe dirección de retorno, al finalizar el programa empiezan a ocurrir cosas extrañas. Si el programa termina regresando al Basic se debería poner un jr $ como última línea en el código del ensamblador de WinAPE para hacer un bucle infinito y ver los resultados; si no se pone pues habría que usar Assembler/Assemble o Ctrl+F9 y luego escribir call &4000 en el emulador.

[dinoneno]

Adjunto la nueva versión beta del IDE 1.0.4. Ahora creo que sí me dejará subirla. Se trata del código fuente, pero entre todos los archivos va también el exe para no tener que compilarlo.

[nacho]

De todas formas me has dado la idea de añadir al ccz80 una opción /post=<orden> (podrían indicarse varias opciones /post) para que el mismo compilador lanza <orden> tras compilar, conde esta <orden> podrías ser la ejecución de InsSNA, del emulador, o cualquier otra. ¿Pensais que sería útil?

Yo creo que sí. O si no, simplemente incluir un fichero BAT "compileForCpc.bat" que genere en BIN, lo meta en un SNA, etc., y que sea parte del fichero "todo en uno".

El WinCPC (pese a sus pegas de asociarte todas las extensiones que le da la gana) puede leer los binario generados por el ccz80. Sin embargo, yo uso el WinApe, escribiend en su ensamblador el siguiente programa:

Código: Seleccionar todo

org #4000
run $
incbin "C:\Ficheros\Fuentes\ccz80\prueba.bin"

Sí, lo conseguí probar desde WinCPC y desde JavaCPC. Es un método un poco lento para hacer pruebas continuas, pero aun así es soportable, aunque no se creara SNA o similar: basta con que el desarrollador del programa sea el que, una vez volcado al .BIN definitivo al emulador, lo pase a un .DSK junto con un cargador básico.

Por mi parte, ahora sólo falta que tenga un rato para hacer varias pruebas básicas (hoy he estado todo el día fuera de casa, y mañana me espera un día todavía más movido, pero me queda algún día de vacaciones... ) Querría hacer algún fuente "puramente académico" para demostrar posibilidades del lenguaje, y si me llega a dar tiempo, también alguno un poco más aplicado con algún ejemplo que se pueda aplicar para quien quiera hacer algún juego usando CCZ80: algo como movimiento de sprites, etc. (si llevo a entender los suficiente la SpritesAlive).

[dinoneno]

Varias de las cosas pendientes sobre el compilador ccz80 ya están hechas. Está en la web la versión 2.0.6 con las novedades:

http://www.telefonica.net/web2/emiliogu ... .html#news

[Artaburu]

Hoy he retomado el asunto de adaptar al czz80 la cpcrslib que tengo para el z88dk. Ya está al 80% más o menos, con lo más importante del mapa de tiles. Si mañana no ando muy liado espero terminarla a falta de optimizar las llamadas a las funciones.
Eso sí, me he encontrado algún problema con la opción nueva de añadir un binario a un código fuente. Si defino una etiqueta para un binario y la uso en el fuente, me dice que la estoy redefiniendo.
Otra cosa que no me mola mucho es no poder definir estructuras y tener que llamar con *(x+2) y **(x+3), porque es muy oscuro y difícil de leer, pero seguro que lo arreglas
Chao!

[Artaburu]

Se ve que he podido
Aquí está el grueso... faltan algunas rutinas que creo que ya las cubre las librerías estandar. Hay mucho que optimizar en las llamadas puesto que al ser algo distintas entre el z88dk y el ccz80 al final he optado por hacerlas todos iguales y ya he visto que se pueden mejorar.
La información de las rutinas está aquí:
http://www.amstrad.es/programacion/cpcrslib.html

Aviso: No hay nada de scrolls ni del WYZPlayer... el scroll no me convence mucho y del Wyzplayer no puedo publicar el código fuente así que por ahora, nada

Adjunta va la librería y aquí un pequeño ejemplo en ccz80 usando algunas de las rutinas incluidas:

[code]
include "cpcrslib.ccz80";

// Definición de variables


byte i;
byte x,direccion;
byte MinX,MinY,MaxX, MaxY,HorzSpd,VertSpd,gravityAccel;



// Iniciación de variables:
x=8;
direccion=0;
MaxX=60;
MaxY=110;
MinX=0;
MinY=0;
VertSpd=1;
HorzSpd=1;
gravityAccel=2;

// Iniciación datos sprite:
**(sp1) = sp1_data; //word
**(sp1+2) = sp1_data;
*(sp1+8) = x; //byte
*(sp1+9) = 20;

cpc_AssignKey(4,#4804); //ESC to key #1

// Desactivamos el firmware puesto que no lo vamos a usar
// y así se gana algo de velocidad
cpc_DisableFirmware();

//Limpieza de la pantalla:
cpc_ClrScr();

gosub establecerColores;
cpc_SetMode(0);


//Se escribe un texto:
gosub escribeTexto;

//rellena el buffer con el mapa y lo envía a pantalla. Es el método para mostrar toda la pantalla:
cpc_ShowTileMap(0);
cpc_ScanKeyboard();
while (!cpc_TestKeyF(4)){
cpc_ScanKeyboard();

//borra la lista de tiles tocados
cpc_ResetTouchedTiles();
gosub pausa;
if (*(sp1+8) >= MaxX)
{
HorzSpd = -HorzSpd;
*(sp1+8) = MaxX;
}
else if (*(sp1+8) <= MinX)
{
HorzSpd = -HorzSpd;
*(sp1+8) = MinX;
}

if (*(sp1+9)>= MaxY)
{
VertSpd = -VertSpd;
*(sp1+9) = MaxY;
}
else if (*(sp1+9) <= MinY)
{
VertSpd = -VertSpd;
*(sp1+9) = MinY;
}

VertSpd += gravityAccel - 1;


*(sp1+8) += HorzSpd;
*(sp1+9) += VertSpd;


cpc_PutSpTileMap(sp1);
cpc_UpdScr();
cpc_PutMaskSpTileMap2b(sp1);
cpc_ShowTouchedTiles();


}



// Antes de salir, habilitamos el firmware:
cpc_EnableFirmware();
// fin del programa
return;


// Subrutinas y funciones:

establecerColores:
for (i=0;i<15;i++)
cpc_SetColour(i,*(tintas + i));
return;



pausa:
asm {
"ld b,8",
"kolo:",
"halt",
"djnz kolo"
}
return;


escribeTexto:
cpc_SetInkGphStr(0,0);
cpc_PrintGphStrXY("PULSA;ESC;PARA;TERMINAR",8*2,20*8);
cpc_PrintGphStrXY("CCZ80;;CPCRSLIB",12*2,21*8);
cpc_PrintGphStrXY("BY;ARTABURU;2009",12*2-1,22*8);
cpc_PrintGphStrXY("WWW<AMSTRAD<ES",12*2+1,24*8);
return;



// Definición de sprites y arrays

// Sprite 1:
array byte sp1[15];
array byte sp1_data = {
4,16,
#FF,#00,#FF,#00,#FF,#00,#FF,#00,
#FF,#00,#FF,#00,#FF,#00,#FF,#00,
#FF,#00,#00,#0F,#55,#0A,#FF,#00,
#AA,#05,#00,#0F,#00,#25,#FF,#00,
#AA,#05,#00,#0F,#00,#1A,#FF,#00,
#00,#0F,#00,#0F,#00,#1A,#55,#0A,
#00,#0F,#00,#0F,#00,#0F,#55,#0A,
#00,#0F,#00,#0F,#00,#0F,#55,#0A,
#00,#0F,#00,#0F,#00,#0F,#55,#0A,
#00,#0F,#00,#0F,#00,#0F,#55,#0A,
#00,#0F,#00,#0F,#00,#0F,#55,#0A,
#00,#0F,#00,#0F,#00,#0F,#55,#0A,
#AA,#05,#00,#0F,#00,#0F,#FF,#00,
#AA,#05,#00,#0F,#00,#0F,#FF,#00,
#FF,#00,#00,#0F,#55,#0A,#FF,#00,
#FF,#00,#FF,#00,#FF,#00,#FF,#00
};


// Lista de colores hardware:
array byte tintas = {
20,0,4,12,11,10,14,13,6,25,31,28,18,24,23,3
};
[/code]

[dinoneno]

Eso sí, me he encontrado algún problema con la opción nueva de añadir un binario a un código fuente. Si defino una etiqueta para un binario y la uso en el fuente, me dice que la estoy redefiniendo.

No sé si entiendo lo que quieres decir. En este ejemplo incluyo un fichero binario (de 10 bytes de tamaño, por ejemplo con los valores 48 a 57 para que imprima todos los dígitos) y después la etiqueta "datos" la uso en la incialización del for:

include "cpc464.ccz80";

datafile "a.bin" = datos;

word p;
byte i;
for (i = 1, p = datos; i <= 10; ++i, ++p) printc(*p);
return;

Otra cosa que no me mola mucho es no poder definir estructuras y tener que llamar con *(x+2) y **(x+3), porque es muy oscuro y difícil de leer, pero seguro que lo arreglas

Sí, en cuestión de tablas y estructuras ccz80 no soporta nada, hay que hacerlo tal y como dices. Creo que lo comenté hace tiempo, no sé si aquí mismo, que se puede definir con "const" ciertos valores para usar en lugar de las constantes, así incluso está más parametrizado el programa. Aquí pongo un ejemplo de una pseudo-estructura y su uso mediante constantes:

include "cpc464.ccz80";

// Este espacio "datos" va a ser una estructura con el siguiente formato:
// - Primer y segundo byte: coordenada x (de tipo word)
// - Tercer y cuarto byte: coordenada y (de tipo word)
// - Quinto byte: color (de tipo byte)
// - Sexto byte: visibilidad, 0 si no es visible, otro valor si lo es (de tipo byte)
array byte punto[6];

const OFS_X = 0,
OFS_Y = 2,
OFS_COLOR = 4,
OFS_VISIBLE = 5;

// Asignar valores para el punto
**(punto + OFS_X) = 320; // Coordenada X = 320
**(punto + OFS_Y) = 200; // Coordenada Y = 200
*(punto + OFS_COLOR) = 1; // Color de punto = 1
*(punto + OFS_VISIBLE) = 1; // Punto es visible

// Dibujar punto
mode(1);
if (*(punto + OFS_VISIBLE))
{
graphicspen(*(punto + OFS_COLOR));
plot(**(punto + OFS_X), **(punto + OFS_Y));
}
return;

Cierto que hay que tener en cuenta si el dato es byte o word para usar * o **. Iré pensando otras soluciones.

[Artaburu]

Eso sí, me he encontrado algún problema con la opción nueva de añadir un binario a un código fuente. Si defino una etiqueta para un binario y la uso en el fuente, me dice que la estoy redefiniendo.

No sé si entiendo lo que quieres decir. En este ejemplo incluyo un fichero binario (de 10 bytes de tamaño, por ejemplo con los valores 48 a 57 para que imprima todos los dígitos) y después la etiqueta "datos" la uso en la incialización del for:

Ok, el problema está en meter la definición después de la llamada. Si la meto antes va bien

[dinoneno]

Se ve que he podido
Aquí está el grueso... faltan algunas rutinas que creo que ya las cubre las librerías estandar. Hay mucho que optimizar en las llamadas puesto que al ser algo distintas entre el z88dk y el ccz80 al final he optado por hacerlas todos iguales y ya he visto que se pueden mejorar.
La información de las rutinas está aquí:
http://www.amstrad.es/programacion/cpcrslib.html

Aviso: No hay nada de scrolls ni del WYZPlayer... el scroll no me convence mucho y del Wyzplayer no puedo publicar el código fuente así que por ahora, nada

Genial

[Artaburu]

Una sugerencia para la llamada a funciones, ¿sería posible una forma de llamar a una función pasando el parámetro en HL y que no tenga que ser una función inline? Así se ganaría bastante en llamadas a funciones de un solo parámetro ya que pasando parámetros por la pila, al retorno de la función siempre hay que saltar en la pila esos parámetros, a parte que buscar el parámetro dentro de la función también es un poco lento

[dinoneno]

Una sugerencia para la llamada a funciones, ¿sería posible una forma de llamar a una función pasando el parámetro en HL y que no tenga que ser una función inline? Así se ganaría bastante en llamadas a funciones de un solo parámetro ya que pasando parámetros por la pila, al retorno de la función siempre hay que saltar en la pila esos parámetros, a parte que buscar el parámetro dentro de la función también es un poco lento

Me ha parecido una idea excelente. Yo la tenía en la cabeza, pero para funciones de varios parámetros, pero no encontraba una forma adecuada de hacerlo. Para un parámetro creo que ya he conseguido llevarlo a cabo. La hoy publicada versión 2.0.7 ya la tiene implementada.

[Artaburu]

¡Muy buena noticia!