Un espoir pour Checkered Flag - Page 3

SCPCD (./57) :

Artemis (./54) :

DEATH (./53) :
Jaguar était prévu pour tourner avec un 68030 (J'ai passé la doc ici il me semble il y a quelques temps). Avec un bus d'adresse de 32bit, une fréquence de 40MHz, 32Mo d'espace ROM, 64Mo d'espace DRAM et 16Mo d'espace SRAM.

Ah ben ça aurait réconcilié pas mal de développeur avec ces specs

Je sais pas d'où viennent ces specs, mais c'est clairement pas réaliste pour les début 90. (sans exploser le prix de vente, vu que c'est au dessus des specs du Falcon et en partie du TT)

Et y a absolument rien qui correspond à ces specs dans les netlist.

Ce sont les specs officiels de 1992 du chipset Jaguar venant de Flare 2 "en personne" avant qu'Atari ne mette les pieds dans le plats

C'est le plus ancien "Jaguar Technical Reference Manual" que je connaisse. Je l'ai posté ici il mes semble il y a "quelques temps".

Encore une fois, il n'est pas siglé "Atari" mais "Flare II", il est daté de juin 1992 (le 12 et 15 exactement) et il fait 90 pages

Brunni (./60) :
Techniquement ça veut dire "être en échec" (au jeu de go). C'est … très bien choisi non ?

Oui je sais, mais c'est pas comme aux échecs ? (si tu dis "échec" c'est que c'est ton adversaire qui est en difficulté).

Tu as la doc quelque part ?
j'ai cherché et pas retrouvé.

Zerosquare (./62) :

Brunni (./60) :
Techniquement ça veut dire "être en échec" (au jeu de go). C'est … très bien choisi non ?

Oui je sais, mais c'est pas comme aux échecs ? (si tu dis "échec" c'est que c'est ton adversaire qui est en difficulté).

Vu que Atari était en difficulté, ca colle bien.
Sinon, il existe un jeu d'échec Japonais, le Shogi je crois bien.

Zerosquare (./62) :

Brunni (./60) :
Techniquement ça veut dire "être en échec" (au jeu de go). C'est … très bien choisi non ?

Oui je sais, mais c'est pas comme aux échecs ? (si tu dis "échec" c'est que c'est ton adversaire qui est en difficulté).

Oui, comme au jeu de la barbichette, quand tu dis "Atari", c'est que l'autre a perdu.

SCPCD (./63) :
Tu as la doc quelque part ?
j'ai cherché et pas retrouvé.

Fichier joint : jagtech1.pdf

Oui ok. Bus compatible 68030, ca ne veux pas dire “on va mette un 68030” et les autres chiffre je ne les ai pas trouvé dans la doc mais si c’est du meme gabari, c’est juste le max supporte par ce qui est prévu de mettre.

Si il n’avait prévu que le 68030, pourquoi ils parlent de l’endianess qui peux être changé et que ça pourrais donc supporter le x86? Et ils font mention que si le CPU n’est pas compatible avec le bit 68030, un simple pal suffit à faire la corrspondznce.

Pourquoi le choix du bus 68030? Probalement pour être pérenne dans le temps et pas de trouver avec un truc qui marcherais mal avec un CPU plus recent, est c’est probablement ce qu’ils pensais qui gagnerais la bataille plutôt que le x86.

Bref des visionnaires.

Oui, je pense aussi que la doc décrit davantage les capacités prévues du chipset Jaguar (qui était prévu pour être utilisé aussi dans des ordinateurs avant qu'Atari abandonne ce marché - c'est d'ailleurs pour cela qu'ils parlent du Falcon à un endroit, et qu'il y a un mode compatible x86) que celui de la console du même nom. Comme le dit SCPCD, une console de jeux avec des spécs pareilles aurait été beaucoup trop chère à l'époque.

Cette doc est intéressante quand même, par exemple dedans on trouve le code qui a servi à générer les tables de conversion CRY/RGB, qui n'y est plus dans les éditions plus récentes.

ok, pas contre je suis quand même étonné qu'il y ai un gap aussi énorme entre mi 92 et novembre 93 (commercialisation de la jag)
car il y a forcement eu des jag mis à dispo pour du dev au moins début 93 et donc des puces TOM/Jerry déjà produite fin 92.
et avoir 2 dev différents ("produit" jaguar de FlareII, et la "console" jaguar d'Atari) me semble très lourd vu que les netlists disponibles ne semble pas avoir de traces de cette spécification :/

Je me suis fait la même réflexion. Peut-être que la doc avait du retard sur les évolutions du projet.

Je pense ne pas avoir été assez clair, il s'agit là du projet Jaguar de Flare II avant la reprise "totale" Atari. C'est probablement une des dernières, sinon la dernière documentation du projet chipset (et non console) Jaguar où en était Flare II avant qu'Atari ne reprenne le contrôle complet et demande des coupes franches dans les coûts obligeant à faire des modifs à la va vite avec des bugs à la pelle et une réduction drastique des performances.

Pour ceux qui n'ont pas suivie toute l'histoire de Flare 2 (anciennement Flare Technology avant le "rachat" par Atari), la Jaguar (ou le chipset jaguar) n'est en fait que l'aboutissement final des années de développement de Flare. Si vous regardez les schémas, les specs, les documentations des différents projets de Flare (que ce soit la Panther, le Konix multisystem, ou encore le Flare one) il n'y a qu'une seule réflexion qui vient à l'esprit : "mais ! c'est la même chose, on retrouve tous les éléments de la Jaguar dans toutes ces machines !". Mêmes idées, même structure, même électronique, même registre !

La doc en question est donc plus que probablement celle de l'ASIC qui existait à ce moment au moins en prototype avec production à quelques exemplaires.

Pour répondre à Godzil, l'interface CPU de cette version est celle du 68030 tout comme celle de la console Jaguar est celle du 68000, ça veut tout simplement dire que nativement TOM est capable de "dialoguer" avec un 68030 (ou un 68000 pour LA Jaguar) sans absolument aucune logique externe supplémentaire. Mais, comme en électronique rien n'est quasi impossible dans ce domaine, il est relativement facile d'adapter cette interface avec un peu de logique pour l'adapter à l'importe qu'elle autre processeur. Facilité en plus par le fait qu'ils ont inclus nativement quelques options pour faciliter cette adaptation (choix du bus de données sur 16 ou 32 bit nativement, choix du boutisme (endianness) nativement...

D'ailleurs, le plus bel exemple est toute simplement la CoJag, qui bien que comprenant TOM et Jerry, fonctionne quand même assez différemment, avec des processeurs différents, et donc tout un tas de logique supplémentaire le tout avec un coût "nettement" à la hausse

Et pour ce qui est des traces dans les Netlist ou les docs, je dirais au contraire qu'il y en a partout.

Avec des registres ou des fonctionnalités qui n'ont aucun intérêt dans la Jaguar, mais qui sont quand même là.
Des bugs à la pelle qui démontre bien la précipitation avec laquelle ils ont fait des modifications "simple" mais permettant de rapidement sortir un produit à moindre coût.
Le DSP qui devait bien évidement fonctionner en 32bit mais comme utilisant la même interface CPU c'est retrouvé bridé avec des solutions bancales introduisant une multitude incroyable de bug à ce niveau.

J'ai d'ailleurs une théorie là dessus notamment avec le bug du GPU in MAIN. On sait que le bug est dû à une puissance insuffisante des transistors de précharge (ou un truc du genre je ne me souviens plus exactement). Je pense que dans la précipitation ils ont tout simplement oubliés de refaire les calculs pour le passage de 40MHz à 26,6 MHz.... Et si c'est le cas ce n'est certainement pas le seul endroit où cette erreur doit poser problème et sortir certains circuits logique des limites de la tolérance acceptable.

La doc est brandé Flare II, cad deja sous l'autorité d'Atari.

JAGUAR has been designed to work with any 16 or 32 bit microprocessor with (up to) 32 address lines. The interface is based ont he 68030 but most microprocessors can be attached using a PAL to synthesise those control signal with differ

The width of the microprocessor is determined during reset by a pull-up / pull-down resistor.

Il y a pas mal de pin marqué "VCC" et "GND" sur TOM et JERRY, rien ne dit que ce sont vraiment des masses ou VCC, ca peux etre des pull-up/down, mais ca peux aussi etre dans le chip directement connecté, SCPCD peux répondre a ca plus facilement vu qu'il connait tres bien la net list.

Comme deja dit par Zero, la doc par du Falcon, le Falcon a un 68030 ce n'est pas pour rien qu'ils ont choisi cet bus, sachant que le 68000 et le 68030 ont en gros le meme type de bus, la seul difference sont la taille de A et D, a part ca, on retrouve SIZ0 & SIZ1, FC0-FC2 etc.. Si il y a des differences elle sont triviales et ne demande pas forcement de la logique en plus.

Et tu crois sérieusement qu'entre la mise en prod & co (faire un ASIC qui marche ne prends pas 2 semaines) Atari a réussi a faire la Jaguar entre Juin 1992 et Novembre 1993? Tu es optimiste.
Meme si flare avait fait la majorité du dev, 6 mois pour produire physicquement un ASIC me semble le minimum, mais il faut aussi faire le soft qui va autour, debugger celui-ci, etc... plus la mis en production pour la commercialisation.

1 an c'est super court, meme avec 90% du boulot fait pour l'ASIC.


Tiens je regardais la schématique au propre de Zero, seul TOM est 64bit? Jerry n'a qu'un bus de donnée 32bit
C'est vraiment pour faire "on a 64bit" dans un coin tout ca :/

DEATH (./72) :
On sait que le bug est dû à une puissance insuffisante des transistors de précharge (ou un truc du genre je ne me souviens plus exactement).

Ah ? Pas souvenir d'avoir lu ça.

DEATH (./72) :
Je pense que dans la précipitation ils ont tout simplement oubliés de refaire les calculs pour le passage de 40MHz à 26,6 MHz....

Je vois pas quels calculs il y aurait à refaire. Un circuit qui fonctionne à une fréquence d'horloge va fonctionner tout aussi bien à une fréquence plus basse (il y a quelques exceptions mais je ne pense pas que ça s'applique au chipset Jaguar). S'ils sont passés de 40 MHz à 26.6 MHz, c'est probablement parce qu'ils avaient été trop optimistes initialement sur le calcul des timings, ou parce que le pourcentage de circuits produits effectivement capables d'atteindre 40 MHz était trop bas.

Godzil (./73) :
Et tu crois sérieusement qu'entre la mise en prod & co (faire un ASIC qui marche ne prends pas 2 semaines) Atari a réussi a faire la Jaguar entre Juin 1992 et Novembre 1993? Tu es optimiste.
Meme si flare avait fait la majorité du dev, 6 mois pour produire physicquement un ASIC me semble le minimum, mais il faut aussi faire le soft qui va autour, debugger celui-ci, etc... plus la mis en production pour la commercialisation.

1 an c'est super court, meme avec 90% du boulot fait pour l'ASIC.

Je suis d'accord.

Godzil (./73) :
Tiens je regardais la schématique au propre de Zero, seul TOM est 64bit? Jerry n'a qu'un bus de donnée 32bit
C'est vraiment pour faire "on a 64bit" dans un coin tout ca :/

Pas vraiment. Tous les blocs qui utilisent beaucoup de bande passante (contrôleur mémoire, object processor, blitter, GPU) sont en 64 bits et regroupés dans Tom. Jerry accueille ceux qui n'ont en pas besoin d'autant (DSP, I²S, UART, I/Os pour les manettes), et pour lesquels il n'y a pas vraiment besoin d'un bus 64 bits. C'est un peu la même philosophie que le découpage north bridge / south bridge des cartes mères. Je pense qu'avoir eu un bus 64 bits sur Jerry aurait été un luxe trop coûteux à l'époque.

Et j'ai oublié d'ajouter que c'était il y a 30 ans. Les moyens de production de l'époque ne sont pas ceux d'aujourd'hui.

J'ai eu l'occasion de bosser pour une société de fabrication d'appareil de haute technicité professionnel (travaillant notamment pour EDF, la SNCF....) , les prototypes peuvent s'enchainer très rapidement en quelques semaines, jours même. Ces sociétés peuvent posséder leur propre ligne d'assemblage de PCB en CMS et pour Atari ce n'était certainement pas un problème non plus. Quand aux ASIC ils était en relation direct avec le fondeur, il ne fallait pas des semaines pour sortir un prototype. Ne prenez pas les années 70-80-90 pour l'âge de pierre, vous seriez surpris de ce qu'il était possible de faire à cet époque et rapidement. D'ailleurs justement, à l'époque ça défilait de partout dans ce domaine.
je parle de prototype, pas de produit final. Et quoiqu'il en soit, oui, la Jaguar s'est littéralement fait dans la précipitation et de toute façon la mise à disposition d'un produit final peut prendre bien moins de temps que vous ne le croyez. Souvenez vous, ils ne partent jamais de zéro.

Quand à Flare 2 Atari en était majoritaire, mais pas propriétaire à 100%

Pour le bug du GPU in MAIN dû à un défaut de puissance, c'est Torlus qui l'a découvert en épluchant les Netlist, il faudrait retrouver où il en a parlé.

Non, un circuit électronique ou logique donné pour une fréquence ne va pas forcément fonctionner correctement à une fréquence inférieur. Notamment les impédances et d'autres facteurs peuvent rendre le circuit instable. Pour les circuits de type dynamique il y a clairement un limite inférieur en deça de laquelle le fonctionnement n'est pas garantie, et cette limite est parfois pourtant élevée. Rare sont d'ailleurs les processeurs pouvant fonctionner en mode statique (il existe une version du 68000 statique qui peut "fonctionner" à.... 0Hz). Un circuit, un processeur dynamique en deça de sa fréquence minimum , les portes logique, les transistors, les registres, vont perdre leur valeur et va devenir instable voir planter. Donc oui, ça se calcul, notamment les transistors de précharge qui commandent les grandes lignes, comme les bus d'adresses, de données etc.

Les 26,6MHz c'est avant tout une question de coût, il fallait trouver un compromis entre vitesse et compatibilité avec les synchro vidéo tv. Dans la Jaguar, il n'y a qu'un seul quartz (bon en fait 2) et il fallait pouvoir en tirer toutes les fréquences nécessaire à moindre coût.

Pour finir, le bus de donnée du DSP est 32bit seulement en interne, c'est amusant car tous les diagrammes de l'époque divulgués au grand publique étaient mensonger à ce sujet
Et comme je l'ai dis, les multiples bidouilles pour passer le DSP de 32 à 16bit en externes sont tellement mal foutus et tellement bugué, vous croyez qu'ils ont mis 1 an pour pondre ça ? Sérieux...

C'est sympa de nous expliquer notre métier

Ha oui les portos sont fait en l'espace de jours?

Je pense etre plutot bien placé pour voir le temps qu'il faut pour faire un tape out en partant de bloc testé pour faire un SoC moderne, c'est des MOIS de travail, pas des jours, et ca n'inclue que des tests supperficiels. Il faut encore en ajouter quand on tests plus en profondeurs.

Je vais prendre en exemple publique: le Propeller 2. Il a fallu quasiment un an a Parallax entre les premiers prototype hardware reçu et les version actuellement vendu.

Quand a baisser la fréquence, comment dire. L'impedance empêche de baisser la fréquence? C'est plutot l'inverse a vrai dire, plus la fréquence est basse moins l'impedance a d'effet. Hint: l'impedance n'a aucun effet sur du courant continue.

Et l'explication sur Static vs Dynamique, tu serait surpris par le nombre de CPU qui sont statiques, mais meme la, l'argument est foireux. le temps maximum entre deux rafraichissement pour de la DRAM est suivant la temperature entre 32ms et 64ms, le point de changement étant a 85°C, ce n'est pas une temperature de fonctionnement normal pour la majorité des appareils travaillant en dessous des 200MHz.

Bref, un cycle de 64ms c'est 15 hertz, 32ms c'est 32 herts. Autant dire que passer de 40Mhz a 25-26Mhz n'a absolument AUCUN impact sur ce genre de détail.

J'ai bossé sur des produits qui on été fait en ~1ans, mais, et c'est le point super important que avec des pieces sur etageres.


Au passage faire des ASIC coutre affreusement cher de nos jour, et c'était encore pire à l'époque, c'est aussi une des raisons pourquoi on prends son temps et évite de rusher ce genre de choses, parce que chaque prototype non fonctionnel est quasiment de la perte sèche, tout le monde n'est pas space-x avec une chier de fric a faire partir en fumé.


Tiens et pour rigoler j'ai regardé les sortie sur la jag, il y a 4 jeux qu'on peux considerer faire partit du lancement:

- Cybermorph (nov 93)
- Trevor McFur in the Crescent Galaxy (nov 93)
- Evolution: Dino Dudes (dec 93)
- Raiden (dec 93)

Donc ces quatre jeux on été fait en moins de 6 mois suivant ta choronologie?


Au passage je cite wikipedia:

In 1989 Martin Brennan was contracted by Atari Corp. to complete and implement the chip design of the unreleased Atari Panther.

Flare a commencé a travailler avec Atari des 1989, soit 4 ans avant la sortie de la Jaguar, sachant qu'il travaillaient sur Panther et Jagar en meme temps, la timeline est bien plus claire et réaliste. Et Panthere et Jaguar on toujours été fait POUR atari, pour les specs Atari.

Quand au rush, bug & co, on va prendre un des bugs hardware les plus connus de l'histoire, le bug FDIV des Pentium.
Intel c'est des centaines, pardon des milliers d'ingénieurs, largement pus de cash qu'Atari, et pourtant leur flagship c'est retrouvé avec un bug grossier. Et il y a pas mal d'autre bugs dans les CPU fait a une époque ou la complexité n'était pas ce qu'elle est maintenant ou les bugs sont tres difficile a trouver et demande des exploits complexe pour etre utilisé.

Exemple les plus connus:
FDIV:
F00F:

Zero > Ouais, surtout quand on a fait microélectronique en formation

DEATH >
Autant fabriquer PCB et souder les composants c'est rapide, autant un ASIC ça met plusieurs semaines/mois pour être produit, surtout un truc aussi complexe qu'un CPU.
De plus, on sais aussi qu'il y a eu au moins 2 versions et donc des tests et correction de bugs entre les versions. Ça à du prendre minimum 4 à 6 mois (et encore je suis gentil vu que TOM est un ASIC très compliqué pour 92).
Il y a aussi 2 fournisseurs différents (Motorola et Toshiba) même si ça à pu être fait en //, il est probable qu'il y ai un déphasage entre les fournisseurs.


Dans les netlists ont vois que :
- Certains sont datés de 90, les correctifs sont tagués 91 ou 92 avec un commentaires, mais aucun commentaire n'indique de profondes réécriture ou qui indiquerais qu'il y ai eu un changement de direction sur l'architecture.
- Tout est exclusivement conçu pour du 24-bit d'adresses :
Changer 32 => 24 n'est pas triviale vu que le décodage d’adresse est fait en dure à la main en NAND bit à bit (c'est d'ailleurs pour ça que quelques rare registres ne sont pas lu et écris aux mêmes adresses causé par quelques changement d'adresse de dernière minutes pour regrouper les registres)
Le plan d'adressage entre la doc flareII-92 et le plan d'adressage dans les netlist étant totalement différents : ça aurait probablement du prendre beaucoup de temps pour tout changer sans tout casser.
Surtout qu'en 92 il y avait déjà les kits de dev Felix et Rapier.


Pour le GPU en Main, ce n'est pas dû à un défaut de puissance mais à un bug de remplissage du prefetch car le latch n'est pas fait à tout les coups au bon moment sur un jump quand les données viennent de la mémoire externe (et ça concerne uniquement les jr/jump : sinon on peut exécuter du code en main, même si je déconseille vu la perte évidente de perf ainsi que le temps aléatoire d'exécution des instructions)


Le DSP a un bus 32-bit interne et externe mais n'est utilisé qu'en 16-bit sur Jag car TOM étant le contrôleur mémoire, il doit présenter les data en fonction du CPU externe. (je ne sais pas comment c'est fait sur les cojag, je n'ai pas retrouvé de schématic)
Par contre le mode 32-bit est effectivement buggé. Le bug a probablement été découvert trop tard et comme il n’impacte pas la Jaguar il n'a pas été corrigé. (bien que avoir une nouvelle révision du DSP n'aurait pas été un luxe, ça aurait permis de corriger le bug UART entre autres )

Zerosquare (./77) :
C'est sympa de nous expliquer notre métier

Je sais bien que certains ici travaillent dans des domaines similaires.

Je suis de formation électronicien, programmeur dans ma jeunesse, dans l'informatique depuis mes 6 ans au moins, ingénieur et technicien en informatique, admin système et réseau etc etc.

Assez amusant d'ailleurs la société dont j'ai parlé m'avait proposer de postuler comme électronicien

Pour info il s'agissait de la société CATU, groupe SICAM, qui fabrique des produits de protection électrique haute/très haute tension pour l'international et le national


Atari, comme tant d'autres à l'époque pondaient des prototypes à la pelle, des modifications à la pelle et ce à quelques mois ou semaines d'intervalles. On ne compte plus les nombres hallucinant de version de cartes mère, d' ASIC propriétaire , de patch de dernière secondes (oui, carrément sur la chaine de production) chez Atari. Même chose chez Nintendo par exemple, la différence c'est qu'ils sortaient des produit fini, et fiables, pas des trucs parfois rafistolés avec des bouts de ficelles. Et ils ne leur fallait donc pas des mois pour pondre une nouvelle carte, un nouvel ASIC... Quelques années auparavant des machines de toute sortes, ordinateur ou consoles, sortaient quasiment "tous les jours " de multiples fabricants conçu et fabriqué en à peine quelques mois, quelques semaines pour certains. L'exception à sans doute été la Jaguar dont il existe très peu de versions différentes (mais certaines avec des patch de dernière minute), mais on n'a pas tout l'historique non plus. Les documents qui ont été récupérés ne représentent probablement que quelques petits % des documents de travaille existant.
Mais par contre une chose est certaines, les prémisses de la Jaguar existaient depuis que Flare à existé. Les quelques documentations techniques et de travail disponibles le montre clairement, ce n'est que la continuité de leur tout premier projet et donc bien avant leur alliance avec Atari.

Quand aux jeux cités.... ça pour avoir été pondu en 4ème vitesse c'est peu de le dire.
Déjà pour la plupart, et au moins pour Cybermorph, ce sont des projet Panther (et peut être même avant), pas fini, et devant servir (pour cybermorph et trevor au moins) de démo technique pour le CES et autres show de présentation

les "exploits" folklorique de la conception, démonstration, sortie de la Jaguar et de tout ce qui tourne autour ne manque pourtant pas (interview, reportage, article, documentation technique...)

Tu ne prototype pas un moule en plastique de la même manière qu'une puce électronique. Oui tu peux faire rapidement des changesments sur le moule d'une piece plastique,et produire rapidement des protos.

La conception d'ASIC, surtout a l'epoque n'avais pas les FPGA a $40K qu'on a de nos jours qui permettent de prototyper "rapidement", et pourtant de nos jours meme avec tout ca, il faut des mois pour sortir une puce en phase finale.

Et tu ne fait pas des retouche de derniere minutes sur un ASIC sans avoir plusieurs semaines de tests avant, la production de puce est vraiment un mode a part, ca n'a rien a voir avec la fab de PCB et utilisation de composant sur étagères.

Quand a tous ces ordinateurs pondus en quelque semaines, tu as des exemple? vu le nombre que tu sous entends, ca ne devrais pas etre dur de donner des exemple vu qu'il doit y en avoir beaucoup!

quand je vous lis, j'ai l'impression de voir les mêmes commentaires qu'on peut entendre quand on parle de la période de la conquête de la Lune "c'est impossible, comment on t il pu faire à l'époque alors qu'aujourd'hui on a du mal" etc.

Comme je l'ai dis, c'est vraiment croire que les années 70-90 c'était l'âge de pierre, grosse erreur alors que c'était le plein essor de l'informatique grand publique, mais bon....

Pas besoin de faire graver un ASIC ou un SOC à chaque modif, les prototypes sont là pour ça, pas besoin de FPGA n'ont plus, vous croyez qu'ils faisaient comment à l'époque ? Au pif ? Généralement à base de composants discrets, de puce logique, programmable ou pas (fallait voir les énormes cartes prototypes bourrées de composants) . Mais oui, au vu de toutes les versions de puces spécialisées existantes, ils ont également pondu pas mal de versions plus ou moins définitive. Il n'y a qu'à voir le nombre de versions différentes d'ASIC chez Atari depuis qu'ils existent. Même en ne prenant qu'une seul gamme, les ST par exemple. Même chose chez Nintendo et la SNES, il y a un nombre incroyable de version de leur puces spécialisés, et elles ne sont pas sortie plusieurs années les une après les autres mais parfois à quelques mois d'intervalles, sans compter les révisions de cartes.
Et on ne peut pas changer non plus aussi facilement le moule d'une pièce en plastique, là pour le coup à l'époque les imprimante 3D ou les autres solutions de moulage à moindre coup ça n'existaient pas. Je ne parierai pas sur le fait que la modification/fabrication des moules à injection coutait moins cher. Un moule à injection à l'époque c'était plusieurs milliers voir 10aine de milliers de $, et encore aujourd'hui ce n'est pas donnée (sauf qu'aujourd'hui il existe d'autre solution, même en injection)

Pour les ordinateurs sortis en quelques semaines (et je parle de ceux partis de "zéro", parce que sinon aujourd'hui, c'est pire), simple, pendant la période du début de l'informatique grand publique qui a commencé fin 70, des 10aine de sociétés ce sont lancés dans la fabrication de consoles et d'ordinateurs partout à travers les monde, des 100aine de modèles, conçus et vendu en quelques semaine. Après, clairement ce n'était pas tous des grandes réussite, ceci dit Atari a bien réussi en faisant un peu n'importe quoi aussi.
Je ne pourrai pas trop dire pour d'autres fabricants (à part la SNES aussi), mais les Atari (arcade, consoles, ordinateurs) c'était quoi... 70-80% d'ASIC minimum par machine (bah oui, à l'époque il n'existait pas de composants complexes spécialisés à tout faire)
Je vous invite à regarder l'intérieur de n'importe quel Atari et de compter le nombre de puces de fabrication Atari (ne regardez pas dans un TT, c'est la crise cardiaque assuré) après, allez voir le nombre de version de chacune de ces puces qui existent.
Sinon vous pouvez aussi allez jeter un œil aux quelques documents qui ont été récupérés et qui font état des multitudes de versions des différentes composants créé (blitter, shifter, glue, mmu, gst-mcu, composants obscures dont on ne connait pas la fonction, et j'en passe)

A noter que je pourrais vous sortir le même type de documents de la société dont je vous parlais mais en *10000 vu que j'avais accès à TOUS les documents qui ont existé avec les trouzmille versions de tel ou tel composants.

Devinette, c'est quoi ça ?



Une des cartes de prototypage du Shifter

Ah ben flute ça ne passe pas

Là le contrôleur DMA ACSI

Plop !

Pourriez-vous me dire ce qu'est un ASIC ? Quant aux Netlists, je me suis fait une petite idée mais si vous aviez quelques précisions je suis preneuse également^^

un ASIC est un circuit intégré spécialisé.
Les netlists, ce sont les "codes sources" du circuit logique pour créer l'ASIC.

Chevels (./87) :
Pourriez-vous me dire ce qu'est un ASIC ?

C'est un truc qui pue des pieds

Sinon on sait quand la PS1 a été développée ? Quand ils ont décidé les specs et ont fait quelque chose avec ? On dit que la Jaguar c'était 1990 ou 1991 je me rappelle plus, et à cette époque on n'avait pas de bonne visibilité sur ce que serait le futur de la 3D. Pour ça que tout ce qui est sorti dans cette période faisait plus ou moins (mais surtout moins) bien. 3DO était bien, avec son GPU dédié certes à fonction fixe, ils avaient juste pas vu le besoin d'un processeur vraiment bon pour les mondes dynamiques et avec des interactions en 3D, des moteurs de collisions corrects, qui définiraient le futur des jeux de plate-forme.

Je ne sais pas quand Sony a eu la vision, mais c'est vraiment un truc de génie. Juste la bonne combinaison. Un processeur son incroyable (quand c'était toujours un argument de vente important), appairé au CD qui n'était pas suffisant en soi si les jeux voulaient faire du streaming pour compenser la mémoire qui ne pouvait pas être suffisante à cette époque. Et y coller 512 ko (!) de DRAM qui coûtait un bras. Un GPU à fonction dédiée type OpenGL (ce qui était risqué), un CPU suffisamment bon avec un accès direct au framebuffer pour les effets supplémentaires -- là où tous les autres au début des années 90 avaient conçu le GPU comme un de ces nouveaux processeurs RISC rapides, programmables et adaptables à ce vers quoi le marché allait supposément évoluer, le problème c'est qu'ils ne paraissaient rapides qu'à l'oeil non initié par rapport à un GPU dédié comme celui de Sony. Bon courage pour faire de l'alpha blending, du texture mapping, du T&L sur autant de polygones, etc. avec un CPU. Fallait juste voir ce à quoi autant de polygones pourrait servir, que c'était VRAIMENT important. Sony ont sacrifié la qualité au maximum d'ailleurs (pas de Z buffer, pas de correction de perspective, nécessitant de découper en bien plus de polygones que nécessaires). C'est vraiment un choix opinioné. Le CPU n'était que single core et pas si puissant (même pas de FPU). L'allocation de mémoire (c'est fou comme tous les autres se sont plantés à ce niveau), n'avoir que 1 Mo ça aurait tellement pu leur péter à la gueule. Après bon faut aussi voir que les développeurs ont fait du mieux qu'ils pouvaient car ils aimaient la plate-forme, et ça ça fait beaucoup

Chevels (./87) :
Plop !

Pourriez-vous me dire ce qu'est un ASIC ? Quant aux Netlists, je me suis fait une petite idée mais si vous aviez quelques précisions je suis preneuse également^^

Allez, on va étaler la confiture

Comme l'a dit SPCD un ASIC est un circuit spécialisé, plus précisément qui effectuent des fonctions qui n'existent pas dans les circuits vendu en série et/ou qui demanderai beaucoup d'autres petits circuits pour réaliser ces fonctions.
Typiquement, ce n'est finalement qu'un ensemble "très" complexe de portes logique réunis sur une puce compact. Avant l'apparition des ASIC, les circuits spécialisés complexe étaient donc réalisés avec des circuits logiques simple, programmables ou non, fabriqués en série par divers fabricants.
Les premiers ordinateurs ou machines d'arcades de ce type utilisaient de grande cartes avec plein plein de ces circuits, coutaient très cher, et étaient relativement limités en vitesse. Quand la technologie a évoluée et que les coûts de gravure ont baissés début 70 il est devenu rentable de faire graver l'équivalent de ces grandes cartes sur une seule puce. Le prix de conception d'une puce spécialisée est certes plus élevé, mais la fabrication en masse rattrape largement les coûts d'un équivalent en circuits logiques discrets, permet une miniaturisation extrêmement importante et des vitesses de fonctionnement bien plus élevés.
Le cartes de prototypage, avant leur passage en ASIC étaient, et sont encore souvent réalisées avec des circuits logiques discrets afin de développer, tester le fonctionnement avant la gravure du circuit final.
Les photos que j'ai posté représentent les cartes de prototypage de certains circuits de l'Atari ST. La première étant celle du Shifter, le circuit logique vidéo des ST. C'est une assez grosses carte alors que sont équivalent ASIC est plus petit qu'un 68000.
Le 1er prototype des ST était d'ailleurs composé de 5 grosses cartes de ce genre. De mémoire les Atari ST comptent environ 5-6 ASIC (la ROM pouvant d'ailleurs également être considéré comme un ASIC)
Sur la Jaguar ce sont plutôt des SOC, bon, c'est juste des ASIC un peu plus complexes et comprenant un microprocesseur, le terme est différent mais le principe reste le même : concevoir un circuit spécialisé qui n'existe pas en série.

