Temas AGD
Re: Temas AGD
Alucinante, la v43A4 tiene estrellas y explosiones así que en la máquina real adolece de los mismos síntomas.
No queda 'clavada' en ningún momento, pero me ha pasado algo mas raro todavía.
Al subir por las pseudoescaleras azules, cuando llega arriba de la pantalla y presenta la pantalla de arriba, no se ve el jugador, y al cabo de
un rato vuelve a salir, pero me ha descontado una vida y esto sucede cada vez
Me extraña que la transmisión del disco haya provocado una corrupción tan curiosa, a saber que pasa
Voy a probar la v43 que solamente tenía la explosión al perder una vida
saludos
No queda 'clavada' en ningún momento, pero me ha pasado algo mas raro todavía.
Al subir por las pseudoescaleras azules, cuando llega arriba de la pantalla y presenta la pantalla de arriba, no se ve el jugador, y al cabo de
un rato vuelve a salir, pero me ha descontado una vida y esto sucede cada vez
Me extraña que la transmisión del disco haya provocado una corrupción tan curiosa, a saber que pasa
Voy a probar la v43 que solamente tenía la explosión al perder una vida
saludos
Re: Temas AGD
Hola,
la v43 'pelada' muestra estrellas en las cuatro direcciones perfectamente sin problema alguno. Algo es algo
En ningún momento se ha clavado el juego incluso diría que se nota levemente mas rápido!
La explosión al perder una vida se muestra correctamente si bien las partículas tardan en salir de pantalla sobre todo si te pillan muy cerca de los bordes de pantalla y por tanto cuando aparece el jugador de nuevo, todavía quedan algunas alejándose hacia los bordes ...
Mañana con tranquilidad voy a ir pasando varias versiones posteriores a la v43 para ver en que momento se empiezan a producir problemas ...
saludos
la v43 'pelada' muestra estrellas en las cuatro direcciones perfectamente sin problema alguno. Algo es algo
En ningún momento se ha clavado el juego incluso diría que se nota levemente mas rápido!
La explosión al perder una vida se muestra correctamente si bien las partículas tardan en salir de pantalla sobre todo si te pillan muy cerca de los bordes de pantalla y por tanto cuando aparece el jugador de nuevo, todavía quedan algunas alejándose hacia los bordes ...
Mañana con tranquilidad voy a ir pasando varias versiones posteriores a la v43 para ver en que momento se empiezan a producir problemas ...
saludos
Re: Temas AGD
Buenos días,
he estado haciendo unas cuantas pruebas mas.
Formateé 10 disquetes y luego envié via cable FT245 10 versiones del juego al FM77AV para irlos grabando en discos distintos.
Las versiones enviadas son:
v43, v43A1, v43A3, v43A4, v44, v44A1, v44A2, v45, v45A1, v45A2
De momento llevo probadas las seis primeras, luego haré las otras cuatro pero ya se de antemano que van fatal
Los resultados 'visibles' han sido estos:
- v43 muestra estrellas multicolor y produce explosiones - funciona CORRECTAMENTE
- v43A1 añade 'cola/trail' . . . . . . . . . . . . . . . . . . . . . . . . funciona CORRECTAMENTE
- v43A3 cambio orden ProShr/VSync, partículas 2x . . . . . . . . Cola no desaparece bien. Estrellas al llegar a final reaparecen al otro lado
- v43A4 ya no muestra 'cola/trail' . . . . . . . . . . . . . . . . . . Las partículas en general van fatal
- v44 añade algunos Efectos . . . . . . . . . . . . . . . . . . . . . Partículas MAL y produce mini-colgadas (queda congelado 1-2 segundos)
- v44A1 algún efecto mas . . . . . . . . . . . . . . . . . . . . . . . . lo mismo que el anterior. Mal partículas, se cuelga
- v44A2 cambio efectos asignados. Eliminado 1 scroll . . . . . ???
- v45 cambio partículas a solo cuatro colores . . . . . . . . . ???
- v45A1 cambios en Rayo. Elimina partículas si pierde vida . . ???
- v45A2 corrige errores sonido al pisar suelo . . . . . . . . . . . Mal partículas, se cuelga (fue cuando vi los errores por primera vez)
saludos
he estado haciendo unas cuantas pruebas mas.
Formateé 10 disquetes y luego envié via cable FT245 10 versiones del juego al FM77AV para irlos grabando en discos distintos.
Las versiones enviadas son:
v43, v43A1, v43A3, v43A4, v44, v44A1, v44A2, v45, v45A1, v45A2
De momento llevo probadas las seis primeras, luego haré las otras cuatro pero ya se de antemano que van fatal
Los resultados 'visibles' han sido estos:
- v43 muestra estrellas multicolor y produce explosiones - funciona CORRECTAMENTE
- v43A1 añade 'cola/trail' . . . . . . . . . . . . . . . . . . . . . . . . funciona CORRECTAMENTE
- v43A3 cambio orden ProShr/VSync, partículas 2x . . . . . . . . Cola no desaparece bien. Estrellas al llegar a final reaparecen al otro lado
- v43A4 ya no muestra 'cola/trail' . . . . . . . . . . . . . . . . . . Las partículas en general van fatal
- v44 añade algunos Efectos . . . . . . . . . . . . . . . . . . . . . Partículas MAL y produce mini-colgadas (queda congelado 1-2 segundos)
- v44A1 algún efecto mas . . . . . . . . . . . . . . . . . . . . . . . . lo mismo que el anterior. Mal partículas, se cuelga
- v44A2 cambio efectos asignados. Eliminado 1 scroll . . . . . ???
- v45 cambio partículas a solo cuatro colores . . . . . . . . . ???
- v45A1 cambios en Rayo. Elimina partículas si pierde vida . . ???
- v45A2 corrige errores sonido al pisar suelo . . . . . . . . . . . Mal partículas, se cuelga (fue cuando vi los errores por primera vez)
saludos
Re: Temas AGD
Revisando desde la v43 en adelante, se puede jugar bien con todas hasta llegar a la v44. Aquí empiezan las cosas raras aunque en el emulador lo único que se detecta es que con los efectos habilitados, algunas partículas de las explosiones no son borradas y por tanto se quedan en la pantalla.
La pantalla con los tres 'rayos' es un buen lugar para ver este problema.
Deshabilitando los efectos, va como la seda y sigo refiriéndome al emulador claro.
En el fichero fuente hay un indicador/flag 'EFLAG' que se puede poner a 1 para tener efectos o a cero para evitarlos
Por comodidad he compilado dos veces para tener dos discos para hacer las pruebas, son
FM77DISKEF.d77 y FM77DISKNE.d77 el primero con efectos el segundo sin ellos.
He buscado las tres llamadas a funciones de efectos y les he puesto al principio que deshabiliten el MMR y al final que lo habiliten de nuevo.
No ha sido suficiente. Está claro que los efectos afectan de alguna manera a las partículas.
He comentado la parte de Proceso de partículas para que no se salte ningún /FS ahora cada vez hace la mitad de partículas, pero ni así mejora el proceso de las mismas
Os adjunto la versión v44R con los dos discos incluídos
Cualquier idea será bien recibida
saludos
NOTA. En esta versión todavía tenemos las partículas con 16 colores y por lo tanto usamos los ficheros de gráficos antiguos
La pantalla con los tres 'rayos' es un buen lugar para ver este problema.
Deshabilitando los efectos, va como la seda y sigo refiriéndome al emulador claro.
En el fichero fuente hay un indicador/flag 'EFLAG' que se puede poner a 1 para tener efectos o a cero para evitarlos
Por comodidad he compilado dos veces para tener dos discos para hacer las pruebas, son
FM77DISKEF.d77 y FM77DISKNE.d77 el primero con efectos el segundo sin ellos.
He buscado las tres llamadas a funciones de efectos y les he puesto al principio que deshabiliten el MMR y al final que lo habiliten de nuevo.
No ha sido suficiente. Está claro que los efectos afectan de alguna manera a las partículas.
He comentado la parte de Proceso de partículas para que no se salte ningún /FS ahora cada vez hace la mitad de partículas, pero ni así mejora el proceso de las mismas
Os adjunto la versión v44R con los dos discos incluídos
Cualquier idea será bien recibida
saludos
NOTA. En esta versión todavía tenemos las partículas con 16 colores y por lo tanto usamos los ficheros de gráficos antiguos
Re: Temas AGD
Hola,
después de bastantes pruebas, he llegado a la v46 que, en el emulador, no deja partículas congeladas y parece ir bien en general
La diferencia, casi la única, respecto la versión anterior es que no tiene el código que deshabilita el MMR a la entrada y lo habilita a la salida de tres funciones de efectos.
Sorprendentemente, al incluir este código es cuando algunas partículas no son borradas. Solo he visto que pase esto con los rayos, especialmente en la pantalla donde hay tres de ellos
Os adjunto la v46 y creo que antes de ponernos con la música convendría optimizar algunas funciones/subrutinas.
Como siempre, no se por donde empezar
¿Podrías mirar cuales son las rutinas mas empleadas, César? Me refiero a las que hacen 'algo', no a las que esperan pacientemente
muchas gracias
saludos
después de bastantes pruebas, he llegado a la v46 que, en el emulador, no deja partículas congeladas y parece ir bien en general
La diferencia, casi la única, respecto la versión anterior es que no tiene el código que deshabilita el MMR a la entrada y lo habilita a la salida de tres funciones de efectos.
Sorprendentemente, al incluir este código es cuando algunas partículas no son borradas. Solo he visto que pase esto con los rayos, especialmente en la pantalla donde hay tres de ellos
Os adjunto la v46 y creo que antes de ponernos con la música convendría optimizar algunas funciones/subrutinas.
Como siempre, no se por donde empezar
¿Podrías mirar cuales son las rutinas mas empleadas, César? Me refiero a las que hacen 'algo', no a las que esperan pacientemente
muchas gracias
saludos
Re: Temas AGD
Capturado en la pantalla de los rayos con muerte incluida por uno de ellos (para tener un poco de todo, sonido, efectos..)
Código: Seleccionar todo
MAIN
34.36% realvsync
31.58% HALT
5.96% Plot
3.90% Send2FM
3.62% SkTyp
3.56% BSort
1.79% DSpr
1.90% SSpriB
SUB
29.98% DNLine
Estos dias estoy dandole vueltas al tema de profiling, ya que no creo que refleje la realidad. Quiero decir, matematicamente si lo hace, pero es un modelo muy simplista que no parece apropiado para una maquina como esta y un motor como el AGD.
Me explico: para empezar tenemos una carga variable, los frames no son constantes. Los pares tienen una determinada carga, los impares otra, y si se alinean los astros con TIMER, otra. Los tiempos de pintado de sprites no dependen solo de la cantidad de sprites a mostrar, sino que ademas dependen (mucho) de la posicion X donde se pinten, y de si alguno parpadea o no. Los tiempos de espera en HALT (gastos de sincronizacion con SUB) se reparten entre las diversas funciones que lo llamen.
Por tanto tenemos tiempos de frame que van desde extremadamente sobrados, a tiempos de frame que se pasan de los 29000 ciclos (aprox) de que dispone MAIN para pintar cualquier frame si no quiere perderse un VSync. El worst case scenario realmente es muy worst, ya que son muchas variables que si se alinean, KABOOM. Mezclese con sincronias de SUB para tener un bonito panorama.
Y para rematar, el profiling suaviza los extremos, dando una media en el tiempo que es en ultima instancia precisa, pero cuya interpretacion directa da lugar a equivocos. He intentado minimizarla reduciendo al maximo la ventana de profiling, pero aun asi los worst case...
He estado dandole vueltas y mas vueltas (ya los tengo mareados ) a los dos problemas, el de la tremenda variabilidad en algunas rutinas (DNLine se lleva la palma) y a un modelo mas preciso de profiling adecuado a lo que tenemos. De momento tengo algunas ideas, que necesitan del maldito tiempo para ver si conducen a algun sitio o son callejones sin salida
PD: Y si se me permite la opinion, el codigo tiene de todo menos "grasa" , asi que no se de donde vas a rascar.
PC 386
Re: Temas AGD
Pere, si vas a ponerte a optimizar, una de las cosas que siempre he pensado que estaria bien seria una pantalla dummy, editada a manija, de tal forma que cuando empieces el juego aparezcas alli, tengas muchos sprites (mas de los que solemos tener), con parpadeos y estrellitas y lo que haga falta, y en la que no sea necesario siquiera mover el personaje. Con una carga tal que haga que claramente se hunda el framerate.
De esa forma, con una pantalla asi, creo que te seria mas sencillo y rapido notar mejorias en los cambios que hagas.
Otra idea que no he podido probar todavia, pero lo comento aprovechando la coyuntura, es sobre el tema del balanceo de sprites: actualmente se ordena la lista de sprites por coordenada Y por el tema de que al pintar directamente sobre framebuffer visible, si queremos evitar problemas con el raster, es preferible hacerlo asi.
Y luego esa lista se distribuye entre los frames par e impar en un fifty-fifty (donde o dibujan lo mismo o el par dibuja como mucho uno mas). Hasta aqui, bien.
Pero claro, el tiempo de pintado de esos sprites no es equivalente en todos los casos. Los de coord X mod 8 = 0 de dibujan rapido, los de X mod 8 = 2/6 mas lentos, y los de X mod 8 = 4 los mas lentos. La diferencia puede ser muy grande entre ambos frames (mal balanceo) en funcion de las coordenadas X.
¿Deberia el BSort ordenar por X? Pues no lo se realmente, pero si que interesaria balancear al maximo la carga entre frames par e impar para minimizar picos en cualquiera de los dos, y que hubiese una cantidad lo mas identica posible de sprites lentos, medios y rapidos en ambos.
De esa forma, con una pantalla asi, creo que te seria mas sencillo y rapido notar mejorias en los cambios que hagas.
Otra idea que no he podido probar todavia, pero lo comento aprovechando la coyuntura, es sobre el tema del balanceo de sprites: actualmente se ordena la lista de sprites por coordenada Y por el tema de que al pintar directamente sobre framebuffer visible, si queremos evitar problemas con el raster, es preferible hacerlo asi.
Y luego esa lista se distribuye entre los frames par e impar en un fifty-fifty (donde o dibujan lo mismo o el par dibuja como mucho uno mas). Hasta aqui, bien.
Pero claro, el tiempo de pintado de esos sprites no es equivalente en todos los casos. Los de coord X mod 8 = 0 de dibujan rapido, los de X mod 8 = 2/6 mas lentos, y los de X mod 8 = 4 los mas lentos. La diferencia puede ser muy grande entre ambos frames (mal balanceo) en funcion de las coordenadas X.
¿Deberia el BSort ordenar por X? Pues no lo se realmente, pero si que interesaria balancear al maximo la carga entre frames par e impar para minimizar picos en cualquiera de los dos, y que hubiese una cantidad lo mas identica posible de sprites lentos, medios y rapidos en ambos.
PC 386
Re: Temas AGD
En la actualidad no estamos usando las tablas pre-desplazadas. Esto hace que el caso de shift=4 tarde el doble de cuando shift=2 o 6 y el caso ideal de shift=0 es casi gratisjimbobaby escribió: ↑05 Oct 2024 17:28 Capturado en la pantalla de los rayos con muerte incluida por uno de ellos (para tener un poco de todo, sonido, efectos..)He estado dandole vueltas y mas vueltas (ya los tengo mareados ) a los dos problemas, el de la tremenda variabilidad en algunas rutinas (DNLine se lleva la palma) y a un modelo mas preciso de profiling adecuado a lo que tenemos. De momento tengo algunas ideas, que necesitan del maldito tiempo para ver si conducen a algun sitio o son callejones sin salidaCódigo: Seleccionar todo
MAIN 34.36% realvsync 31.58% HALT 5.96% Plot 3.90% Send2FM 3.62% SkTyp 3.56% BSort 1.79% DSpr 1.90% SSpriB SUB 29.98% DNLine
Me volveré a mirar con el LWASM los 'costes' en ciclos del sistema actual respecto al que usa las tablas (en Spectrum)
Pues no pensaba 'reducir' código actual sinó mas bien analizar que hacen las rutinas mas consumidoras de ciclos y tratar de rehacerlas de cero. A veces un replanteamiento puede obrar milagros. En realidad lo que suelo hacer es 'convertir' el código Z80 línea a línea y al revisar que no haya errores trato de aprovechar recursos de direccionamiento del 6809 y poco mas. Y al pasar del V9958 al FM77AV ya ni estoPD: Y si se me permite la opinion, el codigo tiene de todo menos "grasa" , asi que no se de donde vas a rascar.
saludos
Re: Temas AGD
Pensando en voz alta ...jimbobaby escribió: ↑05 Oct 2024 17:43 Otra idea que no he podido probar todavia, pero lo comento aprovechando la coyuntura, es sobre el tema del balanceo de sprites: actualmente se ordena la lista de sprites por coordenada Y por el tema de que al pintar directamente sobre framebuffer visible, si queremos evitar problemas con el raster, es preferible hacerlo asi.
Y luego esa lista se distribuye entre los frames par e impar en un fifty-fifty (donde o dibujan lo mismo o el par dibuja como mucho uno mas). Hasta aqui, bien.
Pero claro, el tiempo de pintado de esos sprites no es equivalente en todos los casos. Los de coord X mod 8 = 0 de dibujan rapido, los de X mod 8 = 2/6 mas lentos, y los de X mod 8 = 4 los mas lentos. La diferencia puede ser muy grande entre ambos frames (mal balanceo) en funcion de las coordenadas X.
¿Deberia el BSort ordenar por X? Pues no lo se realmente, pero si que interesaria balancear al maximo la carga entre frames par e impar para minimizar picos en cualquiera de los dos, y que hubiese una cantidad lo mas identica posible de sprites lentos, medios y rapidos en ambos.
Podemos ordenar por posX en lugar de PosY pero no ganaremos nada, seguro.
Podríamos incluso ordenar por posX & $07 para ordenar por el shift que se le va a aplicar, pero no se si esto va a equilibrar la carga en los dos pasos
en que se muestran los Sprites y hay que considerar que tal comparación añadirá algunas líneas código adicionales . En los otros dos motores que convertí, para el MC6847 y para el V9958 *NO* llamo a la rutina BSort y le dejo los ciclos al resto de subrutinas, no se si aquí también saldríamos ganando eliminándola del todo (?)
saludos
Re: Temas AGD
Un trabajo que vamos dejando para otro milenio es el tema de las paginaciones usando el registro MSR y teniendo preparadas cuatro posibles combinaciones de datos en cada una de ellas. Somos unos procrastinadores empedernidos
Además, como parece que el motor mas el script AGD compilado nunca pasará de $6FFF pues podríamos usar la página $7000-$7FFF, como dijo César en su momento, para tener un bloque extra ya preparado. Requerirá algún ajuste de valores para acceder a los datos en esta página, pero puede que nos ayude.
Voy a hacer una sesión de debug esta tarde, si puedo, poniendo un Breakpoint delante de cada función en la que al entrar se mapea algo.
A ver si puedo anotarlo todo, es decir que hay paginado cuando se llega ahí y que queda paginado al salir o antes de deshabilitar el MMR
Tal vez así podamos agrupar las funciones por 'uso' de datos y seamos capaces de definir las cuatro combinaciones que nos permite el MSR
saludos
Además, como parece que el motor mas el script AGD compilado nunca pasará de $6FFF pues podríamos usar la página $7000-$7FFF, como dijo César en su momento, para tener un bloque extra ya preparado. Requerirá algún ajuste de valores para acceder a los datos en esta página, pero puede que nos ayude.
Voy a hacer una sesión de debug esta tarde, si puedo, poniendo un Breakpoint delante de cada función en la que al entrar se mapea algo.
A ver si puedo anotarlo todo, es decir que hay paginado cuando se llega ahí y que queda paginado al salir o antes de deshabilitar el MMR
Tal vez así podamos agrupar las funciones por 'uso' de datos y seamos capaces de definir las cuatro combinaciones que nos permite el MSR
saludos
Re: Temas AGD
Efectivamente, no parece razonable decir que la CPU principal se pasa casi un 66% de su tiempo esperando una interrupción o que el SUB esté libre cuando está claro que nos faltan ciclos para que partículas y efectos no tengan problemas ...jimbobaby escribió: ↑05 Oct 2024 17:28 Capturado en la pantalla de los rayos con muerte incluida por uno de ellos (para tener un poco de todo, sonido, efectos..)Pero no me gusta la respuestaCódigo: Seleccionar todo
MAIN 34.36% realvsync 31.58% HALT 5.96% Plot 3.90% Send2FM 3.62% SkTyp 3.56% BSort 1.79% DSpr 1.90% SSpriB SUB 29.98% DNLine
Lo del realvsync me parece exagerado comparado con SSpriB dibujando los sprites.
Y si HALT se comiera tanto tiempo habría que saber que está haciendo el SUB mientras tanto. No es posible que con las pocas funciones 'delegadas' al SUB nos esté frenando a la CPU principal (?)
saludos
Re: Temas AGD
Hola,
al fin acabé el tema de anotar los mapeos que requiere cada parte del motor AGD
Os adjunto un fichero de texto con los resultados y además el fichero de la compilación FM77CODE.LST que he utilizado para ir
verificando como pagina cada función.
Ahora hay que 'buscar' tres o máximo cuatro combinaciones de páginas para asociarlas a los posibles valores de MSR (0-1-2-3)
A ver si mas tarde puedo echarle una ojeada
Se aceptan propuestas o ideas al respecto
saludos
al fin acabé el tema de anotar los mapeos que requiere cada parte del motor AGD
Os adjunto un fichero de texto con los resultados y además el fichero de la compilación FM77CODE.LST que he utilizado para ir
verificando como pagina cada función.
Ahora hay que 'buscar' tres o máximo cuatro combinaciones de páginas para asociarlas a los posibles valores de MSR (0-1-2-3)
A ver si mas tarde puedo echarle una ojeada
Se aceptan propuestas o ideas al respecto
saludos
Re: Temas AGD
por si alguien quiere mirar el tema de los mapeos, adjunto aquí el último mapa de memoria del motor AGD
saludos
saludos
Re: Temas AGD
Después de unas cuantas simplificaciones, lo mas que he conseguido es agrupar las funciones en cuatro bloques.
Para ello tendría que modificar las definiciones de algunas direcciones de datos al principio del fichero FM77CODE, pero parece factible.
Si no voy equivocado, estos cuatro mapeos preestablecidos permitirían cambiar de uno a otro y en ningún caso sería necesario hacer cambios
para poder trabajar. Obviamente las rutinas que dibujan en VRAM necesitarán paginar las páginas 10 hasta 17 de dos en dos como hasta ahora
Pero como usan los 'slots' $0C-$0D no afectan en ningún caso.
Con estos cambios se podrán eliminar las líneas de código añadidas para guardar ciertas páginas y reponerlas al finalizar como se ven obligadas a hacer las funciones que son llamadas desde el script AGD y desde el motor ...
Ahora lo que hay que estudiar es como activar - desactivar el MMR al inicio y final de cada función al tiempo que seleccionamos el MSR apropiado, sin olvidar habilitar el acceso a la VRAM cuando sea necesario. Esto último entiendo que requiere, forzosamente, que el SUB esté parado y por tanto al salir de la función habría que liberarlo tras deshabilitar el acceso a VRAM.
Se siguen admitiendo ideas, comentarios al respecto
saludos
Para ello tendría que modificar las definiciones de algunas direcciones de datos al principio del fichero FM77CODE, pero parece factible.
Si no voy equivocado, estos cuatro mapeos preestablecidos permitirían cambiar de uno a otro y en ningún caso sería necesario hacer cambios
para poder trabajar. Obviamente las rutinas que dibujan en VRAM necesitarán paginar las páginas 10 hasta 17 de dos en dos como hasta ahora
Pero como usan los 'slots' $0C-$0D no afectan en ningún caso.
Con estos cambios se podrán eliminar las líneas de código añadidas para guardar ciertas páginas y reponerlas al finalizar como se ven obligadas a hacer las funciones que son llamadas desde el script AGD y desde el motor ...
Ahora lo que hay que estudiar es como activar - desactivar el MMR al inicio y final de cada función al tiempo que seleccionamos el MSR apropiado, sin olvidar habilitar el acceso a la VRAM cuando sea necesario. Esto último entiendo que requiere, forzosamente, que el SUB esté parado y por tanto al salir de la función habría que liberarlo tras deshabilitar el acceso a VRAM.
Se siguen admitiendo ideas, comentarios al respecto
saludos
Re: Temas AGD
está resultando lento y enrevesado esto de cambiar las páginas asignadas a algunas funciones. He visto que incluso el cargador FM77LDA2 queda afectado por los cambios deseados.
En este momento tengo realizados todos los cambios para conseguir que con cuatro bloques de MSR no haga falta paginar nada salvo la VRAM de pantalla por supuesto. He modificado la función MMRINI para que prepare los cuatro bloques de MSR con los nuevos valores.
Ahora tengo que ver donde ir añadiendo la selección de MSR e ir eliminando/comentando las líneas de código que mapean y/o guardan valores anteriores. Puede ser un buen berenjenal
Por si alguien quiere echarle una ojeada os subo la versión actual v46A2 y los mapeos correspondientes
saludos
En este momento tengo realizados todos los cambios para conseguir que con cuatro bloques de MSR no haga falta paginar nada salvo la VRAM de pantalla por supuesto. He modificado la función MMRINI para que prepare los cuatro bloques de MSR con los nuevos valores.
Ahora tengo que ver donde ir añadiendo la selección de MSR e ir eliminando/comentando las líneas de código que mapean y/o guardan valores anteriores. Puede ser un buen berenjenal
Por si alguien quiere echarle una ojeada os subo la versión actual v46A2 y los mapeos correspondientes
saludos
Re: Temas AGD
por fin
Con la versión v46A5 ya se utilizan los cuatro bloques del MSR y por lo tanto ya no se realiza ninguna paginación que no sea para ir dibujando
en la VRAM y siempre sobre los slots $0C-$0D.
Algunas funciones/subrutinas han quedado muy simplificadas al quitarles el código necesario para guardar páginas anteriores y paginar las requeridas
@jimbobaby
Aunque solo sea por saber si con esto se gana algo, ¿Podrías tratar de averiguar si vamos mejor de 'ciclos' libres?
¿Podría empeorar el rendimiento el hecho de usar el MSR?
muchas gracias, César
saludos
Con la versión v46A5 ya se utilizan los cuatro bloques del MSR y por lo tanto ya no se realiza ninguna paginación que no sea para ir dibujando
en la VRAM y siempre sobre los slots $0C-$0D.
Algunas funciones/subrutinas han quedado muy simplificadas al quitarles el código necesario para guardar páginas anteriores y paginar las requeridas
@jimbobaby
Aunque solo sea por saber si con esto se gana algo, ¿Podrías tratar de averiguar si vamos mejor de 'ciclos' libres?
¿Podría empeorar el rendimiento el hecho de usar el MSR?
muchas gracias, César
saludos