Core z80

[azrael]

Una pregunta, por curiosidad hay algun core en asm del z80 para arm?
Y otra, sabeis ke consolas usan el z80?
Que otros procesadores de no demasiada potencia hay sin core en asm para gp32?
Es pura curiosida, por ahora no os hagais ilusiones :p
salu2
azrael

[CaraMuuu]

Tengo muy poca idea de ésto, pero creo q como procesador principal muy pocas o ninguna consola lo usan. Llevan un z80 la neogeo, la pocket, la mega drive, etc. repito q no tengo ni zorra, pero creo recordar q en neo geo era el procesador de sonido (creo haberlo leido en la extinta topSNES)
aluego

[alberdi]

Creo que era el procesador de la master y tb de la gameboy.

[chemaris]

es un procesador muy usado para el sonido ,creo que por ejemplo en la md y tambien en portatiles como en la gba , en la gba tambien esta , pero creo que solo por compatibilidad y solo se usa al insertar un cartucho de gb

[dj syto]

cierto, en megadrive se usa para el sonido, y ademas para jugar a los juegos de master system mediante el adaptador master system converter.

en gba mas de lo mismo. aunke no se seguro si se usa pa sonido. creo que solo pa compatibilidad con gb.

tambien esta el spectrum XDDD

[amkam]

segun rlyeh, crei entender que tenia un core del z80 en ensamblador, que es el que usa para el fgen. Y si no, tambien hay cientos de cores del z80 en ensamblador para procesadores arm

[ilarri]

bien, efectivamente el chip de sonido de la neo geo es 1 z80, pero el procesador central de la game boy original era un z80.
mirando en google he encontrado esta web tan interesante, con detalles del chip :

http://www.geocities.com/museo8bits/cpu.htm


Los programadores en assambler Z80 son los que lo tienen mas sencillo al saltar al ASM x86 del PC.
(sacado del texto ;)

leerlo, esta muy interesante =)

[dj syto]

HABLANDO DE Z80S, COMO EL EMU DE RLYEH NO TENIA SONIDO (EL FGEN) LE DESACTIVO LA EMULACION DEL Z80, Y ES POR ESO KE A LO MEJOR AHORA VA ASI DE RAPIDO, KIEN SABE, TAL VEZ CUANDO ACTIVE EL SONIDO LA COSA BAJA MUCHISIMO. PORQUE ESTARA EMULANDO DOS CHIPS, EL ZETAOCHENTA Y EL SESENTAYOCHOMILDEMOTOROLA.

[Segata Sanshiro]

Por supuesto que hay cacharros que lo tienen como procesador principal. En cuanto a que la GBA lo lleve sólo por compatibilidad con la GB... no sé, si no es un Z80, ¿qué chip genera los sonidos de los 4 canales que NO son los dos canales Direct Sound (los que reproducen samples)?

[dj syto]

PUES NO LO SE, SI TU LO SABES SEGURO, SERA ESO, YO ESKE NO TENGO NI IDEA TIO :confused:

[ilarri]

ni idea, constar, cuando poner los chips de la gba, este no consta,pero kizas ya lo consideran como un chip "menor" o de ayuda, ni idea vamos, voy investigar.

[Segata Sanshiro]

PUES NO LO SE, SI TU LO SABES SEGURO, SERA ESO, YO ESKE NO TENGO NI IDEA TIO

No, no, tú cuando me oigas hablar ten en cuenta que yo parece que sé mucho pero lo único que sé es dar el pego... xDDD

Cagüen, otro secreto íntimo desvelado! :D

[dj syto]

ES CIERTO, SUELE FUNCIONAR, YO LO HAGO MUCHAS VECES TAMBIEN XDDDDDDDDDDDDDDDDDD.

PERO EN ESTE CASO, ESKE NO SE LO DE GBA...

[ilarri]

