Plataforma Retro de Hardware Open Source para jogos

gabrielj · 22 de outubro de 2015

Fala galera,

Estou pensando em criar uma plataforma de hardware open source para termos uma comunidade estilo o Uzebox. Desenvolvermos a plataforma e escrever jogos.

A ideia é diversão, não é produzir um console pra competir com os que existem nem nada disso. Ter algo fácil de montar e programar, com componentes que sejam fáceis de encontrar aqui no Brasil ou que pelo menos seja relativamente barato de importar em baixas quantidades.

Gostaria de saber a opinião de vocês principalmente em relação ao fato de ter que soldar um microcontrolador TQFP tipo esse https://en.wikipedia...ad_Flat_Package

Ou se acham melhor que seja um com encapsulamento DIP mesmo https://en.wikipedia...in-line_package

Essa pesquisa é porque a princípio tenho duas idéias, ou utilizar um ATmega1284p no formato DIP com 16kbytes de SRAM rodando a 21.47727MHz com mais alguns CIs mais comuns pra ajudar a gerar cor, OU um ATXmega no formato TQFP 64 ou 100 pinos com 8 ou 16kbytes de SRAM podendo ser overclockado até uns 57.27272 MHz talvez, preciso ver qual o valor mais seguro de não dar problema.

E aí, o que acham? Quem tem interesse em algo assim?

aphawk · 23 de outubro de 2015

@gabrielj,

É uma ideia bem ousada. Recentemente, um cara conseguiu emular um Apple II usando um simples Arduíno Uno, onde o Atmega328P fazia o processamento pesado, e o outro Atmega menos poderoso, que normalmente se encarrega da conversão USB / Serial , foi reprogramado e virou um gerador de vídeo !

Inicialmente, eu evitaria a tentação do Atmega1284P, pois um Atxmega é bem mais equipado de hardware, com mais Sram, mais Flash, as interrupções tem prioridade, e possuem desempenho maior. Para um jogo, onde a parte gráfica é bem importante, velocidade de processamento importa muito.

Mesmo assim, eu tenho um projeto aqui no CDH que usa um Atmega1284P justamente pela facilidade do DIP, e cheio de SRAM e Flash .....

Eu escolheria um Atxmega TQFP, soldaria num adaptador com terminais de espaçamento padrão 0.1" , e assim fica simples fazer o circuito impresso.

Agora, tem de escolher um Atxmega de preço bem acessível, ou usar um Arm ficaria com bem mais performance e preço semelhante.

Paulo

gabrielj · 24 de outubro de 2015

Pois é, se for usar um ATxmega quero usar um TQFP 64 pinos, espaçamento de 0,8mm. Pra mim é tranquilo soldar, mas não sei se tem bastante gente que se interessaria por esse projeto e aceitaria mexer com um componente desse.

Estou muito tentado a usar um ATxmega tipo o ATxmega128A3U que se encontra no aliexpress por uns 25 a 30 reais com frente grátis. Até mais barato que o ATmega1284. E rodando a 57.27272 MHz certamente daria pra programar um wolfstein3D ou Doom nele.

Com um ATmega1284 rodando a 21.47727 MHz até a quantidade de sprites por frame seria bem limitada. Além de precisar de mais uns CIs externos pra ajudar na geração de cor.

aphawk · 24 de outubro de 2015

@gabrielj,

Sim, não é preciso tantos pinos de hardware. Esse ATxmega128A3U está com um bom preço, e tem uma boa performance. E pode ser um excelente server para jogos mais antigos como Doom, Quake, etc.

Como cliente, eu não tenho experiência na parte gráfica para saber se consegue atender o Wolfstein 3D ou o Doom, depende muito da resolução que voce está pretendendo fazer funcionar.

Já tem algumas especificações tipo resoluçao / cores / frames ?

Paulo

gabrielj · 24 de outubro de 2015

@gabrielj,

Sim, não é preciso tantos pinos de hardware. Esse ATxmega128A3U está com um bom preço, e tem uma boa performance. E pode ser um excelente server para jogos mais antigos como Doom, Quake, etc.

Como cliente, eu não tenho experiência na parte gráfica para saber se consegue atender o Wolfstein 3D ou o Doom, depende muito da resolução que voce está pretendendo fazer funcionar.

Já tem algumas especificações tipo resoluçao / cores / frames ?

