 |
Vendredi 23 mai 2025 - 11:13 |
| Translate |
|
| Rubriques |
| Réseaux sociaux |
|
| Liste des jeux Amiga |
|
| Trucs et astuces |
|
| Glossaire |
|
| Galeries |
|
| Téléchargement |
|
| Liens |
|
| Partenaires |
|
| A Propos |
|
| Contact |
|
|
|
L'AA+ est un jeu de composants annoncé par Commodore fin 1992, mais qui n'est jamais sorti. Il était prévu pour équiper les Amiga d'entrée de gamme de 1994. Les machines haut de gamme devant, elles, être pourvues du jeu de composants AAA.
Contexte
L'histoire de l'Amiga est intimement liée à celle de ses puces spécialisées. Ces circuits lui ont permis, lors de son lancement en 1985, d'être techniquement au-dessus des autres ordinateurs, comme le Macintosh, les compatibles PC ou l'Atari ST.
Ces circuits ont connu des améliorations au fil des années mais une partie de ceux-ci furent trop onéreux pour les finances de Commodore. C'est ainsi qu'en 1991, alors que le jeu de composants AAA était en développement, Commodore se rendit compte qu'il coûtait très cher à fabriquer et que beaucoup de temps serait nécessaire à sa finalisation. La société repoussa donc la sortie de l'AAA et conçut, à la place, un autre jeu de composants : l'AA (plus tard renommé "AGA"). Celui-ci fut inclus dans les nouveaux Amiga, comme l'A4000 et l'A1200, à partir de fin 1992.
Mais même avec ce délai supplémentaire, Commodore jugea que l'AAA serait trop cher pour les petites configurations. L'AAA était basé sur quatre puces (Andrea, Monica, Mary, Linda) dans sa version 32 bits et six dans sa version 64 bits (les puces Linda et Monica devaient être doublées). Ce jeu de composants semblait donc irréalisable pour une machine peu chère du type A1200.
La solution vint de la création d'un autre jeu de composants, l'AA+. Ce dernier devait équiper les machines d'entrée de gamme alors que l'AAA serait toujours utilisé pour les grosses configurations.
Lors de la conférence développeur Devcon, qui s'est tenue à Orlando (États-Unis) en janvier 1993, Lew Eggebrecht, vice-président du développement de Commodore, indiqua ces quelques informations sur l'AA+ :
"L'AA+ sera une version plus rentable du AA avec toutes les choses que nous avons toujours voulues y mettre mais sans jamais en avoir le temps. Nous avons une liste exhaustive de tous les problèmes connus : le port série, nous ne pouvons pas lire les disquettes haute densité, il n'y a pas assez de bande passante pour faire fonctionner les écrans en 72 Hz, et il n'y a aucun mode d'affichage "chunky pixel". On a donc tout listé et on s'est dit "Ok, on va corriger tous ces problèmes le plus vite possible", c'est pour ça que l'AA+ est plus une extension qu'une nouvelle architecture. Nous faisons de notre mieux, en profitant des progrès technologiques pour réduire les coûts de manière significative, et c'est bien là l'objectif."On peut donc voir l'AA+ comme une extension de l'AGA mais pas une nouvelle technologie. Cela aurait été un peu l'équivalent de l'ECS par rapport à l'OCS.
Ce projet n'a malheureusement pas été mené à son terme. Pire, selon Dave Haynie, l'AA+ n'existait que sur papier et aucun vrai travail de conception ne fut commencé.
Les puces de l'AA+
Un document préliminaire daté du 14 mai 1992 sur l'AA+ mentionne trois nouvelles puces : Ariel, Belle et Debi (1, 2) qui remplace sept composants de l'AA/AGA (Alice, Paula, Lisa, Video DAC, VIA, Gayle et TTL).
Ariel
Ariel (Agnus/Paula Element) est le successeur d'Agnus/Alice et de Paula présent dans le projet de jeu de composants AA+. Ariel est une puce CMOS personnalisée qui présente 160 broches, 100 000 transistors et qui est cadencée à 57 MHz. Ariel peut être vu comme une fusion Agnus/Alice avec Paula. Elle est responsable de la génération, de la synchronisation et du contrôle des adresses pour la vidéo et pour la mémoire Chip. Elle gère aussi l'interfaçage pour les périphériques et propose des fonctions audio.
Belle
Belle est le successeur de Denise/Lisa présent dans le projet de jeu de composants AA+. Belle est une puce CMOS personnalisée qui présente 84 broches, 100 000 transistors et qui est cadencée à 57 MHz. Belle est responsable des fonctions d'affichage vidéo et présente un convertisseur numérique-analogique 8 bits à triple tampon mémoire. Pour les applications nécessitant le bus vidéo numérique RVB 24 bits complet, le convertisseur numérique-analogique aurait pu facilement être supprimé de la base de données et le bus vidéo numérique pu être mis sur pastilles (ce qui aurait nécessité un boîtier à 144 broches).
Debi
Debi est le successeur du CIA 8520 et de Gayle présent dans le projet de jeu de composants AA+. Debi est une puce CMOS de type réseau de portes (gate array) qui présente 160 broches. Il aurait s'agit d'une conception à nombre de portes relativement faible avec des exigences de vitesse modérées. L'interface du processeur et la logique de contrôle du système n'auraient pas été radicalement différentes de celles implémentées dans la puce Gayle de l'A600, mais les conceptions du VIA 8520 auraient dû être portées et réimplémentées dans la technologie des réseaux de portes.
Spécifications
Voici les spécifications que l'on pouvait attendre de l'AA+ :
- Trois composants, 160 à 280 broches, dont certains avec 100 000 transistors.
- Fréquence d'horloge (pixel clock) de 57 MHz.
- Utilisation de mémoire Chip en DRAM 60 ns mode page.
- Utilisation du système Acuciator de Dave Haynie.
- Contrôleur de lecteur de disquette 4 Mo/4 Mbps avec contrôle de redondance cyclique (CRC) géré matériellement.
- Synchrone avec la fréquence vidéo.
- Compatible avec les registres de l'ECS et de l'AGA.
- Gère tous les processeurs 68k 32 bits.
- Bande passante pour la mémoire huit fois plus élevée qu'avec l'ECS.
- Blitter deux fois plus performant que celui de l'AGA.
- Affichage en 800x600 en 256 couleurs à 72 Hz non entrelacé.
- Affichage de résolutions supérieures à 800x600 mais avec un rafraîchissement plus faible.
- Mode True Color 16 bits (ou 24 bits ?).
- Ports série FIFO avec tampon mémoire plus important.
- Limite de la mémoire Chip repoussée à 8 Mo (registres d'adresses 23 bits).
Quelles auraient été les machines équipées d'AA+ ? Selon les annonces de Lewis Eggebrecht, les prétendantes furent les machines d'entrée de gamme voire de milieu de gamme de Commodore. Il faut noter aussi que l'arrivée de l'AA+ (et de l'AAA) était couplée avec celle d'une nouvelle version d'AmigaOS, la 4, qui devait gérer les écrans RTG et les pixels chunky. Or, ce système nécessitait au moins un 68020 complet (avec MMU voire FPU) et 4 Mo de mémoire. Et à ce moment-là (1993), des rumeurs sur l'existence d'un projet d'Amiga avec ce genre de spécifications furent ébruitées. Il s'agissait de l'Amiga 1400, qui était, selon les maigres informations de l'époque, une sorte d'Amiga 1200 pourvu d'un processeur plus rapide, d'un disque dur et de mémoire Fast en standard. Il est donc légitime de penser que ce modèle aurait aussi été équipé de cet AA+.
L'une des limitations les plus contraignantes de l'ECS/AGA était due à la mémoire Chip. Elle ne pouvait dépasser 2 Mo. Ici, avec l'AA+, la limite serait montée à 8 Mo, de quoi libérer les développeurs de jeux et leur permettre de placer davantage de données graphiques et audio dans cette mémoire Chip. De plus, la bande passante aurait été huit fois plus élevée que sur l'ECS grâce à l'utilisation de bus 128 bits, comme dans l'AAA. Enfin, le mode de pixel dit "chunky", intéressant pour afficher de la 3D, aurait été intégré. Ces trois avancées (limite mémoire Chip repoussée, mémoire plus rapide et mode pixel chunky) auraient sérieusement dopé les performances graphiques des jeux Amiga.
Pour l'affichage du Workbench ou des applications, une résolution de 800x600 en 256 couleurs à 72 Hz (Super 72) aurait été possible, ce qui est à peu près similaires aux caractéristiques du mode SVGA des PC milieu de gamme de l'époque. L'AA+ aurait pu aussi monter à 1024x768 pixels en mode entrelacé, donc pas loin du mode XGA des PC haut de gamme de l'époque.
Du côté de l'audio, les améliorations possibles sont floues. Lewis Eggebrecht prévoyait que les futurs Amiga aient des capacités CD. Selon lui, les bruitages et les musiques devaient venir de ce support, donc il n'était pas important d'apporter des canaux audio supplémentaires. Le vice-président du développement de Commodore voulait, en outre, que les futurs Amiga soient équipés de DSP, même pour les modèles d'entrée de gamme.
Enfin, l'AA+ aurait amélioré deux points matériels importants : le port série (on aurait eu droit à deux ports série avec tampon mémoire) et le contrôleur de lecteur de disquette. Celui-ci aurait pu lire les disquettes haute densité à pleine vitesse et sans bidouilles comme ce fut le cas dans les autres Amiga.
La feuille de route
Dans un document daté du 4 décembre 1991, l'ingénieur George Robbins du "AA+ group" propose une feuille de route de l'implémentation du jeu de composants AA+ :
"Compte tenu de ce qui précède, je propose une approche en trois phases qui présente des avantages à court terme pour assurer la flexibilité de la conception pendant le développement du nouveau jeu de puces, fournir une base claire pour le développement du nouveau jeu de puces et définir l'étape suivante au-delà de l'effort actuel de sorte que les besoins en matière d'architecture et de compatibilité qui pourraient avoir une incidence sur l'effort actuel soient bien compris.
Phase 0
La phase 0 est destinée à recueillir les résultats des efforts de développement déployés à ce jour sous une forme utilisable et à fournir une base sûre pour toute mise en oeuvre du système "AA" entreprise pendant que le nouveau jeu de puces est en cours de développement.
La phase 0 consiste en deux tâches mineures de développement LSI et deux tâches optionnelles qui peuvent être réalisées soit par le développement LSI, soit par les systèmes.
Il est prévu que les tâches de développement des LSI chevauchent la partie architecturale des tâches de la phase 1.
Tâche 1 - Agnus à 100 broches
Modification de la conception actuelle de l'Alice NMOS pour fournir une puce Agnus/Alice universelle dans un boîtier monté en surface à 100 broches. Ce dispositif comprend une interface processeur compatible avec les processeurs 16 ou 32 bits, gère les bus mémoire 16 ou 32 bits et élimine le TTL externe actuellement nécessaire pour la commutation d'horloge et le décodage DRAM. Il n'y a pas d'améliorations architecturales, mais quelques modifications mineures du noyau pour étendre les capacités existantes sont détaillées ci-dessous.
Tâche 2 - Paula MIDI/FIFO
Modification de la puce Paula existante pour fournir des étages FIFO supplémentaires dans la fonction UART afin de résoudre les problèmes actuels de débit à haut débit MIDI.
Tâche 3 - Implémentation de Paula dans un réseau de portes (optionnel)
La puce Paula actuelle est réimplémentée dans un réseau de portes générique pour fournir une fonction UART améliorée, un contrôleur de lecteur de disquette amélioré (haute densité) et une fonction audio 16 bits (qualité CD). Les fonctions disquette et audio 16 bits reposent sur l'extension de l'interface mémoire 32/64 bits à la puce Paula. Compte tenu de la mise en oeuvre générique du réseau de portes, la sortie du convertisseur analogique/numérique audio est remplacée par une interface série vers un convertisseur audio/numérique CD standard.
Tâche 4 - Implémentation du réseau de portes 8520 (optionnel)
La conception actuelle du 8520 NMOS personnalisé est convertie en un réseau de portes générique pour permettre l'intégration des deux 8520 et de "glue logic" (circuits électroniques spécifiques entre d'autres composants) aléatoire dans un seul boîtier. Il est prévu que les modules 8520 résultants puissent être utilisés comme macros pour la combinaison avec d'autres fonctions et "glue logic" qui pourraient être nécessaires dans une implémentation donnée.
Phase 1
La phase 1 vise à fournir une implémentation CMOS d'un jeu de puces équivalent au "AA". destiné à être utilisé dans des systèmes d'entrée et de milieu de gamme qui seront commercialisés dans 18 à 24 mois. La technologie de base est conçue pour être modulaire et peut être reconditionnée sous plusieurs formes au cours de sa durée de vie effective.
Deux tâches principales ont été définies, l'une pour la conception LSI, l'autre dans le domaine du développement LSI, la dernière pouvant être réalisée par les systèmes avec l'aide de la conception LSI.
Veuillez noter que le cloisonnement entre les deux puces reste parallèle à ce qui existe aujourd'hui - il n'y a pas de fonctions de processeur ou de colle système incluses dans la puce ADP et pas de fonctions de "bus de puce" incluses dans la puce combinée d'entrées/sorties.
Tâche 1 - Puce ADP (Agnus, Denise, Paula) à 144 broches
La conception Alice/Agnus à 100 broches définie dans la phase 0 est combinée avec la puce Paula améliorée et la puce Lisa actuelle (Denise AA) pour fournir une puce unique qui met en oeuvre la fonctionnalité "Amiga". La conception de base comprend un CLOT 256x19 bits avec des sorties ROB analogiques et des sprites 32 bits. Des variations d'agencement basées sur la même conception modulaire pourraient fournir un CLOT 256x25 bits avec des DAC internes ou externes et des sprites 64 bits, au détriment de la taille des matrices et/ou du nombre de broches. La fonction Paula comprendrait l'audio 16 bits avec le CD-DAC sériel externe décrit ci-dessus, la gestion du lecteur de disquette haute densité serait optionnelle.
Tâche 2 - Puce combinée 8520/Glue/Gayle à 144/160 broches
L'implémentation du réseau de portes 8520 décrite ci-dessus combine les fonctions de contrôle du système "Gayle" et la "glue logic" aléatoire. Si la technologie du réseau de portes le permet, l'horloge en temps réel et la fonction RS232 peuvent être incluses. La conception est entièrement modulaire, de sorte que les exigences des différents systèmes peuvent être satisfaites ou qu'un partitionnement différent peut être utilisé si un réseau de portes à nombre élevé de broches n'est pas rentable.
Phase 2
La phase 2 est destinée à compléter les extensions de l'architecture et les améliorations de performance nécessaires pour maintenir la position concurrentielle sur le marché des systèmes basés sur le matériel Amiga. Les tâches/caractéristiques ne sont pas entièrement définies à ce stade, mais elles devraient l'être dans le cadre de la composante d'architecture du travail de la phase 1.
Point 1 - Amélioration des capacités d'affichage
Il s'agit essentiellement de l'ajout de pixels chunky de 4/8 bits, d'un mode "Couleurs vraies" (True Color) de 16/24 bits et d'un remplacement du "HAM" impliquant une modalité de calcul/décompression à la volée.
Point 2 - Amélioration des performances du Blitter
La fonction actuelle du Blitter d'Agnus est améliorée pour tirer efficacement parti de la largeur de bande accrue (32/64 bits) fournie par l'architecture AA. Cela peut se faire soit en augmentant la largeur des chemins de données du Blitter, soit en exécutant plusieurs cycles de Blitter de 16 bits dans le cycle de mémoire de base.
Point 3 - Gestion lecteur de disquette haute densité / audio 16 bits
Si ces fonctions n'ont pas été incluses dans l'une ou l'autre des deux phases précédentes, elles sont incluses dans cette phase.
Résumé
La répartition proposée présente des avantages très concrets. Tout d'abord, le développement LSI est responsable d'une seule conception de puce personnalisée. Bien qu'il y ait une certaine douleur associée à "une seule grosse puce", cela concentre toutes les ressources sur une seule entité et les problèmes associés à la coordination de la conception, de la mise en oeuvre, du développement des tests et du débogage de N-puces sont évités. Deuxièmement, les domaines de préoccupation/responsabilité pour la conception LSI et la conception de systèmes sont clairement délimités. Les concepteurs de LSI n'ont pas à se préoccuper de questions de conception de systèmes non pertinentes, les concepteurs de systèmes disposent du composant d'interface du système sous une forme plastique qui ne nécessite pas l'intervention de la conception de LSI pour la personnalisation du système."
Conclusion
L'histoire de l'Amiga est jonchée de bonnes réalisations mais, malheureusement, aussi de choses potentiellement superbes qui n'ont jamais été menées à leur terme. L'AA+ en est une. Ce jeu de composants aurait permis de supprimer la plupart des faiblesses de l'AGA. En 1992/1993, le secteur le plus porteur sur Amiga restait le jeu vidéo. Le gain de performance apporté par l'AA+ aurait été appréciable pour définitivement tourner la page de l'OCS/ECS et contenter les développeurs et les utilisateurs des nouveaux Amiga. Par contre, la compatibilité entre AA+ et AAA n'aurait peut-être pas été totale et cela aurait posé un problème. Une probable scission des développements aurait émergée : applications professionnelles pour l'AAA et jeux pour l'AA+.
Pour l'anecdote, le nom "AA+" fut repris par Mick Tinker de la société Access Innovations pour son jeu de composants qui aurait dû équiper le BoXeR, en 1998. Plus d'information sur cette page.
Liens
- Entrevue avec Lewis Eggebrecht.
- Intervention de Lewis Eggebrecht au World Of Commodore 92 à Toronto.
- Le jeu de composants AAA.
- La feuille de route de l'AA+.
- Specifications_for_Upgraded_AA_AA+_based_Systems.pdf.
- Quelques pages du document précédent, daté du 14 mai 1992 : 1, 2.
|
Nom : AA+. Constructeur : Commodore. Genre : projet de jeu de composants. Date : 1993. Prix : NC. |
|
|