Respuesta: Muy buenas,
Soy David Senabre, gracias y perdona por haber tardado tanto en responder personalmente, pero no he tenido ni un sólo día de vacaciones en todo el verano, y trabajo a jornada completa.
El tema de las señales de control del bus del M68000, la CPU de la Megadrive , no es un tema sencillo. Me encantaría poder ayudarte, pero tengo poco tiempo ahora mismo, así que haré lo posible.

La Megadrive NO sabe nada acerca de la SRAM de los cartuchos ni tiene porque saber nada. De hecho, es un decodificador, dentro del cartucho, el que se ecnarga de habilitar la SRAM cuando la dirección a la que acceder la Megadrive cae dentro del rango de direcciones asignado a la SRAM , es decir, al area del mapa de memoria de la SRAM del cartucho. Este rango suele estar si no me falla la memoria, $200000-$202000 (si es una memoria de 8Kbytes). Para direcciones inferiores a la $200000, esto es, hasta la $1FFFFF, el decodificador del cartucho directamente habilita la ROM y deja la SRAM desactivada (manteniendo su entrada /CS a alta). Entiende, por tanto, que la Megadrive no sabe nada acerca de qué tipo de memoria o dispositivo está ahí, sino que simplemente el progrador del juego o la ROM , sabe que en ese cartucho, en ese rango de direcciones, una circuitería adicional, el decodificador, habilitará una u otra memoria.

Puedes aprender mucho sobre las señales de control de los buses de la consola en el siguiente apartado de mi proyecto de Megadrive (en inglés, eso sí)

http://www.consolasparasiempre.net/proyectos/megaflash/MD%20signals.htm

Y en general, en el apartado de proyectos de la web.

No dejes de contactar conmigo para cualquier consulta, intentaré ser más rápido.

Un saludo

DaviD

Pregunta de: Pepigna

Mensaje: Muxas gracias por todo proximamente te enviare un esquema con lo que tengo realizado.
Solo una cosillla, mas para leer de sram se necesita un retardo?Es decir tengo k implemetar un contador??Es que, nuestro esquema se ha basado en seguir las pistas de un sonic 3 para la realizacion del cartucho. El cartucho usaba 8 puertas nand 2 multiplexores y 2 biestables (flip-flop)
A parte de las correspondientes memorias.
El problema esta en que no le veo utiliadad a tanta circuiteria, a noser k implemente un contador, entonces si seria necesario.
Weno espero no molestar muxo y haber si me puedes ayudar en algo
Salu2222

Respuesta: Hola,

La utilidad de esa circuitería es la de poder interactuar con la memoria para salvar partidas. Has ido a escocger un cartucho muy poco recomendable para estudiar el tema de la SRAM de los cartuchos, porque fíjate que no tiene pila, como otros cartuchos. ¿Por qué? Porque no usa SRAM (recuerda que la pila de los cartuchos sirven para que no se pierda la información grabada en la SRAM ). De hecho, el Sonic 3 usa un tipo de memoria completamente diferente, y no volatil, por lo que la partida permanece salvada por muchos años sin necesidad de pila. En concreto, una EEPROM serie llamada X24C01.

Brevemente, esa memoria se graba y se lee de forma serie por su pin nº 5 ( el de abajo la derecha, mirando el chip de frente con la muesca situada arriba). Sigue un protocolo maestro-esclavo bien documentado, y no es tan sencillo como leer y grabar una memoria RAM de toda la vida, dando una dirección por el bus de direcciones, y activando la señal de lectura (/OE) o escritura (/WE), recogiendo o suministrando el dato en el bus de datos, que suele ser de 8 o 16 bits.
La ventaja de la EEPROM serie es que solo usa 2 pines para todo. La SRAM requiere un pin para cada bit de datos (si es una RAM de 8 bits, pues 8 pines de datos), un pin para cada línea de dirección, igual al logaritmo en base 2 del tamaño de la RAM (10 líneas para 1Kbyte, 20 líneas para 1Mbytes, etc..). Una SRAM de 8 Kbytes típica de muchos cartuchos por ejemplo suele ser de 28 pines (incluyendo alimentación y señales de control). La EEPROM serie de unos 8. La desventaja es que como ves requiere una circuitería adicional.

