You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
(89) |
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2005 |
Jan
(3) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Jordi <jb...@ti...> - 2002-10-10 21:00:55
|
bueno, abusando descaradamente de la mailing list ;) posteo aqui= los cambios mas o menos que tengo en la version de aspectrum de zxdeb= para que funcionen los 128 y los +2 ah, y algunas cosillas mas ;) primero de todo, solo una "apreciacion", y es que ExitEmulator= (en v_alleg.c) deberia llamarse gExitEmulator, pues depende de la libreria que usemos ahora las funciones para emular el 128: de momento usan tamanyo= de pagina fijo de 16 kas, pero pasarlo a 8, 4 o 2 o 1 no deberia ser= dificil (meter un par de defines y ya esta). tampoco esta implementado eso para escribir en ROM sin tener un= if o sea, que tal y como esta aqui funciona, pero se debe pulir: priemro de todo, en z80.h, dentro de Z80regs: byte *RAMbank[MAX_RAM_BANKS]; byte *ROMbank[MAX_ROM_BANKS]; byte *page[4];=09=09=09=09// for each page space, a pointer to its= paged bank int pagenum[4];=09=09=09=09// the same as page, to keep the page number= without comparing pointers int paging_disabled;=09=09=09// outs at 7ffd & 1ffd have no effect int shadow_screen; despues , mi z80initialization queda asi: (basicamente reservo espacio para las paginas de ram) ************************************ int Z80Initialization (void) { FILE *fp; int i; /* we get memory and load font, spectrum ROM and possible snapshots selected by the command line */ printf ("ASpectrum GNU pure C Z80 / Spectrum Emulator V "VERSION"\n" =09=09 "(C) 2000-2001 Santiago Romero (NoP/Compiler).\n" =09=09 "Powered by Allegro 4/3.x WIP -" =09=09 " http://www.talula.demon.co.uk/allegro/\n" =09=09 "Distributed under the terms of GNU Public License V2\n\n"); spectrumZ80.RAM =3D (byte *) malloc( 65536 ); if( spectrumZ80.RAM =3D=3D NULL ) { =09 printf("\n Z80: Error allocating RAM memory,= exiting...\n\n"); =09 return(0); } memset (spectrumZ80.RAM,0,16384*4); // Get memory for RAM banks for (i=3D0;i<MAX_RAM_BANKS;i++) { =09 spectrumZ80.RAMbank[i]=3D(byte *)malloc(16384); =09 if (spectrumZ80.RAMbank[i]=3D=3DNULL) =09 { =09=09=09printf("\n Z80: Error allocating RAM memory,= exiting...\n\n"); =09=09=09return(0); =09 } =09 memset (spectrumZ80.RAMbank[i],0,16384); } // Get memory for ROM banks for (i=3D0;i<MAX_ROM_BANKS;i++) { =09 spectrumZ80.ROMbank[i]=3D(byte *)malloc(16384); =09 if (spectrumZ80.ROMbank[i]=3D=3DNULL) =09 { =09=09=09printf("\n Z80: Error allocating ROM memory,= exiting...\n\n"); =09=09=09return(0); =09 } =09 memset (spectrumZ80.ROMbank[i],0,16384); } init_wrapper(); // abrimos el fichero de letras #ifdef DESTDAT =09if ((fp=3Dfopen( DESTDAT"/font.fnt", "rb" ) )!=3D NULL) =09=09printf("using "DESTDAT"/font.fnt\n"); =09else #endif =09if ((fp=3Dfopen( "font.fnt", "rb" )) !=3DNULL) =09=09printf("using ./font.fnt\n"); =09else =09{ =09=09printf("File font.fnt does not exist...\n"); =09=09return(0); =09 }; =09fread( tfont, 4096, 1, fp ); =09fclose(fp); =09i=3D0; =09// abrimos el fichero de rom =09if (emuopt.romfile[0]!=3D0) =09{ =09=09if ((fp=3Dfopen(emuopt.romfile,"rb"))!=3DNULL ) =09=09=09printf("Using ROM file %s\n",emuopt.romfile); =09=09else =09=09{ =09=09=09printf("The ROM file does not exists.\n"); =09=09=09return(0); =09=09} =09} #ifdef DESTDAT =09else if ((fp=3Dfopen( DESTDAT"/spectrum.rom","rb") )!=3DNULL) =09=09printf("using "DESTDAT"/spectrum.rom\n"); #endif =09else if ((fp=3Dfopen( "spectrum.rom","rb"))!=3DNULL ) =09=09printf("using spectrum.rom\n"); =09else =09{ =09=09 printf("File spectrum.rom does not exist ...\n"); =09=09 return(0); =09}; while( !feof(fp) ) =09 spectrumZ80.RAM[i++]=3Dfgetc(fp); fclose(fp); // =BFNecesario? =BFPara que? //CreateVideoTables(); =09initAYarrays (); =09Z80MachineInitialization(); =09Z80Reset( &spectrumZ80, TSTATES_PER_LINE*(TOP_BORDER_LINES+BOTTOM_BORDER_LINES+SCANLINES)= ); Z80FlagTables(); =09aspectrumInited=3D1; return 1; } ************************************ en macros.cpp tengo esto cambiado: #define Z80ReadMem(A) Z80MemRead (A,regs) #define Z80WriteMem(a,b,c) Z80MemWrite(a,b,c) y z80.c tengo estas funciones cambiadas: (el #ifdef es para= cambiar entre paginacion(128) y no paginacion (48), para debugar, pero= con el metodo de paginacion el modo 48 funciona igualmente (ya digo,= solo debug)) ************************************ #ifdef INLINE_MEMORY inline #endif byte Z80MemRead( register word address, Z80Regs *regs ) { u8 *ptr; int v1,v2; #ifdef NO_PAGING =09return regs->RAM[address]; #else =09ptr=3Dregs->page[(address>>14)&3]; =09v1=3Dptr[address&16383]; //=09v2=3Dregs->RAM[address]; =09return v1; #endif } /*=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D void Z80MemWrite( register word address, register byte value ) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D*/ #ifdef INLINE_MEMORY inline #endif void Z80MemWrite( register word address, register byte value,= Z80Regs *regs ) { u8 *ptr; if( address >=3D 16384 ) { #ifdef NO_PAGING =09regs->RAM[address]=3Dvalue; #else =09ptr=3Dregs->page[(address>>14)&3]; =09ptr[address&16383]=3Dvalue; //=09regs->RAM[address]=3Dvalue; #endif } } en z80outport: =09if (port=3D=3D0x7ffd) =09{ =09=09port_7ffd(regs,value); =09} =09if (port=3D=3D0xfffd) =09{ =09=09outport_fffd(regs,value); =09} =09if (port=3D=3D0xbffd) =09{ =09=09outport_bffd(regs,value); =09} y entonces tengo un machines.cpp del que hago attach, que es el= que se encarga de configurar cada una de las futuras maquinas y= emular el port 0x7ffd. los ficheros de rom estan hardcoded y todo eso , se= tiene que hacer mejor para configurar eso por eso en la proxima entrega, intentare adjuntar el sistema de configuracion por fichero ;) venga, ESPERO que este todo (aunque seguro que algo me he= dejado) todo este codigo es criticable y modificable, pero tal y como= esta de momento funciona perfectamente :)_ (lo mejor para probarlo son= los taps, ya que se tendran que modificar las rutinas de sna y z80 bye :) Kak |
From: Alvaro A. <A_...@te...> - 2002-10-10 20:50:00
|
BUENOS DIAS!!! Y entonces, va Kak y dice ¿Fwd: Re: [Aspectrum-devel] Version de allegro que estamos usando para compilar...? > lo mismo. > vivan los duplicados! > >cierto. note ese efecto en la Abadia del crimen, y tengo que > >reconocer que con ese color quedaba mucho mejor! ;) > >lo que no entiendo es porque los colores se ven "raros", ya que me > >mire la tabla y me parecio que el valor del color estaba bien :( > >>Ah, y una de las cosas que hace fuse es tener una "dirty screen" > >>que actualiza en pantalla sólo los cambios realizados, no la > >>pantalla completa... ¿eso sería útil en aspectrum? > >en modos de video con ventanitas (xwindows, windows, ...) se > >aumentaria mucho la velocidad ya que las funciones no suelen acceder > >directamente al hardware, sino que pasan por las funciones de el api > >con el que les toque pelearse. En modos fullscreen (linux consola, > >msdos) no creo que el aumento de velocidad se notara mucho... > >el rendimiento tambien dependeria del tipo de juego :) editando > >basic > >el aumento de velocidad puede ser *brutal*, pero con el cobra (donde > >casi toda la pantalla es diferente cada vez) o similares no creo que > >se note gran mejora Dos cosinas, 1º que editando basic no vais (ojo vais, vosotros afortunados poseedores de maquinas con cientos de bogomips.) a notar ningun aumento de rendimiento, el emulador va a seguir funcionando a 50 fps y las cosas van a seguir apareciendo a la misma velocidad. 2º ¿Teneis idea de como implementar el dirty Screen? supone interceptar mem_write, comprobar que esta es escribiendo en la pantalla y actulizar no solo la pantalla si no ademas una tabla de dirty rectangles. no se pero no tengo claro que mejore el rendimiento. y aun asi, tengo mis dudas de que aumente el rendimiento, al menos en windows bajo directX no lo vamos a notar, y en linux en ventana, tengo mis dudas (pa mi que el cuello de botella esta por otro lado). si os apetece se puede implementar un pseudo dyrty screen, y es que si el borde no ha cambiado en el ultimo frame, solo se blitee la zona grafica, pero tampoco creo que se note. -- ¿ Qué estás haciendo, Dave ?. Nada, HAL, te instalo Windows 95. _ Grettings of __ _| |___ __ _ Al...@as... LiNUX USER #66734 Saludos / _` | / -_) _` | http://pagina.de/alea A_...@te... de \__,_|_\___\__,_| MS Messenger: alv...@ho... Para obtener Llave Publica GnuPGP un mail con subject: enviar clave pub |
From: Alvaro A. <A_...@te...> - 2002-10-10 20:35:57
|
BUENOS DIAS!!! Y entonces, va Kak y dice ¿Fwd: Re: [Aspectrum-devel] Nueva version.? > >>todo salga como debe, si lo hago todo segun el FAQ el horizonte del > >>aquaplane > >>me sale 16 pixels mas abajo. > >entonces > >se empieza a pintar a partir del primer pixel de pantalla. > >entonces pasan 192 lineas, y vienen 56 mas de borde otra vez > > > >(56+192+64) * 224 = 69988 Bien, una cosa solucionada. Al final era yo el que estaba mal, que raro, es problema es que aquaplane es un juego de 16k y por tanto le afecta la memoria contenida, exactamente 16*224 estados t mientras dibuja el borde, por eso a mi me sobraban esas lineas, he probado vectron y para que el efecto sea igual, hay que usar el valor correcto. > >Now for the timings of each line itself: define a screen line to > >start with 256 screen pixels, then border, then horizontal retrace, > >and then border again. All this takes 224 T states. Every half T > >state a pixel is written to the CRT, so if the ULA is reading bytes > >it does so each 4 T states (and then it reads two: a screen and an > >ATTR byte). The border is 48 pixels wide at each side. A video > >screen > >line is therefore timed as follows: 128 T states of screen, 24 T > >states of right border, 48 T states of horizontal retrace and 24 T > >states of left border. > >o sea, se pintan 256 pixels (de la pantalla). Despues viene el borde > >derecho, despues el horizontal retrace, y despues el borde izquierdo > >de la siguiente linea osea que segun el FAQ las lineas enpiezan a mitad de la pantalla, no tiene sentido, piensa en las lineas del borde superior. > >entonces, para la emulacion del port 0xff, lo que nos ocupa (creo), > >lo correcto seria hacer tstate actual % TSTATES_PER_LINE, y si es > ><128 entonces retornar un valor aleatorio, y si no es <128, retornar > >FF Are los cambios pertinentes a ver si mejora la cosa, de momento me estoy echando unas partidas al cobra de espanto. ¿cortocircuito 1 tambien fallaba si estaba mal implementado el port FF no? -- 3.000.000 de lemmings no pueden equivocarse, ¡COMPRA WINDOWS 95! _ Grettings of __ _| |___ __ _ Al...@as... LiNUX USER #66734 Saludos / _` | / -_) _` | http://pagina.de/alea A_...@te... de \__,_|_\___\__,_| MS Messenger: alv...@ho... Para obtener Llave Publica GnuPGP un mail con subject: enviar clave pub |
From: Alvaro A. <A_...@te...> - 2002-10-10 20:14:52
|
BUENOS DIAS!!! Y entonces, va Santiago Romero y dice ¿[Aspectrum-devel] Colores en el emulador? > Cargando el flying shark he visto que el color amarillo no se > corresponde con el tono que hay en el spectrum... tenemos que > "tomar prestada" una tabla de colores BUENA de algún emulador > para ponerlo en aspectrum. ¿Algún candidato? ¿Pongo la del > fuse o algún otro? La que tu veas conveniente, y si de paso me explicas como funciona lo de la paleta del allegro mejor, por que no me aclaro. La funcion en particular la encuentras con grep "soy un estupido" *.c :-( tengo que acordarme de quitar ese comentario. -- Si quieres a tu pc no instales W95. El no lo haria contigo. _ Grettings of __ _| |___ __ _ Al...@as... LiNUX USER #66734 Saludos / _` | / -_) _` | http://pagina.de/alea A_...@te... de \__,_|_\___\__,_| MS Messenger: alv...@ho... Para obtener Llave Publica GnuPGP un mail con subject: enviar clave pub |
From: Alvaro A. <A_...@te...> - 2002-10-10 20:14:26
|
BUENOS DIAS!!! Y entonces, va Santiago Romero y dice ¿[Aspectrum-devel] GUIs para Allegro? > He estado buscando GUIs para Allegro. > Sé que os gustaría que el menú de Aspectrum fuera tipo +3 y demás, > pero no estoy seguro de que sea sencillo. Algunos de los guis que > os presento permiten customización del aspecto, pero no creo que > deba ser la prioridad principal... :-? 2 cosillas: 1 valora si es interesante que sea compatible (o parecido) con el gui actual. 2 De verdad hace falta un gui, ya ya se que hace falta, me refiero a un gui completo, ten en cuenta que da igual que el gui tenga tooltips, tabs, ventanas, o la de su madre, nosotros con que tenga una opcion de poner mensajes con el boton de aceptar, los cuadros de dialogo "abrir como" y 4 cosas mas basta. > Os pego las URLs para que veáis los screenshots y me deis vuestra > opinión de qué GUI tiene mejor pinta para Aspectrum: > > http://www.steinke.net/allegro/ > (sólo el tercer tema es "bonito", pero parecen MODIFICABLES!). el 1º tampoco esta mal. el la pagina tienes ademas enlaces a otro: bgui2: feo > http://www.lwithers.demon.co.uk/prog/allegro/more_gui/ > (no hay foto, si veis el ejemplo igual sacais algo en claro) no tiene pinta de gui, sino de ser mas widgets para el gui de allegro. > http://www.alphalink.com.au/~tjaden/agup/ > (sólo el tema photon es bonito) coincido contigo. parece compatible con allegro, vere que pasa si lo compilo... > http://www.concentric.net/~skis/ > (algo fea IMHO) Y la licencia puede dar problemas. > http://www.idt.mdh.se/personal/csg/cgui/ > (mirad los screenshots, se me cae la baba!!!!) ta bien. > http://dime.sourceforge.net/ > (Es bonito Y muy facil de usar, mirad el ejemplo del screenshot > cómo se ha generado, el código es apenas una línea!!!!!!!!). si, si, pero que pasa con las funciones de archivos, como no las traiga estamos en las mismas. > [url del masking] > (es bonito y también soporta temas) es para C++, ¿podemos usarlo? > Cuando podais les echais un vistazo, mirais lo que dicen de ellos > y me valorais cada uno de vosotros 2 cuál preferís para allegro. Yo > me quedo en este orden con: > CGUI > DIME > MASKING > ¿Qué opinais? pues que yo me quedaba con el primero o con agup. -- "Solo Windows me hace vibrar asi" - Mr. HD. _ Grettings of __ _| |___ __ _ Al...@as... LiNUX USER #66734 Saludos / _` | / -_) _` | http://pagina.de/alea A_...@te... de \__,_|_\___\__,_| MS Messenger: alv...@ho... Para obtener Llave Publica GnuPGP un mail con subject: enviar clave pub |
From: Alvaro A. <A_...@te...> - 2002-10-10 20:14:04
|
BUENOS DIAS!!! Y entonces, va Santiago Romero y dice ¿Re: [Aspectrum-devel] Version de allegro que estamos usando para compilar...? > El Thu, 10 Oct 2002 05:07:20 +0200, Alvaro Alea <A_...@te...> wrote: > > BUENOS DIAS!!! > > Y entonces, va Santiago Romero y dice ¿[Aspectrum-devel] Version de > > allegro que estamos usando para compilar...? > > > ¿qué versión de allegro estamos usando? Lo digo por instalarme > > > la 4, o alguna anterior si lo decís vosotros... > > Yo la 4.1.algo aunque deberia compilar en principio con cualquiera a > > partir de la 3.9X WIP, aunque el sonido bajo win32 > > a mi solo me funciono cuando instale el 4 (bug de allegro) > > otra vez estas respondiendome a si solo y no a la lista X'D bueno, pues esta vez cuoteo menos y listo :-( > por cierto, que compilando veo esto: > op_dd_fd.c:1: warning: `/*' within comment > In file included from op_dd_fd.c:211, > from z80.c:244: > > Si editas opcodes.c, veras al final de la linea 1 que hay un /* > que deberiamos quitar, asi como en otros ficheros. ARRRRRGGGG al final de la linea!!!!, y mira que busque el puto fallo, y no lo veia, y yo diciendo, pero si el comentario esta bien puesto de que se queja el puto gcc, brrrr. > Por otra parte, ¿usais el cvs? lo digo por saber si si hago cambios > ahi, si se perderan en el olvido, o serviran de algo :) Si, yo en cuanto hago un cambio y funciona, lo meto en el cvs, de echo ahora mismo la version 0.1.6 tiene un bug tonto ya que "el cañon de la gunstick esta desviado" tienes que apuntar unos 20 pixels por encima del blanco para darle, en el CVS esta solucionado. > > En particular si decidimos usar todos la 4 (cosa que aconsejo) quito un > > par de lineas que hay que dependian de la version. > mejor la 4, creo yo. Pues la 4 a la de 1, la 4 a la de dos... -- WINDOWS: a)Virus b)Oquedad mural por donde salen las máquinas infectadas. _ Grettings of __ _| |___ __ _ Al...@as... LiNUX USER #66734 Saludos / _` | / -_) _` | http://pagina.de/alea A_...@te... de \__,_|_\___\__,_| MS Messenger: alv...@ho... Para obtener Llave Publica GnuPGP un mail con subject: enviar clave pub |
From: Santiago R. <com...@es...> - 2002-10-10 17:43:57
|
El Thu, 10 Oct 2002 18:48:09 +0200, Kak <jb...@ti...> wrote: > >Os pego las URLs para que veáis los screenshots y me deis vuestra > >opinión de qué GUI tiene mejor pinta para Aspectrum: > >...... > > ui, a mi la verdad me da igual, no suelo fijarme en los guis de los > emuladores. Escoged la que mas os guste a vosotros :) Vale, pues la cosa queda entonces entre Alvaro y yo :-) > >Cargando el flying shark he visto que el color amarillo no se > >corresponde con el tono que hay en el spectrum... tenemos que > >"tomar prestada" una tabla de colores BUENA de algún emulador > >para ponerlo en aspectrum. ¿Algún candidato? ¿Pongo la del > >fuse o algún otro? > > cierto. note ese efecto en la Abadia del crimen, y tengo que > reconocer que con ese color quedaba mucho mejor! ;) > lo que no entiendo es porque los colores se ven "raros", ya que me > mire la tabla y me parecio que el valor del color estaba bien :( Yo también pensé que la tabla estaba bien hecha... pero no lo veo igual aquí que en otros emuladores. Por cierto, ya llegará el tiempo de aplicar filtrados para ver la pantalla como en una TV, igual que hace el glukalka :) > >Ah, y una de las cosas que hace fuse es tener una "dirty screen" > >que actualiza en pantalla sólo los cambios realizados, no la > >pantalla completa... ¿eso sería útil en aspectrum? > > el rendimiento tambien dependeria del tipo de juego :) editando basic > el aumento de velocidad puede ser *brutal*, pero con el cobra (donde > casi toda la pantalla es diferente cada vez) o similares no creo que > se note gran mejora ya, pero si es algo bueno, y no penaliza otros juegos, sería cuestión de pensarlo, no? saludos! -- Error: 1.414213562 (Excessive square root of 2) _O) NoP / Compiler | com...@es... - ICQ #98602813 /\\ Linux Debian 2.2 | http://escomposlinux.org/sromero - #74.821 \_V #74.821 \_V |
From: Kak <jb...@ti...> - 2002-10-10 17:06:26
|
lo mismo. vivan los duplicados! On Thu, 10 Oct 2002 18:48:09 +0200, Kak wrote: >On Wed, 9 Oct 2002 15:28:26 +0200, Santiago Romero wrote: >> >>=BFqu=E9 versi=F3n de allegro estamos usando? Lo digo por instalarme >>la 4, o alguna anterior si lo dec=EDs vosotros... > >yo uso la 3.9.3X, viejilla, ya lo se, pero me da un palo brutal >cambiar de version! XDDD > >de todas formas son todas bastante compatibles, no creo que la >version sea algo influyente, a no ser que se usen nuevas= funciones >(o >se hayan dejado de usar viejas) > > >>Os pego las URLs para que ve=E1is los screenshots y me deis= vuestra >>opini=F3n de qu=E9 GUI tiene mejor pinta para Aspectrum: >>...... > >ui, a mi la verdad me da igual, no suelo fijarme en los guis de= los >emuladores. Escoged la que mas os guste a vosotros :) > > >>Cargando el flying shark he visto que el color amarillo no se >>corresponde con el tono que hay en el spectrum... tenemos que >>"tomar prestada" una tabla de colores BUENA de alg=FAn emulador >>para ponerlo en aspectrum. =BFAlg=FAn candidato? =BFPongo la del >>fuse o alg=FAn otro? > >cierto. note ese efecto en la Abadia del crimen, y tengo que >reconocer que con ese color quedaba mucho mejor! ;) >lo que no entiendo es porque los colores se ven "raros", ya que= me >mire la tabla y me parecio que el valor del color estaba bien= :( > > >>Ah, y una de las cosas que hace fuse es tener una "dirty= screen" >>que actualiza en pantalla s=F3lo los cambios realizados, no la >>pantalla completa... =BFeso ser=EDa =FAtil en aspectrum? > >en modos de video con ventanitas (xwindows, windows, ...) se >aumentaria mucho la velocidad ya que las funciones no suelen= acceder >directamente al hardware, sino que pasan por las funciones de el= api >con el que les toque pelearse. En modos fullscreen (linux= consola, >msdos) no creo que el aumento de velocidad se notara mucho... > >el rendimiento tambien dependeria del tipo de juego :) editando >basic >el aumento de velocidad puede ser *brutal*, pero con el cobra= (donde >casi toda la pantalla es diferente cada vez) o similares no creo= que >se note gran mejora > >Bye :) >Kak |
From: Kak <jb...@ti...> - 2002-10-10 17:06:16
|
lo siento, pero estoy hasta los webos de esta mailing list que no= mete el nombre de la mailing antes que el nombre del que lo= envia! :) On Thu, 10 Oct 2002 18:39:09 +0200, Kak wrote: >On Wed, 9 Oct 2002 11:40:19 +0200, Alvaro Alea wrote: > >>Otro detalle que habria que valorar es si a Kak le afecta mucho= el >>no usar allegro, con respecto a zxdeb > >por eso no te preocupes, es cuestion de tirar palante el= proyecto >aspectrum y yo ya me espavilare en ese aspecto :) >tampoco me molestaria continuar con una "rama paralela", ya que= de >hecho muchas de estas cosas las hago para aprender, e ir= haciendo >cosas por mi mismo tampoco me matara ;) > >>Aun asi a mi me siguen sobrando 3560 estados T despues de la= int >>para que >>todo salga como debe, si lo hago todo segun el FAQ el horizonte= del >>aquaplane >>me sale 16 pixels mas abajo. > >a ver, en el faq de css dice: > >After an interrupt occurs, 64 line times (14336 T states) pass >before >the byte 16384 is displayed. At least the last 48 of these are >actual >border-lines; the others may be either border or vertical= retrace. > >Then the 192 screen+border lines are displayed, followed by 56 >border >lines again. > >- >o sea: se genera la interrupcion (supongamos que se hace en el >t-state 0) Entonces pasan 64 lineas entre retrace y borde, y >entonces >se empieza a pintar a partir del primer pixel de pantalla. >entonces pasan 192 lineas, y vienen 56 mas de borde otra vez > >(56+192+64) * 224 =3D 69988 >- > >Now for the timings of each line itself: define a screen line= to >start with 256 screen pixels, then border, then horizontal= retrace, >and then border again. All this takes 224 T states. Every half= T >state a pixel is written to the CRT, so if the ULA is reading= bytes >it does so each 4 T states (and then it reads two: a screen and= an >ATTR byte). The border is 48 pixels wide at each side. A video >screen >line is therefore timed as follows: 128 T states of screen, 24= T >states of right border, 48 T states of horizontal retrace and 24= T >states of left border. > >o sea, se pintan 256 pixels (de la pantalla). Despues viene el= borde >derecho, despues el horizontal retrace, y despues el borde= izquierdo >de la siguiente linea > >entonces, para la emulacion del port 0xff, lo que nos ocupa= (creo), >lo correcto seria hacer tstate actual % TSTATES_PER_LINE, y si= es ><128 entonces retornar un valor aleatorio, y si no es <128,= retornar >FF > > > > > >> >>>yo diria que los calculos (dejando a banda el error ese de= los >>>24/48) >>>estan bien, y incluso con ese error, el resultado a la hora= de >>>pintar >>>no deberia diferir, ya que no usamos para nada el 24/48, sino= que >>>usamos el TSTATES_PER_LINE. >>>entonces el que estaria mal emulado por culpa del 24/48 seria= el >>>port >>>0xff >> >>no me aclaro. >bueno, la explicacion correcta esta arriba :) diria que ahora= es >correcta y exacta... espero! xD > >Bye :) >Kak > |
From: Santiago R. <com...@es...> - 2002-10-10 08:29:44
|
En Thu, 10 Oct 2002 00:29:45 +0200 "Santiago Romero" <com...@es...> escribio: > Cargando el flying shark he visto que el color amarillo no se > corresponde con el tono que hay en el spectrum... tenemos que > "tomar prestada" una tabla de colores BUENA de algún emulador > para ponerlo en aspectrum. ¿Algún candidato? ¿Pongo la del > fuse o algún otro? En Aspectrum tenemos: static gRGB colores[17] = { { 0/4, 0/4, 0/4}, { 0/4, 0/4, 192/4}, { 192/4, 0/4, 0/4}, { 192/4, 0/4, 192/4}, { 0/4, 192/4, 0/4}, { 0/4, 192/4, 192/4}, { 192/4, 192/4, 0/4}, { 192/4, 192/4, 192/4}, { 0/4, 0/4, 0/4}, { 0/4, 0/4, 255/4}, { 255/4, 0/4, 0/4}, { 255/4, 0/4, 255/4}, { 0/4, 255/4, 0/4}, { 0/4, 255/4, 255/4}, { 255/4, 255/4, 0/4}, { 255/4, 255/4, 255/4}, { 255/4, 0/4, 0/4} Por otra parte, si descargais FUSE de Philip Kendall veréis que es aprovechable bastante código que nos puede servir, por ejemplo el fichero ay.* (para comparar), el fichero snapshots.* (para soportar más formatos), etc etc etc. Ah, y una de las cosas que hace fuse es tener una "dirty screen" que actualiza en pantalla sólo los cambios realizados, no la pantalla completa... ¿eso sería útil en aspectrum? Reconozco que tengo que remirarme el código de aspectrum porque todavía no conozco a qué nivel habéis hecho los cambios... :( saludos! -- Santiago Romero Departamento de Sistemas sr...@se... Av. Primado Reig 189, entlo 46020 Valencia - Spain Telf. (+34) 96 332 12 00 Fax. (+34) 96 332 12 01 http://www.servicom2000.com |
From: Santiago R. <com...@es...> - 2002-10-09 22:31:18
|
Cargando el flying shark he visto que el color amarillo no se corresponde con el tono que hay en el spectrum... tenemos que "tomar prestada" una tabla de colores BUENA de algún emulador para ponerlo en aspectrum. ¿Algún candidato? ¿Pongo la del fuse o algún otro? -- M&$turb&r$e en exce$0 &f3c7& & l& v!$!0n _O) NoP / Compiler | com...@es... - ICQ #98602813 /\\ Linux Debian 2.2 | http://escomposlinux.org/sromero - #74.821 \_V |
From: Santiago R. <com...@es...> - 2002-10-09 13:51:10
|
He estado buscando GUIs para Allegro. Sé que os gustaría que el menú de Aspectrum fuera tipo +3 y demás, pero no estoy seguro de que sea sencillo. Algunos de los guis que os presento permiten customización del aspecto, pero no creo que deba ser la prioridad principal... :-? Os pego las URLs para que veáis los screenshots y me deis vuestra opinión de qué GUI tiene mejor pinta para Aspectrum: http://www.steinke.net/allegro/ (sólo el tercer tema es "bonito", pero parecen MODIFICABLES!). http://www.lwithers.demon.co.uk/prog/allegro/more_gui/ (no hay foto, si veis el ejemplo igual sacais algo en claro) http://www.alphalink.com.au/~tjaden/agup/ (sólo el tema photon es bonito) http://www.concentric.net/~skis/ (algo fea IMHO) http://www.idt.mdh.se/personal/csg/cgui/ (mirad los screenshots, se me cae la baba!!!!) http://dime.sourceforge.net/ (Es bonito Y muy facil de usar, mirad el ejemplo del screenshot cómo se ha generado, el código es apenas una línea!!!!!!!!). http://www.geocities.com/miran014/html/masking.html (es bonito y también soporta temas) Cuando podais les echais un vistazo, mirais lo que dicen de ellos y me valorais cada uno de vosotros 2 cuál preferís para allegro. Yo me quedo en este orden con: CGUI DIME MASKING ¿Qué opinais? -- "Hola, soy el nuevo Pentium 5 ¿qué? ¿2+2? fácil, 3.9999999999" -- reset _O) NoP / Compiler | com...@es... - ICQ #98602813 /\\ Linux Debian 2.2 | http://escomposlinux.org/sromero - #74.821 \_V |
From: Santiago R. <com...@es...> - 2002-10-09 13:29:58
|
¿qué versión de allegro estamos usando? Lo digo por instalarme la 4, o alguna anterior si lo decís vosotros... saludos! -- "Hola, soy el nuevo Pentium 5 ¿qué? ¿2+2? fácil, 3.9999999999" -- reset _O) NoP / Compiler | com...@es... - ICQ #98602813 /\\ Linux Debian 2.2 | http://escomposlinux.org/sromero - #74.821 \_V |
From: Santiago R. <com...@es...> - 2002-10-09 11:25:12
|
El Wed, 9 Oct 2002 11:29:02 +0200, Alvaro Alea <A_...@te...> wrote: > > Lo primero que quiero hacer es remodelar la Web de Aspectrum para que > > enlace directamente a los .tar.gz de sourceforge y darle un aspecto más > > renovado indicando lo que ya soporta. Para ello necesito que me digais > > todo lo que ya hace Aspectrum en plan propaganda. > > Si, eso es algo que yo tambien tenia ganas de hacer, que al menos tubiese > una seccion de screenshots, una con noticias (y a ser posible que las > pillase directamente de las noticias de sourceforge) y otra para los > downloads. Sí, creo que sería una buena idea. > > Otra cosa que hay que hacer es cambiar los créditos. Creo que ya no es > > sólo mi emulador. Es nuestro emulador, y como tal debéis aparecer en > > hecho :-) Me alegro :))) > > todos los créditos en igualdad de condiciones. Yo me tiré 2 años para > > Uff, te lo curraste no llegaba a imaginar cuanto se podria tardar en > hacer eso. Sí, hijo, sí. Creo que un día os contaré lo emocionante del proceso: cargué la rom en memoria, e hice los ficheros opcodes_*.c de forma que sólo tenían el caso default: donde ponia: "Opcode no implementado %d (etc...)" Empecé a emular la ROM, e iba implementando instrucciones conforme iba fallando el arranque del Spectrum. Llegó un momento en que hice la función DisplayScreen() para ver qué hacía ya mi emulador, y llegué a ver el borrado de pantalla, pero me quedé atrancado en que no salía el mensaje de (c). Tras corregir una instrucción que tenía mal apareció y casi me meo en el momento :) > > Otra cosa que tenemos que decidir es qué hacemos con SDL. Os explico: > > yo empecé el emulador en SDL, y funcionaba estupendamente, pero como > > yo sabía más de allegro que de SDL, pues lo pasé a Allegro. Al hacerlo > > perdí casi un 20% de rendimiento, cosa que en un emulador se nota. > > Vamos, que si con SDL corria en mi Pentium 120, con Allegro tenía que > > saltarse > > En un P166MMX va bien (a 50fps) dentro de algunos dias os digo en un 486 > a 133. Entonces creo que Allegro no está haciendo tan mal trabajo... Además, acabo de ver que ha sido introducida en la versión ACTUAL de Debian: [sromero@compiler:~]$ apt-cache search allegro allegro-demo - cool game, demonstrating power of the Allegro library allegro-demo-data - datafile for the allegro-demo game allegro-examples - example programs and demo tools for the Allegro library cl-acl-compat - Compatibility layer for Allegro Common Lisp cl-sql-aodbc - CLSQL database backend, AODBC cl-uffi - Universal Foreign Function Library for Common Lisp liballegro-dev - Development files for the Allegro library liballegro-doc - Documentation for the Allegro library liballegro4a - portable library for cross-platform game and multimedia development ilisp - Package for interacting with LISPs using EMACSes acl-alisp - Common Lisp Controller implemention for Allegro's alisp compiler acl-alisp8 - Common Lisp Controller implemention for Allegro's alisp8 compiler acl-installer - Installer for Franz' Allegro 6.2 Lisp Trial Edition acl-mlisp - Common Lisp Controller implemention for Allegro's mlisp compiler acl-mlisp8 - Common Lisp Controller implemention for Allegro's mlisp8 compiler acl-pro-installer - Installer for Franz' Allegro 6.2 Lisp Commercial Versions liballegro3.9.36-dev - Development files for the Allegro library liballegro4 - portable library for cross-platform game and multimedia development liballegro3.9.36-dev-common - Development utils for the Allegro library liballegro3.9.40 - portable library for cross-platform game and multimedia development liballegro3.9.36 - portable library for cross-platform game and multimedia development Si además de esto hay RPMs para Redhat y para Mandrake (las mayoritarias) y hay paquete source disponible para gentoo (nueva revelación de la temporada), ya no veo motivo alguno para pasarlo a SDL, siempre que allegro soporte más plataformas destino que SDL. > En realidad siempre se podria hacer un port de allegro encima de SDL. Sí, es cierto. Con lo cual por ahora nos podemos olvidar de allegro, ya que en cualquier momento bastaría con modificar las funciones v_* y el gui. > Humm, no habia caido en eso, tengo que darme una vuelta por > www.libsdl.org Lo que hay que hacer es buscar librerias de GUIs para allegro que permitan modificar el aspecto. Yo me encargo de esto: el gui es muy importante porque sobre él se realizan las configuraciones y algunas de las cosas que me tocan a mi (Pokes, etc) de modo que antes de poder hacer nada de eso hace falta una buena librería de GUI. Dejadme a mi encargado del gui por ahora :) > Si, eso pasaba con la 3.99 WIP usando pantalla completa, tambien se > llevaba fatal con la barra de gnome, por no hablar de que aun se niega a > poner 320x240 en mi ordenador o el bug del hline. > > Pero hay que recordar que era un WIP, ni siquiera era una beta. Pero ya no pasa? liballegro4a - portable library for cross-platform game and multimedia development allegro 4?? > Por cierto que te toca a ti decidir el tamaño de las paginas de ram > X'DDDD A mi???? yo voto lo que diga la rubia. XD > Otro detalle que habria que valorar es si a Kak le afecta mucho el no > usar allegro, con respecto a zxdeb Nada, decidido, no hace falta SDL por ahora. Si algun dia hubiera que migrar, ya sabemos que el cambio es "facil". Bueno, pues al menos ya tenemos algo claro. Además ya verás como ALGUIEN se toma la molestia por nosotros de hacer un port para SDL, muchas veces lo hacen X'D En fin, voy a buscar librerias de guis para allegro, y si no existen la intentaré hacer yo (aunque será un coñazo, me lo veo venir). -- "Hola, soy el nuevo Pentium 5 ¿qué? ¿2+2? fácil, 3.9999999999" -- reset _O) NoP / Compiler | com...@es... - ICQ #98602813 /\\ Linux Debian 2.2 | http://escomposlinux.org/sromero - #74.821 \_V |
From: Alvaro A. <A_...@te...> - 2002-10-09 00:44:02
|
BUENOS DIAS!!! Y entonces, va Kak y dice ¿Re: [Aspectrum-devel] Nueva version.? > cierto! > de hecho con esto ahora mismo acabo de recordar porque meti 48 :) la > cosa esta en que el dibujado del "grafico" dura 128 tstates, cosa que > deja 96 tstates para el resto. Entonces dividi eso por 2, y lo asigne > a cada banda del retrace. > podria ser que el fallo de velocidad fuera por esto, pero entonces no > entenderia porque en mi version funciona bien y en otras no :( ni yo. > superior/inferior pasa algo similar: no mostramos todo el borde con > lo que se pueden asignar lineas a partes no visibles. Aun asi a mi me siguen sobrando 3560 estados T despues de la int para que todo salga como debe, si lo hago todo segun el FAQ el horizonte del aquaplane me sale 16 pixels mas abajo. > yo diria que los calculos (dejando a banda el error ese de los 24/48) > estan bien, y incluso con ese error, el resultado a la hora de pintar > no deberia diferir, ya que no usamos para nada el 24/48, sino que > usamos el TSTATES_PER_LINE. > entonces el que estaria mal emulado por culpa del 24/48 seria el port > 0xff no me aclaro. -- Por fin ya he descubierto lo mejor de Windows 95: UNINSTALL.EXE _ Grettings of __ _| |___ __ _ Al...@as... LiNUX USER #66734 Saludos / _` | / -_) _` | http://pagina.de/alea A_...@te... de \__,_|_\___\__,_| MS Messenger: alv...@ho... Para obtener Llave Publica GnuPGP un mail con subject: enviar clave pub |
From: Alvaro A. <A_...@te...> - 2002-10-09 00:32:38
|
BUENOS DIAS!!! Y entonces, va Santiago Romero y dice ¿Re: [Aspectrum-devel] Futuro? > En Mon, 7 Oct 2002 23:36:21 +0200 "Kak" <jb...@ti...> escribio: > > > la emulacion del 128 y +2 va perfecta, (yo no he encontrado ningun > > la musica 128 ... bueno, pues suena... se parece al resultado final, > ¿De verdad Aspectrum hace ya todo eso? ¡Qué gran trabajo estáis haciendo! en realidad no, el que lo hace es zxdeb, pero casi casi.. > Lo primero que quiero hacer es remodelar la Web de Aspectrum para que > enlace directamente a los .tar.gz de sourceforge y darle un aspecto más > renovado indicando lo que ya soporta. Para ello necesito que me digais > todo lo que ya hace Aspectrum en plan propaganda. Si, eso es algo que yo tambien tenia ganas de hacer, que al menos tubiese una seccion de screenshots, una con noticias (y a ser posible que las pillase directamente de las noticias de sourceforge) y otra para los downloads. > Otra cosa que hay que hacer es cambiar los créditos. Creo que ya no es > sólo mi emulador. Es nuestro emulador, y como tal debéis aparecer en echo :-) > todos los créditos en igualdad de condiciones. Yo me tiré 2 años para Uff, te lo curraste no llegaba a imaginar cuanto se podria tardar en hacer eso. > hacerlo arrancar, pero una vez en marcha sin vuestra ayuda seguramente > estaría pagado. > Otra cosa que tenemos que decidir es qué hacemos con SDL. Os explico: > yo empecé el emulador en SDL, y funcionaba estupendamente, pero como > yo sabía más de allegro que de SDL, pues lo pasé a Allegro. Al hacerlo > perdí casi un 20% de rendimiento, cosa que en un emulador se nota. Vamos, > que si con SDL corria en mi Pentium 120, con Allegro tenía que saltarse En un P166MMX va bien (a 50fps) dentro de algunos dias os digo en un 486 a 133. > frames... Lo del rendimiento tiene un punto importante... si sale un > backend de SDL para gameboy advance, por ejemplo, imaginaros que el > emulador pudiera correr allí!!! O de PSX, o de lo que sea. En realidad siempre se podria hacer un port de allegro encima de SDL. > La pregunta es: ¿Lo pasamos a SDL como único lenguaje? (no debería costar, > pues recordad que apenas pintamos píxeles en pantalla y poco más). ¿Lo > ponemos como opción en tiempo de compilación? (esto me parece exagerado). Pues a mi no. > Por el GUI, Alvaro, no te preocupes, porque SDL es basico (acceso a los > píxeles) pero hay por ahi MUCHAS librerias basadas en SDL: SDL_gui, > SDL_ttf (fuentes truetype), SDL_image, SDL_mixer, etc. Como tal, funcionan > en todas las plataformas que lo hace SDL... Humm, no habia caido en eso, tengo que darme una vuelta por www.libsdl.org > Vamos a pensar un poquito en este tema a ver si sacamos en claro alguna > decisión. Aparte del código ya hecho y de la comodidad de que todos conoce- > mos allegro, ¿qué ventajas le veis a allegro? ¿Que mame esté hecho en > Allegro nos debe dar tranquilidad? Yo es que veo SDL MUY extendido (las > librerias de SDL vienen en todas las distribuciones) mientras que las libs > de allegro no. Ha habido gente de #escomposlinux que no ha querido probar > aspectrum porque al ejecutarlo le pedia las allegro y no venian en rpm/deb > y no querían instalar ficheros compilados (llenar el arbol de directorios > de cosas compiladas, vamos). Además algunos de ellos se les fueron abajo > las XWindow al ejecutar el emulador (creo que era cosa de allegro). Si, eso pasaba con la 3.99 WIP usando pantalla completa, tambien se llevaba fatal con la barra de gnome, por no hablar de que aun se niega a poner 320x240 en mi ordenador o el bug del hline. Pero hay que recordar que era un WIP, ni siquiera era una beta. > Sé que MAME usa allegro, y también RAINE, pero no sé si sería más rentable Y realspectrum :-) > SDL. Igual no es necesario, yo no tengo acciones de SDL, si me convenceis > dándome motivos, yo cambiaré mi opinión. Además ahora como mínimo hay que > votar, porque somos 3 los que somos autores de este emulador y como tales > debemos decidir democráticamente qué caminos votar :-) Por cierto que te toca a ti decidir el tamaño de las paginas de ram X'DDDD Personalmente el encapsulamiento me rebienta, (no es el unico detalle del que no estoy contento, pero he de admitir que son preferencias personales) pero para portarlo a SDL he de admitir que solo hay que cambiar un archivo v_allegro.c y algun detalle mas por ahi. Lo que si hay que tener en cuenta es que muchas de las funciones de v_allegro.c son simplemente añadir una letra al nombre de la funcion, pero en el futuro hay que tener una plataforma como base y portarlo a la otra. Otro detalle que habria que valorar es si a Kak le afecta mucho el no usar allegro, con respecto a zxdeb En win32 y Dos mi unica experiencia es con allegro, y su instalacion es muy sencillita, en el caso de linux, tanto sdl como allegro vienen con mi distro, y estan instalados todo el rato, asi que no se cual es mas comodo. En resumen estoy con Kak y creo que estaria bien durante un tiempo soportar las dos librerias, y luego mas adelante en funcion de lo versatil que sea una u otra decidir. -- "640 kb should be sufficient for anyone" -Bill Gates, 1981 | _ Grettings of __ _| |___ __ _ Al...@as... LiNUX USER #66734 Saludos / _` | / -_) _` | http://pagina.de/alea A_...@te... de \__,_|_\___\__,_| MS Messenger: alv...@ho... Para obtener Llave Publica GnuPGP un mail con subject: enviar clave pub |
From: Alvaro A. <A_...@te...> - 2002-10-08 23:54:22
|
Otro que vais a recibir duplicado, grrr ----- Forwarded message from Alvaro Alea <A_...@te...> ----- From: Alvaro Alea <A_...@te...> To: Kak <jb...@ti...> Subject: Re: [Aspectrum-devel] Nueva version. Organization: ALEAsoft & Hardware Corporation X-Operating-System: Linux www.aleasoft.org 2.4.19 i586 BUENOS DIAS!!! Y entonces, va Kak y dice ¿Re: [Aspectrum-devel] Nueva version.? > On Wed, 9 Oct 2002 00:15:43 +0200, Alvaro Alea wrote: > no se, es cuestion de gustos, pero yo diria que con una tabla de 70 > kas se gana mucha velocidad. Y si no piensa en que Raul Gomez nos > comento una vez que tenia 2 megas de tablas precalculadas en el R80 > :) de las 70 kas a las 2 megas aun nos queda ;) > por cierto, en el +2a y +3 el port 0xff no funciona (siempre retorna > FF), con lo que ademas estaras emulando el port 0xff *siempre* sin > necesidad de ello Yo habia pensado en la siguiente solucion: cuando se declara el hardware se pone si se quiere emular el port FF o no 0xFF = si 0x00 = no luego en el bucle, en lugar de hacer: hwopt.port_FF=0xFF hwopt.port_FF=0x00 como hago ahora hacer: hwopt.port_FF|=0x01 hwopt.port_FF&=0xFE y el bucle igual if hwopt.port_FF==0xFF return 0xFF else return rand()%0xFE Y ya ta, de todas maneras, pa mi que el error no esta exactamente en esto, tendra que ver con esto, pero no es esto, por que probe a comentar mi trozo en la parte del IN y descomentar tu trozo y sige dando saltitos cuando no hay enemigos. ademas tengo un problema MUY GRAVE con los tiempos, explico: Segun el FAQ de ESC css el tiempo es asi: Interupcion 16 lineas que pueden ser de retrazo, o pueden ser de borde superior (supongo que esto es debido a que las teles se comen un trocito de pantalla 48 lineas de borde superior 192 la zona grafica 48 bueno no estoy seguro, pero aprox, del borde inferior 8 del retrazo vertical. total 312 Aqui ya la empezamos a cagar por que segun eso hay 64 lineas antes de empezar a dibujar el primer pixel, pero segun los ajustes que yo hice a ojo con el aquaplane para que el horizonte se dibuje bien solo tiene que pasar 48. ademas esta el impreciso echo de que siempre oi que la int se producial al comienzo del dibujar el frame, no en medio del retrazo vertical, asi que pa mi que se han colao y esos 16 van con los 8 del final. luego dice: la linea horizontal se divide en: 128 lineas de la zona grafica 24 lineas del borde derecho 48 lineas del retrazo horizontal (el fallo va a estar aqui acuerdate que me dijiste que cambiase el 48 por 24 y yo lo hice a ojos cerrados, la version que sace tiene 48 estados t menos cada linea grafica ) 24 lineas del borde izquierdo (ojo con el orden, es importante, empieza las lineas en en borde grafico) total 224 que si lo multiplicamos por 312 dan los 69880 estados t por frame. Ahora la volvemos cagar, dice asi que 224*64 t estados tras la interrupcion es cuando se empieza a pintar el pixel (0,0), gueno, pues en mi opinion 224*64 es cuando se deberia empezar a pintar el borde izquierdo de la linea del pixel (0,0), y 24 estados t mas tarde se empezaria a pintar el pixel (0,0) o de lo contrario la interrupcion se generaria en medio de una linea, lo cual no tiene mucho sentido, ademas de que me faltan 24 tstates al principio y me sobran al final. BRRR bueno, a ver que opinais, yo a seguir investigando. -- No me gustan los Taglines _ Grettings of __ _| |___ __ _ Al...@as... LiNUX USER #66734 Saludos / _` | / -_) _` | http://pagina.de/alea A_...@te... de \__,_|_\___\__,_| MS Messenger: alv...@ho... Para obtener Llave Publica GnuPGP un mail con subject: enviar clave pub |
From: Alvaro A. <A_...@te...> - 2002-10-08 23:53:34
|
Ala, otro que me equivoco, esto esta dejando de ser divertido. siento los duplicados. ----- Forwarded message from Alvaro Alea <A_...@te...> ----- From: Alvaro Alea <A_...@te...> To: Santiago Romero <com...@es...> Subject: Re: [Aspectrum-devel] Futuro Organization: ALEAsoft & Hardware Corporation X-Operating-System: Linux www.aleasoft.org 2.4.19 i586 BUENOS DIAS!!! Y entonces, va Santiago Romero y dice ¿Re: [Aspectrum-devel] Futuro? > En Tue, 8 Oct 2002 11:17:39 +0200 "Santiago Romero" > <com...@es...> escribio: Respecto al enlace a la ultima version, no se puede hacer, sourceforge tiene un sistema de mirrors que te obligan a selecionar uno antes de poder bajartelo. Al menos esa es la respuesta corta, por supuesto que a mano se podria hacer. > Necesitaría también que se cree un enlace tipo > aspectrum-latest.tar.gz que apunte a la ultima version siempre del > emulador en tar.gz para usarlo en mi web y no tener que ir cambiando > la web cada vez que sale una subrelease nueva. En la pagina de admin del proyecto aspectrum en sourceforge encontraras un enlace a un tgz con el snapshot diario del CVS. > Aparte, me podriais decir el CVSROOT y checkout que debo hacer para > descargar aspectrum en sourceforge? Voy a intentar incluso echarle > vistazos en el curro, en el tiempo libre. Ni idea, pero hay algo de eso en la misma pagina de sourceforge, quiza te sirva. > Por otra parte la semana que viene estoy de vacaciones (después de > 1 año!!!) así que no os extrañeis de dejar de leerme en ese momento. > Me he propuesto continuar con Aspectrum. Bueno, pues nada, felices vacaciones. > Voy a buscar a ver si hay librerias de guis para allegro que permitan > cambiar los widgets. En el caso de SDL se podría usar en conjunción > con gtk, pero no sé si allegro puede. Si hay otros guis, con otros widgets, de echo yo tengo uno por aqui con un aspecto a lo macos aqua, pero no es compatible a nivel de codigo, o eso creo. en el caso de sdl lo ideal era: - Crear uno independiente de la plataforma - Utilizar wxwindows (creo que se llama asi) que lo hay pa linux/win/mac al menos. -- Creo que se me ha muerto el ratón. No ha comido nada de queso. _ Grettings of __ _| |___ __ _ Al...@as... LiNUX USER #66734 Saludos / _` | / -_) _` | http://pagina.de/alea A_...@te... de \__,_|_\___\__,_| MS Messenger: alv...@ho... Para obtener Llave Publica GnuPGP un mail con subject: enviar clave pub ----- End forwarded message ----- -- Are you sure you want to quit this great game? _ Grettings of __ _| |___ __ _ Al...@as... LiNUX USER #66734 Saludos / _` | / -_) _` | http://pagina.de/alea A_...@te... de \__,_|_\___\__,_| MS Messenger: alv...@ho... Para obtener Llave Publica GnuPGP un mail con subject: enviar clave pub |
From: Kak <jb...@ti...> - 2002-10-08 18:55:28
|
On Wed, 9 Oct 2002 20:07:31 +0200, Alvaro Alea wrote: >Yo habia pensado en la siguiente solucion: >cuando se declara el hardware se pone si se quiere emular el= port FF >o no >0xFF =3D si >0x00 =3D no > >luego en el bucle, en lugar de hacer: >hwopt.port_FF=3D0xFF >hwopt.port_FF=3D0x00 > >como hago ahora hacer: >hwopt.port_FF|=3D0x01 >hwopt.port_FF&=3D0xFE si, pero el problema es este: haces. la cosa esta en que si el port 0xff no se lee, estas haciendo= cerca de 384 operaciones extras por frame (2 por scanline) para que= solo un 0.5% de los juegos saquen beneficio, mientras se penaliza al= 99.5% de juegos que no usan el port 0xff con 384 operaciones mas por= frame. ya te digo, a mi en principio me da igual hacer un metodo u otro,= pues creo que en mi ordenador ira bien de las dos formas ;) la cosa esta en que si se quiere hacer rapido para ordenadores= mas lentos, la tabla es lo mas rapido. Si me apuras por el tamanyo de= memoria que ocupa ;), se podria dividir por 4 y "aproximar" al= tstate mas proximo: como todas las instrucciones duran mas de 4 tstates= no tendria que suponer ningun problema, y de todas formas si se hace= como esta ahora ese error tambien esta presente, puesto que= cuando decimos que emule por N tstates, en realidad suele emular por excederse de 0 a 15 tstates >Y ya ta, de todas maneras, pa mi que el error no esta= exactamente en >esto, >tendra que ver con esto, pero no es esto, por que probe a= comentar >mi trozo >en la parte del IN y descomentar tu trozo y sige dando saltitos >cuando no hay >enemigos. entonces quizas sea cosa del cambio de plataforma, pues a mi la version con mi trozo no me salta :( tambien se nota mucho en el sonido, ya que se acelera bastante= cuando no hay ningun bicho por ahi. >ademas tengo un problema MUY GRAVE con los tiempos, explico: > >Segun el FAQ de ESC css el tiempo es asi: > >Interupcion >16 lineas que pueden ser de retrazo, o pueden ser de borde= superior >(supongo >que esto es debido a que las teles se comen un trocito de >pantalla >48 lineas de borde superior >192 la zona grafica >48 bueno no estoy seguro, pero aprox, del borde inferior >8 del retrazo vertical. > >total 312 > >Aqui ya la empezamos a cagar por que segun eso hay 64 lineas= antes >de empezar >a dibujar el primer pixel, pero segun los ajustes que yo hice a= ojo >con el >aquaplane para que el horizonte se dibuje bien solo tiene que= pasar >48. > >ademas esta el impreciso echo de que siempre oi que la int se >producial al >comienzo del dibujar el frame, no en medio del retrazo vertical,= asi >que pa >mi que se han colao y esos 16 van con los 8 del final. > > >luego dice: >la linea horizontal se divide en: >128 lineas de la zona grafica >24 lineas del borde derecho >48 lineas del retrazo horizontal (el fallo va a estar aqui= acuerdate >que me >dijiste que cambiase el 48 por 24 y yo lo hice a ojos cerrados,= la >version >que sace tiene 48 estados t menos cada linea grafica ) >24 lineas del borde izquierdo > >(ojo con el orden, es importante, empieza las lineas en en= borde >grafico) cierto! de hecho con esto ahora mismo acabo de recordar porque meti 48 :)= la cosa esta en que el dibujado del "grafico" dura 128 tstates, cosa= que deja 96 tstates para el resto. Entonces dividi eso por 2, y lo= asigne a cada banda del retrace. podria ser que el fallo de velocidad fuera por esto, pero= entonces no entenderia porque en mi version funciona bien y en otras no :( De todas formas como no mostramos todo el borde (solo 8 pixels= por lado) no tendria que suponer ningun problema. Con los bordes superior/inferior pasa algo similar: no mostramos todo el borde= con lo que se pueden asignar lineas a partes no visibles. >total 224 que si lo multiplicamos por 312 dan los 69880 estados= t >por frame. > >Ahora la volvemos cagar, dice asi que 224*64 t estados tras la >interrupcion es cuando se empieza a pintar el pixel (0,0),= gueno, >pues en mi >opinion 224*64 es cuando se deberia empezar a pintar el borde >izquierdo >de la linea del pixel (0,0), y 24 estados t mas tarde se= empezaria a >pintar >el pixel (0,0) o de lo contrario la interrupcion se generaria= en >medio de una >linea, lo cual no tiene mucho sentido, ademas de que me faltan= 24 >tstates >al principio y me sobran al final. mmm... en principio se empieza a pintar al final del= correspondiente scanline: basandome en los sources antiguos... o sea, primero pasan 64 lineas donde no se pintan graficos (TSTATES_PER_LINE*TOP_BORDER_LINES) despues se emula 1 linea completa (TSTATES_PER_LINE), da igual= que sean 24,48 o 200 de borde: lo que cuenta es TSTATES_PER_LINE y entonces, una vez ya esta emulada, se pinta la linea con el DisplayScanline bueno, segun veo el displayscanline esta antes de emular la linea= y no despues... supongo que seria mejor tenerlo al final de emular= la linea. De todas formas, da igual cuando empiece el 0,0 ya que no= dibujamos con "precision de pixel", sino de linea. Mientras acertemos donde= empieza la linea y donde acaba, el resultado deberia estar bien. y una vez hecho esto 192 lineas, se pintan 56 mas (cosa que hacen= 312 lineas en total para el 48) yo diria que los calculos (dejando a banda el error ese de los= 24/48) estan bien, y incluso con ese error, el resultado a la hora de= pintar no deberia diferir, ya que no usamos para nada el 24/48, sino que= usamos el TSTATES_PER_LINE. entonces el que estaria mal emulado por culpa del 24/48 seria el= port 0xff Bye :) Kak |
From: Kak <jb...@ti...> - 2002-10-08 17:06:43
|
perdonad mi correo que no sabe lo que se hace :) On Wed, 9 Oct 2002 00:15:43 +0200, Alvaro Alea wrote: >bueno, la solucion que yo habia pensado es un poco parecida a= esa, >pero >sin array (que soy un poco reacio a usarlos para estas cosas),= en el >bucle principal tengo una variable que esta a 0xff todo el >tiempo escepto cuando dibuja la zona grafica. pero no se por= que >falla. > >de todas maneras preferiria mantener el gasto de memoria dentro= de >unos >limites. hombre, pero piensa que tal y como lo estas haciendo ahora,= estas emulando el port FF todo el rato. Eso significa que ni que el programa no lo use (una gran mayoria de juegos no usan el port= FF, solo los que se quedan colgados en el +2a/+3, o sea cobra, ark2= y pocos mas) lo estas emulando igualmente. no se, es cuestion de gustos, pero yo diria que con una tabla de= 70 kas se gana mucha velocidad. Y si no piensa en que Raul Gomez= nos comento una vez que tenia 2 megas de tablas precalculadas en el= R80 :) de las 70 kas a las 2 megas aun nos queda ;) por cierto, en el +2a y +3 el port 0xff no funciona (siempre= retorna FF), con lo que ademas estaras emulando el port 0xff *siempre*= sin necesidad de ello bye :) Kak |
From: Kak <jb...@ti...> - 2002-10-08 16:46:04
|
On Wed, 9 Oct 2002 00:29:38 +0200, Alvaro Alea wrote: >Aqui tengo una curiosidad personal =BFsabes como va lo de los= canales >de ruido? >parece ser que a muchos emuladores no funcionan los= "sintetizadores >de voz", >p.e. chase HQ, por algo relacionado con el canal de ruido, y me >huelo que >tiene algo que ver con las diferencias entre samples= aleatorios, >ruido rosa y >ruido blanco, pero no encontre nada que lo aclare pues la verdad es que he encontrado muy poca informacion sobre= los canales de ruido. tengo una idea de como emularlos, pero aun no= me he metido con ellos .... >La pregunta es: =BFLo pasamos a SDL como =FAnico lenguaje? (no= deber=EDa >costar,pues recordad que apenas pintamos p=EDxeles en pantalla y= poco >m=E1s). =BFLo ponemos como opci=F3n en tiempo de compilaci=F3n? (esto me= >parece exagerado). mmm... yo en principio no tengo nada a favor ni en contra de= allegro ni de sdl: allegro lo conozco bastante y me parece bastante= decente, sdl lo conozco poco pero creo que esta a la par (quiero decir que= no es un 300% mas potente ni un 300% mas lento, sera algo logico..= un 20% me parece eso, logico) vamos, que en principio me daria igual allegro que sdl. Lo que no= encuentro logico es hacerlo como "libreria unica", pues ya que tenemos (casi) todas las funciones encapsuladas de forma que sea= facil cambiar de libreria, seria una lastima tirarlo ahora= apostando por una libreria unica. Es cierto que en caso de aparecer sdl para gba o psx (cosa que= dudo) se podria portar a esas plataformas (cosa que tambien dudo puesto= que son maquinas a 16 y 33 mhz respectivamente), pero justamente= optando por una libreria unica sacrificamos eso mismo, la portabilidad: ahora mismo tenemos el sistema de funciones "v_" que nos= encapsulan las llamadas a la libreria. Si optamos por sdl podremos portar UNICAMENTE a plataformas con SDL (que no son pocas, pero no son todas). En cambio continuando con ese sistema, podremos tener aspectrum en plataformas con SDL, con Allegro, o con la= plataforma que sea simplemente reescribiendo el fichero v_alleg.c en fin, mi opinion es esa: ningun problema con hacerlo tambien= con sdl, pero yo no lo transformaria a "libreria unica" Bye :) kak |
From: Kak <jb...@ti...> - 2002-10-08 16:37:44
|
On Wed, 9 Oct 2002 00:15:43 +0200, Alvaro Alea wrote: >bueno, la solucion que yo habia pensado es un poco parecida a= esa, >pero >sin array (que soy un poco reacio a usarlos para estas cosas),= en el >bucle principal tengo una variable que esta a 0xff todo el >tiempo escepto cuando dibuja la zona grafica. pero no se por= que >falla. > >de todas maneras preferiria mantener el gasto de memoria dentro= de >unos >limites. hombre, pero piensa que tal y como lo estas haciendo ahora, estas= emulando el port FF todo el rato. Eso significa que ni que el programa no lo use (una gran mayoria de juegos no usan el port= FF, solo los que se quedan colgados en el +2a/+3, o sea cobra, ark2 y= pocos mas) lo estas emulando igualmente. no se, es cuestion de gustos, pero yo diria que con una tabla de= 70 kas se gana mucha velocidad. Y si no piensa en que Raul Gomez nos= comento una vez que tenia 2 megas de tablas precalculadas en el= R80 :) de las 70 kas a las 2 megas aun nos queda ;) por cierto, en el +2a y +3 el port 0xff no funciona (siempre= retorna FF), con lo que ademas estaras emulando el port 0xff *siempre*= sin necesidad de ello bye :) Kak |
From: Santiago R. <com...@es...> - 2002-10-08 09:30:01
|
En Tue, 8 Oct 2002 11:17:39 +0200 "Santiago Romero" <com...@es...> escribio: Necesitaría también que se cree un enlace tipo aspectrum-latest.tar.gz que apunte a la ultima version siempre del emulador en tar.gz para usarlo en mi web y no tener que ir cambiando la web cada vez que sale una subrelease nueva. Aparte, me podriais decir el CVSROOT y checkout que debo hacer para descargar aspectrum en sourceforge? Voy a intentar incluso echarle vistazos en el curro, en el tiempo libre. Por otra parte la semana que viene estoy de vacaciones (después de 1 año!!!) así que no os extrañeis de dejar de leerme en ese momento. Me he propuesto continuar con Aspectrum. Voy a buscar a ver si hay librerias de guis para allegro que permitan cambiar los widgets. En el caso de SDL se podría usar en conjunción con gtk, pero no sé si allegro puede. saludetes. -- Santiago Romero Departamento de Sistemas sr...@se... Av. Primado Reig 189, entlo 46020 Valencia - Spain Telf. (+34) 96 332 12 00 Fax. (+34) 96 332 12 01 http://www.servicom2000.com |
From: Santiago R. <com...@es...> - 2002-10-08 09:19:50
|
En Mon, 7 Oct 2002 23:36:21 +0200 "Kak" <jb...@ti...> escribio: > la emulacion del 128 y +2 va perfecta, (yo no he encontrado ningun > fallo aun) la emulacion del +2a y del +3 es bastante trivial a partir > > la musica 128 ... bueno, pues suena... se parece al resultado final, > algunas melodias las toca bien, algunas no, pero aun le falta > perfectamente en el modo 128 :) como que lo de la paginacion es algo > totalmente independiente del .tap, pues carga la cinta el solito y > pagina el propio programa :) ¿De verdad Aspectrum hace ya todo eso? ¡Qué gran trabajo estáis haciendo! Creo que es el momento de ponerme en serio de nuevo con aspectrum y contribuir al trabajo que estais metiendo en él. Yo lo dejé un poco de lado porque nadie me ayudaba (sólo Alvaro, y seguía teniendo mucho curro aún así con su ayuda) y por falta de tiempo lo dejé parado. Ver este avance realmente motiva, y es donde uno se da cuenta PORQUE es importante la GPL, ya que de otro modo este proyecto hubiera muerto. Lo primero que quiero hacer es remodelar la Web de Aspectrum para que enlace directamente a los .tar.gz de sourceforge y darle un aspecto más renovado indicando lo que ya soporta. Para ello necesito que me digais todo lo que ya hace Aspectrum en plan propaganda. Otra cosa que hay que hacer es cambiar los créditos. Creo que ya no es sólo mi emulador. Es nuestro emulador, y como tal debéis aparecer en todos los créditos en igualdad de condiciones. Yo me tiré 2 años para hacerlo arrancar, pero una vez en marcha sin vuestra ayuda seguramente estaría pagado. Otra cosa que tenemos que decidir es qué hacemos con SDL. Os explico: yo empecé el emulador en SDL, y funcionaba estupendamente, pero como yo sabía más de allegro que de SDL, pues lo pasé a Allegro. Al hacerlo perdí casi un 20% de rendimiento, cosa que en un emulador se nota. Vamos, que si con SDL corria en mi Pentium 120, con Allegro tenía que saltarse frames... Lo del rendimiento tiene un punto importante... si sale un backend de SDL para gameboy advance, por ejemplo, imaginaros que el emulador pudiera correr allí!!! O de PSX, o de lo que sea. La pregunta es: ¿Lo pasamos a SDL como único lenguaje? (no debería costar, pues recordad que apenas pintamos píxeles en pantalla y poco más). ¿Lo ponemos como opción en tiempo de compilación? (esto me parece exagerado). Por el GUI, Alvaro, no te preocupes, porque SDL es basico (acceso a los píxeles) pero hay por ahi MUCHAS librerias basadas en SDL: SDL_gui, SDL_ttf (fuentes truetype), SDL_image, SDL_mixer, etc. Como tal, funcionan en todas las plataformas que lo hace SDL... Vamos a pensar un poquito en este tema a ver si sacamos en claro alguna decisión. Aparte del código ya hecho y de la comodidad de que todos conoce- mos allegro, ¿qué ventajas le veis a allegro? ¿Que mame esté hecho en Allegro nos debe dar tranquilidad? Yo es que veo SDL MUY extendido (las librerias de SDL vienen en todas las distribuciones) mientras que las libs de allegro no. Ha habido gente de #escomposlinux que no ha querido probar aspectrum porque al ejecutarlo le pedia las allegro y no venian en rpm/deb y no querían instalar ficheros compilados (llenar el arbol de directorios de cosas compiladas, vamos). Además algunos de ellos se les fueron abajo las XWindow al ejecutar el emulador (creo que era cosa de allegro). Sé que MAME usa allegro, y también RAINE, pero no sé si sería más rentable SDL. Igual no es necesario, yo no tengo acciones de SDL, si me convenceis dándome motivos, yo cambiaré mi opinión. Además ahora como mínimo hay que votar, porque somos 3 los que somos autores de este emulador y como tales debemos decidir democráticamente qué caminos votar :-) saludos! -- Santiago Romero Departamento de Sistemas sr...@se... Av. Primado Reig 189, entlo 46020 Valencia - Spain Telf. (+34) 96 332 12 00 Fax. (+34) 96 332 12 01 http://www.servicom2000.com |
From: Alvaro A. <A_...@te...> - 2002-10-07 23:25:48
|
BUENOS DIAS!!! Y entonces, va Santiago Romero y dice ¿Re: [Aspectrum-devel] Futuro? > El Tue, 8 Oct 2002 22:53:20 +0200, Alvaro Alea <A_...@te...> wrote: > > puede beneficiar ampliamente de eso (ejemm, no se si sabras que aspectrum > > se distribuje bajo GPL2, ejemm salvo que santiago el poseedor del > > copyright te haya dicho otra cosa claro :-) > Yo? poseedor del (c) X'DDD sip, eso pone el emulador cuando arranca, escepto la rutina de carga de Z80, que esa tiene (C) mio je,je, :-P > > A mi personalmente me gustaria volver a reescribir toda la parte de > > snapshots y ficheros de cinta, para al menos dar un soporte parcial de > > TZX y que se pueda grabar, asi como grabar en todos los formatos. > Os digo lo que mas me interesaba a mi: > 1.- Reescribir el gui (el mio apesta XD). A mi lo que me molaria es que el gui de Aspectrum fuese como el del +3, una ventanina y debajo la barra, que se mueva, parecido a lo que tienes, pero mo mucho mas fook'n'feel spectrummaniaco, con las tiras de 4 colores en el borde y el tipo de letra del spectrum, y debajo 2 lineas con ayuda para cada opcion. que se maneje con los cursores, intro, y espacio. p.cierto que sigo con el bug del hline, se nota mucho al pulsar F1. > 2.- pasar el juego de allegro a sdl. Con sdlspectrum-0.1 (empecé con > sdl y pase a allegro) tenía un 20% más de velocidad/rendimiento!!! Realmente a mi me da igual (en el fondo son 4 cosas las que usamos de allegro) Personalmente me gusta mas allegro, pero por el simple echo de que ya se como esta organizada la ayuda. y por ultimo Practicamente tener que hacer las funciones de "abrir como" y "guardar como" multiplataforma me parece una putada. En cualquier caso todo lo dependiente de allegro escepto el teclado (que tengo en el TODO moverlo) esta en v_allegro.c, asi que se deberia poder hacer en cualquier momento. > 3.- Hacer lo de tokes/pokes solo que te acuerdes de que existen ficheros .POK -- PoRqUE pArPadeaRa lA teCla De BlOq. MaYusCulaS. :-? _ Grettings of __ _| |___ __ _ Al...@as... LiNUX USER #66734 Saludos / _` | / -_) _` | http://pagina.de/alea A_...@te... de \__,_|_\___\__,_| MS Messenger: alv...@ho... Para obtener Llave Publica GnuPGP un mail con subject: enviar clave pub |