sábado, 31 de março de 2007

Outra Atualização de Status

Outra atualização de Status, com as atividades que faltam, antes do primeiro "release" do projeto:
  • Atualizar o guia de montagem e teste;
  • Atualizar o "layout" das placa do cartucho de adaptação por causa de uma discrepância entre a furação da placa biblioteca da caixa Patola e a caixa real.
  • Medir o consumo do circuito, durante uma gravação do cartão
  • Disponibilizar todos os diagramas e "lay-outs" em formato Eagle, EPS e GIF;
  • Disponibilizar todas as listagens e os arquivos .wav dos "drivers" e dos programas de teste

Programa de teste de SD/MMC concluído

Concluí o programa que testa a interface com cartões SD e MMC. Eu fiz uma ligeira modificação no programa em assembler, para registrar o incremento da variável JIFFY (timer do MSX) e poder ter um 'benchmark' da velocidade de transferência . Eis um vídeo do programa rodando com um cartão SD inserido no soquete, e mais abaixo abaixo a captura das telas com um cartão MMC e um SD.

leitura CID/CSD com cartão MMC


leitura e escrita com cartão MMC


leitura CID/CSD com cartão SD


leitura e escrita com cartão SD

Versão 1.0a da placa da interface HB-7000

Esta versão da placa é feita especialmente para ser ligada ao conector traseiro do Expert, através de um cabo "flat" de 50 vias.


sexta-feira, 30 de março de 2007

BUSDIR

Em conversa com o Igor, discutindo a utilização do sinal BUSDIR, chegamos às seguintes conclusões:
  • O MSX não utiliza a linha BUSDIR para fazer DMA (ao contrário do que eu imaginava);
  • O sinal BUSDIR serve para mudar a direção dos 'buffers' de saída colocados no barramento do MSX em três duas situações:
  1. Leitura em memória num SLOT via sinais /RD e /SLTSL;
  2. Leitura de uma porta de I/O via instruçaõ IN/INI/INIR (ou INP do Basic);
  3. Colocação de um vetor de interrupção no barramento, em modo de interrupção 2 do Z80, pois nesta situação o sinal /RD fica em nível alto;
Estas informações podem ser encontradas na página 36 do "MSX Technical Data Book".

Só que em nossa discussão, encontramos um problema no circuito de controlde de busdir da página 35 do 'Data Book'.



O problema desse circuito é que quando DOIS ou mais de um expansores com 'buffer' interno forem ligados ao mesmo tempo, todos os buffers serão acionados, causando assim um conflito que pode inclusive queimar os 'buffers' (isso sem contar que a porta NOR teria que ser 'open collector'). Isso ocorre porque a linha /BUSDIR está ligada diretamente ao controle de habilitação do 'buffer'

Tudo bem que o esquema no 'Data Book' seja mais um 'guideline' do que um esquema propriamente dito, mas uma possível soluão para este problema pode ser "comparando" o comando para habilitar o 'buffer' com o sinal da linha /BUSDIR. Se o sinal /BUSDIR_INTERNO baixar, então o 'buffer tristate' força a linha /BUSDIR a baixar, e na saída da porta OR, o sinal vai zer 'ZERO', acionando assim o 'buffer' do expansor.

Por outro lado, se nenhuma operação deste expansor estiver ativando a linha /BUSDIR_INTERNO, e porventura o outro expansor ativar a linha /BUSDIR, então o sinal na saída da port OR vai ser 'UM', o que não habilita o buffer de saída.




Modificando um pouco o circuito do 'Data Book', e adaptando para usar um 'buffer' bidirecional 'tristate' (LS245), em vez de dois unidirecionais, temos:



Note que foi necessário envolver o sinal de /WR para escolher a direção do 'buffer', e para habililá-lo numa operação de escrita.

Simplificando a lógica, usando apenas um CHIP para fazer as funções das portas AND e OR, e substituindo o 'buffer' tristate por um MOSFET, temos:

quinta-feira, 29 de março de 2007

Versão 1.0 da placa da interface HB-7000

concluí hoje o roteamento da versão 1.0 da placa da interface HB-7000, já com conector de 34 pinos e controle (opcional) do sinal /BUSDIR.

A incorporação do sinal Busdir, foi para fazer esta placa 100% compatível com o padrão MSX, mas incluí também um "jumper" que permite desconectar o sinal /BUSDIR, para os casos em que o circuito vá operar conectado diretamente ao barramento de um micro que possua um expansor de slots com "buffer" interno cujo circuito não tenha sido projetado pensando na utilização de 2 ou mais expansors simultaneamente.

quarta-feira, 28 de março de 2007

Busdir

Um requisito de última hora, resultado de uma conversa com o Igor sobre BUSDIR.
Para estar demtro da norma, um periférico que utilize leitura em I/O deve gerar o sinal BUSDIR com base nos sinais /IORQ, /RD e da lógica de decodificação interna.

Eu utilizei dois "buffers tristate" ociosos do 74HCT125 para gerar um sinal /BUSDIR a partir dos sinais /RD0 e /RD1.

domingo, 25 de março de 2007