Yo todavía no sé como se debe programar la Megadrive para acceder a esa memoria, pero sí puedo decirte que los juegos que usan memoria SRAM estándar, que son todos los que conozco menos el Sonic 3 (pero tal vez haya otros), no van a poder salvar y grabar partida en un cartucho regrabable que lleve EEPROM, precisamente porque como te dije, en una SRAM:

La Megadrive NO sabe nada acerca de la SRAM de los cartuchos ni tiene porque saber nada. De hecho, es un decodificador, dentro del cartucho, el que se encarga de habilitar la SRAM cuando la dirección a la que acceder la Megadrive cae dentro del rango de direcciones asignado a la SRAM , es decir, al area del mapa de memoria de la SRAM del cartucho. Este rango suele estar si no me falla la memoria, $200000-$202000 (si es una memoria de 8Kbytes). Para direcciones inferiores a la $200000, esto es, hasta la $1FFFFF, el decodificador del cartucho directamente habilita la ROM y deja la SRAM desactivada (manteniendo su entrada /CS a alta). Entiende, por tanto, que la Megadrive no sabe nada acerca de qué tipo de memoria o dispositivo está ahí, sino que simplemente el progrador del juego o la ROM , sabe que en ese cartucho, en ese rango de direcciones, una circuitería adicional, el decodificador, habilitará una u otra memoria.

Como la EEPROM no recibe direcciones directamente del bus de direcciones de la consola, porque dicha memoria no tiene bus de direcciones como tal (recuerda, solo usa 2 pines para todas las transferencias), no se puede acceder a su contenido leyendo o escribiendo del área de memoria de la consola $200000-$202000. Se requiere otro procedimiento.

Como tú no te vas a dedicar a programar, no te importa demasiado cúal es el método de acceso que hay que usar en este caso, pero sí debes saber que un juego que esté programado para usar SRAM, accederá a ella de la forma correcta, pero no sabrá nada sobre cómo acceder a una EEPROM serie, y viceversa... espero haberte ayudado un poco, no dejes de ponerte en contacto con nosotros para nuevas consultas, estarémos enctantados de ayudarte, aunque tardemos hasta una semana en responder por motivos de trabajo. Si en algún momento requieres una contestación urgente, marcalo en el asunto del email y haremos cuanto podamos.

un saludo cordial.

DaviD

Pregunta de: pollo septiembre

Mensaje: Hola:

Estuve leyendo los documentos sobre los programadores Flash, me interesa mucho, espero poder construír uno, aún si bien mis conocimientos sobre electrónica son algo básicos aún, creo poder armar uno y no morir en el intento. Pero sería de bastante utilidad incluír en la web una lista de elementos, para poder ir a comprarlos o conseguirlos. Al menos a mí me sería bastante útil ¿Es posible que me puedan enviar una sobre el programador flash?

Desde ya muchas gracias, pero antes de despedirme quisiera felicitarlos por su página, es más que excelente.

Pregunta de: andoba

Mensaje: Disponemos de dos cartuchos de Sonic 3 (PAL y NTSC-J), para ser más exactos, modelos 670-3655-50 (PAL) y G-5531 (NTSC-J). Ambos cartuchos disponen de una memoria RAM no volátil ferroélectrica paralela, de 4 kilobits organizados en palabras de 8 bits. El integrado en cuestion es el RAMTRON FM1208-200CC, el cual es similar al RAMTRON 1608.

También tengo oído que ciertos juegos usan una EEPROM serial (NeoFlash me dijo que el VectorMan 2 USA), pero el caso, nosotros tratamos de hacer funcionar una SRAM paralela en un cartucho de Mega Drive.

Entonces, ¿ la SRAM paralela no necesita circuitería adicional? (exceptuando circuitería para mantener el tiempo de lectura y escritura de la MD con el del integrado al mismo nivel). ¿Las funciones de LDSW y UDSW serían las de /OE y /WE?
(esto aún no lo tenemos demasiado claro).

Muchas gracias, saludos.

Respuesta:

En efecto, la SRAM no requiere circuitería adicional, ni para mantener el tiempo de lectura/escritura ni para nada, sólo un circuito que active la SRAM en el area de memoria correspondiente (como le comentaba a tu amigo en mi primer email).
Normalmente se usan o los 8 bits altos, o los 8 bits bajos del bus de datos de 16 bits de la Megadrive. LDSW y UDSW son ambas señales de escritura, y se debe usar una o la otra en función de cuales de los 8 bits se usen para la SRAM. LDWS para las SRAM que van conectadas a los 8 bits bajos, y UDWS para las que usan los 8 bits altos. Estas harían de /WE. /OE sería como de costumbre, la señal de lectura.

Espero que quede un poco más claro. Si necesitáis más ayuda, sabeis donde estamos.

Un saludo

DaviD

Pregunta de: Jordi

Mensaje: Hola se podria hacer un cartucho regrabable con un shvc-1aon tendrias algun manual como el que tienes hecho con dos memorias
Muchas Gracias, una de las mejores paginas que he visto del tema

Hola,

Gracias por contactar con nosotros.
El cartucho que me dices es el mismo que el que uso en mi artículo pero con una sola ROM, no?
En caso contrario, me ayudaría saber qué juego es, y cual es el decodificador que usa, es decir, el chip que no es ni la ROM ni el CIC (el que lleva el nombre de Nintendo).

Espero tu respuesta.
Un cordial saludo.

DaviD

Pregunta de: Jordi

Mensaje: Hola he echo el corte en el de la cara de delante y en esta de detrás he cortado las 2 pistas que esta en amarillo, pero al ponerlo la consola se queda casi sin corriente como si tuviera algún cruce las he testeado con el tester y no hay no hay continuidad tengo que cortar alguna pista mas?
Muchas Gracias por la ayuda

Buenas,

Vamos a hacer un diagnostico por partes.
1) Que memoria has puesto en el zócalo? Está bien grabada?
2) Qué programador has usado y que ROM has metido?
3) Has cortado la señal /WR de la memoria flash?

Un saludo

David

Pregunta de: Jordi

Mensaje: Creo que si que las tengo bien cortadas faltaba una :) la que me decias pero pasa lo mismo la memoria es una eprom de ordenador pero mañana comprare una como la que dices, el programador es un SuperPro 680 marca xelteck; el juego me lo baje para probar de una de esas roms pero no me digas que me baje creo cabernan ninja pero no estoy seguro y lo grabe como binario

Gracias

Pregunta de: Antonio Flores

Mensaje: Muy buenas!

Estoy muy interesado en si se puede construir un cartucho flash para super nes cuya capacidad sea la máxima(usual, excepto uno de 5 megas que no recuerdo como se llama) 4 megabytes(32megabits como lo llamaban ellos).

He visto el que explicas en la página de hasta 1 megabyte, pero no resulta muy útil para coger una rom cualquiera(que no tenga chip FX o compresión por hardware como el street fighter alpha 2) de 2 o 3 megabytes, grabarla, pincharla en la consola y a funcionar, porque sencillamente no cabe.

Estoy muy familiarizado con el tema de roms, ram ... soy ingeniero técnico industrial en electrónica y me manejo mucho con 8051,ARM7 y ARM9.

Respuesta: Hola,

Gracias por contactar con nosotros.
Se agradece hablar con alguien con tus conocimientos, así me puedo
explicar mejor.

En respuesta a tu pregunta; sí se puede.
Pero el único método aceptable desde mi punto de vista (si no quieres
usar 8 pastillas ROM tipo DIP de 512Kb cada una, más un decodificador
3:8, lo cual es un lio importante), es usar memorias de montaje
superficial, en este caso TSOP 48.
No sé si conoces este encapsulado, y si tienes medios para fabricar un PCB sobre el que soldarlo, etc... Si es así, una 29F032 sería perfecta.
Yo tengo una en mi cajón esperando a tener tiempo para hacerlo, pero de
momento se retrasará un tiempo.

Sino puedes usar TSOP, no te queda otra que buscarte la manera de poder
cablear 8 ROMs, compartiendo las líneas 19 de dirección más bajas
(A0-A18) y usando las 3 línas siguientes (A19-A21) como entrada a un
deco, con cada una de sus 8 salidas conectada a un /CS de una ROM.