Paulo

Bom, como será com saída de video composto no padrão NTSC e não terei um duplo frame buffer pra controlar quanto tempo poderei gastar por frame, será os 60 frames por segundo mesmo.

Pretendo que tenha condições de gerar até 256 cores.

Como possivelmente terá vários modos de videos a resolução e forma de manipulação dos gráficos vai variar, mas quero que tenha uma resolução de 240x224 na melhor das hipóteses, sendo que pode ter menos, como por exemplo, 160x144 para um modo gráfico para raycasting no caso de um Doom. Poderá ter modos com tiles e sprites, ou só tiles, e até um modo só de texto que maximize a quantidade de caracteres por tela.

Caso eu escolha mexer como ATmega1284p se o pessoal achar melhor porque é DIP e tal, devo utilizar uma abordagem mais simples. Para minimizar o uso de componentes externos para a geração de cor talvez precise limitar a quantidade de cores para algo em torno de 192 cores com mais algumas escalas de cinza. A resolução máxima para o uso com tiles e sprites pode cair para uns 192x160 dependendo da dificuldade. E inviabilizaria a implementação de um raycaster.

E independente do microcontrolador que utilizar, quero implementar conexão wifi com um módulo ESP8266, utilizar controles de SNES para o gamepad e dar suporte a teclado PS/2.

Imagina um port do Doom com deathmatch online? hehehe

Gabriel

aphawk · 25 de outubro de 2015

@gabrielj,

Entendí o seu conceito.

Não vejo problema em usar o Atxmega em Tqfp64. Eu já soldei dois adaptadores deste tipo :

http://home.cogeco.ca/~sxtek/D-QFP64-8/QFP64-iso_220.jpg

Com um ferro de baixa potência e ponta fina, dá para fazer. E tenho certeza de que se o projeto for para a frente logo aparece alguém que "venda" esse serviço para quem tem muita dificuldade em soldar.

Vale a pena pelo ganho em performance.

Vai precisar usar memória Sram externa ( tem só 8k nesse Atxmega escolhido) ? Ou está pensando em algum CI gráfico que agilize as coisas e possa ser acessado por DMA do Atxmega ? Ou algo mais simples para ajudar ?

Gostei da parte do Joystick do Snes, mas gostei mais do Doom com deathmatch ! Que saudades do meu tempo de Doom e de Quake .... Bons tempos do clã Darkside, 1996 / 1997 se não me engano, modens a 56k na linha telefônica hehehehe !

Me deu até vontade de reinstalar o Doom !

Paulo

gabrielj · 25 de outubro de 2015

@gabrielj,

Entendí o seu conceito.

Não vejo problema em usar o Atxmega em Tqfp64. Eu já soldei dois adaptadores deste tipo :

http://home.cogeco.ca/~sxtek/D-QFP64-8/QFP64-iso_220.jpg

Com um ferro de baixa potência e ponta fina, dá para fazer. E tenho certeza de que se o projeto for para a frente logo aparece alguém que "venda" esse serviço para quem tem muita dificuldade em soldar.

Vale a pena pelo ganho em performance.

Vai precisar usar memória Sram externa ( tem só 8k nesse Atxmega escolhido) ? Ou está pensando em algum CI gráfico que agilize as coisas e possa ser acessado por DMA do Atxmega ? Ou algo mais simples para ajudar ?

Gostei da parte do Joystick do Snes, mas gostei mais do Doom com deathmatch ! Que saudades do meu tempo de Doom e de Quake .... Bons tempos do clã Darkside, 1996 / 1997 se não me engano, modens a 56k na linha telefônica hehehehe !

Me deu até vontade de reinstalar o Doom !

Paulo

Estou pensando em utilizar apenas o ATxmega mesmo. Utilizar este de 8k ou algum outro com 16k de SRAM.

Nos modos com tiles e sprites ele vai carregar os gráficos da flash e vai usar a ram nos casos do tilemap e talvez na implementação de um sistema de ramtiles para o uso de sprites. No caso de um modo de raycasting, como não vai ter RAM suficiente para um framebuffer vou tentar implementar a engine durante as scanlines mesmo, pré-computando as colunas (alturas das parede e texturas) durante o vsync da TV.

