Creacion de nueva consola (#2)

Darkangelus escribió:[boma]

JAJAJAJAJAJAJAJAJA!!!

Que asta la seman pasada habia examenes... bueno, no lo he habandonado tanto como pueda parecer... el diseño de la cpu alternativa esta decidido al 99% (solo queda decidir si 32 o 64bits), mientras tanto se puede usar el ARM que as propuesto.

Elohe, no tienes por qué escusarte, se a hecho lo que se a podido... .

Estas semanas de reflexion me han servido para ver que nos estamos dejando llevar por las consolas NEXT-GEN. Esto me ha echo replanteame la base fundamental de propio proyecto ¿ Que era prodigy en sus principios ?... facil respuesta; una consola desarrollada por jugadores, para jugadores, que nos enseñara un poco más de este hobby que tantas horas de diversión nos a dado. ¿ Realmente es importante que tenga tantas capacidades ?, yo sinceramente creo que no. Me hace más feliz mi vieja Megadrive que mi "nueva" PS2... , esto es un echo... y que a muchos de nostros nos pasa.

Los más viejos se acordaran que en la epoca de los SPECTRUM-AMSTRAD se aprobechaba al maximo los procesadores, hasta yo me flipo del trabajo de algunos, que podrian ser catalogados como obras de arte en la programación. ( La Abadía del Crimen )

El misterio no es cojer un POWERPC de 500MHZ y que ponga millones de poligonos... "tiene que llenarnos", cada vez que pongamos el juego tener una historia interesante y un metodo de juego simple y eficaz... y eso es Prodigy un vehiculo de nuestros deseos.

Con ella teniamos que aprender electronica, programación, tunearla, disfrutar de lo que hemos creado de la nada. Eso es más grande que cualquier otro pensamiento...

Se empezo con un Z80, luego con un MC6800 y finalmente un ARM9...

Creo que seria más interesante crear algo más humilde.... me doy cuenta que cada vez que le metemos más potencia se hace más caro y costoso ( en tiempo y economicamente hablando).

Por eso creo que nos deberiamos replantear muchas cosas del proyecto, mejor corregir ahora que estamos en un buen momento que luego lamentaremos.

Mi opinion es la siguiente ¿ Por que no hacemos una mezcla entre Megadrive y Super-nintendo ?, las mejores partes de una y de otra...


Mirad, quiero que aporteis vuestra opinión en el hilo y no os corteis ni un pelo.

NO DEIS TANTAS OPINIONES QUE EL SERVIDOR DE EOL NO LO VA A SOPORTAR

llevo leyendoos algun tiempo y creo que tu ultimo post lleva toda la razon (el del servidor y las opiniones no, el anterior). la gente se deja llevar por mas y mas potencia cuando eso no implica mas diversion.
yo no tengo ni idea de esto, pero si lo terminais haciendo y decis como se monta en un tutorial o algo asi probablemente termine haciendome una. lo mejor de snes y megadrive? ok, haced una snes (es broma segueros xDD)

yo no creo que deba volver a dar mi opinion...

ARM9 con FPGA de apoyo o sola.

unkblog escribió:lo mejor de snes y megadrive? ok, haced una snes (es broma segueros xDD)

Megadrive su procesador, supernes su chip grafico...

f5inet cada vez lo veo más dificil el utilizar el ARM9 la FPGA se uilizaría como chip grafico...

No entiendo muchos de estos temas, pero sería muy interesante (en mi opinion) el desarrollo de una consola orientada a juegos de plataformas con buenos efectos (tipo Metal Slug). Me refiero a ese nivel, porque no se necesita una PS2, porque para eso ya esta la PS2... jejeje

Ah! ¿todavia está este proyecto vivo?

Amenudo veo ese problema en programadores: tienen una idea y van inflando mas y mas el globo hasta que explota y.... no queda nada

En estas cosas, hay que tener los pies en el suelo, ir por lo que está mas a mano y luego, se puede pensar en añadir mejoras o tal vez, otro proyecto mayor.

Ahora mismo tenemos varias consolas que permiten scene. GP2X es una de ellas: tiene doble procesador ARM, bastante potencia , es portatil y se puede conectar al TV.

Vosotros estais intentando hacer una maquina que realmente, no se necesita. Se perfectamente porque la quereis hacer y estoy de acuerdo con esa filosofia, pero:

¿no deberiais centraros en hacer una maquina de bajo coste, sencilla de realizar, poca potencia quizá, pero con una programación no demasiado dificil? Algo que se pueda realizar en pocos meses y que no se convierta en un proyecto faraónico

Lo importante es llegar a decir: mira, con un puñado de componentes he creado esta maquinita tan chula. Es el hecho de haber creado algo lo que os llenará.

Una vez hecho un primer proyecto sencillo, visto la gente que participa y dispuesta a programar para dicha maquina, se puede intentar dar un paso mayor.

Has dado en el clavo Hermes, el proyecto se ha echo extremadamente ambicioso. Y lo peor es que nunca vera la luz..., y la culpa es solamente mia, por dar tanta rienda suelta a desarrollar algo que posiblemente sea EXTREMADAMENTE COMPLICADO DE REALIZAR. La gente se cree que estoy pidiendo el MC68000 por marear la perdiz, pero lo hago por el bien del proyecto !!!, cuando vieran el encapsulado de el ARM9, la mitad de la gente no la montaba.

Un chip con encapsulado PLCC es muy facil de montar y de desarrollar una tarjeta sencilla y limpia , en vez del ARM9 con una tarjeta conbulsionada de pistas...

Además se gastaria el MC68000 más alto de gama ( 20MHZ ) que es por cierto un chip que por mucho que pasen los años sigue ahí.

Solo habria que diseñar por FPGA un sintetizador FM y un chip grafico de 2D. Esto da muchas posibilidades a los + programadores y aventureros desarrolladores.

Lo de lector CD lo dejaria para más adelante igual que el de compact flash. Seria utilizar una EPROM a palo seco con un zocalo.

Esta consola seria para gente QUE VALE Y ES BUENA EN SU CAMPO Y AVENTUREROS QUE NO SE AMEDRENTAN ANTE NADA.


Podriamos realizar el sueño de nuestra niñez... , o dejar que sea eso, " tan solo un sueño ".

Mira, te voy a poner un ejemplo de como funciono yo a nivel de programacion:

Hace poco conseguí una novela que leí hace mucho tiempo y que me gustaría poseer, pero que no se edita desde hace eones.

La novela estaba en formato html, asi que la pasé a TXT planop y me dispuse a leerla con el programa "eBook" de la GP2X.

Dicho programa es una mierda pinchá en un palo, asi que se me ocurrió que podría hacer un visor de texto sencillo y que cubriese todo lo necesario para ese menester.


Cuando comenté el tema en los foros de GP32Spain y subí la primera versión, no falto gente que decía que podría incluir soporte para .rtf, .doc. .htm .pdf etc.

Pero yo ya había analizado el tema y llegado a la conclusion de que teniendo en cuenta el tamaño de pantalla, resolucion (320x240) y la comodidad, lo mejor era hacer las cosas como las había pensado (txt plano y punto pelota), añadiendole dos o tres cosillas útiles (posibilidad de marcar capitulos y buscarlos o cambiar el color de los encabezados con unos sencillos comandos), el programa resultaría practico y podríamos disfrutarlo rapidamente.

El resultado es que tardé menos de 48 Horas en terminarlo y el programa cumple perfectamente su cometido: yo por lo menos, leo muy comodamente los relatos y no me fatigo. Objetivo cumplido

Pues eso mismo debe pasar con la consola que quereis crear: debeis centraros en un diseño sencillo, ampliable, etc, que os guste a vosotros y dejar las ideas de los demás para mas tarde o solo acometerlas si no se desvian mucho del proyecto inicial y son buenas ideas, faciles de implementar.

Si no; tarde o temprano lo dejareis por falta de tiempo o desanimo: lo que cuentan son los resultados, eso es lo que os dará fuerza para continuar y mejorarlo

Amigos mios:

No se como van los animos y no quiero darlos, pero tengo una pregunta:

¿el MC68000 es la cpu de Neo Geo??

Si es asi, con esta cpu, creo que tendriamos bastante, aunque tambien habria que contar con los programadores, para ver si pueden exprimir el Arm9, y lo más importante, si disponen del tiempo necesario para exprimirlo.

Yo si Prodigy me ofrece juegos de lucha 2d, y arcades beat em up (un final fight prodigy edition, juegos de lucha tipo street fighter 2 donde lo que cuenta es lo que sabes manejar el luchador y no que sepas realizar un supercombo que aunque te quede una raya de energia seas capaz de encadenarlo y acabar con el contrincante, un metal slag, que no slug por no confundirlos...) me daria mas que por satisfecho. Además podria haber mas gente ayudando a Elohe y a f5inet en el desarrollo...

Una pregunta aparte, ¿que lenguaje de programación usa el MC68000? Quiero aprender a programar y no estaria mal empezar por un codigo para este chip.

Otro caso aparte es si se podria visionar video mediante esta cpu, seria una ventaja mas, pero solo opcional o en un futuro cercano...

Saludetes y espero vuestras respuestas

Si fuera yo, lo que haría es centrarme primero en la parte grafica ¿por que? Porque es la parte más importante y costosa de implementar y la eleccion del procesador y el resto de componentes, depender de esto.


Realmente, teniendo el chip grafico, la consola se montará casi sola, sobre todo si la diseñais como os describo:

En teoría la consola está destinada a juegos 2D, de forma que los aficionados puedan desarrollarlos con cierta facilidad.

teniendo en cuenta el tema de la memoria de vídeo y estos detalles, yo creo que utilizar una resolucion de 320x200 (aquivalente al Modo X en los PC) es la mejor opcion, utilizando paleta.

320x200 a 8 bits, consume exactamente 64000 bytes y la paleta puede almacenarse tambien en esta memoria, en tan solo 768 bytes (3 valores para cada componente RGB) o 1024 bytes si preferimos alinear a 4 bytes.


Es decir, en tan solo 64KB podemos tener nuestra area de visualizacion de 320x200


Ahora lo que deberiamos plantearnos, es si nos interesa utilizar tecnica de doble buffer (para evitar parpadeos), si queremos utilizar una memoria de video independiente o si queremos acelerar los sprites con el hard de video.


De esto ultimo, dependerá (y mucho) la potencia del procesador necesaria para mover un juego.

Por ejemplo, yo tuve un Atari 520ST con un procesador 68000 a 8Mhz, y movia los juegos a esa resolucion sin necesitar de ninguna aceleracion con resultados muy satisfactorios. Si ahora se plantea utilizar un 68000 a 20Mhz, para una configuracion así, va sobrado.

Si utilizaramos aceleracion de sprites, de tal forma que el procesador cargase los sprites en la VRAM al inicio, y el hardware de video se ocupase de leer cierta area de video y componer un sprite en pantalla, utilizando el color 0 como 'transparencia ' , seguramente con un simple Z80 ya estamos servidos.

Sin embargo, hay que tener en cuenta otra cosa tambien: se necesita un circuito controlador de memoria en la consola, sobre todo si la idea es utilizar memorias que son mas rapidas que los procesadores que vamos a utilizar.

Utilizar un controlador de memoria y memoria rapida, nos permite, por un lado, adaptar la velocidad de acceso de dicha memoria a la del procesador, pero tambien dos cosas mas:

1) Si utilizamos el metodo de memoria compartida entre procesador de video y procesador principal, se pueden utilizar los ciclos de reloj en los que el procesador principal (mas lento) no accede a la RAM para que lo haga el procesador de video. La idea entonces, sería que el controlador de ram leyese el valor de RAM que pide el procesador y lo conservase en un latch que es lo que leería realmente la CPU a fin de dejar libre el acceso a la GPU. Con esto conseguimos que el procesador no se ralentice cuando la GPU accede a la RAM y se puede utilizar un bloque de memoria unificada.

