› Forums › Rechercher
Résultats de la recherche sur « morphos »
-
Bonjour,
pour ceux que ça pourrait intéresser, j’ai résolu le problème de la façon suivante : j’ai installé le jeu sur PC (Windows) dans DosBos. J’ai fait une première sauvegarde. J’ai récupéré les fichiers de sauvegarde que j’ai transféré sur MorphOS et à partir de là, je semble pouvoir sauvegarder correctement.
A moi les nuits arabiques!
-
Moi aussi je manque de place, mais si personne du coin veut le prendre je peut éventuellement me déplacer depuis Montpellier.
-
désolé hivernaal, je ne peux malheureusement te la mettre de côté.
www.amigang-store.com
-
ah quel dommage j’y étais il y a 3 jours !!!!!!!!!!!!!!!!
-
dans le forum Petites Annonces
20 août 2013 à 8h45Bonjour,
cause travaux et manque de place, je dois me séparer rapidement de mon eMac 1.42 GHz avec MorphOS 3.2 avec sa licence.
A venir chercher sur Salon de Provence.
www.amigang-store.com
-
Admin @ScudY : Tout le plaisir est pour ouame ! ^^
@Serge : Désolé ! ^^ Pour MorphOS, ça se trouve dans les Préférences de MorphOS au rayon « Souris ».
Dans AmigaOS 4, y’a toujours le Input dédié au combo clavier/souris. Apparemment, c’est la même pour AROS qui a toujours lui aussi une Preferences Input planqué dans le dossier Prefs ^^
—
/me se dit qu’on aura été exhaustif du coup !Only Amiga makes it possible !
-
salut Scudy,
quelle est ta version de l’AmigaOS? Es tu sur un Amiga dit classic A500-600-1200-2000-3000-4000 ? ou sur un
Amiga NG sous
MorphOS-AmigaOS4-AROS?
Sous le Workbench des Amigas Classics, il te faut aller dans ton disque dur qui contient ton système, puis dans le dossier des prefs et en suite dans input.
Tu y trouveras un réglage pour la vitesse de la souris.
Edit : doublé par Batteman sur le fil du rasoir 🙂
RyZen Rulez 😉
-
@ leo : n’utilisant plus mon Pegasos II de manière quotidienne que ce soit sous AmigaOS4 ou MorphOS car j’utilise mon MorphBook, j’avoue ne pas avoir d’idée si Timberwolf + HTML 5 est plus rapide qu’Odyssey + Flash.
Je testerai dés que je rentre de vacances vers le 22 ou 23.
Dans tous les cas, Odyssey Web Browser reste à l’heure actuelle le navigateur le plus complet et rapide de notre microcosme.
Je posterai mes impressions sur un autre fil car j’ai comme l’impression que ça part en hors sujet 🙂
Pour revenir au sujet principal, il serait intéressant de comprendre ce que QT peut apporter à l’Amiga en tant que kit graphique en comparaison à Réaction et MUI et cela sans même mentionner la faciliter à porter des applications que QT offre.
RyZen Rulez 😉
-
@Serge: je comprends mieux. Et la vidéo est plus rapide sur MorphOS ? Même en Flash ?
C’est lent sur QTWeb ?
-
MUI-OWB n’avançant pas sur OS4 alors que la version MorphOS est bien plus évoluée, OWB OS4 n’évoluant pas non plus et Timberwolf qui n’arrive pas a maturité, je trouve que c’est une solution comme une autre de tenter de porter QTWeb.
Il est vrai que ces solutions sont bien moins performantes que les applications portées vers nos systèmes graphiques natifs, néanmoins, seul l’AmigaOS4 a l’heure actuelle peut se réjourir d’avoir un vrai traitement de texte et un outil de manipulation graphique récent.
QT est donc une source de softs de plus ce qui n’est pas négligeable même si elles ne répondent pas aux exigeantes de qualité à la quelle on est habitués.
Tout le monde n’a pas sous la main un developeur hors paire pour porter et maintenir un soft aussi complexe qu’est odyssey web browser morphos 😉
RyZen Rulez 😉
-
@Henes :
Ok, merci pour cette explication très détaillée, j’y vois plus claire maintenant. En gros, si j’ai bien compris, ce qui pose problème avec AmigaOS et Morphos, c’est qu’il n’y a pas de HAL au niveau des fonction du systèmes et que chaque programme attaque directement la fonction, chose qu’il n’y a pas sur osX ? En tout les cas, si on prend tout ça en compte, il semble que le choix d’évolution du matériel pour les AmigaOS NG est bien limité….. Sauf pour Aros !
Maintenant, une autre question : comment diable faisait Amithlon pour permette des softs 68k et x86 de s’éxecuter conjointement dans le système ? En effet, il était possible de coder une application en x86 sous Amithlon. Pourtant, le problème de l’Indianness devait aussi se présenter ?
-
@Henes : Oui je comprends, j’avais oublié tous ces détails :p
Dans ce cas là, la solution serait de « virtualiser » ? Exécuter une application dans une « box » comme on pourrait dire. non ?Oui. C’est ce qu’à fait MorphOS dès son lancement. Et ce que n’a pas choisi de faire OS4… Ce dernier est donc obligé de tout repéter pour passer sur un processeur avec un autre endianess.
Sinon, il ne faut pas oublier que le z80, le 6502,… sont aussi little-endian. Et le PowerPC (enfin, sauf le G5/975) et bien d’autres (Sparc,…) sont bi-endian.
Mais le problème c’est surtout que l’OS n’abstrait pas cette notion et donne accès à tous à tous les programmes: on en revient toujours au même problème. C’est source de problème pour l’endianess, mais aussi pour le SMP, …
-
Et on retombe sur nos pattes. C’est exactement ce qu’est AROS en ce moment.
@Amidark: Intel a inventé le processeur, donc c’est bien Motorola qui est venu foutre la zone même si pour tous le fonctionnement des processeurs Mororola nous semble plus intuitif du point de vue Endianess.Avec ce qui est expliqué plus haut, il est facile de comprendre que AROS est différent d’AmigaOS4 et MorphOS et qu’il ne suffit pas de lui ajouter un émulateur 68k comme sur ses frères pour qu’il exécute des Applis 68k. C’est tout le système qu’il faudrait alourdir de traducteurs dans tous les sens.
Résultat des cours, l’affirmation qui dit qu’on n’a rien a perdre en cassant la compatibilité elle est vrai puisque la compatibilité binaire n’a jamais existé et la compatibilite sources n’a d’intérêt que pour partager facilement des développements entre tous les systèmes Amiga-Like.
Personnellement, je suis totalement pour l’implémentation de fonctions évoluées ( SMP, protection memoire etc ) dans AROS. Ça l’éloignerait des autres Amiga-Like en compatibilite mais ça l’enrichirait.
AmigaOS4 et MorphOS ont bien plus à perdre ( en apparences ) ce qui rebute ce passage brutal, néanmoins je pense qu’on devrait aussi y passer et implémenter un UAE dans les 3 systèmes pour la compatibilité.
RyZen Rulez 😉
-
@guibrush
xcode ne « translate » rien du tout : il ne byteswap rien et ne gère aucun problème d’endianess. Le problème n’existe pas sur OSX (ou avec qemu qui permet de lancer un binaire Linux PPC sur Linux x86).
Sur les Unix, les structures systèmes ne sont pas apparentes. Les programmes manipulent des entiers. Par exemple le process numéro « 7 » va correspondre pour le noyau à une tache située à l’adresse « 987654 ». Et à cette adresse tout est natif dans l’endianess favorite du CPU et bien aligné sur le bon multiple pour aller super super vite. Mais les programmes ne connaissent que le 7 et ne voient jamais le 987654.
Au pire si du code applicatif bigendian aurait besoin de donner ce « 7 » bigendian au noyau little endian pour qu’il en fasse quelque chose… ce code bigendian passerait sans le savoir par un petit stub/wrapper/bout_de_code_dédié_du_système qui transformerait ce 7 bigendian en 7 littleendian et ensuite tout fonctionnerait en little endian dans le noyau.
Tout le système peut donc être littleendian. Il ne sait même pas qu’il y a du n’importe quoi bigendian qui essaye de tourner quelque part.
L’ensemble du système peut donc être natif, optimisé à mort etc tout ce que tu veux.
Cela n’a strictement absolument et définitivement vraiment rien à voir avec comment un Amiga est obligé de fonctionner jusqu’à la fin des temps s’il veut être compatible avec lui même.
Sur Amiga, pas de « 7 ». Le système est ainsi fait qu’on manipule directement l’adresse « 987654 » et tout ce qu’il y a derrière elle. A l’adresse 987654, il y a peut-être une autre adresse 456789. Et à l’adresse 456789, il y a peut-être une autre adresse 654321 etc…
Le 68k bigendian étant arrivé en premier sur Amiga, cela veut dire que les logiciels doivent écrire ce 987654 en bigendian. Et le 456789 en bigendian aussi. Et le 654321 en bigendian etc…
Les données de la tache 987654 doivent donc être stockées en bigendian. Le système pourtant littleendian va donc devoir absolument les manipuler en bigendian. Et de fil en aiguille il en est de même pour les données à l’adresse 456789. Et à l’adresse 654321 etc.
Bref au final quasi tout doit être bigendian et respecter les contraintes d’alignement du 68k qui ne sont pas forcément optimales pour un x86 (c’est à dire que le CPU rame pour accéder aux données). Alors que le CPU est littleendian.
Au final, oui il serait théoriquement possible de faire un AmigaOS x86 similaire à MorphOS et HyperOS : qui exécute des programmes natifs x86 et des programmes 68k de manière transparentes.
MAIS toutes les structures systèmes publiques devraient être bigendian et alignées sur 16 bit. Ces structures systèmes étant, sur Amiga, les structures internes de l’OS : la majorité/beaucoup des données internes au systèmes devraient être bigendian et alignées sur 16bit.
Et, sur Amiga, ces données « internes » au système étant créées et manipulées par les programmes applicatifs… les programmes natifs x86 littleendian devraient donc manipuler toutes les structures systèmes en bigendian aussi.
Bref, grosso-modo, mis à part les données privées des applis x86, tout devrait être bigendian et aligné sur 16bit comme sur 68k.
Les logiciels AmigaOS x86 devraient donc tous faire des transformations little<->big endian pour chaque truc système. Et aller lire ces trucs via du code spécialement prévu pour ne pas planter ou ramer lorsqu’une donnée n’est pas alignée comme il faut.
Et il en est de même pour l’OS lui même. Du noyau jusqu’à la dernière bibliothèque perdue au fin fond du disque dur.
Techniquement c’est réalisable. Mais personne ne veut faire un OS et des applis ainsi compliquées et qui, à machine égale, seraient plus lentes que l’ensemble des autres OS : Windows, OSX etc…
Cela n’aurait juste aucun sens. A part pour le fun de dire « on l’a fait »…
-
De toute façon on veux rester compatible avec les Amiga os 6800×0, mais on est pas obliger de faire l’inverse, un prg sous Amigaos 4.1.X ou Morphos ou Aros n’est pas obligé d’être compatible 6800×0.
Mais je suis pas assez calé la dedans…
C’est dommage que le C soit si compliqué pour moi, ça doit être vachement intéressant de bidouiller en C surtout lorsque l’on tape dans le système