No momento, meu desafio está sendo gerar cor com o ATxmega utilizando os pwms ou USART no modo SPI mas de forma que eu consiga setar a cor e o valor de luminancia do DAC externo (com resistores) em apenas um ciclo, de uma só vez, para otimizar. Ainda não consegui achar uma forma.

aphawk · 25 de outubro de 2015

@gabrielj,

Nem mesmo o Ad725 ???? Bom..... Pelo que você está escrevendo vejo que voce está bem familiarizado com a geração de gráficos.

Acho que para evitar hardware adicional vai ter de fazer várias coisas em Asm. voce programa também em Asm ?

Paulo

gabrielj · 25 de outubro de 2015

@gabrielj,

Nem mesmo o Ad725 ???? Bom..... Pelo que você está escrevendo vejo que voce está bem familiarizado com a geração de gráficos.

Acho que para evitar hardware adicional vai ter de fazer várias coisas em Asm. voce programa também em Asm ?

Paulo

Não queria usar o AD725 porque ele é difícil de se conseguir por aqui, mesmo importando e é caro demais pela função dele na minha opinião. Já usei ele uma vez mas acho que vai complicar pra quem quiser montar.

Sim, já estou familiarizado com ASM, principalmente com AVRs. Na verdade mais que em C.

No passado já mexi com geração de video também. Aqui tem alguns videos https://www.youtube.com/results?sp=QgIIAQ%253D%253D&q=sizucae

Sizucae é de SIstema braZUCA de Entretenimento. Vou pensar em um nome melhor para o novo console hehehe

aphawk · 25 de outubro de 2015

@gabrielj,

Opa, legal heheh você está anos-luz na minha frente !

Não conseguí abrir o seu video no meu Ipad, estranho....

Bom, eu achei alguns posts sobre a geração com Atxmega, mas para saįda Vga. Na marra, como você quer fazer com video composto, achei apenas para Atmega justamente pela SPI, mas não sei se a resolução / cores atende o que você quer fazer. Vou continuar pesquisando...

Paulo

gabrielj · 25 de outubro de 2015

@gabrielj,

Opa, legal heheh você está anos-luz na minha frente !

Não conseguí abrir o seu video no meu Ipad, estranho....

Bom, eu achei alguns posts sobre a geração com Atxmega, mas para saįda Vga. Na marra, como você quer fazer com video composto, achei apenas para Atmega justamente pela SPI, mas não sei se a resolução / cores atende o que você quer fazer. Vou continuar pesquisando...

Paulo

Eu sei que o Brad (AtomicZombie nos fóruns da AVR freak) conseguiu algo do tipo. Mandei um email pra ele mas ainda não obtive resposta ainda.

De qualquer maneira vou continuar com os testes.

Estranho não ter aberto o link. Só buscar "sizucae" no youtube que aparece.

vtrx · 25 de outubro de 2015

Se os vídeos do link tem 7 anos em média,e ja geram vídeo e algum movimento,não entendo porque parou,a ponto de abrir um tópico.

gabrielj · 25 de outubro de 2015

Se os vídeos do link tem 7 anos em média,e ja geram vídeo e algum movimento,não entendo porque parou,a ponto de abrir um tópico.

É porque na época utilizei o ATmega8515 que já é bem antigo e usei SRAM externa. Dá pra ver que usei um monte de CIs. Estou querendo fazer um novo design que seja mais simples de se construir, com componentes mais fáceis de adquirir e que tenha uma API mais fácil de se programar, para que possamos (quem se interessar por esse tipo de coisa) criar uma comunidade em torno disso, para melhorá-lo, criar jogos, etc. Tudo pela diversão de se montar o próprio console e fazer jogos pra ele, e pelo desafio de se extrair o máximo de performance e resultado desses microcontroladores de 8 bits.

vtrx · 25 de outubro de 2015

Vai ter que continuar a usar Ram externa.

Eu utilizaria arquitetura ARM,que é fácil de portar.

Tudo depende do que quer emular ou criar,e da resolução vai depender a Ram externa.

Poderia também fazer um 'mix',usando um micro para video com sua Ram dedicada e outro para periférico e comunicação externa,deste modo poderia usar ATmega e algum outro qualquer.

Se seu desafio seriam em 8 bits,imagino que teria que usar mais de um para um bom resultado.

Se mesmo assim for um desafio de um micro 8 bits,então além da Ram externa,vai ter que usar ASM.

