Comunidad nesdev hispana

NES development discussion in English, Español, Français, Português, русский язык, or any language.

Moderator: Moderators

User avatar
Petruza
Posts: 311
Joined: Mon Dec 22, 2008 10:45 pm
Location: Argentina

Post by Petruza » Fri Jul 15, 2011 9:27 pm

Anes wrote:Argentino, de aca también colaborando con el habla hispana.
Yo vengo haciendo el emulador desde el 2004. Lo dejé por obligaciones, pero estoy de vuelta.
Qué bueno, contá:
1- lenguaje
2- sistema operativo
3- librerías
4- estado de avance
( todos pueden contestar )

User avatar
Anes
Posts: 605
Joined: Tue Dec 21, 2004 8:35 pm
Location: Mendoza, Argentina

Post by Anes » Sat Jul 16, 2011 8:35 am

Petruza wrote:
Anes wrote:Argentino, de aca también colaborando con el habla hispana.
Yo vengo haciendo el emulador desde el 2004. Lo dejé por obligaciones, pero estoy de vuelta.
Qué bueno, contá:
1- lenguaje
2- sistema operativo
3- librerías
4- estado de avance
( todos pueden contestar )
  • 1 - C (Visual Studio)
    2 - Win32/Win64 (Desarrollado bajo Windows 7 x64)
    3 - DirectX (DirectDraw, DirectSound, DirectInput) en fin Ninguna, todo metido dentro del exe hecho desde 0
    4 -
    • - MAPPER 0 (por supuesto)
      - UNROM, CNROM,
      - MMC1
      - MMC3 (parcialmente)
      - Desensamblador (parcialmente también)
En tiempos pasados lo hice en Assembler (MASM) y C++ (VS), pero me quedé con el C.
Los otros tenían Sonido, pero decidí hacer el emulador de vuelta porque era un desastre, pero pronto le agrego sonido. Estoy esperando arreglar cosas del PPU.

User avatar
Petruza
Posts: 311
Joined: Mon Dec 22, 2008 10:45 pm
Location: Argentina

Post by Petruza » Sat Jul 16, 2011 8:49 am

Anes wrote:
  • 1 - C (Visual Studio)
    2 - Win32/Win64 (Desarrollado bajo Windows 7 x64)
    3 - DirectX (DirectDraw, DirectSound, DirectInput) en fin Ninguna, todo metido dentro del exe hecho desde 0
    4 -
    • - MAPPER 0 (por supuesto)
      - UNROM, CNROM,
      - MMC1
      - MMC3 (parcialmente)
      - Desensamblador (parcialmente también)
Ah, muy avanzado.
Cuántos y cuales juegos testeaste?
Cómo testeas y debugeas? con el desensamblador, con el debugger del visual studio?
En qué consiste el desensamblador?

Te pregunto porque yo programé lo mínimo necesario para correr un juego, básicamente las opcodes y un mínimo render, corrí un par de juegos y obviamente no anduvo ninguno. Así que ahora estoy haciendo un debugger gráfico para ver dónde se cuelgan los juegos.

User avatar
Anes
Posts: 605
Joined: Tue Dec 21, 2004 8:35 pm
Location: Mendoza, Argentina

Post by Anes » Tue Jul 19, 2011 1:27 am

Petruza wrote:
Anes wrote:
  • 1 - C (Visual Studio)
    2 - Win32/Win64 (Desarrollado bajo Windows 7 x64)
    3 - DirectX (DirectDraw, DirectSound, DirectInput) en fin Ninguna, todo metido dentro del exe hecho desde 0
    4 -
    • - MAPPER 0 (por supuesto)
      - UNROM, CNROM,
      - MMC1
      - MMC3 (parcialmente)
      - Desensamblador (parcialmente también)
Ah, muy avanzado.
Cuántos y cuales juegos testeaste?
Cómo testeas y debugeas? con el desensamblador, con el debugger del visual studio?
En qué consiste el desensamblador?

Te pregunto porque yo programé lo mínimo necesario para correr un juego, básicamente las opcodes y un mínimo render, corrí un par de juegos y obviamente no anduvo ninguno. Así que ahora estoy haciendo un debugger gráfico para ver dónde se cuelgan los juegos.
Creo que no te conviene escribir el código específico para un sólo juego. Emulá el CPU completoe (que no es tan díficil) primero, depués hacés un Render pixel por pixel básico y de ahí progresas.

He probado unos 100 mas o menos me corre un 85%.

Básicamente depuro con el Visual Studio, en realidad estoy usando el Visual C++ 2010 express con el Resedit (editor de recursos). Lo uso principalmente por las capacidades muy buenas de depuración en tiempo real que tiene. Aunque tengo el Visual Studio Original. Te dejo unos link que te pueden interesar:

