¿Creamos una consola?, si, pero con los pies en el suelo

Hola, me llamo PIC y mis siglas vienen de Peripheral I/O Controller. Mucho gusto

Y una duda que tengo: ¿váis a usar un procesador o microcontroladores?

Saturnino escribió:Buenas de nuevo haber el mc6850 sale 11,73 euros tardarian 2 dias en traerlo de barcelona.
y el EF6850P 2 euros y lo tienen en la tienda.
un cordial saludo compañeros

Pues no esta mal ¿no?

Hola. Perdon por no responder, pero he estado ocupado.
El nombre del proyecto todavia no se ha decidido, ¿verdad?. Haria falta decidirlo para hacer el marketing adecuado.

Yo sigo con la idea de E.O.L. retro project , si os gusta pues cojerlo.

Ánimo y darle caña.

Yo dije Green Dream, por eso de ser el verde el color de EOL durante mucho tiempo, y el del estilo viejo.

En primer lugar pediros disculpas por no haber aportado en estos días, ha estado mi mujer enferman y lo importante es lo importante, ya sabéis

socram8888 escribió:Hola, me llamo PIC y mis siglas vienen de Peripheral I/O Controller. Mucho gusto

Y una duda que tengo: ¿váis a usar un procesador o microcontroladores?

Puritanamente es Peripheral Interface Controller, aunque con esa denominación sólo nos referiríamos a los microcontroladores de Microchip

En cuanto al uso, creo que un híbrido puede dar muy buenos resultados. Hace unos años metí en una placa un Z-80 y para mover grandes bloques de memoria usé un PIC. Mediante un trigger el PIC movía bloques enteros mientras el Z80 podía dedicarse a otras tareas, con lo que por un bajo coste se conseguía un incremento de la velocidad elevado. Cuando el PIC concluía habilitaba una de sus salidas que el Z-80 leía posteriormente para continuar trabajando con los bloques ya movidos.

En este diseño si analizamos las rutinas repetitivas que surjan se puede contemplar implementarlas con PIC's, liberando a los procesadores para otras tareas.

Saturnino escribió:Buenas de nuevo haber el mc6850 sale 11,73 euros tardarian 2 dias en traerlo de barcelona.
y el EF6850P 2 euros y lo tienen en la tienda.
un cordial saludo compañeros

Lo expuesto anteriormente, podemos diseñarnos un interface a nuestra medida con un PIC y ahorrarnos el gasto de chips específicos.

teesala escribió:Podemos mirar otros chips parecidos para I/O de los mandos.

Por otro lado podríamos hacer un diagrama de bloques V2 de las conexiones entre elementos para ir concretando lo que nos falta.

A ver si esta noche puedo y lo hago

Bueno,esto sigue adelante.Y espero que tu mujer esté recuperada.

A ver que os parecen estas pequeñas imágenes para saber acerca de que grupo trata cada post









Podemos colocarlo siempre al comienzo de cada post, y en un vistazo tendremos la información filtrada

Muy muy chulo si señor, y que tu mujer se recupere pronto.
Saludos

danibarna escribió:Muy muy chulo si señor, y que tu mujer se recupere pronto.
Saludos

Lo primero es lo primero, espero que no haya sido nada y se recupere pronto

Señores del departamento de hardware, ¿habria posibilidad de poner conector usb y asi usar un mando usb? Lo digo por que se podria crear un conector universal de esta manera y ya veriamos como trasladar los controles en el software.

thanatos_xbox escribió:Señores del departamento de hardware, ¿habria posibilidad de poner conector usb y asi usar un mando usb? Lo digo por que se podria crear un conector universal de esta manera y ya veriamos como trasladar los controles en el software.

El problema es lo que precisamente comentas, hay muchos pad en el mercado por USB y suelen usad PID's diferentes, por lo que habría que montar un hosts que, al menos, reconociese los más usados. Nos alejaríamos de la simplicidad del proyecto.