2) El controlador de memoria puede ocuparse de mover bloques de memoria de forma mucho mas rapida (DMA) ya que puede ir al maximo de la velocidad de memoria.


Pongamos el ejemplo de una memoria que puede trabajar a 200MHZ y nuestra CPU de 20MHZ. Obviamente, si la CPU accede mediante el controlador de memoria, el dato seria leido a 200Mhz y suministrado a la CPU a los 20MHZ de bus mediante el latch (eso significa que el controlador de memoria, una vez leido o escrito el dato en RAM, debería liberar las lineas de la RAM, claro)

El controlador podria utilizar un contador, de forma que en el primer paso se ocupara de los accesos de la GPU y en el segundo, de la CPU. Eso nos daria una velocidad maxima de acceso de 100MHZ en el caso propuesto. Luego la GPU podria leer esa memoria a 100MHZ como poco y la CPU otros 100MHZ, siendo su acceso real a 20MHZ, lo cual nos deja margen, con un poco de maña para implementar canales DMA utilizando un sistema de memoria unificada y compartida, sin que se provoquen ralentizaciones de ningún tipo.

Un canal DMA con una velocidad menor de acceso, podria ocuparse del sonido: un simple loop en memoria y un volcado directo hacia un DAC para producirlo (no es esencial que utilice las frecuencias de audio habituales, podria ser una simple division de la frecuencia de reloj del sistema)