Quadrado Mágico

Numa conversa com o Igor sobre um expansor de slots ele me passou alguns requisitos para um expansor de slots.

  • Qualquer "slot" físico deve poder receber qualquer sinal de expansão
  • Deve ser possível atribuir a dois "slots" físicos um mesmo sinal de expansão

Pensei bastante numa solução que pudesse atender a tais requisitos sem gastar muitos jumpers, e sem ocupar espaço demais na placa.

A solução foi o "quadrado mágicos". Os sinais de expansão A,B,C,D são entrelaçados com os sinais SLSLT (1,2,3,4) que vão aos 4 slots físicos, conforme a figura abaixo. O nome de "quadrado mágico" surgiu porque para obter uma configuração válida, basta dispor todos os jumpers paralelamente, numa mesma fileira, seja horizontal, seja vertical. As possibilidades são inpumeras, e cobrem todas as 24 combinações de seleção possíveis.



Na placa basta dispor 4 "headers" de 4 pinos uma ao lado da outra, para configurar, basta colocar 4 jumpers entre os pinos.




Eis alguns exemplos:

"padrão": A-1 B-2 C-3 D-4


Variação: A-3 B-4 C-1 D-2


"Inverso": A-4 B-3 C-2 D-1



E aqui um exemplo de como associar um mesmo sinal de expansão a 2 slots físicos. Os Slots físicos 3 e 4 receberam ambos o sinal de expansao C (EXP3)

A-1 B-2 C-3-4

sexta-feira, 23 de março de 2007

Cálculos para a rotina de teste de escrita

Achei a conta que tenho que fazer. Eu preciso calcular o endereço da metade do cartão. Eu já sei calcular o tamanho em blocos de 512bytes.

Apesar das operações de transferência com o cartão serem sempre em blocos, o padrão de endereçamento de dados é byte a byte, usando 32 bits A3-A2-A1-A0, onde A[3..0] têm 8 bits cada um. Apesar disso, todas as operações de leitura e escrita têm que utilizar alinhamento de bloco, ou seja, têm que ser múltiplos de 512bits, senão o cartão reporta um erro de endereçamento ilegal.

Para realizar o teste de escrita, eu escolhi escrever em uma sequência de blocos que fica na metade do tamanho máximo do cartão, pois aí certamente será uma área de dados, e já estará depois da FAT.

Como eu utilizo um programa Basic que faz interface com um programa em Assembler, eu preciso converter o tamanho em blocos num número que corresponda ao endereço da metade do cartão,

Então faço o seguinte:

T_Blocos=Tamannho em blocos de 512 bytes
TBH= int(T_blocos/65536)
TBL= T_blocos-TBH*65536

B4=int(TBH/256)
B3=TBH-B4*256
B2= int(TBL/256)
B1= TBL-B2*256

Com este cálculo eu transformo o valor T_blocos em 4 bytes, B4,B3,B2,B1. O cálculo de B4 é mais para a conta ficar genérica, pois dado que o cartão SD/MMC utilizam 32 bits para endereçar, ou seja, suporta apenas 4GB. O valor de A4 vai ser sempre 0.

Dado que cada bloco tem 512 bytes, para obter a posição do último byte do cartão, eu tenho que multiplicar o tamanho em blocos por 512. Assim para para obter a posição do byte que fica na metade do cartão, eu tenho que multiplicar o tamanho em blocos por 256, ou seja, deslocar 8 bits para a esquerda.

Isso é feito utilizando-se como endereço:

A0=0
A1=B1
A2=B2
A3=B3

Vou implementer estas rotinas no programa Basic e continuar o trabalho.

quarta-feira, 21 de março de 2007

Módulo RTC (atualizado)

Dando prosseguimento às atividades, reprojetei a placa do módulo de relógio RTC para poder comportar 4 tipos de baterias diferentes:
-CR2032, CR2430, Ni-Cd mini ou uma bateria genérica, ligada à placa através de 2 terminais.

O layout mudou ligeiramente, como dá pra ver na figura abaixo.


Um pacote com todos os arquivos encontra-se neste link

domingo, 18 de março de 2007

Mais uma Atualização de Status

Mais uma atualização de Status, mas agora apenas com as atividades que faltam, antes do primeiro "release" do projeto:
  • Finalizar o programa de teste para SD/MMC
  • Atualizar o guia de montagem e teste;
  • Atualizar o "layout" das placas da interface de cartões e do cartucho de adaptação. Este último por causa de uma discrepância entre a furação da placa biblioteca da caixa Patola e a caixa real.
  • Corrigir e atualizar o "layout" do Módulo RTC, que tinha uma inversão entre os sinais SDA e SCL, que tem que ser corrigida. Além disso vou dotar a placa de pelo menos 4 opções de soquete para bateria: CR2420, que estou usando, CR2032 que pode ser aproveitado de uma placa velha de PC, Ni-CD mini, também pode ser aproveitada de uma fonte de PD, e um par de terminais, para ligar qualqer outro tipo de bateria que forneça 3V.
  • Medir o consumo do circuito, durante uma gravação do cartão
  • Disponibilizar todos os diagramas e "lay-outs" em formato Eagle, EPS e GIF;
  • Disponibilizar todas as listagens e os arquivos .wav dos "drivers" e dos programas de teste