Pienso que los pad es lo más sencillo de diseñar y que a la vez pueden dar una gran identidad a la consola, si no mirar atrás y reconoceréis cada consola retro por su mando

FiXeD escribió:El problema es lo que precisamente comentas, hay muchos pad en el mercado por USB y suelen usad PID's diferentes, por lo que habría que montar un hosts que, al menos, reconociese los más usados. Nos alejaríamos de la simplicidad del proyecto.

Y si se pusiese para xbox360??? es el mejor pad que hay usb...a lo mejor he dcho una gilipollez...pero si se pudiese incluir esa opción, cual mejor que el de xbox360

A parte de lo que contesta fixed creo que tambien se refiere a que encareceriamos el proyecto por tener que comprar el adaptador y en el caso de no tener nadie mando de xbox tener que comprar uno.

Hola, acabo de leer las 22 páginas del hilo, y me parece espectacular. Ojalá llegue a buen puerto el proyecto.

Aunque sé que he llegado tarde a la creación de grupos, me atrae la idea del diseño, así que (si fuera posible) me gustaría formar parte del grupo de modelado.

En cuanto a la idea de los mandos, coincido con Fixed. Creo que los mandos podríamos diseñarlos nosotros mismos. Así continuaríamos plenamente con la premisa de no tomar nada prestado (salvo los componentes, obviamente).

Usen el de Snes .

Cosas pendientes:

-Definir hardware o su primera base.
-Definir que método se va a usar para el mando.

-Definir nombre del proyecto.

Aquí teneis un diagrama-bloques-cutre-paint para trabajar con lo que queda.



Tengo la duda si con el 68000 hara falta chip select o ya lo tiene integrado

Tengo que imprimirme el datasheet hoy en el tajo xD

Saludos,

masini2002 escribió:Cosas pendientes:

-Definir hardware o su primera base.
-Definir que método se va a usar para el mando.

-Definir nombre del proyecto.

Esta es la parte que a mi me concierne. Pues a ver si ya hacemos una lista con los nombres que se propusieron y lo decidimos entre todos. Ahora despues cuando tenga tiempo recopilare todos los nombres que hay hasta ahora y asi decidimos el nombre para el proyecto.

teesala escribió:Aquí teneis un diagrama-bloques-cutre-paint para trabajar con lo que queda.



Tengo la duda si con el 68000 hara falta chip select o ya lo tiene integrado

Tengo que imprimirme el datasheet hoy en el tajo xD

Saludos,

Hola buenas, llevo siguiendo varios dias el hilo y quiero mostraros todo mi apoyo a los que estais llevando a cabo este proyecto.

Quería hacer una pequeña anotación ya que hace poco estube trasteando con los AD725 y es que no sirven para obtener una señal RGB/VGA. Son conversores de esta señal a compuesto/svideo. Además, las señales RGB que ha de procesar han de ser analógicas, por lo que la cosa yo creo que quedaria así:

MC68000---->DAC---->Salida RGB y VGA---->AD725--->Video compuesto o svideo

Desde mi punto de vista, dejaría este chip como opcional ya que no es estrictamente necesario.

En cuanto a los integrados que controlen los I/O, estoy de acuerdo con FixeD en que habría que intentar hacerlos con MCUs comunes o resultaria muy dificil que alguien ajeno a todo esto pueda montarse una consola. Está claro que es mucho más laborioso que ir buscando ICs específicos, pero a la larga haría que la difusión de este proyecto fuera mucho mayor.

En fin, si necesitáis algún tipo de ayuda, podéis contar conmigo
Saludos

doblete escribió:Usen el de Snes .

Apoyo la idea, es el mando ideal de los 16 bits, fácil de conseguir, barato, la cantidad de botón necesaria y cómodo para jugar

Ya claro, encontrar conectores hembra de la snes, lo más facil de conseguir del mundo

