Consertando o teclado do TK90

April 22, 2015, 8:10 pm

Recentemente tirei meu TK90X da caixa e coloquei ele de volta na bancada para auxiliar num projeto. Infelizmente a membrana de teclado estava com mau contato 1cm acima do ponto onde se encaixa no conector que vai à via de dados. A solução foi fazer uma extensão com fio paralelo, semelhante ao que já tinha feito para o outro conector (que vai às vias de endereço).

Seguem as fotos:

Conector original foi removido

No lugar foi instalado um conector fêmea de 5 pinos

O conector original foi soldado a um cabo paralelo. Esta soldagem é delicada porque se o pino sobreaquecer pode danificar o conector. A melhor maneira de fazer isso é estanhar rapidamente cada pino, deixando um pouquinho de solda no pino. Em seguida encosta-se o fio (já estanhado da mesma maneira) no pino e só então se aplica o ferro de solda, somente o tempo necessário para a solda derreter e unir o fio ao pino. É preciso ter a mão firme para fazer isso.

Conector original soldado a um cabo paralelo.

Os espaguetes são essenciais para evitar curtos no interior do TK

O acetato foi cortado 1cm acima do ponto de contato anterior.

↧

Capa de monitor

April 24, 2015, 10:03 pm

≫ Next: Placa Adaptadora de barramentos CP200-TK85

≪ Previous: Consertando o teclado do TK90

Adquiri recentemente um monitor Samsung 510n e fiz uma capa para ele utilizando uma sacola plástica que eu ganhei há algum tempo atrás numa visita à AFA.

Para fazer a capa eu cortei a parte de baixo da sacola com um estilete, e emendei a parte de cima usando o ferro de solda e uma régua metálica como guia (*).

Eis o resultado:

↧

Placa Adaptadora de barramentos CP200-TK85

April 25, 2015, 7:04 pm

≫ Next: Tic Tac X

≪ Previous: Capa de monitor

Trabalhei um pouco no layout da placa, para limpar a bagunça feita pelo autorouter e engrossar as trilhas de alimentação.

Aproveitei e inseri os seguintes recursos:

Botão de reset que fica apontado para o usuário
Trilhas de configuração para a posição do sinal /RAMCS para facilitar a modificação na placa do CP200 versão Spock
Pontos de medição dos sinais +5V e +9V

Também subi o projeto para o OSH Park (link). A placa ficou com as dimensões de 40mm x 64,5mm.

↧

Tic Tac X

April 27, 2015, 8:43 pm

≫ Next: TK85 num monitor RGB

≪ Previous: Placa Adaptadora de barramentos CP200-TK85

Este projeto começou há alguns meses atrás, precisamente em 31/12/2014, como um passatempo em meu último dia de férias.

Eu havia ouvido falar de alguns falsos positivos/negativos em monitores testados usando os TIC TACs do Victor e do Luciano e fiquei pensando comigo mesmo se tais falsos resultados não seriam devidos ao sinais de vídeo dos micros antigos serem meio fora do padrão, o que poderia confundir os circuitos dos monitores modernos, apesar de funcionarem bem nas velhas TVs e monitores.

Decidi então fazer um circuito gerador de vídeo com as seguintes características:

Capaz de gerar sinais com a temporização idêntica à dos MSX1, MSX2 e TK90X
Que gerasse sincronismo composto, separado e sincronismo no verde
Que gerasse os sinais sinais com amplitude e impedância corretas
Fácil de operar
Que se desligasse sozinho para economizar bateria
Pequeno, para poder caber numa caixa de Tic Tac
Que a placa fosse face simples
Que utilizasse um microcontrolador fácil de ser encontrado.

Comecei as experiências com um código em assembly para o AVR, pois eu já havia mexido na geração de vídeo com esses microcontroladores. O código foi ficando cada vez mais e mais complexo porque era baseado em interrupções e era meio chato ficar contando os ciclos.

Resolvi então partir do zero e escolhi desta vez usar um PIC. Eu tinha aqui em casa alguns 16F688 que eu ainda tinha aqui de sobra do lote de TKChucks que montei e um 16F648 e assim iniciei meus experimentos com ambos.

Como o circuito com AVR era baseado em interrupções, eu comecei a fazer o meu código assim também mas logo vi que com o PIC isso seria muito complicado, pois mesmo a 20MHz o 'overhead' gerado pelo código das interrupções estava atrapalhando muito.

Daí lembrei do artigo do Victor sobre o Tic Tac Blue onde ele comenta que fez o Tic Tac dele contando ciclo a ciclo. Dei uma relida no artigo e fiquei encucado com uma coisa: Em determinado momento o Victor comenta que o circuito dele gerava uns artefatos porque entre fechar um loop e abrir outro ele perdia alguns ciclos de clock.

Fiz algumas experiências no MPLAB e me deparei com o mesmo problema. Gastei um tempinho resolvendo o problema até chegar numa temporização totalmente equalizada, mas isso é coisa para um outro artigo. Fiz um loop principal para gerar vídeo VGA e fiquei animado porque funcionou logo de cara.

Primeira imagem gerada: VGA 640x480 @ 60Hz

Em seguida passei a estudar os sinais dos microcomputadores. Para o MSX1 e MSX2 eu pude contar com a documentação disponível, além é claro de fazer algumas medidas aqui em um de meus HotBits. Já para o TK90X eu tive que capturar as formas de onda da ULA e analisar. Mais detalhes estão num artigo que escrevi sobre o assunto (link).

O próximo passo foi estudar a geração dos sinais com amplitude e impedância corretos, ou seja R,G,B a 0,7Vpp @ 75Ohms. Isso requereu um pouco de matemática mas nada muito complicado. Um pouco de leitura e alguns exercícios já foram suficientes para resolver a questão e ainda rendeu outro artigo (link).

Dado que seriam 19 modos de operação possíveis (3 computadores x 3 modos de sincronismo x 2 frequências verticais mais o modo VGA), descartei o uso de LEDs ou de jumpers de configuração.

Daí resolvi a coisa da seguinte maneira:

Após power up: O circuito inicia em modo VGA, para testar se tudo está ok (cabo, bateria, etc)
Daí a cada toque no botão o circuito muda de modo:

1. VGA

2. MSX 1 Sincronismo composto, borda branca, faixa central amarela
3. MSX 1 Sincronismo separado, borda branca, faixa central branca
4. MSX 1 Sincronismo no verde, borda branca, faixa central verde

5. MSX 2 Sincronismo composto, borda preta, faixa central amarela
6. MSX 2 Sincronismo separado, borda preta, faixa central branca
7. MSX 2 Sincronismo no verde, borda preta, faixa central verde

8. TK90X Sincronismo composto, borda branca, faixa central amarela
9. TK90X Sincronismo separado, borda branca, faixa central branca
10.TK90X Sincronismo no verde, borda branca, faixa central verde

retorna ao VGA

Todos os modos acima a 60Hz. Para a seleção 60/50Hz - Através de um jumper de solda na placa, mas estou cogitando trocar para a detecção do estado do botão quando o circuito é energizado. Antes disso eu preciso checar se os modos de 50Hz estão operacionais pois não tenho nenhum monitor que suporte 50Hz.

Após um minuto sem operação o equipamento entra em standby, para economizar bateria, e isso é extremamente importante pois o circuito drena bastante corrente, considerando as baterias que ele usa e os resistores de polarização para manter o casamento de impedância do sinal. Ainda que no modo de standby o consumo seja reduzido pela entrada no modo sleep e pelo desligamento dos pinos que ativam os resistores de polarização é sempre bom deixar o circuito sem o jumper de alimentação.

Modo MSX1, sincronismo composto num dos primeiros testes

