sexta-feira, 29 de dezembro de 2006

Captura de listagem

Uma forma fácil de armazenar a listagem de programas é um simples conversor paralelo-serial, composto de um microcontrolador, que aguarda o MSX baixar a linha de strobe, para receber o dado e enviá-lo via porta serial do PC. O microcontrolador faz ainda a sinalização de "busy" (ocupado) para o MSX.




O software para realizar esta implementação é muito simples. Uma possibilidade é utilizar um microcontrolador da família 8051, programado em Basic. A porta P1 recebe os dados da porta de impressora do MSX. A linha P3.2 recebe o sinal de "Strobe", e a linha P3.3 sinaliza a condição de ocupado ("busy"). A interface com o PC pode ser implementada através de um simples transistor.


' Captura porta impressora do MSX e envia
' para porta serial

'SERIAL PORT CONFIGURATION
$BAUD = 19200 'set 19200 baud rate for
$CRYSTAL = 11059000 '22.1184 MHz crystal

dim a as Byte
Reinicia:
p3.3=0 ' desabilita condição ocupado

Aguarda:
if p3.2=1 then goto Aguarda' aguarda sinal strobe

p3.3=1 ' indica ocupado
print p1; ' envia o caractere recebido na serial

' waitms 1
goto Reinicia ' aguarda proximo caractere



Versão em Assembly:


; captura listagem de impressora do MSX
; para a porta serial

$MOD51

org 0
ljmp inicio

inicio: mov a,#255
mov p1,a
setb p3.1
setb p3.2
setb p3.3

mov scon,#40h
mov pcon,#0
mov tmod,#20h
mov th1,#253
mov tl1,#253
setb tr1

reinicia: clr p3.3
aguarda: jb p3.2,aguarda
setb p3.3
mov a,p1
mov sbuf,a
jnb ti,$
clr ti
sjmp reinicia
end

O Diagrama do circuito, baseado num microcontrolador AT89C2051 encontra-se abaixo:



A alimentação do circuito pode ser retirada do conector de Joystick.

quarta-feira, 27 de dezembro de 2006

Testes do protótipo 1 no Expert

Esse Natal rendeu muitos presentes para o MSX....

O protótipo 1 foi testado com sucesso no Expert, e a interface I2C também funcionou. Novas idéias surgiram, mas agora é hora de retomar o fio da meada, ou seja o leitor de cartões SD/MMC.

O próximo passo, é montar o protótipo 2, e começar a trabalhar no software, ou seja, nas rotinas básicas de acesso ao cartão SD/MMC.

segunda-feira, 25 de dezembro de 2006

Interface SPI + I2C simplificada

Da idéia à prática:
A implementação da interface SPI + I2C, até o momento, foi um sucesso, tanto nos testes estáticos, quanto na leitura e escrita utilizando o barramento I2C. O SPI ainda não foi testado por falta de tempo e de um dispositivo que opere neste barramento.

O software de baixo nível ("driver") I2C foi adaptado a partir de uma implementação de David R Brooks que estava disponível sob licença GPL na internet, mas ainda precisa de algumas modificações para trabalhar com memorias flash (o original usa memoria RAM ferromagnetica, que nao tem latência de escrita de página). A leitura, por outro lado, já está plenamente funcional, sendo capaz de ler 16Kbytes de dados em 10 segundos, mesmo sem nenhuma otimização da rotina de leitura.

Segue abaixo um diagrama do circuito, bem como uma ilustração de como ficou a placa.





Os testes foram feitos num Expert 1.1 (soquetado), que recebeu apenas 10 fios.

Eis a foto da montagem "pendurada"



E uma foto da Tela. da TV, num "dump" de memória do "simple" assembler. A E2prom serial utilizada no teste pertencia a um velho celular Ericsson.

domingo, 24 de dezembro de 2006

Interface SPI + I2C simplificada

Com um mínimo de hardware (apenas 3 CIs) é possível implementar uma interface para suportar 2 portas SPI e mais um barramento I2C.

A interface, mapeada em I/O, utiliza um pino livre do próprio decodificador interno do MSX (IC5 no HotBit e IC29 no Expert).

As portas funcionam no modo "bitbang", mas para otimizar a velocidade, foram usados alguns artifícios:
  • Os bits de entrada estão localizados nas posições 0 e 7 da palavra lida. Assim, para ler um bit, bastam duas instruções de rotação de registrador com "carry";
  • Um "latch" endereçável de 8 registradores de 1 bit (LS259) permite escrever um bit com uma rotação e e uma soma com "Carry";
