Ver la versión completa : GP2Xpectrum1.6
EDICION 1: Esta es una versión para que la supervise MetalBrain. La versión definitiva y supervisada por MetalBrain se va a numerar como 1.5 y la subirá Metalbrain. Un saludo a todos.
EDICION 2: Ya esta disponible la version 1.5 final por MetalBrain:
La dirección es la de costumbre:
NOTA: Se ha corregido un bug sobre la 1.5: La buena es la 1.5.1 :)
http://www.speccy.org/metalbrain/GP2Xpectrum1.5.1.zip
Os subo la una nueva version del GP2Xpectrum para MetalBrain con los fuentes incluidos.
Si algún alma caritativa pudiera compilarlo con el el profiling de Notaz se lo agradeceria y podriamos incluir el ejecutable.
La lista de cambios es la siguiente:
- Corregido la emulación del sonido. Fixes del speaker (Sonidos polifónicos) y AY.Reescrito el código de acceso al DSP. Menos problemático y produce menos underrun.
- Añadido sonido stereo para el speaker y el AY.
- Selector de modo de sonido en el menu de configuración: Sin sonido, Mono, Stereo beeper, Stereo AY, Stereo Todo.
- Selector de frecuencia: 44100,32000,22050,11025KHz
- Selector de mute: Off,Low, High. Reduce la ganacia del sonido. Ideal para la F200... :)
- Selector de velocidad de emulacion: de -75% a + 75 %. Aumenta o reduce la velocidad original del spectrum. Para jugar a toda pastilla al ManicMiner :)
- Selector de FPS: Muestra los FPS.
- Selector de VSYNC: Activa el VSYNC.
- Corregido bug que no guardaba la configuración si no estabamos en la ruta por defecto.
- Actualizada la mmuhack.o
Nota: El sonido stereo consume mas recursos. Si oís petardeos probar a subir la velocidad del procesador o eligir otra configuración de sonido.
Un saludo.
Rivroner
20/01/2008, 22:09
Probándola ya mismo :)
Gracias monstruo ;)
Metalbrain
20/01/2008, 22:15
Os subo la una nueva version del GP2Xpectrum para MetalBrain con los fuentes incluidos.
Si algún alma caritativa pudiera compilarlo con el el profiling de Notaz se lo agradeceria y podriamos incluir el ejecutable.
La lista de cambios es la siguiente:
- Corregido la emulación del sonido. Fixes del speaker (Sonidos polifónicos) y AY.Reescrito el código de acceso al DSP. Menos problemático y produce menos underrun.
- Añadido sonido stereo para el speaker y el AY.
- Selector de modo de sonido en el menu de configuración: Sin sonido, Mono, Stereo beeper, Stereo AY, Stereo Todo.
- Selector de frecuencia: 44100,32000,22050,11025KHz
- Selector de mute: Off,Low, High. Reduce la ganacia del sonido. Ideal para la F200... :)
- Selector de velocidad de emulacion: de -75% a + 75 %. Aumenta o reduce la velocidad original del spectrum. Para jugar a toda pastilla al ManicMiner :)
- Selector de FPS: Muestra los FPS.
- Selector de VSYNC: Activa el VSYNC.
- Corregido bug que no guardaba la configuración si no estabamos en la ruta por defecto.
- Actualizada la mmuhack.o
Nota: El sonido stereo consume mas recursos. Si oís petardeos probar a subir la velocidad del procesador o eligir otra configuración de sonido.
Un saludo.
*****, la lista de cambios es alucinante. Lo único malo es que me has jodido la numeración de versiones, saltando a la 1.6 antes de que haya salido la 1.5 definitiva, pero no tiene mucha importancia.
*****, la lista de cambios es alucinante. Lo único malo es que me has jodido la numeración de versiones, saltando a la 1.6 antes de que haya salido la 1.5 definitiva, pero no tiene mucha importancia.
Ok. Me gustaba la 1.6 pero puedes ponerle la que quieras ;) Es por deformacion profesional del maven. 1.x.y donde y es bugfix y x son nuevas funcionalidades...
Un saludo.
Rivroner
20/01/2008, 22:25
Yo a esta la llamaría 1.5 beta5 :D Pues a la anterior de Seleuco la llamé 1.5 Beta 4 :D
De todas formas y viendo los cambios realizados es normal saltar a la 1.6 :)
Ahora cuando metáis la táctil y soporte total para TZX pues la llamáis 1.7 :D
Y por cierto, sé que no todos querrán esta opción, ¿pero sería posible que el emulador metiera una opción para carga de cintas a velocidad real, con sus ruiditos y todo :D ?
Gracias máquinas :)
zikitrake
20/01/2008, 22:25
óño! óño! óño!!! pa la esedé de cabeza! (y después el Caprice :))
(Apoyo la moción de River en lo de las cargas a tiempo real)
Yo a esta la llamaría 1.5 beta5 :D Pues a la anterior de Seleuco la llamé 1.5 Beta 4 :D
De todas formas y viendo los cambios realizados es normal saltar a la 1.6 :)
Ahora cuando metáis la táctil y soporte total para TZX pues la llamáis 1.7 :D
Y por cierto, sé que no todos querrán esta opción, ¿pero sería posible que el emulador metiera una opción para carga de cintas a velocidad real, con sus ruiditos y todo :D ?
Gracias máquinas :)
A mi lo del tzx me tienta... me parece lo único que le falta para ser completo,completo.... pero quiero hacer lo del teclado y luego relajarme un poco y disfrutar de los games que al fin y al cabo es lo importante o no? jeje
En cualquier caso he dejado preparado el emulata para que funcione el sonido del TAPE...
Un saludo.
PD: A mi las betas no me gustan... ni que fueramos google... :) podemos llamarla 1.5 y todos contentos :))
Y por cierto, sé que no todos querrán esta opción, ¿pero sería posible que el emulador metiera una opción para carga de cintas a velocidad real, con sus ruiditos y todo :D ?
Eso,y que haya que "jugar" con el volumen para que no te salga error cargando cinta:D
Eso,y que haya que "jugar" con el volumen para que no te salga error cargando cinta:D
y que salga un "R-TAPE loding error" de vez cuando :D
y que salga un "R-TAPE loding error" de vez cuando :D
Ahí está.Friquismo spectrumero:brindis:
Rivroner
20/01/2008, 22:53
¿Y por qué no? :) Lo de los errores mejor no :D ¿Pero lo otro?
¿Y por qué no? :) Lo de los errores menor no :D ¿Pero lo otro?
Imagínate cargar el The Vindicator y sus quince minutos de carga,se te acaban las pilas para cuando carga :D
Imagínate cargar el The Vindicator y sus quince minutos de carga,se te acaban las pilas para cuando carga :D
Cago en to... yo me acuerdo de un juego que solo me cargo una vez y mira que lo intenté con el azimut, por el mic, por el ear.....simpre al final a tomar por.... jeje.... para mi era el juego mas deseado... :) porque solo pude jugar una vez y ya era frustracción de la mala...
Rivroner
20/01/2008, 23:11
Imagínate cargar el The Vindicator y sus quince minutos de carga,se te acaban las pilas para cuando carga :D
Pues será en tu consola :D
En serio ahora, ¿no sería posible lo que digo? ¿No hay ningún emu de PC que tenga esta opción?
Por cierto, el Street Fighter 2 de Spectrum tardaba 20 minutos creo :D
Jan_Europa
20/01/2008, 23:17
Cago en to... yo me acuerdo de un juego que solo me cargo una vez y mira que lo intenté con el azimut, por el mic, por el ear.....simpre al final a tomar por.... jeje.... para mi era el juego mas deseado... :) porque solo pude jugar una vez y ya era frustracción de la mala...
en mi caso fue el Rocky Horror Picture Show, solo me cargó una vez... y lo seguí intentando durante años
Pues será en tu consola :D
En serio ahora, ¿no sería posible lo que digo? ¿No hay ningún emu de PC que tenga esta opción?
Por cierto, el Street Fighter 2 de Spectrum tardaba 20 minutos creo :D
En tiempo real me parece demasiado,pero una opción para que cargasen en diez segundos y así admirar esas pantallas de carga...lloraría y todo,oye
romeroca
20/01/2008, 23:19
Que recuerdos me habéis despertado.
PIIII-PI PIIII PIRI PIRI
y sus rayitas de colores en los bordes.
en mi caso fue el Rocky Horror Picture Show, solo me cargó una vez... y lo seguí intentando durante años
A mi me pasaba con el Rambo.
Metalbrain
20/01/2008, 23:25
PD: A mi las betas no me gustan... ni que fueramos google... :) podemos llamarla 1.5 y todos contentos :))
Pues me parece estupendo. Creo que en este foro no se puede editar el tema del mensaje, así que edita el mensaje y avisa bien gordo que la versión que hay que subir es la 1.5, que estoy a puntito de subir.
Metalbrain
20/01/2008, 23:54
OK Metal. hecho.
Perfecto, pues la dirección es la de costumbre:
http://www.speccy.org/metalbrain/GP2Xpectrum1.5.zip
Te he puesto como continuador junto a mi, porque lo tuyo no han sido simples parches: has mejorado el sonido de una forma bestial, has añadido un montón de opciones al menú y has corregido bugs, y vas a seguir haciendo cosas.
A mi lo del tzx me tienta... me parece lo único que le falta para ser completo,completo.... pero quiero hacer lo del teclado y luego relajarme un poco y disfrutar de los games que al fin y al cabo es lo importante o no? jeje
Pues mira, prisas en verdad no hay ninguna, así que tomate el tiempo que quieras, pero si te tienta, no lo pienses más: ADELANTE. Yo no tengo demasiado tiempo libre y el poco que tengo prefiero dedicarlo a programar juegos nuevos para Spectrum en CEZGS ( http://cezgs.computeremuzone.com/ ) , así que puedo ceder el mantenimiento digamos "oficial" de este emu. De todas formas tenía pensado cederselo a rlyeh en cuanto acabase mis asuntos pendientes (el teclado USB y rematar la emulación precisa de las demos).
Y bueno, pues ahora voy a anunciarlo por todos los sitios habituales.
Yeeeeik menos mal que te as acordado de mi metalbrain ya iba a activar el mecanismo de autodestruccion que te meti en el minicradle xD
Perfecto, pues la dirección es la de costumbre:
http://www.speccy.org/metalbrain/GP2Xpectrum1.5.zip
Te he puesto como continuador junto a mi, porque lo tuyo no han sido simples parches: has mejorado el sonido de una forma bestial, has añadido un montón de opciones al menú y has corregido bugs, y vas a seguir haciendo cosas.
Pues mira, prisas en verdad no hay ninguna, así que tomate el tiempo que quieras, pero si te tienta, no lo pienses más: ADELANTE. Yo no tengo demasiado tiempo libre y el poco que tengo prefiero dedicarlo a programar juegos nuevos para Spectrum en CEZGS ( http://cezgs.computeremuzone.com/ ) , así que puedo ceder el mantenimiento digamos "oficial" de este emu. De todas formas tenía pensado cederselo a rlyeh en cuanto acabase mis asuntos pendientes (el teclado USB y rematar la emulación precisa de las demos).
Y bueno, pues ahora voy a anunciarlo por todos los sitios habituales.
Muchas gracias MetalBrain. He actualizado el post al link de descarga. Implementaré el soporte del teclado para la F200, que no es complicado en si, sino que quede ergonomico y práctico. Teclado flotante, etc. Luego el tiempo dirá. Impresionante lo tuyo con el CEZGS, enhorabuena por tu estupendo trabajo.
Un saludo.
Rivroner
21/01/2008, 01:04
El sonido ahora es brutalmente bueno, yo pongo el emu a 220 y con todo a tope (44khz Estéreo All y Vsync Activado) y ningún juego de los probados baja de 50 :D
Muchísimas gracias :)
Pues será en tu consola :D
En serio ahora, ¿no sería posible lo que digo? ¿No hay ningún emu de PC que tenga esta opción?
Por cierto, el Street Fighter 2 de Spectrum tardaba 20 minutos creo :D
Prueba el realspectrum
Rivroner
21/01/2008, 03:26
Gracias, pero lo decía porque mangaran el código (si es abierto claro) no porque quiera un emu así en PC (suponía que ya existía). Yo lo quiero para la GP2X :)
Este tipo de cosillas ponedlas en este foro (http://www.gp32spain.com/foros/forumdisplay.php?f=91) mejor, que así podremos pasarlas a portada y ganaréis unos suculentos créditos. ;)
Hay una cantidad de juegos, pocos en realidad, que hacen uso del disco RAM del +2A para ejecutarse ¿podria añadirse la emulación de este modelo el +2a en proximas betas?
Un saludo
T.BRazil
Metalbrain
21/01/2008, 20:21
Hay una cantidad de juegos, pocos en realidad, que hacen uso del disco RAM del +2A para ejecutarse ¿podria añadirse la emulación de este modelo el +2a en proximas betas?
Creo que lo que es la emulación ya está, lo que no hay es reset a ese modelo, pero cargando un snapshot debería funcionar. Además, el disco RAM del +2A debe ser igual al del +3, así que también deberías poderlos ejecutar con imágenes de cinta.
Creo que lo que es la emulación ya está, lo que no hay es reset a ese modelo, pero cargando un snapshot debería funcionar. Además, el disco RAM del +2A debe ser igual al del +3, así que también deberías poderlos ejecutar con imágenes de cinta.
Hoy probaré el beastie Feastie de Beyker en el emulador a ver que hace y te comentaré :-)
Un saludo
T.BRazil
Metalbrain
22/01/2008, 01:55
- Corregido bug que no guardaba la configuración si no estabamos en la ruta por defecto.
No se si se ha quedado ahora peor que como estaba, o es un problema nuevo:
http://www.worldofspectrum.org/forums/showthread.php?p=239543#post239543
http://www.gp32x.com/board/index.php?s=&showtopic=40291&view=findpost&p=581858
Mucho curro hoy :( No son horas de volver a casa...
Reproducido. Mañana le echo un vistazo. En el curro el optenet de los C* nos capa todo lo relacionado con la gp2x. gp2x=games=filtro
Ya esta pillado. Realmente era un error de siempre de la rutina de carga de mconfig que no funciona bién y con las modificaciones nuevas hace que no se inicializen parametros criticos del sonido. El otro error que arregle, era que el mconfig se cargaba antes de leer el fichero ini y no tiene nada que ver con esto.
mira:
void load_mconfig()
{FILE *fp;
sprintf(pathstring,"%s/saves/gp2xpectrum.cfg",globalpath);
fp=fopen(pathstring,"rb");
if(fp==NULL) return;
mas cositas
si no existia mconfig salia y pasaba de todo el codigo de inicalizacion posterior, antes no era tan critico porque se perdian lo de la bateria y el contention y no seteaba el speed, pero ahora pierde parametros de inicialización del sonido.
deberia ser algo del tipo:
void load_mconfig()
{FILE *fp;
sprintf(pathstring,"%s/saves/gp2xpectrum.cfg",globalpath);
fp=fopen(pathstring,"rb");
int read=0;
if(fp!=NULL)
{
fread(&mconfig, 1, sizeof(mconfig), fp);
fclose(fp);
read=1;
}
if(mconfig.id!=0xABCD0009 || !read)
{
Te adjunto el fichero c corregido para que generes una version. Yo lo he llamado 1.5.1 (el 1 de bugfix)
PD: a dormir... jeje
Metalbrain
22/01/2008, 16:18
Gracias por el fix, compilado, subido y promocionando...
http://www.speccy.org/metalbrain/GP2Xpectrum1.5.1.zip
de ver que a mi vecino le costo lo suyo el spectrum
headoverheels
22/01/2008, 16:44
Gracias por el fix, compilado, subido y promocionando...
http://www.speccy.org/metalbrain/GP2Xpectrum1.5.1.zip
El código fuente está incluido? si os interesa puedo probar a compilarlo con profiling y os paso el binario.
Metalbrain
22/01/2008, 17:44
El código fuente está incluido? si os interesa puedo probar a compilarlo con profiling y os paso el binario.
Por mi estupendo, el código viene incluido.
Gracias por el fix, compilado, subido y promocionando...
http://www.speccy.org/metalbrain/GP2Xpectrum1.5.1.zip
OK. Aunque el problema deberia pasar también en la F100. Bueno con el fix se soluciona... a otra cosa....
El código fuente está incluido? si os interesa puedo probar a compilarlo con profiling y os paso el binario.
Eso sería una gran noticia. Ya me veia montando una distro de linux solo para eso ;) Muchas gracias por adelantado.
headoverheels
22/01/2008, 23:05
Ya le he enviado el binario a Metal. No sé si se ganará algo, porque tampoco he usado mucho las versiones anteriores y los juegos que he probado con esta me han ido todos a fullspeed.
Ya le he enviado el binario a Metal. No sé si se ganará algo, porque tampoco he usado mucho las versiones anteriores y los juegos que he probado con esta me han ido todos a fullspeed.
Thks mounstro... :) En algunos games con el stereo y si abres el teclado virtual si que habia bajones de frames... a ver cuanto se mejora...
Metalbrain
23/01/2008, 00:02
Ya le he enviado el binario a Metal. No sé si se ganará algo, porque tampoco he usado mucho las versiones anteriores y los juegos que he probado con esta me han ido todos a fullspeed.
Lo he estado probando y la ganancia no es demasiado espectacular, pero está ahí. Como a velocidades normales no se nota, primero hice una prueba con el Moggy (juego que usa el Wham! The Music Box para el sonido, ya que el sonido beeper es una de las cosas que más lentas se ejecutan), bajando la velocidad del procesador a 135MHz y comparando los FPS que se obtenían. La versión sin optimizar obtiene 37 y la optimizada 39. Luego hice otra prueba con el Tetris 2, poniendo la velocidad de emulación al 150%, y subiendo el procesador a 200 y 220 MHz. Sin optimizar se obtienen 64 fps a 200 y 71 a 220, y optimizado 68 y 75/76. Por lo tanto estimo una ganancia total en torno al 5%-7%.
Rivroner
23/01/2008, 00:09
Hombre, algo es algo, ya lo estás subiendo fiera :D
Por cierto, los "Ram Tweaks" no se los metéis?
Lo he estado probando y la ganancia no es demasiado espectacular, pero está ahí. Como a velocidades normales no se nota, primero hice una prueba con el Moggy (juego que usa el Wham! The Music Box para el sonido, ya que el sonido beeper es una de las cosas que más lentas se ejecutan), bajando la velocidad del procesador a 135MHz y comparando los FPS que se obtenían. La versión sin optimizar obtiene 37 y la optimizada 39. Luego hice otra prueba con el Tetris 2, poniendo la velocidad de emulación al 150%, y subiendo el procesador a 200 y 220 MHz. Sin optimizar se obtienen 64 fps a 200 y 71 a 220, y optimizado 68 y 75/76. Por lo tanto estimo una ganancia total en torno al 5%-7%.
Pues no esta mal.... no obstante creo que influye elbastante el path de ejecución al hacer el profiling... es decir seria bueno probar con el Moggy y hacer el profiling con el teclado virtual levantandolo de vez en cuando.
Hombre, algo es algo, ya lo estás subiendo fiera :D
Por cierto, los "Ram Tweaks" no se los metéis?
Ilustrame Rivroner con las Ram Tweaks que ya me pierdo.... :)
Rivroner
23/01/2008, 02:42
Pues muchas aplicaciones las llevan por defecto o te deja activarlos en el menú.
Se trata de modificar los parámetros de la Ram para tener cierta ganancia, los oficiales de Craigix eran estos:
--trc 6 --tras 4 --twr 1 --tmrd 1 --trfc 1 --trp 2 --trcd 2
De todas formas con el Gmenu2x se pueden activar a casi cualquier aplicación :) Y digo yo, si este emu es el más rápido del universo junto con el Alexkidd2X de Puck así que tampoco es necesario :D
Lo podéis hacer internamente con una opción o con un script de este tipo:
#!/bin/sh
./cpu_speed --upll --timing 1 --cpuclk 175 --trc 6 --tras 4 --twr 1 --tmrd 1 --trfc 1 --trp 2 --trcd 2
./gp2xpectrum.gpe
La velocidad del procesador la he puesto a 175 porque creo que con todo a tope (sonido stereo, vsync,..) y con lo del profiling y los tweaks no hace falta más :D
¡Pedazo de emu :)!
el siguiente codigo os deberia funcionar.
asi cambio yo el clock en la minimal 0.C (sin nada de codigo del cpuctrl de Hermes), y de paso hago los tweaks de ram:
/* Function: gp2x_dualcore_clock
This function sets the clock at ARM 920T coprocessor and RAM tweaks.
Note:
- Call this function only from your 920T program.
Parameters:
s (50,75,100,125,150,175,200,225,250) - Speed value in MHz. Default is 200.
Credits:
RobBrown, sasq and whizzbang (original clock setting code)
god_at_hell (original RAM tweaking code)
craigix, Emu&Co (tweaked RAM timing values) */
void gp2x_dualcore_clock(int s)
{
unsigned long interrupt_flags = gp2x_memregl[0x808>>2],
//tRC=7-1 if mhz > 266
//CAS=0,tRC=6-1,tRAS=3-1,tWR=1-1,tMRD=1-1,tRFC=1-1,tRP=1-1,tRCD=2-1; //emu&co's timings
CAS=0,tRC=6-1,tRAS=4-1,tWR=1-1,tMRD=1-1,tRFC=1-1,tRP=2-1,tRCD=2-1; //craigix's timings
//hardcoded values:
s=(s>=250?0x5D04:s>=225?0x5304:s>=200?0x4904:s>=175?0x3F04:s>=125?0x3c01:s>=100?0x6502:s>=75?0x4902:s>=50?0x6503:0);
if(s)
{
gp2x_memregl[0x0808>>2] = 0xFF8FFFE7; // Mask interrupts
gp2x_memregs[0x0910>>1] = s; // Set clock and wait
while(gp2x_memregs[0x0902>>1] & 1);
gp2x_memregs[0x3802>>1] = ((tMRD<<12)|(tRFC<<8)|(tRP<<4)|(tRCD)); //set RAM tweaks
gp2x_memregs[0x3804>>1] = ((CAS<<12)|(tRC<<8)|(tRAS<<4)|(tWR));
gp2x_memregs[0x0924>>1] = 0x8900 + ((1)<<8); // Set upll timing prescaler to 1 (0x5A00 for fw 1.0.x)
gp2x_memregl[0x0808>>2] = interrupt_flags; // Turn on interrupts
}
}
headoverheels
23/01/2008, 10:05
Pues no esta mal.... no obstante creo que influye elbastante el path de ejecución al hacer el profiling... es decir seria bueno probar con el Moggy y hacer el profiling con el teclado virtual levantandolo de vez en cuando.
El durante el profiling he utilizado bastante el teclado virtual y lo he configurado en stereo 44100, en cuanto al Moggy, ni idea de lo que es (os referís al juego de CEZ?)
Lo importante en el profiling es que los juegos que utilices para hacer el profiling utilicen de forma intensiva aquellas partes del código que más se deseen optimizar. Como no conozco los entresijos del emulador y los expertos sois vosotros, si me decís algun juego exigente que pueda usar, esta tarde cuando llegue a casa hago de nuevo el profiling.
Metalbrain
23/01/2008, 13:18
El durante el profiling he utilizado bastante el teclado virtual y lo he configurado en stereo 44100, en cuanto al Moggy, ni idea de lo que es (os referís al juego de CEZ?)
Si, ese mismo juego. Las ordenes OUT son de las que más tiempo de emulación se llevan, y cuando suena sonido de 48k, se producen muchas de ellas, por lo que las partes más sensibles a la velocidad suelen ser las músicas de los menús en 48k.
Lo importante en el profiling es que los juegos que utilices para hacer el profiling utilicen de forma intensiva aquellas partes del código que más se deseen optimizar. Como no conozco los entresijos del emulador y los expertos sois vosotros, si me decís algun juego exigente que pueda usar, esta tarde cuando llegue a casa hago de nuevo el profiling.
A ver si te mando esta tarde un paquete de juegos y demos que necesiten más optimización.
Pues muchas aplicaciones las llevan por defecto o te deja activarlos en el menú.
Se trata de modificar los parámetros de la Ram para tener cierta ganancia, los oficiales de Craigix eran estos:
--trc 6 --tras 4 --twr 1 --tmrd 1 --trfc 1 --trp 2 --trcd 2
De todas formas con el Gmenu2x se pueden activar a casi cualquier aplicación :) Y digo yo, si este emu es el más rápido del universo junto con el Alexkidd2X de Puck así que tampoco es necesario :D
Lo podéis hacer internamente con una opción o con un script de este tipo:
#!/bin/sh
./cpu_speed --upll --timing 1 --cpuclk 175 --trc 6 --tras 4 --twr 1 --tmrd 1 --trfc 1 --trp 2 --trcd 2
./gp2xpectrum.gpe
La velocidad del procesador la he puesto a 175 porque creo que con todo a tope (sonido stereo, vsync,..) y con lo del profiling y los tweaks no hace falta más :D
¡Pedazo de emu :)!
Eres un pozo de sabiduria Rivroner. mas o menos cambiar los timings de las memorias, pero en vez de en la bios del PC por código. Me encanta todo los tweaks de la gp2x, como se lo curra la gente para exprimir al maximo el Hw. Solo me pregunto... ¿Nos e quemará ninguna consola con tanto overcloking? :)
PD: Thks Rlyeh probaré tu código. Haré alguna prueba.... :brindis:
Por cierto Rivroner, referente al tema de cargar programas como en el spectrum original, el tzx es basicamente eso. Normalmente se mete un trap en la rutina de carga de la rom para acelerar el proceso, pero si hay problemas o en los modos turbo, lo que se hace es leer los pulsos directamente y dejar que los interprete la rom o las rutinas de carga del speedlock incluso se manda al beeper para que suene... hare alguna prueba este finde a ver si me sale algo.
Rivroner
24/01/2008, 02:38
Eres un pozo de sabiduria Rivroner. mas o menos cambiar los timings de las memorias, pero en vez de en la bios del PC por código. Me encanta todo los tweaks de la gp2x, como se lo curra la gente para exprimir al maximo el Hw. Solo me pregunto... ¿No se quemará ninguna consola con tanto overcloking? :)
Que va hombre, es sólo de leer este foro y gp32x durante casi 2 años, que a uno se le quedan las cosas :D
No se quema nada, lo único las pilas :D
Por cierto Rivroner, referente al tema de cargar programas como en el spectrum original, el tzx es basicamente eso. Normalmente se mete un trap en la rutina de carga de la rom para acelerar el proceso, pero si hay problemas o en los modos turbo, lo que se hace es leer los pulsos directamente y dejar que los interprete la rom o las rutinas de carga del speedlock incluso se manda al beeper para que suene... hare alguna prueba este finde a ver si me sale algo.
Muchísimas gracias :) Me haría mucha ilusión estar escuchando eso maravillosos ruiditos durante 10 minutos para luego disfrutar del juegazo elegido :D
:lovegp2x:
Muchísimas gracias :) Me haría mucha ilusión estar escuchando eso maravillosos ruiditos durante 10 minutos para luego disfrutar del juegazo elegido :D
:lovegp2x:
Aqui tienes un regalito. Carga un .tap y disfruta [wei]. No olvides de disfrutarlo en fullscreen :D.
Rivroner
25/01/2008, 00:00
Aqui tienes un regalito. Carga un .tap y disfruta [wei]. No olvides de disfrutarlo en fullscreen :D.
¡Pedazo de animal! Ya haces retoques por petición y todo :D O_o :)
¡¡¡Muchísimas gracias Seleuco!!! Luego lo pruebo, que acabo de llegar de currar y necesito una ducha y cenar algo :D
La Fullscreen pa ti :D, aunque la verdad, se ve bastante bien :)
:brindis:
:lovegp2x:
Metalbrain
25/01/2008, 22:53
Aqui tienes un regalito. Carga un .tap y disfruta [wei]. No olvides de disfrutarlo en fullscreen :D.
¡Joder, que máquina! Buen trabajo. Confío en que la velocidad real/acelerada se convierta en otro parámetro seleccionable en el menú, y que a su debido tiempo extiendas el soporte a los archivos .tzx (incluyendo los turbos y otros bloques más extraños), y tengamos un selector de bloques.
Hay una cantidad de juegos, pocos en realidad, que hacen uso del disco RAM del +2A para ejecutarse ¿podria añadirse la emulación de este modelo el +2a en proximas betas?
Creo que lo que es la emulación ya está, lo que no hay es reset a ese modelo, pero cargando un snapshot debería funcionar.
Por partes... en modo +3 en realidad no funciona porque el juego no es compatible, así que falla en todos los emuladores.
Añadir el reset en +2A es muy sencillo, basta con cambiar unas poquitas líneas y añadir otro par, y haciendolo así carga bien.
Concretamente, se sustituye en main.c, esto:
if(menu_mode==1)
{
//fill_mask(4*8,9*8,32*8,11*8);
if(redrawmask)
{
memset(&mask_keyb[0],0,32*8*11*8);
COLORFONDO=254;
mask_putcad(7,12,254,"SELECT SPECTRUM EMULATION");
if(sub_men==0) COLORFONDO=252; else COLORFONDO=255;
mask_putcad(6,14,255,"48K ");
if(sub_men==1) COLORFONDO=252; else COLORFONDO=255;
mask_putcad(lastx,14,255,"128K ");
if(sub_men==2) COLORFONDO=252; else COLORFONDO=255;
mask_putcad(lastx,14,255,"PLUS2 ");
if(sub_men==3) COLORFONDO=252; else COLORFONDO=255;
mask_putcad(lastx,14,255,"PLUS2A ");
if(sub_men==4) COLORFONDO=252; else COLORFONDO=255;
mask_putcad(lastx,14,255,"PLUS3");
redrawmask=0;
}// redraw
mask_out(4*8,9*8);
if(new_key & GP2X_LEFT) {redrawmask=1;sub_men--;if(sub_men<0) sub_men=4;}
if(new_key & GP2X_RIGHT) {redrawmask=1;sub_men++;if(sub_men>4) sub_men=0;}
if(new_key & GP2X_Y) {redrawmask=1;menu_mode=0;}
if(new_key & (GP2X_X | GP2X_PUSH))
{redrawmask=1;
switch(sub_men)
{
case 1:ZX_Reset(ZX_128);break;
case 2:ZX_Reset(ZX_PLUS2);break;
case 3:ZX_Reset(ZX_PLUS2A);break;
case 4:ZX_Reset(ZX_PLUS3);dsk_load((void *) DSK);break;
default:ZX_Reset(ZX_48);break;
}
menu_mode=0;
}
return -1;
}
por esto otro:
if(menu_mode==1)
{
//fill_mask(4*8,9*8,32*8,11*8);
if(redrawmask)
{
memset(&mask_keyb[0],0,32*8*11*8);
COLORFONDO=254;
mask_putcad(7,12,254,"SELECT SPECTRUM EMULATION");
if(sub_men==0) COLORFONDO=252; else COLORFONDO=255;
mask_putcad(6,14,255,"48K ");
if(sub_men==1) COLORFONDO=252; else COLORFONDO=255;
mask_putcad(lastx,14,255,"128K ");
if(sub_men==2) COLORFONDO=252; else COLORFONDO=255;
mask_putcad(lastx,14,255,"PLUS2 ");
if(sub_men==3) COLORFONDO=252; else COLORFONDO=255;
mask_putcad(lastx,14,255,"PLUS2A ");
if(sub_men==4) COLORFONDO=252; else COLORFONDO=255;
mask_putcad(lastx,14,255,"PLUS3");
redrawmask=0;
}// redraw
mask_out(4*8,9*8);
if(new_key & GP2X_LEFT) {redrawmask=1;sub_men--;if(sub_men<0) sub_men=4;}
if(new_key & GP2X_RIGHT) {redrawmask=1;sub_men++;if(sub_men>4) sub_men=0;}
if(new_key & GP2X_Y) {redrawmask=1;menu_mode=0;}
if(new_key & (GP2X_X | GP2X_PUSH))
{redrawmask=1;
switch(sub_men)
{
case 1:ZX_Reset(ZX_128);break;
case 2:ZX_Reset(ZX_PLUS2);break;
case 3:ZX_Reset(ZX_PLUS2A);break;
case 4:ZX_Reset(ZX_PLUS3);dsk_load((void *) DSK);break;
default:ZX_Reset(ZX_48);break;
}
menu_mode=0;
}
return -1;
}
Por último, el snapshot debería funcionar pero NO funciona. He buscado el bug y resulta que es que no selecciona bien la paginación de la ROM en los snapshots de +2A/+3, porque no carga el último byte de la cabecera donde se indica el OUT que hay que hacer al puerto 0x1ffd.
La corrección es muy sencilla, basta con cambiar en la línea 713 de snaps.c, en la función LoadZ80:
memcpy(buffer, source, 86);
por
memcpy(buffer, source, 87);
ya que necesitamos los 87 bytes que van del 0 al 86.
A ver si te mando esta tarde un paquete de juegos y demos que necesiten más optimización.
Al final no he hecho ningún paquete, pero estuve buscando juegos o demos que se relentizasen tanto como el Moggy al sacar el teclado virtual y no fue nada fácil, aunque al final vi que el Galaxians (ingame) iguala esa lentitud y el Equinox (en la música del menú) la supera.
Rivroner
26/01/2008, 00:10
Hablando de añadir cosas :D
¿Alguien sabe como cambiar de disco con los juegos del +3? Es que llevo semanas intentándolo y nada, tenía que haberlo preguntao antes :D
¡*****, que máquina! Buen trabajo. Confío en que la velocidad real/acelerada se convierta en otro parámetro seleccionable en el menú, y que a su debido tiempo extiendas el soporte a los archivos .tzx (incluyendo los turbos y otros bloques más extraños), y tengamos un selector de bloques.
JiJi... me has pillado, justo en eso estaba currando. Ya leo los bloques turbo del TZX y dentro de poco el resto. :brindis: Ya me carga perfectamente el Profanation
No obstante leer los bloques turbo del tzx hay que pasar de la rutina de la rom y dejarle el peso a la rutina de speedlock. Lo que quiere decir que no es instantaneo como cargar los bloques normales...:confused: Se me ocurre ponerle los 200, frameskip gordo, quitarle el sonido y la contienda, pero los niveles se tienen que leer por la ULA en cualquier caso. Podemos conseguir sobre un 3x-4x de la velocidad normal ya que la gp2x no da pa mas. alguna idea?
A ver si puedo tener un test dentro de poco aunque sea sin el selector de bloques, para testear los loop, turbo, tone, pulse y compañia...
zikitrake
26/01/2008, 02:01
JiJi... me has pillado, justo en eso estaba currando. Ya leo los bloques turbo del TZX y dentro de poco el resto. :brindis: Ya me carga perfectamente el Profanation GUAPOOOO! :rever:
....Podemos conseguir sobre un 3x de la velocidad normal, pero la gp2x no da pa mas... Bueno... pues más vale eso a nada ;)... y seguro que en breve se te ocurre algo para mejorar dicha velocidad :)
Rivroner
26/01/2008, 02:01
Usa el segundo core pa lo de los TZX ¿no? Como si fuese fácil oiga :D
¿Alguien sabe lo de cargar la otra cara en los discos de 3" ?
zikitrake
26/01/2008, 02:07
Sería buenismo que sacasen ya una forma fácil de usar el 2º core (leches!)
River, no lo he probado... como tenía el problema con formatos no-tap no-SnaZ80, actualmente sólo tengo snapshots en la consola; mañana intento probarlos... a ver si se puede
PD-Offtópica: YA PEDÍ MI LIIIIBRO
Metalbrain
26/01/2008, 03:17
¿Alguien sabe lo de cargar la otra cara en los discos de 3" ?
Lo siento, la verdad es que yo tampoco suelo usar las imágenes de disco.
JiJi... me has pillado, justo en eso estaba currando. Ya leo los bloques turbo del TZX y dentro de poco el resto. :brindis: Ya me carga perfectamente el Profanation
Jojojo, me estás haciendo quedar mal al resolver tan rápido los asuntos tan importantes que yo por mi parte dejé apartados. [wei5]
No obstante leer los bloques turbo del tzx hay que pasar de la rutina de la rom y dejarle el peso a la rutina de speedlock. Lo que quiere decir que no es instantaneo como cargar los bloques normales...:confused: Se me ocurre ponerle los 200, frameskip gordo, quitarle el sonido y la contienda, pero los niveles se tienen que leer por la ULA en cualquier caso. Podemos conseguir sobre un 3x-4x de la velocidad normal ya que la gp2x no da pa mas. alguna idea?
Aquí hay mucha información sobre todo de como lo hace el ZXSpin:
http://www.worldofspectrum.org/forums/showthread.php?t=11798&highlight=loop+detection
¡Buena suerte!
Jojojo, me estás haciendo quedar mal al resolver tan rápido los asuntos tan importantes que yo por mi parte dejé apartados. [wei5]
Pos lo mismo digo! Con él y contigo! :D
Como mola a la larga esto de liberar fuentes... quizás debería liberar algunos otros ports q tengo por ahi :S
Rivroner
28/01/2008, 17:28
Pos lo mismo digo! Con él y contigo! :D
Como mola a la larga esto de liberar fuentes... quizás debería liberar algunos otros ports q tengo por ahi :S
Pues las fuentes de tu emu de GameBoy GBC muchos te lo agradecerían, pues K-Teto perdió sus fuentes del GnuBoy y no lo va a continuar claro, aunque es cuasi perfecto su emu le faltan algunos retoques como que vaya a tope con el V-Sync activado(se necesita poner al menos 250mhz con algunos juegos) o algunos cuelgues aleatorias en el menú de selección de roms y alguna cosilla más.
< - >
Seleuco, ya probé la carga real de tap y va muy bien, lo único es que me sonaba que el sonido tenía un pitido más armónico y no tan ruidoso, ¿puede ser cosa de algún bug o es que mi memoria me falla :D? Tb es verdad que donde más oí eso ruiditos fueron con un C64 en casa de mis primos e igual con el Spectrum suena diferente la carga de cintas no sé O_o
Muchas gracias por la versión dedicada :)
Metalbrain
29/01/2008, 15:56
Este tipo de cosillas ponedlas en este foro (http://www.gp32spain.com/foros/forumdisplay.php?f=91) mejor, que así podremos pasarlas a portada y ganaréis unos suculentos créditos. ;)
Hace ya una semana que puse esto...
http://www.gp32spain.com/foros/showthread.php?t=51698
Aquí hay mucha información sobre todo de como lo hace el ZXSpin:
http://www.worldofspectrum.org/forums/showthread.php?t=11798&highlight=loop+detection
¡Buena suerte!
He estado un poco liado, pero este finde he seguido con el soporte de TZX con muchos avances, pero necesito la ayuda del comódin del público. :D. Gracias por adelantado Metalbrain.
Por partes:
Primero implementé mi carga de tzx, pero al final me fusile el libspectrum para el parseo de los bloques de tzx, ya que después de implementar los turbo y compañia, quedaban bloques de tipo onda cuadrada comprimida, datos generalizados, mucho curro oiga... me gusto su concepto de abstracción de cintas, asi que.... [wei5]
Mire lo del ZXSpin e implementé una rutina que detecta "edges" y la verdad es que acelera la carga una enormidad, pasando a ser usable :brindis:, por ahi estamos delante del fuse, que por lo que he visto no hace nada por el estilo :)
Entonces empece a probar los tzx, pintaba bién... pero encontre un problema... :confused: algunos tzx se reseteban y no los cargaba... repase el tema y nada... parecia que el problema estaba en la emulación... un ejemplo erá el "three weeks in paradise 128", asi que mire el cargador del mismo utilizando el debugger que tiene el SPIN y resulta que cascaba cuando hacia una verificacion (suma) de los bytes leidos.
Inicializaba el registo indice con el valor $6b00 y cargaba $e040 bytes con lo que estaba escribiendo en el el banco de la ROM???? al desbordar el word al pasar del $FFFF...
El problema se producia al verficar y leer los bytes de memoria, ya que ese espacio de direcciones esta separado en la ROM_dummy y las paginas de la rom, es decir una zona de lectura y una zona de escritura disjuntas...
MEMr[0]=&ROM_pages[0x4000*0]; MEMc[0]=0; MEMs[0]=0;
MEMw[0]=&ROM_dummy[0x4000*0];
vamos que lees de la rom y no lo que has escrito... :confused:
De momento he solucionado el problema interceptando las peticiones de lectura y mirando si se ha escrito en la MEMw, sino devuelvo de la MEMr.... no tengo muy claro las implicaciones... a si que te agradeceria un poco de ayuda al respecto... a demas no me gusta cargar con mas código algo tan critico en rendimiento como la lectura de memoria... vamos que no acabo de entender lo de la rom dummy :D
... por otro lado, la lectura de los edges la he implementado por dos lados, cada una con sus ventajas e inconvenientes.... por el puerto del mic o metiendo un PATCH en el bucle que procesa los opcodes... la primera opción nos hace perder poco rendimiento, ya que la cinta tira ha medida que se lee del puerto, problema, dificil sincronización y es posible que algun loader que mire el timing nos casque (también facilita el edge loader).... la segunda, es la mas segura, pero penaliza bastante el rendimiento, al tener que estar avanzando la cinta depués de procesar un opcode... ¿Como lo ves?
Queda bastante trabajo de dejarlo todo bién, ya que he hecho muchas pruebas y esta todo lleno de trazas y guarreria diversa :)
Un saludo.
zikitrake
03/02/2008, 22:46
:rever: no hay palabros para darte las gracias por las mejoras que te estás currando.
GRACIAS!
seleuco ya que a mi no me da tiempo con los tzx te digo lo que iba a hacer.
dejate de tzx y todos sus bloques, e implenta los pzx que son mucho mas sencillos, y está el codigo fuente por ahí.
para cargar los tzx conviertelos internamente a pzx, y usa de nuevo el cargador de pzx. te funcionarán todos los tzx, y todos los pzx obviamente.
tambien los csw q yo recuerde.
los pzx son una maravilla. echale un ojo.
seleuco ya que a mi no me da tiempo con los tzx te digo lo que iba a hacer.
dejate de tzx y todos sus bloques, e implenta los pzx que son mucho mas sencillos, y está el codigo fuente por ahí.
para cargar los tzx conviertelos internamente a pzx, y usa de nuevo el cargador de pzx. te funcionarán todos los tzx, y todos los pzx obviamente.
tambien los csw q yo recuerde.
los pzx son una maravilla. echale un ojo.
Muchas gracias por el consejo. Le echare un vistazo, aunque de momento lo que mejor tira es la lectura de los tzx. No obtante, si que es cierto que el libspectrum no esta muy pensado para que cosas. Ej, te llegan los "edge" pero no puedes saber si es un edge de un cero o uno, en los bloques de datos, con lo que para el algortimo de carga por edges he tenido que hacer un algorimo heuristico que determine que pude ser un uno o un cero en funcion del nivel que va leyendo.... :)
Lo que me preocupa es el tema de la rom dummy y las escrituras en el espacio de direcciones de la rom... ¿alguna idea?
Un saludo.
Metalbrain
04/02/2008, 01:08
Por partes:
Primero implementé mi carga de tzx, pero al final me fusile el libspectrum para el parseo de los bloques de tzx, ya que después de implementar los turbo y compañia, quedaban bloques de tipo onda cuadrada comprimida, datos generalizados, mucho curro oiga... me gusto su concepto de abstracción de cintas, asi que.... [wei5]
Ante esto he de decir que ¡ole tus huevos!, yo me estuve mirando como implementar lo de libspectrum pero me parecía super lioso.
Mire lo del ZXSpin e implementé una rutina que detecta "edges" y la verdad es que acelera la carga una enormidad, pasando a ser usable :brindis:, por ahi estamos delante del fuse, que por lo que he visto no hace nada por el estilo :)
Entonces empece a probar los tzx, pintaba bién... pero encontre un problema... :confused: algunos tzx se reseteban y no los cargaba... repase el tema y nada... parecia que el problema estaba en la emulación... un ejemplo erá el "three weeks in paradise 128", asi que mire el cargador del mismo utilizando el debugger que tiene el SPIN y resulta que cascaba cuando hacia una verificacion (suma) de los bytes leidos.
Inicializaba el registo indice con el valor $6b00 y cargaba $e040 bytes con lo que estaba escribiendo en el el banco de la ROM???? al desbordar el word al pasar del $FFFF...
A ver si me entero... ¿el problema sucede siempre o solo desde que implementaste lo del edge loading?
El problema se producia al verficar y leer los bytes de memoria, ya que ese espacio de direcciones esta separado en la ROM_dummy y las paginas de la rom, es decir una zona de lectura y una zona de escritura disjuntas...
MEMr[0]=&ROM_pages[0x4000*0]; MEMc[0]=0; MEMs[0]=0;
MEMw[0]=&ROM_dummy[0x4000*0];
vamos que lees de la rom y no lo que has escrito... :confused:
De momento he solucionado el problema interceptando las peticiones de lectura y mirando si se ha escrito en la MEMw, sino devuelvo de la MEMr.... no tengo muy claro las implicaciones... a si que te agradeceria un poco de ayuda al respecto... a demas no me gusta cargar con mas código algo tan critico en rendimiento como la lectura de memoria... vamos que no acabo de entender lo de la rom dummy :D
¿Ein? Voy a mirarme esa rutina, pero me da la impresión de que para que te funcione la cosa estás haciendo que la ROM se pueda escribir. Lo de la ROM_dummy es sencillamente para que al escribir algo en la ROM, lo que escribas se quede en el limbo y no llegues a leerlo nunca, ya que lo que tienes que leer es el contenido original de la ROM, que se carga en ROM_pages al resetear el modelo y permanece sin cambios.
... por otro lado, la lectura de los edges la he implementado por dos lados, cada una con sus ventajas e inconvenientes.... por el puerto del mic o metiendo un PATCH en el bucle que procesa los opcodes... la primera opción nos hace perder poco rendimiento, ya que la cinta tira ha medida que se lee del puerto, problema, dificil sincronización y es posible que algun loader que mire el timing nos casque (también facilita el edge loader).... la segunda, es la mas segura, pero penaliza bastante el rendimiento, al tener que estar avanzando la cinta depués de procesar un opcode... ¿Como lo ves?
Me inclino mucho más por el método 1, ten en cuenta que tampoco es imprescindible que el edge-loading funcione el 100% de las veces, si algún juego no cargara debería bastar con deshabilitarlo y punto.
Ante esto he de decir que ¡ole tus huevos!, yo me estuve mirando como implementar lo de libspectrum pero me parecía super lioso.
Lo lioso es que compile, con el perl y todo el rollo que tienen montado para que sea multiplataforma.... :confused: Perrerias he tenido que hace para meterlo en la gp2x
A ver si me entero... ¿el problema sucede siempre o solo desde que implementaste lo del edge loading?
El problema es un fallo del emulador que se reproduce con los cargadores de micro-gen...pero seguro que pasa con mas cosas
mira:
el cargador carga bloques de la siguiente manera:
ld ix, $4000
ld de, $1b00
call $8372 (primer bloque)
ld ix, $6b00 ; Este es el que da problemas, direccion de partida a cargar
ld de, $e040 ; el total a cargar
call $8372 (segundo bloque)
(mas bloques)
la carga la hace con el tipico:
$8372...
ld (ix+$00), l ; (incrementado ix y decrementando de hasta que llege a cero)
y después de cargar el bloque lo verifica de la manera:
ld a, $00 ;
l_8384: add a, (hl) ;en hl tenemos el inicio del bloque es decir $6b00 y va sumando
ld e, a ;
inc hl ;
dec bc ; en bc tenemos lel total de bytes a verificar es decir $e040
ld a, b ;
or c ;
ld a, e ;
jr nz, l_8384 ; mira que no queden bytes
cp (hl) ; la ultima posicion leida tiene el byte que debe coincidir con la suma
scf ;
ret nz ;
ccf ;
ret ;
Si miras el bucle si BC es $e040 y como empezamos en $6b00 escribieremos 14b40 bytes en total, como hl es una palabra, al igual que ix... realmente escribiremos de $6b00-$FFFF y $0000-4b40... estamos escribiendo en la ROM.???
he hecho un volcado de esas zonas de memoria y se esta escibiendo, luego cuando el cargador va a leer, lee algo distinto a lo que escribió por el mecanismo de proteccion de la rom que comentas.
¿Ein? Voy a mirarme esa rutina, pero me da la impresión de que para que te funcione la cosa estás haciendo que la ROM se pueda escribir. Lo de la ROM_dummy es sencillamente para que al escribir algo en la ROM, lo que escribas se quede en el limbo y no llegues a leerlo nunca, ya que lo que tienes que leer es el contenido original de la ROM, que se carga en ROM_pages al resetear el modelo y permanece sin cambios.
Lo que he hecho es justamente eso... y asi funciona la carga de estos tzx, pero otros tzx dan problemas.... existe algo erroneo en la gestion de la memoria...
Me inclino mucho más por el método 1, ten en cuenta que tampoco es imprescindible que el edge-loading funcione el 100% de las veces, si algún juego no cargara debería bastar con deshabilitarlo y punto.El edge-loading no es el problema, sino los timing de los tzx, para que todo vaya sincrono, tienes que reproducir los pulsos de la manera mas precisa posible. Si dependes de los outs, puede que pierdas pulsos que ciertos cargadores esperan que pasen aunque no hagan IN's. De hecho algunos TZX no se reproducen de esas manera como es el lord of midnights. :confused:
Metalbrain
04/02/2008, 10:43
El problema es un fallo del emulador que se reproduce con los cargadores de micro-gen...pero seguro que pasa con mas cosas
mira:
el cargador carga bloques de la siguiente manera:
ld ix, $4000
ld de, $1b00
call $8372 (primer bloque)
ld ix, $6b00 ; Este es el que da problemas, direccion de partida a cargar
ld de, $e040 ; el total a cargar
call $8372 (segundo bloque)
(mas bloques)
la carga la hace con el tipico:
$8372...
ld (ix+$00), l ; (incrementado ix y decrementando de hasta que llege a cero)
y después de cargar el bloque lo verifica de la manera:
ld a, $00 ;
l_8384: add a, (hl) ;en hl tenemos el inicio del bloque es decir $6b00 y va sumando
ld e, a ;
inc hl ;
dec bc ; en bc tenemos lel total de bytes a verificar es decir $e040
ld a, b ;
or c ;
ld a, e ;
jr nz, l_8384 ; mira que no queden bytes
cp (hl) ; la ultima posicion leida tiene el byte que debe coincidir con la suma
scf ;
ret nz ;
ccf ;
ret ;
Si miras el bucle si BC es $e040 y como empezamos en $6b00 escribieremos 14b40 bytes en total, como hl es una palabra, al igual que ix... realmente escribiremos de $6b00-$FFFF y $0000-4b40... estamos escribiendo en la ROM.???
Anoche lo estuve mirando... Sí, la rutina escribe en la ROM, aumentando tóntamente el tiempo de carga, seguramente por motivos de protección, de forma que los copiones turbo no puedan cargar el bloque completo en memoria. Además, tras cargar los 16K completos de ROM, también recarga una parte de la pantalla, desde 4000h hasta 4b40h. Lo más seguro es que en ese bloque, la parte de la ROM cargue la misma ROM que había en el momento en el que se grabó, fallando por lo tanto si la ROM es diferente. Lo probé en el ZXSpin y efectivamente, solo en el modelo de 128k carga, en el +2, +2A, +3, casca.
Así pues, sospeché que la ROM del modelo 128k que rlyeh había incluido podría estar ligeramente parcheada provocando así el cuelgue al no ser idéntica a lo que se carga, pero cuando extraje dicha rom del array C en el que lo tenemos, comprobé que es idéntica a la del ZXSpin, así que el problema debe estar en otro sitio. Otra posibilidad es que no estés haciendo las pruebas con el emulador puesto en modo 128, pero teniendo en cuenta que es el modo de arranque por defecto, dudo mucho que sea por eso.
he hecho un volcado de esas zonas de memoria y se esta escibiendo, luego cuando el cargador va a leer, lee algo distinto a lo que escribió por el mecanismo de proteccion de la rom que comentas.
Lo que he hecho es justamente eso... y asi funciona la carga de estos tzx, pero otros tzx dan problemas.... existe algo erroneo en la gestion de la memoria...
Prueba a volcar lo que carga en ROM_dummy, a ver que es lo que sale.
Anoche lo estuve mirando... Sí, la rutina escribe en la ROM, aumentando tóntamente el tiempo de carga, seguramente por motivos de protección, de forma que los copiones turbo no puedan cargar el bloque completo en memoria. Además, tras cargar los 16K completos de ROM, también recarga una parte de la pantalla, desde 4000h hasta 4b40h. Lo más seguro es que en ese bloque, la parte de la ROM cargue la misma ROM que había en el momento en el que se grabó, fallando por lo tanto si la ROM es diferente. Lo probé en el ZXSpin y efectivamente, solo en el modelo de 128k carga, en el +2, +2A, +3, casca.
Así pues, sospeché que la ROM del modelo 128k que rlyeh había incluido podría estar ligeramente parcheada provocando así el cuelgue al no ser idéntica a lo que se carga, pero cuando extraje dicha rom del array C en el que lo tenemos, comprobé que es idéntica a la del ZXSpin, así que el problema debe estar en otro sitio. Otra posibilidad es que no estés haciendo las pruebas con el emulador puesto en modo 128, pero teniendo en cuenta que es el modo de arranque por defecto, dudo mucho que sea por eso.
Prueba a volcar lo que carga en ROM_dummy, a ver que es lo que sale.
Justamente lo que has comentado lo venia yo pensando en el coche de vuelta del curro.... un mecanismo de protección chequeando la rom. Me iba a mirar la rom del spin es ese punto y comparar con la nuestra... pero si ya lo has echo tu... pues nada.
La rom que cargo es la 128 como suponias... creo recordar que solo habia dos bytes con diferencias el $1b02 y el $1b03... te lo digo de memoria. Intentare recuperar los volcados y chequaerlos... mira que hacerte cargar 16k's para comprobar la rom... :mad:
Lo bueno de los tzx es que se recuperan los cargadores que me parecen pequeñas obras de arte... el flashloading esta bién, pero ver los contadores del speedlock o las maravillas que se hacian aprovechando los ciclos muertos en busca de edges no tiene precio :D
< - >
Rectifico he mirado los volcados y las diferencias son
J:\>fc r.txt w.txt
Comparando archivos r.txt y W.TXT
***** r.txt
0561:e5
0562:ed
0563:3f
0564:1f
***** W.TXT
0561:e5
0562:db
0563:fe
0564:1f
*****
donde r.txt son las lecturas de nuestra rom y w lo que escribe el tzx
mirando el desemsamble de la rom coincide con
THE 'LD-BYTES' SUBROUTINE
This subroutine is called to LOAD the header information (from 07BE) and later LOAD, or VERIFY, an actual block of data (from 0802).
0556 LD-BYTES INC D This resets the zero flag. (D
cannot hold +FF.)
EX AF,A'F' The A register holds +00 for a
header and +FF for a block of
data.
The carry flag is reset for
VERIFYing and set for
LOADing.
DEC D Restore D to its original value.
17
DI The maskable interrupt is now
disabled.
LD A,+0F The border is made WHITE.
OUT (+FE),A
LD HL,+053F Preload the machine stack
PUSH HL with the address - SA/LD-RET.
-->IN A,(+FE) Make an initial read of port '254' (ESTE ES EL QUE CAMBIA)
RRA Rotate the byte obtained but
AND +20 keep only the EAR bit,
OR +02 Signal 'RED' border.
LD C,A Store the value in the C register. -
(+22 for 'off' and +02 for 'on'
- the present EAR state.)
CP A Set the zero flag.
--> y el nuevo opcode ES EL TRAPLOAD jeje.. vamos que es el hook para hacer el flashloading... cago en to! habra que reparchear la bios si se pone en marcha el tzx :)
q yo recuerde se cargan las roms sin modificar, y luego le aplico el parche en *ROM.
puedes buscar por el source verás como están las rutinas de parcheo por ahi
en concreto podrias ir buscando desde el z80patch() a ver si hay suerte ;-)
saludos
q yo recuerde se cargan las roms sin modificar, y luego le aplico el parche en *ROM.
puedes buscar por el source verás como están las rutinas de parcheo por ahi
en concreto podrias ir buscando desde el z80patch() a ver si hay suerte ;-)
saludos
Ya lo tenia localizado. :brindis:. a quien se le ocurre parchear la rom y no avisarnos :D
por cierto una pregunta rlyeh que hoy ando empanado y no acabo de verlo claro....
al inicializar el 128 y asignar las paginas se hace algo del tipo MEMw[3]=MEMr[3]=&RAM_pages[0x4000*0-3*0x4000]; siendo RAM_PAGES los bancos de memoria para switchear cuando nos lo digan por el puerto 0x7ffd... pero no es un indice negativo o mi "c" lo tengo mas olvidado de lo que creia...? me parece muy rebuscado que enganche con lo que esta detras en la heap? ...
Metalbrain
05/02/2008, 03:07
por cierto una pregunta rlyeh que hoy ando empanado y no acabo de verlo claro....
al inicializar el 128 y asignar las paginas se hace algo del tipo MEMw[3]=MEMr[3]=&RAM_pages[0x4000*0-3*0x4000]; siendo RAM_PAGES los bancos de memoria para switchear cuando nos lo digan por el puerto 0x7ffd... pero no es un indice negativo o mi "c" lo tengo mas olvidado de lo que creia...? me parece muy rebuscado que enganche con lo que esta detras en la heap? ...
Lo que pasa es que ese offset negativo se compensa luego al leerlo con:
volatile word whereA;
whereA=where>>14;
return *((byte *)(MEMr[whereA]+(where)));
Por ejemplo, cuando where es mayor que 49152 (3*0x4000), whereA queda como 3, y queremos leer de la página 0, que comienza en la posición 0 de RAM_pages y ocupa 16k como todas las páginas, así que al sumar where se compensa el comienzo real en RAM_pages con la posición que ocupa en la memoria.
Ahora lo que no se es si te habré liado más o no. :loco:
El caso es que aunque sea algo rebuscado al hacerlo así nos ahorramos cálculos de tener que estar descomponiendo las direcciones. Vamos, digo yo que será por eso.
sí el tema es q estaba muy optimizado todo el sistema de paginación para que funcionase sin problemas en la GP32 original.
de todas formas mi inicializacion del 128 es asi:
int
initialize_128 (void)
{
model=ZX_128;
memcpy(&ROM_pages[0x4000*0],&spectrum_rom_128[0x4000*0],0x4000);
memcpy(&ROM_pages[0x4000*1],&spectrum_rom_128[0x4000*1],0x4000);
memcpy(&hwopt, &hwopt_128, sizeof(tipo_hwopt));
MEMw[3]=MEMr[3]=&RAM_pages[0x4000*0]; MEMc[3]=0;
MEMw[2]=MEMr[2]=&RAM_pages[0x4000*2]; MEMc[2]=0;
MEMw[1]=MEMr[1]=&RAM_pages[0x4000*5]; MEMc[1]=1; //contended
MEMr[0]=&ROM_pages[0x4000*0]; MEMc[0]=0;
MEMw[0]=&ROM_dummy[0x4000*0];
pagination_128=0;
pagination_plus2a=128;
contended_mask=1;
return 1;
}
no sé que versión pilló Hermes para hacer el emu... pero diria que no fue la ultima. y cualquiera lo adivina ahora con lo reliado que está el código
:S
por cierto que os he visto preguntando antes acerca de rom_dummy; es una pagina de solo-escritura con mierda para simular las escrituras a sitios prohibidos, como la escritura en rom.
Lo que pasa es que ese offset negativo se compensa luego al leerlo con:
volatile word whereA;
whereA=where>>14;
return *((byte *)(MEMr[whereA]+(where)));
Por ejemplo, cuando where es mayor que 49152 (3*0x4000), whereA queda como 3, y queremos leer de la página 0, que comienza en la posición 0 de RAM_pages y ocupa 16k como todas las páginas, así que al sumar where se compensa el comienzo real en RAM_pages con la posición que ocupa en la memoria.
Ahora lo que no se es si te habré liado más o no. :loco:
El caso es que aunque sea algo rebuscado al hacerlo así nos ahorramos cálculos de tener que estar descomponiendo las direcciones. Vamos, digo yo que será por eso.
Joer pues tienes razon. No se pero yo hubiera hecho echo algo del tipo
((byte *)(MEMr[where >> 14 ]+(where & 0x3FFF)));
mucho mas claro... aunque te ganas un &... vamos un ciclo de reloj mas.... aunque con el pipeline seguro que ni eso...
Rivroner
05/02/2008, 21:59
Da gusto ver a estos 3 fieras aquí mejorando lo inmejorable :D :)
Metalbrain
07/02/2008, 23:32
Por favor, Seleuco (o algún admin con poderes), ¿puedes quitar el adjunto con la versión 1.6 del primer post?
Los guiris están que no paran de emocionarse subiendo la versión 1.6 a las noticias de sus webs como si fuese la más avanzada (sin percatarse de que tiene el mismo changelog que la 1.5, vaya memorias de pez [wei]).
Y si algún administrador pudiera cambiarle el título al topic, mejor.
Rivroner
07/02/2008, 23:40
Por favor, Seleuco (o algún admin con poderes), ¿puedes quitar el adjunto con la versión 1.6 del primer post?
Los guiris están que no paran de emocionarse subiendo la versión 1.6 a las noticias de sus webs como si fuese la más avanzada (sin percatarse de que tiene el mismo changelog que la 1.5, vaya memorias de pez [wei]).
Y si algún administrador pudiera cambiarle el título al topic, mejor.
Sí, yo tb me di cuenta de eso el otro día :D
Pues ya sabes, a la próxima la llamas 1.6.1 o la llamas 1.5.2 pero dices claramente en el hilo de GP32X que ésta es más actual que la 1.6 :D
Por favor, Seleuco (o algún admin con poderes), ¿puedes quitar el adjunto con la versión 1.6 del primer post?
Los guiris están que no paran de emocionarse subiendo la versión 1.6 a las noticias de sus webs como si fuese la más avanzada (sin percatarse de que tiene el mismo changelog que la 1.5, vaya memorias de pez [wei]).
Y si algún administrador pudiera cambiarle el título al topic, mejor.
Ya intente quitarlo hace mucho.. pero no hubo manera.. :(
Por cierto el soporte TZX marcha viento en popa.... la rutina de deteccion de edges funciona perfectamente y permite tener cargado un tzx de los normales en unos 15 segundos ;)
A ver si puedo sacar un test este finde...
Rivroner
08/02/2008, 02:52
Por cierto el soporte TZX marcha viento en popa.... la rutina de deteccion de edges funciona perfectamente y permite tener cargado un tzx de los normales en unos 15 segundos ;)
A ver si puedo sacar un test este finde...
¡Yuju! ^_^
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions Inc. All rights reserved.