bueno, he encontrado un comentario al respecto del sonido de la consola, y textualmente dice:
"(...)el chip de sonido, de la familia z80 de Zilog, es potente y versatil, demostrado por su veterania y su capacidad de renovarse, que le convierten en el ave fenix de los procesadores.
La eleccion de este chip para la gba es una decision a futuros,como todo(...)"

(comentario de alguien en nintendo accion, hablando de la gba cuando salio)

"alguien" pk es uno de los responsables del foro,por lo tanto siempre alabara a nintendo.

k modelo de chip lleva?? Ni idea

[azrael]

El tema es este; tengo ideas muy basicas de programacion (se lo ke es un ensamblador, C, la programacion orientada a objetos ... :P) Los conceptos de programación los domino bastante... pero nunka me he acercado demasiado a un lenguaje (a no ser un poco BliztBasic xD).
La cuestion es ke me parece muy interesante el tema de los emuladores, y le he estado dando vueltas.
Y como tengo por aki un librote muy majo de ensamblador de Z80 ( me lo estuve empollando hace tiempo) pensaba ke igual podia currarme un core de Z80...
Pero no se si sera muy util...
Kiza lo unico bueno es que asi entenderia porfin los conceptos de la emulacion, ke no me entran ni para atras.
Por lo ke me imagino un core lo unico ke hace es transformar las instrucciones de ensamblador de un procesador a las de otro,no?
El problema es ke me gustaria ver ejemplos...
y bien comentados, lo ke parece dificil en asm.
A parte de eso.. sabeis de algun emulador en C ke este bien comentado? Eske necesito ejemplos de estructura de un emulador para hacerme una idea.
Yo kreo ke lo ideal hubiera sido ke algun programador como Rlyeh (animo machote) nos hiciera un tutorial para programadores advenedizos xD.
salu2
azrael

[ilarri]

azrael, me parece genial la idea, pues poniendote en ello aprendes cada dia mas, investigar, y no deja de ser una ardua aventura, pero las cosas acaban saliendo.
dices k no seria productivo? para mi personalmente si, pues asi aprenderas.
Hoy por hoy no es productivo hacer un pong, por ejemplo, k funcione en la gp32,pero es un principio, es una forma de demostrarte a ti mismo k puedes hacer algo.
Si sabes algo de z80,ponte a ello, hay muchos sistemas por emular todavia =)

y si te da por ahi, por ejemplo, te podias poner a emular el pc98, a mi personalmente me darias una alegria, aunk despues lo dejases a mitad,pk este sistema,a demas de olvidado y desconocido, es injustamente ninguneado.

o lo k kieras, opciones hay muchas, desde el fururo zot, al gigas engine,el fenix o lo k kieras.

mira este link, kizas veas algo interesante :

http://www.kobira.co.jp/sakura/msdos.htm

[azrael]

Sinceramente no se si soy capaz.. y si lo hago sera un proyecto lentooooo (echale minimo un año) No kiero darte muxas ilusiones para luego chafarte.
Voy a ver si encuentro algo de informacion.
Si encontrais codigos fuente bien comentados, ya sea de cores o de emuladores, rularmelos, xfa.
Salu2
azrael

[azrael]

gracias por el link, estoy mirando los sources a ver si veo algo interesante.

[(_=*ZaXeR*=_)]

Ufff hay muchas consolas con el Z80, al igual que muchas con el 68K son dos de los procesadores mas utilizados en la historia de los videojuegos. El Z80 esta basado en los procesadores de intel 8080 de 8 bits, de ahi que compartan muchisimas similitudes en el ensamblador de los x86, ya que el cambio esta "solo" en el paso a los 16bits. Y si la gb usa como procesador un Z80 de zilog. Tambien los cpc lo usan y otro muchos.

[Sd-Snatcher]

mirate los fuentes del fmsx.

[Sd-Snatcher]

Tambien los cpc lo usan y otro muchos


