O emulador de Interface de disco na MSXRIO 2013

Olá,

Eu levei o emulador de interface de disco para o MSXRIO 2013. Confesso que fiquei bastante preocupado de chegar lá e a interface não funcionar devido a algum fio se soltar do protoboard, mas tudo funcionou direitinho conforme podemos ver na foto acima. A recepção do pessoal foi bastante calorosa e eu pude estabelecer alguns contatos interessantes. Eu fiz e levei para a feira um folder que é como se fosse um manifesto declarando o que é e como funciona a interface e chamando as pessoas a estarem participando do projeto. Abaixo segue o link do dropbox para o arquivo versão PDF do folder.

https://dl.dropboxusercontent.com/u/62498964/Brochure.pdf

Eu fiz contato com dois desenvolvedores que me informaram que estão criando um ambiente de desenvolvimento cross para o MSX. Eles falaram que a intenção é criar uma IDE que permita compilar jogos e programas para MSX no PC e dentro da IDE ter uma forma de imediatamente poder rodar o programa e debuga-lo direto no MSX. Até o momento eles tem usado uma interface de rede mas devido a todo o overhead existente no processo de comunicação com o MSX o tempo para a transferência do programa tem sido longo. Como o emulador de interface de disk drive prevê a inclusão de uma porta USB slave para uso futuro eu falei da possibilidade de usar esta porta usb para permitir a transferência e debug do programa no MSX. Eles demonstraram bastante interesse pela ideia e se mostraram bastante motivados e a motivação deles me "contaminou".

Para a versão 1.0 do firmware não pretendo inserir nenhum código no firmware do PIC visando este fim, isto ficará para revisões futuras. Mas, eu pretendo ligar os sinais para permitir a geração de interrupções por parte da interface. A interface de disco CDX-2 - que eu estou emulando - não usa interrupções e por este motivo a sinalização para a geração de interrupções não é usada. Mas como o PIC ainda possui alguns pinos sobrando eu achei interessante usar estes pinos reserva para permitir a geração de interrupções no MSX em futuras revisões.

Então como funcionaria esta "segunda funcionalidade" do emulador?

Olhando o dump da ROM do CDX-2 é possível observar que aparentemente sobraram algumas centenas de bytes de espaço livre. Usando este espaço livre alteraríamos a CDX-2 para criar uma ISR que aguardaria por uma interrupção por parte da interface que sinalizaria que a IDE lá no PC quer transferir dados para o MSX. Então a ISR, usando os endereços de IO livre na interface (escrita - D5 até D7/leitura D4 até D6) estabeleceria a comunicação com a interface e realizaria a transferência dos dados, posteriormente transferindo a execução para o programa recém carregado. Se você não é desenvolvedor e não quiser usar a interface para este fim então tudo bem, nenhum overhead será criado.

Além disto eu fui perguntado se a interface suporta a emulação de discos de 1.44MB e a resposta é não. Hoje a interface suporta a emulação de discos de 360K e 720K porque eram os formatos suportados pela interface CDX-2. Então eu perguntei se havia alguma interface de disco para MSX que suportava discos de 1.44MB e a pessoa me apresentou uma interface, eu na hora falei que iria tirar uma foto da interface para poder obter maiores informações mas acabou que outra pessoa chegou perguntando outras coisas e eu depois esqueci de tirar a foto e também esqueci o nome da pessoa. Ou seja, eu fiz uma bagunça. Eu estou torcendo para que a pessoa que me falou sobre a interface entre em contato comigo para que eu possa aprender mais sobre ela. Eu não pretendo adicionar o suporte para discos de 1.44MB na versão 1.0 do firmware mas é uma coisa totalmente possível para futuras revisões.

