Emulação de rons de Atari com Pic (Assembly)

Vicente Cesar · 5 de novembro de 2014

Pessoal, não sei se essa é a melhor área para postar isso, mas acho que aqui é o lugar onde posso receber uma resposta mais precisa. Depois de conversar com dois professores tivemos a ideia de usar uma rotina de vídeo que eu desenvolvi em Assebly para emular um rom de Atari e após analisarmos um pouco do seu funcionamento ele me deu um pic que disse ter capacidade para isso. Mas o problema é o seguinte, não sei como começar. Eu baixei o arquivo de um jogo de Atari, extensão .a26 e o código fonte do emulador que roda o jogo, mas não estou me saindo nada bem com esse codigo :s Existe alguma documentação sobre o Atari que eu posso ver como ler as rons ? O emulador é o Stella e pretendemos salvar o jogo em um pendrive. Estou aberto a sugestões. no caso a geração de áudio seria feita através de um segundo pic dedicado a isso, mas nesta primeira etapa pretendo ignorar o áudio se possível.

Não acho que seja complicado pelo que eu vi, principalmente por só ter 32 instruções diferentes no Atari, só preciso compreender o arquivo da rom.

É isso pessoal, se alguém achar que não vai dar certo por favor diga e fale o porque, ajudaria muito também kk. Obrigado

vtrx · 5 de novembro de 2014

Você teria que estudar as instruções do processador 6502,mas você não disse qual o PIC que te falaram que poderia ser usado...

Lembrando que o processador 6502 usa memoria Rom/Ram externa.

http://www.visual6502.org/docs/6502_in_action_14_web.pdf

Vicente Cesar · 6 de novembro de 2014

@vtrx, obrigado, já estou lendo sobre ele, surgiu uma duvida, o que contem em um arquivo .a26 já é o hexadecimal que deve ser interpretado pelo processador ? Se for tem como eu gerar o código Assembly a partir do hex ? Poque fica mais fácil entender o código Assembly. Achei muito bom a maneira que os jogos de Atari foram, foram bem criativos com as técnicas de processamento deles.

Eu não estou com o pic em mão no momento, só me lembro que é da serie 18F. Aproveitando que você entende de assembly e está coerente com o tópico, quero tirar uma duvida.

Uma parte da imagem é composta pelo "Campo de batalha" em português. Que é o plano de fundo, determinado por 20 bits e esses definem metade da tela. Essa metade você pode repetir, ou espelhar. Repetir é algo relativamente fácil, mas teria como espelhar um registrador no pic ? Porque o TIA, que é o processador de vídeo do Atari, se não me engano o nome, possui um registrador responsável por isso, algum pic teria esse recurso, se souber dizer o nome eu mesmo posso pesquisar. Até onde eu sei o pic não foi projetado para esse tipo de aplicação especifica, mas se ouve-se algo do tipo ajudaria bastante haha.

vtrx · 6 de novembro de 2014

Eu não entendi a questão

Vou te deixar com inveja sobre emulação+video com PIC 18F

http://www.pic24.ru/doku.php/en/osa/articles/vga_game

O autor programa pouco...

Felipe Electronic · 6 de novembro de 2014

Então seu projeto vai ler o conteudo de um cartucho de jogo de atari e projetar o video num monitor?

Abs.

Vicente Cesar · 6 de novembro de 2014

@Felipe Electronic O conteúdo estará em um pendrive, quero pegar e colocar o arquivo .bin diretamente nele. O vídeo@vtrx será projetado em uma televisão, inicialmente vai ser só em tons de cinza, um tom de cinza diferente para cada cor.

@vtrx, Realmente, ficou muito ***** isso, quando a minha duvuida, depois eu explico, estou meio sem tempo agora. PS: Eu olhei o projeto e nem acredito que isso foi feito com 12 MHz kkk. Muito bom.

Projetos_afg · 10 de novembro de 2014

@Felipe Electronic O conteúdo estará em um pendrive, quero pegar e colocar o arquivo .bin diretamente nele. O vídeo@vtrx será projetado em uma televisão, inicialmente vai ser só em tons de cinza, um tom de cinza diferente para cada cor.

