Une proposition pour une ULA 2(1/2)
Par Fabrice Francès

Qui n'a pas souhaité des caractéristiques vidéos plus étendues pour son Oric ? Quel joueur ou graphiste n'a jamais trouvé les contraintes de proximité de couleurs trop sévères ? Et quel Oricien désirant faire une utilisation bureautique ou de gestion de sa machine n'a jamais rêvé de 80 colonnes de texte ?
A chaque fois, le même coupable a été désigné: l'ULA de l'Oric. Pourtant, deux raisons ont toujours freiné les ardeurs des pros du hard qui voulaient la peau de cette ULA.
D'abord, sans elle l'Oric ne serait plus l'Oric : supprimez le système d'attributs vidéo série, et toute la bibliothèque des jeux Oric est bonne pour la poubelle; bien sûr cela faciliterait le portage de programmes existants sur d'autres machines (C64, Apple2, etc), mais alors cela veut dire que vous repartez depuis zéro.
Et puis ensuite, l'ULA est tellement centrale au fonctionnement de l'Oric que la supprimer obligerait à redessiner complètement la carte mère Oric (ce qui encore une fois aboutirait à une machine qui aurait pas grand chose à voir avec la famille Oric), c'est pourquoi toutes les tentatives d'extensions graphiques ont bien évité de suivre cette voie : elles se contentent de récupérer quelques signaux provenant de l'ULA et proposent donc des traitements postérieurs à la génération de l'image vidéo par l'ULA, donc pas de modes graphiques étendus (la carte palette de couleurs parue dans Micr'Oric récupère par exemple les signaux RVB qui sortent de l'ULA en TTL pour les remplacer par des niveaux analogiques)