Além disto, eu fui perguntado sobre qual formato a placa de circuito impresso usará, se o formato Patola ou o formato de cartucho grande fornecido pelo Carchano. Eu já até comprei algumas caixas do Carchano mas estas caixas são realmente muito grandes e seria muito melhor se eu tivesse acesso as caixas da Patola. O circuito cabe tranquilamente em uma caixa pequena. Me informaram que a Patola ainda teria a forma para produzir caixas para cartuchos do MSX e que a Patola pode produzir se for colocado um pedido grande de caixas. Se alguém puder me fornecer algumas caixas patola virgens ou se alguém tiver uma previsão de quando estas caixas patola estarão disponíveis novamente para a compra eu paro o desenvolvimento da placa de circuito impresso para poder usar as caixas Patola, senão eu vou usar as caixas grandes do Carchano como base para o projeto mesmo.

Eu conversei também com o Rogério Belarmino sobre a possibilidade da Technobytes produzir o emulador de interface de disco quando o produto estiver em um estágio mais maduro. Afinal de contas o emulador é um projeto open source e qualquer um pode produzir e vender o produto se quiser sem ter que pagar nada por isto. Particularmente falando é fácil para mim produzir as minhas próprias placas e até gosto de fazer placas como um hobby. Mas eu sei que tem gente que gostaria de ter acesso ao emulador mas não tem as habilidades e/ou recursos necessários para por o projeto em prática. Então se a Technobytes ou o Carchano resolverem reproduzir o projeto seria muito legal.

No mais, eu não fiquei até o final do evento porque havia trabalhado no dia anterior até as 22:00 e estava realmente cansado. O grande evento do encontro acredito que seria um novo desenvolvimento do Oazem mas infelizmente não consegui ficar até a apresentação ser realizada. 

Um abraço,

José Paulo