Esta interface permite ligar vários dispositivos interessantes, como:

SPI:
  • Cartões de memória de Playstation;
  • Cartões MMC/SD (em modo SPI);
  • Joysticks de Playstation;
  • Relógios de tempo Real;
  • Displays LCD de celular;
  • Relógios de tempo real (DS1302,...);
  • Memórias seriais (94x46,...);
I2C:
  • Memórias seriais (24Cxx);
  • relógios de tempo real (PCF8583);

quarta-feira, 20 de dezembro de 2006

Direto do Túnel do Tempo...

Reativei hoje, após 12 anos sem uso, meu velho gravador HB2400. Para minha felicidade ele está funcionando em perfeita ordem e para minha surpresa, a maioria das coisas que tenho em fita ainda funciona!!

Eis algumas pérolas, que não constam em nenhum catálogo de programas para MSX:

Seeräuber, ou "pirata" em alemão (ladrão dos mares). Desenvolvido em assembler no Simple. Nunca chegou a ser terminado, pois a faculdade e o namoro consumiram todo o meu tempo, naquele início de década de 90. As cores dos meus programas eram meio esdrúxulas, pois eu tinha uma TV preto e branco, e escolhia as cores simplesmente pelo contraste.
"RightSoft" era minha marca (nunca) registrada, e o nome foi escolhido por ser o único nome bacana que dava pra escrever com o restinho que me sobrara de uma cartela de "letraset" (decalques transferíveis)


Outra tela do programa. Os comandos eram navegáveis via setas de cursor. A seleção era feita por ENTER, ou ESPAÇO, e o retorno ao menu superior era através de "escape". A tela era baseada em scrren1, com caracteres redefinidos, tanto para o logotipo quanto para as letras em fundo invertido. O programa era feito para fita cassete, pois eu nao possuía "disk drive".

Este outro programa era da autoria do irmão de um amigo, com quem eu trocava um monte de programas em fita cassete. Também foi com esses amigos que eu consegui meu "simple" modificado, que tem função "Fsave/Fload", capaz de carregar/ler blocos a 2000bauds.



Outra tela do Pirata em ação, carregando um programa:



Aqui, mais um programa meu, de identificação do cabeçalho dos programas em fita. Ele identificou outro programa, que tinha apenas 30 bytes, chamado LETUDO!!



E para finalizar (por hoje) o último programa que eu havia feito para o MSX, capaz de decodificar código morse a velocidades variáveis, portado de um "paper" para o processador 8080. Havia também um "hardware" externo, que filtrava o sinal captado por um rádio e acionava a entrada de joystick, que era entendida pelo programa.



Quero ver se encontro agora os programas COPY3, cujo menu era inspirado no "PCTOOLS", e o COPY4 (na realdiade, 4.1 ), em Screen2, com janelas semelhantes ao TurboPascal, e navegação por setas de cursor, entre outros avanços introduzidos pela biblioteca de janelas que eu desenvolvi há muito tempo atrás. Esta biblioteca utilizava uma "recursividade lateral", pois recebia um "string" de tamanho variável, que poderia ter como parâmetros ponteiros para outras "strings", que quando selecionadas chamavam a mesma rotina recursivamente. Era legal!!

terça-feira, 19 de dezembro de 2006

Em time que está ganhando não se mexe

Como diz o ditado, em time que está ganhando não se mexe. Por isso, com a simplificação do circuito do sincronizador, a porta NAND que sobrou voltou ao gerador de "clock" automático, que retornou à sua configuração original, já bem testada no protótipo 1. Sobraram duas portas do LS125, que tanto podem ser utilizadas como entradas, ou como portas de saída no circuito da interface I2C, eliminando os diodos D2 e D3.

Na figura abaixo está o diagrama atual do Protótipo2.


A simplificação também permitiu diminuir 1 "jumper". Não é muito, face aos 23 "jumpers" restantes, mas a simples possibilidade de se fazer a placa de face simples já compensa o trabalho.

Simplificação no Sincronizador

Acabei de testar uma simplificação no sincronizador do protótipo 2, que vai permitir economizar uma porta lógica NAND. A porta "livre" deverá ser usada no circuito do gerador de clock automático, no lugar do inversor a transístor, ou na lógica de inibição do sinal de "clock", caso o arranjo com o buffer não funcione a contento.

diagrama do sincronizador já modificado.

segunda-feira, 18 de dezembro de 2006

Protótipo 2 a caminho

