Olá,
Conforme
vocês podem ver na foto acima eu comecei a testar o conceito do projeto. Eu já
tinha um eeprom gravada com a Bios da interface CDX-2 e agora eu criei a lógica
no CPLD para atender ao projeto conforme está no diagrama do sistema enviado no
outro e-mail. Uma coisa que eu já desconfiava e agora tenho certeza é que não
será necessário usar o EPM3064, posso o usar o EPM3032 sem problemas. A parte
lógica está usando apenas 13 macrocélulas o que dá para expandir o design mesmo
usando o EPM3032 que é bem barato (U$ 2,50 no ebay). O projeto criado no
Quartus WEB está num arquivo compactado dentro da minha pasta pública do dropbox.
O link segue abaixo:
https://dl.dropboxusercontent.com/u/62498964/CPLD.zip
Eu criei um programinha basic (ver foto acima) com a finalidade de constantemente estar gerando gerando requisições de IO para o endereço D0 e desta forma testar o CPLD observando as formas de onda no meu osciloscópio. Na foto dá pra ver também que a eeprom está funcionando conforme o esperado e a Bios do CDX-2 está ativa e funcionando bem.
De cara
posso garantir que a parte que decodifica o endereço está funcionando perfeitamente.
Abaixo tem uma tabela que demonstra a parte de decodificação.
O
objetivo desta decodificação de endereços é acionar no PIC um
"Interrupt-On-Change" quando os endereços do IO corretos estiverem
presentes no barramento do MSX. Os pinos de seleção serão ligados aos pinos
RB4, RB5, RB6 e RB7 do PIC que possuem o recurso de "interrupção com a
mudança". Ou seja, caso o estado lógico destes pinos se altere é gerado
uma interrupção. Nos PIC18F há dois vetores de interrupção, um de alta prioridade
e outro de baixa prioridade. Eu pretendo usar o vetor de alta prioridade para
atender às requisições de barramento do MSX. Além disto este vetor de
interrupção será escrito em assembler (provavelmente a única parte do programa
escrita em assembler) não só para acelerar o atendimento às requisições do
barramento como para controlar exatamente a temporização da rotina. O que é
difícil de alcançar com uma rotina escrita em C.
O problema agora surgiu na hora de introduzir wait states. Eu criei três pinos no CPLD que selecionam a quantidade de wait states que serão introduzidos caso seja recebida uma requisição de IO válida. O objetivo dos wait states é garantir que o PIC vai ter tempo suficiente para ler e/ou escrever no barramento de dados. Eu não quero criar um número fixo de wait states por dois motivos: 1) Eu não sei se o PIC será ou não capaz de atender às solicitações do barramento sem ciclos de espera (se for possível melhor, mas só vou saber após eu começar a escrever o código para o PIC) e 2) eu não sei se o PIC será capaz de atender as solicitações do barramento em máquinas mais velozes como o Turbo-R (provavelmente não). Por estes motivos é que eu achei importante ter uma forma de introduzir ciclos de espera configuráveis.
O problema agora surgiu na hora de introduzir wait states. Eu criei três pinos no CPLD que selecionam a quantidade de wait states que serão introduzidos caso seja recebida uma requisição de IO válida. O objetivo dos wait states é garantir que o PIC vai ter tempo suficiente para ler e/ou escrever no barramento de dados. Eu não quero criar um número fixo de wait states por dois motivos: 1) Eu não sei se o PIC será ou não capaz de atender às solicitações do barramento sem ciclos de espera (se for possível melhor, mas só vou saber após eu começar a escrever o código para o PIC) e 2) eu não sei se o PIC será capaz de atender as solicitações do barramento em máquinas mais velozes como o Turbo-R (provavelmente não). Por estes motivos é que eu achei importante ter uma forma de introduzir ciclos de espera configuráveis.
Acima tem
uma tela do meu osciloscópio. A linha amarela é o IORQ e a linha azul é o sinal
de clock. O sinal de clock do barramento é usado para cronometrar o tempo total
do sinal de wait state. Na imagem acima o meu programinha basic não está
rodando e portanto o osciloscópio está captando outras requisições de IO que o
sistema do MSX tem que fazer regularmente. As formas de onda estão ruidosas
assim porque estou medindo o sinal que vem de um flat cabe com uns 40 cm de
comprimento e na ponta do conector há fios que extendem ainda mais esta distância
e isto tudo para plugar num protoboard. Ou seja, tem que ter ruído mesmo. Mas a
eeprom está funcionando no protoboard e a parte de decodificação parece estar
funcionando bem.
Na imagem
acima o programinha basic está rodando e curiosamente o tempo de ativação do
IORQ aumentou mas eu posso garantir que não estou introduzindo wait states. E é
ai o problema, mesmo que eu introduza wait states o sinal de IORQ não se
estende conforme seria o esperado. Veja a imagem abaixo.
A linha
azul agora é o sinal de wait state e no caso estou introduzindo apenas um ciclo
de wait state e eu não sei porque o Z80 não está alongando o tempo do IORQ. A
temporização está igual ao datasheet do Z80 com o wait state sendo introduzido
após o T3 e mesmo assim o processador parece não estar amostrando a linha de
wait. Provavelmente eu vou mudar a lógica do CPLD para que a linha de wait
desça junto com o IORQ para ver se o tempo se estende ou não.
Um abraço,
José Paulo
Nenhum comentário:
Postar um comentário