Tópicos › Scopus e o Nexus 2600
32 conversas · anos 1 a 9 do grupo

No primeiro ano do grupo (2017-2018), o tema começou com os terminais seriais Scopus Sagitta 150 e 180. Felipe "Juca" Sanches e Werner planejaram energizar um Sagitta. Felipe fotografou a placa do Sagitta 150 na USP e rastreou parte da varredura do teclado. Um driver ainda não funcional, com crédito a Werner, foi proposto ao MAME no PR #2776 (arquivo scopus.cpp, que deve reunir os terminais da Scopus). O PR aguardava as alterações pedidas na revisão; compilado por Werner, o driver rodava mas não respondia ao teclado. DQ (Daniel Quadros) se apresentou ao grupo e relatou seu trabalho na Scopus de 1981 a 1986, com firmware de terminais e com o BIOS e o sistema operacional de um compatível PC. Felipe distribuiu o dump da EPROM do terminal Lepus 200, e DQ publicou um disassembly parcial (lepus.asm): o firmware simula DMA com sequências de POP acionadas pela instrução SIM, lê o teclado nos endereços E002 a E00B, um por linha da matriz, e usa a porta E000 para dip switch, baud rate e buzzer. Felipe também digitalizou a publicação "Tecnologia Scopus", de outubro de 1983, trazida por DQ, no repositório Documentos_Scopus.
Ainda no ano 1, Felipe e Affonso Amendola, estagiário do acervo de computadores da Poli, trabalharam num PC-XT Scopus Nexus 2600. DQ explicou que a interface de teclado não segue o padrão IBM, porque usa uma USART 8251, e só funciona com o teclado da Scopus. Com ele, a máquina deu boot no PC-DOS 3.3. As ROMs foram extraídas com o DEBUG, e Felipe publicou um branch do MAME para o Nexus 2600 e os dumps do BIOS v5.03 e da ROM do teclado. O BIOS escreve em portas fora do padrão do XT, como a D550h, que segundo DQ selecionaria o clock entre 4,77 e 8 MHz por meio de um MUX. Affonso removeu as quatro PROMs TBP28L22N da placa-mãe, leu seu conteúdo com um leitor feito com Arduino e publicou os dumps e o código. Ele também escreveu o xt-hd-imager, em Borland C, para enviar os setores do HD pela serial. A primeira imagem, publicada no Internet Archive, perdia um bit de cada byte. Depois de corrigida a serial e, com ajuda de DQ e Ronaldo, a ordem de leitura CHS, a imagem deu boot no DOS 3.3 do Nexus dentro do MAME. Ficaram pendentes os dumps de outros terminais recém-chegados, a ligação serial do terminal TVA80, que não funcionou, e a emulação do Scopus Spectrum ED.
No ano 2 (2018-2019), Felipe compartilhou o livreto digitalizado "Scopus 30 anos", emprestado por DQ, com uma linha do tempo da empresa. Leonardo Roman questionou se o SISNE, o sistema operacional do Nexus, foi criado do zero, como afirma o livreto, ou copiado do MS-DOS. Ricardo Bánffy lembrou de sequências de bytes idênticas.
No ano 9 (2025-2026), Leonardo Roman voltou a perguntar se o SISNE é uma implementação clean-room do DOS, e RicBit passou a desmontá-lo. Ele estendeu seu sistema ao x86 e concluiu que o SISNE.SIS foi em parte compilado de linguagem de alto nível, diferente do MSDOS.SYS. Depois criou um compilador C que reproduz exatamente o binário do SISNE.SIS e publicou o repositório; Leonardo Roman indicou o relato de um desenvolvedor do SISNE 2 segundo o qual foi usado Lattice C. RicBit chegou a 64,2% de código compilado, que ele considera o limite, porque o resto é assembly escrito à mão. Publicou também o command.com, datado de 1990, que provavelmente é assembly escrito à mão.
Ano a ano: Ano 1 · Ano 2 · Ano 9
Foi proposto ao MAME, com crédito a Werner, um driver ainda não funcional do Sagitta 150/180 (PR #2776), e DQ desmontou parcialmente a EPROM do Lepus 200 e relatou seu trabalho na Scopus. No Nexus 2600 da Poli, Felipe "Juca" Sanches publicou um branch do MAME com os dumps do BIOS e da ROM do teclado, e Affonso Amendola leu as PROMs e gerou uma imagem do HD que, com ajuda de DQ e Ronaldo, deu boot no DOS 3.3 dentro do MAME.
Felipe e Werner planejaram a energização do terminal, e Felipe inspecionou a placa do Sagitta 150 na USP. O driver, ainda não funcional, foi proposto no PR #2776, que aguardava as alterações pedidas na revisão. Compilado por Werner, ele rodou, mas não respondia ao teclado.
Felipe mostrou o conversor USB-serial com chip FTDI que pretende usar com o Sagitta. Werner e Felipe discutiram a troca dos capacitores e o conector de alimentação, que tem três pinos alinhados e não segue nenhum padrão. Planejaram montar um cabo com plugues banana, medir fase, neutro e terra com um multímetro e verificar o fusível de 2 A.
Werner foi creditado no PR #2776, que traz um driver ainda não funcional do Scopus Sagitta 150/180 para o MAME. Felipe fotografou a placa do Sagitta 150 na USP: os baud rates impressos no silk, os cabos do CRT e os jumpers que separam a fonte da lógica digital. Ele também rastreou a varredura do teclado (74145, contador 7493, flip-flop 7474), mas ainda não achou onde ela chega ao barramento da CPU. Ficou combinada uma nova visita, com osciloscópio.
Felipe compartilhou o post do fórum Fiozera sobre os terminais seriais Sagitta 150 e 180 da Scopus. Em seguida anunciou que preparava mais um post para o dia seguinte, para consolidar as ideias discutidas no grupo.
O PR #2776 aguardava alterações pedidas na revisão. Felipe indicou o branch sagitta180 e o arquivo src/mame/drivers/scopus.cpp, que deve reunir os terminais da Scopus. Ele também mencionou que há um PC-XT da Scopus no acervo da USP. Werner compilou o driver e o emulador rodou, mas sem responder ao teclado.
Felipe distribuiu o dump da EPROM, e DQ publicou um disassembly parcial. Nele, DQ mostrou como o firmware simula o DMA com sequências de POP, como lê a matriz do teclado e como usa a porta E000. Também foi combinada uma gravação com DQ para o Happy Hacking Video Blog.
Ficou confirmada a ida ao LASSU, na Poli/USP, com dois objetivos. O primeiro era gravar um episódio do Happy Hacking Video Blog com Daniel Quadros (DQ) sobre os terminais da Scopus e o hardware do LEPUS 200. O segundo era organizar o acervo não exposto para montar uma bancada de restauração. DQ comentou que o Sagitta provavelmente usa teclas indutivas e que o Lepus teria sido o primeiro terminal da Scopus com teclas de contato.
Felipe distribuiu o dump da EPROM do Lepus 200. Ele observou que o endereçamento dos periféricos é definido por duas PROMs ligadas às linhas A15-A13 do 8085 e ao pino SOD. Os chips 8275 e 8276 foram comparados: o MAME só tem o 8275, e o 8276 não tem DMA. DQ publicou um disassembly parcial (lepus.asm) com o mapa de memória e indicou a application note AP-62 da Intel como inspiração do hardware do Lepus. Ele mostrou que o firmware simula o DMA com sequências de POP acionadas pela instrução SIM, e que usa truques para limpar linhas e rolar a tela.
DQ continuou o disassembly do Lepus 200. As teclas são lidas nos endereços E002 a E00B, um por linha da matriz, e só uma tecla é aceita por vez, além de shift e control. Shift e control escolhem tabelas de conversão em 0x41D, 0x46D e 0x4BD. Na porta E000, a leitura retorna a dip switch, e a escrita controla o baud rate, o buzzer e um bit que DQ primeiro achou ser o clique do teclado e depois disse parecer ser o LED de caps lock.
Com o teclado da Scopus, que não segue o padrão IBM, o Nexus 2600 deu boot no PC-DOS 3.3. As ROMs foram extraídas com o DEBUG, e as quatro PROMs TBP28L22N foram lidas com um leitor feito com Arduino. Felipe publicou um branch do MAME para o Nexus 2600, cujo BIOS escreve em portas fora do padrão do XT, como a D550h, que segundo DQ seleciona o clock.
Felipe e Affonso, estagiário do acervo de computadores da Poli, tentam usar um Scopus Nexus 2600 que boota mas não aceita digitação. DQ, que participou do projeto do BIOS e do sistema operacional do Nexus 1600, explica que a interface de teclado não segue o padrão da IBM (usa comunicação assíncrona com uma USART 8251) e que só funciona com o teclado da Scopus. Felipe extrai as duas ROMs de 8 KB e as carrega no driver de IBM 5160 do MAME, que fica em tela preta com um apito constante. Nas fotos, DQ identifica a controladora de floppy (NEC D765) e a placa de vídeo com MC6845, padrão CGA, com acesso sincronizado à memória de vídeo, e diz que uma placa com 8255 lhe parece uma controladora de HD.
Com o teclado Scopus, o Nexus 2600 boota no IBM PC-DOS 3.3, com Norton Editor, um compilador PL/M (ISIS86) e jogos como Alley Cat e Zork I. DQ explica que o Nexus não tem BASIC em ROM: a Scopus obteve da Microsoft os fontes do BASIC 8080 na época do CP/M e os converteu para o 8088.
DQ ensina a usar o DEBUG.COM para gravar regiões de memória em arquivo, e Felipe verifica que um dos dumps anteriores tinha bytes errados. No MAME, o BIOS escreve em portas fora do mapa de I/O padrão do XT (D550h, E140h e outras). DQ sugere que D550h selecione o clock entre 4,77 e 8 MHz: no Nexus 1600 a troca era feita por dip switch e no 2600 por uma combinação de teclas. Os valores 1234h/5678h em 0040:0072 foram identificados por DQ como sinalização do Ctrl-Alt-Del, com apoio do IBM PC XT Technical Reference.
O Nexus passou a apitar sem parar e a não reconhecer o HD. Affonso descobriu que a montagem do teclado estava desalinhada, travando teclas, e que o cabo tinha mau contato; o problema do HD foi um erro dele próprio. Felipe nota que a ROM do teclado ainda não foi extraída. Também se discutiram o relé de click, que segundo DQ é acionado pelo firmware do teclado, a ideia de usar samples no MAME para reproduzi-lo e o uso de vídeo composto da CGA pelos jogos da Sierra, que no Nexus (só RGB) aparecem com poucas cores.
Felipe publica um branch do MAME para o Nexus 2600 e os dumps do BIOS v5.03 e da ROM do teclado. Affonso rastreia a inicialização do BIOS até a escrita na porta D550h e a chamada para um endereço vazio onde a execução quebra. DQ explica que a porta 60h é o registrador de dados da 8251 do teclado e a 61h simula parte do Port B da 8255. Segundo ele, a porta de clock controla um MUX entre 4,77 e 8 MHz. Ele também comenta as decisões de projeto da Scopus.
Affonso fotografa a placa-mãe do Nexus e encontra quatro PROMs TBP28L22N. Felipe sugere montar um leitor com Arduino, já que o programador MiniPRO não lista esse chip. DQ supõe, a partir das etiquetas, que CsIBM decodifique os endereços de I/O compatíveis com o IBM PC, CsScopus os endereços próprios da Scopus, e que a PROM marcada Ram selecione os chips de RAM.
Affonso remove as quatro PROMs TBP28L22N da placa-mãe do Nexus e extrai seu conteúdo com um leitor feito com um Arduino emprestado por Felipe. Ele publica os quatro dumps e o código do leitor. Felipe revisa o código e sugere publicá-lo num repositório com licença livre.
Affonso rodou Zork num monitor de fósforo verde no Nexus 2600. A versão pelo interpretador frotz funcionou, mas o ZORK1.COM original mostrava artefatos no texto. Leonardo Roman e DQ os identificaram como códigos ANSI sem suporte. DQ testou no DOSBox as versões da GOG e do infocom-if, que rodaram sem problema. Ele então citou a nota do NNANSI: a versão compilada é para 80286 ou superior com teclado AT e VGA, e precisa ser recompilada para outros sistemas.
Affonso escreveu o xt-hd-imager para enviar os setores do HD pela serial. A primeira imagem, publicada no Internet Archive, perdia um bit de cada byte. Depois de corrigida a serial e a ordem de leitura CHS, a imagem deu boot no DOS 3.3 do Nexus dentro do MAME.
Para preservar o HD do Nexus, Affonso pergunta se um emulador de drive Gotek funcionaria; Felipe sugere um programa que envie os setores pela porta serial, e DQ menciona um programa de comunicação para DOS ou um programa digitado no DEBUG. Os dumps de ROM feitos com o DEBUG foram transferidos por disquete 5 1/4 e Gotek; a ligação do Gotek direto ao Nexus deu seek error. Affonso aponta relatos de uso do firmware do HxC.
Affonso começou a escrever em Borland C um programa que lê o HD do PC-XT Scopus Nexus 2600 e envia os setores pela serial a outro PC. Os testes eram feitos no emulador de XT do MAME. Felipe sugeriu o DOSBox para editar o código fora do emulador, e Affonso respondeu que já fazia isso. Felipe pediu que o código fosse para um repositório git, e Ismael Luceno ofereceu ajuda. Affonso publicou o repositório xt-hd-imager e conseguiu enviar um setor do disco emulado para um terminal serial no MAME.
O programa de transferência funcionou no Nexus real. A cópia completa levaria cerca de 4 horas, então Affonso compartilhou antes um resultado parcial (nexus.out), ainda sem três cabeças. Passando o comando strings, Felipe encontrou o código-fonte do leitor. Encontrou também textos de um programa que diz só poder ser executado no Nexus e lista velocidades iniciais do processador de 5, 8 e 12 MHz, e Affonso perguntou se seria da BraSoft. Felipe observou que o programa serviria para validar no MAME quais portas de I/O trocam a velocidade da CPU. Os caracteres acentuados apareciam quebrados. Felipe perguntou se a rotina descartava o que não fosse ASCII de 7 bits, e Affonso respondeu que não e atribuiu o efeito à codepage do DOS.
Affonso publicou no fórum Fiozera um relato do imageamento do HD do PC-XT Scopus Nexus 2600. Como usuário novo do fórum, ele só podia anexar uma imagem, e Felipe se ofereceu para publicar as outras fotos como resposta.
Affonso publicou a imagem do HD no Internet Archive com duas listas: a dos bad sectors (preenchidos com zeros) e a dos setores lidos só depois de várias tentativas. Nem o parted, nem o mount, nem o MAME conseguiram usá-la. Analisando os bytes, Affonso viu que nenhum valor passava de 7F, ou seja, um bit de cada byte se perdia na serial. Ele corrigiu o envio e preparou uma nova transferência.
Mesmo depois de corrigido o erro de paridade, a nova imagem não dava boot no emulador de XT do MAME. Ronaldo e DQ ajudaram a investigar. DQ orientou Affonso a ler o primeiro setor no Nexus real com o DEBUG e a INT 13h e a comparar com a imagem. Os dados batiam, e os bytes B6 6D foram identificados como resto da formatação. O problema era a ordem de leitura: o programa incrementava setor, cilindro e cabeça, e a convenção do DOS é setor, cabeça e cilindro. Com a imagem reordenada, ela deu boot no DOS 3.3 do Nexus dentro do MAME. Affonso compartilhou a imagem no grupo em .img e .chd.
DQ contou seu trabalho na Scopus com firmware de terminais e com o BIOS e o sistema operacional do Nexus. Explicou também a origem do SISNE e do BASIC do Nexus e os testes de compatibilidade feitos na Scopus com o jogo Sailing, cuja proteção contra cópia falhava a 8 MHz. Felipe digitalizou a publicação "Tecnologia Scopus", de 1983, trazida por DQ.
DQ contou que se formou em 1981, no que acredita ter sido a última turma a usar cartões perfurados antes de a USP comprar terminais Sagitta 180. De 1981 a 1986 trabalhou na Scopus com firmware de terminais de vídeo e com BIOS e sistema operacional de um micro compatível com PC, experiência que deu origem ao livro "PC Assembler". Ele mantém um blog desde 2005 e foi um dos fundadores do Garoa Hacker Clube.
Felipe criou o repositório Documentos_Scopus com o escaneamento de uma publicação da Scopus trazida por DQ e gerou o PDF de "Tecnologia Scopus", de outubro de 1983.
DQ conta que a primeira versão do SISNE (SIstema operacional do NExus) foi escrita num compilador Pascal com partes em assembler. O SISNE era o sistema oficial, mas muitos usuários rodavam PC-DOS ou MS-DOS. Segundo DQ, o nome tem ligação com o Patinho Feio por meio de Edson Fregni.
Affonso encontra no depósito uma peça com o logo da Scopus que parece ser uma interface de impressora. Felipe e DQ falam da Spectrum, que fabricou clones de Apple II (MicroEngenho e Spectrum ED), e de seus sócios; DQ observa que Spectrum e Scopus trabalhavam de forma independente. Um Spectrum ED foi resgatado do centro de reciclagem da Poli. Felipe menciona o Solution 16 de Sebastião, que estava no depósito do Garoa.
A partir do monitor de fósforo verde do Nexus, o grupo discute a disponibilidade de monitores coloridos. Com base na revista Byte, DQ afirma que a placa CGA saiu em 1981 com o PC, mas o monitor colorido da IBM só em 1983, com o XT. Ricardo Bánffy compara a qualidade do texto na CGA e na MDA e cita a Hercules. DQ relembra os testes de compatibilidade na Scopus com o jogo Sailing, cuja proteção contra cópia falhava a 8 MHz.
Affonso planejou fazer o dump das ROMs dos terminais recém-chegados e tentou, sem sucesso, ligar o terminal TVA80 a um PC pela serial. O Scopus Spectrum ED, de 1985, foi apontado como emulação pendente.
Felipe aponta como tarefa pendente de emulação de hardware nacional o "Scopus Spectrum ED, 1985".
Affonso perguntou de quais terminais Scopus já havia dump de ROM e disse que faria o dump dos recém-chegados. Felipe lembrou que mais dumps permitem achar versões diferentes de firmware ou EPROMs corrompidas. Affonso tentou ligar o terminal Scopus TVA80 a um PC por adaptador USB-serial e converteu o cabo em cross, sem sucesso. O conector tem só os pinos 1 a 4, 7, 18, 20 e 25. DQ listou os sinais clássicos do RS-232 e levantou a hipótese de elo de corrente. Também se falou em montar uma bancada de restauro na reserva técnica.
Felipe compartilhou o livreto digitalizado "Scopus 30 anos", emprestado por DQ. Leonardo Roman questionou se o SISNE foi criado do zero ou copiado do MS-DOS, e Ricardo Bánffy lembrou de sequências de bytes idênticas.
O livreto, emprestado por DQ, traz a linha do tempo da Scopus. Discutiu-se se o SISNE foi criado do zero ou copiado do MS-DOS, e foram lembradas sequências de bytes idênticas.
Felipe compartilhou o livreto digitalizado "Scopus 30 anos", emprestado por DQ, que traz uma linha do tempo da empresa. Leonardo Roman questionou se o SISNE foi mesmo criado do zero, como diz o livro, ou se era cópia do MS-DOS; Ricardo Bánffy lembrou de sequências de bytes idênticas. FTMaciel comentou sobre profissionais de informática dos anos 70/80 ainda ativos no serviço público.
RicBit desmontou o SISNE e criou um compilador C que reproduz exatamente o binário do SISNE.SIS. Chegou a 64,2% de código compilado, sendo o resto assembly escrito à mão, e publicou também o command.com.
RicBit estendeu seu sistema ao x86 e criou um compilador C que reproduz exatamente o binário do SISNE.SIS, chegando a 64,2% de código compilado; o resto é assembly escrito à mão. Publicou também o command.com.
Leonardo Roman questionou se o SISNE é implementação clean-room do DOS e indicou a imagem no Datassette. RicBit estendeu seu sistema ao x86, publicou o boot, o init e o início do SISNE.SIS, explicou que instruções como mov reg,reg têm duas codificações, e concluiu que o SISNE.SIS foi em parte compilado de linguagem de alto nível, diferente do MSDOS.SYS.
RicBit criou um compilador C que reproduz exatamente o binário do SISNE.SIS, deduzindo as otimizações do compilador original, e publicou o repositório. Leonardo Roman indicou o relato de um desenvolvedor do SISNE 2 segundo o qual foi usado Lattice C; L. propôs versões sem gotos de uma função ainda não reconstruída, e depois RicBit relatou ter conseguido o match dessa função.
RicBit avança na descompilação do SISNE, clone clean-room brasileiro do MS-DOS. Ele adiciona structs e unions ao compilador e lida com a ambiguidade de ponteiros near/far. Chega a 64,2% de código compilado e diz que esse é o limite, porque o resto é assembly escrito à mão, como mostra um mapa que separa C de asm. Comenta a quantidade de variáveis globais e de stack overflows. Ao abrir o command.com, datado de 1990, conclui que provavelmente é assembly escrito à mão. Publica o command.com completo, com os textos acentuados em Unicode convertidos para BRASCII na compilação.
Índice escrito por agentes Claude que leram o log completo de cada período. Um segundo agente conferiu cada conversa contra as mensagens, e um terceiro conferiu os resumos do ano e dos temas contra as conversas. Pode conter imprecisões: cada item leva às mensagens originais. Para procurar palavras específicas, use a busca.