Karoshi MSX Community
05 de Julio de 2021, 12:56:39 pm *
Bienvenido(a), Visitante. Por favor, ingresa o regístrate.

Ingresar con nombre de usuario, contraseña y duración de la sesión
Noticias:
 
   Inicio   Ayuda Buscar Ingresar Registrarse  
Páginas: [1]
  Imprimir  
Autor Tema: Nuevas dudas sobre programación en ensamblador  (Leído 5018 veces)
0 Usuarios y 1 Visitante están viendo este tema.
Mr Matsusaka
Karoshi Newbie
*
Mensajes: 15


Email
« : 04 de Octubre de 2015, 10:58:06 pm »

Hola de nuevo,

Después de mas de un año de inactividad (debido al nacimiento de mi primer hijo) he vuelto con fuerza a la programación de este pequeño proyecto que estaba haciendo para MSX. Estoy bastante avanzado y resumiendo mucho solo me queda programar la lógica de dos jefes, algunos enemigos y el final del juego, a parte de resolver algunos bugs. Intentaré acabarlo antes de que llegue un hipotético segundo retoño y mi tiempo libre se reduzca literalmente a cero!

Mi duda es sobre las paginas en la memoria RAM.
En principio la configuración mas clásica es la de 4 paginas de 16 KB para ordenadores con un total de 64 KB de RAM. La primera pagina lleva la BIOS, la última las variables de nuestro programa, y las otras dos paginas de en medio se pueden rellenar con la parte ROM de nuestro programa. Al menos es así como lo he aprendido.

Si un programa va a tener mas de 32 KB de ROM (o 48 KB si se usa también la pagina para la BIOS) entonces hay que mapear la memoria para poder tener cartuchos mas grandes como los famosos Megaroms.

Mi duda viene en la manera en la que toda esta información en el cartucho es volcada durante la ejecución.
Se vuelca toda la ROM+RAM del cartucho en la RAM del ordenador? o solo la parte RAM?
En cuando hacemos un switch para cambiar la dirección de una pagina en una megarom, estamos cargando una parte de la ROM de cartucho a la RAM del ordenador con la nueva página o solo estamos cambiando un simple número?

Estoy planteándome cambiar a Megarom quisiera tener claro los conceptos.

Disculpadme si he dicho alguna barrabasada y muchas gracias de antemano!
En línea
theNestruo
Karoshi Lover
***
Mensajes: 236


Email
« Respuesta #1 : 05 de Octubre de 2015, 07:37:58 pm »

Yo no he llegado a intentar hacer MegaROMs, pero creo que te lo puedo explicar de forma sencilla con la memoria no mapeada. No hay volcado ninguno (o no tiene por qué haberlo). Voy a simplificar mucho así que lo mismo luego vienen "los que saben de verdad" y me crujen un poco, pero espero resultar instructivo.

Imagina una cuadrícula de 4x4:
- Cada fila es una página (0, 1, 2 y 3, que empiezan en $0000, $8000, $C000 y $E000 respectivamente).
- Cada columna sería un "slot": una columna llevaría la ROM del ordenador (BIOS + BASIC), otra llevaría la primera cartuchera, otra la segunda cartuchera y la última tendría la RAM.

Ahora bien: el ordenador sólo puede leer 4 casillas de la cuadrícula, una de cada fila. Pero puedes elegir qué es lo que se ve:
- BIOS-BASIC-RAM-RAM: típico al arrancar el ordenador sin cartuchos. Puede haber más RAM pero estaría "escondida" detrás de la BIOS y el BASIC.
- BIOS-ROM-ROM-RAM: típico de un juego de 32K que utilice la BIOS. El BASIC y la RAM (si la hay) están "escondidos".
- BIOS-BASIC-ROM-RAM: típico de un juego de 16K (o de una BASIC ROM).

¿Qué es cambiar de página? Imagina un juego de 48K que utilizara la BIOS. En algún momento necesitará cambiar la página 0 de BIOS a su ROM, copiar o descomprimir datos de una fase o músicas o lo que toque, y volver a poner la BIOS para seguir como antes.
Un MegaROM lo que te permite es tener muchas más posibilidades "propias" (es decir, de tu juego) para alguna(s) de las páginas. Simplificando mucho de nuevo, imagina que tu MegaROM tiene en la página 1 el código del juego y luego tienes varias páginas 2 con las diferentes fases: podrías ir poniendo una u otra según correspondiera. O tener datos comprimidos (que sacarías a RAM) y así podrías tener ahí el bucle principal del juego, etc.
En línea