Alguns comentários, sobre outras atividades, a serem executadas, mas somente depois do "release" inicial estão comentadas abaixo:

-Testar o circuito em 8MHz. Para isso eu preciso de conseguir um MSX que rode a 8MHz. Não conheço ninguém que tenha um. Talvez em algum encontro de MSX...

-Arranjar uma alternativa para o conversor de tensão 3V-5V atual. O circuito atual, embora bem simples, funciona bem. Nem o chaveamento (liga/desliga) é necessário, quando se utiliza um soquete específico de SD/MMC, que liga primeiro os pinos de VCC e GND, assim que o cartão é inserido. Além disso fiz vários testes de "hot insert/removal" no soquete improvisado sem danificar o cartão, enquanto os soquetes de SD/MMC ainda não tinha chegado da Farnell.

-Testar com outros cartões SD/MMC. Eu só tenho 2 modelos de cartão, um SD e outro MMC. Pretendo testar com mais cartões, mas tenho consegui-los emprestados.



Programa de Teste dos Cartões

O programa de teste dos cartões SD/MMC já avançou bastante. A parte mais trabalhosa, que envolve fazer as contas já está pronta.

Agora já consigo saber o tamanho em blocos do cartão. Este número será dividido por 2 e passado para a parte do programa que executa um teste de gravação.

Achei estranho o tamanho ser ligeiramente menor do que a capacidade nominal, ou seja, um cartão de 128MB tem na realidade algo em torno dos 120MB.

Seguem abaixo duas telas do programa.

Tela do programa com um dos cartões MMC


Tela do programa para o cartão SD

sábado, 17 de março de 2007

Rotinas de leitura de CSD e CID

Terminei ontem de madrugada as rotinas de leitura de CSD e CID dos cartões SD/MMC. Complementei o driver com um programinha de teste básico, que permite 4 operações:

  • Ler CSD
  • Ler CID
  • Ler blocos do cartão
  • Escrever blocos no cartão.

Agora só está faltando escrever um programa em Basic para compor um programa de teste funcional da interface.

O código está neste link.

Complementando o "post", os dados do CSD e CID dos cartões sob teste:

MMC CARD1
CSD
90 26 01 2A 0F 59 00 F4
F6 DB 1F FF 92 40 40 2F
CID
15 00 00 30 30 30 30 30
30 11 D0 06 D5 91 B8 00


MMC CARD2
CSD
90 26 01 2A 0F 59 00 F4
F6 DB 1F FF 92 40 40 2F
CID
15 00 00 30 30 30 30 30
30 11 D0 06 CD 39 B8 00


SD CARD
CSD
00 36 00 32 17 59 81 DF
76 DA FF 81 96 40 00 C1
CID
18 49 4E 31 32 38 4D 42
04 40 A7 DE 3D 00 B3 4B

CRC nos comandos do cartão MMC

Quando os cartões SD e MMC operam em modo SPI eles ignoram (por default) o CRC dos comandos enviados; porém passei um bom tempo pra descobrir que o cartão MMC que eu estou testando se recusava a enviar o "data token" quando a CRC "dummy" enviado no final do comando era "00" (zero). Quando desconfiei disso, mudei para 0FFh (255), e o problema foi resolvido. Eu desconfio (embora não tenha testado) que manter o bit 0 (zero) do byte de CRC em nível lógico alto, já resolva o problema. Interessante que para o cartão SD este valor não fez a menor diferença.

De qualquer forma, embora o CRC dos comandos dos cartões SD/MMC seja ignorado, é recomendável utilizar o valor OFFh para evitar surpresas.

sexta-feira, 16 de março de 2007

Analisando o uso de uma CPLD/FPGA

Estou analisando uma versão do circuito implementada em CPLD/FPGA. Já desenhei e simulei o gerador de clock automático, que é o coração do circuito do leitor de SD/MMC.


Gerador de clock: Consumiu 6 macro-células. Eu estimo que o projeto vá caber numa EPM3032. Tira um pouco a graça de quem gosta de montar um circuito com bastantes integrados, mas economiza espaço.



Resultado da simulação. A primeira forma de onda é o sinal de "reset" do gerador de "clock" automático, a segunda é o "clock", e a terceira é a saída de pulsos de "clock"

Expansor de Slots

Andei estudando a viabilidade de transportar o circuito de expansor de slots que vi no MSXpro para dentro de um FPGA. A conclusão é que é viável implementar o circuito utilizando uma EPM3032, de 32 macro células, que custa R$8,00 na Farnell. Esta série de EPLDs funciona com um "core" de 3,3Volts, mas trabalham bem com lógica de 5V. E são mais baratas do que as da série 7000. Coube tudo nesta EPLD com folga, pois apenas 13 macrocélulas, de um total de 32 foi utilizada, mas é preciso utilizar 32 dos 34 pinos disponíveis. Se forem utilizados 2 74LS30s externamente, dá pra liberar o uso de 14 pinos, o suficiente pra implementar o controle de BUSDIR.