Ainda não satisfeito com essa maneira de exibir os modos resolvi escrever na tela o modo usando gráficos rudimentares. Alguns estudos que fiz descartaram a possibilidade de se utilizar uma rotina de geração de caracteres, pois isso tomaria um tempo logo demais limitando muito a quantidade de informações na tela (e demandando várias linhas de altura para os caracteres). A solução foi desenhar cada elemento pixel a pixel.

Pixels no OpenOffice

Criei uma planilha no OpenOffice onde a cor da célula dependia do valor. Se fosse 1 a célula seria preta, se fosse zero, branca. Depois salvei cada linha da sequencia e transformei numa sequências de zeros e uns. Aí então num editor de texto cada "1" foi substituído por uma sequência de instruções e cada zero por outra.
Dessa forma, os gráficos gerados pixel a pixel aparecem na tela para indicar a máquina, o modo de sincronismo e a frequência de operação.

O mesmo modo da foto anterior, agora com 'gráficos'.

A placa de circuito impresso foi outro item extensamente trabalhado. Esqueci de mencionar mas o mesmo código pode ser compilado para o 16F688 e para o 16F648 (sem os caracteres 'gráficos' o código cabe até 16F628). Por conta disso gerei versões de placa para ambos os microcontroladores.

Da primeira versão, com componentes padrão do Eagle passando por várias melhorias para remover os jumpers foram 7 versões para o 16F688 e 5 versões para o 16F648,

Versões da placa para o 16F688

Versões da placa para o 16F628/648.

Além das placas nas figuras acima existe uma última revisão (ainda sem protótipos) que foi necessária por causa do clip da bateria.
Infelizmente eu não tinha notado, até construir os primeiros protótipos, que clip que utilizei faz contato com os terminais positivos de ambas as baterias pela lateral isso gera um curto na célula de cima. O Clip correto prende as baterias pelo alto mas infelizmente tem um 'footprint' diferente.

Protótipo (PIC16F688). A fita adesiva para é para evitar curto nas baterias

placa ficou de tal dimensão que o corpo do conector fica rente à boca da caixinha de Tic Tac, o que a mantém firme dentro da caixa

Protótipo na caixa de Tic Tac

O vídeo abaixo mostra o funcionamento do protótipo:

↧

TK85 num monitor RGB

May 6, 2015, 9:53 pm

≫ Next: Placa do adaptador RGB Kolour

≪ Previous: Tic Tac X

Recentemente adquiri um par de monitores Syncmaster 510n para utilizar com meus micros antigos. Como esses monitores aceitam vídeo em 15KHz era mais do que natural que eu pensasse em conectar o TK-85 nele.

Analisando as especificações do monitor, ele aceita vídeo em RGB com amplitude de 0,7Vpp e sincronismo positivo ou negativo em nível TTL.

Tomando por base estas especificações a adaptação é muito simples, pois o TK-85 possui internamente os sinais de vídeo e de sincronismo composto. Sendo assim a única adaptação necessária seria baixar a amplitude do sinal de vídeo para 0,7Vpp, coisa que se faz com um par de resistores, e jogar este sinal em uma das cores primárias do monitor, por exemplo o verde, ficando assim a tela verde com caracteres em preto.

Também é possível ligar o sinal de vídeo em mais de uma componente de cor e ter até 7 cores de fundo diferentes, e caracteres em preto.

A próxima idéia que surgiu foi utilizar o nível do sinal de vídeo para selecionar duas entre 8 cores diferentes para frente e para fundo. Isso pode ser feito através de um multiplexador 74LS157.

Só que.. nem tudo é tão simples como parece....

Pra começar tive que consertar o TK85, que apresentava um defeito intermitente. Depois de horas de osciloscópio em cima do circuito, analisando vários sinais surge uma primeira pista... Um mau contato na conexão da linha A12 no soquete do Z80.

Soquete original e o Z80

Placa vista por baixo, após troca do soquete

Placa vista por cima, após troca do soquete.

Feita a troca, o circuito funcionou corretamente por alguns instantes e depois deu problema de novo. Dessa vez não era nada com o Z80. Daí comecei a desconfiar do soquete das Eproms, uma vez que este soquete também tem a mesma qualidade (e idade) do soquete da CPU. Removi as Eproms do soquete e inseri novamente, apertando bem dessa vez, daí o circuito funcionava legal (eu ainda estava sem monitor, acompanhando o sinal pelo osciloscópio.

Resolvi então trocar o soquete das Eproms... Pra variar não tinha um soquete de 24 pinos, então tive que improvisar com um de 28, tirando 2 pinos na parte de cima e dois na parte de baixo e cortando o plástico excedente. Eu não tirei os 4 pinos de um lado só porque senão o soquete ia ficar fragilizado.

Soquete original das Eproms principais removido

Placa após solda do novo soquete

Novo soquete das Eproms. Nem parece ter sido modificado :)

Após a troca o TK parou de apresentar problema, mostrando o vídeo sempre que o micro é ligado.

Pois bem, TK consertado, espero que dessa vez pra valer, soldei alguns fios no IC20 (74LS86), pois neste CI estão conectados tanto o sinal de vídeo quanto o de sincronismo, além é claro da alimentação para o multiplexador.

Sincronismo no pino 3, vídeo no pino 6 de IC20 (74LS86)

O sinal de vídeo está disponível no pino 6 e o sinal de sincronismo no pino 3 de IC20 (74LS86).

Pontos para pegar os sinais de vídeo e sincronismo no TK85

Circuito ligado, monitor ligado, liga o TK-85 e.... problema... O circuito só funcionava bem se o fundo fosse preto. Caso fosse de qualquer outra cor a imagem ficava muito escurecida e somente dá para ver alguma coisa nas linhas que possuem caracteres.

Pensando um pouco no assunto cheguei à conclusão, que era mais ou menos óbvia, uma vez que esse tipo de imagem já é manjado pra quem tem mod de vídeo composto no TK85. O problema era a Falta de backporch!!!

E eu que já estava na esperança de conseguir enfiar o circuito inteiro do 'colorizador' dentro do espaço da caixa de RF do TK85 comecei a ficar preocupado, pois precisava de um CI a mais, mas não queria colocar um CI a mais no circuito.

A solução para esse impasse apontava para utilizar o próprio LS157 ou o TK85 para gerar o backporch. (para quem conhece Triz a solução saiu pela lei da idealidade)

Mas se a solução era conhecida, como implementá-la?

Analisando os recursos disponíveis existem algumas portas lógicas não utilizadas dentro do TK85 que poderiam ser utilizadas, ou talvez desse para implementar o backporch usando o próprio LS86, só que não queria mexer muito no circuito do TK.

Já no Ls157 estavam disponíveis 2 entradas, 1 saída e um sinal de Enable que estava sempre ativo, e foi justo este sinal que me permitiu implementar o backporch, usando uma rede RC e um diodo, de forma bem semelhante ao já utilizado no Mod de vídeo do Victor:

Gerador de Backporch implementado no LS157

Como o monitor pode operar tanto com sincronismo positivo quanto negativo, foi utilizado o sincronismo positivo, pois durante e após alguns microssegundos a partir do final do pulso de sincronismo a imagem tem que estar em seu nível de pedestal para o monitor amostrar a imagem corretamente.

Quando um pulso de sincronismo aparece ele faz com que a tensão sobre o capacitor se torne praticamente 0,6Volts que é basicamente a queda no diodo, ou seja, o início do pulso de sincronismo descarrega o capacitor. Como a tensão nos terminais do capacitor é baixa isso faz com que o sinal /OE vá a nível alto, desativando a saída, que cai instantaneamente ao zero devido ao divisor de tensão nas saídas do LS157.

Assim que o pulso de sincronismo cai a zero, o capacitor começa a se carregar através do resistor, de forma que a tensão no pino /OE começa a cair até o limiar em que o LS157 entende como nível zero, ativando então a saída, trazendo-a ao nível correto. Com os valores utilizados (1nf/10K) e um circuito integrado da família LS, o tempo de backporch foi de 7,2us após o final do sinal de sincronismo.