Lo mejor, db9 o db15, coste de centimos.

Desde el desconocimiento os pregunto...sería demasiado locura meter mando por usb? Lo digo porque así en el mercado habrían muchas posibilidades

mcmardigan__ escribió:

teesala escribió:Quería hacer una pequeña anotación ya que hace poco estube trasteando con los AD725 y es que no sirven para obtener una señal RGB/VGA. Son conversores de esta señal a compuesto/svideo. Además, las señales RGB que ha de procesar han de ser analógicas, por lo que la cosa yo creo que quedaria así:

MC68000---->DAC---->Salida RGB y VGA---->AD725--->Video compuesto o svideo

Perdona, el esquema esta mal. Sería MC68K -> conversor a RGB -> AD725 -> compuesto (cable amarillo)

Saryon escribió:Desde el desconocimiento os pregunto...sería demasiado locura meter mando por usb? Lo digo porque así en el mercado habrían muchas posibilidades

El proyecto incluye el diseño de los mandos también

alan wake GKL escribió:Esta es la parte que a mi me concierne. Pues a ver si ya hacemos una lista con los nombres que se propusieron y lo decidimos entre todos. Ahora despues cuando tenga tiempo recopilare todos los nombres que hay hasta ahora y asi decidimos el nombre para el proyecto.

Perfecto!

Respecto a los mandos , yo creo que un conector tipo megadrive, master system, atari y todos los micrordenadores seria lo mas apropiado...

Bueno, he tenido un ratillo y he preparado el siguiente esquema. OJO, es sólo la parte de vídeo, el MC68000 no es el de la unidad central, es exclusivo para vídeo. He colocado los IC's que hasta ahora hemos visto y pueden darnos buenos resultados. Creo que es un buen esquema sobre el que movernos y con el que concretar una de las partes más importantes y compleja:



Uploaded with ImageShack.us

El PIC como os comenté puede encargarse de barrer la RAM que contenga el FRAME completo hacia el DAC, y de esta al conversor de vídeo para dar las salidas que necesitemos

Y ahora unos cálculos teóricos sobre velocidad de transferencia que deben tener las memorias de vídeo:

si usamos una resolución de 420x294 en cada barrido de pantalla deberemos leer 123.480 posiciones de memoria (esto es independiente de la definición que queramos dar, ya sean 8,10 o 12 bits de profundidad de color). La velocidad de propagación de los módulos SRAM usados es de 55 ns (nanosegundos), es decir, para acceder a una posición de memoria y que los datos que se presenten en el BUS de datos sean validos se tarda 0,000000055 segundos (muchos ceros ). Pues bien, con ese tiempo de propagación tenemos que en un segundo podremos acceder a 18.181.818
A primera vista se puede pensar "oh, si tenemos que acceder a 123.480 posiciones y la RAM puede ofrecer 18.181.818 posiciones en un segundo, vamos sobrados"...pues no. Tenemos que recordar que esas 123.480 posiciones son para un FRAME, pero que un segundo de vídeo contiene 50 (PAL) ó 60 (NTSC) FRAME's. Por lo tanto, para un segundo de vídeo en formato NTSC es necesario que la memoria transfiera desde 123.480x60= 7.408.800 posiciones. Y en PAL 123.480x50=6.174.000 posiciones.
Finalmente hemos comprobado que no estresamos el sistema ya que usamos menos de un 50% de la máxima transferencia teórica, con lo cual la estabilidad está asegurada. No obstante luego habrá que sumar tiempos por las transiciones de la memoria shadow y el TIMING que debe aportar el PIC.

Bueno, con esto y un bizcocho...a cenar

Umm, interesante, eso me recuerda a los parpadeos de las maquinas antiguas que debian sincronizarse con el refresco de pantalla para disimularlo lo máximo posible cuando hacían animaciones...

Esta información tan técnica aun no ha llegado al punto de saber cuantos sprites por segundo puede mover ni cosas así ¿no? D

