Toutes mes réponses sur les forums
-
Got mine no problem, many thanks @sampedenawa
@Sampedenawa I’m interested in one assembled, I send you a PM. Grazie mille!
Merci SpiK3r, je vais suivre cette piste ! 🙂
J’espère n’être pas hors sujet…
Je recherche le nom du film ou l’épisode d’une série dont j’avais vu quelques minutes étant petit, autour de mes six ans je crois, donc vers la fin des années 70, je ne sais plus très bien et mes souvenirs peuvent être très déformés. Bref, on voit deux hommes parler, ils sont autour d’une table et le premier essaie de faire admettre au second que ce dernier est en fait un robot. Le second résiste, disant qu’il a des souvenirs d’enfance, mais se voit répondre qu’ils ont été programmés dans sa mémoire… Il objecte qu’il a une vie normale, une épouse (et des enfants je crois), mais la réponse est que c’est une mise en scène… Bref il fait l’objet d’un test en grandeur nature. Devant son incrédulité, le premier lui suggère de s’ouvrir le bras pour constater qu’il n’est pas fait de chair et d’os : c’est bien ce qu’il fait et on peut voir à l’écran qu’il est bien un robot sous sa « peau ».
Est-ce que cela dit quelque chose à quelqu’un ?
Qu’entend-on par « récent » ? gcc 6.3 est utilisé et donc disponible depuis plusieurs mois sous AROS 68k.
Ce que j’ai appris en réparant quelques walkmans haut de gamme construits dans les mêmes années que nos chers Amiga :
– en effet les condensateurs CMS d’aujourd’hui paraissent plus fiables, la technique semble avoir connu de gros problèmes autour des années 90, et on le paie aujourd’hui ;
– les tantales sont effectivement parfois déconseillés dans les circuits audio où ils peuvent induire une « coloration ». Mais ils sont réputés plus fiables, à la condition absolue que leur polarité soit respectée… en cas d’erreur ils peuvent exploser ! Or si un jour un problème surgit ailleurs dans le circuit, une conséquence inattendue peut dans certains cas être une inversion de polarité au niveau d’un condensateur… Et boom !
– les condensateurs sont comme des boîtes de conserves pas solides, contenant un acide très puissant : c’est lui qui attaque la carte, d’abord le vernis de protection, puis les pistes de cuivre qui s’oxydent alors en devenant vertes, puis la résine entre le substrat et la piste, entraînant le décollement de la piste. Pas toujours très rapidement, mais si rien n’est fait l’acide arrivera jusque là !
Le plus important lors du remplacement des condensateurs est de neutraliser cet acide… Et contrairement à une idée répandue, l’alcool ne sert à rien face à l’acide ! (Même à 95 degrés comme on le trouve en vente libre en Italie.)
Le seul moyen efficace est de préparer une pâte au pH légèrement alcalin avec du bicarbonate de soude et un peu d’eau, et de l’appliquer délicatement après avoir dé-soudé les condensateurs. J’utilise une vieille brosse à dents, et je n’hésite pas à recommencer l’opération pour être sûr d’avoir neutralisé l’acide (si le pH dépassait 7 la carte ne serait pas en danger, alors qu’elle l’est s’il reste en dessous). Bien sûr il faut rincer à chaque fois et ce n’est pas le plus facile, puis sécher à la fin : quelques minutes au four à 50 °C.
C’est seulement après cette neutralisation que l’on doit souder les nouveaux condensateurs.
Pour info, j’ai subi les mêmes symptômes sur mon MB Pro 17′ mid-2009 et là aussi le condensateur équivalent est désigné coupable par beaucoup de sites… je l’ai donc remplacé, mais cela n’a pas résolu le problème.
J’ai dû chercher une carte mère, que j’ai trouvée sur Aliexpress : 280 € livrée pour mon modèle.
En réponse à : [RÉSOLU] Script : injection de texte dans un fichier
19 novembre 2016 à 10h12 #274397BatteMan : Je serais très surpris que le SDK de MorphOS ne fournisse pas sed ?
En réponse à : [RÉSOLU] Script : injection de texte dans un fichier
18 novembre 2016 à 13h02 #274314Si sed est installé :
[code]sed -e « s/NOMDEVOLUMEDELISO/$nomvolume/g » ram:cd32.conf >ram:cd32.conf.modifié[/code]
EDIT : J’ai modifié un peu la ligne de commande, parce qu’apparemment pour que cela fonctionne il est plus facile d’utiliser une variable plutôt que [code]ram:T/nomvolume.txt[/code]
Donc avant la ligne sed ci-dessus, ton script doit par exemple comporter la commande :
[code]GetVolumeName_et_ses_arguments >ENV:nomvolume[/code]
La recompilation dont tu parles a pour but de permettre d’accéder à une partition AFS/SFS sous Linux. Mais cela n’est pas du tout nécessaire pour démarrer Aros avec Grub. Il faut bien voir que Grub s’exécute avant même le démarrage du noyau Linux (ou Aros, ou Windows) : de ce point de vue c’est vraiment juste un lanceur. Donc il est inutile que Linux lui-même soit capable d’accéder à une partition d’Aros. La seule chose indispensable, c’est que Grub soit capable de trouver le noyau d’Aros pour pouvoir lancer celui-ci. Le Grub d’Aros sait lire les partitions AFS/SFS et sait donc trouver le noyau d’Aros même sur ces partitions.
Pour un Grub de distribution Linux, le plus simple est de mettre le noyau d’Aros dans le répertoire de Grub. On peut très bien le mettre ailleurs, en fait où on veut sur une partition reconnue par le Grub de la distribution. Et il faut bien sûr faire une entrée (à la main) dans le fichier de configuration de Grub. Ça fait un bout de temps que je n’ai pas installé Aros native puisque j’utilise une mouture hébergée, mais à ma connaissance les choses n’ont pas changé sur ce terrain là.
Ainsi Grub n’a pas de difficulté à trouver Aros, qui est dans un répertoire d’un système de fichier qu’il connait, et il le lance sans problème… Le noyau d’Aros démarre donc, et trouve tout seul sa(ses) partition(s).
Le problème qui subsiste, c’est qu’à chaque mise à jour de Grub par la distribution Linux, le fichier de configuration et de démarrage utilisé par Grub est réinitialisé et les informations relatives à Aros disparaissent. Il faut alors remettre à la main la(les) ligne(s) correspondante(s), ce qui est vite fastidieux. Si l’on veut que les choses se passent bien et automatiquement, il faut mettre un peu les mains dans le cambouis et trouver ce qui sert de source à la distribution Linux pour mettre à jour le fichier précité (c’est en fait un autre fichier, en général caché, et encore moins facilement compréhensible… Mais il y a certainement des tutoriels).
J’ai toujours pris beaucoup de plaisir à lire les écrits de Cosmos, relatifs à l’Amiga ou autres…
Je profite donc de ce fil pour lui exprimer ma gratitude pour tous ces moments. J’espère vraiment que tout va bien.
Bref rien de nouveau depuis les années 90? et tous les OS actuels sont logés à la même enseigne.
Moi si, je trouve qu’il y a eu beaucoup d’évolutions par ailleurs depuis les années 90. Mais tu disais peut-être cela juste pour la protection mémoire ?
À propos spécifiquement de la protection mémoire, Michal Schulz voulait aller beaucoup plus loin quand il implémentait x86-64-aros, mais certains développeurs n’étaient pas d’accord avec la petite perte de compatibilité nécessaire (au niveau source évidemment, et cela n’aurait été implémenté que sur cette version) et Michal les a écoutés (à regrets je crois). Staf Verhaegen pense qu’il est possible de protéger plus qu’actuellement sans perdre de compatibilité, et il compte s’y essayer (entre autres choses) quand il en aura fini avec la réorganisation en cours de l’ABI C.
Quant au SillySMP (« SMP stupide » !), le but est pour l’instant entre autres de voir si ça peut fonctionner sans perte de compatibilité (cf. le mél pointé dans mon précédent post). Donc on pourrait imaginer un UAE qui apporterait plusieurs cœurs 68k, et AROS répartirait entre eux les applications et les bibliothèques Amiga (l’idée en a été évoquée en tous cas). En termes techniques, il est clair qu’à ce stade ce sera loin d’être optimum, puisque pour l’instant les Disable() et les Forbid() bloqueront tous les cœurs… Mais on n’en est qu’au début, et c’est passionnant.
Je serai curieux d’en savoir un peu plus la dessus, pas trop technique quand même. Pourrais tu développer un peu, ou donner un lien si tu as ?
Le sujet avait déjà été évoqué dans quelques fils de discussion sur divers sites Amiga et AROS, mais Jason McMullan est à l’origine de cette tentative, qu’il a annoncée dans ce mél : https://mail.aros.org/mailman/private/aros-dev/2013-August/075241.html (il faut s’être enregistré à la liste de diffusion des développeurs AROS pour pouvoir voir quelque chose au bout de ce lien (mais l’inscription est libre)). La discussion qui a suivi (il y a les liens nécessaires) est passionnante aussi bien sûr.
On peut suivre les développements (les commits sur la branche concernée) ici : https://gitorious.org/aros/aros/commits/silly-smp (pas besoin d’identification ici).
Du fait que chaque groupe ne voudra se faire avaler par l’autre et c’est normal, en ce qui concerne un AOS libre, il y a déjà AROS.
On parlait d’un OS moderne (au sens de « non limité »: on sait qu’Unix est (bien) plus ancien que l’Amiga). Ce n’est pas le cas d’AROS qui se traine les mêmes limitations que l’AmigaOS d’il y a presque 30 ans…
C’est pas ça AmigaOS 5. AROS c’est AmigaOS 3 open source et libre.
Non. En tous cas, AROS ce n’est pas que ça. Alors d’accord, AROS vise à être compatible avec AmigaOS 3.x au niveau API, et être compatible au niveau binaire sur Amiga, et au niveau source sur toute autre architecture. Et AROS-68k prouve que ces objectifs sont presque complètement atteints : presque tout fonctionne, même si certaines fonctions sont encore lentes pour les vraies bécanes. Mais je suis persuadé que les optimisations nécessaires vont continuer à arriver, comme elles le font depuis le début de ce projet.
Mais d’autre part, AROS est complètement portable, et tourne aussi bien sous 68k, PPC (qui manque de devs intéressés, les portages natifs ne sont donc plus bien maintenus, mais la version hébergée sur Linux a la réputation de bien fonctionner), arm (AROS fonctionne en natif et en hébergé sur Raspberry Pi par exemple, mais la version native demande encore du travail sur la pile USB pour être utilisable, et sur la HIDD video pour être performante… y a-t’il des devs interessés ?), et bien sûr sur i386 et x86-64.
Cette dernière version, dans sa mouture hébergée sur Linux, fait l’objet ces jours-ci de travaux relatifs au SMP (c’est une pré-version, sorte de preuve du concept, avant l’extension ou la ré-implémentation sur les autres architectures et moutures). On est donc bien loin des « limitations » de l’AmigaOS d’il y a 30 ans. D’ailleurs, une des merveilles du système d’exploitation de l’Amiga, c’est qu’il était assez modulaire pour être évolutif. Ainsi, l’OS n’avait pas besoin des puces propriétaires et les cartes graphiques par exemple ont toujours pu évoluer. Et AROS utilise effectivement Gallium3D sur les cartes supportées.
Et dois-je rappeler que si l’OS ne dispose pas (encore ?) de la protection mémoire, il y en a pourtant des prémisses fonctionnels : ainsi le noyau et ce qui est considéré comme étant en ROM sont protégés par la MMU contre toute tentative d’écriture. Et bien sûr beaucoup d’autres exemples montrent qu’on est bien au delà des seules fonctionnalités d’AmigaOS 3.x.
@bigdan: Ben moi aussi j’aime bien ça ! Non mais quel égoïste celui-là ! 😉