Hombre es que si consolas lo llevan (coleco, gamegear) oredenadores no veas, a cientos.

[saharoo]

Originalmente anunciado por azrael
Kiza lo unico bueno es que asi entenderia porfin los conceptos de la emulacion, ke no me entran ni para atras.
Por lo ke me imagino un core lo unico ke hace es transformar las instrucciones de ensamblador de un procesador a las de otro,no?



Hola azrael, hola peña!

Soy usuario de la GP32 y también programador de varios lenguajes, entre ellos el ensamblador... y he entrado por aquí de vez en cuando para seguir este mundillo que me apasiona, pero que tengo abandonado por falta de tiempo.

Respondiendo: en la emulacion sería una locura transformar el código máquina de un procesador a otro... lo que se hace es interpretar el código, igual que hace por ejemplo una máquina virtual Java. No es muy complicado, pero se necesita conocer bien la arquitectura que se desea emular a nivel de bits...

Al ser interpretado, el procesador tiene que ejecutar un bucle de varias instrucciones, y desde este bucle se llama a una subrutina distinta dependiendo del nmotécnico a interpretar... es decir, que por cada instrucción del emulado hay que ejecutar varias instrucciones del emulador... es por esto que, la máquina que emula tiene que ser mas o menos un minimo de 10 veces más rápida que la máquina emulada, por ejemplo, para emular la GBA desde la GP32, la GP32 tiene que ser 10 veces más rápida (cosa que creo que se cumple) o más...

Saludos

[Sd-Snatcher]

El caso de la GBA es especial ya que todas las funciones del procesador de la GBA estan en el de la GP32, no hace falta emular puede ejecutar el codigo, pero tiene que dejar tiempo para emular el resto de la maquina.

[(_=*ZaXeR*=_)]

Pozzz zi lo que dice Snatcher es asi, por eso mismo dije que si alguien se atrevia con un emu de la 3DO (algo bestia pero....)

[saharoo]

Originalmente anunciado por Sd-Snatcher
El caso de la GBA es especial ya que todas las funciones del procesador de la GBA estan en el de la GP32, no hace falta emular puede ejecutar el codigo, pero tiene que dejar tiempo para emular el resto de la maquina.


Si... eso también es cierto... ;-P

[Sd-Snatcher]

Creo que el mayor problema de la 3DO seria su copro matematico.

Ya que tambien es un Arm, pero un ARM60 que no se hasta que punto es similar.

El chip de video es una evolucion del usado en el MSX2+y Turbo-R que de hecho se ha utilizado en el MSX en forma de cartucho, y esta muy documentado.

[timofonic]

Originalmente anunciado por Sd-Snatcher
El caso de la GBA es especial ya que todas las funciones del procesador de la GBA estan en el de la GP32, no hace falta emular puede ejecutar el codigo, pero tiene que dejar tiempo para emular el resto de la maquina.

El z80 no lo está, ¿pero acaso lo usan los juegos de gba?

[timofonic]

Bueno 65816 no tiene core en ASM...

8086 tampoco, etc...

[azrael]

