Ressuscitando um TK85 (3)

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.

Ressuscitando um TK85 (2)

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.

Ressuscitando um TK85

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.

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

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

Placa do adaptador RGB Kolour

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)

TK85 num monitor RGB

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: