Obligement - L'Amiga au maximum

Mardi 19 mars 2024 - 06:31  

Translate

En De Nl Nl
Es Pt It Nl


Rubriques

Actualité (récente)
Actualité (archive)
Comparatifs
Dossiers
Entrevues
Matériel (tests)
Matériel (bidouilles)
Points de vue
En pratique
Programmation
Reportages
Quizz
Tests de jeux
Tests de logiciels
Tests de compilations
Trucs et astuces
Articles divers

Articles in english


Réseaux sociaux

Suivez-nous sur X




Liste des jeux Amiga

0, A, B, C, D, E, F,
G, H, I, J, K, L, M,
N, O, P, Q, R, S, T,
U, V, W, X, Y, Z,
ALL


Trucs et astuces

0, A, B, C, D, E, F,
G, H, I, J, K, L, M,
N, O, P, Q, R, S, T,
U, V, W, X, Y, Z


Glossaire

0, A, B, C, D, E, F,
G, H, I, J, K, L, M,
N, O, P, Q, R, S, T,
U, V, W, X, Y, Z


Galeries

Menu des galeries

BD d'Amiga Spécial
Caricatures Dudai
Caricatures Jet d'ail
Diagrammes de Jay Miner
Images insolites
Fin de jeux (de A à E)
Fin de Jeux (de F à O)
Fin de jeux (de P à Z)
Galerie de Mike Dafunk
Logos d'Obligement
Pubs pour matériels
Systèmes d'exploitation
Trombinoscope Alchimie 7
Vidéos


Téléchargement

Documents
Jeux
Logiciels
Magazines
Divers


Liens

Associations
Jeux
Logiciels
Matériel
Magazines et médias
Pages personnelles
Réparateurs
Revendeurs
Scène démo
Sites de téléchargement
Divers


Partenaires

Annuaire Amiga

Amedia Computer

Relec


A Propos

A propos d'Obligement

A Propos


Contact

David Brunet

Courriel

 


Dossier : AAA (Advanced Amiga Architecture)
(Article écrit par David Brunet - mai 2008, mis à jour en mai 2023)


Le AAA (prononcez "triple A") est un jeu de composants, ou "chipset" en anglais, qui fut en développement dans les laboratoires de Commodore mais qui n'a jamais été terminé. AAA signifie "Advanced Amiga Architecture". C'est une sorte de mythe dans le monde Amiga car à quelques mois près (si Commodore y avait mis les moyens), il aurait pu équiper les Amiga de cette époque.

Historique

Depuis l'introduction de l'Amiga en 1985, il y eut deux principales mises à niveau de son jeu de composants : ECS et AGA (ou AA). L'ECS (Enhanced Chip Set) fut une amélioration mineure des puces Agnus et Denise déjà existantes, alors que l'AGA (Advanced Graphics Architecture), fut une mise à niveau majeure incluant des nouvelles puces comme Lisa qui remplaça totalement Denise. Mais l'AGA resta néanmoins une évolution du jeu de composants d'origine et avait peu de choses de révolutionnaire. L'AGA conserva une grande partie des caractéristiques d'Agnus et disposait de la même Paula, la puce responsable notamment de l'audio et des ports.

AAA signifie "Advanced Amiga Architecture". Les premières discussions sur sa conception, qui fut secrète, remontent à 1988. Mais la première version sur silicium ne fut fabriquée qu'en 1992, car Commodore mit pas mal de temps pour définir son architecture, et à se décider sur son développement. L'AAA fut notamment conçu par Dave Haynie, Edward Hepler et Tim McDonald. L'AAA devait être, à cette époque, le futur jeu de composants de l'Amiga, celui utilisé pour les successeurs des machines haut de gamme de Commodore comme l'Amiga 4000. Les machines d'entrée de gamme, elles, auraient dû être équipées d'un autre jeu de composants, l'AA+, prévu pour être moins cher et basé sur l'AGA.

Mais le projet fut abandonné fin 1993 car, bien que techniquement intéressant, les ingénieurs de Commodore jugèrent qu'il aurait été rattrapé par la technologie PC peu après sa sortie. Un autre système matériel devait alors être mis en place pour garder une longueur d'avance : ce fut Hombre.

Caractéristiques

L'AAA est basé sur quatre nouveaux circuits intégrés VLSI (Very Large Scale Integration - intégration à très grande échelle) qui est une technologie de circuit intégré dont la densité d'intégration permet d'incorporer plus de 100 000 composants électroniques sur une même puce, technique à la pointe à cette époque. Ces quatre puces sont Andrea, Linda, Monica et Mary, nommées avec des prénoms féminins comme avec les précédents jeux de composants.

Chaque aspect de l'ECS et de l'AGA fut amélioré avec l'AAA et une certaine compatibilité devait être présente. L'AAA fut conçu pour être compatible au niveau des registres avec l'ECS. La plupart des registres RGA de l'ECS étaient gérés. Le registre "Ultra Hires" (pour afficher des écrans très larges) fut cependant abandonné car il fut rarement utilisé dans la pratique. De leur côté, les registres de l'AGA n'étaient pas gérés. Les ingénieurs derrière l'AAA le concevaient comme un système de transition, et la compatibilité avec l'ECS aurait été supprimée dans les versions futures des jeux de composants Amiga.

L'AAA devait être flexible et pouvait être dédoublé, permettant ainsi de fonctionner en 64 bits ou de doubler la quantité de mémoire Chip adressable. C'est pour cela que les spécifications de la liste suivante sont différentes dans le cas où l'on parle de système simple ou de système double. Dans un système double, il y a toujours une puce Andrea et une Mary mais deux puces Linda et deux Monica. Contrairement aux autres jeux de composants qui étaient inclus à la fois dans les machines d'entrée et haut de gamme, l'AAA devait donc être entièrement modulaire, ce qui aurait permis de l'adapter suivant les machines voulues : console, ordinateur d'entrée de gamme, ordinateur haut de gamme, etc.

En voici ses principales caractéristiques :

Généralités
  • Bus de données 32/64 bits, fréquence de 57 MHz en système simple et de 114 MHz en système double.
  • Total d'un million de transistors pour la version 64 bits système double (750 000 dans sa version 32 bits).
  • Accès à la mémoire Chip 4,56 fois plus rapide que celui de l'ECS et 1,14 fois celui de l'AGA.
  • Architecture mémoire gérant la VRAM et la DRAM Fast Page.
  • Genlock intégré.
  • Inversion possible de la fréquence de transmission des pixels (pixel clock) permettant de faire de l'acquisition vidéo (uniquement en mode Chunky et avec de la VRAM).
  • Dispose de 256 registres 16 bits (compatibles OCS), 384 registres 32 bits et 512 registres 32 bits CLUT.
  • Promotion des écrans : les systèmes qui pilotent des moniteurs à haute résolution devaient avoir la capacité de promouvoir l'affichage de moniteurs à plus faible résolution.
Andrea : (puce 1200, contrôleur de la mémoire Chip - remplaçante d'Agnus/Alice)

Andrea Andrea

  • Contrôle des accès à la mémoire Chip.
  • Contrôle du bus entre mémoire Chip et processeur. Gestion de différentes fréquences d'horloge du processeur.
  • 40 canaux DMA avec allocation dynamique entre le Blitter et le processeur.
  • Contrôle des fréquences pour le bus Chip et l'affichage.
  • Contrôle des synchronisations vidéo.
  • Intégration du Blitter.
  • Gestion possible de plusieurs puces Blitter.
  • Intégration du Copper.
  • Adressage jusqu'à 16 Mo de mémoire Chip en système double.
  • Affichage jusqu'à 800x560 en 9 bits (DRAM Fast Page avec un système simple).
  • Affichage jusqu'à 800x560 en pixel planaire (bitplan) en 13 bits (VRAM avec un système simple).
  • Affichage jusqu'à 800x560 en pixel hybride en 24 bits (VRAM avec un système simple).
  • Affichage jusqu'à 1280x1024 en 5 bits (DRAM Fast Page avec un système double).
  • Affichage jusqu'à 1280x1024 en pixel planaire en 8 bits (VRAM avec un système double).
  • Affichage jusqu'à 1280x1024 en pixel hybride en 24 bits (VRAM avec un système double).
Blitter : (intégré à Andrea)
  • Le Blitter AAA est bien plus rapide que celui de l'ECS/AGA : déplacement d'un écran 640x200x4 neuf fois plus rapidement que l'ancien Blitter.
  • Opération via adressage de pixels (calcul automatique des premiers et derniers masques, du bon "shift", etc.).
  • Utilisable en mode de pixel planaire et Chunky (en 1, 2, 4, 8 et 16 bits pour ce dernier).
  • Intégration de nouvelles opérations arithmétiques "sort" et "tally" pour épauler l'affichage en mode Chunky.
Copper : (intégré à Andrea)
  • Le Copper a été amélioré dans plusieurs domaines.
  • Il peut opérer en 32 bits pour les nouveaux registres 32 bits.
  • Ajout de la fonction de déplacement multiple ("multiple move") pour pouvoir bouger plus efficacement des registres consécutifs.
  • Capacité d'interruption : le Copper peut recevoir un ordre d'interruption du Blitter, permettant de gérer une série d'opérations sans l'intervention du processeur.
Monica : (puce 1201, générateur d'adresses - remplaçante de Denise)

Monica Monica

  • 256 entrées CLUT de 25 bits chacune (soit 256 couleurs indexées sur une palette de 24 bits plus un bit pour le genlock, comme avec l'AGA).
  • Sprites 128 bits et de n'importe quelle hauteur.
  • Mode double champ de jeu ("Dual Playfield") en 8 bits.
  • La fréquence d'affichage des pixels est indépendante de la fréquence du bus.
  • Nouveau mode de pixel : Chunky, en 16 bits (15 bits, soit 32 768 couleurs, plus 1 bit pour le genlock).
  • Nouveau mode de pixel : Demi-Chunky, en 2, 4 et 8 bits.
  • Nouveau mode de pixel : Hybride, en 24 bits. avec 8 plans Chunky séparés pour chaque composante RGB.
  • Nouveau mode de pixel : PackLUT. 2 bits compactés par pixel, décompactés en 8 bits Demi-Chunky par région de 4x4 pixels.
  • Nouveau mode de pixel : PackHY. 4 bits compactés par pixel, décompactés en 24 bits hybride par région de 4x4 pixels.
  • Nouveaux modes HAM (Hold And Modify) : HAM8 en Chunky (262 144 couleurs) et HAM10 en 24 bits planaire (16 777 216 couleurs).
  • Gestion de plus de moniteurs possibles.
Mary : (puce 1203, contrôleur audio et diverses entrées/sorties - remplaçante de Paula)

Mary

  • Contrôleur audio 8 voies stéréo de 8/16 bits avec échantillonnage jusqu'à 100 kHz.
  • Les voies peuvent être assignées à gauche ou à droite.
  • Contrôleur disque gérant le format brut de 1, 2 et 4 Mo (2,88 Mo au format IBM) et tous les autres formats connus, y compris les disquettes Macintosh.
  • Débit théorique de 11,4 Mbits/s (20 fois plus que Paula).
  • Décodage des formats GCR, MFM, RLL (2,7) et Biphase Mark.
  • Gestion des périphériques comme les CD, les DAT et les radios numériques.
  • Calcul de contrôle d'erreur CRC.
  • Deux UART (émetteur-récepteur asynchrone universel) de 4 bits FIFO pour faire la liaison entre l'ordinateur et le port série.
Linda : (puce 1202, double tampon mémoire)

Linda

  • Double tampon mémoire pour l'affichage des lignes : pendant qu'une ligne est lue par Monica depuis le premier tampon de Linda, la suivante est déjà en train d'être lue dans le second tampon de Linda.
  • Décompression à la volée des modes de pixel PackLUT et PackHY.
  • Intégration de la circuiterie des tampons nécessaires à la gestion du mode capture d'images ("framegrabber").
aaa
Schéma du AAA en système simple/entrée de gamme

aaa
Schéma du AAA en système double/haut de gamme

aaa
Schéma d'une carte mère à base d'AAA

Amélioration des performances

Les performances auraient été améliorées au moins dans quatre secteurs :

Une plus grande largeur de bande du processeur

Dans un système utilisant un écran 640x200 en 2 plans de bits, la bande passante du processeur augmente de 3 à 6 fois les performances de l'ancien processeur de l'Amiga. La bande passante du processeur est multipliée par 4 à 9 lorsque le système utilise quatre plans de bits sur un écran de 640x400x2.

Bande passante graphique plus élevée

Le nouveau système est capable de générer une résolution graphique beaucoup plus élevée que l'ancien système. Une configuration d'entrée de gamme utilisant de la mémoire DRAM en mode page rapide peut générer des affichages allant jusqu'à 800x560 en 9 plans de bits. En utilisant la VRAM, la même configuration peut générer des affichages de 800x560 en 13 plans de bits, ou afficher des pixels hybrides en 800x560 pour fournir 24 bits par pixel, en TrueColor en utilisant les affichages Fast Page. Une configuration haut de gamme peut générer plus d'affichages. En utilisant la mémoire en mode Fast Page, elle peut afficher 1280x1024 en 5 plans de bits. Lorsque la VRAM est utilisée, 8 plans de bits peuvent être affichés en 1280x1024 et les pixels hybrides peuvent être affichés sur des moniteurs 1024x768.

Bande passante du Blitter plus élevée

La vitesse de défilement vertical de l'écran peut être utilisée pour mesurer les performances du Blitter. L'AAA peut faire défiler un écran 640x200 en 2 bits environ six fois plus vite que l'ancien jeu de composants Amiga. Il peut faire défiler un écran de 640x200 en 4 bits et un écran 640x400 en 2 bits environ neuf fois plus vite que l'ancien jeu de composants Amiga.

Des performances de Blitter plus élevées avec des puces de Blitter multiples

L'AAA gère plusieurs puces de Blitter dans une configuration de Blitter par banque mémoire. Dans une telle configuration, il aurait été possible de faire fonctionner toutes les puces Blitter en parallèle, chacune opérant sur une partie des données. Les performances du Blitter sont donc augmentées d'un facteur égal au nombre de puces Blitter dans le système. Par exemple, dans un système à deux puces Blitter, les performances du défilement de l'affichage donné ci-dessus passent de six/neuf fois plus rapides à douze/dix-huit fois plus rapides.



Tableaux des performances

La nouveauté de l'interface de capture d'images (framegrabber)

Étant donné que les mémoires VRAM de 1 Mo gèrent les opérations d'écriture sur le port série ainsi que les opérations de lecture standard, cela peut ouvrir la possibilité d'un nouveau type de matériel genre capture d'images (ou capture vidéo). Cela car l'appareil n'aurait pas besoin de sa propre mémoire tampon (il aurait utilisé la VRAM de la puce AAA, ce qui permet une réduction significative des coûts) et qu'avec l'AAA, chaque champ de données est capturé durant le transfert.

Le bit "DIR" dans BPLCON3 permettait aux puces spécialisées de passer en mode capture d'images et de commencer à capturer des données vidéo générées de l'extérieur. Lorsque ce bit est réinitialisé, les puces passent en mode d'affichage normal et Andrea contrôle la récupération des données vidéo de la mémoire pour l'affichage. Lorsque "DIR" est activé, Andrea commande à Linda de capturer des données sur le bus VDATA (le bus entre Linda et Monica), puis présente ces données sur le bus GDATA pour les écrire dans le port série de la VRAM. Andrea fournit tous les signaux de contrôle nécessaires pour piloter les cycles d'écriture du port série.

Seuls la VRAM, la puce 1200 (Andrea) et la puce 1202 (Linda) sont nécessaires pour gérer le mode capture d'images. Il a ainsi été possible de concevoir un appareil de capture d'images autonome en utilisant ces composants, un simple convertisseur vidéo composite vers RVB et (lorsque la capture de pixels à profondeur de couleur limitée est souhaitée) un simple circuit de multiplexage qui aurait sérialisé les pixels de moins de 24 bits en groupes de 32 bits.

Les nouveaux modes graphiques

Pixels Demi-Chunky

Les pixels Demi-Chunky sont des pixels de 8 bits stockés linéairement et utilisés pour adresser la table de correspondance (LUT) de Monica. Les pixels Demi-Chunky sont transférés de Linda à Monica quatre par quatre. L'octet le plus significatif est affiché en premier. L'alignement des pixels Demi-Chunky dans la mémoire est limité à un double alignement de mots longs (64 bits). Cela simplifiait le circuit d'alignement de Linda et ne pose pas de problèmes de compatibilité puisque les pixels Demi-Chunky sont une nouvelle caractéristique de l'AAA.

Toutes les interactions entre Andrea, Linda et Monica pour le traitement des pixels Demi-Chunky sont essentiellement les mêmes que celles en mode planaire (c'était également le cas pour les pixels Demi-Chunky 2 et 4 bits et les pixels Chunky). Les différences sont les suivantes :
  • Linda écrit puis lit les données du tampon de ligne en utilisant un système d'adressage séquentiel.
  • Andrea ne valide NXTPLANE qu'une fois par ligne de balayage. En effet, toutes les données vidéo nécessaires peuvent être récupérées en rafale (dans le cas de la DRAM FaSt Page, ou déplacées dans Linda dans le cas de la VRAM) à la suite d'un cycle de récupération mémoire RAS-CAS (il existe un cas où une limite de page mémoire est franchie pendant la séquence de récupération, ce qui nécessite deux cycles de récupération RAS-CAS). Andrea tient compte de l'interruption du transfert de données qui peut se produire à la suite du deuxième cycle RAS-CAS en désactivant la broche SCACT (Shift Clock Active) pour les cycles au cours desquels aucune donnée ne doit être enregistrée et traitée par Linda.
  • Le délai que Linda doit traiter entre le moment où (le signal de la broche) DFTCHWIN est validé et le moment où Linda conduit les quatre premiers pixels sur le bus GDATA est différent pour les pixels Demi-Chunky par rapport le délai nécessaire pour transférer les pixels planaire.
Demi-Chunky à quatre bits

Les pixels Demi-Chunky à quatre bits sont similaires aux pixels Demi-Chunky. Il s'agit de pixels de 4 bits stockés linéairement et utilisés pour adresser la table de correspondance de Monica. Les pixels Demi-Chunky à quatre bits sont transférés de Linda à Monica huit par huit. Le nibble (demi-octet) le plus significatif est affiché en premier. L'alignement des pixels Demi-Chunky à quatre bits dans la mémoire est limité à un double alignement de mots longs (64 bits).

Demi-Chunky à deux bits

Les pixels Demi-Chunky à deux bits sont des pixels de deux bits stockés linéairement et utilisés pour adresser la table de correspondance de Monica. Ils sont transférés de Linda à Monica seize à la fois. L'axe des deux bits les plus significatifs est affiché en premier. L'alignement des pixels Demi-Chunky à deux bits dans la mémoire est limité à l'alignement des mots longs (32 bits). Ce mode d'affichage utilise un alignement en mot long, par opposition à l'alignement à deux mots longs utilisé dans les autres modes Demi-Chunky, afin de gérer le défilement avec quatre bits de contrôle de défilement.

Pixels hybrides

Comme leur nom l'indique, ces pixels sont un croisement entre les pixels Chunky et les pixels planaires. Ils permettent l'affichage de pixels de 24 bits. L'approche hybride des pixels de 24 bits permet de surmonter le problème de compactage/décompactage associé aux vrais pixels Chunky de 24 bits. Les pixels hybrides sont stockés sous la forme de trois plans Demi-Chunky, chaque plan décrivant l'une des couleurs rouge, vert et bleu. Linda est chargée d'extraire les couleurs de chacun des trois mots longs de couleur et de les assembler en pixels de 24 bits (les octets les plus significatifs sont extraits et envoyés à Monica en premier). Les pixels sont à leur tour envoyés à Monica, un à la fois, un tous les cycles d'horloge des pixels lorsque le mode d'affichage est en haute résolution, et un tous les deux cycles d'horloge des pixels lorsque le mode d'affichage est en basse résolution, comme spécifié par la ligne de contrôle de sortie CAPEN. Les 24 bits les moins significatifs du bus VDATA contiennent les données du pixel. Les bits 23-16 contiennent les données rouges, les bits 15-8 contiennent les données vertes et les bits 7-0 contiennent les données bleues. Les bits 31-24 doivent être ignorés.

Andrea valide NXTPLANE trois fois lorsque chacun des trois plans de couleurs est extrait de la mémoire pour être stocké dans Linda. Le plan de couleur rouge est récupéré en premier, suivi des plans de couleur vert et bleu. Linda stocke chacun des plans de couleur en utilisant un schéma d'adressage "write one location, skip two" (écrire une adresse, en passer deux). Cette approche simplifie l'assemblage ultérieur des pixels en alternant les emplacements séquentiels des tampons à double mot long avec les données rouges, vertes et bleues. Lorsque Linda envoie une ligne de données de balayage à Monica, elle accède séquentiellement à trois doubles mots longs et stocke temporairement ces données rouges, vertes et bleues dans des registres d'attente au sein du circuit Outmux. À partir de ces registres, Linda assemble huit pixels de 24 bits et les envoie à Monica avec le signal OAPEN habituel.

Pixels compactés

Les pixels compactés forment une image d'écran compressée qui, lorsqu'elle est décompressée et affichée, offre un degré élevé de résolution des couleurs, mais avec une fraction des besoins de stockage. Les données des pixels compactés sont compressées de la manière suivante : l'écran est segmenté en régions de 9x4 pixels. Deux couleurs sont attribuées à chacune de ces régions, ainsi qu'une carte de 16 bits qui définit laquelle des deux couleurs devait être affichée. Lorsqu'un pixel "1" est rencontré, l'une des couleurs du pixel, la couleur 1, est affichée, et lorsqu'un pixel "0" est rencontré, la couleur 0 est sélectionnée et affichée.

La décompression est réalisée en temps réel par Linda. La puce envoie des pixels Demi-Chunky standard ou des pixels hybrides standard vers Monica après décompression. Linda écrit des pixels puis lit des données de tampon de lignes de pixels compressés en utilisant un système d'adressage séquentiel.

Le circuit de collecte des données d'affichage impose des contraintes quant à la position exacte sur l'écran où les lignes de pixels compactées peuvent commencer. La règle est simple : les lignes de pixels compactés (traitées par unités de quatre lignes d'affichage en mode de répétition sur une ligne, par unités de huit lignes en mode de répétition sur deux lignes, etc.) peut démarrer sur la première ligne d'affichage active, telle que définie par le registre DIWSTRT, ou toutes les quatre (huitièmes, etc.) lignes d'affichage physique par la suite. Cela implique bien sûr que le défilement vertical des affichages à pixels compactés n'est possible que par groupes de quatre (huit, etc.) lignes de balayage.

Les pixels PackLUT

Les pixels PackLUT sont décompressés par la puce Linda pour former des pixels Demi-Chunky standard. Les couleurs de chaque région de l'écran sont des valeurs de 8 bits utilisées pour adresser une entrée dans la table de recherche des couleurs de Monica. 32 bits sont nécessaires pour spécifier complètement chaque région de l'écran, ce qui donne un taux de compression des données de 4 par rapport aux pixels Demi-Chunky standard.

Linda effectue la décompression des données dans le circuit Outmux (toutes les données PackLUT sont stockées dans un tampon de ligne, même dans la version haut de gamme de l'AAA, et l'extraction des pixels pairs/impairs, dans le cas de ce système haut de gamme, est effectuée au fur et à mesure de la décompression des données). En raison de l'organisation des pixels compactés (chaque région contenait des informations pour une ligne de balayage séquentielle), chaque tampon mémoire de données est accédée quatre fois. Cela signifie qu'Andrea n'a besoin d'envoyer des données à Linda qu'une fois toutes les quatre lignes de balayage. Andrea peut également profiter du fait qu'il y avait plus de temps disponible et envoyer des données de pixels compactés à Linda au cours de plus d'une ligne de balayage. Cela permet de générer des affichages qui sont autrement impossibles à produire car il n'y aurait pas assez de bande passante mémoire disponible pour que toutes les données soient accessibles en une seule ligne de balayage. Chaque fois que le circuit de contrôle de sortie de Linda accède à un tampon mémoire, un nibble différent de la partie bitmap du pixel compacté est utilisé pour déterminer le décodage approprié. Dans le cas des pixels PackLUT, quatre pixels Demi-Chunky sont décodés simultanément lors de chaque transfert vers Monica.

L'alignement des pixels PackLUT dans la mémoire est limité à un double alignement de mots longs (64 bits).

Pixels PackHY

Les pixels PackHY sont décompressés pour former des pixels hybrides standard. Les deux couleurs définissant chaque région de l'écran sont des valeurs de 24 bits utilisées pour piloter directement les canons à couleurs de l'écran. Dans ce mode d'affichage, 64 bits de données sont nécessaires pour spécifier chaque région, ce qui donne un taux de compression des données de 6 par rapport aux pixels hybrides standard.

Les puces traitent les données PackHY de la même manière que les données PackLUT. Les différences sont que deux fois plus de données doivent être récupérées et stockées dans Linda, et que les données des pixels sont envoyées à Monica de la même manière que les données des pixels hybrides.

L'alignement des pixels PackHY dans la mémoire est limitée à un alignement mot long double (64 bits).

HAM

L'AAA gère le mode HAM exactement comme dans l'ancien jeu de composants. Quand l'option "HAM" du registre BPLCON0 est activée, les plans de bits de 1 à BPU (plan de bits utilisés) sont accédés pour générer l'affichage. BPU est réglé sur 6 pour activer un mode HAM compatible avec les anciennes puces Amiga. Dans ce cas, les plans 5 et 6 fournissent les bits de contrôle HAM et les plans 1 à 4 fournissent une adresse à la table de correspondance, ou sont utilisés pour remplacer l'une des sorties couleur de la table de correspondance commandée par les bits de contrôle HAM. Lorsque la table de correspondance est adressée, seuls les 16 registres inférieurs de celle-ci sont disponibles. Lorsque l'une des couleurs de la table de correspondance est remplacée par les plans 1 à 4, les deux nibbles de couleur les plus significatives et les moins significatives sont remplacées par la couleur de remplacement HAM spécifiée.

Le mode HAM a également été étendu pour tirer parti des plans de bits supplémentaires fournis par l'AAA. Lorsque le mode HAM est activé, mais que BPU n'a pas été réglé sur 6, il est possible d'utiliser jusqu'à dix plans de bits (HAM10). Dans ce mode, les plans de bits 3 à BPU sont utilisés pour adresser la table de correspondance, et les plans de bits 1 et 2 sont utilisés pour fournir les informations de contrôle HAM. Lorsque le BPU était réglé sur 10, les 256 registres de la table de correspondance sont accessibles. Lorsqu'une modification de la couleur de la table de correspondance est effectuée, les 8 bits de la couleur de celle-ci étaient remplacés par les données des plans 3 à 10. Si BPU est réglé sur un nombre supérieur à 6 mais inférieur à 10, les bits d'adresse les plus significatifs sont forcés à l'état bas. Cela permet aux modes HAM d'exiger une surcharge de données plus faible et d'assurer la compatibilité avec le mode HAM 8 bits de l'AA.

Mode Extra Half Brite

Le mode Extra Half Brite n'a pas été étendu dans l'AAA. Il a été conservé tel qu'il fut défini à l'origine, et cela pour gérer les anciens logiciels. Comme dans l'ancien jeu de composants, le mode Extra Half Brite ne peut pas être explicitement activé. Lorsque BPU est réglé sur 6, que le double champ de jeu est désactivé et que l'option "HAM" n'est pas réglée, le mode Extra Half Brite est activé. Ce réglage peut bien sûr être annulé en réglant l'option "KILLEHB" (supprime le mode Extra Half Brite).

Les sprites

Des registres de sprites étendus ont été ajoutés à l'AAA pour permettre l'affichage de sprites de 32 bits. Plusieurs nouveaux modes ont également été incorporés dans le fonctionnement des sprites étendus.

Chaque fois que l'un des anciens registres SPRxCTL est écrit, les bits qui activent les nouveaux modes sont réinitialisés afin d'assurer la compatibilité logicielle avec l'ancien jeu de composants. Ces modes ne peuvent être activés (ou réactivés) qu'en écrivant (ou réécrivant) les registres sprite étendus. Dans l'ancien jeu de composants, la résolution des sprites est toujours en basse résolution (lowres). En d'autres termes :
  • En mode basse résolution, chaque pixel de sprite a une largeur de 1 pixel de plan de bits.
  • En mode haute résolution, chaque pixel de sprite a une largeur de 2 pixels de plan de bits.
Un bit "FAST" a été ajouté aux registres de contrôle des sprites étendus, ce qui permet d'outrepasser cette règle. Lorsque ce bit est à 0, le sprite est affiché en mode basse résolution (moitié de la fréquence de transmission des pixels) comme dans l'ancien jeu de composants. Lorsque ce bit est à 1, le sprite est affiché en haute résolution, ou à la fréquence de transmission des pixels (cela fonctionne dans tous les systèmes AAA et toutes les combinaisons d'écrans basse résolution/haute résolution, sauf dans le cas d'un système AAA double et si le mode pixel basse résolution est activé).

Dans l'ancien jeu de composants, il est impossible d'afficher des sprites en dehors de la fenêtre d'affichage définie par DIWSTRT et DIWSTOP. Aucun sprite ne peut apparaître dans le bord de l'écran. Un bit de contrôle étendu des sprites a été défini (CONSPRT) permettant de contourner cette difficulté. Lorsque ce bit est activé, les sprites peuvent être affichés partout sauf dans les intervalles de suppression. Monica utilise le signal présent sur la broche d'entrée CBLK pour déterminer où se trouve la zone de suppression. Il est possible que des collisions de sprites soient générées dans les régions de suppression. D'un point de vue matériel, Monica traite les données sprites à tout moment lorsque CONSPRT est activé. Ces informations sont simplement supprimées aux sorties du convertisseur numérique-analogique lorsque l'entrée CBLK indique une région de suppression. Lorsque CONSPRT est désactivé, les sprites ne peuvent être affichés que dans la région définie par DIWSTRT et DIWSTOP.

Une nouvelle fonction de répétition des sprites a également été incorporée dans l'AAA. Le champ de contrôle HSRPT dans SPRxCTLX définit le nombre de fois qu'un sprite doit être répété sur chaque ligne horizontale. Ce mode permet de générer des sprites très répétitifs. Par exemple, il peut être utilisé pour dessiner des lignes horizontales pour la génération de curseurs. Une dernière utilisation de ce mode est la génération de sprites symétriques à double largeur.

Le nouveau bit "SMIRROR" permet aux sprites d'être reflétés autour d'un axe vertical chaque fois que le sprite est réaffiché sous le contrôle de HSRPT. L'axe est situé juste après le bit de données 0 du sprite. SMIRROR permet l'affichage de sprites symétriques larges.

Mode rafale des sprites

Deux bits de contrôle supplémentaires sont fournis dans les registres SPRxPOSX, BURST64 et BURST128. Lorsque l'un de ces bits de contrôle est activé, le contrôleur DMA exécute des cycles de bus en mode rafale pour satisfaire les demandes de données sprite. Cela permet d'afficher des sprites de 64 ou 128 bits de large. Certaines limitations existent en ce qui concerne l'utilisation des extractions sprite en mode rafale.

Le bit de contrôle "Burst64" dans le registre de contrôle sprite étendu active les sprites de 64 bits de large et provoque deux cycles de transfert en rafale. Les listes de sprites de 64 bits doivent être alignées pour commencer à deux adresses de mots longs. Le matériel DMA sprite a été conçu pour exécuter deux cycles complets de transfert en rafale lorsque Burst64 est activé. Un transfert en rafale est utilisé pour remplir le registre de données SPRxDATX A, et l'autre est utilisé pour remplir le registre de données SPRxDATX B. Le matériel DMA a été simplifié en exigeant que deux transferts en rafale de ce type soient toujours effectués lorsque la liste des sprites est consultée et que le canal DMA des sprites est en mode Burst64. À cette fin, les informations relatives à la position et au contrôle des sprites qui suivent la partie de la liste consacrée aux données des sprites doivent être répétées deux fois (c'est-à-dire position, position, contrôle, contrôle). Cela simplifie non seulement la logique DMA, mais fournit également un moyen de remplir les listes de sprites avec des données afin d'éviter les problèmes de croisement de pages résultant de problèmes d'alignement des données de sprites.

Le bit de contrôle "Burst128" dans le registre de contrôle sprite étendu active les Sprites 128 bits et provoque quatre cycles de transfert en rafale. Les listes de sprites de 128 bits doivent être alignées pour commencer à des adresses de quatre mots longs. De manière similaire à la méthode décrite ci-dessus pour remplir les listes de sprites avec des données afin d'éviter les problèmes de croisement de pages, la position du sprite et les informations de contrôle du sprite qui suivent la partie des données de la liste de sprites doivent être répétées quatre fois (c'est-à-dire position, position, position, position, contrôle, contrôle, contrôle, contrôle, contrôle).

Il est possible de générer des listes de sprites contenant un mélange de sprites 32 bits, de sprites 64 bits et de sprites 128 bits, mais certaines restrictions d'alignement s'appliquent lorsqu'un tel mélange est effectué. La longueur des sections de position et de contrôle d'une liste de sprites n'est pas la seule donnée qui peut affecter l'alignement de la liste de sprites. Les données du sprite lui-même peuvent affecter l'alignement de la liste. Par exemple, si une liste de sprites n'est pas configurée pour afficher deux fois le sprite 0, avec la première définition de sprite dans cette liste configurée pour être un sprite 32 bits de deux lignes de haut, et la deuxième définition de sprite configurée pour être un sprite 128 bits, alors la liste de sprites doit être Située en mémoire pour commencer à une adresse telle que le bit d'adresse A1 est 0, et le bit d'adresse A2 est 1. Cela garantit qu'aucun problème de saut de page n'est rencontré pendant le traitement des sprites de 128 bits.

Contrôleur de disquette

Le contrôleur de disquette AAA a été conçu pour être flexible. Il peut être utilisé pour lire/écrire une variété de flux de données sériels à partir d'une variété de supports ou de matériel. L'objectif de flexibilité a été tempéré par le désir d'obtenir un contrôleur à faible coût. Afin d'atteindre ces deux objectifs simultanément, il est nécessaire de sacrifier une partie de l'automatisation matérielle normalement associée aux contrôleurs de disquettes, et d'exiger qu'un pilote logiciel doit assister certaines des opérations de formatage de l'en-tête de secteur. En choisissant le bon équilibre entre la gestion logicielle et le matériel, un contrôleur a été implémenté, ce dernier fournit des temps d'accès compétitifs, une charge logicielle minimale, une surface de puce minimale et une flexibilité maximale.

La gestion des lecteurs de disquette de 2 et 4 Mo a été ajoutée (un nouveau format de disquette Amiga 4 Mo/RLL(2,7) est prévu). Les circuits de disquettes sont capables d'encoder et de décoder le format MFM pour assurer la compatibilité IBM, et de nouveaux modes ont été ajoutés pour gérer les formats RLL(2,7) et les CD-ROM audio. Des adresses RCA nouvelles et étendues ont été définies pour contrôler ces nouveaux modes et les lecteurs de disquette à plus haute densité. Un nouveau canal DMA a été défini, ce qui permet un haut degré de flexibilité en ce qui concerne les formats de supports de disquettes. Sous contrôle logiciel, il est possible de gérer de nombreux nouveaux formats de secteur sans qu'il soit nécessaire de modifier le matériel. Les anciens registres de contrôle des disquettes ont été laissés intacts pour préserver la compatibilité.

Nouvelles caractéristiques des disquettes :
  • un séparateur de données jusqu'à 20 fois plus rapide (fenêtre de 100 ns) avec des paramètres variables.
  • Le séparateur de données peut avoir une fréquence différente (asynchrone) de la fréquence du système.
  • Décodage/encodage des codes MFM, Biphase Mark et RLL(2,7).
  • Lecture et écriture basées sur le secteur avec calcul et génération de CRC, les données sont lues/versées directement depuis/vers la mémoire tampon de l'utilisateur.
  • Lecture/écriture en continu du format numérique de diffusion CD/DAT/FM.
  • Formats spécialisés avec des débits de données allant jusqu'à environ 5 Mbits/sec.
Modes du contrôleur de disquette

Voici les extensions apportées à Paula pour permettre la gestion haute performance de médias précédemment étrangers à la ligne de produits Amiga.

Mode piste : le mode piste (mode-0) a été conçu pour être utilisé avec l'ancien format Amiga. Le mode piste est aussi utilisé pour formater les disquettes pour une utilisation en mode secteur. Comme avec le contrôleur de disquette Paula, le mode piste nécessite que les données soient converties vers/depuis le format bit brut par le coprocesseur ou le processeur hôte.

Mode secteur : le mode secteur (mode=1) a été conçu spécialement pour le format Western Digital (IBM), mais peut également être utilisé dans un large éventail de formats de secteurs. Il peut opérer sur un à N secteurs par piste et effectuer une génération CRC/un contrôle d'erreur. Le mode secteur nécessite des données brutes en mémoire. Ces données sont une copie de l'en-tête du secteur qui adresse les données du secteur à traiter. Le contrôleur de disquette utilise ces données pour les comparer au flux de données brutes provenant de l'unité de la disquette. Une fois que l'en-tête de secteur approprié est trouvé, le contrôleur de disquette commence à lire/écrire des données sectorielles non codées depuis/à partir de la mémoire, en effectuant un codage programmé sur les données (MFM, RLL(2,7), etc.) au fur et à mesure qu'elles sont traitées depuis/vers le flux de bits en série du support.

Mode CD : le mode CD (mode=2) a été conçu pour les formats CD, DAT et de diffusion numérique. Il transfère les données décodées vers la mémoire et encode les données de la mémoire au fur et à mesure de leur sortie. Le mode CD génère une interruption à chaque secteur pour permettre une double mise en mémoire tampon des données audio CD.

Mode piste plus ou "trackplus" : le mode piste plus (mode=3) a été conçu comme un mode de format limité pour les transferts à grande vitesse qui nécessitent une bande passante DMA réduite. Il transfère uniquement des données codées/décodées de/vers la mémoire. Les marques de synchronisation sont automatiquement insérées/reconnues dans le flux de données brutes et les CRC sont générés/vérifiés. Ce mode exige qu'une image des données de piste non codées existe dans la mémoire lorsque les écritures sont effectuées, et laisse une image décodée des données de piste dans la mémoire lorsque les écritures sont effectuées. Cette image comprend une section d'en-tête, des données de synchronisation, des données d'écart, des données CRC (ces données sont laissées vides lorsque les écritures sont effectuées, car le contrôleur calcule le CRC approprié et l'insère dans le flux de données) et les données réelles.

Comparatif Mary/Paula pour la gestion des disquettes

  Mary Paula
Largeur de bit brut 88-9000 ns 2000 et 4000 ns
Débit brut maximal 11,4 Mbits/s 0,5 Mbits/s
Méthode d'encodage brute Oui Oui
Méthode d'encodage GCR Oui Oui
Méthode d'encodage MFM Oui Non (réalisé logiciellement)
Méthode d'encodage RLL(2,7) Oui Non
Méthode d'encodage Biphase-Mark Oui Non
Synchronisation 32, 16 et 8 bits 16 bits
Mode piste Oui Oui
Mode secteur Oui Non
Mode CD numérique Oui Non
Mode piste plus Oui Non
CEC matériel Oui (secteur, piste plus) Non
Fréquence PLL asynchrone Oui Non
Types d'entrées Impulsion, NRZ Impulsion

Audio

Dans la puce Paula d'origine, chaque canal est une entité matérielle distincte, chaque canal a son propre registre de longueur, son propre compteur de longueur, son propre registre de période et son propre compteur de période. Dans l'AAA, il n'y a qu'un seul ensemble de logique de calcul pour tous les canaux et pour toutes les combinaisons logiques. Les calculs sont séquencés à raison de quatre calculs par canal, et les huit canaux sont calculés en séquence. Ce calcul séquentiel utilise moins de silicium et permet d'obtenir la même fonctionnalité.

Un canal audio donné peut fonctionner soit en mode "ancien" (compatibilité), soit en mode "nouveau". Un canal passe en mode ancien à la mise sous tension, et chaque fois que l'ancien bit DMACON est activé ou qu'une écriture est effectuée dans le registre AUDXDAT 16 bits pour ce canal. Le nouveau mode se déclenche lorsque le nouveau bit DMACONX DMA est utilisé ou lorsque le nouveau registre de données AUDXDATX est utilisé. Le canal reste dans le mode dans lequel il est réglé jusqu'à ce que certaines actions se produisent. Les actions de l'ancien mode l'emportent sur celles du nouveau mode en cas de conflit. L'idée est que tous les anciens programmes doivent fonctionner quel que soit le mode dans lequel un programme laisse les nouveaux bits de contrôle.

Une autre modification a été apportée aux circuits du potentiomètre (pot). Ils peuvent à présent être programmés pour compter à un taux de BUSCLK (14,3 MHz) ainsi qu'au taux traditionnel de 16 kHz. Lorsque ce nouveau mode est invoqué, la période du potentiomètre est établie par la période du canal audio 3 au lieu de la période traditionnelle de synchronisation verticale du moniteur. Ce nouveau mode de fonctionnement à vitesse plus élevée permet d'utiliser les circuits du potentiomètre comme circuit d'échantillonnage audio. Lorsque le mode d'échantillonnage audio est invoqué, le canal audio 3 ne peut plus être utilisé dans le mode de sortie normal. Le canal est sacrifié pour gérer l'échantillonnage audio.

UART (Universal Asynchronous Receiver Transmitter, émetteur-récepteur asynchrone universel)

Un deuxième UART a été ajouté à l'AAA. Cet UART est identique à l'UART original à tous égards, sauf bien sûr les adresses RGA. En plus du nouvel UART, les deux UART ont été étendus pour contenir un tampon FIFO de port de réception. Ces FIFO ont une longueur de quatre octets et permettent au système d'avoir plus de temps de latence pour gérer des taux de bauds de réception plus élevés.

Exemples de fonctionnement

1. Fréquences de bus et d'affichage des pixels

La fréquence du bus système n'est plus liée à la fréquence de l'affichage/transmission des pixels. Le générateur de fréquence contient deux cristaux pour fournir la fréquence du bus système et la fréquence de transmission des pixels (dans une implémentation à fonction réduite du système d'entrée de gamme, il est possible d'utiliser un cristal à fréquence unique pour piloter à la fois les circuits de fréquence de transmission des pixels et les circuits de fréquence de bus du jeu de composants). La fréquence de l'horloge du bus maître (MCLK) est de 57,2727 MHz et est constante pour toutes les configurations du système, y compris les systèmes haut de gamme. Andrea utilise cette horloge pour dériver un BUSCLK de 14,318 MHz et un CLK28 de 28,636 MHz. Le CLK28 est utilisé pour piloter le contrôleur de disque de Mary, le Blitter et le coprocesseur (note : il s'agit de la configuration standard. Il est possible de piloter la broche CLK28 de Mary avec une fréquence plus élevée afin de gérer de manière fiable les disques durs, les lecteurs DAT et d'autres périphériques de stockage de bits sériels à haut débit). BUSCLK constitue la base de la synchronisation du bus de la puce et de la synchronisation des circuits audio, UART, potentiomètre et souris.

La fréquence de transmission des pixels varie en fonction du moniteur utilisé dans le système. Les systèmes NTSC utilisent une fréquence de transmission des pixels de 14,318 MHz, les systèmes VGA de 28,636 MHz, les systèmes VGA+ de 36 MHz, les systèmes 1024x768 de 64 MHz et les systèmes 1280x1024 de 110 MHz (tous à des fréquences de trame de 60 Hz). La fréquence de transmission des pixels est également programmable dans un système de résolution d'affichage donnée. Cela est nécessaire pour permettre la promotion d'écrans à faible résolution. Par exemple, la fréquence de transmission des pixels en mode natif d'un système 1024x768 est de 64 MHz. Lorsqu'un écran NTSC est promu, la fréquence de transmission des pixels est ramenée à 44 MHz. Ce changement est effectué par le processeur ou le coprocesseur sur la ligne précédant la ligne à promouvoir. Le passage de la fréquence de transmission des pixels de 64 à 44 MHz se fait alors automatiquement au moment de la suppression horizontale.

Un circuit synthétiseur de fréquence programmable peut être utilisé pour fournir les différentes fréquences de transmission des pixels nécessaires à la promotion d'écran sur un écran donné. Ce circuit serait incorporé dans un module de personnalisation du moniteur et serait modifié pour correspondre au moniteur utilisé dans le système. La carte de personnalisation de la fréquence de transmission des pixels contiendrait également une logique qui répondrait à la nouvelle adresse RGA MONITORID pour informer le logiciel du type de moniteur utilisé dans le système. Pour simplifier le circuit externe, Mary fournit un signal MONIDEN pré-décodé pour piloter la carte de personnalisation.

2. Liaison série Mary/Andrea

Dans l'ancien jeu de composants Amiga, un port série existait entre Agnus et Paula afin que Paula puisse informer Agnus des canaux DMA qui avaient besoin d'être entretenus. La synchronisation de ce port série est intimement lié aux intervalles de temps fixes du DMA. Pendant que Paula transmettait des requêtes à Agnus, Agnus répondait immédiatement à la requête en exécutant le cycle de transfert DMA approprié. Ce schéma n'aurait pas fonctionné dans le nouveau jeu de composants AAA parce qu'il n'est pas possible de garantir qu'un cycle donné soit disponible pour satisfaire une requête. L'AAA incorpore un schéma de requête DMA prioritaire à la demande. La liaison série entre Andrea et Mary a été modifiée en conséquence. Plutôt que d'attendre le temps mort horizontal pour informer Andrea de toutes les requêtes DMA accumulées au cours de la ligne précédente, Mary envoie des requêtes à Andrea au fur et à mesure qu'elles sont générées. Les requêtes sont accumulées et envoyées à l'Andrea comme suit :

Après la réinitialisation du système, la liaison série entre Mary et Andrea fonctionne en permanence et envoie des données, même lorsqu'il n'y a pas de requêtes DMA. Dans Mary, les requêtes audio entrent dans deux registres à décalage de 8 bits décalés lorsque les 2 bits inférieurs du compteur audio de Mary sont égaux à 3 (à une fréquence de 3,5 MHz). Les requêtes sont prises sur plusieurs points du registre à décalage de sorte qu'elles sortent de la liaison à la position de bit correcte dans le transfert. Les requêtes de disque sont introduites dans un FIFO à deux profondeurs chargé par un signal de Mary interne, DSKDR. La sortie de ce FIFO est multiplexée sur DMAL aux positions binaires appropriées.

Andrea est synchronisée avec la liaison série par deux bits de marquage spéciaux. Il n'y a pas de requête DMA au moment de la mise sous tension et de la réinitialisation. Un compteur de 5 bits dans Andrea compte jusqu'à 31 et s'arrête jusqu'à ce que deux "1" soient présents, séparés par 3 bits (les bits entre les deux ne sont pas vérifiés). Comme il s'agit d'un système synchrone, le canal série ne doit jamais perdre la synchronisation après le premier transfert nul suivant la réinitialisation. Si le canal se désynchronise, il se rétablit en deux cycles de transfert complets au maximum qui ne contiennent pas de requêtes DMA. Après la synchronisation, le compteur d'Andrea serait en retard de quelques tics par rapport à celui de Mary. Un registre à décalage de 4 bits reçoit les données du DMAL, et tous les 4 bits, un nibble de données est verrouillé, soit dans le FIFO de requête de disque, soit dans quatre des registres de stockage de demande audio. Le FIFO de disque n'est chargé que lorsque le numéro de la requête est différent de zéro. L'accusé de réception de l'intérieur d'Andrea indiquant que le cycle a eu lieu décharge le FIFO du disque ou réinitialise les bascules de requête audio de manière appropriée. La liste suivante indique la position relative de chaque bit de requête dans le flux de données série :

Bit	Signification

0	audOdsr, Audio channel 0 (re)start request
1	audOdr, Audio channel 0 empty
2	aud1dsr, Audio channel 1 (re)start request
3	audldr, Audio channel 1 empty
4	aud2dsr, Audio channel 2 (re)start request
5	aud2dr, Audio channel 2 empty
6	aud3dsr, Audio channel 3 (re)start request
7	aud3dr, Audio channel 3 empty
8	dskreq(2), Disk Request Control Bit 2
9	dskreq(1), Disk Request Control Bit 1
10	dskreq(0), Disk Request Control Bit 0
11	0, this bit always zero
12	dskreq(2), Disk Request Control Bit 2
13	dskreq(1), Disk Request Control Bit 1
14	dskreq(0), Disk Request Control Bit 0
15	0, this bit always zero
16	aud4dsr, Audio channel 4 (re)start request
17	aud4dr, Audio channel 4 empty
18	audSdsr, Audio channel 5 (re)start request
19	aud5dr, Audio channel 5 empty
20	aud6dsr, Audio channel 6 (re)start request
21	aud6dr, Audio channel 6 empty
22	aud7dsr, Audio channel 7 (re)start request
23	aud7dr, Audio channel 7 empty
24	dskreq(2), Disk Request Control Bit 2
25	dskreq(1), Disk Request Control Bit 1
26	dskreq(0), Disk Request Control Bit 0
27	1, sync, this bit always one
28	dskreq(2), Disk Request Control Bit 2
29	dskreq(1), Disk Request Control Bit 1
30	dskreq(0), Disk Request Control Bit 0
31	1, sync, this bit always one

3. Liaison série Andrea/Linda

Linda a besoin de certaines informations du registre de contrôle du plan de bits (BPLCON) pour exécuter toutes ses fonctions. Les limitations des broches de Linda ne permettent pas d'accéder au bus AD de manière à ce qu'elle puisse verrouiller elle-même les données du registre BPLCON. Les limitations des broches d'Andrea ne permettent pas de transférer les informations de contrôle nécessaires directement à Linda via des lignes de signal dédiées. Comme la plupart des données nécessaires ne peuvent changer que ligne par ligne, une liaison série entre les deux puces a été mise en place pour transférer les données qui changent lentement au début de chaque ligne de balayage. Les informations transférées sur la liaison série sont les suivantes :
  • Haute ou basse résolution (HI/LO RES).
  • Nombre de plans de bits utilisés (BPU4-0).
  • Mode d'affichage du champ de jeu impair (OBPLMODE2-0, appelé T2-0 (pour le type) sur la liaison).
  • Commutation, direction, répétition de ligne (appelé RP1-0 sur la liaison).
  • PF1H0, PF2H0 (lsb de défilement des champs de jeu 1 et 2).
Les données envoyées à Linda sont les mêmes que celles utilisées par Andrea pour la récupération des lignes graphiques actuelles. En d'autres termes, le registre est accessible après le registre "TransferValues".

Linda utilise HI/LO lorsqu'elle transfère des informations à Monica. Lorsque HI/LO indique une faible résolution, les données sont envoyées à Monica à la moitié de la fréquence à laquelle elles sont envoyées en mode haute résolution.

BPU ("bitplanes used") indique à Linda combien de plans de bits de données sont mis en mémoire tampon. Linda l'utilise lorsque le mode graphique est en plan de bits pour aider à déterminer le moment exact où les données doivent être envoyées à Monica.

BPU a également une signification lorsqu'il contient un zéro. Le zéro BPU indique qu'aucune donnée ne doit être envoyée à Monica sur cette ligne de balayage. Il n'est pas nécessaire que le type de graphique soit un plan de bits pour que ce soit le cas. Le champ BPU est forcé à toutes les reprises pendant les lignes de balayage qui constituent la suppression verticale.

T2-0 est décodé par Linda pour déterminer le type de données graphiques comme suit :

T2-0 	Type de graphismes

000 	Mode planaire
001 	Mode hybride
010 	Mode Chunky
011	Mode PackLUT
100	Mode Demi-Chunky 4 bits
101	Mode Demi-Chuncky (Half-Chunky)
110	Mode Demi-Chunky 2 bits
111	Mode PackHY

Linda doit connaître le type de graphismes lorsqu'elle reçoit des données extraites de la mémoire et lorsqu'elle accède aux données mises en mémoire tampon pour les présenter à Monica.

SWITCH est un signal que Linda utilise pour déterminer qu'elle doit changer de banque mémoire et commencer à remplir de nouvelles lignes de données dans le tampon qu'elle vient de finir d'envoyer à Monica. SWITCH est normalement activé à chaque ligne de balayage. Il ne l'est pas sur certaines lignes de balayage lorsque le système graphique est en mode de promotion d'écran. Dans ce cas, Linda continue de remplir la banque mémoire qu'elle remplit à la dernière ligne de balayage, et elle envoie à Monica le même tampon que celui qu'elle a envoyé à la dernière ligne de balayage. En d'autres termes, SWITCH est activé à chaque ligne de balayage que le "compteur d'avance de ligne" d'Andrea passe à 0.

DIR est le signal de direction. Lorsque ce bit est activé, les données graphiques sont capturées sur le bus VCDATA et présentées sur le bus GDATA (normalement, les données graphiques sont capturées sur le bus GDATA et présentées sur le bus VDATA). Ce signal indique que le sous-système graphique est en mode capture d'images.

RP indique combien de lignes de balayage chaque tampon de données graphiques est envoyé à Monica. Linda n'utilise cette information que lorsque le mode graphique est l'un des types de pixels compactés. Le tableau suivant indique combien de fois chaque ligne est envoyée à Monica lorsque le mode d'affichage est un type de pixels compactés :

RP1,0	Action

00	Chaque ligne est répétée quatre fois
01	Chaque ligne est répétée trois fois
10	Chaque ligne est répétée deux fois
11	Chaque ligne est affichée une fois

PF1H0, PF2H0 sont les bits les moins significatifs des champs de jeu 1 et 2 de contrôle de défilement des graphismes. Linda utilise ces bits pour déterminer quels bits graphiques, pairs ou impairs, extraire du flux de données entrant dans un système double (haut de gamme). Lorsque ces bits sont à zéro, la puce Linda paire extrait les pixels pairs, et la puce Linda impaire extrait les pixels impairs.

Les données sérielles sont communiquées à Linda via le signal "TDATA", et cadencées dans Linda avec le signal "TCLK". La liste suivante montre la position relative de chaque bit de données dans le flux de données en série.

Position bit	Signification

0		HI/LO RES.   Haute résolution de BPLCON0
1		BPUO.	     BPUO de BPLCON0
2		BPU1.	     BPU1 de BPLCON0
3		BPU2.	     BPU2 de BPLCON0
4		BPU3.	     BPU3 de BPLCON0
5		BPU4.	     BPU4 de BPLCON0
6		T0.	     OBPLMODEO de BPLCON3
7		T1. 	     OBPLMODE1 de BPLCON3
8		T2.	     OBPLMODE2 de BPLCON3
9		SWITCH 	     Permutation des banques mémoire
                             Généré depuis TransferValues
10		DIR.	     DIR de BPLCON3 (mode "Framegrabber")
11		RP0.	     LINERPT0 de BPLCON3
12		RP1.	     LINERPT1 de BPLCON3
13		PF1H0.	     PF1H0 de BPLCON1
14		PF2H0.	     PF2H0 de BPLCON1

Le Nyx

Les quatre puces du jeu de composants du AAA, bien que jamais terminées, ont été fabriquées à quelques exemplaires. Et pour les tester, une carte prototype a été conçue par Dave Haynie et Greg Berlin : le Nyx. Il existe trois prototypes de Nyx mais ils sont malheureusement pas assez fonctionnels pour lancer le système d'exploitation. Cette carte est basée sur l'architecture de l'Amiga 3000 mais l'AAA, à terme, était prévu d'être intégré dans l'architecture Acutiator, également conçue par Dave Haynie.

Nyx Nyx
Le Nyx

Les quatre composantes du AAA sont les grosses puces noires : Linda et Monica au centre-gauche, Andrea au centre et Mary tout à droite. Les deux emplacements au-dessus de Linda/Monica sont réservés à deux autres puces Linda et Monica. Pour l'anecdote, sachez qu'en octobre 2001, Dave Haynie vendit un des trois exemplaires de Nyx sur eBay. Il réédita une vente similaire en avril 2011. De chanceux collectionneurs Amiga sont donc en possession de ces raretés.

Nyx
Dave Haynie montrant le Nyx

Les coûts

Le coût des puces était prévu à 18,70 $ (Andrea), 10,36 $ (Mary), 16,38 $ (Monica), 11,40 $ (Linda) et 5,60 $ (Gary version AAA), pour un coût total du AAA, avec les autres puces et mémoire, à 214,325 $. Dave Haynie prévoyait un prix de vente d'un système AAA à 650 dollars (avec une marge triple) ou 850 dollars (avec une marge quadruple).

En comparaison, l'AA+ aurait coûté 172,01 $ (pour un prix de vente de 520 $, alors que l'Amiga 500 à cette époque (1992) coûtait 178 $ à produire et était vendu 540 $.

Conclusion

Des puces pleinement fonctionnelles du AAA n'ont jamais été produites, bien que le terme de son développement était à portée de main. Certains des aspects de ce jeu de composants ont été repris dans Hombre, une conception très différente basée sur le microprocesseur PA-RISC 7150 de Hewlett-Packard. Si commodore avait donné plus de moyens à ses ingénieurs, l'AAA aurait sans doute été disponible entre 1990 et 1992, et il aurait ainsi remis l'Amiga au sommet de la technologie pour quelques mois/années.

Annexe

Sur la page Dave Haynie Archives existe un aperçu concernant les spécificités techniques du AAA : www.thule.no/haynie/research/nyx/docs/AAA.pdf. Et en avril 2023, Dave Haynie a publié un document détaillant tout ce jeu de composants. Ce dernier document a servi de base technique pour cet article.

Nom : AAA (Advanced Amiga Architecture).
Constructeur : Commodore.
Genre : prototype de jeu de composants.
Date : 1988-1993.
Prix : 650 à 850 $.


[Retour en haut] / [Retour aux articles]


Soutenez le travail de l'auteur