Il faut donc remplacer l'ULA pour avoir accès à de nouveaux modes graphiques , mais bien sûr personne ne veut perdre la compatibilité avec l'ancienne ULA. Une autre possibilité, ce serait d'avoir un deuxième générateur vidéo complètement externe à l'Oric, avec sa propre mémoire écran, mais je trouve la première solution plus élégante. Ce que je propose donc, c'est un remplacement Plug&Play de l'ULA par un circuit compatible de manière ascendante (une ULA 2). Les avantages, ce sont : pas de modification de la carte mère Oric, il suffit de retirer l'ULA de son support et d'enficher à la place le nouveau circuit (on pourra donc toujours revenir à la configuration initiale si on le souhaite); une parfaite compatibilité avec les programmes existants, les nouveaux modes graphiques ne seront activés que par de nouvelles applications qui en ont la connaissance; pas de double génération vidéo, donc pas besoin de deux moniteurs (ou d'interrupteur à basculer); et pas de deuxième boitier pour l'extension vidéo (l'oric garde son aspect extérieur). La limitation de cette approche, c'est l'impossibilité de proposer des modes graphiques trop différents de ceux de l'Oric, parce que l'ULA2 doit garder les mêmes broches que l'ULA d'origine, donc elle recevra toujours l'horloge à 12 MHz et devra toujours générer 4 signaux R,V,B,SYNC en TTL (soit 8 couleurs). Malgré tout, j'espère que vous admettrez que les modes proposés sont une véritable avancée pour l'Oric...

Toute cette proposition est basée sur une simple constatation : les attributs série de synchronisation de l'ULA laissent un bit inutilisé : en effet, ces attributs (18 à 1F en hexadécimal) utilisent le bit 1 pour déterminer si la fréquence de rafraichissement est 50 ou 60 Hz et le bit 2 pour indiquer le mode Texte ou le mode Hires, mais le bit 0 n'est pas utilisé. En le récupérant pour notre usage, nous pouvons donc avoir les attributs de synchronisation suivants:

18: 60 Hz, TEXT 40 colonnes
19: 60 Hz, TEXT 80 colonnes
1A: 50 Hz, TEXT 40 colonnes
1B: 50 Hz, Mode ARCADE
1C: 60 Hz, Hires
1D: 60 Hz, Hires 2
1E: 50 Hz, Hires
1F: 50 Hz, Hires 2

donc, un nouveau mode Hires 2 pour les graphistes, un mode Texte 80 colonnes pour les travailleurs (utilisation type bureautique avec un moniteur à 60 Hz), et un mode Arcade pour les joueurs.

Quelques rappels sur le fonctionnement de l'ULA

Grâce à l'étude détaillée de l'ULA faite par Mike Brown, on sait maintenant que le générateur vidéo de l'ULA génère un signal d'horloge disymétrique, ce qui lui permet d'exploiter doublement une caractéristique intéressante du 6502 qui est que le bus n'est utilisé que pendant une demi-période de l'horloge. Donc, à partir de l'horloge à 12 MHz de l'Oric, l'ULA fabrique une horloge à 1 MHz qui est composé d'une demi-période équivalente à 8 cycles de l'horloge 12 MHz et d'une demi-période équivalente à 4 cycles. Pendant les 4 cycles de la seconde demi-période, c'est le 6502 qui utilise le bus mémoire; pendant les 8 cycles de la première demi-période, l'ULA peut accéder deux fois à la mémoire afin de générer l'image vidéo. En effet, lorsque l'ULA est en mode Texte, il lui faut d'abord lire un octet de la mémoire vidéo, puis un octet de générateur de caractère. Par ailleurs, le signal vidéo généré par l'ULA est cadencé à la fréquence de 6 MHz, c'est à dire que les 6 pixels d'un caractère ou d'un octet en haute résolution sont émis de manière régulière durant les 12 cycles internes de l'ULA correspondant à un cycle 6502.

En haute résolution, l'ULA ne fait qu'une lecture de la mémoire vidéo, ce qui lui permet d'obtenir les 6 pixels à émettre. On peut donc mettre à profit la deuxième lecture, pour fabriquer un nouveau mode graphique. Si on lit deux octets au lieu d'un, la première idée qui vient à l'esprit est de doubler la résolution, donc émettre 480 pixels par ligne au lieu de 240, ce qui est réalisable en cadençant les pixels à 12 MHz au lieu de 6 MHz. Mais, de cette façon, on garderait les contraintes du mode Hires d'origine, à savoir l'impossibilité d'avoir plus de deux couleurs par groupe de 6 pixels, ce qui rend les images multicolores très difficiles à réaliser, car il faut introduire des attributs de changement de couleurs et donc on augmente encore la distance entre des points de couleurs différentes. A mon avis, les utilisateurs Oric seraient moins intéressé par une augmentation de la résolution dans ces conditions que par un assouplissement des contraintes de couleurs. Je propose donc de coder chaque pixel par plus de bits, en gardant la résolution de 240 points par ligne. Il faudrait 18 bits pour coder 6 pixels avec 8 couleurs possibles pour chacun d'eux, et on ne lit que 16 bits, donc il va falloir trouver un compromis.

Voici donc la proposition de codage des octets:

b7: inversion vidéo
b6: 0 pour un attribut, 1 pour un pattern de bits
b5,b4: couleur du pixel 1
b3,b2: couleur du pixel 2
b1,b0: couleur du pixel 3

ce qui laisse penser à priori que chaque pixel est codé par 2 bits, mais en fait on est très proche des 3 bits grâce à l'inversion vidéo et à un système de palettes de couleurs. Une palette de couleurs contient 4 couleurs et chacun des 3 pixels d'un même octet peut prendre n'importe laquelle de ces 4 couleurs, ou les 4 couleurs obtenues par inversion vidéo de la palette si le bit 7 est positionné. De façon à minimiser la proximité des couleurs, la palette courante peut être changée globalement par un attribut, donc on retrouve quelque peu les problèmes des attributs séries mais à une échelle moindre parce que seulement trois pixels sont perdus si un attribut est inséré, et parce que ces changements de palettes sont presque inutiles du fait que les 8 couleurs sont accessibles immédiatement; toutefois, ils restent très utiles en début de ligne pour choisir les 4 couleurs qui pourront être obtenues sans avoir recours à l'inversion vidéo.