Pena que depois dos celulares,minha vontade de fazer algo similar sumiu...

Fiquei com a impressão de reinventar a roda por causa dos Tablets e celulares,afinal um Tablet é tudo isso que precisamos ja montado,apenas mudando o sistema operacional.

aphawk · 25 de outubro de 2015

@vtrx,

Esse Atxmega tem toda a interface para acessar a Sram por Dma, e rodando a 57 Mhz fica bem rápido. E não precisa de CI adicional ( acho... ), fica um hardware bem minimalista. Existe um outro Atxmega que tem 16K de Sram, mas acho mais simples usar uma Ram estática externa.

Aproveitei e dei uma boa olhada no Uzebox, a coisa está evoluindo bem, e tem alguns jogos bem legais. E olha que é um projeto mais antigo...

paulo

gabrielj · 26 de outubro de 2015

A geração de cores no formato NTSC não está ficando tão legal. Estou começando a considerar utilizar saída VGA.

Seria bem mais simples, não precisaria de nenhum chip externo. Daria um apelo mais retro computer do que video game, mas ainda assim seria legal. E hoje em dia até as TVs novas tem entrada VGA.

Vou fazer uns testes.

26 de outubro de 2015

Daria um apelo mais retro computer do que video game, mas ainda assim seria legal. E hoje em dia até as TVs novas tem entrada VGA.

Vou fazer uns testes.

Muito interessante, dá para ver que você manja bastante da parte gráfica.

Eu particularmente gosto muito desses consoles caseiros, inclusive acompanho o site um portátil chamado gamebuino (um ATmega328p e um lcd nokia 5110) é um sisteminha bem simples, com um buffer para o LCD, e um timer gerando uma interrupção 20 vezes por segundo (para 20 frames) a cada interrupção o buffer é transmitido para o LCD, bem simples mesmo... Mas o legal é que com toda essa simplicidade se obtém resultados impressionantes, veja só, ja que você citou o Wolfstein 3D:

(ainda não é jogável, é apenas o cenário mesmo)

Com resolução de 84x48 e um Bit de cor, conseguiram renderizar um cenário 3d em primeira pessoa, fazer a animação de abertura das portas e dos disparos... Realmente incrível, chega a ser inspirador (rsrs)... !!!