De nos jours on emploie plutôt des gros circuits logiques programmables pour faire les prototypes (voir même le produit final).

Quand au Netlist, avant pour concevoir un gros circuit en vu d'en faire un ASIC ou un SOC, tout était fait "à la main". A base de schémas complexes, de photogravures et j'en passe, représentants par exemple les portes logiques, comment elles sont agencées etc. On a alors inventé les Netlist, qui sont simplement des fichiers qui représentent un circuit plus ou moins complexe et qui sont conçu à l'aide d'un langage qui décrit les fonctionnalités du circuit. Un peu comme un langage de programmation, mais pour concevoir un circuit électronique. C'est bien plus simple et rapide pour concevoir les très gros circuits spécialisés (voir même les petits plutôt que de se taper des tables logiques de 3km de long pour une simple PAL ?). ils sont utilisés pour la réalisation final de la puce à graver. Ils peuvent également être utilisés dans un simulateur pour... simuler le fonctionnement du circuit.
Bon après j'ai un peu simplifié, parce qu'entre netlist et langage de programmation matériel, la frontière n'est pas grande. Suivant le point de vue, c'est un peu la même chose... On peut passer de l'un à l'autre avec les programmes adéquates, on peut faire de la simulation directement avec les fichiers de programmation etc.
Par exemple les Netlist de la Jaguar de l'époque qui ont été récupérés ont été traduits en langage "moderne" VHDL par Torlus il me semble.