O protótipo 2, já está a caminho, e inclui mudanças resultantes dos testes efetuados com o protótipo1. O suporte a I2C já está incorporado, sem crescer a quantidade necessária de "chips". Mas como nem tudo é perfeito, ainda ficou faltando o LED :) .

Eis o circuito (clique na figura para amplicar):


e um "preview" da placa, roteada em face simples.

domingo, 17 de dezembro de 2006

Mais um desafio

Mais um desafio para o projeto do leitor de MMC. Só que desta vez é mais fácil de resolver.

Nos microcontroladores com unidade SPI, normalmente há um registro de dados, que é escrito antes de se invocar uma transmissão, e depois que a transmissão acontece, este registro é lido de volta, pois contém o byte recebido.

No circuito atual do leitor de MMC, a leitura acontece antes da trasmissão/recepção, e para saber o byte recebido, é necessário fazer outra leitura. Só que essa leitura gera automaticamente outra escrita, ou seja, oito ciclos de clock. Assim, é necessário algum mecanismo para inibir esta escrita automática quando se quer apenas ler o último byte recebido, como por exemplo após uma instrução INIR (leitura de bloco).

sábado, 16 de dezembro de 2006

Agora sem "buffer"

Realizei o mesmo test do post anterior, mas agora sem o "buffer". O circuito funciona corretamente com um 74HC595 acionando a via de dados do MSX.

sexta-feira, 15 de dezembro de 2006

Agora sim! Resultados positivos!

Já que o uso do "buffer" não matou o problema do "glitch", resolvi partir para outra solução, baseado na observação do funcionamento do gerador de "clock" automático, que era indiferente ao "glitch", por ser controlado por um flip-flop (metade do contador LS393).

Resolvi então usar um dos flip-flops da placa de protótipo original para amostrar o sinal de saída do decodificador nas bordas de subida do sinal de "clock" do z80.



Resolvi utilizar a borda de subida, para não precisar de utilizar um inversor antes do sinal de "clock". Se não funcionasse, eu experimentaria na borda de descida.

Desta vez, o circuito funcionou sem problemas.

Fiz um teste utilizando o "loop" entre a entrada e a saída, com o seguinte programa em assembler:

LD HL,0A000H
LD B,0 ; 256 bytes)
LD C,12 ; porta
INIR

Desta forma pude comprovar o perfeito funcionamento do circuito, que retornou os seguintes bytes:

A000: XX 00 FF FE FD FC FB FA
A008: F9 F8 F7 F6 F5 F4 F3 F2
A010: F1 F0 .....

O primeiro byte, XX, era o valor que foi lido por último. O segundo byte é o valor do registrador B no inicio da iteração, que vai sendo decrementado até atingir 0.

Note que a instrução INIR foi utilizada, ou seja, o circuito leu os dados na velocidade máxima que o Z80 suporta para endereçamento de I/O.

A figura abaixo contém o detalhe que foi modificado. A a porta IC7A nem precisa ser utilizada, pois o flip-flop possui uma saída /Q.




O circuito como está hoje, pode ser visto abaixo:



Agora sim, vai ser possível iniciar os testes com o conversor de tensão e com o buffer de saída, operando em 3Volts.

Mais dificuldades.

Fiz mais alguns testes. O "glitch" apareceu de novo, mesmo com o "buffer"!!

Consegui reproduzir a situação em que eu lia 255 sem dar glitch, que era um loop infinito, em Basic:

10 print inp(12)
20 goto 10

Se eu usasse essa instrução, e forçasse a entrada de dados a nível 1, conseguia ler o valor 255 sem o menor problema.

Olhando o codigo desta função (via um disassembly do basic), deu pra notar que o que ela faz é avaliar o operando que foi passado, e retornar o valor do operando no par HL. Em seguida o registrador B é carregado com H e o registrador C é carregado com L. Detalhe importante, é que o registrador B sempre vai conter 0, pois o valor da porta está entre 0 e 255

Em seguida o MSX executa a instrução

IN A,(C)

e devolve ao Basic o valor lido.

O que acontece nesse caso é que as linhas A8-A15 vão sempre conter 0 (valor de B), quando é utilizada a instrução INP do basic.

Uma segunda experiência mostrou que utilizando a instrução acima, e variando o valor de B, é possível fazer o "glitch" aparecer.

A conclusão estava na, mas eu não tinha percebido: O aparecimento do "glitch" depende do valor que aparece nas linhas A8-A15!!! Talvez por algum gato do Z80, talvez por algum gato do meu HotBit...

Mas o problema é que isso compromete todo o projeto, pois pretende-se fazer uso da instrução INIR, que usa o registrador B como contador (decremental), e internamente a instrução coloca nas linhas A8..A15 o valor atual de B

