"Color Extender for ZX-Spectrum" - este é o título do artigo publicado no echo fido7.zx.spectrum em 3 de agosto de 1997. O artigo descreveu a idéia de resolver um dos principais problemas da plataforma ZX-Spectrum - conflito de atributos . A publicação despertou algum interesse naquele momento, e eu gostaria de falar sobre detalhes técnicos e a história do problema.
Não vou me aprofundar nos detalhes técnicos e apenas descrever estruturalmente a idéia e a solução.
Parte não técnica da história, você pode pularA história do desenvolvimento começou no início da primavera de 1994, quando o país ainda vivia "mudanças no rascunho", o que levou ao fechamento maciço de adiamentos e ao apelo de estudantes de escolas profissionais e técnicas. Tive sorte - estive no meu último ano no Colégio Radiotécnico de Leningrado e, dessa forma, o Estado concordou em adiar a curto prazo o recebimento acelerado de um diploma com a substituição do design do diploma por um exame em todas as disciplinas. Ele deixou o exército em 1 de março de 1994, como técnico de rádio certificado.
Nas forças armadas da época, havia um afluxo sem precedentes dos mesmos especialistas do nível técnico médio, embora isso arruinasse levemente o sistema de recrutamento outono-primavera na cabeça dos "avós", que já tinham uma classificação clara nos nomes, eles apelidaram de "goblin". Entre os "estrondosos", havia muitas pessoas que gostavam do ZX-Spectrum e Alexander Gumin era assim na minha divisão (ele escreveu jogos no ZX-Spectrum sob o selo ANCCAN com Denis Markelov e ficou conhecido por sua adaptação do Mortal Kombat para esta plataforma em 1997), com quem falar sobre programação e hardware.
Mais perto de meados de abril de 1994, no final do "curso de jovens lutadores", Alexander e eu fomos transferidos para o batalhão de construção localizado em Strelna, um subúrbio de São Petersburgo. Lá tivemos que dominar a difícil especialidade do cortador de cabos por vários meses. A vida nessa parte fluía sem pressa e o estudo alternava com roupas, que na maioria das vezes esticavam as mãos, mas davam ao cérebro tempo para reflexão. Então, em uma das roupas da cozinha, no meu andar e pensando no ZX-Spectrum e suas capacidades, tive a idéia de como superar o "conflito de atributos".
Eu ponderei essa idéia até o final do serviço e fiquei cada vez mais convencido de que "poderia funcionar". Infelizmente, a ideia da viabilidade da própria plataforma, à qual eu iria aplicar essa ideia, me visitou com menos frequência. No entanto, na Rússia, o ZX-Spectrum brilhou mais vivamente no céu entre 1991 e 1996. Alguns produtores russos de seus clones aumentaram tanto que patrocinaram programas de TV (por exemplo, a empresa Bi-Em patrocinou o programa "The Jungle's Name" por um tempo). Mas durante o serviço havia outros problemas, então decidi adiar todos os problemas relacionados ao comércio até ser enviado para a reserva. Periodicamente e sem revelar detalhes, eu estava interessado em vários especialistas no tópico de viabilidade técnica e validade da abordagem. Ele manteve a idéia em segredo profundo e nem a compartilhou com Alexander Gumin, apenas indicando-lhe vagamente que havia encontrado uma solução muito simples para aumentar o número de cores, mantendo a compatibilidade com versões anteriores.
Tendo ingressado no “cidadão” em 1997 e conseguido um emprego como engenheiro de software da segunda categoria na empresa de São Petersburgo “Tecnologias e modelos de informação”, comecei a me interessar um pouco pela questão da comercialização da solução. Por alguma razão, eu tinha certeza de que, se apenas sugerisse a solução que encontrei, todos começariam a rasgar com as mãos e o dinheiro fluiria. Comecei a telefonar para o conhecido, na época, na área de fabricantes e comerciantes de "Engenharia do espectro", como Sergey Zonov, Vyacheslav Skutin (Nemo) e outros. Sergey Zonov simplesmente me disse que "o trem já partiu" e não há mais sentido comercial nesse empreendimento. Vyacheslav Skutin, sendo um spektrumist ortodoxo, ficou hostil com qualquer idéia em que tentassem mudar alguma coisa na plataforma e essa também era uma versão completamente morta. Decidi que havia pouca conversa e pelo menos algo precisava ser feito, e era melhor começar com um emulador para obter materiais promocionais e dados experimentais.
Em 1998, tomando como base um dos emuladores ZX-Spectrum de código aberto existentes na época, escritos em Pascal, criei um emulador primitivo de quatro computadores trabalhando em paralelo. Eu parcialmente adaptei o jogo After The War 2 para ele, colorindo alguns de seus sprites. O sistema funcionou e, além de aproveitar a ideia de trabalho, consegui capturas de tela à minha disposição, confirmando a ideia de colorir jogos existentes.
Em 1998, visitei a empresa Peters, que estava desenvolvendo sua nova plataforma Sprinter na época. Ele tentou interessar o diretor Nikolai Noskov. Eles investiram pesadamente no novo desenvolvimento e, de acordo com a lei da maldade, a arquitetura super flexível do Sprinter, capaz de emular quase qualquer plataforma de processador único no Z80, não podia estender quatro processadores. No entanto, uma visita a essa empresa foi muito útil, pois ele se encontrou com o autor da plataforma Sprinter, Ivan Makarchenko, e aprendeu sobre novas oportunidades no campo do desenvolvimento de FPGA.
Logo a crise de 1998 "murchava" e havia uma ingênua esperança de que o interesse no ZX-Spectrum pudesse reviver. No início de 1999, nós (com meu parceiro na época, Andrei Savichev) tínhamos planos de criar o "Fundo Nacional do Espectro" e uma reunião foi realizada sobre esse assunto no novo escritório da mesma empresa de Peters. Mas eles não entram no mesmo rio duas vezes e, é claro, nada aconteceu. Já em 1999, todas as idéias sobre o tópico de implementação de hardware da plataforma foram descartadas (trabalhamos nesse desenvolvimento com Sergey Egorov, mas não fomos além dos esquemas). Até 2007, eu praticamente não lidava com a plataforma, mas houve tempo e decidi reescrever o emulador e elaborar os detalhes da plataforma, verificando as abordagens e deixando-as "virtualmente".
O modo de vídeo padrão ZX-Spectrum, exibe 256 por 192 pixels. No modo monocromático, isso requer apenas 6144 bytes, o que representa aproximadamente 10% do campo total da memória (contra 50% no BK-0010). As informações de cores são armazenadas em 768 bytes adicionais, localizados imediatamente após os dados de pixel. A paleta consiste em oito cores e dois tons. A cor dos pixels iluminados e descartados é determinada imediatamente para o bloco de 8 por 8 pixels e o matiz é determinado imediatamente para a cor dos pixels iluminados e descartados.
Parece colorido e uma quantidade relativamente pequena de dados é enviada muito rapidamente, mas exige um esforço e arte incríveis de artistas e programadores no desenvolvimento de jogos e protetores de tela coloridos. A menor inconsistência no gráfico leva a um conflito de atributos. A maioria dos desenvolvedores fez seu trabalho bem no cenário BK-0010, com apenas quatro cores (mas para todos os pontos!), A quase-cor Spectrum parecia muito vantajosa e atual.
Com o desenvolvimento da plataforma para o ZX-Spectrum 128, foi adicionada a capacidade de alternar o hardware entre duas páginas de memória de vídeo. Os programadores encontraram rapidamente uma maneira de obter várias cores usando uma mudança muito rápida das páginas de vídeo exibidas e uma alteração dinâmica dos atributos de cores.
Por isso, foi possível aumentar programaticamente a resolução da tela (o que é perfeitamente mostrado, por exemplo, na demonstração "Dead Morose", onde ao mesmo tempo o texto é executado com uma resolução de 256, 512 e 768 pontos horizontalmente).
Porém, qualquer solução de software que exija um aumento no fluxo de informações de vídeo leva a um aumento no consumo do processador, o que é muito crítico no caso de jogos dinâmicos. Não havia fonte não utilizada de reservas de energia de computação no sistema. Tudo depende do processador no ZX-Spectrum e fornece uma pequena descarga, exceto talvez o processador de música no campo dos efeitos sonoros.
Minha idéia era que você poderia adicionar mais três processadores, lançando em cada um deles o processamento de seus componentes de cores. Os dados recebidos da memória de vídeo de cada processador devem ser integrados, formando um valor YRGB para cada pixel . Atributos de cores padrão são ignorados. O processamento paralelo de informações deve garantir que não haja desempenho de flacidez.
Não posso dizer que era original na idéia, porque foi inspirado pela leitura do livro de tradução "The Computer Gains Mind" (Mir Publishing House, 1990), que descreveu uma certa plataforma gráfica da Pixar desenvolvida na Lucasfilm. E, de acordo com o TRIZ, é apenas uma transição de um monossistema para um polissistema.
Uma pergunta muito dolorosa para qualquer desenvolvimento - e quem escreverá o programa? (em particular, a plataforma Sprinter se deparou com essa "armadilha"). No meu caso, o problema com o software foi resolvido automaticamente pelo fato de que raramente os programas existentes verificavam que tipo de dados eles gravavam na memória de vídeo e simplesmente trabalhavam com eles "como um carteiro com uma carta selada". De acordo com meus cálculos, verificou-se que a maioria dos programas de jogos existentes poderia sobreviver com facilidade à adaptação de seus dados de vídeo sem alterações no código executável. Obviamente, jogos com um pacote de gráficos ou otimizações internas em sua saída para a tela foram cortados. A adaptação de tais programas exigiria pesquisa e alteração do código executável. O desenvolvimento de ROMs especializadas não era necessário.
Eu acho que esse conceito é aplicável a qualquer plataforma doméstica antiga (por exemplo, AGAT, Radio86RK, BK-0010 etc.), onde não há acelerador de vídeo dedicado e o processador trabalha diretamente com a memória de vídeo para formar uma imagem.
Na primeira versão do emulador, acabei de fazer com que quatro ZX-Spectrum 48s funcionassem de forma síncrona. Mas o que é fácil de simular no emulador é muito difícil de repetir em hardware real. É bastante difícil garantir o carregamento de dados em quatro módulos de computação e iniciar de forma síncrona a partir do mesmo endereço. Uma solução semelhante que Spec256 apresenta para esse SIMD Z80 virtual especializado de 64 bits, que não existe na natureza. Como parte de uma solução mais realista (e mais complexa) para esse problema, a plataforma ZX-Poly foi formada.
Do “Color Extender” ao ZX-Poly
Módulos do processador
O ZX-Poly é uma plataforma de computação baseada no ZX-Spectrum 128 contendo quatro módulos de processador. Cada módulo possui suas próprias portas de E / S endereçáveis visíveis externamente. Embora os módulos do processador compartilhem os sinais de controle do sistema (RESET, NMI, CLK e INT), eles funcionam independentemente.
Existe uma certa classificação, dependendo do índice do módulo - quanto menor o índice, maior a classificação, respectivamente, "módulo 0" é o mestre no sistema. O acesso de gravação às portas do sistema do módulo é permitido apenas para o módulo com classificação igual ou superior, não há restrições de leitura. Isso foi feito porque havia pensamentos sobre o desenvolvimento de um sistema operacional especializado.
Um detalhe muito importante é que todos os dispositivos de processador usados devem ser do mesmo fabricante (e seria bom ter uma série de produção), pois a menor diferença em sua organização interna ou otimização pode violar a consistência do sistema.
Imediatamente após o início do sistema, apenas o módulo mestre (CPU0) é iniciado, os módulos restantes estão no modo WAIT, portanto, para o usuário, tudo passa despercebido.
No espaço IO, o ZX-Poly adiciona as seguintes portas disponíveis para gravação e leitura:
- porta de configuração principal $ 3D00
- módulo 0 - $ 00FF, $ 10FF, $ 20FF, $ 30FF
- módulo 1 - $ 01FF, $ 11FF, $ 21FF, $ 31FF
- módulo 2 - $ 02FF, $ 12FF, $ 22FF, $ 32FF
- módulo 3 - $ 03FF, $ 13FF, $ 23FF, $ 33FF
A principal porta de configuração do ZX-Poly é $ 3D00. Somente o módulo mestre pode gravar nele, mas ele está disponível para leitura em todos os módulos e cada uma de suas próprias informações especializadas é retornada. Em particular, um módulo pode descobrir seu índice, se sua memória está mapeada para as portas de E / S do módulo principal, o deslocamento de sua memória na pilha, etc. Além disso, a porta de configuração da plataforma base $ 7FFD passou por pequenas alterações, que usam bits não utilizados no original.
A memória
Como na arquitetura original do ZX-Spectrum 128, existem ROM e RAM. Se a organização e o trabalho com a ROM praticamente não mudaram, a RAM se transformou em um "heap" comum de 512 KB, no qual cada processador trabalha com uma janela dedicada de 128 KB (ou seja, 8 páginas de 16 KB no ZX-Spectrum 128). O deslocamento da janela pode ser alterado em incrementos de 64 Kb e todos os módulos do processador podem ser projetados para funcionar com uma parte de memória total ou parcialmente sobreposta no heap. A ROM pode ser desativada e a página RAM0 RAM será conectada em seu lugar (isso permite criar uma versão "colorida" do sistema operacional base, por exemplo, um intérprete básico). Após uma redefinição de hardware, todos os módulos recebem deslocamentos automáticos para separar as janelas de memória na pilha.
O mestre do módulo processador (CPU0) tem a capacidade de mapear os espaços de endereço de outros módulos (CPU1-3) na área de suas portas de E / S. I.e. ele pode gravar na porta, alterando o estado da célula de memória de um determinado módulo e, ao mesmo tempo, é possível gerar um sinal NMI em um módulo mapeado. Ao ler as células de memória de um módulo mapeado, a geração INT é possível. Isso foi feito para emular dispositivos virtuais usando os módulos 1-3.
Controlador de vídeo
A principal “cereja” é, obviamente, um controlador de vídeo, tudo foi iniciado para isso. No total, a plataforma suporta cinco modos de vídeo.
Modos de vídeo ZX-Spectrum 128 (modo 0,1,2,3)
Esses modos de vídeo não são dignos de nota e não diferem em nada do modo de vídeo padrão do ZX-Spectrum 128. A página de vídeo atual do módulo de processador selecionado com coloração de atributo é exibida. Imediatamente após o início do sistema, o modo 0 é ativado, ou seja, A página de vídeo do módulo mestre (CPU0) é exibida.
ZX-Poly 256x192 (modo 4)
Este modo de vídeo não usa nenhum dado da área de atributo. O bit de pixel de cada módulo é combinado com os dados de pixel de outros módulos e os quatro bits gerados são usados para gerar um sinal YRGB de brilho de cor.
Cada módulo é responsável por seu componente:
- módulo 0 (mestre) para verde (verde).
- módulo 1 para vermelho (vermelho)
- módulo 2 para azul (azul)
- módulo 3 para brilho
Se você iniciar um jogo não adaptado nesse modo, ele será simplesmente preto e branco.
ZX-Poly 256x192 com máscara por INK + PAPER (modo 6)
Como o anterior, ele fornece 16 cores para cada ponto, mas há um "truque". Em alguns programas do ZX-Spectrum, os elementos gráficos são ocultos usando os valores idênticos de INK e PAPER nos atributos, especialmente em jogos de rolagem. Se você remover esta oportunidade, os elementos gráficos começarão a se acumular na tela, quebrando a imagem. Portanto, o estado de TINTA e PAPEL é analisado a partir do atributo do módulo mestre lido na memória de vídeo (CPU0) e, se forem idênticos, todos os pontos serão destacados com a cor retirada de TINTA / PAPEL (é claro, levando em consideração o brilho).
ZX-Poly 256x192 com máscara por FLASH + TINTA + PAPEL (modo 7)
Mode é uma combinação dos modos 4 e 6. Para os atributos legíveis do módulo mestre (CPU0), o bit FLASH é analisado e, se estiver definido (o que é raro em jogos dinâmicos no campo de jogo), o bloco 8 por 8 pixels é exibido no modo 6 ( com máscara com TINTA e PAPEL idênticos). Se o FLASH for reiniciado, o bloco será exibido como em um ZX-Spectrum comum. O bit FLASH não é praticado em sua função direta e não pisca.
Esse modo é muito conveniente para evitar redesenhar os painéis de informações do jogo e alguns efeitos no jogo (por exemplo, quando os desenvolvedores de jogos piscam no campo de jogo por meio de atributos).
ZX-Poly 512x384 com atributos (modo 5)
Os atributos são usados quase da mesma maneira que na plataforma original, sem nenhuma alteração (mesmo o bit FLASH). Os dados de pixel de vídeo de cada módulo são coloridos com um atributo da memória de vídeo deste módulo e, após passar pela coloração, são exibidos em um padrão quadriculado, devido ao qual um bloco de familiaridade é de 16 por 16 pontos.
Este modo permite dobrar a resolução dos aplicativos, sem alterar o código executável. É verdade que experimentos com o mesmo jogo "Pinóquio" mostraram que em jogos brilhantes com grandes detalhes, o efeito será pouco perceptível. Como esses são pixels virtuais, os jogos não sabem nada sobre isso e o movimento mínimo possível dos elementos do jogo é no nível de dois pixels virtuais. Eu acho que esse modo é bom para jogos com pequenos objetos de jogo em um local familiar.
Um efeito muito melhor nesse modo de vídeo foi obtido em aplicativos de texto, por exemplo, no editor de texto ZX-Word, onde apenas a fonte foi processada sem alterações no código executável.
Multitarefa
Apesar de os processadores do sistema usarem a mesma fonte de sinais de controle, eles funcionam de forma independente. O sistema não pode ser chamado de SIMD de pleno direito, já que cada processador processa instruções de seu próprio bloco de memória, simplesmente aproveita a capacidade de "palm off" as mesmas instruções. , " " — .
, , "". , .
RESET
RESET , . JP ADDR .
-
master- (CPU0). , ( M1), WAIT, RESET. , , 16 .
2007 JavaSE . Z80 ( -) FDD 181893. JDK 1.8+ .
ZX-Spectrum , 80% , . ZX-Spectrum 128, Options->ZX 128 Mode , ZX-Poly .
-, ZX-Spectrum — . , File->Options
Se os jogos não usarem pacotes de sprites, a coloração será bem simples. É preciso ter cuidado quando houver otimizações no código executável de saída do sprite, pois isso pode levar à dessincronização dos módulos do processador.
Um gerenciador de inicialização foi desenvolvido para carregar dados nos módulos a partir de um disco e iniciar simultaneamente simultaneamente. Seu código para TAP e TR-DOS é apresentado no projeto.
Juntamente com o emulador, um pequeno utilitário (também escrito em Java) para aplicativos de coloração foi desenvolvido.
Todo o projeto é publicado no GitHub sob a licença GNU GPLv3 .
