IMPORTANTE - convocatoria de The Mojon Twins
Moderador: Sir Cilve Sinclair
- Alxinho
- Freddy Hardest
- Mensajes: 896
- Registrado: Mar Jun 19, 2007 11:20 am
- Ubicación: Barcelona
- Contactar:
Re: IMPORTANTE - convocatoria de The Mojon Twins
Me aprovecho y lanzo otra pregunta ... Lo que ocupe el .tzx es una buena guía para saber lo que te queda de memoria?
Retrobytes Productions --> http://retrobytesproductions.blogspot.com.es
Soy un tío feliz, más que nada ... porque me sale más a cuenta.
Soy un tío feliz, más que nada ... porque me sale más a cuenta.
- na_th_an
- Nonamed
- Mensajes: 1889
- Registrado: Lun May 07, 2007 10:16 am
- Ubicación: Andalucía
Re: IMPORTANTE - convocatoria de The Mojon Twins
Más o menos, pero hay una forma mejor. Cuando cargues el tzx en el emulador, casi todos los emuladores tienen su tape browser. Ahí puedes ver exactamente los bytes que ocupa tu binario: habrá un bloque BASIC cargador y otro con el código compilado. En spectaculator es muy sencillo de ver. Mira a ver donde empieza (si no has especificado nada, será 32768) y cuánto ocupa. La memoria que te quedará será 65536-INICIO-LONGITUD.
Si te vas quedando apurado, puedes bajar la dirección de compilador con el parámetro -S hasta 25000 más o menos. La memoria por debajo de 32768 está en contienda y es "más lenta", aunque tampoco se nota mucho si no estás haciendo efectos especiales o scrolles super suaves en super ensamblador
Otro parámetro es el que controla el "heap". Las cadenas en ZX Basic son automáticas: puedes operar con ellas fácilmente sin preocuparte de donde están, cuanto ocupan, reservar o liberar memoria... Para ello, el runtime de ZX Basic reserva un espacio de RAM que se llama "heap" y ahí guarda sus cadenas y opera con ellas. Por defecto este espacio es de 4Kb. Si tu programa opera poco con cadenas (si estás haciendo un juego de acción, por ejemplo, no tendrás mucho manejo de cadenas) puedes bajar este valor.
El Maritrini, por ejemplo, se compila en 29000 (-S 29000) y tiene un heap muy pequeño, de 256 bytes (-H 256) porque lo único que hace con cadenas es recorrer cadenas cortas (de menos de 32 bytes) para imprimirlas, y poco más.
Si te vas quedando apurado, puedes bajar la dirección de compilador con el parámetro -S hasta 25000 más o menos. La memoria por debajo de 32768 está en contienda y es "más lenta", aunque tampoco se nota mucho si no estás haciendo efectos especiales o scrolles super suaves en super ensamblador
Otro parámetro es el que controla el "heap". Las cadenas en ZX Basic son automáticas: puedes operar con ellas fácilmente sin preocuparte de donde están, cuanto ocupan, reservar o liberar memoria... Para ello, el runtime de ZX Basic reserva un espacio de RAM que se llama "heap" y ahí guarda sus cadenas y opera con ellas. Por defecto este espacio es de 4Kb. Si tu programa opera poco con cadenas (si estás haciendo un juego de acción, por ejemplo, no tendrás mucho manejo de cadenas) puedes bajar este valor.
El Maritrini, por ejemplo, se compila en 29000 (-S 29000) y tiene un heap muy pequeño, de 256 bytes (-H 256) porque lo único que hace con cadenas es recorrer cadenas cortas (de menos de 32 bytes) para imprimirlas, y poco más.
- Alxinho
- Freddy Hardest
- Mensajes: 896
- Registrado: Mar Jun 19, 2007 11:20 am
- Ubicación: Barcelona
- Contactar:
Re: IMPORTANTE - convocatoria de The Mojon Twins
Joer macho ... estás hecho todo un experto y la verdad es que me suena todo un poco a chino ... Yo suponía que mientras no me pese más de 48kb todo debería ir bien, si tuviese problemas probaría de esta manera a ver.
¡Muchas gracias por la aclaración!
Por cierto ... que gracias también por los tutos de mojonía que me han solucionado un par de quebraderos de cabeza bien gordos como lo de los charsets ... te estaré toda la vida agradecido! Me suena de haberlo leído en algún artículo de MM o MH pero no me acuerdo bien, a lo mejor era otra revista o vete a saber y me estaba volviendo loco buscando porque sabía que era cosa de cambiar una variable interna como con los UDGs pero ni zorra idea ...
¡Muchas gracias por la aclaración!
Por cierto ... que gracias también por los tutos de mojonía que me han solucionado un par de quebraderos de cabeza bien gordos como lo de los charsets ... te estaré toda la vida agradecido! Me suena de haberlo leído en algún artículo de MM o MH pero no me acuerdo bien, a lo mejor era otra revista o vete a saber y me estaba volviendo loco buscando porque sabía que era cosa de cambiar una variable interna como con los UDGs pero ni zorra idea ...
Retrobytes Productions --> http://retrobytesproductions.blogspot.com.es
Soy un tío feliz, más que nada ... porque me sale más a cuenta.
Soy un tío feliz, más que nada ... porque me sale más a cuenta.
- na_th_an
- Nonamed
- Mensajes: 1889
- Registrado: Lun May 07, 2007 10:16 am
- Ubicación: Andalucía
Re: IMPORTANTE - convocatoria de The Mojon Twins
Ten en cuenta que, de los 48K, tienes que restar los 7 que ocupa la pantalla, el cargador BASIC y las variables del sistema, con lo que se te queda en unos 40K y pico.
También hay que tener en cuenta que el compilador empieza a generar el CM a partir de una dirección y que, por defecto, esa dirección es 32768, con lo que, sin tocar esto, sólo podrías usar de ahí hasta el final, que son 32K.
Además, hay que restar el espacio de las cadenas que te mencioné, o sea, 4K menos. Si te ves apurado, baja el -H a 256 bytes o incuso menos.
También hay que tener en cuenta que el compilador empieza a generar el CM a partir de una dirección y que, por defecto, esa dirección es 32768, con lo que, sin tocar esto, sólo podrías usar de ahí hasta el final, que son 32K.
Además, hay que restar el espacio de las cadenas que te mencioné, o sea, 4K menos. Si te ves apurado, baja el -H a 256 bytes o incuso menos.
- Alxinho
- Freddy Hardest
- Mensajes: 896
- Registrado: Mar Jun 19, 2007 11:20 am
- Ubicación: Barcelona
- Contactar:
Re: IMPORTANTE - convocatoria de The Mojon Twins
Ahora sí! Releyendo el artículo de Boriel y tu post ya lo he pillado. Por un lado el -s para la direccion del compilador y el -h para el ahorro de las cadenas. Gracias!
Pero ... ¿Qué significa memoria de contienda? ¿De reserva o algo así?
Pero ... ¿Qué significa memoria de contienda? ¿De reserva o algo así?
Retrobytes Productions --> http://retrobytesproductions.blogspot.com.es
Soy un tío feliz, más que nada ... porque me sale más a cuenta.
Soy un tío feliz, más que nada ... porque me sale más a cuenta.
- na_th_an
- Nonamed
- Mensajes: 1889
- Registrado: Lun May 07, 2007 10:16 am
- Ubicación: Andalucía
Re: IMPORTANTE - convocatoria de The Mojon Twins
No, "memoria en contienda" es que hay dos dispositivos "peleándose" por esa memoria
La memoria RAM del Spectrum está dividida en "RAM baja" y "RAM alta", por decirlo sencillamente. La "RAM baja" son los primeros 16K. Al principio de este bloque está la memoria de pantalla.
En el Spectrum, la imagen de la TV la genera un chip que hace muchas otras cosas y que conocemos como ULA. Para hacer esa imagen, la ULA tiene que leer la RAM para ver qué imagen dibujar.
Por tanto, la zona baja de la RAM es accedida por la CPU (para ejecutar programas o escribir en la pantalla, por ejemplo) y por la ULA (para generar la imagen de la TV). Es posible que ambos intenten acceder a la vez (que quieras escribir un texto en la pantalla justo cuando la ULA está consultando la RAM para dibujar un nuevo cuadro de imagen). En ese caso, se dice que la memoria está en contienda. Y esta contienda siempre la gana la ULA, o si no, no tendríamos una imagen fija en la TV. La ULA siempre tiene que tener la RAM disponible para ella, porque si no pudiera leerla cuando lo necesita no podría generar bien la imagen y veríamos parpadeos en la TV.
Eso significa que en estos casos la CPU tiene que esperarse. Por tanto, el código que se ejecute en esa zona de la RAM puede ejecutarse más lento y, lo que es peor, puede tardar más o menos dependiendo de las circunstancias, por lo que no se suele emplear para hacer programas que necesiten una temporización precisa.
Sin embargo, si estamos haciendo un juego en ZX Basic con cosas que se mueven a nivel de caracter podemos despreocuparnos de estos temas.
Es totalmente seguro poner el -S a 25000, por ejemplo. No creo que notes demasiada diferencia.
La memoria RAM del Spectrum está dividida en "RAM baja" y "RAM alta", por decirlo sencillamente. La "RAM baja" son los primeros 16K. Al principio de este bloque está la memoria de pantalla.
En el Spectrum, la imagen de la TV la genera un chip que hace muchas otras cosas y que conocemos como ULA. Para hacer esa imagen, la ULA tiene que leer la RAM para ver qué imagen dibujar.
Por tanto, la zona baja de la RAM es accedida por la CPU (para ejecutar programas o escribir en la pantalla, por ejemplo) y por la ULA (para generar la imagen de la TV). Es posible que ambos intenten acceder a la vez (que quieras escribir un texto en la pantalla justo cuando la ULA está consultando la RAM para dibujar un nuevo cuadro de imagen). En ese caso, se dice que la memoria está en contienda. Y esta contienda siempre la gana la ULA, o si no, no tendríamos una imagen fija en la TV. La ULA siempre tiene que tener la RAM disponible para ella, porque si no pudiera leerla cuando lo necesita no podría generar bien la imagen y veríamos parpadeos en la TV.
Eso significa que en estos casos la CPU tiene que esperarse. Por tanto, el código que se ejecute en esa zona de la RAM puede ejecutarse más lento y, lo que es peor, puede tardar más o menos dependiendo de las circunstancias, por lo que no se suele emplear para hacer programas que necesiten una temporización precisa.
Sin embargo, si estamos haciendo un juego en ZX Basic con cosas que se mueven a nivel de caracter podemos despreocuparnos de estos temas.
Es totalmente seguro poner el -S a 25000, por ejemplo. No creo que notes demasiada diferencia.
- Alxinho
- Freddy Hardest
- Mensajes: 896
- Registrado: Mar Jun 19, 2007 11:20 am
- Ubicación: Barcelona
- Contactar:
Re: IMPORTANTE - convocatoria de The Mojon Twins
Gracias hermoso!
Retrobytes Productions --> http://retrobytesproductions.blogspot.com.es
Soy un tío feliz, más que nada ... porque me sale más a cuenta.
Soy un tío feliz, más que nada ... porque me sale más a cuenta.
- na_th_an
- Nonamed
- Mensajes: 1889
- Registrado: Lun May 07, 2007 10:16 am
- Ubicación: Andalucía
- wilco2009
- Freddy Hardest
- Mensajes: 543
- Registrado: Lun Sep 17, 2012 9:40 am
- Ubicación: Valencia
Re: IMPORTANTE - convocatoria de The Mojon Twins
na_th_an escribió:wilco2009 escribió:No se si ponerme directamente a investigar el funcionamiento de las rutinas que citas, o refrescar primero el ensamblador del Z80.
¿que me recomiendas?
Hombre, la adaptación que hay que hacer en el código que genera Beepola o BeepFX no es demasiado grande, pero ayuda saber qué estás haciendo, sobre todo en BeepFX, que el ensamblador que saca el programa es muy diferente al que maneja ZX Basic, y hay que hartarse de adaptar linea y código (que es auto-modificante).
Refresca los conceptos básicos de ASM, eso siempre viene bien Fíjate en subacolib.bas, el módulo donde está la biblioteca que usa el juego: está escrita entera en ASM, pero embebida en BASIC. Es lo mejor del compilador. Puedes combinar lo mejor de cada casa.
Bueno, pues al fin he terminado el repaso al assembler con la ayuda del excelente curso de sromero que hay incluido en el wiki, pero me entran dos dudas.
Según he visto, en el caso de z88dk los parámetros de una subrutina vienen justo debajo (dos bytes por encima de sp) de la posición de retorno de la subrutina. Vamos lo típico. Pero mi sorpresa a sido, que en el caso del zxbasic no es así.
He descubierto empíricamente (ya que no está documentado o al menos yo no lo he encontrado por ninguna parte) resulta que hay otra palabra de dos bytes en la pila antes de empezar a sacar los parámetros. O sea en total SP+4.
La pregunta es ¿que narices hay en SP+2 y SP+3?
Por otro lado no he encontrado la manera de acceder a la dirección de memoria de las variables definidas desde ZXBasic.
Tercero y último (si ya sé que había dicho dos cosas), me ha sorprendido sobremanera que, en algunas ocasiones si defino variables en un asm en medio del código el valor de dichas variables es aleatorio. El mismo código funciona pasando la definición de las variables a la cabecera del programa (donde suelen ir las variables globales). ¿Tendrá esto algo que ver con el optimizador, y el puñetero compilador se piensa que el ámbito de dichas variables deja de tener validez?
PD: Me acabo de terminar el juego, jajaja Que mala leche lo de la gasolina!
- na_th_an
- Nonamed
- Mensajes: 1889
- Registrado: Lun May 07, 2007 10:16 am
- Ubicación: Andalucía
Re: IMPORTANTE - convocatoria de The Mojon Twins
Ya dijimos que lo que molaba era el final
Y sobre las preguntas que planteas... Ahí ya no llego. Mejor que se lo preguntes a Boriel directamente.
Y sobre las preguntas que planteas... Ahí ya no llego. Mejor que se lo preguntes a Boriel directamente.
- wilco2009
- Freddy Hardest
- Mensajes: 543
- Registrado: Lun Sep 17, 2012 9:40 am
- Ubicación: Valencia
Re: IMPORTANTE - convocatoria de The Mojon Twins
na_th_an escribió:Ya dijimos que lo que molaba era el final
Y sobre las preguntas que planteas... Ahí ya no llego. Mejor que se lo preguntes a Boriel directamente.
Pues no he conseguido averiguar que hay en SP+2 y +3 pero viendo los ejemplos de Boriel he visto que hay una forma más sencilla de acceder a los parámetros, gracias a que deja IX apuntando a la cima de la pila.
Entonces [IX+4] e [IX+5] contienen el primer parámetro y [IX+6] e [IX+7] al segundo y así sucesivamente.
Por otro lado le he estado echando un vistazo al código de Maritrini y se me plantean algunos temas:
- ¿Qué parámetros usas en el Beepola a la hora de exportar los datos?. He intentado sustituir la música por una de las que vienen en los ejemplos y el sonido me sale muy lento.
- ¿Con qué programa generas los datos de los efectos de sonidos?
- He pensado que igual estaría bien añadirle máscaras a foursprites para que se vea el fondo en la posición donde está situado el Sprite. Se que esto ralentizaría algo el código ya que no se podría utilizar directamente la instrucción ldi, pero quizás le daría algo más de realismo. Yo de momento estoy muy verde y no creo que pueda implementarlo, pero voy a ir haciendo intentos.
Y de momento ya está todo.
Por cierto, esto creo que empieza a ser "offtopic" en exceso, ¿Donde prefieres que te hagamos este tipo de cuestiones (si no te importa que te demos el coñazo, claro)? ¿En la web mojonia o abro un hilo en Programación?
- na_th_an
- Nonamed
- Mensajes: 1889
- Registrado: Lun May 07, 2007 10:16 am
- Ubicación: Andalucía
Re: IMPORTANTE - convocatoria de The Mojon Twins
En el beepola hemos usado el motor del Musicbox, que es el más sencillo y el que da menos problemas. También es el que suena menos "guay", pero bueno.
Los sonidos los hacemos con BeepFX de Shiru. Lo malo es que el ensamblador que saca esta aplicación es raruno y hay que adaptarlo bastante (usa etiquetas locales, por ejemplo, y código automodificable, pero tampoco es tan complicado).
Usar máscaras haría que no diera tiempo a actualizar los tres sprites durante el borde, con lo que habría parpadeos. Para poder hacerlo habría que usar un buffer intermedio y hacer volcados, o quizá montar un sistema de dirty rectangles (orientado a caracter, por ejemplo, y marcar los caracteres que hay que actualizar en pantalla). Además está el problema de que se mezclarían los colores.
Los sonidos los hacemos con BeepFX de Shiru. Lo malo es que el ensamblador que saca esta aplicación es raruno y hay que adaptarlo bastante (usa etiquetas locales, por ejemplo, y código automodificable, pero tampoco es tan complicado).
Usar máscaras haría que no diera tiempo a actualizar los tres sprites durante el borde, con lo que habría parpadeos. Para poder hacerlo habría que usar un buffer intermedio y hacer volcados, o quizá montar un sistema de dirty rectangles (orientado a caracter, por ejemplo, y marcar los caracteres que hay que actualizar en pantalla). Además está el problema de que se mezclarían los colores.
- Alxinho
- Freddy Hardest
- Mensajes: 896
- Registrado: Mar Jun 19, 2007 11:20 am
- Ubicación: Barcelona
- Contactar:
Re: IMPORTANTE - convocatoria de The Mojon Twins
Otra consultilla ...
¿Qué leches le pasa a la función ATTR en Basic Compiler?
Yo la añado al programa con #include y me dice que el archivo attr.bas tiene este problema en la linea 97:
"attr.bas:97:warning:FUNCTION 'attraddr' declared as FALLCAST with 2 parameters"
Yo la manera de usarla en el programa es igual que el basic normal --> IF ATTR(y,x)=0 THEN ...
y no hay manera ... es que el problema me lo da en propio attr.bas y no sé que puede ser
¿Qué leches le pasa a la función ATTR en Basic Compiler?
Yo la añado al programa con #include y me dice que el archivo attr.bas tiene este problema en la linea 97:
"attr.bas:97:warning:FUNCTION 'attraddr' declared as FALLCAST with 2 parameters"
Yo la manera de usarla en el programa es igual que el basic normal --> IF ATTR(y,x)=0 THEN ...
y no hay manera ... es que el problema me lo da en propio attr.bas y no sé que puede ser
Retrobytes Productions --> http://retrobytesproductions.blogspot.com.es
Soy un tío feliz, más que nada ... porque me sale más a cuenta.
Soy un tío feliz, más que nada ... porque me sale más a cuenta.
- wilco2009
- Freddy Hardest
- Mensajes: 543
- Registrado: Lun Sep 17, 2012 9:40 am
- Ubicación: Valencia
Re: IMPORTANTE - convocatoria de The Mojon Twins
Alxinho escribió:Otra consultilla ...
¿Qué leches le pasa a la función ATTR en Basic Compiler?
Yo la añado al programa con #include y me dice que el archivo attr.bas tiene este problema en la linea 97:
"attr.bas:97:warning:FUNCTION 'attraddr' declared as FALLCAST with 2 parameters"
Yo la manera de usarla en el programa es igual que el basic normal --> IF ATTR(y,x)=0 THEN ...
y no hay manera ... es que el problema me lo da en propio attr.bas y no sé que puede ser
El error que da es sólo un warning pero debería funcionar correctamente.
Las funciones FASTCALL teoricamente se deben usar para pasar un sólo parámetro a una función en ensamblador y consiste en que el parámetro que le pasas se copia en el registro a si es un parámetro de un byte y el el registro HL si es un parámetro de dos bytes.
Para funciones con más parámetros hay que recurrir a la pila comenzando en SP+4, aunque el ZXBasic de Boriel te deja asignado el registro IX apuntando a la cima de la pila para facilitar el acceso, de tal forma que el primer parámetro lo tienes en [IX+4].
El compilador se queja por que la FASTCALL no esta pensada para eso, pero resulta que como son dos parámetros de tamaño byte el primer parámetro está copiado en el registro A y el segundo parámetro lo recupera de la pila.
- Alxinho
- Freddy Hardest
- Mensajes: 896
- Registrado: Mar Jun 19, 2007 11:20 am
- Ubicación: Barcelona
- Contactar:
Re: IMPORTANTE - convocatoria de The Mojon Twins
Pufff .... yo de asm ni jota idea pero si dices que no pasa nada y debería funcionar ... aunque salirme siempre este mensaje queda un poco feo ...
Retrobytes Productions --> http://retrobytesproductions.blogspot.com.es
Soy un tío feliz, más que nada ... porque me sale más a cuenta.
Soy un tío feliz, más que nada ... porque me sale más a cuenta.
¿Quién está conectado?
Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 14 invitados