Como copiar arquivos de um notebook de 30 anos
(unterminated.com)- Era preciso preservar curtas gravações de áudio restantes em um Apple PowerBook Duo 280c de 1994, mas saída de áudio, disquete, rede e adaptador de disco estavam todos bloqueados, então a transmissão por fax virou a rota alternativa
- Com o editor hexadecimal do ResEdit, o arquivo de áudio foi aberto como texto hexadecimal, colado no Microsoft Word e enviado usando a função de fax da janela de impressão
- A recepção ficou a cargo do modem embutido e do app de fax de um ThinkPad T60 com Windows XP, e em vez de ligar os dois notebooks diretamente por uma linha telefônica, foi necessário um circuito simulador de linha telefônica baseado em bateria de 9V
- O método de reconverter a imagem de fax TIF com OCR deixou estalidos e pops no áudio por causa de leituras erradas como 0/C, 9/4 e 0/D, além de erros de omissão e inserção
- No fim, foi criada a ferramenta FaxToBinary para analisar diretamente a grade de caracteres de largura fixa e treinar manualmente os padrões dos caracteres, recuperando um arquivo de áudio idêntico ao original byte a byte
Caminhos de cópia que estavam bloqueados
- O dispositivo em questão era um PowerBook Duo 280c de 1994, e dentro dele havia algumas gravações curtas de áudio que precisavam ser preservadas
- Felizmente, o notebook ainda inicializava, o disco rígido girava com uma leve batida, e os arquivos de áudio podiam ser reproduzidos pelo alto-falante interno
- Os métodos normais de cópia foram sendo bloqueados um a um
- Sem conector de áudio, era difícil fazer uma cópia analógica de boa qualidade
- O disco rígido interno usava SCSI com um conector incomum, e nem estava claro se sistemas modernos conseguiriam ler facilmente o antigo sistema de arquivos HFS
- Ao conectar um drive de disquete externo, o computador deixava de funcionar, e não foi possível descobrir a causa da falha
- Havia porta AppleTalk e conector telefônico, mas nenhum software de rede estava instalado
- O HTTP só foi padronizado em 1996, e o notebook também não tinha software de acesso discado que pudesse ser usado na época
- Em compensação, o discador telefônico e o software de fax ainda estavam lá, o que abriu um desvio usando o modem
Transformando o arquivo em um documento de fax
- O notebook tinha vários jogos e também o editor de recursos ResEdit, cujo editor hexadecimal permitia ver o conteúdo bruto do arquivo em hexadecimal
- O ResEdit não oferecia função de saída, então era preciso mover o texto hexadecimal para outro aplicativo
- O arquivo de áudio de exemplo tinha 37.928 bytes, e como cada byte era mostrado como dois caracteres hexadecimais, sua representação em texto ficava com o dobro do tamanho
- Como havia limite para o tamanho tratado de uma vez, o arquivo foi dividido para cópia, usando blocos de 12288 bytes, ou seja, unidades de 0x3000, por serem fáceis de lembrar no deslocamento
- O texto hexadecimal copiado para a área de transferência podia ser colado diretamente em um documento do Microsoft Word, e o Word fornecia a função de saída
- Todos os arquivos tinham menos de 100KB, e a velocidade média da cópia manual via área de transferência do ResEdit para o Word foi estimada em cerca de 316 bytes/s
Criando uma linha telefônica simulada entre os dois notebooks
- O computador receptor era um ThinkPad T60 com modem discado embutido, e o app de fax do Windows XP conseguia salvar faxes recebidos como imagens TIF de múltiplas páginas
- A tentativa de ligar os dois notebooks diretamente com um cabo telefônico falhou
- O PowerBook fazia a chamada, mas o ThinkPad não atendia
- A opção “Ignore Dial Tone” também não funcionou
- A tensão fornecida pela rede telefônica fixa real era importante para o funcionamento do modem, e isso foi resolvido com um circuito simulador de linha telefônica
- Esse circuito podia ser montado com componentes eletrônicos comuns e uma bateria de 9V, fornecendo uma linha telefônica simulada entre os dois notebooks
- A transmissão de fax exigia uma folha de rosto por exigência da FCC, e, após adicioná-la, a transmissão prosseguiu
- No início, o tempo estimado após a rasterização era de 24 minutos, mas ao reduzir o tamanho da fonte isso caiu para 6 páginas e 7 minutos, e o fax foi recebido no ThinkPad a 14400bps
Com OCR, os erros permaneciam
- O fax recebido pelo ThinkPad era uma imagem TIF, e para convertê-la de volta em arquivo binário, primeiro foi tentada a conversão para PDF com OCR
- A imagem do fax parecia favorável para OCR
- O texto havia sido gerado por computador, com alinhamento e forma consistentes
- Havia apenas 16 tipos de caracteres usados: 0-9 e A-F
- Foi usada a fonte Courier, uma fonte monoespaçada comum
- Era possível selecionar o texto resultante do OCR, copiá-lo para um editor hexadecimal e salvá-lo como arquivo binário
- O Audacity identificou o formato de áudio do arquivo resultante como unsigned 8-bit PCM, little-endian, 22050Hz, mono, e também exibiu a forma de onda
- A reprodução era razoavelmente boa, mas quedas bruscas na forma de onda soavam como estalidos ou pops causados por erros de transcrição do OCR
- Mesmo tentando vários programas de OCR e mudando tamanho e tipo de fonte, não se chegou a 100% de precisão
- Havia confusão entre 0 e C, 9 e 4, 0 e D
- Também aconteciam omissões de caracteres ou inserções de novos caracteres
Recuperação byte a byte com FaxToBinary
- Como o texto da imagem de fax havia sido gerado em uma fonte de largura fixa, o documento inteiro podia ser tratado como uma grade de caracteres com espaçamento constante
- Ajustando corretamente o ponto inicial, o deslocamento dos caracteres e o espaçamento entre linhas, era possível capturar e analisar cada caractere individualmente
- A ferramenta própria mostrava uma visualização à esquerda para verificar se os parâmetros de tamanho e deslocamento estavam corretos, e, se não houvesse deriva ao mover entre caracteres ou mudar de linha, o processamento podia começar
- O reconhecimento de caracteres funcionava com um método simples de treinamento manual
- Sempre que aparecia um padrão inédito, o usuário informava qual caractere ele representava
- Depois, ao encontrar novamente um caractere com a mesma forma, a ferramenta reutilizava a resposta anterior
- O código da ferramenta está disponível em FaxToBinary.zip
- Após um pouco de treinamento manual, a ferramenta gerou o arquivo, o áudio passou a tocar suavemente sem pops, e a cópia ficou idêntica byte a byte ao original
- Depois de recuperar o arquivo, ainda foi possível rodar DOOM naquele PowerBook
2 comentários
Só um pensamento.
ihexousrecordfornecem checksum.zmodem.Opiniões do Hacker News
Passei por um problema parecido ao fazer OCR de dumps hexadecimais de uma revista antiga de computadores, e resolvi criando uma ferramenta para verificar o resultado do OCR
Ao inserir o resultado do OCR e separar os números, ela mostra os caracteres recortados do original agrupados por classificação; olhando a olho nu, dá para encontrar rapidamente erros de classificação, como um “3” que caiu no grupo dos “8”
https://blog.qiqitori.com/2023/03/ocring-hex-dumps-or-other-...
https://blog.qiqitori.com/2023/03/ai-day-in-retroland-prolog...
Escrevi dois posts relacionados, e a ferramenta também está linkada neles. Só que a usabilidade da ferramenta é apenas um pouquinho melhor que a do sendmail
Não sei se havia um ambiente de programação ou algo parecido com o Microsoft Word da época nos notebooks antigos da Apple, mas imagino que haveria um jeito melhor sem hackear o hardware
Um jeito melhor provavelmente teria sido usar a porta serial em vez de enviar fax pela porta de modem. Adaptadores serial-USB são fáceis de encontrar
Basicamente, num segundo passe, você encontraria os outliers de cada grupo de caracteres, os reclassificaria temporariamente em outro grupo e, se a pontuação de similaridade dos grupos envolvidos melhorasse, manteria a mudança, repetindo até não haver mais melhorias
Por exemplo, dá para encontrar o “3 menos parecido com os outros 3”, colocá-lo temporariamente entre os “8” e, se as pontuações de “quão parecidos são os pedaços de 3 entre si” e “quão parecidos são os pedaços de 8 entre si” melhorarem, manter essa alteração
Mas, se o documento misturar várias fontes, isso pode ter efeito contrário, por exemplo agrupando “3” de fontes diferentes e estragando a pontuação de similaridade do grupo
Aquele notebook não tinha uma porta serial (COM)? Na época era quase universal e, segundo este site [1], ele tinha duas
Resolver com Zmodem teria sido simples, e acho que já havia software de terminal
[1] https://everymac.com/systems/apple/powerbook_duo/specs/mac_p...
Mas seria preciso ter no PowerBook algo capaz de receber via serial. O ClarisWorks com certeza conseguia, e é bem provável que o Office tivesse a mesma função de “receber documento”
Ou então dava para “imprimir” pela porta serial e capturar a saída serial. Na prática é uma transferência de texto unidirecional, mas seria suficiente para o que o autor queria fazer
Ainda assim, enviar por fax e fazer OCR é bem estiloso
Não me lembro de haver um app de terminal instalado no notebook, embora eu talvez não tenha procurado o bastante
No começo achei que ele fosse fotografar a tela do notebook antigo e fazer OCR, mas o método real foi muito mais interessante
Ainda assim, talvez tivesse sido mais rápido usar uma fonte grande e gastar 24 minutos na transmissão. É bem possível que escrever o software de OCR atualizado tenha levado mais de 24 minutos
Mas aí não teria graça
Omiti isso no texto para manter a concisão, mas, na prática, testei várias fontes e tamanhos de letra, uma página por vez, e revisei manualmente; não houve grande melhora
[0] https://social.immibis.com/notice/AeWSRvyKlhBB2hANoe
Quando eu era jovem, precisei extrair um banco de dados dBase 2 de um desktop CP/M para um PC portátil MS-DOS
Configurei um cabo serial, rodei PROCOMM no PC, ajustei as portas dos dois lados para 9600/n/8/1 e, enquanto imprimia no dBase 2, fiz o PROCOMM gravar a sessão em um arquivo
Se eu deixasse rodar sem pausar por tempo demais para gravar no disquete, caracteres se perdiam, então controlei o fluxo no lado do CP/M com ctrl-s/q
Na época, acho que ninguém tinha descoberto um jeito de fazer isso assim
Ainda assim, se havia um modem instalado, lembro que também deveria haver software de terminal
AppleTalk está perto da resposta certa. Os drivers vinham integrados e a Apple manteve muito bem a compatibilidade por longos períodos
Passei por um problema parecido ao transferir arquivos entre um IIGS e equipamentos modernos. Emulador de disquete, SCSI e serial bruta também funcionam, mas colocar no meio um Mac que tenha tanto AppleTalk quanto Ethernet simplifica tudo: dá para arrastar e soltar toda a hierarquia de arquivos entre o dispositivo de destino baseado em AppleTalk e um compartilhamento como SMB
SCSI também costuma ser fácil de converter, desde que você conheça o conector e o tipo do drive e esteja disposto a encadear alguns adaptadores. Pelo que lembro, drives SCSI de 2,5 polegadas usavam conectores da família SCA, e, desde que se respeitem as regras de terminação simples/diferencial, existem adaptadores SCSI para ligar praticamente qualquer coisa a qualquer outra
O problema é encontrar um SO ou uma ferramenta que leia o sistema de arquivos antigo do Mac; provavelmente dava para ler e gravar imagens de disco com um dos utilitários que leem imagens brutas
É bem possível que conectar em outro lugar e copiar os dados fosse algo bastante simples. Trabalho em um lugar que lida com hardware de mais de 30 anos com frequência, e o ponto central é sair do enquadramento de que isso é uma solução de software
Isso não é um problema de software; na maioria das vezes exige outro tipo de especialização
Também pensei em conversão SCSI, e o autor disse que não tinha certeza se conseguiria ler o volume HFS, mas o Linux já tem drivers HFS há décadas
Neste caso, por ser um PowerBook Duo com disco SCSI, seriam necessários um dispositivo como o Duo Dock[2], um adaptador conversor HDI-30[3] e uma combinação de cabos, conversores e controladores para conectar dispositivos SCSI paralelos a um sistema moderno
Se você tiver uma máquina com slot PCI Express ou um gabinete Thunderbolt PCI Express, recomendo um adaptador LSI Logic Ultra320, que sai por menos de US$ 50 no eBay. Drivers para macOS, Linux e Windows são fáceis de encontrar
Depois de tudo preparado, basta conectar os Macs com um cabo SCSI, segurar T durante a inicialização do PowerBook para entrar no modo de disco de destino e, se o SO perguntar se você quer formatar um disco que ele não consegue ler, responder obrigatoriamente não
Para acessar o sistema de arquivos HFS, no macOS, o caminho que parece mais completo e fácil é criar uma imagem bruta do disco, fazer backup, instalar o Mac OS 9 no qemu, anexar a imagem, converter HFS para HFS+ in-place com o Alsoft PlusMaker e então montar a imagem no macOS atual
Como bônus, você também obtém um sistema Mac OS 9 emulado, capaz de executar a maioria dos apps do disco rígido original do PowerBook em um Mac moderno
[1] https://developer.apple.com/library/archive/technotes/tn/tn1...
[2] https://en.wikipedia.org/wiki/PowerBook_Duo#Docking_stations
[3] https://www.amazon.com/dp/B0081SAIS2/
[4] https://www.broadcom.com/support/download-search?pg=Legacy+P...
[5] https://wiki.qemu.org/Documentation/GuestOperatingSystems/Ma...
[6] https://www.macintoshrepository.org/19-plusoptimizer-plusmak...
[7] https://www.macintoshrepository.org/809-stuffit-deluxe-1-5-x...
[8] https://www.macintoshrepository.org/1724-toast-5-titanium
Gosto disso porque parece uma prova prática de teoria da informação
“Transmita um arquivo de 32.000 bytes pelo canal que quiser. Todos os canais são ruins de algum jeito. Você tem um smartphone, uma porta serial e um computador. O computador não tem compilador, mas dá para usar qualquer função básica. Soluções que exigem mais bytes de entrada do que o arquivo a transmitir, como scripts, estão desclassificadas. Não há limite de tempo, mas vence a solução mais rápida. Comecem.”
Não sei se eu teria me saído melhor que o autor se fosse um Mac antigo. Mas, se desse para trocar caracteres visualmente parecidos, como 3 e 8, por caracteres bem distintos, como 8→Z, fica a tentação de achar que filmar a tela com o smartphone e usar OCR talvez fosse o método mais rápido
Acho que o System 7 tinha AppleScript, então talvez fosse possível fazer uma etapa de substituição parecida com
sedInstalar o hfsprogs, montar o drive e extrair os arquivos necessários, fim
O conector proprietário poderia ser um problema, exigindo algum desvio tipo solda improvisada, mas felizmente equipamentos antigos costumam funcionar bem mesmo assim
Sinceramente, é a vantagem de quem é mais de hardware
Então eu procuraria uma codificação que tornasse os erros extremamente raros. Se fosse preciso despejar o drive inteiro do notebook, eu preferiria deixar o notebook ligado por uma semana a usar um método mais rápido, mas sujeito a erros
Fazendo uma conta simples, enviar 320 MB em uma semana dá 530 bytes por segundo. Se a tela for exibida a 4 Hz e gravada com o smartphone, dá para assumir que não haverá frames perdidos nem artefatos estranhos; seriam cerca de 135 bytes por frame, ou 1080 bits
Se uma tela de 8,4 polegadas e 640×480 for dividida em quadrados de 16×16 pixels, surgem 1000 células de cerca de 0,5 cm. Exibir cada célula em preto e branco por 0,25 segundo quase bate com a largura de banda necessária sem que artefatos da câmera afetem muito os dados
Como não haveria OCR de caracteres, os problemas acima diminuiriam, mas primeiro seria preciso colocar esse programa na máquina
O trecho em que o disco rígido interno era SCSI com um conector incomum e parecia difícil de adaptar, na verdade, tinha como caminho usar o barramento SCSI
SCSI é um protocolo de barramento com bus mastering em que vários mestres podem compartilhar o barramento, então é possível conectar dois computadores ao mesmo barramento SCSI ao mesmo tempo e acessar juntos o dispositivo de disco. Não dá para confiar em escrever simultaneamente no sistema de arquivos, mas, hoje, um disco inteiro daquela época é só um arquivo grande, então bastaria fazer um dump completo
Inconsistências em um sistema de arquivos aberto seriam algo no nível de uma recuperação de falha, e não teriam afetado arquivos armazenados há muito tempo
O HFS antigo também teria sido muito fácil de montar no Linux via loopback, graças às virtudes do estilo open source/New Jersey
Ainda tenho a imagem completa do disco de um Mac SE20 antigo, de 1988, e a monto de vez em quando. Também a extraí pelo barramento SCSI. Acho que o 20 significava os MHz do processador 68020, mas por coincidência ele também tinha um disco de 20 MB, e o SE30 do ano seguinte era parecido
A parte em que usaram software de fax me lembrou uma ideia em que eu tinha pensado no passado, mas nunca executei. Se a capa do fax incluísse algo como um grande QR code codificando o formato .DOC do documento, ele poderia ser enviado até por uma máquina de fax comum; se o destinatário fosse um modem de computador, receberia o documento no formato original e poderia interromper o restante da transmissão do fax com um handshake
Acho que teria sido uma forma suave de superar a velha tecnologia de fax
Há alguns anos passei bastante tempo tentando trocar arquivos entre um Macintosh Plus e um computador moderno
Na época usei dois drives ZIP de 100 MB, um SCSI para o Mac Plus e outro USB para o computador moderno, e depois usei uma conexão pela porta serial com software de terminal [1]
Hoje há uma opção melhor e barata: o BlueSCSI[2]. É um emulador de HDD SCSI que permite montar arquivos .img armazenados em um cartão SD como discos HDD, e também oferece emulação de CD e de placa de rede
Depois de copiar os arquivos para esse drive virtual, dá para extraí-los em uma máquina moderna com um explorador HFS ou um emulador
[1] https://blog.rekawek.eu/2016/12/08/mac-plus#hard-drive
[2] https://bluescsi.com/
Foi um texto realmente empolgante e, para meu conhecimento limitado de computadores, complexo demais
Lá por 1993~1994, pensando na ordem em relação a outros acontecimentos, tive a oportunidade de “consertar” um notebook IBM que não dava boot. Era grosso, pesado e grande, mas a tela tinha mais ou menos o tamanho de um disquete de 3,5 polegadas
Nunca vi um notebook desses em fotos nem em nenhum outro lugar, então imagino que, mesmo para os padrões da época, já fosse algo mais antigo. Se alguém souber o que era, gostaria de ver uma foto
Um tiozão nerd do bairro, meio fora de época e que era como um mentor, me deu para tentar consertar, e eu fiquei alguns dias exibindo aquilo em cima da mesa. Acho que consertei de um jeito bobo e simples, provavelmente mudando o AUTOEXEC.BAT e carregando o WordStar. O necessário era só o WordStar no DOS, nem era Windows 3.x
É bem provável que aquele notebook tivesse sido dado por missionários cristãos que visitavam a igreja local da minha cidade natal
Tenho outra história de conserto de computador, mas preciso lembrar os detalhes para escrever. Envolveu dormir em um quartel nas montanhas, ter escolta armada para urinar e voltar para casa atendendo uma grávida em uma ambulância. Essa “missão” foi com um amigo de infância da vizinhança, mas ele faleceu, e aquele tio anacrônico também faleceu. Uma coisa não tem relação com a outra
Só que a tela dele provavelmente era um pouco maior que um disquete de 3,5 polegadas, e ele nem tinha disquete de 3,5 polegadas, só suportava 5,25 polegadas. O Osborne 1 ou computadores portáteis do início dos anos 80 tinham telas menores, mas provavelmente não rodavam DOS
Outro candidato é o PC Convertible: https://en.wikipedia.org/wiki/IBM_PC_Convertible
Se havia “software de fax”, quase certamente também havia um emulador de terminal, e teria sido possível enviar os arquivos sem corrompê-los usando algo como ZMODEM
Foi doloroso de ler, como ver alguém usando uma faca de manteiga no lugar de uma chave de precisão