Si necesitas más ayuda pídemela. Solamente he esbozado las dos
posibilidades que me vienen a la cabeza ahora mismo... cabría la
posibilidad de usar otras memorias superficiales no tan dificiles de
manejar como la TSOP , como el encapsulado SO, cuyos pines están algo más
separados, siguen siendo memorias de 1Mb, pero en un cartucho de 2
zócalos podrías montar facilmente 2 de ellas, o incluso 4 sin mucho problema (para llegar a los 4Mbytes), porque son más finitas. Te aviso,
no obstante, que estás memorias SO se están dejando de fabricar y son
dificiles de encontrar (bastante).

Espero noticias tuyas, aunque podría demorarse mi contestación unos días
por tema de trabajo.

Un saludo

DaviD

Pregunta de: Antonio Flores

Mensaje: Es un proyecto que tuve que aparcar porque me robaron la supernes hace un par de años, que triste entran en mi casa del campo y en lugar de llevarse la tele se llevan la super(suete que no encontraron los cartuchos sólo llegué a tener 4 pero todos muy buenos en esos tiempos todos hicimos intercambio de cartuchos con los colegas, seguro que lo recuerdas, ahora intento conseguir otra, para experimentar y eso. En un principio yo tenía esbozado a ver si podía utilizar un ARM7(mejor este) o incluso un Z80( con programa en chip externo claro) para que recogiera la dirección solicitada por la consola y direccionar a su vez por puerto usb a 12Megabits/seg

un pen drive(claro que habría que meter las roms en la raíz e indicarle en un txt la rom que queremos cargar, para que capture el intervalo de memoria en el que se encuentra la rom a modo de offset que se sumaría a la dirección pedida por la supernes, leería la rom desde el usb y le llevaría el dato de vuelta a la supernes. Este planteamiento necesita las roms en el pen de forma consecutiva, vamos un pen drive desfragmentado porque sino hay que currarlo mucho más y temo no llegar a esos niveles...jajaj

Pero esto me parece muy ambicioso como para hacerlo de buenas a primeras y lo tuyo parece más sencillo.

Si consigo una supernes (ya tengo protegida mi casa del campo con una alarma con teléfono que yo mismo hice en ARM7) seguiré con el tema, más que nada por aprender y eso.

No sé tanto de componentes como tú, estas hecho todo un jefe.

Un saludo David, y muy buena página la vuestra.

Respuesta:

Me encanta tu idea, pero por atrevida y por apasionada. Me encanta imaginar cosas así.
Ahora bien, dudo que funcionara. Un ARM7 no es fácil que supere los 50 MIPS. Eso implica que ejecuta una instrucción cada 20 ns.
Hasta lo que sé, la SNES requiere que se le entrege el byte que solicita en menos de 200 ns, y algunos juegos en menos 120 ns. Eso te da para una 6 u 10 instrucciones.
Pero para detectar la dirección que le pide la SNES , el ARM7 necesitaría al menos un par de instrucciones, y para comunicarse por USB, bastantes más. Y eso no es más que una parte del proceso. El Z80 sería aún más lento. El pendrive tiene q procesar la solicitud de lectura y mandarla al ARM7 que su vez la dirija al bus de datos de la SNES. Has violado todas las restricciones de tiempo por mucho. Yo ya había pensando muchas cosas parecidas a esta.

En cambio, lo que yo comento funciona muy bien. Si puedes soldar un ARM7, que seguramente lo tengas en encapsulado TQFP, podrías soldar una TSOP en un PCB a medida, si puedes hacerlos por insolación. Es mucho más sencillo, barato, y una flash de tipo 29F032 se parece mucho a una ROM original, y respondería a la consola en menos de 100 ns. De hecho, más rápido que las ROMs originales.
Vamos no tiene sentido complicarse, aunque si quieres hacer algo de ese tipo, te recomiendo que leas lo que tengo publicado de mi proyecto de Megadrive, en el que cargo ROMs de una Compact Flash por puerto de expansión a un cartucho regrabable, usando una BIOS que carga por el propio puerto de expansión, y otorga a la consola de un interfaz básico de menus, para mandar partidas salvadas a un PC, y recogerlas también.
Pero lo de cargar ROMs, primero las cargo en el cartucho que lleva una memoria flash como la que te he comentado antes, pero de 16 bits. Luego, desde ahí se juega. No se tarda más que unos segundos en cargar la ROM en el cartucho, luego el sistema es genial!! En un futuro quiero implementar un controlador de memoria SDRAM en una FPGA y usar una SDRAM en lugar de la Flash para carga el juego, lo que permitiría cargarlo mucho más rápido.

Un saludo

DaviD

Pregunta de: inacete

Mensaje: He encotrado buestra pagina por casualidad y estoy con un proyecto de electronica-programacion que me viene muy grande. Necesito cualquier ayuda que me podais prestar.

Me he propuesto lo siguiente:

1 º Conectar una pistola de juegos a mi pc, la "lcd topgun" con la que se puede jugar en pantallas de todo tipo. lleva unos sensores de led que dan la posicion a la que se apunta.

2º conectar por usb el pc al puerto de juegos de mi dreamcast y que el ordenador simule un pad de esta consola.

3º escribir un programa que tome los datos de la pistola y los mande a la dreamcast, asi poder jugar al THE HOUSE OF THE DEAD de dreamcast en mi monitor tft

Lo que he avanzado:

1 comprobado que la pistola conectada al pc funcion perfectamente con los sensores en otro sitio que no es el monitor.

2 la pistola trae un software sdk para programacion de juegos y utilidades.

3 me he informado del MAPLE BUS, el protocolo puerto de mandos de la dreamcast.

Para futuro he visto como conectar el mando de la WII en el pc, con este mismo sistema se podria jugar a dreamcast con este mando.

Si puedes aportar cualquier conocimiento o te interesa colavorar, escribeme a inacete@terra.es

Gracias. Un saludo

Respuesta: Muy buenas.

Te pido mil disculpas por no haber respondido antes, pero entre todo el spam que me llega, pasé por alto (no sé como) tu email, y acabo de verlo.

¿Como llevas el proyecto?
¿Resolviste las dudas?

Lo que proponias no era en absoluto sencillo. Ya sólo controlar una Dreamcat desde un USB tiene tela. Y ya sólamente hacer cualquier chorrada por USB tiene tela.

Ya me dices algo.

Un saludo

David Senabre

Pregunta de: inacete

Mensaje: Hola David, muy agradecido y sorprendido por tu respuesta.
Tambien agradecerte tu pagina web, he aprendido un monton en ella. Lo que es un analizador logico y muchas mas cosas.
La verdad es que el proyecto lo tengo parado, ahora estoy con otro tambien de dreamcast para poder conectarle un disco duro.
Estamos empezando y en poco tiempo tendremos pagina web, te mandare un link por si te quieres pasar.

Ya que me contestas voy a aprobechar un poco:
Tengo una pistola de juegos de la marca ems que funciona emulando raton. Tambien me he descargado un sdk que el mismo fabricante pone en su web para que cualquiera pueda programar cosas para la pistola.
He comprobado que por el puerto paralelo se pueden mandar pulsaciones a un mando preparado (soldar las salidas de datos del puerto paralelo a los interruptores del mando) lo que se llama hackear un mando.
lo que tendria que hacer es un programa que pasara los datos de driver de la pistola al puerto paralelo.
La verdad es que no controlo nada de programacion asi que lo tengo muy parado.

Un saludo y gracias otra vez

Pd: voy a entra a tu pagina web un rato a ver si aprendo algo mas.

Respuesta: Hola,

Me alegra saber que has aprendido cosas, ese era uno de mis principales objetivos.
Lo de conectar un disco duro a la Dreamcast es algo que pensé hace ya tiempo, y algo que estoy seguro que podría hacer, pero que en mis circustancias actuales no me sería posible, por falta de tiempo. Si no lo has leído, deberías pasar por la sección de "proyectos" y ver lo que tengo colgado sobre la Megadrive. Actualmente puedo cargar ROMs desde un disco duro o una tarjeta compact flash, y jugarlos en la consola. Mirate esto que colge en youtube hace poco
http://www.youtube.com/watch?v=DsbBpbylK88 ; son dos partes, la del link es la primera. Busca los videos que tengo colgados sino te aparece.

Respecto a lo de la pistola, no sé si te he entendido bien...
Quieres usar un mando como si fuera la pistola, para que los drivers de ésta lo controlen? Obviamente si no sabes programar, está dificil. ¿Qué conocimientos tienes en otros campos, como por ejemplo electrónica? ¿Estás estudiando algo (carrera, curso,...)? Un poco para ubicarme.
Puede que tal vez te interese leer en la sección de "el taller" el artículo que escribí
sobre el programador Flash. Diseñado y construído desde cero, es una placa que sirve para grabar y leer memorias flash, usando el puerto paralelo de un PC y un software también programado por mi, que muestra como constrolar el puerto con Delphi desde Windows XP.

Ya me dices algo, y gracias por tus comentarios :-)
Un saludo.

David Senabre

Pregunta de: Fabio Bernal

Mensaje: saludos de mi parte y muy buena la pagina.
lo que queria preguntarles es cual es la diferencia entre el conector de cartuchos nes de 72 pines y los de 60 pines y como puedo convertir mi cartucho de 72 a 60 , les agradaceria mucho si me mandaran los diagramas de conectores de 60 pines y de los cartuchos de 60-70 mas los diagramas de las roms del cartucho gracias.

Repuesta: Hola Fabio,

En primer lugar, siento no haber respondido antes, pero el trabajo no me deja mucho respiro.
La única diferencia entre el cartucho de 72 pines y el de 60 pines es el pinout (es decir, la función de cada pin). Realmente son equivalentes, sólo cambian de sitio.
Existen adaptadores comerciales, y es posible fabricarlos, pero es dificil conseguir los conectores (en España al menos es totalmente imposible, a no ser que los saques de una consola que lo lleve).

Espero tu respuesta, y procuraré responder antes.
un saludo

David Senabre

Pregunta de: Javier Hernández Moreno

Mensaje: por favor mandenme paso a paso que necesito y como hago mi propio cartucho recargable de snes
vivo en mexico.

Acabo de adquirir un gameshark version 3.3 para n64 pero no cuento con el manual de uso y tengo muchas dudas sobre como se usa y especificamente sobre el puerto de 25 pines que trae
¿Me pueden ayudar con informacion sobre este accesorio?
Se los agradecere infinitamente.
p.d. Reciban un saludo de los mexicanos que nos interesan mucho los temas tratados en su web.

Pregunta de: francesc falip rubinat

Mensaje:

Hola antes que nada felicitaros por la web, y sobre todo, por los artículos tan brutales que os currais.
Solo queria comentaros una cosa que no me cuadra del artículo de la Wii. En vuestro artículo decis lo siguiente:
"Por empezar a hablar de algo, la CPU de la Wii, bautizada como Broadway, está fabricada en 90nm, en lugar de los 180nm empelados en el Gekko, procesador de la Gamecube. Esto permite obtener un chip cuya superficie de silicio ocupa la mitad."
Si no lo tengo mal entendido, al fabricar una CPU de 180nm a 90nm su tamaño se reduce a 1/4 parte del tamaño original.
De hecho, el broadway mide menos de la mitad que el gekko (18.9 mm^2 frente a los 43 mm^2 del gekko) por tanto no cuadra si solo se pudiese reducir el tamaño a la mitad.
Por lo menos eso es lo que tengo entendido, si me equivoco corregidme.

Saludos.

Pregunta de: Daniel Ballesteros Álvarez

Mensaje:

Buenas,mi nombre es Daniel.Andaba buscando-leyendo info sobre programacion en consolas antiguas y me tope por casualidad con vuestra pagina por el articulo :INTRODUCCIÓN A TILES Y BITPLANES,q me ha encantado.
He estado leyendo gran cantidad de ella y estoy impresionado.
Sobre todo en los articulos de las consolas de 128 bit.Toda esa documentacion,informacion,ademas de muy bien explicado.

Fui poseedor de una master system 2,un amstrad cpc 6128 q aun poseo pero sin monitor y una dreamcast (pobre,con juegazos como el shenmue no entiendo como pudo morir tan pronto..)

Ahora me ha dado por investigar cosas sobre la gameboy,si la primera,bueno mas en concreto sobre la version color.
Algunos juegos me tienen realmente impresionados ,pero sobre todo algunas demos tecnicas q vi por la red.

Se programar algo en c y java,no mucho la verdad,salvo las cosas tontas de algoritmos matematicos q hacemos en clase,...Del estilo de las q hacemos con el R y el sas.(Estoy estudiando estadistica).
Estoy buscando info para "meter mano en el tema" y afortunadamente hay bastante material disponible,incluidas las fuentes.
Y bueno ahora intentando aprender algo mas y empezar un poco con el asm z80,con el tiempo libre q me dejan los estudios.

Me da pena ver como cada vez mas y mas se desaprovechan las maquinas,como cualquier juego actual q pida unos requisitos increibles para a penas mejorar lo anterior,pero bueno.

Algo parecido con los sistemas operativos,los cuales sin mejorar nada util comen mas y mas recursos.Con lo bien q tira mi pentium 2 con linux todo el dia dandole cera.

Me gustaria  hacerte unas preguntas,espero q no sean demasiadas y no molestar demasiado,es q cuando me pongo a escribir,buff soy un torbellino de ideas.Hay van:

1)Preguntar/pedir si añadiras tambien a la gameboy y color en tu seccion de 8 bits,creo q seria fantastico.