Amarelo: Sincronismo / Azul: backporch no sinal de vídeo da componente verde G

Após a implementação do backporch a imagem ficou como se esperava:

Imagem com a geração de backporch

Daí deu para brincar com as cores.

Programa de teste.

Ajuste para agradar os usuários de CP200

Ajuste para agradar os usuários de CP300/TRS-80

Ajuste para agradar quem gosta de tomar Coca Cola

Agora para os usuários de HotBit (meu preferido)

Também tem ajuste para os usuários de CP-400

Tem até ajuste para as meninas!

O diagrama do circuito, que foi batizado de Kolour, encontra-se abaixo. O Objetivo agora é colocar tudo dentro de uma placa que possa ser instalada no lugar do modulador de RF.

Aos curiosos uma foto do protótipo:

E uma visão geral do setup de testes sobre a bancada:

↧

Placa do adaptador RGB Kolour

May 11, 2015, 4:11 pm

≫ Next: Temporização do código na geração de réplicas dos sinais de vídeo do TK90, MSX1 e MSX2

≪ Previous: TK85 num monitor RGB

Finalmente terminei de rotear a placa do Kolour. Deu um pouco de trabalho pois queria manter ela em face simples, a fim de ficar fácil de montar um protótipo:

Placa em face simples para facilitar a montagem

Eu substituí as chavinhas dip que são relativamente caras e difíceis de serem encontradas, por terminais para inserção de 'jumpers'.

O conector utilizado foi do tipo mini-din de 6 pinos, o mesmo usado nos teclados ps/2. Para ligar no monitor VGA é necessário um cabo de adaptação cuja pinagem encontra-se abaixo. Este conector permite a utilização da caixa do TK85 sem modificações.

Cabo adaptador para ligar no monitor VGA.

O diagrama final mudou um pouco por causa do roteamento mas ficou até mais fácil de ser entendido. As ligações aos pinos 14 e 13 do LS157 são para não deixar entradas do CI sem sinal conectado.

Circuito final

O paconte contendo os arquivos eagle encontra-se no seguinte link: (dropbox).

A placa também foi compartilhada no OSHPark (link)

↧

Temporização do código na geração de réplicas dos sinais de vídeo do TK90, MSX1 e MSX2

May 11, 2015, 4:33 pm

≫ Next: Ressucitando um TK85

≪ Previous: Placa do adaptador RGB Kolour

Este projeto começou há alguns meses atrás, precisamente em 31/12/2014, como um passatempo em meu último dia de férias.

Eu estava relendo o artigo do Victor sobre o Tic Tac Blue e em determinado momento ele comenta que o circuito dele gerava uns artefatos porque entre fechar um loop e abrir outro ele perdia alguns ciclos de clock.

O circuito é baseado num PIC16F688 rodando a 20MHz

Fiquei encucado com aquilo e na falta do que fazer comecei a brincar com o MPLAB. Nas primeiras experiências descartei a possibilidade de gerar vídeo por interrupções, mesmo a 20MHz. Para gerar vídeo, ainda mais em VGA tem que ser realmente contando ciclo a ciclo.

Então imaginei gerar cada parte do vídeo (sincronismo, bordas e vídeo ativo) com alguns loops. Mais ou menos algo assim:

video:

...
        movlw N_LINHAS
        movwf CONTA
_loop1:
        call GERA_LINHA
        decfsz CONTA,F
        goto _loop1
        movlw N_LINHAS
        movwf CONTA
_loop2:
        call GERA_LINHA
        decfsz CONTA,F
        goto _loop2
...
...
        goto video

De cara o problema já se apresentou: Entre o começo de um loop e o final do outro perdem-se 2 ciclos. Não sei se foi exatamente assim o problema que o Victor enfrentou, mas como havia dito eu queria alguma coisa para distrair a cabeça isso já serviu:

A primeira coisa quer fiz foi analisar o exato número de ciclos gastos.

video:

...
        movlw N_LINHAS     ; 1
        movwf CONTA        ; 1
_loop1:
        call GERA_LINHA    ; N 2 do call, x da linha, 2 do return
        decfsz CONTA,F     ; 1 o goto vira um nop quando pulado
        goto _loop1        ; 2 na iteração, 1 quando é pulado
        movlw N_LINHAS     ; 1
        movwf CONTA        ; 1
_loop2:
        call GERA_LINHA    ; N
        decfsz CONTA,F     ; 1
        goto _loop2        ; 2
...
...
        goto video

daí considerando as iterações:

video:

loop 1:
CONTA=4->N+1+2 ciclos
CONTA=3 N+1+2
CONTA=2 N+1+2
CONTA=1 N+1+2
CONTA=0 N+1+1+1
movlw    1 ciclo
movwf    1

loop 2:
CONTA=N_LINHAS    N+1+2
CONTA=N_LINHAS-1 N+1+2
...
...
CONTA=1 N+1+2
CONTA=0 N+1+1+1
...
goto video

Assim entre cada iteração temos N+3 ciclos e entre a última iteração do loop1 para a primeira iteração do loop2 temos N+5 ciclos.

Eu gastei algum tempo pensando em como poderia fazer para fazer para gastar o mesmo tempo entre a iteração e a passagem de um loop para o outro. Depois de algumas tentativas frustradas de colocar NOPs antes e depois dos loops, cheguei a uma solução que é muito simples:

Colocar o movlw dentro do loop!

Dessa forma:

video:

...
        movlw N_LINHAS     ; 1
        movwf CONTA        ; 1
_loop1:
        call GERA_LINHA    ; N 2 do call, x da linha, 2 do return
        movlw N_LINHAS     ; 1
        decfsz CONTA,F     ; 1 o goto vira um nop quando pulado
        goto _loop1        ; 2 na iteração, 1 quando é pulado

        movwf CONTA        ; 1
_loop2:
        call GERA_LINHA    ; N
        movlw N_LINHAS     ; 1

        decfsz CONTA,F     ; 1
        goto _loop2        ; 2 / 1
...
...
        goto video         ;2

Assim o tempo gasto nas iterações fica:

video:

loop 1:
...
CONTA=4 N+1+1+2
CONTA=3 N+1+1+2
CONTA=2 N+1+1+2
CONTA=1 N+1+1+2
CONTA=0 N+1+1+1
movwf    1

loop 2:
CONTA=N_LINHAS    N+1+1+2
CONTA=N_LINHAS-1 N+1+1+2
...
...
CONTA=1 N+1+1+2
CONTA=0 N+1+1+1
...
goto video 2

Daí temos um tempo entre cada iteração de N+1+1+2 ciclos e entre a última iteração do loop1 para a primeira iteração do loop2 temos N+1+1+1+1 ciclos, ambos resultando em N+4 ciclos!

Mas a coisa não pára por aí.... Ainda faltava resolver um último detalhe... o GOTO VIDEO no final consome 2 ciclos.O que fazer nesse caso?

A resposta para esse problema exigiu pensar um pouco mais. Quando estava quase desistindo veio a inspiração.

A última linha da tela teria que ser colocada fora do loop.

do_video:
        movlw N_LINHAS     ; 1 - valor inicial do primeiro loop
frame:
        movwf CONTA        ; 1
_loop1:
        call GERA_LINHA    ; N 2 do call, x da linha, 2 do return
        movlw N_LINHAS     ; 1
        decfsz CONTA,F     ; 1 o goto vira um nop quando pulado
        goto _loop1        ; 2 na iteração, 1 quando é pulado

        movwf CONTA        ; 1
_loop2:
        call GERA_LINHA    ; N
        movlw N_LINHAS     ; 1
        decfsz CONTA,F     ; 1
        goto _loop2        ; 2
