Re: Programar para PSP
Publicado: 25/10/14 8:30
Link escribió:Supongo que la poca potencia de la PSP se traduce en una emulación lenta e inaceptable no? en lo personal no me afecta lo lento o injugable que sea, como que me basta con ver que un juego sale, por ejemplo el emu de N64 que tengo en la PSP corre algo lento y con errores, pero me gusta asi, tiene ese algo que no es perfecto y le da un toque especial, asimismo para Android tengo el emu de NDS y ese si que corre lentisimo, pero salen los juegos eso demuestra que SI se puede emular, y eso es lo unico que me interesa, a pesar que corra a 10fps...TheElf escribió:Portar un emulador de 32x es posible, lo mas logico seria incluir el core en el picodrive, pero no lo veo realista, ya que la PSP no tiene potencia para poder emularla
Cores assembler de m68k muy optimizados son faciles de ver, pero de risc, son mas complejos, y los dos hitachi necesitan bastante potencia para ser emulados
Aparte: admiro tu conocimiento en este tema, siempre me pregunté como funciona un emulador y veo que la tenés clara, y siempre me han maravillado este tipo de programas, desde el Nesticle en una Pentium 1 y andando bien para mi era magia pura, quizas puedas hacer un breve resumen de como funciona un emulador? como se hace? obviamente sin aspectos técnicos, solo por curiosidad me interesa saber como se comunica el rom con el core, y como el core se comunica con (supongo) el DirectX o la PC en si (o su kernel en el SO) que se yo, la verdad no tengo ni idea y solo estoy especulando.
Todo se puede emular, independientemente del hardware, no hay dudas sobre ello. No es necesario programar un emulador de Playstation 3 para un Pentium 1, porque es posible..
El tema esta en quien quiere perder tiempo en programar algo, que no sirve de nada
Para un emulador, cuando decido programar o modificar uno, lo primero es averiguar que hardware tiene el dispositivo a emular. El hardware del dispositivo emulador, da igual por ahora. Si es PC es intel x86, si es una PSP sera MIPS
Supongamos que queremos emular una consola que tiene este hardware
CPU principal: Z80
Chip sonido: yamaha YM2612
VDP: ? normalmente son propietarios
En un PC x86
En ese caso, lo primero es emular los diferentes chipsets. Por suerte alguien ya programo emuladores de estos diferentes componentes... si no, toca programarlo de 0
Hay dos modos, emulacion completa, o traduccion de instrucciones
Si el hardware que emula es potente, lo mejor es una emulacion completa. Cada instruccion que el juego envia al Z80, se emula, y se devuelve al juego. Esto es preciso, pero lento
Asi funcionan casi todos los emuladores modernos,
Supongamos que tenemos el Sonic, y este juego envia esta instruccion
2+2 = ?
El juego esperara "4" como resultado. En ese caso, el emulador, mandara 2+2 al emulador de Z80, el Z80 emulado hace la suma, devuelve 4 al emulador, y el emulador devuelve esta instruccion al Sonic
Si el hardware no es potente, se tiene que recurrir a la traduccion, que significa, que cada instruccion que el juego envia al Z80, se trata de "traducir" esa instruccion a una igual o similar que tenga el hardware que emula
En ese caso, Sonic envia 2+2 al Z80, nuestro emulador/traductor, intercepta esta funcion, y en vez de enviarla al Z80 emulado, la envia directamente al CPU de la maquina emuladora, que ejecutara esta suma muchisimo mas rapido ya que puede hacerlo de forma nativa
Una vez tiene el resultado "4" lo devuelve al Sonic
Esto es rapido, pero no demasiado preciso, y suele dar fallos
Luego esta el lenguaje de programacion, de alto o bajo nivel, C es mas lento que ASM, pero devido a la complejidad de programar en ensamblador, suele presentar mas fallas, ya que los programadores no son dios, asi que cores en C, suelen ser mas lentos pero fiables
Por ejemplo, cuando programo cosas para megadrive, suelo programar todo en basic, pero rutinas muy pesadas, como dibujado de pantalla, aceso a memoria, todo en ensamblador
Asi minimizo las posibilidades de fallos, al escribir lo minimo posible en asm
La comunicacion se produce de manera simple, supogamos que nuesto DirectX de windows para emitir un pitido a 1khz, usa el comando " beep(1000) "
Seguimos con Sonic como ejemplo
Este juego, quiere emitir el pitido, en ese caso, la instruccion que envia el juego es ensamblador de Z80, supongamos "ld hl,1000"
Nuestro emulador intercepta la instruccion "ld hl,1000" que se envia al yamaha, y la emula en nuestro emulador del chip de sonido. En hardware real, el yamaha enviaria analogicamente el beep
Pero como estamos emulando, tenemos que interceptar el resultado del Yamaha, y traducirlo nuevamente al formato que espera nuestro sistema, en ese caso "beep(1000)"
Asi que
En hardware real
Sonic "ld hl,1000" ---> Yamaha ---> Salida analogica de audio de la Megadrive
En emulador
Sonic "ld hl,1000" ---> Emulador de Yamaha ----> emulador --> DirectX "beep(1000) " ---> Salida analogica de audio de nuestro PC
Ahora entenderas el famoso "lag" que se produce en todos esos pasos extras
En la PSP devido a que el hardware es relativamente potente, se emula, en la GBA o Nintendo DS ya que no hay hardware para emular, se suele trasladar
Cuando decido programar u optimizar un codigo, lo primero que hago, es ver que funciones tiene el hardware emulador, compararlas con la del hardware emulado, y tratar de transladar todo lo mas posible
Simplemente hay que buscar las instrucciones de los procesadores, y compararlas
Y bueno, es mas o menos eso
Eso rompe toda la idea original, que es no alterar la resolucion vertical. La horizontal disimula bien el bilinear, la vertical noZell_ff8 escribió:Sí, no le cambies el aspect ratio, son espantosos los juegos estirados así. Amplialo x1.41 V y H por igual. Nunca vas a ver un círculo en un juego si no.
Lo que quiero es modificar todos los emuladores que no soporten esta funcion, y transformar 256x224 en 384x224 y 320x224 en 400x224, para ganar algo de pantalla
El aspect ratio es secundario, y personalmente, me da bastante igual