Daedalus:Emulador N64 (#2)

1, 2, 3, 4, 511
Pues eso chicos,ya tenemos emulador de N64,no va a full speed logicamente, pero van unos cuantos juegos con no demasiados errores graficos segun parece :P(y muchos otros arrancan pero no pasan del menu...todavia ;) )

-Daedalus-


Imagen


Yep we have a N64 Emulator! Beating PSMonkey and PSDonkey to the punch is StrmnNrmn, who has released the first public build of his N64 Emulator, Daedalus. StrmnNrmn was also one of the people who got N64 emulation on the PC. This release makes it the first publicly released N64 Emulator for the PSP. And it's working pretty good. Although it's a port, it still shows that given the right amount of perseverance, anything can be achieved.


ImagenImagenImagen


Imagen


*ACTUAL R8

[^] Replaced all uses of sceCtrlReadBufferPositive with sceCtrlPeekBufferPositive.
[^] Various known value optimisations for the dynamic recompilation engine.
[^] Various texture cache optimisations and rendering optimisations.
[+] Implemented a new clipping method which is more efficient and gives better results.
[-] Removed 'tesselate large triangles' setting.
[+] Added option to reset emulator to the main menu.
[^] No longer use index buffers for rendering.
[^] Implement matrix multiplication using VFPU.
[^] Implement vertex transform and lighting code using VFPU.
[^] Implement clipping code using VFPU.
[^] Minor AddTri optimisations.
[^] Free background and font textures while emulator is running to free VRAM.
[!] Fixed bug in default controller config (c-down and dpad-down were broken)

DEscarga: http://sourceforge.net/project/showfiles.php?group_id=57977&package_id=188603&release_id=442362




R7
[^] Avoid checking for interrupts in dynarec code in most situations.
[^] Optimise dynarec Load/Store instructions to avoid checking for interrupts directly.
[^] Implemented the remaining 32-bit integer instructions in the dynarec.
[^] Implemented the remaining commong load/store instructions in the dynarec.
[^] Implemented JAL/JR in dynarec.
[^] Optimised various texture cache related features.
[^] Added various known value optimisations to the dynarec engine.
[^] Link together blocks even when they exit with branch likely instructions.
[+] Added option to allow frequency of texture update checks to be reduced.
[+] Added the ability to configure buttons
[!] Fixed a couple of compatibility issues caused by the dynarec.
[!] Fixed a couple of issues related to self-modifying code and the dynarec.
[!] Fixed issues with the framerate counter flickering
Descargar:

Link


R4
* Optimizacion del emulador
* Soporte para roms mas grandes
* Mejores texturas
* Aumento en la lista de compatibilidad

Descarga(2.0+):enlace
Descarga(1.5):enlace


R1

* There is no savegame support. (no hay save games)
* There is no audio support. (no hay audio)
* Not all the N64 controls can be used. (no van todos los controles)
* Large ROMs (i.e. over 8MB) cannot be loaded. (las roms mas grandes de 8mb no van)
* Many roms won't boot. (muchas roms ni siquiera arrancaran)
* Many roms have serious graphical glitches. (muchas roms tienen serios errores graficos)
* Many roms have random lockups and crashes. (muchas roms se bloquean aleatoriamente)
* Most roms run at a low framerate.(muchas roms van a pocos FPS)

Descargar(1.5 only): enlace


R2
* Compatibilidad con 2.0
* Solucionado algunos bugs
* Mejores texturas

Descargar(1.5 & 2.0+):enlace


-Tambien os dejo aki un eboot creado por djacura: Pinchar aqui imagen
Continuación de 'Daedalus:Emulador N64'

hkg36e escribió:Hombre pensad que es bueno que no de noticias.Si no da noticias buenas , no sabemos de sus avances, pero si no da noticias malas,significa que sigue ocn el proyecto
wenas ante todo buen trabajo por emulador muy bueno jeje, pero aora me gustaria saver de donde me bajo los rooms XD

gracias.

1 salu2
no se pueden dar links a paginas de ROMS (observese ke solo lleva una O)