Já sabe qual sera a plataforma de desenvolvimento? Imagino eu que sera o AVR GCC (vi que você citou a Biblioteca pgmspace que permite guardar informação na memoria Flash do ATmega) isso é muito interessante pois a lógica do jogo geralmente não ocupa muito espaço (não tanto quanto os Sprites e os tileMap's do cenário), mas acho que para sprites coloridos e de uma resolução considerável ( ja que você citou 240x224 e 256 cores) mesmo com a Flash pode ser pouco dependendo do tamanho do projeto (jogo)...

No forum do Gamebuino, burlaram esse problema fazendo o Streaming direto do cartão SD, talvez seja uma opção para esse caso tambem, acho que seria interessante fazer um benchmark para testar a velocidade de acesso ao cartão de memoria, assim da para saber se é possível carregar dados do jogo direto do cartão sem comprometer muito o processamento do uC...

Na minha humilde opinião,também acho que seria interessante diminuir o Frame Rate pela metade, acho que 60 Frames é muito, acima de 30 frames não notaríamos a diferença.

Você tem um projeto muito interessante em mãos, eu fico aqui torcendo para dar certo pois é difícil, ver um Brasileiro com um projeto audacioso desses... Vou ajudar no que puder, mas meus conhecimentos na parte de geração de vídeo são bem superficiais (acho que dá para notar rsrs), quem sabe mais para frente posso ajudar em algo (alguma biblioteca de física para os jogos? Gravidade? Atrito? aceleração? Inercia? rsrsrs).

Bom, espero que de tudo certo mesmo, qualquer coisa em que eu possa ser util, estamos ai!!

Grato, Luiz Gustavo.

gabrielj · 26 de outubro de 2015

A plataforma que pensei foi AVR GCC mesmo. A princípio acredito que fazer o streaming dos gráficos em tempo real a partir do SD não seria possível, a não ser para algum modo com baixa resolução para um player de video estilo o que o uzebox faz. Mas quero usar o SD não só para carregar o jogo e programar a flash do uC, mas tentar carregar os sprites e tiles para uma nova fase por exemplo a partir do SD.

Nesse caso eu teria que gravar os gráficos na RAM do uC pra não ficar reescrevendo a flash toda hora, mas mesmo que seja possível gravar na RAM apenas uns 128 tiles de 8x8 pixels cada, ainda fica interessante já que os jogos ganham a possibilidade de serem virtualmente muito grandes.

O framerate eu não sei como faria para reduzir. No caso da geração do video não tem jeito, preciso gerar os 60 frames para a TV ou monitor aceitar. No entanto, caso tenha um frame buffer duplo eu posso demorar o tempo que precisar para desenhar no buffer inativo e trocar a hora que eu quiser pelo ativo. Dessa forma daria pra reduzir o framerate para 30, 20, 15, conforme fosse necessário. Mas sem frame buffer duplo ficaria complicado. Nessa questão uma RAM externa viria a calhar.

Eu agradeço a atenção e digo que realmente precisarei de ajuda. Muita coisa precisará ser feita, emulador, ferramentas de desenvolvimento (conversores de gráficos, sons, etc), documentação.

aphawk · 26 de outubro de 2015

@gabrielj,

Infelizmente não posso ajudar em nada com o C, mas posso ajudar no ASM puro e também no hardware.

Pelo que eu andei lendo, gerar os sinais direto em VGA tem temporização crítica e consome bem mais CPU. Mas com o Atxmega a mais de 50 Mhz, vai ser mais fácil.

Por outro lado, hoje um simples adaptador VGA -> vídeo composto custa uma bagatela.

E a SRAM ? Achei algumas de 64K que custam pouco mais que uma de 8K. Claro que no formato Dip mesmo. Tem alguma preferência de tamanho ?

Paulo

26 de outubro de 2015

Eu agradeço a atenção e digo que realmente precisarei de ajuda. Muita coisa precisará ser feita, emulador, ferramentas de desenvolvimento (conversores de gráficos, sons, etc), documentação.

Acho que posso ajudar em alguma coisa então.. rsrs... Conversores de graficos e sons não são tão dificeis de fazer, acho que posso dar um jeito nisso mais para frente... huehue... Já ate fiz algo parecido para o Gamebuino, só vai precisar de umas modificações por conta dos gráficos serem coloridos...

Este por exemplo, ja converte os Sprites e gera o tile MAP, passando tudo para código compatível com a biblioteca do GB, é fácil modificar as saídas para para gerar um tipo de código diferente.

Esta é uma versão beta com alguns Bugs ainda (fiz em 2 dias rsrs), mas funciona bem dentro suas capacidades, acabei dando uma parada no desenvolvimento por falta de tempo mesmo, ai acabei não adicionando mais nada nela.

Não sou nenhum T.I., mas me viro bem no visual Basic... rsrs

A questão do Som é um pouco mais complicado, vamos ter que esperar para ver como a biblioteca de Som vai funcionar para podermos bolar algo.

A questão do frame Rate é complicado mesmo, kkk... obrigatoriamente teremos que gerar 60 frames, precisaríamos ter 60 interrupções no programa e para reduzir o frame rate precisaríamos de 2 buffers, e que implica no dobro de memoria consumida, mas seria um ganho interessante em processamento, pois teríamos o dobro de tempo e só metade do trabalho para manipular o programa.

Um jeito de otimizar isso seria usar um microcontrolador menor para fazer a parte de geração de video, tipo um buffer de saida que fica sendo exibo até ser atualizado, quando o uC central termina de gerar o próximo frame, ele atualiza o uC gerador de video que passa a exibir o ultimo frame recebido... Acho que isso complica um pouco as coisas (a nivel de contrução do projeto mesmo), se tentarmos com 60 frames mesmo talvez de para fazer o processamento do jogo no intervalo entre frames, afinal serão 50Mhz certo? rsrs

Acho que isto deve ser experimentado para ver se o desempenho em 60 Frames é satisfatório, ou se até lá conseguirmos bolar um jeito de fazer em 30 frames sem dobrar o consumo de memoria, melhor ainda...

gabrielj · 26 de outubro de 2015

VGA realmente deixa a questão do tempo um pouco apertado. Mas aparentemente, pelos testes que o pessoal anda fazendo, as versões USB dos ATxmega, que estão virando padrão, aguentam overclock até uns 70MHz sem reclamar. Se setarmos em 64MHz para gerar VGA acho que dá pra inserir uma engine de tiles com sprites nos tempos de pixels.

Acho que usar mais de um uC vai dificultar um pouco, tanto na hora de montar, como cada vez que for programar para atualizar ou programar durante o carregamento de cada jogo caso o jogo queira implementar um modo gráfico diferente.

Quanto a memória externa, encontrei uma SRAM de 128kbytes no aliexpress por uns 19 reais. Praticamente o preço do ATxmega, além de adicionar mais espaço na placa de circuito impresso depois. E ainda tem a questão da velocidade, a que encontrei é de 45ns, acho que precisa de uma de 10 ou 15ns porque o uC vai estar rodando no dobro da velocidade e pode não ler/escrever corretamente essas memórias mais lentas.

Para jogos 2D tenho certeza que a SRAM interna de 8 ou 16kB será suficiente, mas para outros usos como um raycaster e coisas do tipo a RAM externa pode vir a calhar. Estou dividido quanto a isso ainda.

gabrielj · 27 de outubro de 2015

Eu testei o overclock no Xmega que eu tenho aqui que é o ATxmega128A1 e consegui 56 MHz (cristal de 4 MHZ e PLL x14) rodando estável, não cheguei a testar leitura e escrita da flash totalmente mas parece estar ok. Esperava chegar nos 64 MHz mas como esse que eu tenho não é USB, esse foi o limite.

Parece que as versões USB dos Xmega (Atxmega128A1U nesse caso) suportam overclock maior devido a necessidade do clock dos circuitos USB terem que rodar a 48MHz.

Dizem que as versões sem USB estão ficando escassas e a Atmel está dando preferência para produzir versões com USB. Mas eu não estou vendo isso nos sites de venda. Ainda parece ser difícil encontrar com USB.

gabrielj · 10 de maio de 2016

Eae,

Só pra dar algum sinal de vida, segue um video de raycasting com o ATXmega384C3 rodando a 72MHz.

Estou utilizando 8 bits de cor, onde defini 2 bits pra cada cor RGB e dois bits gerais de luminância. A resolução do raycasting que usei foi de 192x144. Ficou um formato bom ocupando 27648 bytes dos 32768 disponíveis, sobrando uns 5k de RAM para a aplicação, e dá pra deixar os arredores da tela como hud para mostrar status, vidas, mapa, etc.

https://youtu.be/hQ16UbVliLU

Implementei também um modo gráfico mais simples de tiles para texto e já adaptei uma versão de tiny basic pra ele, rodou legal. Assim que fizer um video eu posto. No caso do basic, na parte de salvar um programa na eeprom e carregar a coisa complicou por causa do overclock. A eeprom não funciona de jeito nenhum a 72MHz. Implementei então duas funções simples para mudar o clock para 32MHz e pra voltar para 72MHz. Dessa forma sempre que o basic vai fazer alguma operação na eeprom ele reduz o clock e depois volta. Nesse meio tempo a geração do sinal VGA é interrompida. Então na hora de salvar algum programa ou carregar a tela dá uma apagada. Mas acho aceitável, inclusive isso acontecia com alguns computadores 8 bits antigos. De qualquer maneira no futuro possivelmente não utilizarei a eeprom interna, e apenas um cartão SD / microSD.

Abraço.

aphawk · 10 de maio de 2016

@gabrielj ,

Ficou bem legal ! Me lembrei do famosos "Monstro das Trevas" do Sinclair ZX-81 / TK82C / TK85 .

Não imaginava que era possível esse overclock.... mas se o truque 32/72 Mhz é confiável, então bola para frente.

Pelo preço, usar um SD card para armazenamento resolve esse problema da Eeprom interna com muita vantagem.

Parabéns pela continuidade do desenvolvimento !

Paulo

gabrielj · 10 de maio de 2016

@aphawk Valeu

Pois é, a ideia era usar mesmo cartão SD para o armazenamento de jogos e programas. Só fiz esse truque pra usar a eeprom pra poder testar as rotinas de save e load que já tinha na versão do tiny basic que eu modifiquei. Se bem que a eeprom interna vai ser útil para configurações do sistema e pequenos parâmetros futuramente.