...
...

        movwf CONTA        ; 1
_last_loop:
        call GERA_LINHA    ; N
        nop                ; 1 dummy, pois segue trecho sem iteração
        decfsz CONTA,F     ; 1
        goto _last_loop    ; 2


        nop                ; 1
_last_line:
        call GERA_LINHA    ; N   última linha
        movlw N_LINHAS    ; 1 quant. de linhas para o primeiro loop
        goto frame         ; 2

Desta forma, entre a última linha gerada e o retorno ao primeiro loop temos N+1+2+1 ou seja novamente N+4 ciclos.

Assim para gerar vídeo basta definir quantas linhas de de cada tipo serão geradas e criar as rotinas para preencer cada linha, lembrando de descontar 8 ciclos por linha equivalentes aos 4 gastos nas iterações mais 2 do CALL e mais 2 do RETURN.

A título de exemplo o frame para gerar o vídeo do TK90X, conforme as medições que eu descrevi num artigo anterior fica:

; TK90X ULA Frame
; N_LINHAS TIPO
;   1      Heq1
;   3      Vser
;   1      Heq2
; 20      Brancas
; 15(33) Borda topo NTSC(PAL)
; 92      Video ativo primeira metade (barras de cor)
;   8      texto
; 92      Video ativo segunda metade (barras de cor)
; 22(54) Borda de baixo NTSC(PAL)
;   7      Brancas
;   1      Branca, ultima linha
;-----
; 262 (312) linhas

↧

Ressucitando um TK85

May 12, 2015, 10:26 pm

≫ Next: Ressucitando um TK85 (2)

≪ Previous: Temporização do código na geração de réplicas dos sinais de vídeo do TK90, MSX1 e MSX2

Fiquei animado com a postagem do amigo Clóvis que deu um trato num TK85 dele e resolvi continuar o meu trabalho de ressucitação de um TK que achei na casa da minha mãe mas nem me lembro mais de onde ele veio nem como foi parar lá.

Esta placa estava em estado lastimável, faltando vários componentes, como o regulador de tensão, o dissipador de calor, o 555, os jaques, o modulador de RF o cristal, as memórias DRAM, os transistores, os conectores de teclado, a Eprom auxiliar, vários capacitores eletrolíticos. Além disso a placa tinha vários resistores quebrados.

Apesar disso tudo estar faltando, a placa estava em bom estado, e comecei a restaurá-la mais ou menos na época em que montei o Nestor, mas acabei deixando a restauração de lado por alguma razão (acho que foi esperando o cristal que comprei chegar) e acabei esquecendo dessa placa.

Só lembrei dela recentemente quando tive que pegar um TK-85 que estava guardado na mesma caixa que a placa para poder 'emprestar' o teclado ao TK90X.

Mas como disse, o post do Clóvis me animou e essa noite em vez de ir deitar resolvi mexer um pouco na plaquinha do TK.

No ponto onde parei a restauração eu já tinha colocado de volta os jaques (sobras do Nestor), o 555 e componentes associados, os transistores, os eletrolíticos e trocado uma porção de resistores quebrados.

Hoje instalei o 7805 e um dissipador de calor. Como não tinha um modelo nem de longe parecido coloquei um bonitinho que retirei de um conversor DC DC de placa mãe de PC, e isolei a placa com fita de Kapton para o dissipador não fechar nenhum curto.

Também achei mais um resistor quebrado (R74) e troquei o cristal. Ao energizar a placa infelizmente não tinha oscilação.

Durante o 'troubleshooting' acabei me deparando com um errinho no diagrama refeito do TK. Um dos lados do capacitor C1 estava ligado incorretamente (no diagrama) ao pino 8 de IC20 (LS86) em vez de estar ligado ao terra.

Engraçado é que coloquei um outro cristal em paralelo com o cristal de 6.5 e o circuito começou a oscilar.

Daí mexi um pouco no valor do capacitor de realimentação do oscilador, mas o circuito só oscilava, e de maneira bem instável, com a ponta de prova conectada a um pino do cristal.

Tirei o cristal e testei num oscilador que tenho aqui e para minha felicidade o cristal está normal, oscilando a 6,5 MHZ.

Daí refiz o circuito num protoboard e ele oscilou corretamente! Com isso desconfio que tenha algum problema nas conexões ou mesmo no LS86. Mas isso fica pro próximo post.

Seguem anexas algumas fotos.

Placa semi-restaurada. Foto do início de 2014

Cristal oscilador de 6,5MHz.

Foto de hoje, antes de eu começar a mexer novamente.

Dissipador de calor retirado de uma placa de PC. Fiz um furo na lateral para prender o regulador.

Regulador com pasta térmica já preso ao dissipador.

Regulador de tensão já soldado na placa. Detalhe do 555, capacitores e zeners novos.

Placa já com o regulador, o dissipador de calor, as memórias RAM e o cristal reinstalados.

Mais um resistor que estava quebrado foi substituído.

↧

Ressucitando um TK85 (2)

May 13, 2015, 10:02 pm

≫ Next: Documentação do teclado LABO

≪ Previous: Ressucitando um TK85

Continuando com a pesquisa de defeitos do artigo de ontem...

O oscilador a cristal estava funcionando de forma aleatória e somente quando a ponta de prova estava em cima do cristal (eu monitorava ao mesmo tempo os sinais dos pinos 11 e 12).

Como o cristal é 'filho único' eu precisava verificar se ele estava bom. Então repliquei o oscilador do TK85 num proto-board e o circuito oscilou a 6,5MHz como esperado provando que o cristal estava em ordem.

Oscilador do TK85 replicado no proto-board e funcionandoa 6.5MHz

Oscilador do TK85

Restava testar as conexões da placa, coisa que fiz com o multímetro na escala de continuidade. Depois de constatar que estava tudo em ordem o jeito foi remover IC20 (LS86) e testar ele no oscilador do proto-board.

IC20 (LS86) removido. O cristal e o capacitor C1 estão fora da placa, montados no proto-board

Quando coloquei no proto-board o LS86 que estava na placa o oscilador não funcionou, comprovando que o CI estava com problemas. Reinstalei então o cristal e o capacitor C1 na placa e instalei um soquete para o LS86.

Soquete, cristal e capacitor reinstalados em seus devidos lugares.

Após instalado o CI em seu soquete o oscilador passou a funcionar, e deu para partir para os testes seguintes.

Oscilador funcionando novamente.

A primeira coisa que fiz foi checar se os sinais de sincronismo e de vídeo para ver se o TK estava vivo. Havia um sinal instável no vídeo mas não havia sincronismo.

O primeiro lugar para checar é o gerador de base de tempo, composto por IC11, IC12 IC21 e IC23. Este gerador recebe o sinal de 3,25MHz e divide até chegar num tempo de aproximadamente uma linha (64us). Os pulsos podem ser vistos no pino 11 de IC23. Mas este circuito estava em ordem

Gerador de base de tempo horizontal.

Olhando um pouco à frente vi que os pulsos de sincronismo estavam ficando parados na porta D de IC24, uma vez que o sinal de /IOWR estava constantemente em nível zero (pino 13 de IC24) .

Gerador de base de tempo, sincronismo e sinais de escrita no cassete.

As linhas /IORQ e /WR estavam fixas em nível alto, e o flip flop formado pelas portas C e D de IC16 permanecia em sempre travado. em nível zero.

Agora que estou escrevendo este artigo começo a desconfiar que o diodo D22 está invertido no diagrama. Amanhã eu confirmo isso.

Pinos 13 de IC24 ficava fixo em nível zero, mantendo o pino 11 travado em nível alto.

Prosseguindo, como no padrão do ZX81 o vídeo é gerado parte por hardware parte por software nas interrupções não mascaráveis, desconfiei que o comportamento estranho talvez fosse devido a um problema com o Z80, ou a ROM ou a RAM, e deixei de lado por algum tempo os sinais de sincronismo.