Al ke le interes hacer un emulador de GBA, ke se mire esto (http://www.cs.rit.edu/~tjh8300/CowBite/CowBiteSpec.htm) , que casi parece un tutorial.
Salu2
azrael
P.D.: en el caso de GBA ke es lo ke habria ke hacer pues, emular simplemente los chips adicionales y lo ke este en ARM ke lo ejecute sin mas?

[huahe]

Podeis echar un vistazo aquí para enteraros de todo el rollo procesadores, etc

http://www.emulatronia.com/maquinadeltiempo/frames-linea-temporal.htm

[enkonsierto]

Estos son dos tutoriales enfocados a enseñara a hacer emuladores de space invaders y de pacman. A lo mejor a alguien le resulta util.

http://www.ascotti.org/programming/side/side.htm
http://www.ascotti.org/programming/pie/pie.htm

Están en inglés, eso sí.

[xenon]

Originalmente anunciado por azrael
Una pregunta, por curiosidad hay algun core en asm del z80 para arm?
Y otra, sabeis ke consolas usan el z80?
Que otros procesadores de no demasiada potencia hay sin core en asm para gp32?
Es pura curiosida, por ahora no os hagais ilusiones :p
salu2
azrael

Sobre el core, ni idea... pero bueno, el z80 no es tan potente como para no poder mejorar un core en nuestra gp32.

¿Maquinas Z80? Pues si tienes como yo 22 tacos o mas... siempre tendrás en mente:

- Amstrad CPC (464, 472, 664, 6128, 464+ y 6128+)
- MSX 1, 2 y 2+ (Menos el Turbo-R, que usa R800 además de Z80)
- ZX Spectrum (48, 128, + , +2, +2A, +3)

- Amstrad GX4000
- Colecovision
- Sega Master System
- Sega Game Gear
- Nintendo Gameboy
- Nintendo Gameboy Color

Luego están el montón de máquinas que usaban el z80, pero como coprocesador, sobre todo muchos sistemas o consolas 68000.

Un saludo

[FunkyBoy]

En la GBA el z80 solamente se usa cuando le metes un cartucho de GB. En GBA ni siquiera le llega corriente para ahorrar batería y no se puede utilizar de ninguna manera.
En GB era el procesador principal así como en los spectrums y otros ordenatas...
Cuando llegaron los micros de 16 bits como el 68000, algunos fabricantes lo dejaron como chip secundario en plan copro. Ejemplos son la NeoGeo o la Megadrive/Genesis que lo usaban para controlar el chip de sonido.
En la GBA han añadido dos canales de sonido digital, lo que llaman Direct Sound. Pero no llevan un procesador especial. Se controla directamente desde el arm escribiendo en unos registros. El chip de sonido se encarga de leer las ondas de una zona de memoria especial via DMA.

El caso es que hacer un emulador de z80 estaría bien porque abriría la puerta a un montón de máquinas. Si además es bueno (rápido) se podría utilizar en emus de Megadrive y cosas por el estilo.

Por cierto, lo de que los emus no transforman código, es un decir. Procesadores "sencillos" como el z80 o incluso el 65816 se pueden emular del tirón, pero desde hace ya algún tiempo los emulatas suelen usar un método conocido como Dynamic Recompilation o Dynarec, que lo que hace es parsear el ensamblador original de la máquina a emular y genera código de la máquina en la que se está ejecutando. Esto permite aumentar la velocidad de la emulación a veces hasta en 10 veces. Depende de muchísimos factores. El problema suele ser que consume mucha más memoria y es muchisimo más complicado de programar. Un buen ejemplo de este sistema es el UltraHLE, que es de los primeros emuladores que lo usaban. Básicamente a eso es a lo que ellos llamaban High Level Emulation (HLE).

Si teneis más dudas, pues ala, a preguntar que pa eso estamos.

[Sd-Snatcher]

(Menos el Turbo-R, que usa R800 además de Z80)



No, no, el Turbo-r no tiene Z-80, el R-800 es un derivado del z-80 totalmente compatible, de hecho el r800 es un z80 con multiplicacion a 16 bits, y a 7 mhz.

[xenon]

http://www.faq.msxnet.org/msxtr.html

Aqui encontrarás que el turbo-r, tal como dije, usa un z80 de apoyo....

# RISC CPU R800 (DAR800-X0G), 28.63630 MHz internally (16-bit). (Can be accelerated to 40MHz by changing the crystal.) A cooler is required due to heat development.
# CPU Z80A 3,5 MHz compatible (DAT9769C, 8-bit, included in the S1990, see below)

Un saludo :brindis:

[bitrider]

Bueno, y entrando al trapo de una cosilla que se ha dicho un par de post más arriba.

No sé por qué tenéis la extraña idea de que un emu de GBA en tiempo real fácil, porque basta con meter en la memoria de la GP32 la rom de GBA y echarla a rular. Porque ambos tienen un procesador de la misma familia.

Megustaría decir que esto dista bastante de ser real. Una virtualización de este tipo sería más complicado que hacer un emulador con un interprete clásico.

Tenéis que daros cuenta que son máquinas totalmente diferente, funcionan a diferente velocidad, la memoria está mapeada de forma diferente, los procesadores NO son exactamente iguales y la circuitería de apoyo no es la misma ni por asomo.

Total, que habría que conocerse la GBA al dedillo (cosa que también pasa en un emu clásico) y la progrmación y funcionamiento de la GP32 y ,principalmente de su procesador, también al dedillo (esto no sucede en tan alto grado en la emulación estándar). Habría que usar, en el caso de la virtualización, técnicas mucho más complejas.

[Sd-Snatcher]

He leido y escuchado opiniones al respecto de todo tipo.

Unos dicen una cosa otros otra, pero hay una cosa que esta clara, el R800 puede ejecutar codigo del Z80, entonces, ¿para que otro Z80?, Incluso por haber, hay gente, mucha que dice las dos cosas ¿¿¿¿¿???????.




http://www.mccm.aktu.nl/millennium/milc/turbo-r/topic_5.htm




2.2.3 BLOCK DIAGRAM

The MSX Turbo-R system-equipment is explained with a block diagram.
The MSX Turbo-R has 2 CPU's (Z80 and R800). The type of processor (R800 or
Z80) can be freely changed in the use of program. If one of the processors
is used the other processor will be put on HOLD.
It is not possible to use both the processors at the same time.