Todo esto se podria implementar desde una fpga de las que hablais:


logica de dma:

int flag; // registro de flags
byte * addr_s; // registro direccion fuente
byte * addr_d; // registro direccion destino
int size_x; // registro bytes a mover
int skip; // registro bytes a saltar
int size_y; // numero de repeticiones (usado en sprites)

int temp_x; // registro temporal


if(flag & 1) // DMA activa
{
while(size_y!=0) // si size_y distinto de cero buclea
{
temp_x=size_x;

while(temp_x!=0)
{
if(flag & 2) // sprite, usa el valor 0 como transparencia
{ if(addr_src[0]!=0) addr_dst[0]=addr_src[0];
}
else addr_dst[0]=addr_src[0];

addr_dst+=1;
addr_src+=1;
temp_x--;
}
addr_dst+=skip;
size_y--;
}
flag=0; // se terminó
}

Llevando a cabo una rutina asi, se puede hacer un desplazamiento desde memoria a memoria de video y representar un sprite en pantalla de forma correcta, ya que dispone de todo lo necesario para dibujar un cuadrado en pantalla byte a byte, usando el valor 0 como valor de transparencia. Esto hecho por logica programable facilita mucho las cosas y no es tan necesario una CPU potente.

Yo he estoy trabajando en un clon del 68000, las caracteristicas son interesantes, 2 hilos por hard aubnque pude que primero haga una versiond e 1 hilo, 8k x2 de cache L1 de datos y 8K x2 de cache L1 para intrucciones, 2 ALU (+,-,&,|,>,<,=) y 2 ALU(Mult/DIV), he simulado el algoritmo para gestion de dos hilos, y a pesar de ser simple es muy eficaz, la aproximacion multihilo es ligeramente diferente a la normal en vez de hacer que una misma cpu ejecute dos hilos he fusionado 2 CPUs simples para que compartan las unidades de ejecucion y puedan usar las burbujas de la otra para colar sus instruciones sin que esto afecte a la ejecuciopn de la otra ( de un IPC<0.7 pasa a un IPC<0.9 para ambas CPUs).