Medindo as linhas de dados e de endereços no Z80 vi que algumas delas ficavam variando, outras não. Isso poderia ser um problema do Z80. Para verificar se era isso coloquei a ponta de prova numa linha das linhas que estava parada (no caso o A13) e observei o comportamento durante o RESET. A linha tinha sinal por um tempo depois sumia. O mesmo padrão se repetia para outras linhas com sinal fixo, como IORQ e /WR. Esse comportamento indica que o Z80 está OK.

O próximo passo então foi checar se todas as linhas das SRAMs estavam recebendo alimentação e sinais corretamente, uma vez que os soquetes das SRAMs estavam meio oxidados. Comecei checando as alimentações de +5, -5 e -9 e estavam todas OK.

Daí fui checando as vias de dados se estavam coerentes com as linhas de dados do Z80. Para fazer esse check uma das pontas de prova do osciloscópio vai no pino do Z80 e a outra vai na memória. Os traços devem ser iguais. Se houver diferença de um pro outro alguma coisa pode estar errada.

Eu tive um pouco de sorte, pois ao chegar na linha DD4 vi que ela estava em nível alto o tempo inteiro nos pinos 2,14 de IC34 (4116) porém no Z80 esta linha ficava um 'sujinho' em nível baixo.

Checando no diagrama os outros pontos onde essa linha é conectada vi que o sinal estava OK nos pinos das EPROMs porém no pino 24 da furação destinada ao PSG o sinal não chegava.

Peguei então o multímetro para conferir mas nem precisava. Uma inspeção visual já deu para achar o problema ali dentro do soquete da ROM auxiliar. Uma trilha estava partida muito provavelmente pela ferramenta usada para remover a EPROM quendo a placa foi canibalizada.

Trilha do sinal DD4 interrompida por dano causado por ferramenta.

Reparo efetuado com fio esmaltado.

Remendada a placa, os sinais de /IOWR começaram a ser gerados e já era possível ver atividade em todas as linhas do Z80, porém ainda não tinha sincronismo presente no pino 2 de IC20 (LS86).

Seguindo a trilha do sinal de sincronismo cheguei ao pino 12 de IC22 (LS32) que estava fixo em 2,0Volts. Este pino é ligado ao pino 8 de IC24 (LS00) que tinha sinal.

Checando com o multímetro vi que não havia continuidade entre estes pinos. Porém dependendo de como eu pressionasse o pino 8 de IC24 o multímetro acusava continuidade.

O sinal não passava do pino 8 de IC24 para o pino 12 de IC22.

Olhando a placa por baixo deu para ver a razão. O pino estava sem solda!

O pino 8 do IC24 (LS32) estava sem solda.

Refeita a solda, o sinal de sincronismo passou a aparecer normal no pino 2 (e 3) de IC20 (LS86). Uma maneira bacana de ver ambos o sinais é sincronizar pelo sinal vertical presente no pino 4 de IC24 e colocar a outra ponta de prova no sinal de sincronismo (pino 8 de IC24 ou pino 11 de IC22).

Apesar do sincronismo estar normal, o vídeo está uma bagunça. Ainda não liguei a um monitor mas com a ponta de prova do osciloscópio já deu para ver a encrenca. Amanhã vou ligar o circuito do Kolour neste TK para dar uma olhada no aspecto da tela para ver se tenho alguma pista.

↧

Documentação do teclado LABO

October 5, 2014, 8:35 pm

≫ Next: Ressucitando um TK85 (3)

≪ Previous: Ressucitando um TK85 (2)

Segue abaixo uma pequena documentação a respeito do teclado LABO.

A pinagem do conector DB-25 encontra-se abaixo.

O teclado consome 480mA de corrente. então é recomendado alimentar ele com uma fonte com capacidade de pelo menos 600mA, para ter uma folga.

O sinal /CAPS é uma entrada ativa em nível baixo e serve para acender a luz que fica dentro da tecla SHIFT LOC e drena por volta de 20mA quando conectado ao terra.

O sinal /UPPER fica normalmente em nível alto (TTL) porém vai a nível zero quando se pressiona a tecla UPPER FUNCTION.

O sinal TX DATA é a saída do teclado, em nível TTL. A velocidade de transmissão é de 1200 bauds com 8 bits de dados, sem paridade e 1 bit de parada (1200 8N1).

A cada tecla pressionada seu código correspondente é transmitido. A tecla SHIFT não possui código próprio, sendo usada apenas para acessar os símbolos alternativos das teclas numéricas e de pontuação.
O teclado não tem auto-repetição automática. Para isso o teclado tem a tecla REP que quando pressionada em conjunto com uma tecla, repete sua transmissão a cada 100ms.

A tecla SHIFT LOC possui dois códigos que transmite alternadamente ao ser pressionada 0xBA para as teclas minúsculas (a, b, c, d, ....) e 0xBB para as teclas maiúsculas (A. B, C, D,...). Esta tecla não altera o estado dos símbolos alternativos das teclas numéricas e de pontuação.
Quando as teclas minúsculas estão selecionadas e se pressiona SHIFT as teclas maiúsculas são transmitidas. Já o oposto não acontece: quando as teclas maiúsculas estão selecionadas pressionar SHIFT não altera o estado para minúsculas.

O mapeamento das teclas encontra-se abaixo. As teclas que não possuem código, quando pressionadas, equivalem ao código ASCII grafado na tecla.

As teclas que possuem apenas um código, quando pressionadas em conjunto com a tecla SHIFT transmitem o caractere 0x00.

Os números do teclado numérico não enviam os mesmos códigos que os números do teclado normal. As teclas Y e N do teclado numérico não possuem os mesmos códigos das teclas Y e N do teclado normal.

A tecla "-" ao lado do SHIFT da direita é um "underscore" e não um sinal de menos.

A tecla na segunda posição à esquerda de BACKSPACE é a tecla de Circunflexo/Til. São teclas ASCII normais, porém a grafia adotada na tecla (setas) não corresponde à grafia normal (^/~).

As teclas ESCAPE e BACKSPACE não usam os códigos ASCII padrão .

↧

Ressucitando um TK85 (3)

May 15, 2015, 10:57 pm

≫ Next: Ressucitando um TK-85 (4)

≪ Previous: Documentação do teclado LABO

Hoje não foi um dia muito frutífero, mas a pesquisa continua...

Em primeiro lugar tive que conectar a placa do TK a um monitor. Como a TV de 5" cabe melhor na bancada do que o monitor LCD eu montei num protoboard uma versão melhorada do A/V Treloaded que usa menos componentes e tem melhor desempenho. Por desempenho entenda-se que a saída tem impedância de 75Ohms e acoplamento DC. Eu batizei o circuito de 'TK85 AV Tetraloaded'. Poderia também ser Treloaded Plus, mas como eu na realidade removi componentes também poderia ser Treloaded Minus. Enfim, segue anexo circuito.

TK85 A/V Tetraloaded

Diagrama do circuito.

Depois de ligado o circuito na TV a imagem que apareceu estava cheia de artefatos, o que confirmou as observações de anteontem no osciloscópio.

Artefatos na tela.

Nas minhas observações o que achei estranho é que o registrador de deslocamento IC9 (Ls165) está recebendo dois pulsos de load dentro de um mesmo ciclo M1. Não me lembro de ser assim no outro TK.

Azul: SH/LD de IC9. Barras verticais: Ciclo M1

Uma coisa que achei estranha é que quando a ponta de prova é colocada na linha DD6, a imagem fica praticamente sem artefatos, muito embora o K do cursor tabém não esteja OK nessa situação.

Ao se encostar na linha DD6 o padrão de artefatos muda.

