"Color Extender for ZX-Spectrum" - c'est le titre de l' article publié dans le echo fido7.zx.spectrum le 3 août 1997. L'article décrivait l'idée de résoudre l'un des principaux problèmes de la plate-forme ZX-Spectrum - le conflit d'attributs . La publication a suscité un certain intérêt à ce moment-là, et je voudrais parler des détails techniques et de l'histoire du problème.
Je n'entrerai pas dans les détails techniques et je décrirai simplement structurellement l'idée et la solution.
Partie non technique de l'histoire, vous pouvez sauterL'histoire du développement a commencé au début du printemps 1994, alors que le pays connaissait encore des «changements dans le projet», ce qui a conduit à la fermeture massive des reports et à l'attrait des élèves des écoles professionnelles et des écoles techniques. J'ai eu de la chance - j'étais dans ma dernière année au Leningrad Radiotechnical College et de cette manière, l'État a accepté de donner un délai court pour la réception accélérée d'un diplôme avec le remplacement de la conception du diplôme par un examen dans toutes les matières. Il a quitté l'armée le 1er mars 1994 en tant que technicien radio agréé.
Dans les forces armées à cette époque, il y avait un afflux sans précédent des mêmes spécialistes du niveau technique moyen, bien que cela ait légèrement ruiné le système de conscription automne-printemps dans les têtes des «grands-pères» qui avaient déjà une gradation claire dans les noms, ils ont surnommé cet appel atypique «gobelin». Parmi les «en plein essor», il y avait suffisamment de gens qui aimaient ZX-Spectrum et Alexander Gumin était dans mon unité (il a écrit des jeux sur le ZX-Spectrum sous le label ANCCAN avec Denis Markelov et est devenu connu pour son adaptation de Mortal Kombat pour cette plateforme en 1997), qui parler de programmation et de matériel.
Vers la mi-avril 1994, à la fin du «cours du jeune combattant», Alexander et moi avons été transférés au bataillon de construction situé à Strelna, dans la banlieue de Saint-Pétersbourg. Là, nous avons dû maîtriser la spécialité difficile du câble-épisseur pendant plusieurs mois. La vie dans cette partie coulait tranquillement et l'étude alternait avec des tenues, qui tendaient principalement les mains, mais donnaient au cerveau le temps de réfléchir. Donc, dans l'une des tenues de la cuisine, mon étage et en pensant au ZX-Spectrum et à ses capacités, j'ai eu l'idée - comment surmonter le «conflit d'attributs».
J'ai réfléchi à cette idée jusqu'à la fin du service et suis devenu de plus en plus convaincu que «ça pouvait marcher». Malheureusement, l'idée de la viabilité de la plateforme elle-même, à laquelle j'allais appliquer cette idée, m'a moins visité. Cependant, en Russie, le ZX-Spectrum a clignoté le plus vivement dans le ciel d'environ 1991 à 1996. Certains producteurs russes de ses clones ont tellement augmenté qu'ils ont parrainé des programmes à la télévision (par exemple, la société BiM a parrainé le programme «The Jungle's Name» pendant un certain temps). Mais pendant le service, il y avait d'autres problèmes, j'ai donc décidé de reporter tous les problèmes liés au commerce jusqu'à ce que je sois envoyé à la réserve. Périodiquement et sans révéler de détails, j'ai été intéressé par différents experts sur le thème de la faisabilité technique et de la validité de l'approche. Il a gardé l'idée profondément secrète et ne l'a même pas partagée avec Alexander Gumin, lui indiquant seulement vaguement qu'il avait trouvé une solution très simple pour augmenter le nombre de couleurs tout en conservant la compatibilité descendante.
Entré dans le «citoyen» en 1997 et obtenu un emploi d'ingénieur logiciel de deuxième catégorie au sein de la société de Saint-Pétersbourg «Technologies de l'information et modèles», j'ai commencé à m'intéresser un peu à la question de la commercialisation de la solution. Pour une raison quelconque, j'étais sûr que si je faisais juste allusion à la solution que j'avais trouvée, tout le monde commencerait à se déchirer avec les mains et l'argent coulerait. J'ai commencé à téléphoner aux plus connus, à l'époque dans le domaine des fabricants et des marchands de "Spectrum Engineering", comme Sergey Zonov, Vyacheslav Skutin (Nemo) et d'autres. Sergey Zonov m'a simplement dit que «le train est déjà parti» et il n'y a plus de sens commercial dans cette entreprise. Vyacheslav Skutin, étant un spektrumist orthodoxe, a pris l'hostilité avec toute idée dans laquelle ils ont essayé de changer quelque chose dans la plate-forme et c'était aussi une version complètement morte. J'ai décidé qu'il y avait peu de discussions et qu'au moins quelque chose devait être fait et il était préférable de commencer avec un émulateur afin d'obtenir du matériel promotionnel et des données expérimentales.
En 1998, en prenant comme base l'un des émulateurs open source ZX-Spectrum de l'époque écrits en Pascal, j'ai réalisé un émulateur primitif de quatre ordinateurs fonctionnant en parallèle. J'ai partiellement adapté le jeu After The War 2 pour cela, en coloriant certains de ses sprites. Le système a fonctionné et, en plus d'apprécier l'idée de travail, j'ai eu à ma disposition des captures d'écran confirmant l'idée de colorier les jeux existants.
En 1998, j'ai visité la société Peters, qui développait alors sa nouvelle plateforme Sprinter. Il a tenté d'intéresser leur réalisateur Nikolai Noskov. Ils ont investi massivement dans le nouveau développement et, selon la loi de la méchanceté, l'architecture super flexible du Sprinter, capable d'émuler presque n'importe quelle plate-forme à processeur unique sur le Z80, ne pouvait pas étendre quatre processeurs. Cependant, une visite dans cette entreprise a été très utile, car il a rencontré l'auteur de la plateforme Sprinter Ivan Makarchenko et a découvert de nouvelles opportunités dans le domaine du développement FPGA.
Bientôt, la crise de 1998 a «flétri» et il y avait un espoir naïf que l'intérêt pour le ZX-Spectrum pourrait renaître. Au début de 1999, nous (avec mon partenaire de l'époque, Andrei Savichev) avions même l'intention de créer le «National Spectrum Fund» et une réunion a eu lieu sur ce sujet dans les nouveaux bureaux de la même société Peters. Mais ils ne pénètrent pas deux fois dans la même rivière et, bien sûr, rien n'en est sorti. Déjà en 1999, toutes les idées sur le thème de l'implémentation matérielle de la plateforme étaient écartées (nous avons travaillé sur ce développement avec Sergey Egorov, mais nous ne sommes pas allés plus loin que les schémas). Jusqu'en 2007, je ne m'occupais pratiquement pas de la plateforme, mais il y avait du temps et j'ai décidé de réécrire l'émulateur et de travailler sur les détails de la plateforme, en vérifiant les approches et en les laissant "virtuellement".
Le mode vidéo standard ZX-Spectrum affiche 256 x 192 pixels. En mode monochrome, cela ne nécessite que 6144 octets, soit environ 10% du champ mémoire total (contre 50% sur le BK-0010). Les informations sur les couleurs sont stockées dans 768 octets supplémentaires situés immédiatement après les données de pixels. La palette se compose de huit couleurs et de deux nuances. La couleur des pixels éclairés et jetés est déterminée immédiatement pour le bloc de 8 x 8 pixels, et la teinte est déterminée immédiatement pour la couleur des pixels éclairés et jetés.
Il a l'air coloré et une quantité relativement faible de données est envoyée très rapidement, mais cela nécessite des efforts et un art incroyables de la part des artistes et des programmeurs lors du développement de jeux de couleurs et d'économiseurs d'écran. La moindre incohérence dans le graphique entraîne un conflit d'attributs. La plupart des développeurs ont bien fait leur travail dans le contexte du BK-0010, avec ses quatre seules couleurs (mais pour chaque point!), La quasi-couleur Spectrum semblait très avantageuse et fraîche.
Avec le développement de la plate-forme vers ZX-Spectrum 128, la possibilité de basculer le matériel entre deux pages de mémoire vidéo a été ajoutée. Les programmeurs ont rapidement trouvé un moyen d'obtenir plusieurs couleurs en utilisant un changement très rapide des pages vidéo affichées et un changement dynamique des attributs de couleur.
Pour cette raison, il était même possible d'augmenter la résolution de l'écran par programme (ce qui est parfaitement illustré, par exemple, dans la démo "Dead Morose", où en même temps le texte s'exécute avec une résolution de 256, 512 et 768 points horizontalement).
Mais toute solution logicielle nécessitant une augmentation du flux d'informations vidéo a entraîné une augmentation de la consommation du processeur, ce qui est très critique dans le cas des jeux dynamiques. Il n'y avait aucune source inutilisée de réserves de puissance de calcul dans le système. Tout dépend du processeur du ZX-Spectrum et lui donne un peu de décharge, sauf peut-être le processeur de musique dans le domaine des effets sonores.
Mon idée était que vous pourriez ajouter trois processeurs supplémentaires, en jetant sur chacun d'eux le traitement de leur composante couleur. Les données reçues de la mémoire vidéo de chaque processeur doivent être intégrées, formant une valeur YRGB pour chaque pixel . Les attributs de couleur standard sont ignorés. Le traitement parallèle des informations doit garantir l'absence de performances d'affaissement.
Je ne peux pas dire qu'elle était originale dans l'idée, car elle a été inspirée par la lecture du livre de traduction "The Computer Gains Mind" (Mir Publishing House, 1990), qui décrivait une certaine plate-forme graphique Pixar développée dans Lucasfilm. Et selon TRIZ, c'est juste une transition d'un mono-système à un poly-système.
Une question très douloureuse pour tout développement - et qui écrira le programme? (en particulier, la plate-forme Sprinter est tombée sur cet "écueil"). Dans mon cas, le problème avec le logiciel a été automatiquement résolu par le fait que très rarement les programmes existants vérifiaient le type de données qu'ils enregistraient dans la mémoire vidéo et travaillaient simplement avec eux "comme un facteur avec une lettre scellée". Selon mes calculs, il s'est avéré que la plupart des programmes de jeu existants pouvaient assez facilement survivre à l'adaptation de leurs données vidéo sans changements dans le code exécutable. Bien sûr, les jeux avec un ensemble de graphiques ou d'optimisations internes dans sa sortie à l'écran ont été coupés. L'adaptation de tels programmes nécessiterait des recherches et une modification du code exécutable. Le développement de ROM spécialisées n'était pas du tout nécessaire.
Je pense que ce concept est applicable à toute ancienne plate-forme domestique (par exemple, AGAT, Radio86RK, BK-0010, etc.), où il n'y a pas d'accélérateur vidéo dédié et où le processeur travaille directement avec la mémoire vidéo pour former une image.
Dans la première version de l'émulateur, je venais de faire fonctionner quatre synchrones ZX-Spectrum 48. Mais ce qui est facile à simuler sur l'émulateur est très difficile à répéter sur du vrai matériel. Il est assez difficile d'assurer le chargement des données dans quatre modules informatiques et d'effectuer un démarrage synchrone à partir de la même adresse. Une solution similaire Spec256 introduit pour ce SIMD Z80 virtuel 64 bits spécialisé, qui n'existe pas dans la nature. Dans le cadre d'une solution plus réaliste (et plus complexe) à ce problème, la plateforme ZX-Poly a été formée.
De «Color Extender» à ZX-Poly
Modules de processeur
ZX-Poly est une plate-forme informatique basée sur le ZX-Spectrum 128 contenant quatre modules de processeur. Chaque module possède ses propres ports d'E / S système adressables visibles de l'extérieur. Bien que les modules de processeur partagent les signaux de contrôle du système (RESET, NMI, CLK et INT), ils fonctionnent indépendamment.
Il y a un certain classement en fonction de l'indice du module - plus l'indice est petit, plus le rang est respectivement élevé, "module 0" est maître dans le système. L'accès en écriture aux ports système du module n'est autorisé qu'au module de rang identique ou supérieur, il n'y a aucune restriction de lecture. Cela a été fait parce qu'il y avait des idées sur le développement d'un système d'exploitation spécialisé.
Un détail très important est que tous les processeurs utilisés doivent être du même fabricant (et ce serait bien d'avoir une série de production), car la moindre différence dans leur organisation ou optimisation interne peut violer la cohérence du système.
Immédiatement après le démarrage du système, seul le module maître (CPU0) est lancé, les modules restants sont en mode WAIT, donc pour l'utilisateur tout passe inaperçu.
Dans l'espace IO, ZX-Poly ajoute les ports suivants disponibles pour l'écriture et la lecture:
- port de configuration principal $ 3D00
- module 0 - 00FF $, 10FF $, 20FF $, 30FF $
- module 1 - 01FF $, 11FF $, 21FF $, 31FF $
- module 2 - $ 02FF, $ 12FF, $ 22FF, $ 32FF
- module 3 - $ 03FF, $ 13FF, $ 23FF, $ 33FF
Le port de configuration principal ZX-Poly est de $ 3D00. Seul le module maître peut y écrire, mais il est disponible pour lecture dans tous les modules et chacune de ses propres informations spécialisées est retournée. En particulier, un module peut connaître son index, si sa mémoire est mappée aux ports IO du module principal, l'offset de sa mémoire dans le tas, etc. De plus, le port de configuration de la plate-forme de base $ 7FFD a subi des modifications mineures, qui utilisent des bits inutilisés dans l'original.
La mémoire
Comme dans l'architecture originale du ZX-Spectrum 128, il existe des ROM et RAM. Si l'organisation et le travail avec la ROM n'ont pratiquement pas changé, la RAM s'est transformée en un «tas» commun de 512 Ko dans lequel chaque processeur fonctionne avec une fenêtre dédiée de 128 Ko (soit 8 pages de 16 Ko dans le ZX-Spectrum 128). Le décalage de fenêtre peut être modifié par incréments de 64 Ko et tous les modules de processeur peuvent être projetés pour fonctionner avec un morceau de mémoire se chevauchant totalement ou partiellement dans le tas. La ROM peut être désactivée et la page RAM0 RAM sera connectée à sa place (cela vous permet de faire une version "full-color" du système d'exploitation de base, par exemple, un interpréteur de base). Après une réinitialisation matérielle, tous les modules reçoivent des décalages automatiques pour dissocier les fenêtres de mémoire du tas.
Le module maître processeur (CPU0), a la capacité de mapper les espaces d'adressage des autres modules (CPU1-3) dans la zone de ses ports IO. C'est-à-dire il peut écrire sur le port, en changeant l'état de la cellule mémoire d'un module donné, et en même temps, il est possible de générer un signal NMI sur un module mappé. Lors de la lecture à partir des cellules de mémoire d'un module mappé, la génération INT est possible. Cela a été fait pour émuler des périphériques virtuels à l'aide des modules 1-3.
Contrôleur vidéo
La «cerise» principale est bien sûr un contrôleur vidéo, tout a été démarré pour cela. Au total, la plateforme prend en charge cinq modes vidéo.
Modes vidéo ZX-Spectrum 128 (mode 0,1,2,3)
Ces modes vidéo sont sans particularité et ne diffèrent pas du tout du mode vidéo standard ZX-Spectrum 128. La page vidéo actuelle du module de processeur sélectionné avec la coloration d'attribut s'affiche. Immédiatement après le démarrage du système, le mode 0 est activé, c'est-à-dire La page vidéo du module maître (CPU0) s'affiche.
ZX-Poly 256x192 (mode 4)
Ce mode vidéo n'utilise aucune donnée de la zone d'attribut. Le bit de pixel de chaque module est combiné avec les données de pixel des autres modules et les quatre bits générés sont utilisés pour générer un signal YRGB de luminosité de couleur.
Chaque module est responsable de sa composante:
- module 0 (maître) pour Vert (vert).
- module 1 pour Rouge (rouge)
- module 2 pour Blue (bleu)
- module 3 pour la luminosité
Si vous démarrez une partie non adaptée dans ce mode, elle sera simplement en noir et blanc.
ZX-Poly 256x192 avec masquage par ENCRE + PAPIER (mode 6)
Comme le précédent, il fournit 16 couleurs pour chaque point, mais il y a un «truc». Dans certains programmes ZX-Spectrum, les éléments graphiques sont masqués en utilisant les mêmes valeurs ENCRE et PAPIER dans les attributs, en particulier dans les jeux à défilement. Si vous supprimez cette opportunité, les éléments graphiques commencent à s'accumuler à l'écran, brisant l'image. Par conséquent, l'état de l'encre et du papier est analysé à partir de l'attribut du module maître lu dans la mémoire vidéo (CPU0) et s'ils sont identiques, tous les points sont mis en surbrillance avec la couleur tirée de l'encre / du papier (bien sûr, en tenant compte de la luminosité).
ZX-Poly 256x192 avec masquage par FLASH + ENCRE + PAPIER (mode 7)
Le mode est une combinaison du mode 4 et du mode 6. Pour les attributs lisibles du module maître (CPU0), le bit FLASH est analysé et s'il est défini (ce qui est rare dans les jeux dynamiques sur le terrain), le bloc de 8 x 8 pixels est affiché en mode 6 ( avec masquage avec ENCRE et PAPIER identiques). Si FLASH est réinitialisé, le bloc s'affiche comme sur un ZX-Spectrum normal. Le bit FLASH n'est pas pratiqué dans son rôle direct et il n'y aura pas de clignotement.
Ce mode est très pratique pour éviter de repeindre les panneaux d'informations du jeu et certains effets dans le jeu (par exemple, lorsque les développeurs de jeux clignotent sur le terrain de jeu via des attributs).
ZX-Poly 512x384 avec attributs (mode 5)
Les attributs sont utilisés presque de la même manière que dans la plate-forme d'origine, sans aucune modification (même le bit FLASH). Les données de pixels vidéo de chaque module sont colorées avec un attribut de la mémoire vidéo de ce module et, après avoir traversé la coloration, sont affichées en damier, grâce à quoi un bloc de familiarité est de 16 par 16 points.
Ce mode vous permet de doubler la résolution des applications, sans changer le code exécutable. Certes, les expériences avec le même jeu «Pinocchio» ont montré que dans les jeux brillants avec de grands détails, l'effet sera mal perceptible. Puisqu'il s'agit en quelque sorte de pixels virtuels, les jeux n'en savent rien et le mouvement minimum possible des éléments du jeu se situe au niveau de deux pixels virtuels. Je pense que ce mode est bon pour les jeux avec de petits objets de jeu dans un endroit familier.
Un effet bien meilleur dans ce mode vidéo a été obtenu sur les applications de texte, par exemple, sur l'éditeur de texte ZX-Word, où la police a été traitée sans modification du code exécutable.
Multitâche
Malgré le fait que les processeurs du système utilisent la même source de signaux de commande, ils fonctionnent indépendamment. Le système ne peut pas être appelé SIMD à part entière, car chaque processeur traite les instructions à partir de son propre bloc de mémoire, il profite simplement de la possibilité de "supprimer" les mêmes instructions. , " " — .
, , "". , .
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
Si les jeux n'utilisent aucun paquet de sprites, la coloration est assez simple. Des précautions doivent être prises lorsqu'il y a des optimisations dans le code exécutable pour la sortie des sprites, car cela peut conduire à la désynchronisation des modules de processeur.
Un chargeur de démarrage a été développé pour charger des données dans des modules à partir d'un disque et démarrer simultanément simultanément. Son code pour TAP et TR-DOS est présenté dans le projet.
Avec l'émulateur, un petit utilitaire (également écrit en Java) pour les applications de coloration a été développé.
L'ensemble du projet est publié sur GitHub sous la licence GNU GPLv3 .