Hace poco se ha creado un foro para reunir toda la info sobre esta consola ,q poco a poco se va perdiendo,y bueno hay hay alguna de mis "locas ideas",como xq no usar todas las fuentes disponibles
y crear una especie de gamemaker sin necesidad de reinventar todo ,si no de manera sencilla usar esos efectos,modos,y cosas de las demos,simplemente usando las fuentes disponibles y dediando todo el "esfuerzo" a la parte artistica y poder crear juegos del estilo  y con la calidad de fish files sin tener q reimplementar todo el codigo.(de hecho hay al menos 4 ejemplos para dibujar el fondo con hires de los cuales disponemos las fuentes.
http://gameboygenius.8bitcollective.com/gbdev/index.php

2)Por cierto la demo kirbyxxl y stuntfx supongo q podria funcionar sin ningun problema en la master system no?? Y el aumento de paleta de colores o hicolor de gbcolor??
(De la demo stuntfx no hay fuentes,me he puesto en contacto con el autor y me ha dicho q no tiene ningun problema en mandarlas,pero q tardara tiempo en encontrarlas)

3)si continuas con los manuales de programacion comentaras alguna demo de este estilo?Con trucos curiosos como el de estas q te puse arriba .Por ejemplo se q la demo del kirbyxxl es el fondo el q se mueve simulando un sprit grande ,y los sprits realmente son la nube y las montañas,y q la animacion solo cambia pocas partes para q entrara en la ram disponible,pero a parte de eso ,no se como meterle mano y cambiar ciertas cosas.(mi nivel de asm es minimo)