Status do Projeto

Mais uma atualização de "Status" dos requisitos.


Requisitos de Hardware:
O hardware...

-Deverá utilizar o espaço de endereçamento de I/O do Z80, dentro do padrão MSX (abaixo de 040h);
Cumprido. O circuito foi projetado para funcionar nas portas 12 e 13 do endereçamento de I/O do Z80. Os drivers do programa utilizam endereçamento relativo, via registrador C e suportam operação em quaisquer 2 portas consecutivas, sem necessidade de adaptação do código.

-Deverá utilizar o clock do Z80 como fonte de clock;
Cumprido. Comprovação pelo próprio projeto.

-Deverá suportar um clock (do Z80) de até 7,16MHz;
Teste a 3.5MHz ok. Simulação até 8MHz .

-Deverá ser capaz de gerar um clock numa frequência inferior a 400KHz, para inicialização do cartão;

Cumprido. O circuito possui um sinal de clock alternativo. A frequência do sinal de clock alternativo é definida por software, alternando-se o tempo em que o sinal de clock alternativo fica em nível alto e nível baixo.

-Deverá realizar a transferência de dados de forma bidirecional, conforme padrão SPI (transmite e recebe ao mesmo tempo);

Cumprido.

Deverá realizar uma transferência de blocos através de instruções de I/O de bloco (INI, INIR, OUT, OTIR), tão rápido quanto possível para o Z80;

Cumprido.

- Deverá realizar transferência de bytes num tempo igual ao do MSX para fazer acessos consecutivos de I/O;

Cumprido (acessos consecutivos automáticos - INI, INIR, OUTI, OTIR)

- Deverá ser possível implementar a interface sem a necessidade de chips de lógica programável, utilizando apenas componentes comuns no mercado: chips TTL, resistores e capacitores de famílias padrão;

Cumprido.

- Deverá haver um LED indicador de acesso ao cartão.

Cumprido. Um LED vermelho foi utilizado.

- Deverá haver um LED indicador de que a alimentação do cartão está ativa.

Cumprido. Um LED verde foi utilizado.

- Deverá suportar Inserção/Remoção/troca do cartão sem necessidade de se desligar o computador.

Cumprido.

- Deverá possuir um conversor para alimentar o cartão MMC/SD, fornecendo uma tensão entre 2,8V e 3,6V, com capacidade de pelo menos 100mA;

Cumprido. Mas está sendo estudada a possibilidade de alternativa para o conversor atual. Uma boa possibilidade é a transferênica deste conversor para para uma placa auxiliar, cuja ligação com a placa principal se dará por apenas 4 fios. Esta placa auxiliar pode conter várias alternativas (BJT, JFET, LDO, chaveados, etc), dependendo da disponibilidade de componentes de quem for montar o projeto.

-O circuito deve ser projetado de forma a consumir pouca energia.

Cumprido. O circuito utiliza chips de tecnologia HCT e HC. O consumo ainda não foi medido.


-Todos os diagramas e "lay-outs" devem ser disponibilizados;

Em andamento. O protótipo 2 está sendo reformulado para refletir as alterações sofridas durante os testes e experimentações.

-A placa de circuito impresso da versão final deve ser projetada de forma a permitir a montagem caseira (refs [1] [2] [3]);

Em andamento. aguardando o circuito chegar à versão final. Mas todas as placas de protótipo até o momento foram construídas utilizando este método, em placas de face simples.


-Deverá possuir suporte para um relógio de tempo Real I2C;

Cumprido. Módulo RTC já construído, e testado.

-Deverá possuir circuitos de teste auxiliares, montados em placa externa, para auxiliar no teste dos vários blocos que compõem o circuito, de forma a suportar a construção e teste gradual da interface;

Cumprido. Uma sonda lógica foi projetada especialmente para auxiliar na montagem deste circuito.

-Deverá possuir um guia de montagem que suporte a construção e o teste gradual da interface;

Em andamento. Pendente revisão do guia após definida versão "release" de hardware.


Requisitos de Software:

-Todo o código fonte será disponibilizado sob licença GPL;

Em andamento. Drivers básicos SD/MMC em estágio avançado de desenvolvimento. Drivers I2C já foram reescritos e testados.

-Deverá haver um software de testes que suporte o teste dos vários blocos que compõem o circuito, de forma a suportar a construção e teste gradual da interface;

O guia de montagem e teste substitiu tal software. Programa de teste para relógio de tempo real já escrito e testado. Programa de teste para SD/MMC ainda precisa ser escrito.

-Deverão ser implementadas as rotinas de baixo nível destinadas à inicialização e identificação do cartão, bem como à leitura, escrita e apagamento de blocos de memória;

Rotinas de inicialização, escrita e de leitura prontas. Rotinas de identificação de fabricante e capacidade de disco ainda não escritas. Rotina de pré apagamento será desconsiderada, dada a velocidade de gravação já obtida sem tal rotina.

-O software deverá suportar cartões MMC e SDC;