<8 CHAPTER 2 SYSTEM ORGINAZATION>
Å--------ã Å--------ã Å---------ã Å------------ã
¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡
¡ Z80 -------¢ S1990 -------¢ R800 ------¢ DRAM ¡
¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡
-------- ----\--- --------- ------------
¡



2.4.1 FEATURES OF THE R800

The R800, develloped CPUused in the Turbo R, has the features shown below.

1. Z80 and object-compatible
With the software written for the Z80 note that the parts dependent on the
timing of the CPU are removed and not-changed can be used.

2. The CPU clock frequency is 7.15909 Mhz
Because compared with the number of clockpulses per instruction in the Z80
sharply lower , the z80 conversion is in fact at the speed on 28.63636Mhz
(If there are no waitstates).
3. multiplication commands
the multiply command that is supported has an accuracy of 8bit x 8bit ->
16 bit and also 16bit x 16bit -> 32 bit
Dependend on this, bigscale progress of mathematical- operation-procedure
speed is possible. (??)
4. LSB/MSB defenition instructions
With the Z80 / The access of the higher and the lower 8 bit of register
IX/IY with the LSB/MSB defenition is properly ensured
In figure 1.2 the [verwerkings]speeds of the most important instructions is
shown. (When the Turbo R has no waitstates. On the MSX 2+ 1 waitstate
occurs on the M1 cycle.??)


----------------------------------------------------------------
http://www.old-computers.com/museum/computer.asp?st=1&c=290

CPU R800 - Z80A downwards compatible but 5 to 10 times faster than a Z80
SPEED 3.579545 MHz (Z80 mode), 7.16 MHz (R800 mode - equivalent to a 28.64MHz Z80 CPU)

http://www.old-computers.com/museum/computer.asp?c=627

CPU Zilog Z80A and R800 (16 Bit RISC)
SPEED Z80A: 3.579545 MHz / R800: 28.636360 MHz

http://www.old-computers.com/museum/computer.asp?c=775

CPU 8-bit Zilog Z80A and 16-bit RISC R800 (DAR800-X0G)
SPEED Z80A: 3.579545 MHz / R800: 28.636360 MHz