Sobre el chip Grafico 2D, lo que he hecho asta ahora permitiria asta 854*480@100 con doble buffer. Bueno, es un poco raro ya que no trabaja a 32 bits de color, usa:

7 bits rojo
7 bits azul
7 bits verde
7 bits Alpha
4 bits Z-Buffer

Tu solo tienes que decirle donde copia un sprite de memoria a pantalla y el automaticamente aplica las trasparaencia y el Z-Buffer durante la copia, las colisiones deben de seguir haciendose en CPU.

Todo teniendo en cuenta que usa una arquitectura de memoria convencional. La RAM es 32x200MHZ DDR (32x400MHZ).

Elohe, esa GPU usa una FPGA, no?

a ver si descartamos el ARM9 por dificultad de soldado y tenemos una FPGA que da miedo acercarle el soldador...

no hay GPUs mas sencillas que se puedan sacar de placas antiguas?

Elohe escribió:Sobre el chip Grafico 2D, lo que he hecho asta ahora permitiria asta 854*480@100 con doble buffer. Bueno, es un poco raro ya que no trabaja a 32 bits de color, usa:

7 bits rojo
7 bits azul
7 bits verde
7 bits Alpha
4 bits Z-Buffer

Pedazo bicho estas currando, pero...

Pero lo del Z buffer, no lo entiendo: para 2D sale mucho mejor ir pintando los sprites de forma ordenada, la Z sobra y dificulta el uso de los colores ( 8 bits sería lo natural y te evitas mascaras y desplazamientos al tratarlo)