Usar um pendrive!? Que eu saiba nenhum PIC18 tem USB Host para isso.

Esqueça o pendrive, implementar a pilha USB host é muito complicada e consumiria muitos recursos do microcontrolador, duvido que conseguiria manter a taxa de transferência mínima para o jogo rodar na velocidade normal.

Uma saída seria usar um cartão SD que é infinitamente mais fácil de se interfacear do que um pedrive, mas levando em conta que estará usando uma tabela de arquivos (FAT32), com um pic18 seria muito difícil conseguir velocidades de transferência maiores que 200Kbytes/s. Não sei quanto ocupa o binário desses jogos, se não for muito grande você pode transferir do cartão SD para uma memória RAM externa (existem umas memórias RAM seriais da microchip com até 1Mbit de armazenamento).

Agora a emulação vai exigir um poder de processamento grande. Esse projeto que o @vtrx postou dei uma olhada no código fonte e descobri que o jogo não é emulado, todo o jogo está escrito no arquivo 'game.c'.

Não sei qual era a velocidade que o processador 6502 do console atari (minhas pesquisas indicam algo entre 1 e 2MHz), mas você vai precisar de pelo menos 16 (chute meu) vezes essa velocidade para dar tempo de ler e executar o conjunto de instruções equivalente.

Vicente Cesar · 10 de novembro de 2014

@Projetos_afg, a ideia do pendrive é justamente colocar o jogo todo na RAM do pic ou em uma RAM externa. O clock do Atari é de 1.19 MHz e o do PIC 16F628A (Que é o que estou usando enquanto o 18F não chega)vai até 20MHz. Realmente gasta bem mais processamento emular do que rodar um jogo interno, mas acho que um PIC 18F será mais que o suficiente pelo que ando analisando. Quanto o tamanho do jogos o comum é 4KB, mas podem variar de 2KB a 32 KB (porém a maior parte é de 4 KB e os de 2KB são considerados muito ruins então o objetivo é emular pelo menos os de 4KB).

Ainda não fiz muitos testes pois estou terminando de codificar minhas rotinas de vídeo colorido. E por eu estar fazendo em Assembly ao invés de C (que era como estava tentando ante) acho que ganho um desempenho.

Quando terminar as rotinas de vídeo volto a trabalhar na emulação.

Projetos_afg · 11 de novembro de 2014

@Projetos_afg, a ideia do pendrive é justamente colocar o jogo todo na RAM do pic ou em uma RAM externa. O clock do Atari é de 1.19 MHz e o do PIC 16F628A (Que é o que estou usando enquanto o 18F não chega)vai até 20MHz. Realmente gasta bem mais processamento emular do que rodar um jogo interno, mas acho que um PIC 18F será mais que o suficiente pelo que ando analisando. Quanto o tamanho do jogos o comum é 4KB, mas podem variar de 2KB a 32 KB (porém a maior parte é de 4 KB e os de 2KB são considerados muito ruins então o objetivo é emular pelo menos os de 4KB).

Ainda não fiz muitos testes pois estou terminando de codificar minhas rotinas de vídeo colorido. E por eu estar fazendo em Assembly ao invés de C (que era como estava tentando ante) acho que ganho um desempenho.

Quando terminar as rotinas de vídeo volto a trabalhar na emulação.

Lembre-se que o clock do PIC sempre demora 4 ciclos de clock para executar a maioria das intruções. Se você têm um PIC16 com um cristal de 20MHz na verdade ele está executando 5 milhões de instruções por segundo. No caso do PIC18 a maioria dos modelos têm um PLL interno para multiplicar a frequência do cristal. No projeto que o @vtrx postou o cristal do microcontrolador é de 12MHz, mas o PLL interno multiplica por 4 e resulta em 48MHz, como o PIC precisa de 4 ciclos para cada instrução então nesse caso ele executa 12 milhões de instruções por segundo.

Vi que o 6502 demora entre 2 e 7 ciclos de clock por instrução dependendo do endereçamento utilizado, o que parece dar uma boa margem de tempo para um PIC18 emular o binário, desde que você consiga ler rápido o suficiente da memória RAM externa (não encontrei nenhum PIC18 com mais de 4KB de RAM interna).