y a ver si la gente deja de poner post diciendo ke esperan a la r5 ke lo unico ke hacen es llenar los hilos de paginas ke no dicen nada...

tengamos paciencia
Esto puede ser lo que me haga cambiar de opinion sobre la psp... [fumando] [fumando]
No veo el momento de jugar al OOT,Mario 64,mario kart,lilat wars.......
Solo de pensarlo ya me emociono

Salu2
¿Algun juego medio jugable en esta version?

Salu2
TeKKin escribió:wenas ante todo buen trabajo por emulador muy bueno jeje, pero aora me gustaria saver de donde me bajo los rooms


Ésta es muuuy buena, 100% recomendada: CLICK AKÍ! :D (ja, 2 veces en un día, vas de mal en peor)

No o descargo, porque no tengo roms de n64, bueno, si tengo, pero no me interesa mucho jugar al n64, ahorita estoy viciado con el chrono trigger :D pero bueno, ojalá saquen una nueva versión... obviamente mejorada XD
Os pongo esto y me voy a sobar ZZZZ, posteado por el creador del emulador en su pagina:

StrmnNrmn posted this update about his N64 emu for PSP:

Just a quick update on the dynarec status, as I know a lot of people are more interested in this than the grizly details of branch delay instructions

Last weekend (13/14 May) I managed to assemble the fragment buffers into native x86 code, and execute this dynamically. I spent some time debating whether to target MIPS or Intel initially, but I decided that it would be a lot easier for me to debug the code generation on the PC than it would be to debug code gen on the PSP.

In the end I'm glad I started with the PC as it allowed me to fix a number of hairy problems without going down the torturous path of debugging self modifying code on the PSP with just a few printf() statements to help track down any problems.

With this version of the dynarec, 200KB of N64 code was now generating just 2MB of x86 assembly (i.e. an expansion ratio of around 1000%). The PC version was running around 60% faster with dynarec enabled than with it disabled, which is a pretty significant speedup (although this is still very early in the process).

What's also important is that this is before I've done any real optimisation of the generated code. For each instruction I'm still calling the generic instruction handler which has the overhead of figuring out which source registers to use, which register is the destination etc. The *real* speedup comes from generating code to handle op codes explicitly, as you remove all this decoding overhead along with the overhead of jumping to another function. Once you've removed most of the generic instruction handling you can start looking at caching register values to minimise the amount of memory that's being moved around.

With the PC version up and running fairly successfully, I've spent this weekend getting the PSP code generation working. I don't want to go into too many details (as I want to go into more depth in future posts), but I know people are keen to hear some news about how this is going.