Por otro lado, es mejor poder utilizar paletas de colores para crear efectos sobre los objetos y encima ocupan menos espacio los sprites.

La resolucion es otro tema a tener en cuenta: Es mejor una resolucion menor,pienso yo.

Elohe, el problema que tiene esto desde el principio... ¿cuanta gente podrá montarlo?

En ese Z-Buffer lo he llamado asi por llamarlo de alguna manera, esos 4 bits tienen funciones especiales y solo 1 es Z-Buffer, siendo el valor 0 el valor de sprite y 1 el de consola para debuging y errores. De todas maneras ese es su funcionamiento interno no el externo, lo del color paletizado se soporta por hard sin penalizacion(asta paletas de 1024 colores) usa aceso indirecto en vez de directo al color del sprite.

Cualquiera que sea capaz de montar un chip de PS2 o XBOX360 de los que necesitan soldadura sera capaz de montarla sin problemas.

Quiza fuera mas util destinar 4 bits de alpha a esas funciones especiales: 4 bits del alpha da para 16 niveles de translucidez, mas que suficiente en juegos 2D

De esa forma, puedes disponer 8 bits por color

Gracias chicos por reactivar el hilo, sobre todo a Hermes

La verdad es que con un MC68K tendriamos un buen cacharrejo además de poder disponer de más gente experimentada con este micro. Hermes tienes razon en que tendriamos que haber desarrollado primero el chip grafico, ya que es la parte más complicada de conseguir, porque principalmente no la venden... hay que hacerla desde cero. Utilizar un divisor de frecuencia para generar sonido es muy buena idea Hermes !!!, por lo menos para empezar .

Elohe ¿ ya has recivido la FPGA que comentastes?, parece que ya estas liado desarrollando el procesador multi hilo y además la GPU !!, al final parece que has optado por utilizar un core del 68k modificado... ¿ Se podría utilizar un 68k normal y corriente para substituir este ??. Has realizado alguna prueba con la FPGA ( si la tienes, claro... ) ?

Curriculum MC68k:

Apple Macintosh 128, Macintosh 512, Macintosh 512e, Macintosh Plus
Consola Atari Jaguar
Philips CDI
Sega Genesis - MegaDrive / MegaDrive II/Multi Mega - CDX

Demostrando que posiblemente a resoluciones bajas pueda mover MPG1 minimo...

No tengo todavia la FPGA, de momento he podido experimentar de estrangis en la uni con una de alli. LA sustitucion del core que ago por un 68k es algo tediosa por que aun siendo compatibles a nivel de codigo objeto no lo son al 100% a nivel electrico, mi core arroja unos cuantos OPS/HZ mas que un 68k, mi intencion es hacer que GPU+CPU quepa en una sola 3XS400, un poco tedioso pero ideal.

El Motorola 68k tambien esta en la NeoGeo, los Amiga...

bueno... aqui estoy yo... esperando que haya algo en silicio para ponerme con el software...