Ahora van sobre la gameboy advance ,

5)Y ya por ultimo,y espero no aburrirte,tengo unas dudas "tecnicas".En todos los sitios dicen q la gameboy advance no puede usar el chip z80 si esta en modo advance,y no entiendo muy bien xq.
Por ejemplo en la web de abajo  hay una aplicacion para poner el modo gbc habiendo arrancado el modo gameboy advance,pero aun asi dice q los dos a la vez no.Y por otro lado lei q el rayman advance usa el z80 para el sonido.
http://www.dwedit.org/dwedit_board/viewtopic.php?id=339

-Tambien he leido lo mismo sobre la ds y advance ,q solo permite usar uno de los arm,y no los dos,cuando seria muy util usar cada uno en una pantalla,para por ejemplo usar 3d en ambos sin tener q reducir el numero de fps.

Segun videos y cosas q he visto es una pena q no durara tambien un poco mas la gba,pues estaban en preparacion algunos juegos realmente impresionantes en 3D.
Me gustaria saber si la gba podria hacer cosas como el "floor over floor" ,por ejemplo usado en el motor de sonic roboblast2,q es psudo 3d,con sprites en 2d.Se q tiene poca ram,pero juegos como el doom2 y el mariokark muestran q se podria hacer no??

Bueno gracias por tu tiempo y por interesantisima pagina.Espero no haber mandado un mail demasiado largo/pesado.