6502:
http://users.telenet.be/kim1-6502/6502/proman.html
Éste de explica el 6502 de una forma sencilla y amigable, mucho mejor que los documentos esos tan exactos. El 6502.txt del Nesdev tiambién es un buen comienzo.

DirectDraw:
http://archive.gamedev.net/reference/ar ... le1260.asp
http://archive.gamedev.net/reference/ar ... le1270.asp

Podés usar directamente el el modo de colores de 32bits depth en DirectDraw. Mostrar píxeles (ahí en el artículo te muestra cómo mostrar píxeles usando coordenadas X e Y. Te sugiero que emprecés con esto, después optimizás el código.
Del CPU no te olvidés del nestest.nes para probar el CPU.

PPU:
Te aconsejo que empecés como todos con el de Yoshi (auque está desactualizado) para un panorama general. Después podés pasar al nintech.txt y depués al "2A03" reference. De todas formas así fue como hice yo.
En realidad cuando empecé lo hice por scanline, fui dando vueltas y preguntando en el NesemDev hasta que obtuve algo palpable.
Acordate que el pattern table son dos bytes, y que obiente el bit alto y el bit bajo del pixel, con esto te sobra para hacer un render de 4 colores para ver algo en la pantalla (sobre todo el nestest.nes para que testees el CPU. Después más adelante te preocupas por los attribute table.
Tomá como referencia un juego simple: "Popeye" se me viene a la cabeza y metele hasta que veas algo en pantalla. En el switch(opcode)
agrega un default para que veas los opcodes que estan fallando.

Aunque sea una pregunta boluda, preguntala en el Nesdev, es la mejor forma de avanzar.

En fin así mas o menos empecé yo, que hay otras formas no lo niego, pero algo de resultado me dió. :)

Si querés agregame al messenger o mandame un mail y charlamos.

Suerte. :wink:

User avatar
ehguacho
Posts: 83
Joined: Tue Mar 09, 2010 11:12 pm
Location: Rosario, Argentina
Contact:

Post by ehguacho » Tue Jul 19, 2011 7:40 am

me gustaria agregar una pequeña cosita: el "6502.txt" tiene algunos errores en los numeros de los opcodes. en el foro se dice que este -> http://www.obelisk.demon.co.uk/6502/reference.html es el mejor documento sobre el 6502 de la web, ya que no tiene errores (cabe destacar que el documento es sobre el 6502 original, y NO sobre el 6502 que usa la NES, que tiene unas pequeñas variaciones). un sitio en el que te pueden ayudar muchisimo es este -> http://forum.6502.org/, un foro hecho por gente que la tiene mas que clara con el 6502.
sorry about my english, i'm from argentina...

http://nestate.uuuq.com

User avatar
Petruza
Posts: 311
Joined: Mon Dec 22, 2008 10:45 pm
Location: Argentina

Post by Petruza » Tue Jul 19, 2011 9:24 am

Anes wrote:Creo que no te conviene escribir el código específico para un sólo juego...
Me expresé mal, no es que apunté a que corra un juego específico, sino que le di soporte apenas para que pudiera correr cualquier juego con mapper 0.
Implementé todos los opcodes documentados, y los testeé.
Con respecto al render, en realidad como estoy desarollando el engine exclusivamente, no tiene render per se, simplemente emula el estado de la memoria de video, nametables, etc. y eso luego es tomado por algún plugin que se ocupa del render.
Por ahora y para testearlo hice un plugin muy básico que renderea no por scanline ni pixel, sino por sprite. Esto funciona, obviamente que los juegos que usan scroll con pantalla partida o algún otro truco entre scalines, se verán mal, pero para testear juegos sin scroll en pantalla fija como por ejemplo balloon fight, sirve.

El emulador logró mostrar una pantalla estática con la intro del Zelda, que es una demo que alguien posteó en este foro, pero cuando pruebo juegos de verdad, crashean en algún lugar, y me parece medio tedioso usar un debugger normal para debugear el juego, por eso quiero desarrollar un debugger visual para ver en qué estado está la memoria de video, nametables, sprites y demás

User avatar
Anes
Posts: 605
Joined: Tue Dec 21, 2004 8:35 pm
Location: Mendoza, Argentina

Post by Anes » Tue Jul 19, 2011 11:32 am

ehguacho wrote:me gustaria agregar una pequeña cosita: el "6502.txt" tiene algunos errores en los numeros de los opcodes. en el foro se dice que este -> http://www.obelisk.demon.co.uk/6502/reference.html es el mejor documento sobre el 6502 de la web, ya que no tiene errores (cabe destacar que el documento es sobre el 6502 original, y NO sobre el 6502 que usa la NES, que tiene unas pequeñas variaciones). un sitio en el que te pueden ayudar muchisimo es este -> http://forum.6502.org/, un foro hecho por gente que la tiene mas que clara con el 6502.
Sí ese docuemento es el más exacto pero no explica los modos de direccionamiento. Yo decía para alguien que recién está empezando ...
Me expresé mal, no es que apunté a que corra un juego específico, sino que le di soporte apenas para que pudiera correr cualquier juego con mapper 0.
Implementé todos los opcodes documentados, y los testeé.
Con respecto al render, en realidad como estoy desarollando el engine exclusivamente, no tiene render per se, simplemente emula el estado de la memoria de video, nametables, etc. y eso luego es tomado por algún plugin que se ocupa del render.
Por ahora y para testearlo hice un plugin muy básico que renderea no por scanline ni pixel, sino por sprite. Esto funciona, obviamente que los juegos que usan scroll con pantalla partida o algún otro truco entre scalines, se verán mal, pero para testear juegos sin scroll en pantalla fija como por ejemplo balloon fight, sirve.

El emulador logró mostrar una pantalla estática con la intro del Zelda, que es una demo que alguien posteó en este foro, pero cuando pruebo juegos de verdad, crashean en algún lugar, y me parece medio tedioso usar un debugger normal para debugear el juego, por eso quiero desarrollar un debugger visual para ver en qué estado está la memoria de video, nametables, sprites y demás
Está bien, cada uno tiene su método. Yo no niego que en el futuro voy a necesitar un debugger mas o menos así.

User avatar
Petruza
Posts: 311
Joined: Mon Dec 22, 2008 10:45 pm
Location: Argentina

Post by Petruza » Tue Jul 19, 2011 2:47 pm

Si, sobre ese doc basé mi cpu

User avatar
Anes
Posts: 605
Joined: Tue Dec 21, 2004 8:35 pm
Location: Mendoza, Argentina

Post by Anes » Tue Jul 19, 2011 4:13 pm

Petruza wrote:
Si, sobre ese doc basé mi cpu
En realidad, los cpu test de Blargg en el readme tienen una matriz de los ciclos de los opcodes, de ahí yo los tomé directamente e hice una matriz en C.
ANes

User avatar
Petruza
Posts: 311
Joined: Mon Dec 22, 2008 10:45 pm
Location: Argentina

Post by Petruza » Tue Jul 19, 2011 5:20 pm

y la ejecución de las instrucciones, la hacés con punteros a función guardados en esa matriz?

User avatar
ehguacho
Posts: 83
Joined: Tue Mar 09, 2010 11:12 pm
Location: Rosario, Argentina
Contact:

Post by ehguacho » Tue Jul 19, 2011 5:50 pm

si están compadre, solo que no están en ESA página en particular. es cuestión de buscarla en el index jeje http://www.obelisk.demon.co.uk/index.html

no creo que en este momento te haga falta la info que pueda brindarte ese sitio, simplemente contesto por si el día de mañana alguien lo lee :)
sorry about my english, i'm from argentina...

