"Color Extender for ZX-Spectrum" - das ist der Titel des Artikels, der am 3. August 1997 im echo fido7.zx.spectrum veröffentlicht wurde. Der Artikel beschrieb die Idee, eines der Hauptprobleme der ZX-Spectrum-Plattform zu lösen - den Attribut-Konflikt . Die Veröffentlichung erregte damals ein gewisses Interesse, und ich möchte über technische Details und die Geschichte des Problems berichten.

ZX-Poly Logo

Ich werde nicht tief in die technischen Details gehen und nur die Idee und Lösung strukturell beschreiben.

Nicht-technischer Teil der Geschichte können Sie überspringen

Die Entwicklungsgeschichte begann im Frühjahr 1994, als das Land noch "Änderungen im Entwurf" erlebte, die zur massiven Schließung von Stundungen und zur Attraktivität von Schülern von Berufsschulen und technischen Schulen führten. Ich hatte Glück - ich war in meinem letzten Jahr am Leningrader Radiotechnischen Kolleg und so stimmte der Staat zu, eine kurzfristige Verzögerung für den beschleunigten Erhalt eines Diploms zu gewähren, indem das Diplomdesign durch eine Prüfung in allen Fächern ersetzt wurde. Er verließ die Armee am 1. März 1994 als zertifizierter Funktechniker.

In den Streitkräften gab es zu dieser Zeit einen beispiellosen Zustrom der gleichen Spezialisten der mittleren technischen Ebene, obwohl dies das Wehrpflichtsystem im Herbst-Frühling in den Köpfen der „Großväter“, die bereits eine deutliche Abstufung der Namen hatten, leicht ruinierte, nannten sie diesen nicht standardmäßigen Ruf „Kobold“. Unter den "boomenden" gab es genug Leute, die ZX-Spectrum mochten und Alexander Gumin war in meiner Einheit (er schrieb Spiele auf dem ZX-Spectrum unter dem ANCCAN-Label mit Denis Markelov und wurde 1997 für seine Adaption von Mortal Kombat für diese Plattform bekannt). wen man über Programmierung und Hardware spricht.

Kurz vor Mitte April 1994, am Ende des "Kurses für junge Kämpfer", wurden Alexander und ich in das Baubataillon in Strelna, einem Vorort von St. Petersburg, versetzt. Dort mussten wir einige Monate lang die schwierige Spezialität des Kabelspleißers beherrschen. Das Leben in diesem Teil verlief gemächlich und das Lernen wechselte sich mit Outfits ab, die meistens die Hände belasteten, dem Gehirn aber Zeit zum Nachdenken gaben. In einem der Outfits in der Küche, auf meinem Boden und beim Nachdenken über das ZX-Spectrum und seine Fähigkeiten kam mir die Idee, wie man den "Konflikt der Attribute" überwinden kann.