Por enquanto o problema está sem solução.

quinta-feira, 14 de dezembro de 2006

"Buffer" para o 74HC595

A placa adaptadora com o "buffer" para o 74HC595 foi concluída. Eis a disposição dos componentes. O "layour" desta placa adaptadora encontra-se neste link em formato EPS. Detalhe é que as trilhas ficam do lado de cima da placa. Os pinos marcados em azul correspondem à pinagem original do 74HC595 na placa de protótipo.



E uma foto da placa adaptadora montada sobre a placa de protótipo. Na foto não aparece, mas debaixo da placa adaptadora foi necessário colocar um soquete de 16 pinos funcionando como espaçador.


Leitor de SD/MMC: Avanços

Continuando o post anterior, para contornar o problema do "glitch", havia duas opções imediatas:

1) Utilizar um 74HCT595, compatível com a família LS
2) Utilizar um 74HCT4094


A primeira opção não foi testada, pois não foi possível encontrar um 74HCT595, nem um LS. Já o HC é encontrado com facilidade.

A segunda opção também não funcionou, ou melhor, funcionou mas apresentou o mesmo problema do "glitch" fantasma.

Uma terceira opção foi tentada então: Ligar um buffer 74LS245 (ou 244) entre a saída do registrador de deslocamento e o barramento do MSX. Como Tive dificuldade para encontrar um HCT4094 ( o que ue utilizei de testes era um "sample" da Texas), eu preferi utilizar o "buffer" em conjunto com o HC595.


Felizmente, desta vez, o circuito funcionou!!! A configuração utilizada para teste consiste num "loop" da entrada para a saída, ou seja, o byte lido corresponde ao byte escrito na iteração anterior.



A listagem dos programas de teste encontra-se abaixo. A primeira listagem é em assembly e a segunda em Basic.


A montagem em "aranha"da configuração de teste não é apropriada para um uso mais extensivo da placa de protótipos, e vai exigir, por enquanto, uma plaquinha adaptadora.



Assim que esta placa estiver pronta, os próximos passos para o teste do projeto consistirão em:

1) Teste do conversor de tensão 3V~5V
2) Leitura em "loopback" do lado onde o cartão é conectado

Após estes 2 passos terem sido completados, os primeiros testes com o cartão já poderão ser efetuados.

sexta-feira, 8 de dezembro de 2006

Registradores de deslocamento: Mais testes

Apesar do longo tempo que se passou deste a última postagem sobre o leitor de MMC, as atividades de desenvolvimento não pararam. Este tempo foi gasto na investigação de um funcionamento errático do circuito, mais especificamente do registrador de deslocamento de entrada, o 74*595.

O que acontecia é que quanto este registrador continha valores com muitos bits 1, isso bagunçava de alguma maneira o barramento do MSX, gerando um "glitch" no sinal IORQ. Este "glitch" bagunçava toda a sistemática do gerador de clock automático.

Descobrir este problema não foi tarefa fácil, e no momento ainda não tenho causa certa, mas tudo leva a crer que seja causado por incompatibilidade entre a família lógica "HC", do registrador de deslocamento, e a lógica interna do MSX, baseada em chips LS. Um mau funcionamento era até de certa forma esperado, pela mistura de famílias lógicas, mas nunca imaginei que isso fosse bagunçar o próprio barramento do Z80.

Para chegar onde cheguei, foram necessárias várias e várias horas de testes, checando suposições. A descoberta do "glitch" só foi possível por causa de uma das ferramenteas de auxílio à construção do circuito: Um contador externo. Se eu tivesse um osciloscópio talvez já tivesse detectado o problema e resolvido há mais tempo. Utilizando-se o contador, observa-se que quando o "glitch" aparece, em vez da contagem avançar de 1 em 1, ela avança de 2 em 2.

Em linhas gerais, o processo de eliminação do problema consistiu em checar se o endereçamento era feito corretamente. Foi onde se descobriu aparecimento eventual do "glitch".

Em seguida, descobriu-se uma condição específica que fazia o "glitch" aparecer, que era a leitura de um valor "FF".

Depois isolou-se o sinal que transfere os dados do registrador de deslocamento para o latch interno do 595, onde se constatou que o simples recebimento serial do valor "FF" não causava o surgimento do problema.

Depois constatou-se que o problema estava do "latch" interno do 595 para o buffer de saída.

Depois foi preciso isolar todos os circuitos restantes da linha em que o "glitch" aparecia. Tentou-se islolar o sinal de saída do segundo decodificador via um buffer, mas o "glitch" continuava aparecendo.