http://nestate.uuuq.com

User avatar
ehguacho
Posts: 83
Joined: Tue Mar 09, 2010 11:12 pm
Location: Rosario, Argentina
Contact:

Post by ehguacho » Tue Jul 19, 2011 5:52 pm

Petruza wrote:y la ejecución de las instrucciones, la hacés con punteros a función guardados en esa matriz?
segun lei en algunos documentos sobre emulacion, ese metodo tiene la mejor performance pero puede llegar a tirar un error de sobrecarga en la pila de llamadas. ¿sera cierto eso? ¿o con la capacidad de los procesadores de hoy uno deberia despreocuparse de algo asi?
sorry about my english, i'm from argentina...

http://nestate.uuuq.com

User avatar
Petruza
Posts: 311
Joined: Mon Dec 22, 2008 10:45 pm
Location: Argentina

Post by Petruza » Tue Jul 19, 2011 6:05 pm

No veo por qué podría haber problemas con la pila. Si se llamaran recursivamente podría ser, pero no tiene sentido.
Cada CPU emulado debería llamar sólo a una instrucción a la vez

User avatar
ehguacho
Posts: 83
Joined: Tue Mar 09, 2010 11:12 pm
Location: Rosario, Argentina
Contact:

Post by ehguacho » Tue Jul 19, 2011 6:12 pm

Petruza wrote:No veo por qué podría haber problemas con la pila. Si se llamaran recursivamente podría ser, pero no tiene sentido.
Cada CPU emulado debería llamar sólo a una instrucción a la vez
lo mismo pense yo, pero queria sacarme la duda de todas maneras jeje
sorry about my english, i'm from argentina...

http://nestate.uuuq.com

User avatar
Anes
Posts: 605
Joined: Tue Dec 21, 2004 8:35 pm
Location: Mendoza, Argentina

Post by Anes » Wed Jul 20, 2011 10:53 am

Petruza wrote:y la ejecución de las instrucciones, la hacés con punteros a función guardados en esa matriz?
No, de ahí tomo los ciclos nomás, no uso puntero a funciones, excepto para los mappers.

Mapeo la memoria del CPU y PPU.
ANes

Post Reply