Wenas, estoy siguiendo vuestro hilo y me llama bastante la atención lo de esta consola, pero porque no os poneis de acuerdo de una vez por todas en el hardware?
Habeis pensado en hacer alguna "reunión" o algo, como por ejemplo, en el Irc y decidir de una vez por todas el hardware?
Es que esto es algo bastante complejo y yo pienso que si cada uno da una configuración distinta, se va a convertir en algo imposible, porque si ya va a ser dificil con una sola configuración en la que todo el mundo este de acuerdo, si ni siquiera existe dicha configuración esto será imposible.
Yo pienso que lo suyo sería plantear el objetivo de la consola, lo que se quiere que tenga y que aguante, los componentes y cosas que creeis que debiera tener y luego buscar un hardware adecuado a esas necesidades, ponerse todo el mundo de acuerdo en dicho hardware y luego trabajar con el.
Yo estoy estudiando electrónica, pero acabo de empezar y no tengo mucha idea, con lo cual no os puedo ayudar mucho en ese aspecto.
Lo que no entiendo y es que si el proyecto tiene como objetivo crear dos consolas, una más básica y otra más avanzada, porque no se decide ya la básica, se investiga con ella, y la avanzada se hace con más tiempo, no?.

Buenas a todos.

Elohe ¿ que pruebas realizaste para comprobar si funcionaba lo que tenias echo ?, el chip grafico tenia que representar una carta de ajuste o algo en un monitor ?? o como ???

F5inet se agradece que no dejes el proyecto

El micro Driebes es un MC68K tuneado por Elohe xD en una FPGA y como dice el amigo Hermes es mejor desarrollar la GPU antes

Perdonad que este tanto tiermpo sin atender el hilo...

Hola de nuevo, dios cuanto tiempo sin andar x eol, bueno solo decir que a ver como va el proyecto y que siga hacia delante que me molaria poder tener una mia ^_^ a y aqui tengo un colega que hace unas bases de puta madre en beatbox en este hilo lo podeis oir:

http://www.elotrolado.net/showthread.php?s=&threadid=529983

A hay algun plano preliminar ya para irlo viendo?

Suerte y a seguir asi.

Weno he encontrao la web de un tio que tambien se ha hecho una "consola" propia, no parece gran cosa, pero a lo mejor los entendidos en elctrónica pueden cojer ideas de este sistema.

http://www.ugrad.physics.mcgill.ca/~beek/as2/

De momento se esta con el diseño VHDL de la CPU y la GPU, ultimamanete he estado revisando documentacion de GPUs para ver que cosas se pueden mejorar en la nuestra, aunque me centro en los diseños 2D tambien he cogido algunos de 3D y realmente el diseño de la GPU de la N64 me ha sorprendido y es facilmente clonable.

Hombre, conseguir algo semejante a la N64 sería todo un logro.
Y habeis pensado en algo parecido a un mando y tal? O solo teclado y ratón?.

La cuestion no es conseguir algo semejante a nintendo 64, la cuestion es lograr una maquina equilibrada y con un diseño correcto. En principiuo solo es 2D la maquina.

Buenas, gente

Elohe, como va el core de la GPU ??? , esto cada vez se parece más al proyecto Revolution con tanto secretismo

A, el mes pasado aparecio en elektor el horno para SMD-BGA

Y el mes que viene aparece lo que sera una FPGA ``multi capa´´,

Elektor escribió:el módulo tiene una potente FPGA con mucha RAM y memoria FLASH

( aunque no especifica cuanta )

Aun estan sujetas mucahs cosas de aqui a cambios.

