"Color Extender para ZX-Spectrum": este es el título del artículo publicado en echo fido7.zx.spectrum el 3 de agosto de 1997. El artículo describió la idea de resolver uno de los principales problemas de la plataforma ZX-Spectrum: el choque de atributos . La publicación despertó cierto interés en ese momento, y me gustaría contar sobre detalles técnicos y la historia del problema.

Logotipo de ZX-Poly

No profundizaré en los detalles técnicos y solo describiré estructuralmente la idea y la solución.

Parte no técnica de la historia, puede omitir

La historia del desarrollo comenzó a principios de la primavera de 1994, cuando el país todavía experimentaba "cambios en el borrador", lo que condujo al cierre masivo de aplazamientos y al atractivo de los estudiantes de escuelas vocacionales y escuelas técnicas. Tuve suerte: estaba en mi último año en el Leningrad Radiotechnical College y de tal manera que el estado acordó dar un retraso a corto plazo para la recepción acelerada de un diploma con el reemplazo del diseño del diploma con un examen en todas las materias. Abandonó el ejército el 1 de marzo de 1994 como técnico de radio certificado.

En las fuerzas armadas en ese momento había una afluencia sin precedentes de los mismos especialistas del nivel técnico medio, aunque esto arruinó ligeramente el sistema de reclutamiento otoño-primavera en las cabezas de los "abuelos" que ya tenían una gradación clara en los nombres, llamaron a esta llamada no estándar "duende". Entre los "en auge" había suficiente gente aficionada al ZX-Spectrum y Alexander Gumin era así en mi división (escribió juegos en el ZX-Spectrum bajo la etiqueta ANCCAN con Denis Markelov y se hizo conocido por su adaptación de Mortal Kombat para esta plataforma en 1997), con quién hablar sobre programación y hardware.

Más cerca de mediados de abril de 1994, al final del "curso del joven luchador", Alexander y yo fuimos transferidos al batallón de construcción ubicado en Strelna, un suburbio de San Petersburgo. Allí tuvimos que dominar la difícil especialidad de cable-splicer durante varios meses. La vida en esta parte fluía sin prisa y el estudio alternaba con atuendos, que en su mayoría tensaban las manos, pero le daban tiempo al cerebro para reflexionar. Entonces, en uno de los conjuntos de la cocina, mi piso y pensando en el ZX-Spectrum y sus capacidades, se me ocurrió la idea de cómo superar el "conflicto de atributos".

Reflexioné sobre esta idea hasta el final del servicio y me convencí cada vez más de que "podría funcionar". Desafortunadamente, la idea de la viabilidad de la plataforma en sí, a la que iba a aplicar esta idea, me visitó con menos frecuencia. Sin embargo, en Rusia, el ZX-Spectrum brilló más vívidamente en el cielo desde aproximadamente 1991 hasta 1996. Algunos productores rusos de sus clones han aumentado tanto que patrocinaron programas de televisión (por ejemplo, la compañía Bi-Em patrocinó el programa "The Jungle's Name" por un tiempo). Pero durante el servicio hubo otros problemas, así que decidí posponer todos los problemas relacionados con el comercio hasta que me enviaran a la reserva. Periódicamente y sin revelar detalles, estaba interesado en varios expertos sobre el tema de la viabilidad técnica y la validez del enfoque. Mantuvo la idea en secreto y ni siquiera la compartió con Alexander Gumin, solo le indicó vagamente que había encontrado una solución muy simple para aumentar la cantidad de colores y mantener la compatibilidad con versiones anteriores.

Después de ingresar al "ciudadano" en 1997 y conseguir un trabajo como ingeniero de software de la segunda categoría en la empresa "Tecnologías y modelos de información" de San Petersburgo, comencé a interesarme un poco en la cuestión de comercializar la solución. Por alguna razón, estaba seguro de que si solo insinuaba la solución que había encontrado, todos comenzarían a llorar con las manos y el dinero fluiría. Comencé a llamar a los conocidos, en ese momento en el campo de los fabricantes y comerciantes de "Ingeniería del espectro", como Sergey Zonov, Vyacheslav Skutin (Nemo) y otros. Sergey Zonov simplemente me dijo que "el tren ya se fue" y que ya no hay ningún sentido comercial en esta empresa. Vyacheslav Skutin, siendo un ortopedista ortodoxo, se mostró hostil con cualquier idea en la que intentaran cambiar algo en la plataforma y esta también era una versión completamente muerta. Decidí que se hablaba poco y que al menos había que hacer algo y que era mejor comenzar con un emulador para obtener materiales promocionales y datos experimentales.