theNestruo."Old BASIC programmers never die; they GOSUB but never RETURN."
Mr Matsusaka
Karoshi Newbie
*
Mensajes: 15


Email
« Respuesta #2 : 05 de Octubre de 2015, 10:30:43 pm »

Vamos, que al final los accesos son directos a la ROM del cartucho. Me ha quedado claro.
Supongo que en el caso de las casettes y los disquetes si que se tendrá que volcar todo en la RAM del ordenador, con lo que las restricciones serán mayores.
En línea
Mortimer
Karoshi Lover
***
Mensajes: 216


WWW
« Respuesta #3 : 06 de Octubre de 2015, 07:32:34 am »

Piensa que el ordenador no sabe si lo que tiene enchufado es un cartucho normal o un megarom. Simplemente va a buscar al slot dónde está el cartucho la información que necesita, y es el mapeador que va en el hardware de cartucho el que gestiona estas, digamos subpáginas, y da la lectura correcta.

Aquí tienes toda la info: http://bifi.msxnet.org/msxnet//tech/megaroms.html

Si no recuerdo mal el AsMSX gestiona automáticamente casi todo el trabajo de crear un megarom.

Y como dices, con cinta o disco tendrías que ir pasando a RAM el código antes de ejecutarlo.
En línea
SapphiRe_MSX
Visitante
« Respuesta #4 : 09 de Octubre de 2015, 03:16:57 pm »

Si un programa va a tener mas de 32 KB de ROM (o 48 KB si se usa también la pagina para la BIOS) entonces hay que mapear la memoria para poder tener cartuchos mas grandes como los famosos Megaroms.

No. Un juego en cartucho puede tener hasta 64k sin necesidad de mapper. Las páginas 1 y 2 estarían siempre ahí y la página 0 se podría alternar con la BIOS sin problema alguno. La página 3 pisaría la RAM, por lo que se puede usar para mantener cosas que no necesiten de RAM para ser usadas.

Pero es algo totalmente factible hacer un juego de 48K (por ejemplo QBIQS) o 64K (por ejemplo Arcomage) sin necesidad de pasar a MegaROM.

Después de mas de un año de inactividad (debido al nacimiento de mi primer hijo) he vuelto con fuerza a la programación de este pequeño proyecto que estaba haciendo para MSX. Estoy bastante avanzado y resumiendo mucho solo me queda programar la lógica de dos jefes, algunos enemigos y el final del juego, a parte de resolver algunos bugs. Intentaré acabarlo antes de que llegue un hipotético segundo retoño y mi tiempo libre se reduzca literalmente a cero!

Yo con los dos pequeñajos y el caos que fue el año pasado y este (aunque menos) no he tenido tiempo de nada. Con dos hijos el tiempo no se reduce a cero, experimentarás los números negativos y luego los imaginarios  Grin Grin Grin Grin Grin

En línea
theNestruo
Karoshi Lover
***
Mensajes: 236


Email
« Respuesta #5 : 09 de Octubre de 2015, 07:17:12 pm »

Un juego en cartucho puede tener hasta 64k sin necesidad de mapper. Las páginas 1 y 2 estarían siempre ahí y la página 0 se podría alternar con la BIOS sin problema alguno. La página 3 pisaría la RAM, por lo que se puede usar para mantener cosas que no necesiten de RAM para ser usadas-
Una pregunta, SapphiRe, ¿realmente se llega a usar lo de poner ROM en la página 3? Es decir, teóricamente todo "encaja", pero en la práctica supongo que: o bien juegas con dónde hay RAM y dónde está la pila (porque en cualquier momento puede haber ROM en cualquiera de las páginas), o bien haces algo que realmente no necesite RAM ni para volver... y ahí es donde a mi imaginación le cuesta llegar. ¿Qué se puede hacer ahí?

Es más, yo pensaba que las ROMs de 64kB lo que hacían era permitir paginar en alguna de las otras páginas.
En línea

theNestruo."Old BASIC programmers never die; they GOSUB but never RETURN."
Imanok
Karoshi Hero
*****
Mensajes: 626


« Respuesta #6 : 11 de Octubre de 2015, 05:23:23 pm »

Yo también estoy con una rom de 64kb y los últimos 16kb los uso de almacén de gráficos.