A ver si estas pascuas publico las instruciones de la GPU, muchas funciones deberan de ser echas usando microcodigo, vamos que se dispone de algo parecido a un Pixel Shader pero orientado a sprites, la GPU dispone de intruciones especiales como un ADDP que coje directamente dos pixel y los suma, porsupuesto color 32bits RGBA y usando 1 ciclo por pixel. Soporta color paletizado que internamente lo convierte a RGBA, las paletas se almacenan en una cache exclusiva de 16k, pudiendo almacenar 8 paletas distintas de 512 colores, 16 de 256 colores o 32 de 128 colores, por cierto la GPU seguramente correra a unos 50MHZ en una Spartan3 arrojando un fillrate de 20Mpixles minimo. Posiblemente soportara dibujado inteligente, es decir solo redibuja aquellas partes del frane que cambian o mueve los trozos del frane que no cambian de contenido pero si de posicion. Las resoluciones seguramente deban de ser multiplos de 2 (trabaja en bloque de 2x2 pixels).

Elegir el formato interno de color:

Color 32 bits RGBA 8888
o
Color 16 bits RGBA 5551

Gracias Elohe

Ostias, con las instrucciones se podrian hacer YA programillas incluso desarrollar un simulador de GPU

Referente al color... ¿ Cual es más facil de implementar ???

la dificultad de implementacion es la misma, la diferencia es el maximo numeor de operaciones simulataneas que podriamos realizar, usando una configuracion interna de 64bits seria 2 operaciones de 32 bits de color o 4 de 16bits.

ESPERA UN MOMENTICO... ¿ la gpu es de 64bit ???

Bueno , si tiene 32bit de colores, sera color real. Los juegos 2D se verian muy bien

¿ Has probado algo más en la GPU ?

PD: Ya eres MegaAdicto!!!, felicidades

Bueno, la cosa va leeenta...pero vá y eso es muy importante. La verdad es que al menos empeño le estais metiendo!!! Espero ver lo que podrá hacer vuestra niña!!!

IridiumArkangel escribió:Bueno, la cosa va leeenta...pero vá y eso es muy importante.

ESO ES LO IMPORTANTE

IridiumArkangel escribió:Espero ver lo que podrá hacer vuestra niña!!!

Le tengo unas ganassss

Añado datos:

16 registros de pixeles.
8 registros para microcodigo.
2 grupos de 2 contadores anidados programables.
el conjunto de intrucciones para pixeles es de tipo SIMD.
el conjunto de intruciones de microcodigo es de tipo RISC.
caches separadas para pixeles, microcodigo, paletas y frame.
2 canales de memoria DDR de 32bits.
registro que permite añadir 32 o 64 "instruciones" virtuales acesibles desde la CPU(por decidir, dependera del tamaño final del diseño)
comunicacion con la CPU mediante memoria FIFO, modo especial de aceso directo a memoria para tramsitir microcodigo, sprites...

Elohe, como puedes ser tan jodidamente listo

Solo es un boceto de lo que quieres hacer ??... recuerda que es muy difícil implementar eso en FPGA.

No se yo, no se yo... ¿ tu crees que nos cabera en una de 300K gates ?

Seguramente cabra todo en una Spartan 3S400, eso si habra que hacer un diseño limpio para lograrlo, en todo caso se prodrian usar 2 sin problemas, esa posibiladad ya la tengo estudiada. Lo que mas costara sera el sistema de mezcla de pixels optimizada con canal alpha (implica divisiones y multiplicaciones lo que provocara un pipeline muy largo, seguramente de 16 estados).

Si bien es no es un boceto, pero sigue siendo un diseño previo, namas acabe con el juego de instrucines (falta por decidir si añado alguna o quito alguna otra, esta pascuas pongo la lista a votacion por si creeis que sobre alguna o falta alguna) empiezo la programacion.

Hombre, dos FPGAs... ¿ no son muchas ???, para eso le metemos directamente una de 1M Gates así nos sobran puertas... CPU+GPU

Bueno, ya se vera la FPGA en la que cabe, espero que solo quepa en una y podre todo mi empeño en ello.

venga señores, un poco de alegria... con un poco de suerte de aqui a navidades 2006 tendremos los esquemas

Mejor eso f5inet, que nunca tenerlos

PD: Haber si en navidades tenemos un juego....

con que operaciones contara ese clonico m68k que estas preparando elohe?

suma, resta, multiplicacion y ¿division? ¿coma flotante?