Pelo que entendi esse atari tinha um processador de vídeo, acho difícil você decodificar as instruções e gerar um sinal de vídeo em tempo real somente com um PIC18.

Volto a dizer que não dá para utilizar um pendrive com um PIC18. Nenhum modelo dessa família tem USB Host, somente USB Device. Use um cartão SD que é tranquilo de interfacear (utiliza o protocolo SPI).

vtrx · 11 de novembro de 2014

Pelo que entendi esse atari tinha um processador de vídeo...

Esta é uma enorme vantagem do sistema.

Vicente Cesar · 11 de novembro de 2014

@Projetos_afg, eu irei tentar e tirar minhas próprias conclusões (Posso estar perdendo meu tempo, mas acredito que seja possível do jeito que estou fazendo). Mas o que está dando dor de cabeça mesmo é gerar cores na imagem . Desanimador isso Dx

Projetos_afg · 11 de novembro de 2014

Por volta de 2010~2011 eu estive procurando como gerar sinais de vídeo composto com um PIC16. Lembro-me de ter encontrado um site muito bom sobre o assunto. Hoje não encontrei mais esse site, mas encontrei este PDF que foi escrito pelo mesmo autor: http://elinux.org/images/e/eb/Howtocolor.pdf

Apesar do autor afirmar que não conseguiu gerar sinais no padrão PAL (só teve sucesso com o NTSC) ele explica muito bem como funciona a geração desses sinais.

Edit:

Encontrei o site no web archive: http://web.archive.org/web/20140209113630/http://www.rickard.gunee.com/projects/video/sx/gamesys.php

Vicente Cesar · 11 de novembro de 2014

Sim sim, essa vou uma das fontes na qual mais procurei mas não ajudou muito. Você conseguiu fazer?

OBS: @Projetos_afg, eu vi um post seu sobre isso no fórum enquanto pesquisava sobre o assunto haha. Mas não tinha conclusão.

Projetos_afg · 11 de novembro de 2014

@Vicente Cesar

Consegui apenas desenhar uma linha na tela, mais nada! Você conseguiu muito mais do que eu.

O que andei pesquisando recentemente foi o protocolo VGA que é muito mais fácil de se usar. Usei um FPGA como controlador de vídeo, mas o projeto está incompleto e estou cheio de coisas para se fazer nesse final de ano!

Vicente Cesar · 11 de novembro de 2014

Entendi, que pena que não continuou no Vídeo Componente, seria tão mais simples se alguém falasse o que falta haha, mas acho que estou bem perto. Boa sorte com o VGA ai.

@Projetos_afg, aproveitando que você já mexeu com sinal de vídeo, talvez saiba me responder uma pergunta. Como eu deixo uma onda defasada em Xº ? E com é possível transportar duas informações em uma onda se elas estiverem defasadas ?

Eu li muito sobre isso estudando um pouco de telecomunicações. Mas eu não entendo. Você sabe algo sobre isso ? (Se outros souberem responder, por favor comentem haha).

Projetos_afg · 12 de novembro de 2014

@Projetos_afg, aproveitando que você já mexeu com sinal de vídeo, talvez saiba me responder uma pergunta. Como eu deixo uma onda defasada em Xº ? E com é possível transportar duas informações em uma onda se elas estiverem defasadas ?

Eu li muito sobre isso estudando um pouco de telecomunicações. Mas eu não entendo. Você sabe algo sobre isso ? (Se outros souberem responder, por favor comentem haha).

Dei uma lida no pdf que indiquei.

Entendi que sobre o sinal de vídeo em preto e branco é adicionado mais um sinal com uma modulante de 4.43 MHz (no Brasil utilizamos o PAL-M que usa uma modulante de 3.58 MHz) que transporta a informação de cor utilizando o esquema de modulação 4QAM analógico.

O 4QAM significa Quadrature Amplitude Modulation que utiliza a modulação por fase combinada com a modulação em amplitude para a transmissão de informações. O 4QAM permite transmitir permite transmitir 2 bits por Hz (digital) ou 2 sinais diferentes (analógico) conferindo assim uma boa eficiência espectral.