En 1998, tomando como base uno de los emuladores ZX-Spectrum de código abierto existentes en ese momento escritos en Pascal, hice un emulador primitivo de cuatro computadoras trabajando en paralelo. Adapté parcialmente el juego After The War 2, coloreando algunos de sus sprites. El sistema funcionó y, además de disfrutar de la idea de trabajo, obtuve capturas de pantalla a mi disposición que confirmaban la idea de colorear los juegos existentes.

En 1998, visité la compañía Peters, que estaba desarrollando su nueva plataforma Sprinter en ese momento. Intentó interesar a su director Nikolai Noskov. Invertieron mucho en el nuevo desarrollo y, de acuerdo con la ley de la mezquindad, la arquitectura súper flexible de Sprinter, capaz de emular casi cualquier plataforma de procesador único en el Z80, no podía extender cuatro procesadores. Sin embargo, una visita a esta empresa fue muy útil, ya que se reunió con el autor de la plataforma Sprinter Ivan Makarchenko y aprendió sobre nuevas oportunidades en el campo del desarrollo de FPGA.

Pronto la crisis de 1998 "se marchitó" y había una ingenua esperanza de que el interés en el ZX-Spectrum pudiera revivir. A principios de 1999, nosotros (con mi socio en ese momento, Andrei Savichev) incluso teníamos planes de crear el "Fondo Nacional del Espectro" y se celebró una reunión sobre este tema en la nueva oficina de la misma compañía Peters. Pero no entran en el mismo río dos veces y, por supuesto, nada salió de él. Ya en 1999, todas las ideas sobre el tema de la implementación de hardware de la plataforma fueron descartadas (trabajamos en este desarrollo con Sergey Egorov, pero no fuimos más allá de los esquemas). Hasta 2007, prácticamente no traté con la plataforma, pero hubo tiempo y decidí volver a escribir el emulador y resolver los detalles de la plataforma, comprobar los enfoques y dejarlos "virtualmente".

El modo de video estándar ZX-Spectrum, muestra 256 por 192 píxeles. En modo monocromo, esto requiere solo 6144 bytes, que es aproximadamente el 10% del campo de memoria total (frente al 50% en el BK-0010). La información de color se almacena en 768 bytes adicionales ubicados inmediatamente después de los datos de píxeles. La paleta consta de ocho colores y dos tonos. El color de los píxeles iluminados y descartados se determina inmediatamente para el bloque de 8 por 8 píxeles, y el tono se determina inmediatamente para el color de los píxeles iluminados y descartados.

Se ve colorido y una cantidad relativamente pequeña de datos se envía muy rápidamente, pero requiere un increíble esfuerzo y arte de artistas y programadores al desarrollar juegos de color y protectores de pantalla. La menor inconsistencia en el gráfico conduce a un conflicto de atributos. La mayoría de los desarrolladores hicieron su trabajo perfectamente y con el telón de fondo de BK-0010, con sus solo cuatro colores (¡pero para cada punto!), El espectro cuasi-color parecía muy ventajoso y fresco.

Ejemplo de atributo ZX-Spectrum

Con el desarrollo de la plataforma para ZX-Spectrum 128, se agregó la capacidad de cambiar el hardware entre dos páginas de memoria de video. Los programadores encontraron rápidamente una forma de obtener varios colores utilizando un cambio muy rápido de las páginas de video mostradas y un cambio dinámico de los atributos de color.

Debido a esto, incluso fue posible aumentar programáticamente la resolución de la pantalla (que se muestra perfectamente, por ejemplo, en la demostración "Dead Morose", donde al mismo tiempo el texto se ejecuta con una resolución de 256, 512 y 768 puntos horizontalmente).

Pero cualquier solución de software que requiera un aumento en el flujo de información de video condujo a un aumento en el consumo del procesador, lo cual es muy crítico en el caso de los juegos dinámicos. No había una fuente no utilizada de reservas de energía informática en el sistema. Todo se cuelga del procesador en el ZX-Spectrum y le da un poco de descarga, excepto quizás el procesador de música en el campo de los efectos de sonido.

Mi idea era que podría agregar tres procesadores más, lanzando sobre cada uno de ellos el procesamiento de su componente de color. Los datos recibidos de la memoria de video de cada procesador deben integrarse, formando un valor YRGB para cada píxel . Los atributos de color estándar se ignoran. El procesamiento paralelo de la información debe garantizar que no se produzca una disminución del rendimiento.

Esquema de color en ZX-Poly 256x192

No puedo decir que fue original en la idea, ya que se inspiró en la lectura del libro traducido "The Computer Gains Mind" (Mir Publishing House, 1990), que describe una determinada plataforma gráfica Pixar desarrollada en Lucasfilm. Y según TRIZ, es solo una transición de un mono-sistema a un polisistema.