Lo que hago es un bucle donde quito la ram del slot3, selecciono ese banco de 16kb, cargo valores en registros, vuelvo a poner la ram, copio los valores de los registros en un buffer y vuelta a empezar.

Suena muy bruto, pero funciona perfectamente bien si lo haces en las transiciones (fuera del juego en sí).
En línea
theNestruo
Karoshi Lover
***
Mensajes: 236


Email
« Respuesta #7 : 11 de Octubre de 2015, 10:21:11 pm »

Pues lo he estado pensando y me he dado cuenta de que, efectivamente, como almacén de gráficos puede ser bastante fácil usarlo. Pseudocódigo:
Código:
; (código en las páginas 1 o 2)
; Subrutina (CALL) para volcar gráficos desde la página 3
; param hl, de, bc: igual que LDIRVM
LDIRVM_DESDE_PG3:
    ; ... código para poner ROM en PG3 (se perderá la pila)
    jp LDIRVM_PG3
SALIR_LDIRVM_PG3:
    ; ...código para restaurar RAM en PG3 (se recuperará la pila)
    ret

; (código en la página 3)
LDIRVM_PG3:
    ; ...rutina similar a LDIRVM con OUTs y djnz
    jp SALIR_LDIRVM_PG3 ; sustituye al ret porque no hay pila

; (datos en la página 3)
    .db ...
(todo esto lo digo sin haber mirado si efectivamente esas tres rutinas (poner ROM, restaurar RAM y LDIRVM) se pueden hacer efectivamente sin nada de RAM)
« Última modificación: 11 de Octubre de 2015, 10:22:44 pm por theNestruo » En línea

theNestruo."Old BASIC programmers never die; they GOSUB but never RETURN."
pitpan
Karoshi Forum's Guru
*******
Mensajes: 1812


« Respuesta #8 : 16 de Octubre de 2015, 10:19:16 pm »

El problema "gordo" de tener ROM en la página 3 (E000h - FFFFh) es que, salvo que hagamos algún invento, no tenemos pila. No teniendo pila, no se pueden hacer CALL/RET, pero siempre podremos sobrevivir a un JP.

Mucho cuidado también con las variables del sistema y con los vectores de interrupción, que se "reescriben" en la RAM alta. Tendríamos que hacerlo todo forzando siempre un DI como una casa, y verificando que las rutinas de la BIOS que utilicemos no nos hagan un EI en ningún momento. Y no quiero pensar en qué pueda suceder con dispositivos que tengan puertos mapeados en la RAM y cosas así de exóticas.

Pero sí, es factible. Lo que no veo es qué ganáis respecto al uso de un MegaROM. Un ROM de 48 KB sin mapper podría cargarse vía cassette o disco en un ordenador de 64 KB de RAM. Una ROM de 64 KB no Sad
En línea
Mortimer
Karoshi Lover
***
Mensajes: 216


WWW
« Respuesta #9 : 17 de Octubre de 2015, 10:21:43 am »

Yo hice alguna pruebecilla hace tiempo para copiar de ROM en página 3 a VRAM, y usé los registros alternativos para guardar la dirección de retorno y el estado original del registro de slots para poder restaurarlo, con interferencias de la BIOS no tenía problemas porque no la usaba.

También pensé en algo más rebuscado que no llegué a probar: Dejar la pila en ROM de la página 3, pero precargando los valores de retorno de forma que al hacer el RET hiciera el "POP" de la dirección correcta. Porque al menos en mi caso, la secuencia de llamadas siempre dejaba la pila en un estado previsible. Es decir, que el sistema hacía "PUSH" que no se grabarían porque eran en ROM, pero en la ROM ya estaría el valor del que estaba intentando escribir. Después, al volver a poner la página de RAM, la pila seguía funcionando tal cual.

Sobre lo que comenta pitpan de dispositivos con puertos mapeados en RAM, creo que si están bien hechos no debería haber problemas, porque no se seleccionarán al estar en otro SLOT que nuestro cartucho.

Y la ganancia, en mi caso era pensando en un hipotético futuro encartuchado físico, supongo que es más fácil y/o barato usar una ROM normal de 64K que una mapeada. ¿No?

Saludos!
« Última modificación: 17 de Octubre de 2015, 10:28:48 am por Mortimer » En línea
Páginas: [1]
  Imprimir  
 
Ir a:  

Impulsado por MySQL Impulsado por PHP Powered by SMF 1.1.21 | SMF © 2013, Simple Machines XHTML 1.0 válido! CSS válido!