Group chat: Arqueologia Digital e Preservação Histórica por meio da Emulação de Dispositivos Eletrônicos - page 3
Werner Eck:
de q esses 4 valores jogados no &30 possam estar inicializando os 4 modos de dma
Werner Eck:
poderia ser ou o crtc jogando DRQ0~DRQ3 pro dma ou o dma jogando dack0~dack3 pro crtc
Werner Eck:
eu to meio confuso
não... esses valores aí são a inicialização do CRTC
a primeira escrita é em 0x31 (bit A0=1) e o valor é zero, ou seja, trata-se desse comando aí da tabela acima, o comando de reset do CRTC
e os 4 bytes seguintes são escritos em 0x30 (bit A0=0)
então o primeiro byte é 4F = 0100 1111 = S H H H H H H H
então S=0 e H = 4f
S=0 significa "Normal Rows" (isso provavelmente significa que não há 1 ou mais pixels de espaçamento entre os tiles)
e H=4f significa que temos 0x50 caracteres por linha
veja que soma 1 ao valor
0x50 = 80 caracteres por linha
oras bolas... é um terminal de 80 colunas :-)
veja, inclusive, na tabela acima, que 80 é o maior valor permitido.
e tá lá justamente o nosso 4F na tabela
ele soma 1 sempre
o valor zero significa 1 caractere por coluna e assim por diante. Veja de novo os valores da tabela
o chip interpreta a configuração como (valor+1)
o segundo byte é 0x59 = V V R R R R R R
0x59 = 0101 1001
V = 1 e R = 25
Werner Eck:
vc quer dizer, 1 char por linha?
Werner Eck:
to tentando ler essa parte
ok... vamos olhar para a tabela de novo
caso esse parâmetro tivesse recebido uma escrita do valor 0x00 = 0 0 0 0 0 0 0 0 , isso significaria 1 char por linha (que é bizarro, mas parece que o chip suporta esses casos degenerados)
isso provavelmente seria um caractere grandão, esticadão na horizontal
pra um único caractere ser desenhado em uma linha inteira
mas o que o firmware do sagitta configura é 4F
que é o valor binário 1 0 0 1 1 1 1, que, apesar de em decimal valer 79, na tabela ele mostra que o chip interpreta como sendo 80 chars por linha
Werner Eck:
e os outros valores, $59, $99, $ee?
ok... vamos pros outros 3 valores
o segundo valor é 0x59 = 0 1 0 1 1 0 0 1
que segundo a tabela corresponde aos valores dos parâmetros V V R R R R R R
V = 1 e R = 25
e o significado desses valores:
Werner Eck:
são esses parametros V e R q eu não estou achando
Werner Eck:
é q vc deve estar com esse pdf em várias abas
R = rows / frame
tá na parte debaixo da página 17 (que é identificada como página 8-239)
Werner Eck:
acabei de me dar conta de q tá td ali na msm pag, eu q comi bola
Werner Eck:
Eu quero pensar q essa parte de inicialização do CRTC esteja funcionando
yep
parece tudo perfeito
por que esse valor R = 25 é o que nos diz que a tela tem 25 linhas
ou seja é um terminal em resolução 80x25
resolução bem típica
Werner Eck:
uma coisa q me chamou a atenção é esse parametro M
Werner Eck:
parece ser um offset para o contador de linhas. Mas pensando melhor, acho q nao tem nada a ver com nada
Werner Eck:
entao, voltamos ao estado de...
Werner Eck:
parece q a inicialização do CRTC se dá ali mesmo
Werner Eck:
talvez então, ele não esteja lendo a área certa?
Werner Eck:
ou os caracteres lidos não estejam sendo escritos na área de VRAM q o CRTC espera? Mas se isso está codificado na EPROM, então é lá mesmo q tem q ser
Werner Eck:
será q estamos setando o CRTC para o range de endereçamento de VRAM certo?
eu acho que a transferência DMA não está acontecendo
por que o emulador não está interligando corretamente os sinais entre o DMAC e o CRTC
e o efeito colateral é que o CRTC é inicializado, mas sua memória interna tem um buffer todo cheio de zeros
e ele nunca consegue efetuar uma leitura via DMA
e portanto a gente continua vendo o caractere número zero na tela inteira
acho que o ponto agora é estudar o mecanismo de requisição e acknowledge de transferência DMA
o endereço inicial e final também devem estar sendo configurados corretamente, pois já mapeei o DMAC nas portas 44 e 45 que é onde o firmware escreve 8000 e 8fff que é a faixa de endereços da VRAM
acho que já matamos a xarada do mapeamento em I/O e o nó está agora na emulação da interconexão dos 2 chips.
tem um outro carinha na jogada que é o Intel 8212
tem um desses na placa e o datasheet do DMAC diz que ele é projetado pra trabalhar junto com um 8212
Werner Eck:
ele existe no sagitta?
sim
Werner Eck:
eu tava vendo isso no ds do crt
Werner Eck:
veja na pg 2-112
Werner Eck:
e depois pg 2-111, fig 8
Werner Eck:
e o 8212 é um latch de 8 bits
Werner Eck:
se vc disse q tem ele na placa, teria q emular o bicho tbm
Werner Eck:
ele deve estar entre o barramento de dados e o crtc
A configuração do DMAController é meio confusa no MAME. Olha um exemplo de um driver de outro computador que usa esse chip. Olha como ficam as macros:
Tenho que entender melhor a função de cada sinal
pra não ficar perdido
não adianta chutar. O importante é entender o que está acontecendo :-)
Vou dormir. Amanhã eu devo continuar nessa pesquisa
em última instância, dá pra ir lá na USP com um multímetro e verificar quais são as interligações que foram feitas entre os chips
boa noite!
uma observação, entretanto...
apesar de vermos os endereços de I/O 44 e 45 sendo usados, o chip DMAC provavelmente está mapeado nas portas de 0x40 até 0x48
e o acesso a 44 e 45 é a configuração do canal número 2
e, de fato tem uma escrita que o firmware faz no endereço 0x48
eu tava comendo bola
vou mapear nesse range, por que assim a escrita em 0x48 vai setar o modo de operação da DMA
caramba... acho que é isso
estou tentando
olha a escrita em 0x48 alí
tá escrevendo o valor 0xC4
vamos ver o que é esse valor ?
Werner Eck:
acabei de chegar nisso
o valor 4 do número 0xC4 são aqueles 4 bits baixos de enable dos canais
4 = 0 1 0 0
ou seja, todos os canais estão desabilitados
exceto o canal número 2
isso é a prova de que o sinal de DMA Request que o chip CRTC precisa enviar para o DMAC é por meio do canal 2.
É por isso que eu estou mantendo essa linha assim:
MCFG_I8275_DRQ_CALLBACK(DEVWRITELINE("dma8257" , i8257_device , dreq2_w))
dreq2_w é o método do emulador do DMAC que vocÊ precisa chamar para sinalizar uma requisição de DMA para o canal #2
Werner Eck:
imaginei q seria isso
veja que essa macro configura que o DRQ emitido pelo CRTC chama um callback que sinaliza um dma request no canal 2 do DMAC
levou um tempinho até eu entender essa sintaxe
Werner Eck:
agora sabemos q ele está setando o modo dma no canal 2, para isso o CRTC precisa requisitar nesse canal
sim
não tá funcionando ainda, mas foi bom eu ter tido essa sacada
se eu continuasse mapeando em 44 e 45 apenas, jamais iria funcionar
precisa mapear no intervalo todo, pra que o firmware consiga configurar o chip de DMA
na porta 48
Werner Eck:
bom, eu realmente preciso descansar
Werner Eck:
já to vendo névoa na minha frente
Werner Eck:
boa noite, vou nessa.
tem uns outros bandidos que são as portas 0x21, 0x00 e 0x50
o firmware acessa esses outros endereços logo no começo
então aí tem coisa também
talvez seja o setup do chip de RS232
Werner Eck:
amanhã podemos ver isso
beleza
eu posso também em algum momento dar um commit e subir pro meu github esse código atual do driver pela metade
boa noite
e happy hacking!
BOOOM !!!!
Agora sim! Agora posso ir dormir :-)
Werner Eck:
Eae maluco?!!
Werner Eck:
Fala, o q era?
hehe
burocracias do MAME
Werner Eck:
to olhando lá o seu commit
tinha faltado eu implementar explicitamente o mecanismo de leitura de memória
pra ser sincero... eu não entendi direito tudo ainda
Werner Eck:
não era nada técnico no final das contas
mais ou menos...
Werner Eck:
me fala, os endereços dos registradores de dma e do crtc estavam certos no fim?
sim
agora o próximo passo é fazer a serial funcionar
Werner Eck:
tem q emular o uart
suspeito que o controlador de porta serial esteja mapeado no endereço 0x21
já instanciei o módulo de emulação de UART
Werner Eck:
se já tiver ele no MAME, meio caminho andado...
falta configurar
sim, já tem
essas coisas são muito comuns
o MAME é extremamente modular e certamente algum outro driver já usou esses chips todos
Werner Eck:
daí é pegar no ds pra saber como é a inicialização né? E comparar padrões na EPROM pra encontrar isso
é
é por aí
Werner Eck:
vc já desconfia de onde tenha isso na EPROM?
Werner Eck:
de tanto olhar
estou suspeitando desse código aqui:
portas 0x21 e 0x00
Werner Eck:
parece ser bem semelhante ao dma... ele joga 3 valores na $21
Werner Eck:
deve estar setando alguns modos
Werner Eck:
é o q lembra, daquilo q vimos ontem. Qual o código do chip SPI?
Werner Eck:
Isso aqui é interessante ter como referencia:
https://en.wikichip.org/wiki/intel/mcs-80MCS-80 - Intel
The MCS-80 (Micro Computer Set-80) was a family of 8-bit microprocessor chipsets developed by Intel. Introduced on April, 1974, the MCS-80 featured the 8080 CPU, the forefather of all modern x86-based microprocessors.
Forwarded message from Fractal:
Forwarded message from Fractal:
Werner Eck:
Werner Eck:
Werner Eck:
Werner Eck:
Werner Eck:
Se o 8251 for mapeado em $21, então a primeira palavra seta o modo assíncrono: 0x7A=01 11 10 10: 1 stop bit; paridade: habilitada, par; compr. palavra: 7 bits; fator baud rate: 16x
Werner Eck:
O q segue deve ser a instrução de comando seguida de dados. To lendo essa parte para entender
acho q é mapeado em 0x20 e 0x21
Werner Eck:
dois endereços?
sim
um pra dados e outro pra comandos
é um setup comum de vários dispositivos
usar o bit de endereço zero para diferenciar entre duas portas
Werner Eck:
isso é padrão do MAME?
não
isso é padrão de design de hardware
Werner Eck:
q estranho... não me soa familiar isso\
Werner Eck:
Se quero endereçar um periférico, uso um endereço, no qual ele está mapeado...
muitos periféricos usam multiplos endereços
é comum isso
Werner Eck:
bom. vc acha q faz algum sentido o q eu falei aí atrás?
acho que faz um pouco
mas não acho que seja na porta 21
acho que ele está mapeando dados na 20 e comandos na 21
Werner Eck:
é q eu estava baseando a minha análise nisso q vc falou
Werner Eck:
Werner Eck:
só vejo ele escrever no $21 nesse snippet. E le alguma coisa do $00
talvez não haja escrita de dados nessa parte do programa, mas haja em outro trecho
Werner Eck:
depois faz uns rotate right
Werner Eck:
bom, vou deixar pra qdo vc chegar nessa parte. Aí vc já tem condição de ver os mnemônicos./
putz! acho que esse 0x00 pode ser o dipswitch !
Werner Eck:
teria q ter os dispositivos mapeados
Werner Eck:
pra saber em qual endereço de memória está cada um deles
Werner Eck:
ele le o $00 e depois faz um AND com o q tem no acc
Werner Eck:
minto; ele lê o $00 e depois faz um and com o q tiver no $03 e o acc
Werner Eck:
na prática, entendo q ele joga o q tem no $00 no acc, depois faz um AND com esse valor e $03
isso
ele tá tomando decisão em função dos 2 bits menos significativos lidos da porta 0x00
Werner Eck:
beleza; só falta entender o contexto disso
que eu acho que é de onde ele lê a configuração dos dipswiches
Werner Eck:
pode ser sim. Um jeito comum de se deixar a parte de configuração (stop bit, paridade, palavra, etc) da interface configurável pelo usuário
Werner Eck:
se é q isso é a parte do 8251
Werner Eck:
não temos certeza ainda
Werner Eck:
pode ser outra coisa
aqueles 2 bits lidos do endereço 0x00 definem qual valor é escrito na porta 0x21
0x7A, 0x4E ou 0x5A
Werner Eck:
ummmm... tá fazendo mais sentido hein??
supondo que a porta 0x20 é para dados e a 0x21 é para comandos, acho que a gente pode tentar interpretar esses 3 valores conforme o datasheet descreve a estrutura dos comandos
pra ver quais são as opções
e se fizer sentido, a gente documenta já no driver
Werner Eck:
pode ser sincrono ou assincrono. E o terceiro byte pode ser o comando
Werner Eck:
perae q eu preciso forrar o estomago. Senao caio duro aqui
olha só como se faz pra implementar um dip switch no MAME:
Werner Eck:
isso vc tirou de um driver já implementado?
Werner Eck:
ou vc escreveu isso agora?
Werner Eck:
Eu suponho q o q tem nas linhas 0x3A/0x3E/0x42 não está sendo executado antes da instrução da linha 0x46?
Werner Eck:
talvez esse bloco q vc me passou seja parte de um desvio condicional?
Werner Eck:
a lógica estando mais concentrada nas linhas 0x57 e 0x5c?
Werner Eck:
(q eu não tenho)
segue então uma imagem mais completa do código pra dar mais contexto:
Esse código aí eu escrevi com base nas observações e conclusões que descrevi ontem/hoje aqui
É claro que o tempo todo eu olho pra código de outros drivers para aprender como se faz e para escrever de forma similar.
Werner Eck:
poutz... desculpa parecer chato, mas esse ps aí é ilegível... 😔
clica na imagem pra ver maior
Werner Eck:
eu até abri numa janela do browser, mas fica minúsculo mesmo assim. Dando zoom fica pixelado
eita!
vamos focar mais então:
são 5 operações de escrita na porta $21
os bytes são escritos nessa sequencia: 7A, 37, 40, X, 37
onde X é um de 3 valores possíveis (escolhidos em função dos bits lidos da porta $00 - dispwitch?): 7a, 4e ou 5a
vou agora olhar pro datasheet do chip de UART pra ver o que esses comandos significam
Werner Eck:
ah, então o 7A/37/40 são escritos sequencialmente na porta, só os 7a/4e/5a é q são selecionáveis nas dips?
isso!
Werner Eck:
na verdade, só os dois últimos...
Werner Eck:
perceba como o 7a se repete
Werner Eck:
tenho certeza disso...
Werner Eck:
o 7a é sempre escrito
o primeiro byte é 74
Werner Eck:
onde vc viu isso?
ah nao
é 7a mesmo
mal...
então... reiterando: os bytes são escritos nessa sequencia: 7A, 37, 40, X, 37 (com X = 7a, 4e ou 5a)
Werner Eck:
mas eu não vejo nenhuma instrução de branch direcionando para a linha 0x52.
Werner Eck:
só para as linhas 0x57 e 0x5c
Werner Eck:
caso ele não faça jump para essas linhas, ele executa a 52
Werner Eck:
é isso. Ele le as dips, se der algum setting lá ele executa o branch correspondente
Werner Eck:
se não der nada (0x00) então ele faz 0x7A e sai fora
Werner Eck:
e aí escreve 0x37 e na sequencia, lê da porta 0x50 - isso independente do q ele decidiu escrever anteriormente.
exato
a ultima escrita acontece em todos os casos
por que todas as condições pulam pra lá
então apenas o quarto byte é condicional
Werner Eck:
e vc já decodificou os parametros q ele seta nos valores 4e e 5a?
ainda não
estou vendo isso agora.
isso aqui é importante:
Werner Eck:
isso q eu tinha postado
ou seja, o primeiro byte, $7A, é com certeza uma "mode instruction"
o outro 7A talvez seja uma "command instruction" e aí pode ter uma interpretação diferente, apesar de ser o mesmo valor numérico
Werner Eck:
7A seria isso
Werner Eck:
figuras 8 e 10
meu cérebro dá nó nesses números... editei as mensagens anteriores para ficarem com o número certo
sim, vc tem razão é 7A
Werner Eck:
o q vc disse vai de encontro ao q eu falei tbm
Werner Eck:
e tá bem aí nessa seção q vc está lendo, uma ou duas páginas adiante
Werner Eck:
os detalhes de cada bit dependendo de como vc quer setar o modo
perfeito
acho que sua análise está perfeita
Werner Eck:
eu to devagar, pegando novamente o jeito
Werner Eck:
nunca escrevi assembler do mcs-80
(eu tirei umas duas horas de cochilo durante a tarde hoje e já não lembrava mais de nada :-D)
Werner Eck:
mas escrevi do z-80
Werner Eck:
e isso já faz 23 anos... rs
(não lembrava mais dos comentários que você tinha feito mais cedo hoje à uma da tarde)
Werner Eck:
não esquenta Juca
Werner Eck:
Tamo junto nesse projeto
claro
Werner Eck:
(na medida em q eu ajudar mais e atrapalhar menos)
é que eu vi que eu to explicando o que você já explicou hahahahah
sabe aquele lance que eu te falei sobre tipicamente ser usado o bit A0 do barramento de endereços para chavear entre duas portas de I/O dos periféricos ? Por exemplo portas 0x20 para dados e 0x21 para comandos
Na prática é implementado usando esse sinal C ou /D:
o sinal A0 da CPU é ligado a esse seletor Control/Data
Vou sair agora e volto daqui 1 hora. Té mais
mas fica uma observação:
acho que só deve ter sobrado a porta de I/O 0x50 sendo manipulada pelo firmware
e não sei ainda o que ela é
então suspeito que possa ser relacionada à leitura do teclado talvez. Alguém tem que fazer isso em algum momento. Só não sei se é tão cedo no setup ou se ós vai ser feita a varredura do teclado mais pra frente
té mais
Werner Eck:
Eu imagino q o teclado seja constantemente lido
Werner Eck:
Daí, se ele estiver mapeado no &0x50, provavelmente ele deve aparecer em algum momento dentro de um loop.
pode ser lido em rotina de interrupção também
Werner Eck:
daí é só ver nos endereços específicos q o processador olha...
eu mapeei o chip I8251 nas portas 0x20 e 0x21 e declarei que o hardware possui uma porta serial e que os sinais da porta estão ligados ao chip 8251:
E aquela linha MCFG_RS232_PORT_ADD("rs232", default_rs232_devices, nullptr) significa que é uma porta onde os dispositivos seriais típicos podem ser ligados ( default_rs232_devices é uma lista de periféricos seriais) e que por padrão o driver é inicializado sem nenhum periférico conectado nesa porta (por isso o nullptr ali)
com isso, aparece no menu interno da interface do MAME uma opção para configurar a porta serial:
No submetu "Slot Devices" tem rs232
e veja que está inicialmente sem nenhum periférico instalado na porta
mas posso selecionar algumas opções como "printer", "null_modem", "pty", "keyboard", "loopback", "terminal"
Werner Eck:
Seria como dizer, o terminal seria inicializado por padrão sem nenhum periférico plugado na interface serial
dessas, a opãço "pty" é interessante pois supostamente permitiria criar um par mestre/escravo de pseudo terminais do unix
Werner Eck:
E vc seleciona um periférico pelo MAME
e com isso talvez seja possível eu configurar meu sistema hospedeito (GNU+Linux) para abrir uma sessão de login no terminal emulado e forma similar ao que acontece com programas emuladores de terminal vt-100 como o xterm ou o gnome-terminal
Werner Eck:
Existe dentro dessas opções, alguma q permita mapear a própria serial do host rodando MAME como periférico virtual?
Werner Eck:
daí permitindo conectar um dispositivo real via serial ao emulador?
hmmm... isso seria interessante também
mas o que eu tenho em mente é fazer tudo virtual: processos do meu GNU+Linux vinculados a um pseudo-terminal criado pelo MAME com a interface rs232 emulada do terminal da scopus
Werner Eck:
E essa nossa implementação da rs232 está pronta?
Werner Eck:
digo, no terminal Sagitta
eu não sei como se configura um pseudo-terminal para abrir uma sessão de login no GNU+Linux, etão esse caminho via pty eu vou deixar pra investigar depois.
antes disso, testei outra coisa:
essa opção instancia um terminal serial genérico e liga ele na porta do sagitta emulado
Werner Eck:
e na outra ponta o q vc obtém?
ao resetar, aparece isso aqui:
veja que a metade da janela do lado esquerdo é a tela de um terminal genérico
e o lado direito é a tela do sagitta emulado
aí supostamente eu poderia digitar em um e ver os caracteres aparecendo no outro
Werner Eck:
(tá borrado, mas dá pra ver esquerda vs direita)
Werner Eck:
supostamente ou realmente? rss
quando eu digito não acontece nada
mas o MAME tem um submenu para configuração do terminal genérico
veja aqui:
Werner Eck:
vc implementou as dips?
declarei os dipswitches com valor default 0 nos dois bits
Werner Eck:
cara eu acho q tem q ser 7 data bits, parity enabled, 1bit
Werner Eck:
por causa daquele byte 0x7a
Werner Eck:
suponho q ele esteja default nisso
então eu liguei o Local echo e pelo menos o terminal genérico mostra o que eu to digitando nele
e agora preciso fazer isso que você tá falando mesmo: configurar o terminal genérico com os mesmos ajustes do terminal sagitta emulado pra ver se a emulação está funcionando
Werner Eck:
quanto à taxa de transmissão, estou incerto, pois no DS do chip ele explica q fica setado em "16x"
Werner Eck:
vc provavelmente tbm terá q experimentar com diversos baud rates diferentes.
Werner Eck:
eu começaria pelo mais baixo... afinal, eram os anos 70.
eu acho que o caminho é interpretar todos os bytes de setup que o firmware escreve na porta 0x21 e assim ter a certeza de qual é o ajuste que o firmware faz, portanto restringindo a quantidade de chutes necessários. Teoricamente não deveria ser necessário chutar nada.
Werner Eck:
deixa eu ver aqui
os bytes são escritos nessa sequencia: 7A, 37, 40, X, 37 (com X = 7a, 4e ou 5a)
Werner Eck:
acho q de cara o 37 é invalido para mode... começa escrevendo 2 zeros
Werner Eck:
corrigindo, pode ser q esteja setando para modo sincrono
Werner Eck:
deixa ler aqui
estou lendo também
volto daqui a pouco
Não é exatamente a técnica usada aqui, mas parece que algo similar está acontecendo:
então no nosso caso temos mode:7a command:37 seguido de comand:40(RESET) e mode:X command:37
Werner Eck:
que parece ser o q o byte 0x40 faz
Werner Eck:
para de ler pensamento cara
hehe
Werner Eck:
eu acabei de decodificar ele
Werner Eck:
concordo q 37 deve ser command
então vejamos quais informações de paridade, stop bits, start bits, baud-rate, etc que conseguimos extrair do mode:7a (e dos outros modes possíveis: 4e ou 5a)
e depois vejamos o que o command:37 faz
Werner Eck:
0x7A=01 11 10 10: (modo assíncrono) 1 stop bit; paridade: habilitada, par; compr. palavra: 7 bits; fator baud rate: 16x
Werner Eck:
modo 0x4e me parece ser assincrono tbm...
Werner Eck:
estou lendo agora
Werner Eck:
0x4E=01 00 11 10: (modo assíncrono) 1 stop bit; paridade: desabilitada, ímpar; compr. palavra: 8 bits; fator baud rate: 16x
Werner Eck:
0x5A=01 01 10 10: (modo assíncrono) 1 stop bit; paridade: habilitada, ímpar; compr. palavra: 7 bits; fator baud rate: 16x
Werner Eck:
são singelas diferenças no comprimento da palavra e paridade
Werner Eck:
mas é certo q está setando o USART em modo assíncrono sempre
Werner Eck:
agora os command word
Werner Eck:
0x37=00 11 01 11: (command instruction): X (irrelevante - chip em assíncrono e modo command); RTS=0, PE=OE=FE=reset; normal operation (TxD=high), receive enable=1; DTR=0, transmit enable=1
Werner Eck:
acho q é isso
Werner Eck:
pizza chegou, tá servido?
hahaha, não obrigado
Werner Eck:
domingo, nada melhor q pizza + cerveja e debugging de ROM
receive enable=1; junto com transmit enable=1 significa que ele está pronto a fazer ambos
não sei se o terminal vai fazer algo com os dados entranto
Werner Eck:
o negócio agora é testar as combinações possíveis
talvez nesse momento inicial o operador precise fazer algo pra ativar o funcionamento (sair dessa tela de boot, esse splash screen com o nome do modelo no meio: "Sagitta 150 versao 4.00")
Werner Eck:
pode ser... tem o manual do usuário?
nope
Werner Eck:
outra coisa, vc podia tentar forçar ele a carregar a ROM 0?
peraí... nunca procurei hahaha
Werner Eck:
pizza, volto em instantes
Werner Eck:
ou não.. rsss
eu tive que adicionar ao driver uma fonte de sinal de clock para /TxC e /RxC
a frequencia que eu usei foi chutada (copiada de outro driver)
aí com isso eu configurei o terminal genérico com 1200 baud
e o terminal sagitta começou a responder aos caracteres enviados pelo terminal genérico
Werner Eck:
CARAAAAAALHOOOOO!!!
Werner Eck:
Tá funcionando o terminal!!!
:-)
Werner Eck:
se conseguissemos emular uma porta serial mapeando pra um host ethernet, já pensou??
falta ainda emular o teclado do sagitta
que deve ser relacionado àquela porta 0x50
e, sim, seria muito legal ligar esse sagitta emulado em alguma coisa moderna
Werner Eck:
vc disse q pegou um CI que estava conectado ao teclado do sagitta, não?
eu provavelmente vou depois tentar aprender como se faz o setup de sessão de login do GNU+Linux via pseudo-terminal
Werner Eck:
verdade, fazer o sagitta mandar caracteres pra um terminal via ethernet
não... era a ROM do gerador de catacteres e o próprio CRTC que estavam escondidos debaixo do painel metálico do teclado
Werner Eck:
por exemplo, uma maquina emulando um host ibm
Werner Eck:
e o circuito do teclado?
ah sim! O próprio MAME pode emular máquinas que trabalham com terminais seriais
eu não estudei o circuito do teclado lá na usp
e existe sim a possibilidade de ter algum circuito integrado adicional que eu não vi, por que uma parte da pcb ainda ficou encoberta por uma outra chapa metálica
Werner Eck:
blz, isso fica pra próxima etapa
mas talvez dê pra inferir isso s'por análise do firmware como fizemos até agora mesmo
agora eu vou sair (vou no cinema assistir o novo Blade Runner)
acho que por hoje é só
Werner Eck:
ow esse filme deve ser mto bom
Werner Eck:
blz - foi bom, rendeu bastante
Werner Eck:
Não esperava ver o sagitta emulado tão rápido
:-)
té mais
e Happy Hacking !
Com isso, agora o menu de config de dipswitches fica bonitinho, mostrando as opções existentes:
E essa aqui é uma forma melhor ainda de se fazer, usando as macros PORT_DIPLOCATION e PORT_DIPUNKNOWN_DIPLOC:
o resultado dessa alteração é que agora o MAME desenha um diagrama mostrando qual a posição de cada chavinha (dipswitches):
Eu quero preparar um cabo DB-25 <=> FTDI-USB
E também um cabo para ligar esses 3 pinos aí na tomada
E levar lá na USP pra tentar ligar esse terminal
inicilamente ver se ele mostra Sagitta 180 na tela assim que liga
e depois conectar nele via minicom pra ver qual é o baudrate correto (sabendo o baudrate, dá pra inferir qual é a frequencia de sinal de clock usada de fato para o TxC e o RxC)
Werner Eck:
Cara, ficou tão legal isso. Sugestão pra deixar os textos das dips com a mesma aparência, troque a string "parity disabled" por "no parity" (era assim q os manuais dos modems se referiam a esses parâmetros na época).
Werner Eck:
Será q esse cabo a gente não encontra pronto no mercado? Vou dar uma pesquisada
é possível...
Werner Eck:
Deixa eu procurar aqui
eu tenho um ftdi (serial / USB) mas ele não tem o conector DB-25, pensei em adaptar
Werner Eck:
É aquele q sai 4 fios de um lado pra vc espetar na placa?
já o cabo de alimentação elétrica acho que vai ter que ser preparado mesmo
Werner Eck:
4 ou 5 não lembro direito
GND, VCC, TX e RX
Werner Eck:
Cara se olhando a foto de trás do equipamento, parece um plug macho de energia padrão abnt?
parece plug "banana"
Werner Eck:
É da mesma grossura q os banana?
https://en.wikipedia.org/wiki/Banana_connectorBanana connector
A banana connector (commonly banana plug for the male, banana socket or banana jack for the female) is a single-wire (one conductor) electrical connector used for joining wires to equipment. The term 4 mm connector is also used, especially in Europe, although not all banana connectors will mate with 4 mm parts, and 2mm banana connectors exist. Various styles of banana plug contacts exist, all based on the concept of spring metal applying outward force into the unsprung cylindrical jack to produce a snug fit with good electrical conductivity. Common types include: a solid pin split legthwise and splayed slightly, a tip of four leaf springs, a cylinder with a single leaf spring on one side, a bundle of stiff wire, a central pin surrounded by a multiply-slitted cylinder with a central bulge, or simple sheet spring metal rolled into a nearly complete cylinder. The plugs are frequently used to terminate patch cords for electronic test equipment, while sheathed banana plugs are common on multimeter probe leads.
não sei dizer. Pela foto dá a impressao de que sim
Werner Eck:
Teria q ver. Pq o banana tem um diâmetro razoavelmente maior q um plug d tomadas
Werner Eck:
Daí teria q improvisar mais
ah! obviamente, antes de tentar ligar na tomada seria bom eu dar uma revisada nos capacitores pra ver se não tem algum estourado...
ou vazando
Werner Eck:
Se fosse o mesmo tipo de pino q nos plugues das tomadas macho, poderia se fazer algo usando um adaptador
que eu me lembre, os capacitores parecem bons. Nada chamou muito a minha atenção quando olhei semana passada
Werner Eck:
Cara, eu já te adianto, melhor seria trocar todos os caps da fonte de cara
Werner Eck:
O problema nem sempre é a aparência e sim o comportamento interno
Werner Eck:
Capacitores tendem a apresentar ESR com o passar do tempo. São sempre os primeiros componentes a se deteriorarem e apresentar falhas.
Werner Eck:
Depois de + d 40 anos, é certo q não vão estar mais dentro dos parâmetros.
ESR = resistencia equivalente em série?
Werner Eck:
E isso vc só consegue medir retirando o componente da placa
Werner Eck:
Daí eu te digo, mais fácil trocar logo
complicado isso... a vontade é de preservar o equipamento intacto sempre que possível
só fazer as alterações estritamente necessárias
Werner Eck:
Mas essas são...
e "alterações" no sentido de trocar peça por equivalente
Werner Eck:
Vc pode estourar a fonte se ligar ele assim
jamais modificar o circuito
Werner Eck:
Vai ser um baita estrago
é, eu imagino
Werner Eck:
Vc não estará modificando
Werner Eck:
Só reparando. Faz parte do processo.
sim, é verdade
faz sentido
Werner Eck:
Não é como pegar um fusca 66 original e trocar o carburador por injeção eletrônica
Werner Eck:
É como retirar o carburador, limpar por dentro e reinstalar
Werner Eck:
Só q capacitor a gente não tem como abrir.
Werner Eck:
Então trocamos por um novo. Vai ter a mesma aparência do original (talvez em um tamanho menor)
Werner Eck:
Não é tão crítico assim como vc está pensando q é.
Werner Eck:
E o Sagitta agradece.
pensando sobre o painel do Patinho Feio e como representar o output da TeleType...
Teoricamente dair pra ligar o terminal Sagitta no Painel réplica do Patinho Feio
Werner Eck:
mas vc fala sobre o real ou o emulado?
é funcionalmente equivalente a uma teletype (com teclado e saída na tela igual ao que sairia impresso no papel)
na réplica
Werner Eck:
só pra situar, estou falando em emular o PF implementando esse código:
https://github.com/wmoecke/PatinhoFeio_Arduinowmoecke/PatinhoFeio_Arduino
PatinhoFeio_Arduino - Arduino Code to emulate the Patinho Feio Computer and interface with a replica front-panel.
ligado ao terminal real
Werner Eck:
sim, acho legal. Só precisamos fazer a conecão real
Werner Eck:
ah o terminal real?
sim, emulador do pato rodando no arduino controlando chaves e luzes do painel ligado ao terminal sagitta de verdade
Werner Eck:
daí temos q ver se dá pra fazer ele funcionar sem muito trabalho
o arduino tem porta serial. É sossegadíssimo de fazer
só que não é portátil
Werner Eck:
minha única preocupação em usar o sagitta real é q talvez exija uma manutenção mais pesada
então um displayzinho simulando a saída na teletype pode ser uma opção mais compacta
Werner Eck:
foi o q eu pensei, e é sussa de implementar
Werner Eck:
até pq já tenho implementado, basta mudar a entrada serial
aí por questão de estética eu faria um segundo quadro, contendo uma fotografia duma teletype modelo ASR33 e, embutido no quadro, um display de texto com uma ou duas linhas de texto
Werner Eck:
hahaha q boa idéia!!
Werner Eck:
uma linha só pelo amor de Deus... rsss
só que esse aí é de 40 chars
a teletype acho que chegava a 72
então é uma aproximação apenas
o bom de ter mais de uma linha é que facilita da a sensação de rolagem do papel da teletype pulando de linha
fazendo scroll
e não tem input como na teletype. Apenas output
tem um programa relativamente grande do patinho feio chamado HEXAM
Werner Eck:
até pq dá pra inserir programas nele por chaves ou por fita perfurada, como vc chegou a fazer, não?
é um exemplo que vem a listagem completa no manual do assembler
e serve para manipular o conteúdo da memória
é uma espécie de monitor do sistema
e para opera-lo é necessário ter uma teletype, pra digitar os comandos e ver a saída
isso
algum tipo de simulação de uma interface de fita perfurada seria legal também
pensei até que um leitor de cartão SD poderia ser usado para abstrair o processo. Com cada cartão sendo uma fita individual
Werner Eck:
como foi q vc e o prof. adaptaram aquela leitora de fitas?
do ponto de vista tátil é meio tosco, mas é o melhor que imaginei até agora
o professor Guido Stolfi comprou um cebeçote de uma máquina antiga no eBay
e interfaceou
Werner Eck:
com o que exatamente?
fazer isso seria bem legal
com alguma placa de microcontrolador que ele prefere usar. Não sei dizer qual é. Ele não me contou os detalhes ainda.
Eu precisaria perguntar.
Werner Eck:
essa interface era com o seu PF emulado?
não
ele interfaceou com o computador dele apenas para fazer o dump dos dados das fitas
Werner Eck:
mas seria pela serial?
eu não sei exatamente o que ele fez
sei o que ele fez, mas não sei os detalhes técnicos da solução usada
Werner Eck:
então, eu pensei q se ele tiver já feito esse microcontrolador ler os dados das fitas e passar serialmente os bits, a gente poderia adaptar isso ao arduino.
sim, mas o mais difícil é a interface mecânica/ótica
Werner Eck:
que parece q ele já fez
o resto a gente refaz com os pés nas costas
Werner Eck:
por isso mesmo
entendi
Werner Eck:
a parte mais dureza parece q ele já fez
Werner Eck:
se apresentarmos o painel pronto, emulando no arduino e mostrando em um display, será q ele não se anima a conectar a leitora dele ao nosso PF?
acho que sim
Werner Eck:
até pq esse hardware deve estar encostado agora
ele já viu o painel não funcional. E também já viu o emulador do Pato no MAME. Acho que é só questão de jogar a idéia.
Werner Eck:
seria legal pra ele ver o hardware dele conversando com o nosso, e passando fitas de verdade pra o PF
Werner Eck:
vamos terminar esse painel
Werner Eck:
daí a gente mostra a coisa toda funcionando, deixamos ele brincar
Se não me engano, a interface de fita está na casa dele. Levar isso para exposição na USP seria bem legal.
Se ele topar.
ok, acho uma boa
Werner Eck:
e daí no meio da brincadeira, jogamos
Werner Eck:
"poutz, já pensou q legal seria se desse pra fazer a carga dos programas originais do PF em fita?"
as coisas aos poucos vão se alinhando. Acho muito legal essa idéia.
vamos trabalhar no painel então
Werner Eck:
lógico q ele iria dar aquele sorrisinho maroto
vou almoçar. Té mais!
Werner Eck:
depois a gente fala os detalhes disso
Werner Eck:
Eu acredito que "adaptar" seu cabo usb/ftdi em um conector DB25 não seja na prática, viável. Pois além dos TX/RX existem sinais de controle (DTR/DSR/RTS/CTS) que precisam de sinalização. Eu não sei quanto a se esses cabos prontos vêm com circuitos que adaptam esses sinais.
Werner Eck:
Exemplo de um cabo *conversor* (fornece todos os sinais de dados e controle) é esse:
https://www.comm5.com.br/produtos/conversor-usb/1S-USB/1S-USB - Comm5
Conversor de USB para 1 saída serial RS232 CARACTERÍSTICAS Atenta à necessidade de controle de todos os sinais disponíveis em uma porta serial nos periféricos envolvidos em uma automação, principalmente comercial, o conversor 1S-USB da Comm5 foi criado especialmente para atender esta carência de mercado. Sendo assim, sua compatibilidade abrange boa parte dos periféricos seriais […]
Werner Eck:
o problema é q esse modelo tem preço na faixa dos R$120~R$150, o q me faz erguer as sombracelhas, especialmente qdo vejo um anúncio assim:
http://bit.ly/2zhLT2DCabo Conversor USB X Serial DB9 e DB25
Aplicações - Conecta seu PC atual em mouses, scanners, impressoras e outros dispositvos que usem porta serial (COM). Compatibilidade - Suporta as especificações USB 1.1 e 2.0 - Compatível com todas as portas seriais comuns RS 232 (DB25 ou DB9) - Tamanho do cabo: 80 cm
Tela inicial do sagitta 180 com a ROM #0 carregada em vez da ROM supostamente herdada do 150:
a conexão com o terminal genérico não funciona com essa outra ROM, entratanto.
Talvez essa outra ROM espere receber alguma sinalização diferente pela serial. Talvez essa sim use algum protocolo específico dos computadores Burroughs, em vez de simplesmente enviar e receber raw ASCII.
Werner Eck:
ela tem uma série de parametros listados na tela
Werner Eck:
será q isso vem das dips?
Werner Eck:
especialmente interessante nesse caso é o "Atraso Interno do CTS"
Werner Eck:
vc só redirecionou o CS para essa ROM ao invés da primeira?
Werner Eck:
deu uma olhadinha se nessa ROM tem tbm as palavras de inicialização do 8251?
não posso ver isso agora
só carreguei a outra ROM e rodei o emu
por que do nada lembrei que era um teste óbvio que eu ainda não tinha feito. E, de fato, a recompensa foi imediata. Mas eu não posso dedicar tempo pra ver isso em mais detalhes agora.
você pode tentar fazer o seu setup de compilação do MAME aí no seu computador
Werner Eck:
eu ia ver com vc o q eu preciso ter aqui instalado
Werner Eck:
tem q ser no linux?
e fazer o checkout do branch sagitta180 do meu repositório
Não. Basta ter o git instalado
e depois instalar as dependências e tal
mas supostamente funciona em qualquer dos principais sistemas operacionais
Werner Eck:
compilador, essas coisas?
o MAME é multi-plataforma
Werner Eck:
o compilador é do próprio MAME?
Werner Eck:
ou tem q instalar o gtk, etc?
não. A gente usa o gcc
não precisa de gtk, mas precisa de outras bibliotecas
compilar o MAME por si só já é um grande aprendizado
Agora, uma coisa é verdade: não precisa ser no GNU+Linux. Mas eu, pessoalmente, recomendo fortemente que seja ;-)
Bom... vou voltar pro meu trampo aqui. Té mais
Werner Eck:
o único linux q eu tenho aqui é o Kali na VM
Werner Eck:
blz vou ver aqui o q eu consigo fazer
Werner Eck:
Werner Eck:
sou chique pra kct... até git já tenho
Werner Eck:
só pq eu gosto de vc, vou fazer no Kali.
Tá valendo :-)
você tem conta no github ?
ah é, verdade! Você mostrou um repo do Patinho Feio pra Arduino que você fez fork, verdade
agora lembrei
pode ser
vc pode fazer clone do mamedev/mame.git
ooops
clone não
fork
Werner Eck:
isso q eu ia falar
faz um fork do repo principal
Werner Eck:
faço primeiro um fork do mamedev e depois dou checkout aqui
aí você clona localmente o seu
depois você adiciona o mamedev e o meu como remotes
Werner Eck:
agora vc falou grego
um "remote" nada mais é que uma referência para algum outro repositório git existente para um dado projeto
Werner Eck:
deixa eu ir la fazer as primeiras duas etapas
quando você clona localmente o seu, o git cria automaticamente um remote chamado "origin" apontanto do seu repo local para o seu repo remoto hospedado nos servidores do github
tanto é que logo depois de fazer o clone, você pode digitar o comando "git remote -v" (-v é pra ser "verboso" e te mostrar as URLs) e com isso você vai ver que "origin" consta lá com a URL do seu repo no github
mas depois você pode adicionar outros remotes
veja por exemplo o meu caso:
eu tenho esse monte de remotes cadastrados aí por que eu já colaborei com essas outras pessoas
o remote "ramiro" é de um outro brasileiro que também contribui código pro MAME
e eu costumo apelidar o repo principal de um projeto de "upstream"
e veja que no meu caso "origin" é o meu repo pessoal
Werner Eck:
pq sua maquina chama guaraná?
"gitlab" também é um repo pessoal meu só que hospedado no GitLab
por que eu posso :-)
Werner Eck:
então tá, esses nomes q tem à esquerda foi vc q deu
sim
Werner Eck:
e a finalidade de vc adicionar um remote seria qual?
o "origin" é dado automaticamente pelo cliente de git como um remote apontando para o repo de onde você fez o clone inicial
Werner Eck:
entendi. eu ainda estou clonando por isso não fiz nada ainda
é pra você poder fazer fetch desses repos pra sincronizar seu código com o código das outras pessoas
Werner Eck:
por exemplo... se você fizer uns commits seus e quiser contribuir, você vai fazer push pro seu repo pessoal lá do github, que é o remote "origin"
mas de tempos em tempos você vai querer atualizar o seu repo com os commits novos que os desenvolvedores do MAME fizeram recentemente, e para isso você vai ter que sincronizar com o remote "upstream"
então a primeira coisa que você pode fazer, que vai ser bem útil é:
Werner Eck:
tbm acho bom criar um remote do seu repo não?
e depois você pode também fazer:
Werner Eck:
daí eu posso fazer upstream direto pra vc
Werner Eck:
deixa ele terminar aqui... aposto como isso deve levar um tempo
é... é um repo bem grandão
e depois você provavelmente ainda vai gastar um bom tempo instalando as dependências pra conseguir compilar corretamente
minha dica é tentar compilar e ver onde falha
e com isso ir descobrindo quais bibliotecas ainda falta instalar
Werner Eck:
😒 pressinto dores de cabeça por vir
Werner Eck:
bom aqui nessa minha distro já vem com muita coisa pré-instalada... vamos ver
pra facilitar o seu build sugiro você começar fazendo um build "single-driver", pra evitar de ter que compilar o MAME inteiro desnecessariamente
como o zezinho e o sagitta ainda estão aguardando alguém fazer o merge dos respectivos pull requests, é mais fácil começar por algum driver meu que já esteja integrado no MAME como, por exemplo, o do CP-500 da semana passada
a linha de comando mágica para isso é:
make SUBTARGET=trs80_ SOURCES=src/mame/drivers/trs80.cpp REGENIE=1
se isso rolar aí você me avisa que a gente parte pro passo seguinte que é pegar os commits do meu remote com o código de emulação do sagitta
que envolve essa complexidade extra de lidar com remotes que você não conhecia ainda
Werner Eck:
ih, vc vai ver q tem muita coisa q eu desconheço sobre o git...
vamos um passo por vez que vai ser de boa ;-)
Werner Eck:
aquela magia negra q vc fez no garoa... me pede pra refazer...
hahaha
Werner Eck:
acabo com o seu repo e o do MAME numa tacada só
Werner Eck:
Até o Papai Nicola vai vir bater na porta da minha casa
o bom é que no git se alguém se ferrar é só você. Minha cópia do repo continua inteirinha na minha máquina :-)
o dano fica contido
Werner Eck:
Por isso eu SEMPRE zipo td antes de fazer qq coisa relacionada a git. Se zicar, eu sobrescrevo tudo com a cópia
Werner Eck:
Já passei por isso no git e jurei nunca mais deixar o git me ferrar
Eu já fiz coisas similares. Mas só quando resolve explorar alguma feature do git que eu não conheço direito ainda.
no dia a dia eu aprendi a confiar
por que já me acostumei com o uso básico e uma ou outra funcionalidade avançada.
Werner Eck:
Eu tinha problemas qdo um outro cara fazia commits e eu ainda não tinha dado push
Werner Eck:
imagina com 600 e tralala
Werner Eck:
vou precisar aprender a dar commit toda hora
não necessariamente
pra isso existe o rebase
por exemplo
(é uma das opções)
mas deixa esses detalhes pra depois
eu explico tudo com calma quando chegar a hora
Werner Eck:
estou me atendo aos primeiros passos
Werner Eck:
to sabendo q o professor q eu tenho agora manja bem do assunto
Werner Eck:
vai ser mais suave
Werner Eck:
e o clone ainda ta rolando
será que eu devo começar a cobrar a hora-aula ? LOL
(tô brincando)
Eu costumo seguir no meu dia-a-dia o conselho do ET Bilu: "Busquem conhecimento!"
Werner Eck:
Sempre fiz isso na vida.
Werner Eck:
Nunca pegaram na minha mãozinha pra me levar. Sempre foi apanhando
Werner Eck:
Mas sempre é bom qdo se tem alguém com experiencia e paciência por perto pra perguntar as coisas
Comigo foi a mesma coisa. Aprendi muita coisa como autodidata e apenas em algumas poucas ocasiões eu tive quem me ajudasse. Talvez por isso mesmo que eu tenho tanto gosto por passar adiante o conhecimento às outras pessoas. Acho que é por que eu senti na pele a falta de alguém me orientando quando eu era mais jovem.
Alguns exemplos de exceções foram o Ricardo Bittencourt, o Spy, o Marco dal Poz e o Lucas Villa Real. Esses foram caras que me ensinaram muita coisa boa!
Werner Eck:
eu valorizo cada pessoa q me ajudou na minha trilha. Não esqueço de nenhum até hj
E mais recentemente outras pessoas entraram nessa minha lista de "gurus", como o Luciano Ramalho e o DQ.
O Garoa Hacker Clube tem um poder de atrair essas pessoas boas, eu acho.
boas de bondade! Não apenas boas de técnica.
Werner Eck:
é q gente q se interessa por aprender fazendo, normalmente é gente do bem
Werner Eck:
pessoal q não tem preguiça de cair em cima de um negócio pra se aprofundar naquilo
yep!
esse é o espírito
vide nossos ultimos 4 ou 5 dias em cima desse terminal serial da Scopus
(e o Zezinho)
Werner Eck:
pois é exatamente isso. A gente se deu bem logo de cara pq eu senti essa facilidade de chegar e entrar de sola dando palpites e vc corrigindo
Werner Eck:
(e saber ouvir tbm é essencial)
Werner Eck:
a gente só aprende coisas novas se souber escutar o outro lado. Tanto eu quanto vc fomos ninjas nisso.
Werner Eck:
por isso a coisa flui tão naturalmente
Às vezes eu sou um pouco arrogante. Aconteceu de você falar a coisa certa e eu ignorar achando que tava errado. Mas um pouco depois me toquei. Eu tenho treinado ultimamente isso. Aprender a escutar melhor as pessoas.
Quando eu percebo que estou sendo um pouco arrogante eu fico com vergonha. E acho que é bom. Por que é um mecanismo bom pra eu evitar de fazer isso e me auto-policiar.
Werner Eck:
só de vc falar isso já é sinal de q vc tem caráter.
Werner Eck:
ninguém é santo
bom... chega de sessão de terapia
hahaha
Werner Eck:
👍 de vez em qdo faz bem.
Werner Eck:
nada dito aqui poderá nem será usado contra vc
Werner Eck:
pqp tá td lá, até ontem.
Werner Eck:
ow vc assistiu o Blade Runner?
e estará todo o resto também
Assisti sim. Não me impressionou. Mas prefiro não bater papo sobre isso aqui nesse grupo ;-)
Manter o foco é bom
Para off-topics como esse pode me chamar em pvt
Werner Eck:
tem um negócio pra te perguntar off mas não é sobre o filme.
ok. Segue aqui um script para concatenar páginas escaneadas de documentos em alta resolução, comprimindo e gerando um PDF lowres de tamanho razoável:
Isso foi usado no processo de digitalização de vários dos documentos relacionados ao Patinho Feio
nitidamente o script não é genérico e foi editado caso a caso em função das necessidades de cada iniciativa de escaneamento
não é a ferramenta universal, mas é um ponto de partida pra se fazer esse tipo de manipulação de imagens