Em seguida foi feito um programa em assembler que desabilitava todas as outras interrupções, e fazia uma leitura na porta 12. O "loop" de atraso ("delay") é para poder acompanhar visualmente o acendimento dos LEDs do contador.
ORG 9000H
DI
LOOP: LD HL,5FFFH
IN A,(12)
DELAY:
DEC HL
LD A,L
OR H
JR NZ,DELAY
JR LOOP

Com esse programa rodando, descobriu-se que o "glitch" surgia na própria linha IORQ do Z80!

Para eliminar a possibilidade de que qualquer leitura de um valor FF pudesse proporcionar um "glitch", o programa acima foi adaptado para ler a matriz do teclado do MSX, que retorna o valor "FF" se nenhuma tecla estiver sendo pressionada (li a linha 0 do teclado). Nessa situação, o "glitch" não acontecia, o que era bom sinal.

Em seguida, o 74HC595 foi desconectado e em seu lugar foi conectado um 74LS244, cujas entradas foram conectadas a um resitor de pullup com um jumper para selecionar um valor "0" ou "FF". Com este circuito, foi possível ler (tanto o valor "0" quanto) o valor "FF" sem que o "glitch" surgisse.

Conclusão: O 74HC595 é inadequado ao circuito. Em seu lugar tenho como opções imediatas:

1) Utilizar um 74HCT595, compatível com a família LS
2) Utilizar um 74HCT4094


74LS244 em teste, no lugar do HC595

sexta-feira, 1 de dezembro de 2006

NovoCaps: Uma Caps Lock diferente para o Expert

Existem várias soluções para colocar um Led de Caps Lock no Expert, a maioria delas envolve furar o micro; outras, mais inteligentes (p.ex [1]), utilizam LEDs bicolores no lugar do LED de "power".

O Expert não tem um LED de Caps pois o conector de teclado tem apenas 13 pinos, dois quais 12 são usados pela matriz do teclado, e o 13° é utilizado pela alimentação. A malha do cabo foi utilizada para levar o sinal de terra (GND). Um LED de CAPS exigiria um pino a mais, mas este pino não estava disponível. A solução de compromisso encontrada pela gradiente foi "matar" o LED de CAPS.

Mas isso aconteceu no passado. Voltando aos dias de hoje, haveria uma maneira de colocar um LED de CAPS no teclado do Expert, sem ser necessário alterar o "hardware" existente?

Bem, para contornar uma solução de compromisso, normalmente é necessário resolver uma contradição. Eu estava então diante de um problema inventivo, e isso me lembrou o TRIZ.

Uma das ferramentas desta metodologia de resolução de problemas consiste em levantar os recursos disponíveis. Dos 13 fios do conector, apenas 2 não "trafegava informação", que eram exatamente os fios da alimentação. A partir daí, já me surgiu uma solução, mas mesmo assim, dei uma consultada breve nos 40 princípios, e deu pra encontrar mais algumas.

A solução consiste em se utilizar o fio de Vcc (pino 13) para transportar o estado do LED de CAPS, junto com a alimentação. Note que é necessário transportar "alimentação" para o teclado, e não "transportar "+5Volts". Basta então duplicar o regulador de tensão para obter já dentro do teclado, os 5Volts que eu preciso, e utilizar a tensão no fio para identificar o estado do LED.

O circuito do multiplexador e do multiplexador encontram-se abaixo. O Multiplexador é colocado entre o +12Vcc e o pino 13 do conector de teclado (que deve ser desconectado do Vcc), enquanto o demultiplexador é colocado entre o fio que vem do pino 13 e a alimentação do 7448. Um Led bicolor é colocado no lugar do LED original do Expert.


Multipexador



Demultipexador

Quando o caps não está acionado, o transistor do multiplexador fica cortado, e o pino 13 recebe 12 volts. A tensão no pino 3 do 741 é então de 3 volts, enquanto no pino 2 é de apenas 2,5 , fazendo o LED vermelho acender junto com o verde, resultando numa cor amarelo-alaranjada do LED.

Quando o CAPS é acionado, o transistor conduz, fazendo com que a tensão na linha Vcc caia para aproximadamente 7,5Volts. Nesse momento a tensão no pino 3 passa a ser de apenas 2,4Volts, apagando assim a parte vermelha do LED, que fica então na cor verde, indicando que o CAPS está ativo (tal qual o led verde de CAPS do HotBit).

Link para o circuito, diagramas, layout da placa, etc...