dame algunos datos mas

¿la GPU es un blitter puro o mas bien sera programable en plan de ejecutar instrucciones? ya he leido lo del ADDP que sumara directamente dos pixeles hasta saturacion (supongo), pero tambien vendria bien una suma de pixeles hasta media aritmetica (ideal para antialias) y resta de pixeles.

el m68k esta aparcado asta completar la GPU, la GPU dispone de intruciones orientadas a pixel y es programable, miralo como un SPE del CELL, pero orientado a sprites.

EDIT hay una intruccion que permite hacer "alpha blending" de dos pixels, con un rendimiento de un 1 pixel( son mas, depende del ancho de la unidad vectorial) por ciclo de reloj y una latencia de aproximadamente 16 ciclos.

EDIT2: AMPLIANDO

asume alpha entre 1(opaco) y 0(tranparente);

Funciones propuestas a implementarse por HARD, hay mas esto es solo un ejemplo, estas funciones comparten mucho hard en comun.

color = color1*(1-alpha(color2)*n)+color2*alpha(color2)*n <- el alpha resultante es MAX(alpha(color1),alpha(color2))
color_=_color1*(si_MIN(alpha(color1)*n1,alpha(color2)*n2)=alpha(color1)*n1,alpha(color1)*n1*1/(alpha(color2)*n2)_si_no_1-alpha(color2)*n2*1/(alpha(color1)*n1)+color2*(si_MIN(alpha(color1)*n1,alpha(color2)*n2)=alpha(color1)*n1,1-alpha(color1)*n1*1/(alpha(color2)*n2)_si_no_alpha(color2)*n2*1/(alpha(color1)*n1))_<-_el_alpha_resultante_es_MAX(alpha_(color1),alpha(color2))
color = color1*n1+color2*n2
color = color1*n1-color2*n2
color = blanco-color1 <- conserva el alpha chanel intacto

proponed mas funciones aritmeticas si quereis.

EDIT3. Corrijo la segunda formula, estaba erronea, admito la frormula es un tocho pero es bastante sencilla de implementar.

EDIT4. Añado formula:

color = color1*(1-alpha(color2)*1/alpha(color1)*n)+color2*alpha(color2)*n*1/alpha(color1) <- el alpha resultante es MAX(alpha(color1),alpha(color2))

EDIT5 y ultimo.se me olvido decir que n,n1 y n2 estan comprendidas entre 1 y 0 igual que el canal alpha.

Subo el hilo Elohe para que la gente lo vea , por favor entendidos en el tema .... AYUDADNOS !!!

PD: Genial

ayuda!!!!!!!!! necesito ayda para verificar las formulas por si hay erroneas, estas estan mal:
color = color1*(1-alpha(color2)*1/alpha(color1)*n)+color2*alpha(color2)*n*1/alpha(color1)
color_=_color1*(si_MIN(alpha(color1)*n1,alpha(color2)*n2)=alpha(color1)*n1,alpha(color1)*n1*1/(alpha(color2)*n2)_si_no_1-alpha(color2)*n2*1/(alpha(color1)*n1)+color2*(si_MIN(alpha(color1)*n1,alpha(color2)*n2)=alpha(color1)*n1,1-alpha(color1)*n1*1/(alpha(color2)*n2)_si_no_alpha(color2)*n2*1/(alpha(color1)*n1))_<-_el_alpha_resultante_es_MAX(alpha_(color1),alpha(color2))

Re-subo el hilo que es lo unico que puedo hacer. Haber si alguna alma caritativa nos echa una mano

Me gustaria ayudarte, pero no tengo claro que quieres que hagan esas dos formulas que crees que tienes mal.
Si me dices que deberia de haber en el resultado "color", igual te puedo ayudar.

Creo que mucha gente se cree que yo soy Elohe ( o me da esa sensación ). Pero somos dos personas distintas

Haber que dice Elohe.

Gracias lous por ofrecerte a echarnos una mano

PD: Sera mejor por messenger ¿ no ?, más rapido y comodo para los que participeis