Un saludo
Dani

Respuesta: Muy buenas Daniel,

Primeramente te agradezco tus comentarios positivos, y me alegro mucho que te haya servido.
Deberías leer los 3 artículos que tengo en la web sobre programación de consolas
clásicas, si no lo has hecho ya, pues es una forma muy buena de empezar. Los ejemplos son para la NES y la master system 2, pero cualquier de ellas te ayudará un montón a acceder a cualquier otra. Es tiempo bien invertido, créeme.

Paso a responder gustosamente tus preguntas.

1) Sí, está en el plan añadir la Gameboy, pero de momento por falta de tiempo ha tenido que ser pospuesto...
La idea que tienes me parece muy bien, pero haría falta gente y colaboración. Yo a penas doy a basto con lo que hago, porque trabajo y no tengo mucho tiempo libre. Mis proyectos me quitan bastante tiempo, y además todos los artículos, programas e informaciones técnicas las hago yo. Me encantaría vivir 200 años para aportar mucho más!

2) No conozco esa demo, pero si corre bien en GameBoy, puedes tener casi la certeza de que irá en Master System, pues no sólo es más potente, y dispone de más memoria, sino que comparten el mismo tipo de microprocesador. No veo ningún posible limitante. Se trata de recodificar todos los accesos a los puertos de video y sonido, pero seguramente no haya que hacer muchos cambios en el código, pues ambas se programan en ensamblador para el Z80.