sección de la página del libro "The Computer Gains Mind"

Una pregunta muy dolorosa para cualquier desarrollo, ¿y quién escribirá el programa? (en particular, la plataforma Sprinter se encontró con esta "trampa"). En mi caso, el problema con el software se resolvió automáticamente por el hecho de que muy raramente los programas existentes verificaban qué tipo de datos grababan en la memoria de video y simplemente trabajaban con ellos "como un cartero con una carta sellada". Según mis cálculos, resultó que la mayoría de los programas de juegos existentes podrían sobrevivir fácilmente a la adaptación de sus datos de video sin cambios en el código ejecutable. Por supuesto, se cortaron los juegos con un paquete de gráficos u optimizaciones internas en su salida a la pantalla. Adaptar tales programas requeriría investigación y alteración del código ejecutable. El desarrollo de ROM especializadas no era necesario en absoluto.

Creo que este concepto es aplicable a cualquier plataforma doméstica antigua (por ejemplo, AGAT, Radio86RK, BK-0010, etc.), donde no hay un acelerador de video dedicado y el procesador funciona directamente con la memoria de video para formar una imagen.

En la primera versión del emulador, acabo de hacer que cuatro ZX-Spectrum 48 funcionen sincrónicamente, pero lo que es fácil de simular en el emulador es muy difícil de repetir en hardware real. Es bastante difícil asegurar la carga de datos en cuatro módulos informáticos y hacer un inicio sincrónico desde la misma dirección. Una solución similar que Spec256 presenta para este SIMD Z80 virtual especializado de 64 bits, que no existe en la naturaleza. Como parte de una solución más realista (y más compleja) a este problema, se formó la plataforma ZX-Poly.

Del "extensor de color" a ZX-Poly

Módulos de procesador

ZX-Poly es una plataforma informática basada en el ZX-Spectrum 128 que contiene cuatro módulos de procesador. Cada módulo tiene sus propios puertos de E / S del sistema direccionables visibles desde el exterior. Aunque los módulos del procesador comparten las señales de control del sistema (RESET, NMI, CLK e INT), funcionan de manera independiente.

Diagrama de bloques

Hay una cierta clasificación según el índice del módulo: cuanto menor es el índice, mayor es el rango, respectivamente, el "módulo 0" es el maestro en el sistema. El acceso de escritura a los puertos del sistema del módulo solo está permitido para el módulo con el mismo rango o superior, no hay restricciones de lectura. Esto se hizo porque había pensamientos sobre el desarrollo de un sistema operativo especializado.

Ranking de módulos

Un detalle muy importante es que todos los dispositivos de procesador utilizados deben ser del mismo fabricante (y sería bueno tener una serie de producción), ya que la más mínima diferencia en su organización interna u optimización puede violar la consistencia del sistema.

Inmediatamente después del inicio del sistema, solo se inicia el módulo maestro (CPU0), los módulos restantes están en modo de ESPERA, por lo que para el usuario todo pasa desapercibido.

En el espacio IO, ZX-Poly agrega los siguientes puertos disponibles para escritura y lectura:

puerto de configuración 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

El puerto de configuración principal de ZX-Poly es $ 3D00. Solo el módulo maestro puede escribir en él, pero está disponible para leer en todos los módulos y se devuelve cada una de sus propias informaciones especializadas. En particular, un módulo puede encontrar su índice, si su memoria está asignada a los puertos IO del módulo principal, el desplazamiento de su memoria en el montón, etc. Además, el puerto de configuración de la plataforma base $ 7FFD ha sufrido cambios menores, que utilizan bits no utilizados en el original.

El recuerdo

Como en la arquitectura original del ZX-Spectrum 128, hay ROM y RAM. Si la organización y el trabajo con la ROM prácticamente no cambiaron, la RAM se convirtió en un "montón" común de 512 KB en el que cada procesador funciona con una ventana dedicada de 128 KB (esto es 8 páginas de 16 KB en el ZX-Spectrum 128). El desplazamiento de la ventana se puede cambiar en incrementos de 64 Kb y se puede proyectar que todos los módulos de procesador funcionen con una pieza de memoria superpuesta total o parcialmente en el montón. La ROM se puede desactivar y la página RAM0 RAM se conectará en su lugar (esto le permite hacer una versión "a todo color" del sistema operativo base, por ejemplo, un intérprete básico). Después de un RESET de hardware, todos los módulos reciben compensaciones automáticas para separar las ventanas de memoria en el montón.