Cumprido. A rotina de inicialização prevê ambos os tipos. Testado em um cartão SD e um cartão MMC

-Deverão ser implementadas as rotinas de baixo nível para acesso ao relógio de tempo real;

Cumprido. Drivers I2C já testados, e suportam a operação básica do relógio de Tempo Real

Testes com MMC: Benchmarks

Acabei de realizar agora, com sucesso, um teste com 2 cartões MMC de 128Mbytes.



A Performance de escrita e de leitura foi praticamente igual à do cartão SD (vide tabela abaixo). Interessante é que embora os cartões MMC sejam de mesma marca e modelo (SAMSUNG MMC+PLUS 2 - 128MB), a velocidade de leitura de um é ligeiramente diferente da do outro.

Cartão Leitura Escrita
SD 167 145
MMC 1 163 145
MMC 2 154 145

Unidade Kbytes/s

segunda-feira, 12 de março de 2007

Software de Teste RTC concluído.

Terminei o software de teste do modulo RTC. É um programa Basic que funciona em conjunto com uma rotina em assembler. Nada muito rebuscado. Apenas o suficiente para um teste funcional, afinal este programa foi criado como complemento ao guia de montagem e teste.

Eis abaixo um "screenshot" do mesmo. A opção "P" acerta o relógio para as 23:59:30 de 31/12/1999, para fica mais fácil de ver todos os dígitos mudando. Os sinais de Exclamação são o sinal de OK da rotina de leitura do relógio, com o "verbose" ligado.



Para acertar, a hora basta pressionar "A" (ou qualquer outra tecla que não seja "Q" e "P"), e entrar os dados um por um. Caso se deseje manter algum valor, basta pressionar . O programa checa também as faixas de valores válidos.

As listagens em Basic e Assembler encontram-se nos links abaixo:
rtc-tst001.bas
I2C007.asm

domingo, 11 de março de 2007

Picodrives

Utilizando uma EEPROM serial, montei um "Picodrive" para ser ligado à porta de joystick. Os pinos bidirecionais 6 e 7 da porta de joytick são perfeitos para os sinais SDA e SCL do protocolo I2C. Já tenho grande parte do código escrita, e assim que tiver tempo vou mexer um pouco mais nisso, e no sistema de arquivos simplificado que criei para dispositivos até 128Kbytes de capacidade de armazenamento.

Placa com adaptador SD/MMC

Este final de semana trabalhei no novo "layout" da placa adaptadora de cartão MMC. É que pra caber na "soleira" do Hotbit tem que ter no máximo 3,5cm de largura, e a placa que montei (vide foto abaixo) tem um pouco mais que isso.




Um detalhe importante é que se o cartão estiver sendo utilizado com seu soquete específico, ele não precisa de que a linha Vcc seja chaveada, ou seja, pode ficar alimentado o tempo todo, tornando assim opcional o uso do sinal +P3V3ON e do LED indicador de alimentação.

Somente para ilustrar, segue abaixo uma foto da placa adaptadora já montada, mas não ainda em sua versão final.

sexta-feira, 9 de março de 2007

Finalizando...

O projeto agora está quase finalizado. falta cumprir alguns requisitos mais importantes:

  • Testar com o cartão MMC
  • Escrever o programa de teste de cartão SD/MMC
  • Escrever rotinas de identificação de cartão.
  • Escrever o programa de teste do relogio RTC (metade já escrito)
  • Revisar o guia de montagem e teste (de preferência montando uma nova placa isso)
  • Ajuntar a documentação - códigos fonte, licença GPL, arquivos Eagle, Postscript e GIF com os diagramas e as imagens das placas de circuito impresso.

Há ainda alguns requisitos que não considero importantes agora, pro primeiro "release" do projeto.

  • Testar a 8MHz (nem sei onde arranjar um MSX a 8MHz!)
  • Medir o consumo de corrente (leitura e escrita)
  • Estudar alternativas pro conversor 5V-3V. O que tem já funciona bem, mas gostaria de dar opções.
  • Rotinas de pré apagamento de setores.

RTC testado!!

Deixei o micro algumas horas desligado, e voltei a ligar hoje novamente, pra testar modulo RTC. A hora, como não poderia deixar de ser, continua funcionando normalmente. Quem foi que disse que o MSX1 não tem Relógio de tempo real, hein??

Modulo RTC testado. Já esta funcionando!

Acabei de testar o funcionamento do módulo RTC. Escrevi duas rotinas básicas pra ler e pra escrever os registros do PCF8563. A estrutura dos registros encontra-se na figura abaixo.


(clique na imagem para ampliar)

Fiz também um programa em Basic para ler o módulo RTC via I2C e imprimir na tela os valores lidos. Uma coisa importante é mascarar os bits não implementados dos registros, pois eles mudam de estado eventualmente.

Fiz vários testes, inclusive desconectar o módulo da interface com o programa rodando (e o micro ligado). Depois reconectei o módulo e a hora se manteve... como tinha que ser, ne??

quinta-feira, 8 de março de 2007

I2C: Progressos