Atualização do projeto de emulador de interface de disquete (#8) - It Works!

Olá,

Ótimas notícias! O emulador de interface de disquete para MSX está funcionando! Conforme podemos ver acima há duas fotos dos jogos "Elevator Action" e "Abadia do Crime". Jogos estes que foram carregados para o meu Expert 1.0 usando a interface. Muito legal.

Basicamente não houve qualquer alteração no circuito desde a última atualização postada aqui. O que houve foi a correção de alguns bugs e a interface passou a funcionar ok. Eu aproveitei e escrevi o código necessário para permitir escritas em disco e com algum sucesso eu consigo realizar escritas. Por exemplo, se eu escrever um programa em basic e executar o comando save o programa será salvo, porém, ainda há algum bug no código do firmware porque se eu escrever vários programas, e tentar salva-los, alguns serão escritos e outros não. Este problema eu ainda tenho que investigar mais a fundo.

De qualquer maneira o problema descrito acima ainda não é o foco para o momento. Como o protótipo está funcionando no protoboard, o que prova que o conceito do circuito está correto, eu decidi focar minha atenção em criar a parte física do projeto, i.e., diagrama elétrico e placa de circuito impresso.

Abaixo segue uma imagem da revisão 1 do diagrama elétrico:

 

 O link para o projeto do circuito (Kicad) segue abaixo:

https://dl.dropboxusercontent.com/u/62498964/MSXDiskEmul.zip

A "revisão 1" do diagrama elétrico ainda não representa todo o circuito, falta ainda interligações a serem feitas mas o grosso do circuito está lá.

Conforme prometido meses atrás eu pretendo disponibilizar todo o projeto como sendo OSHW (Open Source Hardware) e seguindo o que determina a licença GNU segue no diagrama uma cópia da disposições gerais da licença. O motivo para eu ter colocado o circuito sob a licença GNU e não em domínio público é para garantir o meu reconhecimento. Muito trabalho e muito esforço tem sido colocado por mim neste projeto e o mínimo que eu peço é que as pessoas, caso venham a comercializar e/ou modificar o projeto que mencionem o meu nome como o iniciador ou fundador do projeto. É só.

Além disto, não está mais disponível no dropbox as revisões do código do firmware que eu disponibilizei antes. O motivo para isto é que eu quero realizar um "clean-up", documentar o código  e acrescentar os avisos da licença GNU antes de compartilhar o código. Além disto eu acho que vou iniciar um projeto no Source Forge e colocar o código disponível lá.

No mais, no próximo sábado (19/10/2013) acontecerá a MSXRIO 2013 e eu pretendo mostrar o meu protótipo funcionando lá. Como eu somente enviei um pedido para reserva de mesa hoje eu não sei se vou conseguir mesa para expor meu projeto. De qualquer forma, caso eu consiga vai ser muito legal. Espero que com isto eu consiga a adesão de mais pessoas para o projeto já que até o momento tem sido um projeto de uma pessoa com algumas participações pontuais.

Um abraço,

José Paulo

Adaptador para cartões Micro SD

Olá,

Foto Superior

Foto Inferior

  

 

Eu criei uma placa para adaptar cartões micro sd ao meu protoboard para me permitir fazer experiências com estes dispositivos. As fotos do resultado final estão disponíveis acima. É possível utilizar um adaptador de micro sd para sd para adaptar os cartões ao protoboard e é isto que eu fazia mas descobri que estes adaptadores de micro sd para sd não são muito robustos e logo passam a apresentar mal contato.

Abaixo segue o link para o projeto do Kicad com o esquemático e o design da placa de circuito impresso. Espero que seja de alguma utilidade para alguém.

https://dl.dropboxusercontent.com/u/62498964/Adaptador%20microsd.zip

Um abraço,

José Paulo

Atualização do projeto de emulador de interface de disquete (#7)

Olá,

Acima segue a última foto atualizada do protótipo do emulador de interface de disquete. No circuito em si há poucas alterações, eu troquei o teclado que eu estava usando por um outro mais robusto e fiz um adaptador de cartão SD usando de fato um conector para cartões SD. Antes eu estava fazendo testes com cartões sd usando uma adaptação parecida com a da imagem abaixo:

Uma adaptação como da foto acima funciona mas eu acho que estes adaptadores de micro sd para sd não foram feitos para você ficar inserindo e removendo os cartões a todo o instante. Como estamos usando um circuito de teste que a todo o instante precisamos trocar os cartões logo o adaptador começa a apresentar problemas de mal contato. Para resolver este problema eu fiz uma placa de circuito com um conector para cartões micro sd de verdade e que me parece ser de boa qualidade e na placa eu inseri os resistores de pull up smd de 33K necessários para a interface com o cartão e um capacitor de 100nF entre a linha de alimentação e o terra. Os componentes smd não podem ser vistos porque estão soldados por baixo da placa adaptadora. A inserção destes componentes smd diminuiu um pouco a quantidade de fios no protoboard e melhorou a robustez do circuito.

Como podemos ver na foto acima eu coloquei 4 resistores de 100 ohms em série com os sinais do cartão smd e isto também melhorou bastante a qualidade da comunicação com o cartão sd.

As maiores alterações e aonde eu tenho alocado a maior parte do meu esforço é em desenvolver o firmware e eu fiz grandes progressos neste quesito.

As rotinas que fazem a comunicação com o cartão SD eu já tinha feito e praticamente não sofreram alterações. No estágio atual eu consigo acessar normalmente alguns cartões e outros não. Conforme eu já havia escrito anteriormente eu creio que o problema reside no fato de que nem todos os cartões sd suportam comunicação SPI. De qualquer forma eu consigo acesso tanto a cartão normais como cartões HD (High Density), então, para mim, já está bastante satisfatório para não ter mais que me preocupar com estas rotinas.

Numa camada acima estão as rotinas que manipulam a estrutura FAT existente nos cartões. Inicialmente eu tentei usar o Petit FatFs sem sucesso então eu parti para criar eu mesmo minhas próprias rotinas de manipulação do FAT. Hoje eu consigo navegar na estrutura de diretório e abrir os arquivos dsk o que é também bastante satisfatório.

Com as rotinas descritas acima prontas eu fui capaz de melhorar a interface com o usuário e de finalmente emular a interface com o MSX de forma a permitir ao computador que tenha finalmente acesso aos dados contidos nos arquivos dsk. Abaixo segue uma série de fotos da interface com o usuário em ação. Abaixo segue a foto da tela inicial do circuito:

 

A interface do circuito com o usuário se resume a quatro botões que eu vou chamar de "seta para cima", "seta para baixo", "Selecionar" e "Voltar". Nesta tela se eu teclar as setas eu seleciono as várias opções existentes no menu principal, o botão "voltar" não possui função neste tela e a tecla "selecionar" seleciona a opção desejada. Se na tela acima eu pressionar o botão "selecionar" eu pulo para a tela de seleção de arquivo. Caso não haja um cartão sd inserido ou caso ocorra algum erro de leitura no cartão sd aparece uma mensagem de erro e teclando qualquer tecla voltamos para o menu principal. Existindo um cartão sd que não apresente erros nos pulamos para a tela de seleção de arquivos no qual eu posso navegar na estrutura de arquivos do cartão sd e eu posso selecionar arquivos com extensão dsk. Qualquer outro arquivo existente no cartão não será mostrado. Caso o cartão não possua subdiretórios e não possua arquivos com extensão dsk aparecerá a mensagem de disco vazio e pressionando qualquer tecla voltaremos para o menu principal.

Na imagem acima podemos ver o resultado após pressionarmos a tecla "selecionar". No caso do cartão em questão temos um subdiretório chamado "TESTE1".

Se teclarmos o botão "selecionar" novamente nos entramos dentro do subdiretório TESTE1. Na imagem acima podemos ver a primeira entrada do subdiretório "TESTE1" que é a entrada "." que nada mais é do que uma referência ao próprio diretório. Na sequência temos a entrada ".." que é uma referencia ao subdiretório ou diretório raiz anterior ao subdiretório atual. Uma curiosidade: se teclarmos ao botão "voltar" nos não voltamos para o subdiretório anterior, mas sim para o Menu Principal. Enquanto na tela de seleção de arquivos o botão "voltar" sempre volta para o menu principal. Sendo assim para voltamos um nível na estrutura de diretórios temos que selecionar a entrada ".." e teclar o botão "selecionar".

Navegando na estrutura do subdiretório de exemplo "TESTE1" encontramos o arquivo da imagem abaixo:

 

No meio do nome do arquivo existe uma seta para a direita mas isto na verdade é o equivalente no display LCD ao caractere "~" de forma que o nome correto do arquivo é "ELEVAT~1.DSK". No display de LCD que eu estou usando não existe o caractere "~" mas eu creio que da para viver com este caractere trocado. O nome do arquivo continua bastante legível. Aliás, a rotina também somente amostra as entradas de diretório com o nome no formato 8.3. Nomes de arquivos e subdiretórios estendidos não são apresentados, mas isto não chega a ser um problema porque sempre existe duas entradas de diretório para o mesmo arquivo ou subdiretório uma no formato 8.3 e a outra no formato estendido. Isto faz parte da especificação do FAT32.

Neste momento se pressionarmos a tecla "selecionar" finalmente disponibilizamos um arquivo para o MSX manipular. Antes deste momento o MSX sempre obtém do registrador de status a informação de "drive not ready", i.e., uma leitura no endereço de IO D0 sempre obtém o valor 0x80. Com a seleção do arquivo a leitura do status passa a representar o estado atual do arquivo. Por exemplo, se o arquivo dsk selecionado tiver com a flag de read-only ativa o MSX receberá a informação de disco protegido contra gravação. Abaixo segue a foto da tela após a seleção do arquivo.

 

Na tela acima além de vermos o nome do arquivo selecionado podemos ver que o disco não está protegido contra gravação - cadeado aberto - e podemos ver os valores selecionados de cabeça, trilha e setor. Estes valores são atualizados automaticamente quando o MSX passa a manipular o "disk drive". Neste momento o MSX poderia acessar o arquivo dsk como se fosee um disco magnético real e é neste ponto que eu estou tendo problemas.

 

Com o arquivo selecionado se eu executar o comando "files" para listar os arquivos existente dentro do arquivo dsk o MSX apresenta a listagem correta. No caso da imagem acima está sendo apresentado o conteúdo do disco do jogo "Elevator Action", mas se eu digitar load "autoexec.bas" o MSX acessa o setor 2 da trilha 0, cabeça 0, depois o setor 6 da trilha 0 e da cabeça 0 e depois fica lendo o registrador de status indefinidamente como se estivesse esperando alguma coisa acontecer e não concluí o comando load. Eu realmente não consigo entender que alteração do status que ele está esperando que aconteça. De qualquer forma eu estou neste estágio de desenvolvimento.

Além disto, estou tendo problemas com a programação do PIC em si. Não consigo em hipótese alguma fazer com que a rotina de interrupção de baixa prioridade funcione para mim. Eu não consigo entender o porquê e eu preciso que isto funcione porque eu preciso temporizar diversas tarefas dentro do meu código. Isto é uma coisa que tem me aborrecido bastante e estou inclusive pensando em trocar o PIC 18F4550 por um PIC24FJ64GA004. A minha maior resistência a esta ideia é o fato de que isto representaria um retrocesso muito grande para tudo aquilo que eu já obtive até o momento. Se na próxima semana eu não obtiver uma resposta para este problema vou ter que começar quase que do zero na criação do meu projeto.

Abaixo segue o link do código fonte do firmware até o momento. O código está precisando de um clean up porque você vai testando e mudando coisas no seu código e chega um pouco que as coisas começam a ficar confusas. De qualquer forma o código está ai para quem quiser estudar e participar do projeto.

https://dl.dropboxusercontent.com/u/62498964/MSXFirmware_3.X%2020130929.zip

Um abraço,

José Paulo

Nova peça para o Kicad: Adaptador smd para cartão micro sd

Olá,

Eu criei mais uma nova peça (part) para o kicad: um adaptador smd para cartão micro sd. A peça em questão pode ser facilmente encontrada no ebay e os arquivos do kicad você pode baixar no kicad cloud acessando os links abaixo.

Para o esquema elétrico:
http://www.kicadcloud.com/schematicSymbol/4370

Para a placa de circuito impresso:
http://www.kicadcloud.com/pcbModule/4371

Abaixo segue mais informações sobre a peça:

Um abraço,

José Paulo

Energia: Arduino Framework para o Launchpad da Texas

 

 Olá,

Eu já escrevi aqui no blog a respeito do Launchpad da Texas Instruments. E eu descrevi a maior vantagem dos Launchpads: o preço. E a maior desvantagem: a incompatibilidade com a plataforma arduino.

Pois bem. Eu tenho o MSP430 Launchpad e o Stellaris Launchpad. Recentemente eu acessei o site da Texas para baixar a última versão do software de desenvolvimento para o meu Stellaris Launchpad e, para minha surpresa, a Texas parou de dar suporte para a família de MCUs Stellaris a favor da nova família Tiva. Você simplesmente não consegue mais baixar os softwares que são necessárias para você usar este modelo de placa de desenvolvimento. Curiosamente, na loja online da Texas o Stellaris Launchpad ainda está disponível para venda (com preço promocional - Uau!!!). Creio eu que sejam pontas de estoque que a Texas ainda possui.

Na minha humilde opinião eu creio que a forma como a Texas tratou do assunto simplesmente abandonando os usuários do Stellaris a favor da nova linha Tiva é um absurdo e um absurdo ainda maior é continuar vendendo as pontas de estoque que eles nem mesmo dão mais suporte. Isto só me faz querer pensar duas ou mais vezes antes de usar os produtos da Texas em meus projetos.

De qualquer forma eu descobri que fiquei órfão e com uma plaquinha que eu não conseguia usar. E, buscando por alternativas para continuar usando a plaquinha que possuo é que eu esbarrei com o projeto "Energia". Basicamente o Energia é um framework baseado no Arduino que permite usar o MSP430 Launchpad e o Stellaris Launchpad. Fantástico! Nos testes iniciais tudo funcionou direitinho de primeira e como os Launchpads já vem com o programador incorporado você não perde espaço no MCU com o bootloader e o seu sketch entra em ação assim que você alimenta a placa. Nos arduinos originais o programa de bootloader entra em operação primeiro e apenas após alguns segundos é que o seu sketch assume o controle do MCU.

Eu realmente sempre usei MCUs da microchip e fiz algumas experiências com 8051 e com os MCUs da Texas. O arduino era uma plataforma que eu ainda não havia experimentado e estou muito entusiasmado em usar meus launchpads com o Energia. Ao mesmo tempo que eu poderei continuar usando meus launchpads eu ainda vou poder aprender um pouco sobre a linguagem Wiring e a plataforma arduino no geral.

Os launchpads não são arduinos. A pinagem e o "form factor" dos launchpads fazem com que estes não sejam compatíveis com os famosos shields dos arduinos que são as verdadeiras estrelas do mundo arduino. Mas de qualquer forma é uma alternativa muito interessante.

Abaixo segue o link para o site do projeto Energia:

http://energia.nu/

Se você possui um launchpad MSP430 ou Stellaris eu acho que vale a pena experimentar o Energia. Além de tornar o trabalho de programação dos launchpads muito mais fácil é uma alternativa interessante para as soluções proprietárias que a Texas Instruments oferece.

Um abraço,

José Paulo

Atualização do projeto de emulador de interface de disquete (#4)

Olá,

Já faz um bom tempo que eu não escrevo nada no blog. Um pouco por conta de falta de tempo, um pouco por dificuldades diversas que eu tenho enfrentado em meus projetos e um pouco por conta de uma falta de interesse momentâneo. Mas é isso. Espero retomar as atividades tanto aqui como nos meus projetos.

O projeto do emulador de interface de disquete está se arrastando. Dificuldades mil eu tenho encontrado. E tocando o projeto sozinho amplia o grau de dificuldade.

O primeiro problema que eu tenho encontrado é com relação à comunicação com os cartões SD propriamente dito. Os cartões SD possuem duas formas de comunicação: usando o que é chamado de protocolo SD que é mais rápido, porém mais complexo, e a outra é por meio do "protocolo" SPI que é mais simples e que muitos MCUs disponibilizam dispositivos que implementam este protocolo como é o caso do PIC18F4550 que está sendo usado no projeto. O problema reside no fato de que aparentemente nem todos os cartões SD suportarem corretamente o protocolo SPI. Há documentos "oficiais" que descrevem em detalhes como se deve comunicar com os cartões SD tanto em modo SD como em modo SPI, mas aparentemente há cartões que não seguem estritamente o que é estipulado para este modo. Inclusive no documento versão 2 dos cartões SD é informado que futuras revisões do padrão podem não mais suportar o modo SPI. Uma pena. De qualquer forma eu consegui interagir com alguns cartões micro SD que eu tenho aqui em casa o que para mim já é satisfatório. E agora vai aí uma dica: aparentemente os cartões da marca Kingston funcionam muito bem em modo SPI.

O segundo problema é que eu não consigo fazer funcionar corretamente a interrupção de baixa prioridade. Como eu já descrevi em posts anteriores a interrupção que trata do barramento de dados do MSX precisa ser muito rápida e para isto eu dei a este rotina a interrupção de alta prioridade e escrevi a rotina em assembler para garantir o máximo de velocidade possível. Para garantir maior velocidade eu decidi também que a interrupção de alta velocidade tratará apenas da "interrup-on-change" que é a interrupção que é acionada quando o MSX faz uma operação de leitura ou escrita na faixa de endereços de IO equivalente ao controlador de disquete original deste computador (0xD0 à 0xD7). Pois bem, o problema surge quando eu quero usar os outros dispositivos do computador dando a elas a interrupção de baixa prioridade. Eu não sei porque, toda a vez que eu libero (habilito) as interrupções de baixa prioridade o MCU parece travar no mesmo instante. No momento os outros dispositivos não estão fazendo falta ainda. Mas seria legal poder usar a interrupção de baixa prioridade para por exemplo temporizar alguma coisa, sei lá.

O terceiro problema é com o sistema de arquivos FAT em si. Inicialmente estava pensando em usar o "petit FatFs" que é um software livre criado justamente para permitir que MCUs com pouco memória RAM e Flash possam fazer a interface com cartões SD contendo partições FAT. Pois bem, quando eu tento compilar o código do Petit FatFs o compilador acusa o erro de falta de espaço para o parâmetro X qualquer. Após muito quebrar a cabeça eu percebi que, apesar do código do Petit FatFs ser bastante enxuto, na verdade ele transfere muita informação entre as suas diversas funções e isto acaba violando o espaço que foi destinado por default pela Microchip para uso com estes parâmetros. Eu acho que se eu mudar o espaço reservado para a COMRAM no arquivo lkr do pic18F4550 eu consigo fazer as rotinas compilarem normalmente... mas pensando bem é melhor não. Porque? Eu explico. O Petit FatFs foi feito para transferir pequenas quantidades de informação mas na minha aplicação eu vou transferir entre o MSX e o cartão SD setores inteiros de 512 bytes. Eu então achei melhor reservar um espaço de 512 bytes na memória do PIC apenas para estas transferências entre o PIC e o cartão SD. Sendo assim eu estou fazendo as minhas próprias rotinas de tratamento do FAT.

As rotinas em si ainda possuem uma quantidade enorme de bugs mas já consigo navegar entre as pastas e arquivos dos cartões SD que estão em teste.

Abaixo segue algumas imagens da tela LCD do emulador de interface de disquete:

Nas imagens acima estou visualizando um arquivo chamado "ELEVAT~1.DSK" e um diretório chamado LOST respectivamente. É possível observar que no caso do arquivo eu não estou apresentando a extensão DSK porque eu achei desnecessário já que a minha rotina está filtrando para apresentar apenas os arquivos com esta extensão. Mas eu estou começando a perceber que isto pode ser um erro. Porque? Porque caso não haja no cartão SD um arquivo com extensão DSK e nem um diretório o rotina informa que o cartão está vazio e eu acho que isto pode levar o usuário a pensar erroneamente que o cartão está vazio enquanto que na verdade não está. Eu acho que vou mudar meu código para apresentar o simbolo do disquete apenas para arquivos válidos (com extensão DSK) mas apresentar outros arquivos que existam no cartão. O cadeado aberto indica que o arquivo, ou disco, pode ser escrito. Para o MSX, um arquivo com cadeado aberto vai representar um disquete sem a proteção contra a gravação e portanto o disquete (arquivo) pode ser alterado pelo MSX. As setas no canto direito indicam que há mais arquivos "para cima ou para baixo" que você pode navegar com as setas de UP e DOWN do controle da interface.

Ainda há muito a ser feito neste projeto mas o projeto está andando. Abaixo eu deixo o link para o código fonte do firmware do PIC. Caso alguém se sinta compelido em estudar o código e ajudar ou dar ideias, por favor, se sinta a vontade.

https://dl.dropboxusercontent.com/u/62498964/MSXFirmware_3.X%20-%20Nova%20Vers%C3%A3o.zip

Um abraço,

José Paulo