-----------------------------------------------------------------
Aqui por ejemplo una discusion, incluso sobre si el procesador es o no RISC.

http://www.msx.org/forumtopic923.html

------------------------------------------------------------

[Sd-Snatcher]

emu de GBA en tiempo real fácil

No se si se ha dicho tanto como facil, pero lo que si se ha descartado, es una emulacion en alto nivel, por que la gp32 no da para ello, asi que se buscan nuevas vias, lo otro ya existe (ports de emus de gba), pero no vale de nada asi que como si no.

Quizas se necesite un Core ARM7 en ASM.

[azrael]

SInceramente no tengo mucha idea... pero preguntrle a Porpeller que creo ke es un programdor experimentado.
La arquitectura ARM es escalable, es decir, el codigo de un arm7 se puede ejecutar nativamente en un arm9. Lo unico que ocurriara es que se ejecutara mas rapido.
Y no seria posible ejecutar unicamente el codigo para ARM a la velocidad a la que se ejecuta en el arm7 (un ciclo de cada diez mas o menos, creo)y utilizar el resto para EMULAR los dispositivos IO de la GBA?(entiendo por dispositivos IO los diferentes procesadores para los modos graficos etc..)
Salu2
azrael

[bitrider]

es que es en lo único que se parecen una GBA y una GP32, en que tienen un procesador *PARECIDO*.

Difiere en:

*Distinto conjunto de instrucciones (el ARM7 tendrá un subconjunto de las instrucciones del ARM9, pero las instrucciones exclusivas del ARM9 han de ser consideradas inválidas para que se comporte como una GBA real )
*Distinta velocidad de proceso. (algunos juegos pueden recaer en esto para según qué efectos/algoritmos)
*Distintas direcciones de memoria.
*Distinto soporte de almacenamiento.
*Distinta circuitería de apoyo (chips de sonido, reloj, pantalla,...)

En resumen, algunas de estas cosas sería casi imposible de realizar con la virtualización (velocidad de proceso correcta y eliminar instrucciones extras), otras requerirían un gran esfuerzo de programación: Crear un programa que en todo momento monitorizase el comportamiento del código GBA e hiciese las traducciones oportunas (mucho más difícil de lo que suena a simple vista).

No es que sea imposible, pero como decía SD-Snatcher, es emulación de alto nivel. Pocos tienen la capacidad y disponibilidad de recursos (tiempo sobre todo) para dedicar a esta tarea. Es muuucho más sencillo crear un emulador que funcione como un interprete, o incluso más realizar un port de un emu que ya funcione.

[Sd-Snatcher]

Bueno, digamos que con alto nivel me referia a precisamente un port por ejemplo del VGA, hecho en C (Por eso lo del core en ASM), y eso ya se ha hecho, y no vale para nada. Yo como propeller creo que la unica salida es la virtualizacion, y los problemas a los que tu haces referencia son los normales en cualquier virtualizacion, pero se han superado muchas veces.

A ver, una posibilidad:

*Distinto conjunto de instrucciones (el ARM7 tendrá un subconjunto de las instrucciones del ARM9, pero las instrucciones exclusivas del ARM9 han de ser consideradas inválidas para que se comporte como una GBA real )

---Ya pero los juegos de GBA no usan ninguna intruccion del ARM9, no se trata de que se comporte como una GBA, es un emulador. El unico caso que conozco que funcione como tu planteas es el emulaor de coleco para msx, pero esas maquinas son un 95% iguales, solo varia la bios y las direcciones de I/O, que es donde trabaja el emu en el MSX, a la vez que ejecuta el codigo nativo de la Coleco.

La solucion es como la del emulador de gameboy para msx, el procesador de virtualiza y el resto se emula.


*Distinta velocidad de proceso. (algunos juegos pueden recaer en esto para según qué efectos/algoritmos)

Bueno gracias a esa diferencia se puede emular, habra que tener varios procesos, uno para el "core" de ARM7 y otro para la emulacion del hard añadido.