Fiz alguns testes mas nada conclusivo. Cheguei a desconfiar de alguns sinais e troquei os circuitos integrados IC5 e IC15 porém a situação continuou a mesma.

IC5 e IC17 com soquetes.

Também troquei as memórias por outras que eu tinha aqui mas a situação continuou igual. Só mudou um pouco os padrões na tela.

Amanhã vou anotar algumas formas de onda do TK que está bom e usar como comparação.

↧

Ressucitando um TK-85 (4)

May 17, 2015, 1:57 pm

≫ Next: Caixa reciclada para o TK85

≪ Previous: Ressucitando um TK85 (3)

Continuando o post anterior...

Hoje eu peguei o TK-85 que está funcionando corretamente e capturei várias formas de onda, a fim de comparar com a placa que estou tentando restabelecer seu funcionamento.

Eu usei como trigger o sinal de base de tempo vertical presente no anodo de D22 e escorreguei a base de tempo para aproximadamente 2,5ms além. A razão disso é que intervalo vertical não há vídeo sendo gerado. Eu ajustei a posição vertical de forma que a borda de descida do ciclo M1 batesse com o centro da tela do osciloscópio, ou seja sobre o eixo vertical.

A razão de usar o ciclo M1 como referência é que o TK85 (ZX81) literalmente executa a memória para desenhar a tela, e o ciclo M1 vai a nível baixo no início do ciclo de busca (fetch) das instruções.
Quando o ZX81 executa instruções na região correspondente ao D-FILE, existe um circuito que gera 'NOPS' para o Z80 para cada caractere na tela. Sendo assim, este sinal é uma boa referência de tempo para se checar os outros sinais.

Com uma referência fixa foi possível combinar várias formas de onda e combina-las numa figura única de forma a facilitar o entendimento (ou futuras pesquisas de pane).

Formas de onda do TK85

Olhando a figura acima vemos de cara uma coisa estranha. O sinal presente no pino 9 de IC5 (LS373) varia entre 0 e 1,2Volts. Isso estava assim também na placa defeituosa e foi exatamente esse comportamento que ontem me fez suspeitar de IC17 (LS04) e de IC5 (LS373). Acabei trocando IC5 porque apesar de tudo a saída da porta E de IC17 invertia o sinal. Depois de trocado IC5 o comportamento do circuito não havia se alterado.

Geração do sinal SHIFT/LOAD

Como última e desesperador medida acabei trocando também IC17, pois sua porta C estava ligada diretamente em DD6 que quando tocada com o dedo ou a ponta de prova mudava o sinal produzido na tela (vide post anterior).
A conclusão é que embora bizarro esse circuito funciona assim mesmo. O que acontece é que na fase alta do sinal de REFRESH, as saídas de IC5 estão em tristate, e isso equivale a deixar o pino 11 de IC17 em aberto. Com isso, os 1,25 Volts são enxergados como nível alto e a saída representa o inverso do sinal de entrada com um pequeno detalhe: Na falta de algo para puxar a entrada do inversor (IC17-11) para cima, o sinal sobe relativamente devagar, formando uma rampa que causa um delay de aproximadamente 200ns na borda de descida do sinal no pino 10 de IC17. Não sei dizer se este atraso é proposital, teria que analisar mais ou fazer mais experimentos.

Continuando, o sinal de NOP 'atrasado' junto com o sinal MREQ (também atrasado por uma rede RC) e mais o sinal de 3.25MHz são combinados numa porta NAND de forma que um pulso baixo só aparecerá no momento em que os três sinais estiverem em nível lógico alto. Isso acontece entre na fase alta de clock, no final do ciclo de 'refresh', logo antes do início do ciclo de 'fetch' seguinte (o sinal nop segue mais ou menos o inverso do sinal de refresh)

Formas de onda em IC18C (LS10, TK85 funcionando)

Na placa defeitosa, os sinais estavam um pouco diferentes: O sinal de clock era um pouco mais bem comportado, e o sinal de NOP 'atrasado' por IC5 (LS373) apresentava uns glitches que desapareciam quando tocava-se o dedo ou a ponta de prova na linha DD6. O sinal MREQ' era igual.

Já a saída era muito estranha, em vez dos pulsos curtos apareciam dois pulsos de SHIFT/LOAD e era isso que fazia o registrador de deslocamento apresentar aquele monte de lixo na tela.

Formas de onda em IC18C (LS10, TK85 defeituoso)

Abrindo-se a varredura da tela para conferir os estados lógicos apareceu um suspeito: IC18. Aparentemente a saída estava simplesmente invertendo o sinal MREQ'.

Forma de onda 'esperada' em IC18 (vermelho) versus sinal atual (azul)

Comparando o sinal observado com o sinal desejado tinha-se a impressão de que a porta NAND não estava funcionando corretamente. Daí, dá-lhe trocar o LS10, Aproveitei para colocar um soquete.

IC18 (LS10) removido

Soquete instalado para IC18 (LS10)

Estava fácil demais.... não precisa nem dizer que não funcionou...

Então, pausa pra tomar um café e brincar com o cachorro enquanto pensa no problema...

Brincando com o Otto para refrescar as idéias.

Alguns biscoitos depois comecei a investigar outra a diferença que observei nos sinais: O clock. Como eu ainda tinha na memória do osciloscópio o clock do TK funcionando, fiz uma nova captura e sobrepus os dois sinais:

Clock 3.25MHz'. Branco: TK funcionando / Azul: TK com defeito

Daí apareceu uma coisa que não tinha notado de início. O Clock do TK com defeito estava sobreposto a um sinal de aproximadamente 1,2Volts. Isso me fez lembrar da saída do LS367 que era reconhecida como nível alto daí refiz a análise dos sinais na entrada de IC18 considerando que o clock estivesse sendo enxergado pelo CI como em nível alto o tempo inteiro:

Considerando o Clock em nível alto, explicava-se o comportamento da saída.

Bingo!!! Considerando-se o Clock em nível alto o tempo inteiro, o comportamento estranho do sinal SHIFT/LOAD estava explicado!

O problema agora havia se transformado em estudar porque o clock estava diferente do que deveria. Analisando o circuito do TK novamente, vemos que o sinal de clock/2 (3.25MHz) saindo do pino 9 de IC4 (LS74) passa por uma rede diferenciadora (C3-R5) e vai para o pino 9 de IC18. Como o sinal estava passando, o capacitor poderia estar em curto ou o resistor poderia estar aberto.

Derivador de clock.

Deu um pouco de trabalho encontrar estes dois componentes (C3, R5) que estavam ao lado do jack de 'EAR'. Quando os encontrei verifiquei que a conexão de GND do resistor estava aberta. Observando do lado de baixo da placa vi o problema:

Trilha danificada quando a placa foi canibalizada.

A conexão entre o terminal negativo do resistor R5 (e sabe-se lá o que mais, já que a trilha é grossa) e a ilha do jack de EAR que vai ao GND estava aberta! Esta trilha deve ter-se rompido quando a placa foi canibalizada e passou batido quando eu soldei o Jack para substituir o que estava faltando.

Consertei a placa usando fio rígido. Cortes, trincas e demais interrupções sempre devem ser reparadas soldando fio entre ilhas, pois quando o fio é soldado nas trilhas elas aquecem e tendem a descolar e depois de algum tempo o reparo pode romper-se novamente.

Trilha reparada.

Depois do conserto, verifiquei a forma de onda dos sinais de CLOCK e SHIFT/LOAD. Desta vez estava tudo certo! Até os picos que apareciam no sinal de "NOP" e a sensibilidade quando se tocava a linha DD6 desapareceram.

Formas de onda como esperado agora!

Formas de onda boas, o próximo passo foi ligar o monitor. Agora sim... SUCESSO!!!

O próximo passo vai ser soldar os pinos para os conectores do teclado e testar se a leitura e escrita no cassete estão funcionando.

