Toutes mes réponses sur les forums
-
Moi aussi, deux messages.
J’ai envoyé ma carte bleu et je n’ai toujours pas reçus les vidéos porno Ataristes !!
J’aurai été voir les flic si je n’avais pas honte et que je n’étais pas déjà recherché.
Dans le compte rendu du lien posté par k1200rs21 on peut lire ceci.
Le rêve d’apporter le chipset AGA à tout les Amiga OCS/ECS va devenir une réalité avec le GOLD3. Souvenez vous comme vous étiez frustrés quand vous étiez jeunes avec votre A500 quand vous ne pouviez pas lancer un jeu AGA alors que votre amis avec un A1200 lui le pouvait. Ce temps sera bientôt révolu.
Donc il semblerait que le core 3 sera dispo pour les vampires V2.
Alors ce n’est pas très clair, il faudrait demander directement sur le forum apollo.
Doesn’t that not contradict the first statement from Gunnar: « the APOLLO HARD-FPU is coming for Vampire4. »
Cela ne contredit il pas la première déclaration de Gunnar ? : « l’APOLLO HARD-FPU arrive pour la Vampire4 ».
Not necessarily. The hard-FPU and everything else fit the v4 FPGA easily but even though these tests are being done on the v2 (a well-known reliable hardware suitable for testing), some features planned for v2 Gold3/Platinum are probably missing or removed in order to make space for the FPU in the v2.Pas nécessairement. La FPU et tout le reste rentrent facilement dans le FPGA de la v4, mais même si ces tests sont effectués sur la v2 (un matériel reconnu et fiable apte à tester), certaines fonctionnalités prévues pour v2 Gold3 / Platinum seront probablement manquantes ou supprimées afin de créer l’espace nécessaire pour le FPU dans la v2.
Also note that Gunnar said that the v4 FPU would do one or even two FLOPS per clock cycle. The results shown above are still below that meaning that there is still work to be done.
Notez également que Gunnar a déclaré que le FPU de la V4 effectuerait un ou même deux FLOPS par cycle d’horloge. Les résultats présentés ci-dessus sont encore inférieurs à cela, ce qui signifient qu’il reste du travail à accomplir.
Voici quelques liens
http://www.zetetique.fr/index.php/dossiers/71-radiesthesie
L’expérience conduite à l’université de Munich entre 1986 et 1988 est sans doute la plus grande expérience de radiesthésie jamais réalisée en terme de nombre de participants et de moyens investis. Les meilleurs sourciers d’Allemagne se sont vus proposer comme expérience la détection d’une quantité d’eau circulant dans un tuyau positionné sous un faux plancher. Dans un premier temps, cinq cent sourciers se présentèrent, approuvèrent le procédé d’expérimentation, et sélectionnèrent quarante-trois d’entre eux pour participer aux épreuves finales. Dans chaque test, un robot portant un tuyau dans lequel une masse d’eau circulait fut positionné aléatoirement sous le plancher. On prit soin de demander à chacun des sourciers d’identifier les zones du plancher où, pour des raisons qui étaient les leurs, il ne pourraient exercer leur art. Les coordonnées correspondantes furent exclues des possibilités de placement du robot par l’ordinateur. [Il est amusant, à ce propos, de noter que l’ensemble des points « inutilisables » indiqués par les sourciers couvraient la quasi-totalité du plancher]. Le sourcier parcourait ensuite la surface afin de donner la position de la masse d’eau déterminée à l’aide de sa baguette, de son pendule ou de tout autre ustensile de son choix. Chaque sourcier effectuait des séries de 5 à 15 essais par session. Après deux ans d’expérimentation et 843 essais effectués, le traitement statistique des résultats obtenus pour ces différents essais montra qu’il n’y avait aucune différence entre la performance des radiesthésistes et une détection effectuée au hasard. Mais les rapporteurs de l’expérience crurent bons de préciser que les séries des 6 meilleurs sourciers donnaient des résultats qui étaient statistiquement significatifs.
Tout le monde cria victoire : les sceptiques, qui mirent en avant l’absence de résultat sur l’ensemble des séries des 43 meilleurs sourciers… et les sourciers qui prétendirent évidemment que sur 43 sourciers, 6 seulement étaient finalement compétents et que la science l’avait montré. Les statisticiens sceptiques montrèrent que cette sélection des résultats positifs était un biais dans l’analyse finale, mais trop tard. Le gouvernement allemand considéra que l’expérience était un échec. Elle aura couté 400.000 deutschmarks au contribuable allemand.
Quelques années plus tard, pourtant, Tom Napier de la « Philadelphia Association for Critical Thinking » (PHACT) mettra tout le monde d’accord et l’on pourra alors considérer que le dossier est définitivement clos. Il reprit les données de l’expérience de Munich et reproduisit l’expérience. Sans budget, ni hangar… ni même sourcier. Il utilisa deux ordinateurs, l’un positionnant un chariot « virtuel » et l’autre indiquant une position au hasard, en respectant les paramètres des tests allemands. Il appliqua au résultat de ses series le même traitement statistique de celui qui avait été utilisé à Munich. Le résultat fut sans surprise : sur l’ensemble des tirages, les sourciers virtuels de Napier obtinrent des résultats légèrement inférieurs (mais sans que cela soit significatif au niveau statistique) aux radiesthésistes allemands. Mais les 6 meilleurs sourciers virtuels eurent un taux de succès largement supérieur.
zeGouky +1000
@Doolittle Fais moi un jet d’astuce + informatique, j’ai une brouette de dés si tu veux.
Clair, la démo est impressionnante, il faudrait voir sur un vrai 500.
Un truc intéressant à tester serait les « Alone in the dark » sur mac, grâce à fusion.
http://www.macintoshrepository.org/4909-alone-in-the-dark-3
Et la série des « Marathon », une siorte de doom sf.
*Troll ON* Et pour le 3000 ?? *Troll Off*
Tout ce met en place, avec ça et le prochain core qui inclura le FPU et une SIMD 128bit compatible SSE ça va poutrer sa mère et sa grand mère avec !
Clair que c’est cool !! Si ça pouvais arrêter tout le bordel qu’il y a en ce moment ce serais bien, parce que c’est très très très fatigant de voir un milieu de passionnés partir en sucette plutot que de profiter des opportunités offertes par des gars comme majsta, gunnard, Lukas Hartmann et tout ceux qui font que ça bouge dans le bon sens sans se prendre la tête avec tout le monde.
AMIGA RULEZZZZVoila la réponse que j’ai eu, c’est comparé au 6502, il y a même quelques mots de R.J.Mical (Si je pollue le post, un admin peut ouvrir un nouveau sujet)
La moitié des réponses pointent l’intérêt du 68K par rapport au système d’exploitation de l’Amiga. C’est du hors sujet.
On parle spécifiquement de l’assembleur, pas d’une machine en particulier.
Par ailleurs, parmi les 4 langages assembleur que j’ai appris, la facilité et la puissance d’utilisation du 6502/6510 a été claire.
Avec ses différents modes d’adressages (directs, indirects, pré-indexés, post-indexés, etc) utilisables pour presque toutes les instructions, c’était un plaisir de coder.
Pour le 68K, les modes d’adressage ne fonctionnent pas tous pour toutes les instructions. Des fois oui, des fois non. Bonjour les erreurs d’assemblage qui vont contraindre de revoir la façon de programmer et modifier le source. Grosse perte de temps et énervement à la clef.
Q. Why does the Lynx use a 6502 and not a 68000?
A. « Some people believe it’s less of a processor than the 68000, for example. That series of chip was used in the Amiga, but it wouldn’t make our machine do things any better. In fact, it would only make the unit larger and more expensive. It’s also harder to write 68000 code, so we definitely made the right decision. »
–R.J. Mical
« The real answer for the choice for the 6502 vs. 68000 was price. Secondary considerations (that did not really enter into the decision making process): 68000 code is very fat compared to 6502 code. An application that takes 1K of 6502 code averages 2.5 to 3K of 68000 code. The 6502 is very bus-efficient, the 68000 has lots of dead time on the bus. As for it being harder to write 68000 code, that is probably not true, and in any case was not part of the reason the decision was made. »
–Stephen Landrum
Additionally, inside sources at Atari say that one major reason for the 6502 vs 68000 processor choice was that the 6502 design was available as a component that could be plugged into a custom chip design. This allowed engineers to build a chip with a 6502 and other supporting hardware around it all in one package. It is only around 1993-1994 that Motorola offered the 68000 as a design component.
Il est dommage que ces modes d’adressages n’aient pas été réutilisés. ça aurait bien simplifié le codage en ASM 68k.
En même temps, les 2 cpu 65xx et 68k sont bien différents : 4 ans d’écart, 8 bits vs 16 bits, 25$ vs 140$, 1MHz vs 8MHz
Autre particularité du 6502, c’était un cpu qui tenait à la fois du RISC et du CISC.
Même les instructions utilisant les modes d’adressage complexes faisaient que chaque instruction ne prenait que 2 à 7 cycles d’horloge au maximum. Sur le 68K, on va de 4 à plus de 30 cycles d’horloge. Le max est d’environ 150 cycles pour la multiplication et la division (que ne faisait pas le 6502 de base mais son grand frère 16 bits à 20MHz).
Après avoir pris le temps de passer en revue le jeu d’instruction du 68K, il est indéniable que le les modes d’adressage qui « fluctuent » d’une instruction à l’autre sont rédhibitoires :
Pour être opérationnel de façon efficace sur le 68K, il faut connaître à fond PAR COEUR tous les modes d’adressage instruction par instruction…
Ben voyons ! On n’a que ça à faire. Déjà que coder en ASM c’est plus long qu’en langage évolué, ça devient le pompon.
Bon, après mettre pris ça, je suis en train de rechercher mes dents 😉
Merci pour vos réponses, si vous avez d’autres exemples n’hésitez pas, je pourrais faire plus de promo 😉
Petite question pour les programmeurs.
J’ai toujours entendu dire que l’assembleur 68k était un des plus simple/plaisant à utilisé. En tant que bon fanboy d’Amiga, j’aimerai pouvoir expliquer pourquoi à un ami qui connais la programmation (assembleur et autres).
Quelqu’un pourrait me faire un petit topo ? Même s’il y a des choses uniquement compréhensibles par un programmeur 🙂
Merci,
Amiga RULEZZZZZZZ
Voici la mise à jour SILVER2 du Core APOLLO pour les Vampire2 V600-2.
Pour effectuer la mise à jour de votre Vampire2, veuillez télécharger ce fichier exécutable AMIGA.
Démarrer ce programme à partir du CLI.Veuillez noter que la mise à jour reprogramme votre Vampire.
La mise à jour prendra quelques secondes.
Une coupure de courant, éteindre l’ordinateur où tout autre problème durant la mise à jour peut rendre votre Vampire inopérante.Veuillez noter que vous effectuez cette mise à jour à vos propres risques.
La Team à Paulo (Pardon, la Team DE Paulo… l’Apollo-Team) ne pourrait être tenue pour résponsable d’aucun problème, défaillance ou perte de donnée.Veuillez noter que si votre Vampire2 à été rendue non fonctionelle, comme décrit, suite à une coupure de courant – vous pouvez rendre la Vampire opérationelle à nouveau en utilisant un dispositif de flashage externe (par exemple, l’USB Blaster). Ce dispositif n’est pas inclus et doit être acheté séparément.
****************************************************************
SILVER-2 Journal des Modifications.
La mise à jour du Core SILVER2 apporte les changements suivants.
* Icache Prefetchers amélioré.
Exécution du code plus rapide.* Dcache Prefetchers amélioré.
Traitement des données plus rapide.* Nouveau Controleur Mémoire.
Fastmem bien plus rapide.* Compatibilité des jeux améliorée.
(certains jeux étaient trop rapides).
L’IRQ sur des Amigas lent peut rebondir avec un Core CPU très rapide. Par exemple 68060 et Apollo.
Apollo est maintenant renforcé afin d’empêcher efficacement l’IRQ de rebondir.* Compatibilité des jeux améliorée.
(certains jeux étaient trop lents).
L’exécution des instructions en Chip mem est désormais accélérée.* Instruction Bitfield corrigée.
Cela corrige FBLIT et certaines applications.* Amélioration de la sortie vidéo du SAGA.
* Amélioration du CPU.
Quelques Fusions d’instructions supplémentaires sont supportées.Version Originale
Here is SILVER2 APOLLO Core Update for the Vampire2 V600-2
To update your Vampire2 please download this AMIGA executable file.
Start the update program from CLI.
Please note the update will reprogram your VAMPIRE.
The update will take several seconds.
Turning the computer off during the update, a power-outage or other failure can render your Vampire non-operational.
Please note that you will do the update on your own personal risk.
The Apollo-Team it not liable for any problem, failures or data loss.
Please note that if your turn the Vampire2 non-functional as described because of powerloss – you can get the Vampire operational again by using an external flash device. This device is not included and must be purchased separately.
************************************************************
SILVER-2 CORE Change Log
The SILVER2 Core update will bring you the following changes
* Improved Icache Prefetchers
Faster Code execution* Improved Dcache Prefetchers
Faster Data handling* New memory controller
Much faster Fastmem.* improved Game compatibility
(some games running to fast)
IRQ on slow AMIGAs can bounce with very fast CPU cores. E.g 68060 and Apollo
Apollo is now enhanced to reliable prevent IRQ from bouncing* improved Game compatibility
(some games running to slow)
Instruction execution in chip mem is speed up now* Bitfield Instructions fixed.
This fixes FBLIT and some applications* improved SAGA Chunky Video out
* improved CPU
Some more instruction Fusings SupportedDéja mis par Flype.
QUELQU’UN A DES YEUX A VENDRE PAS CHER ???