Consegui finalmente encontrar o erro nas minhas rotinas de I2C. Consegui agora há pouco que o relógio de tempo real e uma E2PROM serial me respondessem um "acknowledge", quando interrogados em seus endereços corretos.

Eis o trecho do código que não estava funcionando, e a pequena correção, destacada em vermelho.

10750 I2CPB: ; PUT BYTE
10760 PUSH BC
10770 LD D,A
10780 LD B,8
10790 I2PB1: XOR A
10800 SLA D
10810 ADC A,SDALO
10820 OUT(C),A
10830 LD A,SCLHI
10840 OUT(C),A
10850 DEC A ; A=SCLLO
10860 OUT (C),A
10870 DJNZ I2PB1

Se eu não inicializar o valor de A com Zero, a soma com SDALO+CY vai dar um valor indefinido.

Eu tive que corrigir este mesmo erro em outro trecho do código, mas depois consegui fazer a leitura sequencial de vários bytes na E2PROM.

11150 I2CAK:;GIVE ACK CY=VALOR ACK
11155 XOR A
11160 ADC A,SDALO
11170 OUT (C),A
11180 LD A,SCLHI
11190 OUT (C),A
11200 DEC A
11210 OUT (C),A
11220 LD A,SDAHI
11230 OUT (C),A
11240 RET
Segue abaixo a captura da tela, lendo um trecho já conhecido da E2PROM

quarta-feira, 7 de março de 2007

I2C: um capítulo à parte.

Em meio à luta para desenvolver a interface I2C, descobri um erro no módulo RTC. As linhas SDA e SCL estão trocadas.

segunda-feira, 5 de março de 2007

Um benchmark mais cuidadoso

Andei pensando numa maneira de fazer um benchmark mais cuidadoso da escrita e da leitura do cartão. Fui dar uma olhada no "livro vermelho" do MSX vi que a cada 1/60 de segundo (16,67ms) o MSX incrementa o valor da variável de sistema JIFFY (FC9Eh).

Como o "driver" do HB-7000 não desabilita as interrupções, usei o código abaixo para fazer um "benchmark" mais preciso do que no olhômetro.

LD HL,0000h
LD (JIFFY),HL
Transfere 128Kbytes
LD HL,(JIFFY)
Imprime HL
Com o "verbose" desligado, consegui os seguintes valores da variável "JIFFY" ao final dos 128Kbytes:

Escrita: 53 * 1/60 = 0,883 segundos => 144,90Kbytes/segundo

Leitura: 46 * 1/60 = 0,766 segundos => 166,95Kbytes/segundo


Acho que tá bom, ne?

O código encontra-se neste link.


Agora é hora de me concentrar no "driver" I2C pro relógio de tempo real. Acho que o projeto já está bem próximo de um "baseline".

domingo, 4 de março de 2007

Status do Projeto

Mais uma atualização de "Status" dos requisitos.


Requisitos de Hardware:
O hardware...

-Deverá utilizar o espaço de endereçamento de I/O do Z80, dentro do padrão MSX (abaixo de 040h);
Cumprido. O circuito foi projetado para funcionar nas portas 12 e 13 do endereçamento de I/O do Z80. Os drivers do programa utilizam endereçamento relativo, via registrador C e suportam operação em quaisquer 2 portas consecutivas, sem necessidade de adaptação do código.

-Deverá utilizar o clock do Z80 como fonte de clock;
Cumprido. Comprovação pelo próprio projeto.

-Deverá suportar um clock (do Z80) de até 7,16MHz;
Teste a 3.5MHz ok. Simulação até 8MHz .

-Deverá ser capaz de gerar um clock numa frequência inferior a 400KHz, para inicialização do cartão;

Cumprido. O circuito possui um sinal de clock alternativo. A frequência do sinal de clock alternativo é definida por software, alternando-se o tempo em que o sinal de clock alternativo fica em nível alto e nível baixo.

-Deverá realizar a transferência de dados de forma bidirecional, conforme padrão SPI (transmite e recebe ao mesmo tempo);

Cumprido.

Deverá realizar uma transferência de blocos através de instruções de I/O de bloco (INI, INIR, OUT, OTIR), tão rápido quanto possível para o Z80;

Cumprido.

- Deverá realizar transferência de bytes num tempo igual ao do MSX para fazer acessos consecutivos de I/O;

Cumprido (acessos consecutivos automáticos - INI, INIR, OUTI, OTIR)

- Deverá ser possível implementar a interface sem a necessidade de chips de lógica programável, utilizando apenas componentes comuns no mercado: chips TTL, resistores e capacitores de famílias padrão;

Cumprido.

- Deverá haver um LED indicador de acesso ao cartão.

Cumprido. Um LED vermelho foi utilizado.

- Deverá haver um LED indicador de que a alimentação do cartão está ativa.

Cumprido. Um LED verde foi utilizado.

- Deverá suportar Inserção/Remoção/troca do cartão sem necessidade de se desligar o computador.

Cumprido.

- Deverá possuir um conversor para alimentar o cartão MMC/SD, fornecendo uma tensão entre 2,8V e 3,6V, com capacidade de pelo menos 100mA;