*Distintas direcciones de memoria.

Para eso estan los desplazamientos.

*Distinto soporte de almacenamiento.

Creo que esto es lo de menos. No creo que nadie piense insertar un cartucho en la GP32, y el programa una vez en memoria , es el programa.

*Distinta circuitería de apoyo (chips de sonido, reloj, pantalla,...)

La que tiene que ser emulada.




La 3ª via seria parsear la ROM y convertirla en un programa de GP32, pero creo que puede ser incluso mas complicado.

[Segata Sanshiro]

La 3ª via seria parsear la ROM y convertirla en un programa de GP32, pero creo que puede ser incluso mas complicado.`

Sí, pero suena de bien... :D :musico:

[bitrider]

*Distintas direcciones de memoria.

Para eso estan los desplazamientos.

*Distinto soporte de almacenamiento.

Creo que esto es lo de menos. No creo que nadie piense insertar un cartucho en la GP32, y el programa una vez en memoria , es el programa.


No lo sé cierto, pero creo recordar que hay cartuchos de hasta 128Mbits (16MBytes), por lo tanto que el medio de almacenamiento toma una relevancia especial, mas aún cuando la GP32 no tiene mas que 8MBytes, de los cuales quizás pudiésemos utilizar 5 ó 6 como mucho (el emu ocupa espacio).

Y en cuanto a lo de los desplazamientos...

Creo que la mejor solución a estos dos problemillas estaría en la MMU, que para algo está.

[azrael]

Originalmente anunciado por Segata Sanshiro
Sí, pero suena de bien... :D :musico:
En ese caso a la GP32 le sobraria ram por todos lados...
y me da a mi que los juego sirian casi de masiado rapidos...
HABLANDO DE ESO.... no seria factible realizar un programa ke parseara los juegos el solito?
Seria parecido a programar un emulador... pero los resultados creo ke serian mas satisfactorios si se consigue.
El unico problema seria el tiempo ke perderiamos parseando juego por juego...
Pero kien no lo haria??? :D
salu2
azrael

[Segata Sanshiro]

Pero habría problemas... Por ejemplo, el programa tendría que simular la estructura de tiles, planos y scrolls de la GBA... Si la GP32 tuviera algo parecido igual se podría hacer directamente, quién sabe cómo hubiera sido, pero no lo tiene. Sería difícil de hacer.

Supongo que habría que:

+Determinar dónde acaba el código del juego y empiezan gráficos, etc.

+Sustituir las interrupciones por las correspondientes en GP32

+Simular (supongo que en tiempo real) los tiles, sprites y planos de scroll de la GBA

+...

Vamos digo yo.

[azrael]

Una pregunta, existe un precedente a lo ke he descrito?

[ilarri]

kizas si, kizas no, kien sabe.Los k lleven mas aki supongo k tendran mas idea al respecto.
pero por las respuestas, k nadie te ha puntualizado lo tipico "eso ya se dijo"" eso ya se comento hace..." me parece que has planteado una via inexplorarada hasta el momento, dificil,compleja,larga en tiempo de realizacion....pero kien sabe si
con futuro.

pd:los 2 proyectos secretos k dejo caer anarchy k estaban en realizacion, es evidente k el fgen no es uno de ellos,pues se dijo antes de la aparicion del nuevo core luego....a k se referiria??

voto por atar a anarchy a una silla y obligarle a ver como hacemos una fogata, tipo campamento, y usamos sus consolas como madera xDD, aunk creo k no podria soportar ni la idea!!, k cruel soy! en serio....especulo, pk no se nada...sera un emulador de gba k ya hace funcionar algo?? ojala

[Efompor]

Reesy tiene un Z80 core en ARM ASM que él hizo para su emulador de "drSms" en GBA. Se ha dado ya al fDave y a Rlyeh para el trabajo sobre sus emuladores de la genesis.