Pues eso. Que me pica la curiosidad de si existe algún método de portear soft de una a la otra plataforma, siempre contando con las limitaciones lógicas entre ambas máquinas.
Me dicen que @xzakox controla sobre gameboy, a ver si él sabe algo.
Pues eso. Que me pica la curiosidad de si existe algún método de portear soft de una a la otra plataforma, siempre contando con las limitaciones lógicas entre ambas máquinas.
Me dicen que @xzakox controla sobre gameboy, a ver si él sabe algo.
Si la lógica del juego está hecha con C me imagino que será mucho más fácil que si es ensamblador.
No sé qué procesador lleva la GB y si es pariente del Z80.
aquí hay bastante info
http://marc.rawer.de/Gameboy/Docs/GBCPUman.pdf
Game Boy Specs
CPU: 8-bit (Similar to the Z80 processor.)
ï Main RAM: 8K Byte
ï Video RAM: 8K Byte
ï Screen Size 2.6"
ï Resolution: 160x144 (20x18 tiles)
ï Max # of sprites: 40
ï Max # sprites/line: 10
ï Max sprite size: 8x16
ï Min sprite size: 8x8
ï Clock Speed: 4.194304 MHz(4.295454 SGB, 4.194/8.388MHz GBC)
ï Horiz Sync: 9198 KHz (9420 KHz for SGB)
ï Vert Sync: 59.73 Hz (61.17 Hz for SGB)
ï Sound: 4 channels with stereo sound
ï Power: DC6V 0.7W (DC3V 0.7W for GB Pocket)
El procesador de una gameboy basicamente es un z80, el problema es la parte del scroll y los sprites que en el spectrum lo tienes que hacer por software y si quieres que vaya rapido tienes que tirar de ensamblador.
Metodo:
1 desensamblas una rom de gameboy
2 escribes rutinas de scroll y sprites (lo bueno es que la puedes usar en otros proyectos)
3 buscas en el código donde se mueven los sprites y scroll, lo redireccionas a tus rutinas
4 profit!!!
No es lo mismo tener diez años de experiencia, que tener un año de experiencia diez veces.
It is an undisputed truth that the Atari ST gets the best out of coders. No dedicated hardware, just the CPU and a frame buffer! Some call it Spartan, others name it Power Without The Price, and a select few say `challenge accepted'! --- by spkr from smfx
recuerdo que en una entrevista jon ritman dijo que era MUY diferente programar en spectrum y programar en gameboy.
futu-block (01/04/2018)
Estoy seguro que es muy diferente ya que en ensamblador para aprovechar el hardware se hacen virguerias que luego si se quiere pasar a otro sistema no serán nada fácil de aplicar directamente.
vamos a ver, ensamblador es codigo unico para todo, ¿no? lo unico malo que tiene el spectrum es que por su paleta grafica no puede tener mas de dos colores por cada 8x8 pixeles y gameboy trabaja mucho los 8x8 metiendole el doble de colores, asi que si se logra portar algo de gameboy a ZXspectrum habría que hacer un ''regraficado'' de la ostia, osea que ya no sería emulación sino ''port'' entrecomillado para que no me apaleen (por si acaso)
En cuanto de ZXspectrum a gameboy debería ser muy ''facil'' tambien, lo de tambien es por el tema de paleta, incluso estaría guapo decidir como adaptar los dos colores a los cuatro de gameboy por cada 8x8, peeeeeeeeero, ahora es cuando el gameboy vá a dar problema porque tiene una resolución de 160x140 versus los 265x190 y no me acuerdo que tiene el ZX spectrum (creo que 196) osea que es otro gol por la escuadra, y ya van dos
Total, mi veredicto es que como emular N64 en la gp2x F100, imposible, aunque no descarto que alguien lo haga y estoy deseandolo, pero si no se hacen ports de juegos individuales como que nanai
Google stadia es un fracaso, google stadia funciona mal, google admite su fracaso con stadia la latencia es el problema intrinseco de stadia, el público abandona google stadia, stadia mal.
davken (01/04/2018)
¡Es el horror de los horrores!
El lenguaje ensamblador es totalmente dependiente de la arquitectura, cierto es que en dos arquitecturas diferentes con mismo procesador los mnemónicos (nombres) de las instrucciones van a ser los mismos... pero ahí acaba la similitud. Los resgistros del procesador que utilicen, el rango de direcciones, lo que haya en cada rango de direcciones (adaptador de vídeo, de audio, DMA...) es completamente distinto... así que las rutinas serán todas radicalmente distintas para cada plataforma.
Algo más fácil es si estuviera todo hecho en C, con HexRays se puede recuperar "relativamente" bien las funciones en C a partir del binario; pero en aquellos tiempos se hacía casi todo en ensamblador... sirva a modo de ejemplo: incluso Metal Slug que es un juego de 1996 recuerdo haber leído por ahí que se escribió en ensamblador, y en el 96 el lenguaje C y los compiladores de C para procesador 68000 ya llevaban un largo tiempo en el mercado.
La maestría interior...
Metal Slug para Atari STE: Video-1 Video-2
En venta memorias de 512 KB y 1 MB para Amiga 500 y Amiga 500 Plus
En venta disco duro tarjeta micro SD para Atari ST/E, compatible SDHC
Se ha hecho algo parecido con juegos de C64 y se han portado a Atari 800.
En este caso creo que usaron la version de spectrum, por lo que tuvieron que reescribir todo el código pero teniendo una referencia.
Ups, pues no, usaron la del BBC micro, que también lleva un 6502
Última edición por swapd0; 03/04/2018 a las 01:05
No es lo mismo tener diez años de experiencia, que tener un año de experiencia diez veces.
It is an undisputed truth that the Atari ST gets the best out of coders. No dedicated hardware, just the CPU and a frame buffer! Some call it Spartan, others name it Power Without The Price, and a select few say `challenge accepted'! --- by spkr from smfx
Marcadores