Cumprido. Mas está sendo estudada a possibilidade de alternativa para o conversor atual. Uma boa possibilidade é a transferênica deste conversor para para uma placa auxiliar, cuja ligação com a placa principal se dará por apenas 4 fios. Esta placa auxiliar pode conter várias alternativas (BJT, JFET, LDO, chaveados, etc), dependendo da disponibilidade de componentes de quem for montar o projeto.

-O circuito deve ser projetado de forma a consumir pouca energia.

Cumprido. O circuito utiliza chips de tecnologia HCT e HC. O consumo ainda não foi medido.


-Todos os diagramas e "lay-outs" devem ser disponibilizados;

Em andamento. O protótipo 2 está sendo reformulado para refletir as alterações sofridas durante os testes e experimentações.

-A placa de circuito impresso da versão final deve ser projetada de forma a permitir a montagem caseira (refs [1] [2] [3]);

Em andamento. aguardando o circuito chegar à versão final. Mas todas as placas de protótipo até o momento foram construídas utilizando este método, em placas de face simples.


-Deverá possuir suporte para um relógio de tempo Real I2C;

Parcialmente cumprido. "Hardware" necessário já pronto e testado. Módulo RTC já construído, mas ainda não testdo.

-Deverá possuir circuitos de teste auxiliares, montados em placa externa, para auxiliar no teste dos vários blocos que compõem o circuito, de forma a suportar a construção e teste gradual da interface;

Cumprido. Uma sonda lógica foi projetada especialmente para auxiliar na montagem deste circuito.

-Deverá possuir um guia de montagem que suporte a construção e o teste gradual da interface;

Em andamento. Pendente revisão do guia após definida versão "release" de hardware.


Requisitos de Software:

-Todo o código fonte será disponibilizado sob licença GPL;

Em andamento. Drivers básicos SD/MMC em estágio avançado de desenvolvimento. Drivers I2C precisam ser reescritos e testados, para suportar o relógio de tempo real.

-Deverá haver um software de testes que suporte o teste dos vários blocos que compõem o circuito, de forma a suportar a construção e teste gradual da interface;

O guia de montagem e teste substitiu tal software. Entretanto, 2 programas de teste necessitam ainda serem escritos; um para SD/MMC e outro para I2C.

-Deverão ser implementadas as rotinas de baixo nível destinadas à inicialização e identificação do cartão, bem como à leitura, escrita e apagamento de blocos de memória;

Rotinas de inicialização, escrita e de leitura prontas. Rotinas de identificação de fabricante e capacidade de disco ainda não escritas. Rotina de pré apagamento será desconsiderada, dada a velocidade de gravação já obtida sem tal rotina.

-O software deverá suportar cartões MMC e SDC;

A rotina de inicialização prevê ambos os tipos. Testado em um cartão SD. Ainda não testado com um cartão MMC.

-Deverão ser implementadas as rotinas de baixo nível para acesso ao relógio de tempo real;

Drivers I2C precisam ser reescritos e testados, para suportar o relógio de tempo real

Atualizando o protótipo

Modifiquei o protótipo 2 que tenho montado para torná-lo representativo da versão final. Troquei as linhas D0 e D7, pois isso vai me fazer ganhar um pouco de velocidade na interface I2C. Isso significa também que vou ter que fazer uma atualização do guia de montagem e testes. Quanto aos drivers que estão escritos, basta mudar o valor das linhas EQU no inicio do programa, e nada mais.




A maior vantagem nesta mudança, é permitir controlar o nível do sinal de saída do 259 a partir do bit D0. Assim posso usar trechos de código como:

XOR A
RR E (registro E contém o dado)
ADC A,I2CSdaLo
OUT (C),A

ou, para gerar um pulso de clock,

(Registro D contém I2CSckLo)

INC D
OUT (C),A
DEC D
OUT (C),A


Montei e testei também a placa com o conector de MMC. Coloquei 2 Leds: um verde pra indicar VCC ligado, e outro vermelho pra indicar CS ativo (baixo). Ficaram bem legais. É impressionante ver que os leds dão apenas uma piscadinha, ao escrever um bloco de 16K no cartão, coisa que leva uns 3 minutos no meu gravador cassete...

[]s
Daniel

Placa do MSXDOS2+adaptaror HB-7000

Corroí neste final de semana a placa para o cartucho MSXDOS2+adaptador de 34 vias para o HB-7000.

Fiz as placas usando o método de transferênica de "toner". As duas faces foram feitas de uma vez só e o alinhamento ficou muito bom. Eu fiz, basicamente, os seguintes passos:

- Gerei os 2 "layouts" em formato .eps no eagle. A face de cima eu gerei com a opção "upside down", pra ficar "de cabeça pra baixo

Inseri as figuras dentro de uma arquivo de texto no openoffice.org, e alinhei as duas à esquerda da folha. Deixei um espaço de aproximadamente 1 cm entre elas.

Imprimi esta folha utilizando o "driver" eps.

Nota: Também é possivel fazer isso usando bitmaps da imagem das faces (ou GIF,PNG,etc) :). O importante é ficar uma de cabeça pra baixo em relação à outra.