Ich dachte bis zum Ende des Gottesdienstes über diese Idee nach und war immer mehr davon überzeugt, dass "es funktionieren könnte". Leider besuchte mich die Idee der Realisierbarkeit der Plattform selbst, auf die ich diese Idee anwenden wollte, weniger oft. In Russland blitzte das ZX-Spektrum jedoch von etwa 1991 bis 1996 am lebhaftesten am Himmel auf. Einige russische Produzenten ihrer Klone sind so stark gestiegen, dass sie Programme im Fernsehen gesponsert haben (zum Beispiel hat das Unternehmen BiM die Sendung „The Jungle's Name“ seit einiger Zeit gesponsert). Aber während des Dienstes gab es andere Probleme, so dass ich mich entschied, alle Fragen im Zusammenhang mit dem Handel zu verschieben, bis ich in die Reserve geschickt wurde. In regelmäßigen Abständen und ohne Einzelheiten preiszugeben, interessierte ich mich für verschiedene Experten zum Thema technische Machbarkeit und Gültigkeit des Ansatzes. Er hielt die Idee geheim und teilte sie nicht einmal mit Alexander Gumin, was ihm nur vage anzeigte, dass er eine sehr einfache Lösung gefunden hatte, um die Anzahl der Farben zu erhöhen und gleichzeitig die Abwärtskompatibilität aufrechtzuerhalten.

Nachdem ich 1997 in den „Bürger“ eingetreten war und eine Stelle als Softwareentwickler der zweiten Kategorie bei der St. Petersburger Firma „Information Technologies and Models“ bekommen hatte, begann ich mich ein wenig für die Frage der Kommerzialisierung der Lösung zu interessieren. Aus irgendeinem Grund war ich mir sicher, dass, wenn ich nur auf die Lösung hinwies, die ich gefunden hatte, jeder anfangen würde, mit den Händen zu reißen, und das Geld fließen würde. Ich fing an, die damals im Bereich "Spectrum-Building" bekannten Hersteller und Händler wie Sergey Zonov, Vyacheslav Skutin (Nemo) und andere anzurufen. Sergey Zonov sagte mir einfach, dass „der Zug bereits abgefahren ist“ und dass dieses Unternehmen keinen kommerziellen Sinn mehr hat. Vyacheslav Skutin, ein orthodoxer Spektrumist, war feindselig gegenüber jeder Idee, bei der er versuchte, etwas auf der Plattform zu ändern, und dies war auch eine völlig tote Version. Ich entschied, dass wenig geredet wurde und zumindest etwas getan werden musste, und es war am besten, mit einem Emulator zu beginnen, um Werbematerial und experimentelle Daten zu erhalten.

1998 habe ich auf der Grundlage eines der damals in Pascal geschriebenen Open-Source-ZX-Spectrum-Emulatoren einen primitiven Emulator aus vier parallel arbeitenden Computern erstellt. Ich habe das Spiel After The War 2 teilweise dafür angepasst und einige seiner Sprites eingefärbt. Das System funktionierte und ich hatte nicht nur Spaß an der Arbeitsidee, sondern auch Screenshots, die die Idee bestätigten, vorhandene Spiele zu färben.

1998 besuchte ich die Firma Peters, die zu dieser Zeit ihre neue Sprinter-Plattform entwickelte. Er machte einen Versuch, ihren Regisseur Nikolai Noskov zu interessieren. Sie investierten viel in die neue Entwicklung und nach dem Gesetz der Gemeinheit konnte die superflexible Sprinter-Architektur, die fast jede Einzelprozessorplattform auf dem Z80 emulieren kann, vier Prozessoren nicht erweitern. Ein Besuch in diesem Unternehmen war jedoch sehr nützlich, da er sich mit dem Autor der Sprinter-Plattform Ivan Makarchenko traf und sich über neue Möglichkeiten im Bereich der FPGA-Entwicklung informierte.

Bald „schwand“ die 1998er Krise und es bestand die naive Hoffnung, dass sich das Interesse am ZX-Spectrum wieder beleben könnte. Anfang 1999 hatten wir (mit meinem damaligen Partner Andrei Savichev) sogar Pläne, den „National Spectrum Fund“ zu gründen, und ein Treffen zu diesem Thema fand im neuen Büro des gleichen Peters-Unternehmens statt. Aber sie betreten nicht zweimal denselben Fluss und natürlich ist nichts daraus geworden. Bereits 1999 wurden alle Ideen zum Thema Hardware-Implementierung der Plattform verworfen (wir haben mit Sergey Egorov an dieser Entwicklung gearbeitet, sind aber nicht weiter gegangen als die Pläne). Bis 2007 habe ich mich praktisch nicht mit der Plattform befasst, aber es war Zeit und ich habe beschlossen, den Emulator neu zu schreiben und die Details der Plattform zu erarbeiten, die Ansätze zu überprüfen und sie "virtuell" zu lassen.

Der Standard-Videomodus ZX-Spectrum zeigt 256 x 192 Pixel an. Im Monochrom-Modus sind hierfür nur 6144 Byte erforderlich, was ungefähr 10% des gesamten Speicherfelds entspricht (gegenüber 50% beim BK-0010). Farbinformationen werden in zusätzlichen 768 Bytes gespeichert, die sich unmittelbar nach den Pixeldaten befinden. Die Palette besteht aus acht Farben und zwei Schattierungen. Die Farbe der beleuchteten und verworfenen Pixel wird sofort für den 8 × 8-Pixelblock bestimmt, und der Farbton wird sofort für die Farbe der beleuchteten und verworfenen Pixel bestimmt.

Es sieht farbenfroh aus und eine relativ kleine Datenmenge wird sehr schnell gesendet, erfordert jedoch einen unglaublichen Aufwand und Kunst von Künstlern und Programmierern bei der Entwicklung von Farbspielen und Bildschirmschonern. Die geringste Inkonsistenz im Diagramm führt zu einem Attributkonflikt. Die meisten Entwickler haben ihre Arbeit vor dem Hintergrund des BK-0010 gut gemacht. Mit seinen nur vier Farben (aber für jeden Punkt!) Sah Spectrum quasi-color sehr vorteilhaft und frisch aus.

Beispiel für ein ZX-Spectrum-Attribut

Mit der Entwicklung der Plattform zu ZX-Spectrum 128 wurde die Möglichkeit hinzugefügt, Hardware zwischen zwei Seiten Videospeicher zu wechseln. Programmierer fanden schnell einen Weg, mehrfarbig zu werden, indem sie die angezeigten Videoseiten sehr schnell änderten und die Farbattribute dynamisch änderten.

Aufgrund dessen war es sogar möglich, die Bildschirmauflösung programmgesteuert zu erhöhen (was beispielsweise in der Demo "Dead Morose" perfekt gezeigt wird, in der gleichzeitig Text mit einer Auflösung von 256, 512 und 768 horizontalen Punkten ausgeführt wird).

Alle Softwarelösungen, die eine Erhöhung des Videoinformationsflusses erfordern, führten jedoch zu einer Erhöhung des Prozessorverbrauchs, was bei dynamischen Spielen sehr kritisch ist. Es gab keine ungenutzte Quelle für Rechenleistungsreserven im System. Alles hängt am Prozessor im ZX-Spectrum und gibt ihm eine kleine Entlastung, außer vielleicht dem Musikprozessor im Bereich der Soundeffekte.

Meine Idee war, dass Sie drei weitere Prozessoren hinzufügen könnten, die die Verarbeitung ihrer Farbkomponente auf jeden von ihnen übertragen. Die empfangenen Daten aus dem eigenen Videospeicher jedes Prozessors sollten integriert werden und einen YRGB-Wert für jedes Pixel bilden . Standardfarbattribute werden ignoriert. Die parallele Verarbeitung von Informationen sollte sicherstellen, dass keine Leistungseinbußen auftreten.

Farbschema in ZX-Poly 256x192

Ich kann nicht sagen, dass die Idee originell war, da sie von der Lektüre des Übersetzungsbuchs "The Computer Gains Mind" (Mir Publishing House, 1990) inspiriert wurde, in dem eine bestimmte in Lucasfilm entwickelte Pixar-Grafikplattform beschrieben wurde. Und laut TRIZ ist es nur ein Übergang von einem Monosystem zu einem Polysystem.

Abschnitt der Seite aus dem Buch "The Computer Gains Mind"

Eine sehr schmerzhafte Frage für jede Entwicklung - und wer wird das Programm schreiben? (Insbesondere die Sprinter- Plattform stieß auf diese "Falle"). In meinem Fall wurde das Problem mit der Software automatisch dadurch behoben, dass sehr selten vorhandene Programme überprüften, welche Art von Daten sie im Videospeicher aufzeichneten, und einfach mit ihnen „wie ein Postbote mit einem versiegelten Brief“ arbeiteten. Nach meinen Berechnungen stellte sich heraus, dass die meisten vorhandenen Spieleprogramme die Anpassung ihrer Videodaten ohne Änderungen im ausführbaren Code problemlos überstehen konnten. Natürlich wurden Spiele mit einem Paket von Grafiken oder internen Optimierungen in der Ausgabe auf dem Bildschirm abgeschnitten. Die Anpassung solcher Programme würde die Erforschung und Änderung des ausführbaren Codes erfordern. Die Entwicklung spezialisierter ROMs war überhaupt nicht erforderlich.

Ich denke, dass dieses Konzept auf jede alte Haushaltsplattform (z. B. AGAT, Radio86RK, BK-0010 usw.) anwendbar ist, bei der es keinen dedizierten Videobeschleuniger gibt und der Prozessor direkt mit dem Videospeicher arbeitet, um ein Bild zu erstellen.

In der ersten Version des Emulators habe ich gerade vier ZX-Spectrum 48s synchron arbeiten lassen. Was auf dem Emulator jedoch einfach zu simulieren ist, lässt sich auf echter Hardware nur sehr schwer wiederholen. Es ist ziemlich schwierig, das Laden von Daten in vier Computermodule sicherzustellen und einen synchronen Start von derselben Adresse aus durchzuführen. Eine ähnliche Lösung, Spec256 , wird für diese spezialisierte virtuelle 64-Bit- SIMD Z80 eingeführt, die es in der Natur nicht gibt. Als Teil einer realistischeren (und komplexeren) Lösung für dieses Problem wurde die ZX-Poly-Plattform gebildet.

Vom „Color Extender“ zum ZX-Poly

Prozessormodule

ZX-Poly ist eine Computerplattform, die auf dem ZX-Spectrum 128 basiert und vier Prozessormodule enthält. Jedes Modul verfügt über eigene extern sichtbare adressierbare System-E / A-Ports. Obwohl die Prozessormodule die Systemsteuersignale (RESET, NMI, CLK und INT) gemeinsam nutzen, arbeiten sie unabhängig voneinander.

Blockdiagramm

Abhängig vom Index des Moduls gibt es eine bestimmte Rangfolge - je kleiner der Index, desto höher der Rang, "Modul 0" ist Master im System. Der Schreibzugriff auf die Systemports des Moduls ist nur für Module mit demselben oder einem höheren Rang zulässig. Es gibt keine Leseeinschränkungen. Dies geschah, weil über die Entwicklung eines speziellen Betriebssystems nachgedacht wurde.

Rangfolge der Module

Ein sehr wichtiges Detail ist, dass alle verwendeten Prozessorgeräte vom selben Hersteller sein müssen (und es wäre schön, eine Produktionsserie zu haben), da der geringste Unterschied in ihrer internen Organisation oder Optimierung die Konsistenz des Systems verletzen kann.

Unmittelbar nach dem Start des Systems wird nur das Master-Modul (CPU0) gestartet, die restlichen Module befinden sich im WAIT-Modus, sodass für den Benutzer alles unbemerkt bleibt.

Im E / A-Bereich fügt ZX-Poly die folgenden Ports zum Schreiben und Lesen hinzu:

Hauptkonfigurationsport $ 3D00
Modul 0 - $ 00FF, $ 10FF, $ 20FF, $ 30FF
Modul 1 - $ 01FF, $ 11FF, $ 21FF, $ 31FF
Modul 2 - $ 02FF, $ 12FF, $ 22FF, $ 32FF
Modul 3 - $ 03FF, $ 13FF, $ 23FF, $ 33FF

Der Hauptkonfigurationsport für ZX-Poly ist $ 3D00. Nur das Master-Modul kann darauf schreiben, es steht jedoch allen Modulen zum Lesen zur Verfügung, und jede seiner eigenen speziellen Informationen wird zurückgegeben. Insbesondere kann ein Modul seinen Index herausfinden, ob sein Speicher den E / A-Ports des Hauptmoduls zugeordnet ist, den Versatz seines Speichers im Heap usw. Auch der Konfigurationsport der Basisplattform $ 7FFD wurde geringfügig geändert, wobei im Original nicht verwendete Bits verwendet werden.

Die Erinnerung

Wie in der ursprünglichen Architektur des ZX-Spectrum 128 gibt es ROM und RAM. Wenn sich die Organisation und die Arbeit mit dem ROM praktisch nicht geändert haben, hat sich der RAM in einen gemeinsamen „Heap“ von 512 KB verwandelt, in dem jeder Prozessor mit einem dedizierten 128-KB-Fenster arbeitet (dies sind 8 Seiten mit 16 KB im ZX-Spectrum 128). Der Fensterversatz kann in Schritten von 64 KB geändert werden, und alle Prozessormodule können so projiziert werden, dass sie mit einem vollständig oder teilweise überlappenden Speicherelement im Heap arbeiten. Das ROM kann deaktiviert werden und die RAM0-RAM-Seite wird an ihrer Stelle verbunden (dies ermöglicht es Ihnen, eine "Vollfarben" -Version des Basisbetriebssystems zu erstellen, z. B. einen Basisinterpreter). Nach einem Hardware-RESET erhalten alle Module automatische Offsets, um Speicherfenster im Heap zu trennen.

Der Prozessormodul-Master (CPU0) kann die Adressräume anderer Module (CPU1-3) auf den Bereich seiner E / A-Ports abbilden. Das heißt, Er kann auf den Port schreiben, den Status der Speicherzelle eines bestimmten Moduls ändern und gleichzeitig ein NMI-Signal auf einem zugeordneten Modul erzeugen. Beim Lesen aus Speicherzellen eines zugeordneten Moduls ist eine INT-Generierung möglich. Dies wurde durchgeführt, um virtuelle Geräte mit den Modulen 1-3 zu emulieren.

Videocontroller

Die Hauptkirsche ist natürlich ein Videocontroller, alles wurde dafür gestartet. Insgesamt unterstützt die Plattform fünf Videomodi.

ZX-Spectrum 128-Videomodi (Modus 0,1,2,3)

Diese Videomodi sind unauffällig und unterscheiden sich überhaupt nicht vom Standard-Videomodus ZX-Spectrum 128. Die aktuelle Videoseite des ausgewählten Prozessormoduls mit Attributfarbe wird angezeigt. Unmittelbar nach dem Start des Systems wird der Modus 0 aktiviert, d.h. Die Videoseite des Master-Moduls (CPU0) wird angezeigt.

ATW2 im Standard-ZX-Modus

ZX-Poly 256x192 (Modus 4)

Dieser Videomodus verwendet überhaupt keine Daten aus dem Attributbereich. Das Pixelbit jedes Moduls wird mit Pixeldaten von anderen Modulen kombiniert und die erzeugten vier Bits werden verwendet, um ein YRGB-Signal mit Farbhelligkeit zu erzeugen.

Jedes Modul ist für seine Komponente verantwortlich:

Modul 0 (Master) für Grün (grün).
Modul 1 für Rot (rot)
Modul 2 für Blau (blau)
Modul 3 für Helligkeit

kolorierte Version

Wenn Sie in diesem Modus ein nicht angepasstes Spiel starten, ist es einfach schwarzweiß.

ZX-Poly 256x192 mit Maskierung durch INK + PAPER (Modus 6)

Wie beim vorherigen bietet es 16 Farben für jeden Punkt, aber es gibt einen „Trick“. In einigen ZX-Spectrum-Programmen werden grafische Elemente mit den identischen INK- und PAPER-Werten in den Attributen ausgeblendet, insbesondere in Scroller-Spielen. Wenn Sie diese Möglichkeit entfernen, sammeln sich die grafischen Elemente auf dem Bildschirm an und brechen das Bild. Daher wird der Status von INK und PAPER anhand des Attributs des aus dem Videospeicher (CPU0) gelesenen Mastermoduls analysiert. Wenn sie identisch sind, werden alle Punkte mit der Farbe aus INK / PAPER hervorgehoben (natürlich unter Berücksichtigung der Helligkeit).

ZX-Poly 256x192 mit Maskierung durch FLASH + INK + PAPER (Modus 7)

Modus ist eine Kombination aus Modus 4 und Modus 6. Für die lesbaren Attribute des Master-Moduls (CPU0) wird das FLASH-Bit analysiert und wenn es gesetzt ist (was bei dynamischen Spielen auf dem Spielfeld selten ist), wird im Modus 6-Modus ein 8 x 8-Pixel-Block ausgegeben ( mit Maskierung mit identischer TINTE und PAPIER). Wenn FLASH zurückgesetzt wird, wird der Block wie bei einem normalen ZX-Spectrum angezeigt. Das FLASH-Bit wird nicht in seiner direkten Rolle geübt und es wird nicht geblinkt.
Dieser Modus ist sehr praktisch, um zu vermeiden, dass Spielinformationsfelder und einige Effekte im Spiel neu gestrichen werden (z. B. wenn Spieleentwickler durch Attribute auf dem Spielfeld blinken).

Animierter angepasster fliegender Hai

ZX-Poly 512x384 mit Attributen (Modus 5)

Attribute werden fast wie auf der ursprünglichen Plattform verwendet, ohne Änderungen (sogar das FLASH-Bit). Die Videopixeldaten jedes Moduls werden mit einem Attribut aus dem Videospeicher dieses Moduls eingefärbt und nach Durchlaufen der Färbung in einem Schachbrettmuster angezeigt, wodurch ein Vertrautheitsblock 16 mal 16 Punkte beträgt.

Schachbildung

In diesem Modus können Sie die Auflösung von Anwendungen verdoppeln, ohne den ausführbaren Code zu ändern. Experimente mit demselben Spiel „Pinocchio“ haben zwar gezeigt, dass bei hellen Spielen mit großen Details der Effekt kaum spürbar ist. Da es sich um virtuelle Pixel handelt, wissen die Spiele nichts darüber und die minimal mögliche Bewegung von Spielelementen liegt auf der Ebene von zwei virtuellen Pixeln. Ich denke, dass dieser Modus gut für Spiele mit kleinen Spielobjekten an einem vertrauten Ort ist.

Beispiel des Spiels "Pinocchio"

Ein viel besserer Effekt in diesem Videomodus wurde bei Textanwendungen erzielt, beispielsweise im ZX-Word-Texteditor, bei dem die Schriftart ohne Änderungen im ausführbaren Code verarbeitet wurde.

angepasstes ZX-Word

Multitasking

Trotz der Tatsache, dass die Prozessoren im System dieselbe Quelle von Steuersignalen verwenden, arbeiten sie unabhängig voneinander. Das System kann nicht als vollwertige SIMD bezeichnet werden , da jeder Prozessor Befehle aus seinem eigenen Speicherblock verarbeitet und einfach die Möglichkeit nutzt, dieselben Befehle "abzustreifen". , " " — .