I got the basic code generation working on Saturday morning (thankfully I'd already resolved most of the tricky issues in developing the x86 version the previous weekend). I spent most of Saturday afternoon fixing some really horrible instruction cache related bugs. I'm still not 100% sure I've fixed them, but it seems very stable at the moment. At the moment I'm at the same stage with the PSP version of the dynarec that I was with the PC version last weekend - the code generation is running fine (and executing on the PSP without crashing more importantly but I've only just started looking at optimising things. It's still too early to speculate on numbers for the performance improvement it will give. Currently it's running around 10% faster with dynarec enabled, but it's still very early days.

More soon.

-StrmnNrmn


Chau
Sólo un 10% más rápido con el dinarec activado?? eso es....

Veamos si va sobre 6fps de media en mario 64 un 10 por ciento más sería.........(haced vosotros mismos las cuentas X-D muy poco!!!!
Sinceramente, si es solo un 10% más, el progreso no es muy notable que digamos y menos cuando va a 6fps.

Monkey64 prometia más a largo plazo.. [reojillo]
Una pena que los leones se le hecharan encima para arrancarle un brazo.
MecawenNnnNnnNNN!! [+furioso] [+furioso] [+furioso] [+furioso]
Ahora es un 10% mas rapido, pero acaba de hacerlo, quizas de aqui a un mes el porcentaje haya aumentado considerablemente

Chau
para q fuese algo notable de 6fps deberia ir un 100% mas rapido para al menos tener 12fps ;) , es q de 6 a 6,6... pero bueno poco a poco
en el articulo pone algo de 1000% pero no se a que se refiere....

en la pagina de pspudates uno comenta que los juegos de 5 pasaran a 50fps pero creo q se ha flipado un poco bastante, jejejej
aki lo de pspup:

PSPUpdates escribió:DaedalusStrmnNrmn is deadset on letting people know that he is doing his best to improve his N64 emulator, Daedalus. Just last week he let us in on how he's trying to incorporate a dynamic recompiler to his N64 emulator to make it run somewhat at par with the original N64 speed. Today he posts more of the dynarec progress on his blog.

StrmnNrmn has now succeeded in assembling the fragment buffers into a native x86 code and execute it dynamically. At first, he debated as whether to target MIPS or Intel initially. He ended up initially debugging the code generation on the PC rather than doing it on the PSP. It turned out to be a wise decision.

"I'm glad I started with the PC as it allowed me to fix a number of hairy problems without going down the torturous path of debugging self modifying code on the PSP with just a few printf() statements to help track down any problems," StrmnNrmn says.

Converting the fragment simulator loop directly into assembly was the first thing StrmnNrmn did to start with the x86 code generation. Each instruction in the fragment had the following generated code:

set current pc
set branch delay flag
get op code in ECX
call handler for specified op code (from R4300.cpp)
if ( exception set ) exit to exception handler
if ( branch instruction and branch taken ) exit to branch handler

This generated code produced a lot of assembly (i.e. 200KB of N64 instructions will produce 4MB of x86 assembly, which means an expansion of around 2000%). This didn't bother StrmnNrmn. All he was concerned with at that time was preserving the behavior of the fragment simulator as much as possible.

The full article awaits after the jump!


y ai lo ke pne en el blog de StrnmNrnm:

StrnmNrnm escribió:Just a quick update on the dynarec status, as I know a lot of people are more interested in this than the grizly details of branch delay instructions :)

Last weekend (13/14 May) I managed to assemble the fragment buffers into native x86 code, and execute this dynamically. I spent some time debating whether to target MIPS or Intel initially, but I decided that it would be a lot easier for me to debug the code generation on the PC than it would be to debug code gen on the PSP.

In the end I'm glad I started with the PC as it allowed me to fix a number of hairy problems without going down the torturous path of debugging self modifying code on the PSP with just a few printf() statements to help track down any problems.

To start with on the x86 code generation, all I did was convert my fragment simulator loop directly into assembly. So the generated code for each instruction in the fragment looked something like this:


set current pc
set branch delay flag
get op code in ECX
call handler for specified op code (from R4300.cpp)
if ( exception set ) exit to exception handler
if ( branch instruction and branch taken ) exit to branch handler



So a fragment with 100 instructions in would have this block repeated 100 times (with different pc, delay flag constants etc).

This generated a lot of assembly (i.e. 200KB or so of N64 instructions would generate over 4MB of x86 assembly, i.e. an expansion of around 2000%). At this point I wasn't interested in performance though - I wanted to make sure that I was preserving the behaviour of the fragment simulator as much as possible. The exception and branch handlers mentioned in the pseudo code above warrant more detailed description, but I'll leave that for another post.

At this point I spent a few hours debugging, but generally everything was working pretty well. The emulator was currently running around the same speed with 'dynarec' enabled as with it disabled (I use quotes because there isn't really much 'dynamic' about this code yet).

I spent the rest of the weekend and the early part of last week trying to optimise the generated assembly and see what I could get away with removing. One of the first things to go was setting the program counter before executing each instruction. The only instructions that need to know this tend to be branching instructions (which are relative and need to know the current PC to work out their target address) and other instructions that can potentially fire exceptions. The vast majority of instructions don't need to know the current PC though (e.g. arithmetic ops, logical ops etc).

Next I had a look at reworking things so I only needed to explicitly set the branch delay flag if a branch delay slot was actually active. I made the precondition that the branch delay slot was always clear, and explicitly set/cleared it when I knew the state needed to change.

Finally I removed exception handling from all the instructions I knew to be safe. For instance, I know ANDI (and immediate) can never throw an exception. As I only perform counter updates at the end of the block, an exception can never be fired when executing this instruction.

After all these changes I had an instruction execution block which looked something like this:


if ( pc needed ) set current pc
if ( branch delay instruction )set branch delay flag
get op code in ECX
call handler for specified op code (from R4300.cpp)
if ( can throw exception and exception set ) exit to exception handler
if ( branch instruction and branch taken ) exit to branch handler


This meant that the vast majority of instructions looked as follows:


get op code in ECX
call handler for specified op code (from R4300.cpp)


So I had nice big fragments like this:


...
get op code in ECX
call handler for specified op code (from R4300.cpp)
get op code in ECX
call handler for specified op code (from R4300.cpp)
get op code in ECX
call handler for specified op code (from R4300.cpp)
get op code in ECX
call handler for specified op code (from R4300.cpp)
...


Essentially I removed the vast majority of the instruction fetch/decoding overhead from the emulation.

With this version of the dynarec, 200KB of N64 code was now generating just 2MB of x86 assembly (i.e. an expansion ratio of around 1000%). The PC version was running around 60% faster with dynarec enabled than with it disabled, which is a pretty significant speedup (although this is still very early in the process).

What's also important is that this is before I've done any real optimisation of the generated code. For each instruction I'm still calling the generic instruction handler which has the overhead of figuring out which source registers to use, which register is the destination etc. The *real* speedup comes from generating code to handle op codes explicitly, as you remove all this decoding overhead along with the overhead of jumping to another function. Once you've removed most of the generic instruction handling you can start looking at caching register values to minimise the amount of memory that's being moved around.

With the PC version up and running fairly successfully, I've spent this weekend getting the PSP code generation working. I don't want to go into too many details (as I want to go into more depth in future posts), but I know people are keen to hear some news about how this is going.

I got the basic code generation working on Saturday morning (thankfully I'd already resolved most of the tricky issues in developing the x86 version the previous weekend). I spent most of Saturday afternoon fixing some really horrible instruction cache related bugs. I'm still not 100% sure I've fixed them, but it seems very stable at the moment. At the moment I'm at the same stage with the PSP version of the dynarec that I was with the PC version last weekend - the code generation is running fine (and executing on the PSP without crashing more importantly :) but I've only just started looking at optimising things. It's still too early to speculate on numbers for the performance improvement it will give. Currently it's running around 10% faster with dynarec enabled, but it's still very early days.

More soon.

-StrmnNrmn



salu2
alguien hace el favor de traducir,??????

esto ansiosoooo [poraki] [poraki]

salu2
Dice a grandes rasgos algo asi, como que ha preferido gastar todo la semana pasada debuggueando y probando la version pecera (X86) para entenderlo un poco mejor. Y que el domingo se puso con ello en la psp, incrementando un 10 % la velocidad... o sea que ese 10 % lo ha echo solo el domingo, dice que es muy pronto y acaba de empezar con la recompilacion dinamica.

Un saludo
Y que le falta optimizar muchas llamadas que por lo visto ahora entre llamadas aún se mueve demasiada memoria que se puede optimizar mucho.
sin lugar a dudas, muy buenas noticias. esperemos que pueda optimizarlo mucho mas!!
Joder,pues en un solo dia un 10% mas.....ya es,esperemos 10 dias y entonces 100% jejejejeje [chulito] ,ojala.
pochi escribió:Joder,pues en un solo dia un 10% mas.....ya es,esperemos 10 dias y entonces 100% jejejejeje [chulito] ,ojala.


El 100% de 6Fps son.... a ver que piense.... 12fps ohhh.

Me parece que tendremos que esperar 100días. [ginyo]
El 100% de 6Fps son.... a ver que piense.... 12fps ohhh.

Estas seguro??? yo creo qe el 100% de 6fps son 6fps [qmparto]
Fran_Teruel escribió:
El 100% de 6Fps son.... a ver que piense.... 12fps ohhh.

Me parece que tendremos que esperar 100días. [ginyo]


Es un decir [666] ,no te lo creas profesor [sati]
Natsu escribió:
Estas seguro??? yo creo qe el 100% de 6fps son 6fps [qmparto]


Se supone que es un aumento del 100% así que en realidad es un 200% del rendimento anterior. [sonrisa]


Esperemos que al final, tarde una semana o medio año, se pueda llegar a jugar a algo.
Ya me imaginaba que querias decir eso pero me hizo grácia por que se podia interpretar de otra forma. [qmparto]

A ver s sale ya!!!
Donde se pueden ver las ultimas noticias?

Porque alomejor estamos esperando todos a que diga alguien algo y nadie lo mira...
Xenogears escribió:Donde se pueden ver las ultimas noticias?

Porque alomejor estamos esperando todos a que diga alguien algo y nadie lo mira...


en el blog de StrnmNrnm ( joder, por fin m aprendi l put nombre xD)

http://strmnnrmn.blogspot.com/2006/05/dynarec-status.html
Supongo que aqui

Edito:Upps Black_Skull se me adelanto [agggtt]

Saludos Xeno.
pero a todo esto aun no e podido probar el emulador devido a ke no tengo ningun juego XD ke mal :( aver si alguien me aconseja de algo por ke kiero yo tambien probarlo joer!!!!

saludos
TeKKin escribió:pero a todo esto aun no e podido probar el emulador devido a ke no tengo ningun juego XD ke mal :( aver si alguien me aconseja de algo por ke kiero yo tambien probarlo joer!!!!

saludos


sabes que no se puede dar esa informacion por Eol pero si googleas encontras unas .Roms. muy .Cool. :P, se sabe algo de esa R5 ?? cuando andemos sobre los 18Fps ya me planteare hecharme unos vicios :D
Na, aun no se sabe na, espero q esta semana si sake algo, aunq vaya solo a un pokito mas, asi vamos probando, o al menos q PSMonkey sake algo q esto esta mu parao

Chau
No es q este mu parao, esque en las ultimas semanas nos han malacostumbrao de una manera increible! han empezado a salir proyectos de todos los lados, a cual mejor, y claro... ahora hay mono de novedades jejejejejeje

Enga Saludos!
yo creo q ya habra hecho mejoras, pero no creo que se trate de sacar una nueva version si "solamente" mejora 1 o 2 fps respecto a la version anterior. igual espera a que haya un cambio un poco mas grande

nose es mi opinion
La gente dice q cuando la cosa ande a 30 fps la cosa sera jugable... estais de coña no???

Incluso a 50 fps es 1 coñazo. No hay nada mas askerosamente desesperante q un juego q se ralentiza, aunq sea unos pokillos frames

Y si no mirad el emu de SNES, q alguna vez se ralentiza de 60 a 30 o 40 fps y te toca mucho los cojones
Si esq es eso q han salido muchas cosas en poco tiempo, pero esq con la PSP es asi, llega un mes o una semana y empiezan a salir cosas por todos los lados, q no te da tiempo casi ni a probarlas, y luego hay un paron hasta el siguiente mes o semana q vuelven a caer bombas XD

Lo malo de esto q casi siempre las salidas de juegos buenos coinciden con los bombazos, por eso luego cuando hay paron no tenemos ni juegos ni bombazos y se hace mucho mas largo

Seguro q cuando sake la R5 habra hecho muchos mas avances, va pokito a poco, por eso no ha sacado aun la R5, porq habra subido los fps pero quizas no lo suficiente como para sacar una nueva version

Chau
Deku escribió:La gente dice q cuando la cosa ande a 30 fps la cosa sera jugable... estais de coña no???

Incluso a 50 fps es 1 coñazo. No hay nada mas askerosamente desesperante q un juego q se ralentiza, aunq sea unos pokillos frames

Y si no mirad el emu de SNES, q alguna vez se ralentiza de 60 a 30 o 40 fps y te toca mucho los cojones



Ummm, el ojo humano no es capaz de captar más de 30 fps, por lo que una ralentización visible sería cuando cae a 20-25 fps y no las que tú has dado.

Un saludo.
no creo q la n64 rularan los juegos a 60fps...
Vi hace tiempo por aqui un hilo en el q se hablaba de los Fps q puede captar el ojo humano y en el hilo venia un estudio realizado q decia q cada ojo puede percibir mas o menos, asi q a cada uno nos puede parecer una cosa

Yo pienso q si el Mario 64 o el Zelda OOT se pueden jugar a 18 fps en la proxima version me los voy a comer enteritos, si ahora el Mario va a 10 mas o menos en algunos sitios, y casi se puede hasta jugar, con 18 soy feliz

ChaU
Deku escribió:La gente dice q cuando la cosa ande a 30 fps la cosa sera jugable... estais de coña no???

Incluso a 50 fps es 1 coñazo. No hay nada mas askerosamente desesperante q un juego q se ralentiza, aunq sea unos pokillos frames

Y si no mirad el emu de SNES, q alguna vez se ralentiza de 60 a 30 o 40 fps y te toca mucho los cojones


Pues si que eres sibarita tio... Ya me conformaria yo con 25 constantes ...
Si sacan el emu a 30 fps (con frameskip 1 seria 100%) yo le hago una estatua de bronce al creador.
me gustaria saver como puedo correr algun juego de la N64 e puesto el zelda y se me keda la consola peta en el menu. aver si alguien me puede explicar como acerlo porfa

Gracias


saludos
de la versión R5 nada de nada nop?¿
de la versión R5 nada de nada nop?¿


se supone k salia hace un par de semanas , pero aun nada de nada [qmparto] [qmparto]

salu2
tened paciencia, yo creo q x lo menos un par d meses vamos a tardar en empezar a ver algo decente...

eso si, el tema del chip arroja mucha luz al tema. Seguro q si conseguimos plena libertad en PSP habra un emu cojonudo de 64
NUEVA VERSION!!!!!!

ts been a few weeks since we have had an update from StrmnNrmn, but he has once again kept us eager people in the loop by posting a further update on his progress with Daedalus - an Nintendo64 emulator for the PSP.

Be warned the following may go over the heads of most people, but according to StrmnNrmn he has made a lot of progress in the following areas:

Most integer arithmetic and logical instructions have now been implemented
Register caching has now been implemented
Direct linking all direct branches to compiled fragments and linking to all indirect branch targets

Work on the dynarec engine has reached approximately 40-50% completion which basically has translated so far to a 100% speedup in ROMs tested (including Mario Kart and with a slight performance increase with Zelda)

There has obviously been some fantastic progress thus far, but StrmnNrmn points out he still has the following to work on:

Fully implement all the remaining integer ops
Finalize implementation of the fast linear scan register allocation algorithm
Track 'known' values for specific registers which can be used to optimize the generated code
Cache the memory location pointer and optimize load/stores using this information as a base pointer
Optimize all memory access instructions
Detect and optimize 'busy wait' loops
Implement all the branching instructions
Implement instructions and register caching instructions

http://pspupdates.qj.net/Daedalus-N64-Emulator-W-I-P-Update-/pg/49/aid/48890
Jurrrr!! me que buenas noticias!!!
POs a grandes rasgos, que ha conseguido aumentar la velocidad un 100%(no que los juegos vayan al cien por cien ojo!!) que juegos como mario kart vanbastante bien y que, bueno que estemos atentos que sacara una nueva actualzación pronto, sólo comenta los avances nada de material [snif]
que ha conseguido aumentar la velocidad un 100%(no que los juegos vayan al cien por cien ojo!!)


cierto, dice que ha aumentado un 100% la velocidad que tenian... osea, que si un Mario Kart marchaba a 5fps, ahora lo hara a 10fps.

Deen0X
Pero todabia no ha salido la release no??Es que como poneis nueva version...

Saludos.
501 respuestas
1, 2, 3, 4, 511