↧

Caixa reciclada para o TK85

May 17, 2015, 8:25 pm

≫ Next: Ressucitando um TK-85 (5)

≪ Previous: Ressucitando um TK-85 (4)

Aproveitando a onda da reciclagem salvei de ir pro lixo uma caixa de placa de vídeo que serviu perfeitamente para abrigar um TK85. Só precisei cortar um pouco a espuma para encaixar o TK, e ainda sobrou um compartimento onde cabe perfeitamente uma fonte chaveada e um cabo de vídeo.

O TK-85 há décadas não tinha uma casa própria.

↧

Ressucitando um TK-85 (5)

May 21, 2015, 8:29 pm

≫ Next: Caixa padrão para projetos com Arduino

≪ Previous: Caixa reciclada para o TK85

Nos últimos dias não tenho conseguido mexer muito com a plaquinha "ressucitada", mas hoje consegui fazer umas poucas coisas:

Instalei duas barras de pinos. Uma com 5 pinos e outra com 8 pinos.

Barras de pinos para as conexões do teclado.

Com isso já deu para testar as combinações da matriz de teclado. Felizmente todas as teclas estão funcionando.

A imagem ficou muito nítida com o TK85AV Tetraloaded

Instalei também alguns componentes faltantes na placa para implementar o MOD do PSG. Ficou faltando o Jaque de saída (que não tenho no momento) e um capacitor de desacoplamento, este último só fui me dar conta agora. A lista completa dos componentes necessários é:

1 AY3-8912 (IC29, PSG)
1 74LS00 (IC27)
1 LM386 (IC 38)
4 diodos 1N4148 (D6, D7, D8, D9)
4 capacitores de 100nf (C15, C24, C31, C32)
1 capacitor de 220uf (C16)
1 resistor de 47K (R66)
1 resistor de 100K (R65)
1 soquete de 8 pinos (para IC38)
1 soquete de 14 pinos (para IC27)
1 soquete de 28 pinos (para IC29)
1 Jaque de áudio P2

Como ainda falta testar algumas coisas não instalei os CIs, somente os soquetes.

Ficou faltando o capacitor C32 que serve para desacoplar a alimentação de IC27 (LS00)

Soquete e capacitores para o amplificador de áudio.

Por hoje é só...

↧

Caixa padrão para projetos com Arduino

May 23, 2015, 7:30 pm

≫ Next: Retomando um antigo projeto

≪ Previous: Ressucitando um TK-85 (5)

Há algum tempo atrás um amigo me deu algumas caixas padrão que ele tinha sobrando, e acabei descobrindo por acaso que ela abriga perfeitamente uma placa de Arduino UNO e ainda sobra espaço para um "shield". A caixa em questão é a CP-013 da Patola.

Caixa CP-013 da Patola

A caixa tem ranhuras laterais onde uma placa de Arduino se encaixa direitinho.

A caixa tem espaço para uma placa de Arduino e mais um "shield"

A furação aproximada (apenas para a placa do Arduino) é vista na figura abaixo.

Caixa CP-013 após a furação.

Opcionalmente pode-se fazer um rebaixo na tampa o jaque de alimentação para melhorar o encaixe.


Rebaixo para o plug de alimentação.

Caixa CP-013, tampa e Arduino.

Caixa já furada, vista de outro ângulo.

↧

Retomando um antigo projeto

May 24, 2015, 7:21 pm

≫ Next: Tek - Adaptador de teclado genérico

≪ Previous: Caixa padrão para projetos com Arduino

Há algum tempo atrás fiz o projeto de um adaptador de teclado genérico para micros antigos baseado em registradores de deslocamento mas esse projeto ficou meio abandonado em função de uma variação para ser ligada externamente ao TK90X (que infelizmente precisava de uma modificação interna no TK e por isso também foi abandonada).

Pois bem, como a placa 'ressuscitada' precisa de um gabinete e de um teclado, resolvi retomar o projeto do adaptador de teclado genérico (ou Tek) e construí um protótipo.

Prótótipo montado. Os 595 só entram depois dos primeiros testes com o microcontrolador

Foi necessário furar uma fileira extra para acomodar todos os chips na placa de 5x10cm

O projeto do TK90X era baseado num AVR, mas como o espaço é pouco nessa placa vou utilizar o PIC16F688 que tem apenas 14 pinos porém é mais que suficiente para estimular a matriz e ainda sobram pinos para uma porta serial ( que auxilia no 'debug' e serve de expansão 'cross typing' ) e para alguns pinos de entrada/saída para outros fins como entrada de sinais especiais (led caps, teclas modificadoras, etc)

e ainda sobram mais alguns pinos para uma interface serial e

↧

Tek - Adaptador de teclado genérico

May 28, 2015, 8:16 pm

≫ Next: Sinal /KBD no TK-85

≪ Previous: Retomando um antigo projeto

A fim de seguir com o projeto do adaptador de teclado genérico tratei de fazer o PIC16F688 se comunicar com o teclado PS/2. Para não perder muito tempo com a implementação resolvi usar uma biblioteca pronta do compilador Mikrobasic para PIC. Esse compilador, ou melhor esse ambiente de desenvolvimento possui bibliotecas para vários periféricos bem fáceis de usar além é claro do 'conforto' de se programar em Basic, pelo menos para quem viveu a época dos micros clássicos. A versão 'demo' permite gerar código até 2Kbytes, o que dá para fazer bastante coisa.
Porém, a facilidade tem seu preço, como por exemplo quando uma biblioteca não tem as funcionalidades que você quer ou não se comporta da maneira como você deseja, e foi exatamente o que aconteceu.

A biblioteca de PS/2 interpreta os 'scancodes' levando em consideração o estado da tecla shift e o caps lock, o que complica bastante a geração dos estados da matriz. Por exemplo, quando eu pressiono SHIFT juntamente com a tecla "8" a biblioteca me retorna o asterisco "*". Até aí tudo bem, eu poderia simplesmente associar o "*" ao estado correspondente na matriz.
Mas a coisa complica na hora por exemplo de um SHIFT+Letra, pois o teclado interpreta o estado da tecla SHIFT e também o estado da tecla Caps Lock. Dessa forma não tenho como diferenciar somente pelo código recebido quando eu estou pressionando A com o Caps ligado ou SHIFT+A, pois em ambos os casos eu receberia somente que a tecla "A" (maiúscula) foi recebida. Assim seria necessário acrescentar um tratamento paralelo dos estados das teclas CAPS e SHIFT. Isso sem falar no SHIFT+ENTER que seria chato de tratar também...

Pelo menos ficou a experiência de ter lidado com o Mikrobasic, que achei bem positiva.

Bom, no projeto abandonado do emulador de teclado externo para o TK90 eu tinha passado por algo semelhante com a biblioteca PS/2 'padrão' do Arduino, e acabei usando uma outra biblioteca que me retornava os 'scancodes' exatamente como recebidos do teclado, sem os interpretar nem transformar em ASCII. Esta biblioteca tem ainda a vantagem de ser bidirecional, ou seja ela permite enviar comandos ao teclado como inicializar, trocar o modo dos scancodes ou mudar o estado dos leds.

Como essa biblioteca é bem simples resolvi porta-la para o PIC (em C) trocando algumas funções que tomei emprestadas de uma biblioteca de I2C que eu havia escrito na época do projeto do TKChuck.

Para minha surpresa, o código funcionou logo de cara!!

Biblioteca myPS2 funcionando!

Os dois primeiros bytes recebidos são o teclado respondendo ao comando de inicialização e ao Auto Teste finalizado com sucesso . Os bytes seguintes são correspondentes às teclas sendo pressionadas.

O próximo passo foi portar o restante do código do projeto anterior para o PIC e refazer a tabela que associa o 'scancode'à matriz de teclado de forma a refletir as teclas do TK85.