El módulo maestro del procesador (CPU0) tiene la capacidad de asignar los espacios de direcciones de otros módulos (CPU1-3) en el área de sus puertos IO. Es decir él puede escribir en el puerto, cambiando el estado de la celda de memoria de un módulo dado, y al mismo tiempo, es posible generar una señal NMI en un módulo mapeado. Al leer desde las celdas de memoria de un módulo mapeado, es posible la generación INT. Esto se hizo para emular dispositivos virtuales utilizando los módulos 1-3.

Controlador de video

La "cereza" principal es, por supuesto, un controlador de video, todo se inició para ello. En total, la plataforma admite cinco modos de video.

Modos de video ZX-Spectrum 128 (modo 0,1,2,3)

Estos modos de video son irrelevantes y no difieren en absoluto del modo de video estándar ZX-Spectrum 128. Se muestra la página de video actual del módulo de procesador seleccionado con color de atributo. Inmediatamente después del inicio del sistema, se activa el modo 0, es decir. Se muestra la página de video del módulo maestro (CPU0).

ATW2 en modo ZX estándar

ZX-Poly 256x192 (modo 4)

Este modo de video no utiliza ningún dato del área de atributos. El bit de píxel de cada módulo se combina con los datos de píxel de otros módulos y los cuatro bits generados se utilizan para generar una señal YRGB de brillo de color.

Cada módulo es responsable de su componente:

módulo 0 (maestro) para verde (verde).
módulo 1 para rojo (rojo)
módulo 2 para azul (azul)
módulo 3 para brillo

versión coloreada

Si comienzas un juego no adaptado en este modo, simplemente será en blanco y negro.

ZX-Poly 256x192 con enmascaramiento por TINTA + PAPEL (modo 6)

Al igual que el anterior, proporciona 16 colores para cada punto, pero hay un "truco". En algunos programas de ZX-Spectrum, los elementos gráficos se ocultan utilizando los valores idénticos de INK y PAPER en los atributos, especialmente en los juegos de desplazamiento. Si elimina esta oportunidad, los elementos gráficos comienzan a acumularse en la pantalla, rompiendo la imagen. Por lo tanto, el estado de TINTA y PAPEL se analiza a partir del atributo del módulo maestro leído desde la memoria de video (CPU0) y si son idénticos, todos los puntos se resaltan con el color tomado de TINTA / PAPEL (por supuesto, teniendo en cuenta el brillo).

ZX-Poly 256x192 con enmascaramiento por FLASH + TINTA + PAPEL (modo 7)

El modo es una combinación del modo 4 y el modo 6. Para los atributos legibles del módulo maestro (CPU0), se analiza el bit FLASH y, si está configurado (lo cual es raro en juegos dinámicos en el campo de juego), el bloque de 8 por 8 píxeles se muestra en el modo modo 6 ( con enmascaramiento con TINTA y PAPEL idénticos). Si se reinicia FLASH, el bloque se muestra como en un ZX-Spectrum normal. El bit FLASH no se practica en su función directa y no habrá parpadeo.
Este modo es muy conveniente para evitar volver a pintar los paneles de información del juego y algunos efectos en el juego (por ejemplo, cuando los desarrolladores de juegos destellan en el campo de juego a través de atributos).

Tiburón volador adaptado animado

ZX-Poly 512x384 con atributos (modo 5)

Los atributos se usan casi de la misma manera que en la plataforma original, sin ningún cambio (incluso el bit FLASH). Los datos de píxeles de video de cada módulo se colorean con un atributo de la memoria de video de este módulo y, después de pasar por el color, se muestran en un patrón de tablero de ajedrez, debido a que un bloque de familiaridad es de 16 por 16 puntos.

formación de ajedrez

Este modo le permite duplicar la resolución de las aplicaciones sin cambiar el código ejecutable. Es cierto que los experimentos con el mismo juego "Pinocho" mostraron que en juegos brillantes con grandes detalles, el efecto será poco notable. Como se trata de una especie de píxeles virtuales, los juegos no saben nada sobre esto y el movimiento mínimo posible de los elementos del juego es del nivel de dos píxeles virtuales. Creo que este modo es bueno para juegos con pequeños objetos de juego en un lugar familiar.

ejemplo del juego "Pinocho"

Se obtuvo un efecto mucho mejor en este modo de video en aplicaciones de texto, por ejemplo, en el editor de texto ZX-Word, donde la fuente se procesó sin cambios en el código ejecutable.

ZX-Word adaptado

Multitarea

A pesar de que los procesadores del sistema utilizan la misma fuente de señales de control, funcionan de manera independiente. El sistema no puede llamarse un SIMD completo, ya que cada procesador procesa instrucciones desde su propio bloque de memoria, simplemente aprovecha la capacidad de "sacar" las mismas instrucciones. , " " — .