Buenas noches compañeros,entoces Fixed descartamos el Z80B para el audio,para la unidad central que MC68000 vamos a utilizar el de 16 MHZ o as pensado en otro.
un cordial saludo saludo compañeros.
pd: espero que tu mujer se recupere pronto

jean la montard escribió:Umm, interesante, eso me recuerda a los parpadeos de las maquinas antiguas que debian sincronizarse con el refresco de pantalla para disimularlo lo máximo posible cuando hacían animaciones...

Esta información tan técnica aun no ha llegado al punto de saber cuantos sprites por segundo puede mover ni cosas así ¿no? D

Hoy os habéis propuesto que le dé a las matemáticas

Vamos a poner un escenario usando un MC68000 a 20 MHz (http://cache.freescale.com/files/32bit/ ... df?pspll=1) y con un refresco de pantalla de 60 ciclos:

al usar una memoria shadow, o doble buffer, para el vídeo, en el momento que tengamos compuesto un FRAME podemos parametrizar cuanto tiempo usaremos en crear el siguiente. Una buena medida sería que utilizáramos una proporción 3:1, es decir, el buffer de vídeo se mostrará en pantalla 3 veces seguidas y se cambiará por el otro. Esto nos daría 20 cuadros distintos por segundo, más que suficiente para generar sensación de velocidad.

Por otro lado, para el buffer en el que estemos creando el FRAME dispondremos de 3 ciclos de pantalla, y como cada uno son aproximadamente 15 milisengundos ( 0,015 segundos) tendremos 45 milisegundos para crear el FRAME. Supongamos que el primer ciclo (15 milisegundos) lo dedicamos al fondo (tiles) y dejamos dos para sprites, 30 milisegundos.

Por otro lado, un MC68000 a 20 MHz tiene 20.000 ciclos cada milisegundo, disponiendo en total de 600.000 ciclos para sprites. Damos un valor teórico de 4 ciclos por instrucción y ejecución del MC68000 (que es una media elevada, ya que el MC68000 tiene poderosas instrucciones para mover bloques de memoria). Entonces obtenemos que podremos mover 600.000/4=125.000 pixels. El sprite mínimo es una retícula de 8x8=64 pixels, con lo que 125.000/64=1.953 sprites cada ciclo de FRAME. Lógicamente esto es para el sprite más pequeño, y nos convienen grandecitos, por ejemplo, de 16x16, que serían 256 pixels, quedando la división 125.000/256=488 sprites de 16x16.

Con esto nos hacemos una idea aproximada, aunque luego podamos sacar más rendimiento o en algunos FRAMES, dependiendo de su dificultad de composición, perdamos alguno. Aún así podemos observar las virtudes al usar este procesador para tal propósito.

Saturnino escribió:Buenas noches compañeros,entoces Fixed descartamos el Z80B para el audio,para la unidad central que MC68000 vamos a utilizar el de 16 MHZ o as pensado en otro.
un cordial saludo saludo compañeros.
pd: espero que tu mujer se recupere pronto

En primer lugar, gracias Saturnino, ya está repuesta. Te agradezco el interes.

Por lo que al chip de sonido respecta, no lo tengo del todo claro, estoy buscando algún Yamaha con varios canales en formato DIP que se siga haciendo, aunque está difícil la tarea.

Por lo que estoy viendo teoricamente podremos hacer buenos juegos incluso mejores que que lo que se vio en megadrive,estoy en lo cierto o no compañero Fixed

Saturnino escribió:Por lo que estoy viendo teoricamente podremos hacer buenos juegos incluso mejores que que lo que se vio en megadrive,estoy en lo cierto o no compañero Fixed

Lo dije al principio, a los costes que hoy en día tiene el hardware usado en el proyecto, y su velocidad, podemos sobrepasar los cuellos de botella de aquella época y montar algo potente en comparación. De todas formas la base es esa, debemos desarrollarla

Creo que todos hemos aprendido algo hoy xD

Por otro lado, como iran conectados los 2 68000? Compartiran bus de datos? Compartiran la memória de tabla de posiciones?

Saludos, vamos avanzando

cada dia estoy mas ilusionado con este proyecto,fixed con el tema de la pcb como la desarrollaremos, crees que va a ser grande la videoconsola

teesala escribió:Creo que todos hemos aprendido algo hoy xD

Por otro lado, como iran conectados los 2 68000? Compartiran bus de datos? Compartiran la memória de tabla de posiciones?

Saludos, vamos avanzando

No sé por qué me da, amigo, que a ti poco tengo que enseñarte

En cuanto al bus de datos, el MC68000 como bien dices debe poder acceder a la tabla de posiciones (CY7C185) para "maquetar" los FRAME's y a la memoria de TILES y SPRITES (AS6C4008) para poder mover desde la SD los bloques. Habrá que poner algún gestor en el BUS (algo que podría hacer nuevamente un PIC).

Saturnino escribió:cada dia estoy mas ilusionado con este proyecto,fixed con el tema de la pcb como la desarrollaremos, crees que va a ser grande la videoconsola

Mmm, la PCB quizás podamos desarrollarla en Proteus, estoy en conversaciones con un amigo que lo maneja en el trabajo y quizás pueda generarla. En cuanto a tamaño, diría que aproximadamente como la de una MD, tampoco queremos que se nos achicharre en los primeros vicios

no por eso lo preguntaba, digo a va ser a tamaño megadrive vs neo geo, pero lo que importa es que va a ser excelente y nos vamos a divertir muchisimo con el desarrollo como cuando la juguemos.
un cordial saludo

Por ahora el coste del hardware cuanto seria de media.

Pd espero que tu mujer este mejor fixed que no te lo he dicho.

thanatos_xbox escribió:Por ahora el coste del hardware cuanto seria de media.

Pd espero que tu mujer este mejor fixed que no te lo he dicho.

Pues mi idea es movernos entre 60-80 €, aunque seguro que podemos rebajar costes buscando bien los componentes.

Y muchas gracias thanatos_xbox, ya se encuentra recuperada

Ya estoy de vuelta. Gracias a una p*** Dreamcast que no quiere leer me he perdido toda la tarde y parte de la noche el hilo.
Me he leido todas las paginas para recopilar todos los nombres que he encontrado para el proyecto (si me dejo alguno decidmelo, que se me puede haber pasado por alto). Aqui estan:

- Retroplay
- Iretro
- D.E.O.L (Diseñada en el otro lado)
- BIT-E-ALL bit-eol
- Proyecto Galilieo
- Project OSOV "the Other Side of Videogames"
- E.O.L. Project (EOLP)
- E.O.L.R project (El otro lado retro project)
- Proyecto creacion
- Eolclasica
- 16biteoliana
- Proyecto Bit
- Píxeol.
- Project of illusions eol.
- Proyecto Green Dream


A VOTAR!!!!!


Que alguien me ayude como poner marketing arriba

Sin duda el que mas me gusta.

Me gusta este



Me suena a proyecto Cloverfield

FiXeD escribió:

teesala escribió:Creo que todos hemos aprendido algo hoy xD

Por otro lado, como iran conectados los 2 68000? Compartiran bus de datos? Compartiran la memória de tabla de posiciones?

Saludos, vamos avanzando

No sé por qué me da, amigo, que a ti poco tengo que enseñarte

En cuanto al bus de datos, el MC68000 como bien dices debe poder acceder a la tabla de posiciones (CY7C185) para "maquetar" los FRAME's y a la memoria de TILES y SPRITES (AS6C4008) para poder mover desde la SD los bloques. Habrá que poner algún gestor en el BUS (algo que podría hacer nuevamente un PIC).

Saturnino escribió:cada dia estoy mas ilusionado con este proyecto,fixed con el tema de la pcb como la desarrollaremos, crees que va a ser grande la videoconsola

Mmm, la PCB quizás podamos desarrollarla en Proteus, estoy en conversaciones con un amigo que lo maneja en el trabajo y quizás pueda generarla. En cuanto a tamaño, diría que aproximadamente como la de una MD, tampoco queremos que se nos achicharre en los primeros vicios

A mi me gusta el Eagle para el diseño PCB, ademas es gratuito (aunque la version freeware no hace placas grandes y en el camino que vais...) y da muy buenos acabados. Yo he usado muchos para hacer placas en insoladora: OrCAD, Protel, Proteus... pero EAGLE en relacion sencillez/acabados es lo mejor.

Para el nombre quiza deberias hacer una votacion en el hilo (supongo que algun mod podria abrirla, porque no recuerdo si el creador del hilo la puede incluir, una vez ya abierto el hilo) y dejarla abierta el tiempo que estimeis oportuno

gracias fixed por elegir el que yo propuse

FiXeD escribió:

thanatos_xbox escribió:Por ahora el coste del hardware cuanto seria de media.

Pd espero que tu mujer este mejor fixed que no te lo he dicho.

Pues mi idea es movernos entre 60-80 €, aunque seguro que podemos rebajar costes buscando bien los componentes.

Y muchas gracias thanatos_xbox, ya se encuentra recuperada

Pues opino que por el camino que vais no baja de 100€ ni locos... y quedan componentes que ni se han mencionado y que van encarecer considerablemente el coste como el almacenamiento (SD + zocalo + inteface), mando artesanal (buff aqui la cosa se puede disparar..), alimentacion, pcb, conectores,..
Por cierto, me intersa saber como vais acceder desde el MC a la SD/MMC.

Un hilo para el nombre no estaria mal y seria mas facil para votar.

Sigo el hilo y según se me vengan ideas las propongo, pero no tengo "ni zorra idea" de hardware y el 95% de este proyecto le pertenece.

Como siempre apoyo por mi parte a todos estos ingenieros y técnicos.

bertobp escribió:Por cierto, me intersa saber como vais acceder desde el MC a la SD/MMC.

Yo usaría un PIC16F88. Hace tiempo vi con este PIC una conversión de SD a D8 así que sería algo parecido.

FiXeD escribió:En cuanto al bus de datos, el MC68000 como bien dices debe poder acceder a la tabla de posiciones (CY7C185) para "maquetar" los FRAME's y a la memoria de TILES y SPRITES (AS6C4008) para poder mover desde la SD los bloques. Habrá que poner algún gestor en el BUS (algo que podría hacer nuevamente un PIC).

Perfecto

Por otro lado voto por:


Cuando tengamos el nombre ya podríamos crear una firmita para dar a conocer el proyecto por el foro

Saludos!

Si puedo votar, votaría por:

E.O.L.R project (El otro lado retro project)

teesala escribió:

bertobp escribió:Por cierto, me intersa saber como vais acceder desde el MC a la SD/MMC.

Yo usaría un PIC16F88. Hace tiempo vi con este PIC una conversión de SD a D8 así que sería algo parecido.

Me lo suponía...

Si os parece podemos decidir el formato del schematic / programa de CAD para no tener problemas de compatiblidad.

También el modelo en concreto de la familia 68000 que usaremos.

Si mañana tengo tiempo miraré mas a fondo el tema SD

Saludos!

teesala escribió:

Si os parece podemos decidir el formato del schematic / programa de CAD para no tener problemas de compatiblidad.

También el modelo en concreto de la familia 68000 que usaremos.

Si mañana tengo tiempo miraré mas a fondo el tema SD

Saludos!

Estupendo, este finde hay que darle un empujoncito

Yo voto por EAGLE Layout Editor