Imprimi a folhas em papel "couchet", e peguei a folha já impressa, dobrei ela ao meior de forma a alinhar a furação das duas faces.

passei cola nas bordas laterais, formando uma espécie de "envelope".

Cortei a placa praticamente na medida final e coloquei dentro do "envelope".

Vim com o ferro de passar e fui esquentando gradualmente, pro toner derreter. Fiz isso nas duas faces, virando de tempos em tempos o conjunto.

Depois que o papel estiver ja bem preso, é necessário passar um estilete no ponto da dobra, de forma a deixar as metades das folhas "livres". Eu não fiz isso e precisei retocar depois com a caneta de placa, pois na dobra o papel tende a levantar.

Depois corroí e furei.

O desalinhamento não foi muito. menos de 1/2 mm em alguns pontos apenas. Talvez se eu tivesse passado o ferro mais frio no começo tivesse sido melhor, mesmo assim ja estou muito satisfeito com o resultado, mesmo apesar de ter errado a mão no ferro de passar. Poderia ter deixado ele ligeriramente mais quente.
.

sexta-feira, 2 de março de 2007

Acerto na rotina de inicialização.

Eu mexi mais um pouco na rotina de inicialização.

Eu computei corretamente o valor de HL para o Delay de 1ms assim que a alimentação do cartão é ligada.

Eu tinha notado que o cartao algumas recusava-se a inicializar quando removido com o seu Vcc ainda ligado. Ciclando-se a alimentação ele inicializava - out (13),129 :out(13),1 .

Quando coloquei o delay de 1ms no inicio da rotina, eu chutei um valor pra HL que acabou resolvendo o problema, mas quando fui computar, em vez de 1ms eu estava aguardando 180ms!

Lendo de novo a especificação do cartão, eu reparei que o tempo de resposta ao comando CMD1 (ou ADMD41) é da ordem de centenas de milissegundos. Algumas implementações de interfaces de leitura destes cartões com microcontroladores chegam a aguardar 1segundo antes de sinalizar um erro.

O código anterior usava o contador B num "loop" para aguardar a resposta correta ao comando CMD1(ACMD41). Isso resultava num "loop" com um tempo menor que 40ms. Como o cartão não respondia neste tempo, a rotina retornava erro.

Refiz a rotina de inicialização, colocando o "delay" pós "power-up" de 1ms e usando um "loop" que dura no minimo 800ms. Agora funciona mesmo quando eu tiro o cartão e o recoloco.

Deu pra notar também que o tempo de acesso ao cartão reduziu. Antes o tempo de inicialização era perceptível (180ms). Agora nem dá pra notar.

Agora falta refazer alguns calculos apenas, pro segundo loop de inicialização, que envia os comandos ACMD41, caso o CMD1 falhe (alguns SDs precisam ser iniciados com dessa maneira). O Valor de HL muda, pois o comando ACMD41 é uma sequência de envio dos comandos CMD55 e CMD41, ou seja, gasta mais ciclos de "clock". Consequentemente o valor de HL vai ser menor.

Segue abaixo uma captura da tela, com 3 execuções simultâneas.

  • Na primeira o cartão inicializou sem problemas
  • Na segunda eu retirei fora o cartão.
  • Na terceira eu recoloquei o cartão e rodei de novo o programa. Dá pra notar que o cartão demorou mais tempo até responder. Detalhe importante: Olhando a saída com "verbose" ativado, dá pra ver que o cartão respondeu após 26 chamadas. Demorei a entender porque, pois eu á tinha feito vários testes, onde o cartão não inicializara após 255 chamadas (40ms). A explicação é que quando eu uso o modo "verbose" eu gasto bastante tempo chamando a rotina de impressão dos caracteres recebidos, que por sua vez chama a BIOS. E este tempo gasto pelo fato e eu estar "imprimindo" os caracteres, é suficiente para o cartão terminar seu processo interno de inicialização.


O código atual encontra-se neste link.

quinta-feira, 1 de março de 2007

Nova Placa Protótipo 2 + cartucho de MSXDOS

Uma das dificuldades que encontrei durante o desenvolvimento da interface foi encontrar um conector IDC de 50 pinos. Na realidade eu não encontrei, e por isso usei ligações "wire-wrap".

Como eu uso apenas 27 fios na interface (contando 2 fios pro GND e 2 pro VCC), resolvi utilizar um conector de 34 vias, facilmente encontrável já montado em qualquer loja de informática, pois é um conector de drives de 3 1/2".

Eu aproveitei o circuito do cartucho MSXDOS2 do MSXPRO, e adicionei um conector de 34 vias. Pra facilitar a montagem, tive o cuidado de deixar todas os pontos de solda na face da solda.

Eis as imagens dos "layouts".

Cartão MSXDOS2



Placa do protótipo 2 já com o conector de 34 vias.


Detalhe do conector adaptador. Deixei como reserva um pino de "busclock" indo ao pino 16 do "BUS" do MSX .... :)


Um arquivo ZIP com os arquivos acima em formato eagle pode ser encontrado neste link.