No começo da varredura de cada linha do televisor é enviado um sinal de sincronia para que o oscilador interno da televisão esteja em fase com o oscilador do dispositivo que está gerando o vídeo:

É dessa forma que o televisor consegue perceber a defasagem dos sinais.

Com o sinal em preto e branco e as componentes R - Y (vermelho - luminância) [V] e B - Y (azul - luminância) é possível reconstruir as cores RGB. No sinal PAL a luminância (preto e branco) pode ser calculada por:

Y = 0.222R + 0.707G + 0.071B

Então para convertermos uma imagem RGB em suas componentes Y, U e V podemos utilizar a seguinte matriz:

┌ ┐   ┌                     ┐   ┌ ┐│Y│   │ 0.299  0.587  0.114 │   │R││U│ = │-0.147 -0.289  0.436 │ * │G││V│   │ 0.615 -0.515 -0.100 │   │B│└ ┘   └                     ┘   └ ┘

O sinal gerado pode de imagem para cada linha pode ser gerado com a seguinte função:

S(t) = Y + U*cos(2*π*F_M*t) ± V*sin(2*π*F_M*t)

Em que F_M é a frequência da modulante e t é o sinal no domínio do tempo.

Você pode observar nessa função o sinal ±, isso é devido ao PAL (Phase Alternating Line) precisar que um dos sinais seja defasado 180º (o color burst precisa ser defasado em 90º) em cada linha em relação à anterior.

O autor utilizou o microcontrolador SX rodando a 50MIPS para gerar um sinal com cores somente por software. Acredito que nessa parte seja necessário fazer em hardware para ter uma boa resolução e não exigir um microcontrolador poderoso dedicado somente para essa tarefa.

Vicente Cesar · 12 de novembro de 2014

Acho que entendi, o que pretendo fazer é deixar todos os valores possíveis já calculados na memoria (Fazer um palheta de cores, com 16 cores mais exatamente). Acha que seria possível ? A gora estou com o PIC 18F4550, finalmente chegou \o\, junto com osciladores de 16, 20, 24 e 32 MHz. Isso agiliza esses cálculos se levarmos em conta que tenho uma baixíssima resolução, então o calculo que faço para um pixel vale exatamente para os próximos 12.

Se você olhar no vídeo do que estou fazendo os pixel's são enormes:

Acho que nessas condições posso conseguir gerar as cores.

A unica coisa que eu não entendi bem foi o "±" na equação... Poderia explicar com um pouco mais de detalhes ?

Enquanto não consigo gerar o sinal a cores estou programando a logica de um jogo bem simples e o sinal Y (Que no caso eu já sei).

Projetos_afg · 12 de novembro de 2014

A unica coisa que eu não entendi bem foi o "±" na equação... Poderia explicar com um pouco mais de detalhes ?

Enquanto não consigo gerar o sinal a cores estou programando a logica de um jogo bem simples e o sinal Y (Que no caso eu já sei).

Esse sinal indica a que em cada linha de varredura você deve defasar a componente "V" em 180º em relação á anterior. Isso é necessário no PAL para evitar que ocorra erros cumulativos na sincronia do sinal (o NTSC originalmente tinha esse problema, o PAL usou essa técnica para resolve-lo, nas televisões NTSC novas isso não acontece mais).

Exemplo:

1ª linha:

S(t) = Y + U*cos(2*π*F_M*t) + V*sin(2*π*F_M*t)

2ª linha:

S(t) = Y + U*cos(2*π*F_M*t) - V*sin(2*π*F_M*t)

O autor afirmou que não conseguiu encontrar uma forma elegante no software para gerar essa defasagem, já que o sinal Y também teria que estar em fase com as cores.

Acabei encontrando 4 CIs que já codificam os sinais em PAL:

http://www.cirrus.com/en/pubs/proDatasheet/CS4954-55_F6.pdf

http://www.nxp.com/documents/data_sheet/SAA7108AE_SAA7109AE.pdf

http://www.analog.com/static/imported-files/data_sheets/ADV7174_7179.pdf

http://www.eecg.toronto.edu/~tm3/ad722.pdf

Vicente Cesar · 13 de novembro de 2014