3) Actualmente no tengo tiempo para seguir con este tema, al menos a corto o medio plazo, pero te agradecería cualquier aportación. Estoy dispuesto a preparar la información y publicarla, siempre reconociendo el mérito de su autor.

Por cierto, no hay pregunta 4)
:-)

5) Ahora no tengo tiempo para leer las fuentes que me has pasado, y te prometo que lo haré en breve y te responderé como es debido. De momento, aporto lo que sé de memoria.
El motivo por el cual no se puede usar el Z80 a la vez que el ARM7tdmi que corre los juegos de GBA es un tema de arquitectura. Por la forma en que un ingeniero diseña un sistema digital, hay cosas que se pueden y cosas que no se pueden hacer. Por la forma en la que está construída, se debe configurar la CPU maestra que va a ejecutar el código, y luego no es posible cambiar de una a otra. Por cierto es algo muy comprensible, dada la tremenda diferencia de arquitectura de un Z80 y un ARM. Sin ir más lejos las instrucciones de un ARM7 son de 32 o de 16 bits. En el caso de la GBA se usa el modo de 16 bits, llamado THUMB.

Yo me atrevería a decir, sin asegurarlo, es que sólo una CPU puede estar ejecutando código, pero que el Z80 es accesible por el ARM7 a través de algunos puertos, y sea posible acceder al mapa de memoria del mismo, cargar código, y lanzarlo a ejecución simultáneamente. Debes entender que el Z80 tiene su propia memoria, y el ARM7 la suya.

Por tanto son algo así como dos sistemas diferentes. Mientras el ARM7 ejecuta un juego de GBA, es posible que pueda hacer lo que te he comentado para poner al Z80 a trabajar en otras cosas,... en la Megadrive se hacía algo así. La CPU principal, un Motorola 68000, puede acceder, usando ciertos mecanismos, a un Z80 que suele emplearse para tareas de audio, y no sé si también es capaz de controlar el sintetizador yamaha que lleva la consola. Todavía no he programado cosas con sonido para ella.
Volviendo a la GBA, como supongo que el Z80 sigue teniendo acceso a los puertos de control del sistema de audio, aún cuando la consola funciona con el ARM7, es posible que se transfiera código ejecutable del Z80 para ser ejecutado en el Z80 y luego éste mismo lo envíe al hardware de sonido.
Todo esto que te he dicho es simplemente una suposición mia.

Bueno, eso que dices sobre la DS y la Advance no es cierto. La DS usa los 2 ARMs. El ARM7 de hecho es el único que puede leer el estado de la cruceta y los botones, y creo que de la pantalla táctil también. Ambos, el ARM7 y el ARM9 se comunican por diversos métodos. Y sí, te lo digo, que yo he programado demos para GBA y DS (y colgaré muy pronto en la web). La DS usa
siempre los 2 procesadores.

Respecto al floor over floor y demás no lo sé, es muy dificil de decir, y arriesgado por mi parte de afirmar... Pero en principio no veo ningún impedimento en hacer juegos pseudo3D usándo sprites 2D. Es técnicamente factible, aún cuando deba prestar mucha atención a hacer las cosas eficientemente (por ejemplo nada de divisiones a destajo, el ARM7 no tiene unidad aritmética para divisiones y para hacerlas requiere usar reiterádamente la operación de resta, consumiendo muchos ciclos de CPU) ¿Cuándo dices poca ram, te refieres a la ram de video o a la ram principal?

Muchas gracias Un saludo

David