Matriz do teclado do TK-85 linearizada (somente 5 bits menos significativos).

Por exemplo, a tecla "S" equivale à coluna 1 (bit D1) da linha 2 (A9):
#define _Tecla_S 0x0A // 0.0.001.010 -> 0000 1010 -> 0x0A

Já a tecla "Backspace" equivale à SHIFT + 0, ou seja SHIFT + coluna 0 da linha 3 (bit D0 de A12)
#define _Tecla_BS 0x83 // 1.0.000.011 -> 1000 0011 -> 0x83

Um detalhe de montagem do circuito é que o bit D0 ficou na saída Q7 do registrador de deslocamento. Isso requereu alguns acertos, porém agora o programa preenche a matriz corretamente. Nas figuras abaixo as sequências de números correspondem à matriz, sendo a primeira o estado da matriz quando a tecla é pressionada e a segunda quando a tecla é solta.

Tecla "1"

Tecla "S"

Tecla "Backspace", composta de "SHIFT" + "0"

Somente tecla "SHIFT"

O próximo passo vai ser conferir se os registradores de deslocamento estão sendo devidamente preenchidos com o conteúdo da matriz e em seguida começa o teste 'ao vivo' conectado na placa do TK85.

↧

Sinal /KBD no TK-85

May 29, 2015, 7:32 pm

≫ Next: Tek - Adaptador de teclado genérico (2)

≪ Previous: Tek - Adaptador de teclado genérico

Este post é para ajudar o amigo Clóvis a identificar um problema num TK-85, mas fica também de referência para futuras pesquisas

O sinal /KBD é gerado pela combinação dos sinais /IORQ, A0 e /RD. A decodificação é incompleta, e qualquer endereço de I/O lido vai gerar este sinal que ativa o buffer IC10 (LS365) e permite a leitura das colunas do teclado (bits D0-D4) além do sinal do cassete (bit D7). Este sinal também permite ao TK reconhecer o funcionamento em 50/60Hz através da presença/ausência do diodo D6. Se o diodo está presente, então toda vez que o sinal /KBD for ativado ele vai forçar um nível baixo na linha D6. Caso o diodo não esteja instalado, o nível lido é alto (apesar de não existir um pull-up na linha).

Lógica de geração do sinal /KBD no TK-85

A forma de onda normal do sinal /KBD é uma série de 9 pulsos espaçados de 25us e que se repetem a cada 16 ms (a 60Hz). A primeira leituraé para ler e isolar o estado da tecla SHIFT e as seguintes são para ler o estado das colunas (D0..D4) para cada uma das 8 linhas do teclado (A8..A15).

O sinal /KBD consiste de uma série pulsos para ler a matriz do teclado.

Os 9 pulsos são ativados a cada quadro de vídeo gerado (60Hz).

↧

Tek - Adaptador de teclado genérico (2)

May 29, 2015, 8:44 pm

≫ Next: Tek - Adaptador de teclado genérico (3)

≪ Previous: Sinal /KBD no TK-85

Continuando com o projeto, hoje testei a parte da geração do sinal serializado para a matriz composta pelos registradores de deslocamento. São necessários 3 sinais

DOUT - Sinal que sai do microcontrolador e entra na matriz
SCK - Sinal de clock para os dados que chegam

RCK - Sinal de transferência dos flip flops internos (shift register) para os flip flops de saída (storage register)

Os registradores de armazenamento internos aos 595 são fundamentais para este circuito pois evitam que falsos pressionamentos sejam detectados durante a transferência serial (bit a bit) da matriz.

Os sinais gerados encontram-se abaixo:

Transferência da tecla Q para a matriz. Ao final é gerado um pulso de transferência (RCK)

Captura da transmissão de várias teclas.

Se mais de uma tecla for pressioanda, ambas são tranferidas à matriz. Algumas teclas são transferidas como uma combinação de mais teclas como é o caso das setas de cursor, que são transferidas como se fossem as teclas SHIFT e a tecla correspondente no teclado (UP=7, DOWN=6, LEFT=7, RIGHT=8)

Transmissão de teclas simultâneas e transmissão de tecla composta SHIFT+xx

O próximo passo é montar tudo no TK e ver se funciona!

↧

Tek - Adaptador de teclado genérico (3)

June 1, 2015, 10:03 pm

≫ Next: TEK - Placa 'universal' e coleção de links

≪ Previous: Tek - Adaptador de teclado genérico (2)

A primeira vez que liguei o circuito do adaptador de teclado ao TK nem preciso dizer que não funcionou, ne?

Pois bem, depois de perder algum tempo preocupado com as formas de onda da linha de dados que circula entre os registradores de barramento, achei o primeiro pedaço do problema: Falta de resistores de pullup nos pinos de seleção de linhas.

O circuito precisa de resitores de pull-up nos pinos que vão às linhas de endereço.

No TK, com o teclado mecânico, estes resistores de pull-up não são necessários, uma vez que o resistor de pullup da linha de entrada do LS365 puxa a linha para cima. Ao se pressionar uma tecla quem puxa a linha para baixo é a linha de endereço.

Já no emulador de teclado, as linhas de endereço são ligadas aos pinos de /oe dos registradores de deslocamento, e sem os resistores de pullup essas linhas todas ficavam em estado indeterminado. O interessante é que eu esperaria que essas linhas ficassem ativas, pois os registradores de deslocamento são HC e os pinos abertos são tomados como nível baixo, o que deveria ter gerado algum lixo que seria percebido pelo TK como alguma tecla pressionada, mas enfim, não foi assim que aconteceu.

O fato é que depois que coloquei os resitores de pull-up já foi possível baixar o sinal, linha a linha e conferir o acionamento de cada coluna à medida em que se pressionava a tecla correspondente.

Todas as linhas funcionaram, exceto a última linha!! Daí conferindo o circuito, achei que o pino do /oe do chip que recebe os bits da última linha estava em nível alto o tempo inteiro, devido a uma problema na solda (o fio esmaltado não tinha perdido a isolação direito).

Depois de consertada a solda e conferido o contato no multímetro, novo teste e.... Mesma situação!!
Novamente o mesmo procedimento, checar todos os sinais que chegam ao CI. Assim descobri que tinha esquecido de soldar o pino 12, do sinal de RCK que é o sinal responsável por transferir os dados do registrador de deslocamento para o latch de saída.

Havia uma falha dupla na montagem de um dos registradores de deslocamento.

Pois é, falha dupla!!! O pior das falhas duplas é você achar um defeito e achar que está resolvido e depois não testar mais aquele pedaço! Isso pode acontecer com tudo: de máquinas a software!! E o procedimento para resolver e sempre o mesmo: Conferir tudo, mesmo que já tenha sido conferido antes, sem tomar nada por garantido. Se tiver dúvida se já testou ou não, teste de novo.

Depois de consertado mais esse problema, a última linha passou a funcionar. O passo seguinte foi ligar no TK e torcer os dedos!!

Aí sim, sucesso!!!!

Circuito montado na placa ressuscitada.

Todas as teclas funcionaram perfeitamente, inclusive as compostas (setas, backspace, etc)

Detalhe da montagem. A alimentação vem do TK

Circuito composto de 8 registradores de deslocamento (HC595) e um PIC16F688

O projeto ficou pequeno, e ocupou apenas 575 bytes de memória. Isso significa que cabe perfeitamente num PIC menor como um 12F675 ou 12F629, e ainda sobra espaço para melhorar a tabela de associação das teclas (por exemplo BACKSPACE ficou mapeado como SHIFT + 0 pressionados simultaneamente).

Tela do projeto, que está bem simples e consumiu pouca flash.

Agora preciso dar uma arrumada no código, melhorar os comentários, etc antes de publicar. Também preciso redesenhar o circuito.

↧