Estava cá eu, confabulando com meus botões a respeito da Vida, do Universo e de Todas as Coisas quando nosso colega fudeba Emiliano Fraga resolveu compartilhar suas experiências com o emulador de drive E100S, sobre o qual escrevi um tempo atrás e fiquei devendo um follow-up.

O relato do Emiliano consiste exatamente no que fiquei devendo, com uma diferença: para manipular as imagens de disco, ele usa o software para Windows indicado pelo copiador fabricante do hardware, enquanto que eu ignorei olimpicamente tal software e parti para uma rota alternativa – chegando inclusive a algumas conclusões diferentes. Confira aí abaixo.

Para ficar mais fácil de entender o que o emulador faz com o pendrive, comecei com um cartão microSD (com adaptador, vira pendrive) que zerei de cabo a rabo usando o comando dd do Linux. Sim, tudo neste post é feito em Linux. Para descobrir que nome o Linux dá ao dispositivo que representa o  pendrive, é só olhar o arquivo /proc/partitions antes e depois de inserir o pendrive na USB do PC, e conferir que uma linha a mais aparece. Aqui, ele atribuiu o nome /dev/sdb. Então vamos começar a manipular a tabela de partições com o comando fdisk /dev/sdb (rodando como root).

O fdisk nos avisa que o dispositivo não tem uma tabela de partições válida (tudo zerado, lembra?) e vai criar uma quando for gravar as alterações. Usando a opção n, vamos criar uma partição de 160 megabytes. (Depois eu explico o porquê desse tamanho.)
Por padrão, o fdisk do Linux cria partições do tipo Linux. (Puxa, que surpresa.) Para evitar confundir Linuxes e Windowses e Macses nos quais eu venha a inserir esse pendrive no futuro, decidi mudar o tipo da partição para algo que seja alienígena para todos.
“Non-FS data” (Dados que não são sistema de arquivos) parece perfeito. Vou usar esse código (hexa DA).
Como eu não gosto de desperdício, vou usar o resto do espaço livre para uma partição FAT. Usando o velho esquema inventado pelo MS-DOS na década de 80: criar uma “partição estendida” e, dentro dela, um “drive lógico”.
O tipo do drive lógico, mais uma vez, foi definido por padrão como Linux. Mudamos para FAT32, que é o tipo C. (Nada a ver com “drive C”.)
E assim ficou nossa tabela de partições:
Com a opção w do fdisk, gravamos as alterações e voltamos ao prompt do Linux. Agora vamos fazer a formatação lógica do nosso drive FAT. (Reiterando, este não será usado pelo emulador, ele usará a primeira partição.)
Desmontamos o pendrive do PC (em windowsês, “removemos o dispositivo com segurança”) e estamos prontos pra começar a brincar com ele no MSX.

Não há problema em ligar o MSX sem o pendrive inserido. Assim que você o insere no emulador, desaparece o código de erro no display e aparece “00”, indicando que, para o micro, há um disquete inserido no drive. Pois vamos formatá-lo como qualquer usuário de MSX cristão (e muçulmano) formata disquete, oras.
Vamos testar a gravação digitando um sofisticadíssimo programa em BASIC e salvando-o.
Ao que parece, tudo bem. Agora, vamos apertar o botão da direita no emulador para mudar da imagem 00 para a 01. Sob a visão de mundo do MSX, você retirou o disquete do drive e colocou outro.
Naturalmente, temos que formatar esse “outro” “disquete”.
O programa BASIC ainda está na memória. Vamos salvá-lo… com outro nome.
Chegou a hora de trazer o pendrive de volta pro PC pra ver o que cargas d’água foi gravado nele. Para isso, nada melhor que um editor/visualizador hexa. Como sou fã do rústico, eu uso o comando hexdump. Estamos interessados em ver a primeira partição do dispositivo, que no Linux aparece como /dev/sdb1. Isso porque o dispositivo inteiro era /dev/sdb, lembram? (No seu PC pode aparecer diferente, /dev/sdc, /dev/sdd…)

Para visualizar paginado e poder fazer buscas, uso a seguinte linha de comando: hexdump -C /dev/sdb1 | less
O primeiro bloco é o setor de boot do MSX-DOS. Observe que aparece um “volume label” SNYJX101 (o MSX é um F-700 da Sony), uma mensagem de erro, e o nome do arquivo que, se existir, será carregado para a memória como sistema operacional. (MSXDOS.SYS) Mais à frente, o diretório-raiz com o nome que a gente salvou, e o conteúdo do programa BASIC.

E a segunda imagem? Lembram que, nela, a gente salvou um “IDIOTA2.BAS”? Pois bem, vamos procurar por “IDIOTA2″… Ahá!
O mesmo setor de boot, um diretório-raiz com o arquivo de nome diferente, e o conteúdo. Achamos. Vê-se que a segunda imagem começa na posição hexa 180000, que convertido para decimal dá 1572864 – exatamente um mega e meio. Espaçamento excelente para imagens de 1.44, o que indica que as versões 720K e 1.44M do emulador usam o mesmo firmware.

E é esse o motivo para o tamanho da nossa partição de imagens. 100 imagens x 1.5 MB = 150 MB. E eu botei mais 10 porque sou paranoico.

(O Emiliano reporta um uso de 342 MB pelo software da IPCAS. Essa discrepância merece futura investigação.)

Como eu sou teimoso e tinhoso e não quero não quero não quero usar esse software Windows, vou usar o bom e velho dd de novo para ler e gravar imagens .DSK do pendrive. E aproveita que eu tô calmo.

As opções de linha de comando que nos interessam são count, seek e skip.
Agora vamos gravar um .DSK de um jogo na terceira imagem do emulador (que aparecerá como 02 no display). Para isso usamos a opção seek, que pula um certo número de blocos no dispositivo destino antes de iniciar a gravação. Quantos blocos?

O tamanho do bloco (ou setor), tanto no MSX quanto no PC, é obrigatoriamente 512 bytes, logo também precisamos da opção bs=512. Os deslocamentos devem ser múltiplos de 1.5 MB. Em blocos, isso dá 1024 * 1024 * 1.5 / 512 = 3072.

Ou seja, para gravar na primeira imagem, seek de zero; para gravar na segunda, seek de 3072; para gravar na terceira, seek de 3072×2 e por aí vai. As contas podem ser feitas na própria linha de comando, como pode ser visto abaixo:
Levamos o pendrive pro MSX, avançamos no botão até o número 02…
…e voilá! A imagem está visível pro MSX como drive A:!
Roda beleza.
E para trazer pro PC um disco gravado no MSX? Ora, usamos o processo inverso, usando as mesmas contas com a opção skip em vez de seek. Com mais um cuidado: temos que especificar a contagem de blocos, senão ele vai gerar um arquivo imenso contendo uma imagem até o final da partição. Como a imagem é de 720K, a contagem de blocos é 720 * 1024 / 512 = 1440.

O Linux nos permite montar um arquivo imagem como se disco fosse, o que torna muito fácil conferir se o que foi lido está correto. Vejam:
Çudaí, galera. Qualquer dúvida, comentem. Aqui no blog tanto quanto no podcast, seu comentário é o nosso salário.