@Projetos_afg, cabeça já está doendo haha No caso, qual a unidade de tempo da formula? Tenho que recalcular para cada pixel mudando esse tempo ?

Projetos_afg · 13 de novembro de 2014

@Projetos_afg, cabeça já está doendo haha No caso, qual a unidade de tempo da formula? Tenho que recalcular para cada pixel mudando esse tempo ?

Sim, a unidade de tempo é a mesma de cada pixel da imagem e ela vai depender da resolução do sinal de vídeo.

Vicente Cesar · 13 de novembro de 2014

Então se eu estou fazendo com cada pixel equivalendo a 12 pixels eu posso refazer o calculo a cada 12 ? Outra coisa, como eu poderia calcular seno e cosseno de um angulo qualquer no pic ? Não me parece nada simples ... porém acho que da tempo se eu for fazer esse calculo de 12 em 12 (Caso seja possível).

Projetos_afg · 13 de novembro de 2014

Então se eu estou fazendo com cada pixel equivalendo a 12 pixels eu posso refazer o calculo a cada 12 ? Outra coisa, como eu poderia calcular seno e cosseno de um angulo qualquer no pic ? Não me parece nada simples ... porém acho que da tempo se eu for fazer esse calculo de 12 em 12 (Caso seja possível).

Isso você usa uma tabela pronta com as unidades adequadas. Calcular em tempo real seno e coseno com o PIC demoraria dezenas de milisegundos.

Mas gerar um sinal de 3,58MHz mesmo sendo em onda quadrada para o 'color burst' já é complicado com o PIC. Você precisaria fazer um overclock de 14.328224 MIPS e mesmo assim não daria tempo para um loop:

;Cristal = 14.328224MHz;PLL = x4;Gera uma onda quadrada de 12 ciclos a 3,58MHzbsf	PORTx, ynopbcf	PORTx, ynopbsf	PORTx, ynopbcf	PORTx, ynopbsf	PORTx, ynopbcf	PORTx, ynopbsf	PORTx, ynopbcf	PORTx, ynopbsf	PORTx, ynopbcf	PORTx, ynopbsf	PORTx, ynopbcf	PORTx, ynopbsf	PORTx, ynopbcf	PORTx, ynopbsf	PORTx, ynopbcf	PORTx, ynopbsf	PORTx, ynopbcf	PORTx, ynopbsf	PORTx, ynopbcf	PORTx, ynopbsf	PORTx, ynopbcf	PORTx, ynopbsf	PORTx, ynopbcf	PORTx, ynop

Esse sinal nunca foi visado para ser emulado por software. Use um dos CIs que sugeri e sua vida ficará bem mais fácil!

Vicente Cesar · 13 de novembro de 2014

Sei que poderia fazer com os CI's que você disse, mas não é a primeira vez que vejo alguém fazer isso com um microcontrolador, então acho que á uma manira de faze-ló. o problema é que ainda não entendi o sinal de vídeo (Colorido), então estou pesquisando mais. Eu preciso entender o que vou fazer, e depois vou codificar.

Realmente calcular senos em tempo real não daria, mas pelo tempo está na formula, isso não entra na minha cabeça. Estou a pesquisar, assim que tiver resultados eu digo. Mas obrigado pela ajuda de vocês todos.

Projetos_afg · 13 de novembro de 2014

Com um PIC18 isso não é possível. Nunca vi nenhum projeto utilizando PICs 18/16 gerando video colorido sem auxílio de algum hardware externo para isso.

Encontrei um projeto fantástico que utiliza um AVR para gerar o sinal PAL colorido: http://www.linusakesson.net/scene/phasor/index.php

O AVR tem uma grande vantagem por ter um set de instruções bem mais poderoso, 32 registradores de uso geral (o pic só tem o W) e acesso à memória de forma linear sem troca de bancos / páginas.

mister nintendo · 13 de novembro de 2014

você pode usar a série de taylor pra calcular um seno ou cosseno

sen(x)= x - x^3/3! + x^5/5! - x^7/7! + x^9/9! .......... (continua dependendo da precisão que você quer)

mas pelo formato da conta da pra ver que um pic demoraria muito tempo pra fazer isso, só de ter que elevar um numero a nona haha, impraticável para seu projeto

flowww